Throwing up a log of a conversation I had with exor674 from before this post was put up. Lightly cleaned up for coherency and to remove unrelated conversation tangents, otherwise presented without comment.
exor674> I (manually) forked the dw-free repo into a repo on bitbucket, and converted all my oauth-related MQ patches to branches
exor674> one thing I am not sure how I am going to handle is when the patches are committed assuming we use the upload patch style. I guess just merge default into the next branch down which should be a no-op merge unless other changes got in the way? exor674> ( and if I can manage this, I can manage with whatever we work with and will show if we can maybe use bitbucket to host? )
exor674> I think maybe one problem is if you pull/fetch that repo, all my branches will become into your thingy exor674> with git, if you fetch someone elses repo, you have to explicitly name the branch Afuna> so with git it's possible to just get the stable branch? Afuna> but not so with mercurial? exor674> I mean, if you are doing a lot of things where you PULL the branch to finish it exor674> you'll have your thingy tainted by ALL their branches exor674> while with git you should be able to only pull the one branch you want to work with exor674> or maybe not even track it locally
exor674> see, here's another case when I think hg is bad exor674> you can't pull my repo into your dw-free w/o screwing up your ability to push to the main repo ( without tainting it from my repo ) exor674> we'd have to pass flattened patches back and forth exor674> while I *think* with git you could pull my branch locally exor674> and still successfully work with the live repo Afuna> oh huh, that seems weird Afuna> I'd've thought that that was one thing hg would excel in! Afuna> not doubting you or antyhing, I'm just rather o_o that exor674> nope exor674> like I just now have all the branches in mine and accidentally tried to push to the core repo ( which wouldn't happen ) exor674> $ hg push exor674> pushing to http://hg.dwscoalition.org/dw-free exor674> searching for changes exor674> abort: push creates new remote branch 'feature/OAuth-DeepBackend'! exor674> (did you forget to merge? use push -f to force)
exor674> and remember the MESS when we switched to staging for a while? Afuna> I thought that was just because we didn't know what we were doing? exor674> nope. Because we moved off the default braaaanch
exor674> and tip is weird too exor674> for that, maybe exor674> because tip is the most recent commit in the rpo exor674> not the most recent commit on the branch or exor674> ( HG branching was added as an afterthought, as far as I can tell while it was designed into git? ) exor674> like the hg repo is just a repo exor674> tags are through a hack exor674> branches are probably a hack too Afuna> yeah exor674> everything's really in the same treeeeeeee exor674> git branches are real branches
Afuna> hg IIRC was for a while uh. the clone to a different folder as a barncha? exor674> hg wants you to maintain seperate repo trees exor674> instead of braaanching
Afuna> I think the v. best way to is to like Afuna> actually do a walkthrough of Afuna> "here's how we would develop a feature now" Afuna> "here's how we think it'd work in git" Afuna> "here's how we think it'd work in hg" Afuna> is the most important thing IMO
exor674> the mq process is probably easier then git exor674> but proper branching can NOT be done in hg exor674> without making a MESSSS! exor674> and what if you decided to name a branch develop/FixGreen exor674> and I named one that too, for something totally different exor674> we'd have a COLLIIIIISION exor674> when you pulled mine in to commit it exor674> with hg
Afuna> mq is fine for personal development, but it's harder for sharing transparently /o\ Afuna> it's possibel to publish the mq repo, but it's one more level of abstraction exor674> I think with git you could just check out remote/anall/develop/FixGreen exor674> and not track it locally exor674> so it'd be totally seperate from *your* develop/FixGreen
exor674> and bitbucket theoretically has pull requests
Afuna> I do wonder if I'm just missing something ,because so many people use mercurial happily * Afuna side eyes exor674> maybe we're both missing something Afuna> yeah maybe :( Afuna> another reason to mention the flow we have in mind? Afuna> so that if someone knows something we don't...
exor674> for instance here's a uh exor674> possibly a popular-used hg repo: https://bitbucket.org/pmetzger/growl/changesets exor674> looks like there are personal-work branches in the main repo exor674> here's another one that doesn't branch at all: https://bitbucket.org/snej/murky/overview exor674> I think it's a case of that you ahve to be CAREFUL in hg not to taint the repo when merging exor674> but you have to TRY HARD to taint a git repo while merging exor674> or https://bitbucket.org/lindenlab/ seems to use multiple hg repos instead of branchen -- scroll down to the bottom exor674> viewer-beta, viewer-development, viewere-release, etc exor674> and I think the branches being on ALL of those proves my thesis too that branching produces unfuntimes exor674> unfun times are unfun! exor674> and heh YEP exor674> http://pastie.org/private/gxjhmfchgxdmmva32lwjxw exor674> and you have to do a commit to close the branches exor674> or even: http://pastie.org/private/ozutvffnnmf8hdl7o3zwfw exor674> I do not get what to do in that case exor674> and see how badly that pollutes the repo
Afuna> does stash work like an unnamed mq? Afuna> hm. though Id' rather encourage branching than stash, at least in terms of... Afuna> regular flow, and use stash only for really really quick things
Afuna> oh hmmm http://mercurial.selenic.com/wiki/BranchingExplained Afuna> yeah looks like you're right there's really no way to... Afuna> do the branching hting at least not cleanly, in mercurial exor674> i mean we could maintain a production and development branch exor674> and get all mergey with it exor674> but yeah
no subject
exor674> I (manually) forked the dw-free repo into a repo on bitbucket, and converted all my oauth-related MQ patches to branches
exor674> one thing I am not sure how I am going to handle is when the patches are committed assuming we use the upload patch style. I guess just merge default into the next branch down which should be a no-op merge unless other changes got in the way?
exor674> ( and if I can manage this, I can manage with whatever we work with and will show if we can maybe use bitbucket to host? )
exor674> I think maybe one problem is if you pull/fetch that repo, all my branches will become into your thingy
exor674> with git, if you fetch someone elses repo, you have to explicitly name the branch
Afuna> so with git it's possible to just get the stable branch?
Afuna> but not so with mercurial?
exor674> I mean, if you are doing a lot of things where you PULL the branch to finish it
exor674> you'll have your thingy tainted by ALL their branches
exor674> while with git you should be able to only pull the one branch you want to work with
exor674> or maybe not even track it locally
exor674> see, here's another case when I think hg is bad
exor674> you can't pull my repo into your dw-free w/o screwing up your ability to push to the main repo ( without tainting it from my repo )
exor674> we'd have to pass flattened patches back and forth
exor674> while I *think* with git you could pull my branch locally
exor674> and still successfully work with the live repo
Afuna> oh huh, that seems weird
Afuna> I'd've thought that that was one thing hg would excel in!
Afuna> not doubting you or antyhing, I'm just rather o_o that
exor674> nope
exor674> like I just now have all the branches in mine and accidentally tried to push to the core repo ( which wouldn't happen )
exor674> $ hg push
exor674> pushing to http://hg.dwscoalition.org/dw-free
exor674> searching for changes
exor674> abort: push creates new remote branch 'feature/OAuth-DeepBackend'!
exor674> (did you forget to merge? use push -f to force)
exor674> and remember the MESS when we switched to staging for a while?
Afuna> I thought that was just because we didn't know what we were doing?
exor674> nope. Because we moved off the default braaaanch
exor674> and tip is weird too
exor674> for that, maybe
exor674> because tip is the most recent commit in the rpo
exor674> not the most recent commit on the branch or
exor674> ( HG branching was added as an afterthought, as far as I can tell while it was designed into git? )
exor674> like the hg repo is just a repo
exor674> tags are through a hack
exor674> branches are probably a hack too
Afuna> yeah
exor674> everything's really in the same treeeeeeee
exor674> git branches are real branches
Afuna> hg IIRC was for a while uh. the clone to a different folder as a barncha?
exor674> hg wants you to maintain seperate repo trees
exor674> instead of braaanching
Afuna> I think the v. best way to is to like
Afuna> actually do a walkthrough of
Afuna> "here's how we would develop a feature now"
Afuna> "here's how we think it'd work in git"
Afuna> "here's how we think it'd work in hg"
Afuna> is the most important thing IMO
exor674> the mq process is probably easier then git
exor674> but proper branching can NOT be done in hg
exor674> without making a MESSSS!
exor674> and what if you decided to name a branch develop/FixGreen
exor674> and I named one that too, for something totally different
exor674> we'd have a COLLIIIIISION
exor674> when you pulled mine in to commit it
exor674> with hg
Afuna> mq is fine for personal development, but it's harder for sharing transparently /o\
Afuna> it's possibel to publish the mq repo, but it's one more level of abstraction
exor674> I think with git you could just check out remote/anall/develop/FixGreen
exor674> and not track it locally
exor674> so it'd be totally seperate from *your* develop/FixGreen
exor674> and bitbucket theoretically has pull requests
Afuna> I do wonder if I'm just missing something ,because so many people use mercurial happily
* Afuna side eyes
exor674> maybe we're both missing something
Afuna> yeah maybe :(
Afuna> another reason to mention the flow we have in mind?
Afuna> so that if someone knows something we don't...
exor674> for instance here's a uh
exor674> possibly a popular-used hg repo: https://bitbucket.org/pmetzger/growl/changesets
exor674> looks like there are personal-work branches in the main repo
exor674> here's another one that doesn't branch at all: https://bitbucket.org/snej/murky/overview
exor674> I think it's a case of that you ahve to be CAREFUL in hg not to taint the repo when merging
exor674> but you have to TRY HARD to taint a git repo while merging
exor674> or https://bitbucket.org/lindenlab/ seems to use multiple hg repos instead of branchen -- scroll down to the bottom
exor674> viewer-beta, viewer-development, viewere-release, etc
exor674> and I think the branches being on ALL of those proves my thesis too
that branching produces unfuntimes
exor674> unfun times are unfun!
exor674> and heh YEP
exor674> http://pastie.org/private/gxjhmfchgxdmmva32lwjxw
exor674> and you have to do a commit to close the branches
exor674> or even: http://pastie.org/private/ozutvffnnmf8hdl7o3zwfw
exor674> I do not get what to do in that case
exor674> and see how badly that pollutes the repo
Afuna> does stash work like an unnamed mq?
Afuna> hm. though Id' rather encourage branching than stash, at least in terms of...
Afuna> regular flow, and use stash only for really really quick things
Afuna> oh hmmm http://mercurial.selenic.com/wiki/BranchingExplained
Afuna> yeah looks like you're right there's really no way to...
Afuna> do the branching hting at least not cleanly, in mercurial
exor674> i mean we could maintain a production and development branch
exor674> and get all mergey with it
exor674> but yeah