Jed Brown writes: > On Tue, Mar 5, 2013 at 8:09 PM, Sean Farley <sean at mcs.anl.gov> wrote: > >> And this is why I think git makes things more complicated than need >> be. >> > > By keeping remotes namespaced and having exactly one branching > mechanism?
By not forcing any branching? All of what you have described so far can be accomplished, easily, with forking / pull-requests and the remote-branches extension today [1]. You can get even more fancy after Atlassian implements non-publishing repos. >> > As I mentioned before, bookmarks in hg are much more in-your-face than >> git >> > branches. Up until now, we have not allowed multiple heads in any PETSc >> > repositories. Can we do it without confusing people? >> >> I disagree about them being in your face. I think you're making this >> workflow more complicated than need be. >> > > To start with, 'hg log' shows you all bookmarks. The normal user following > petsc-dev will issue > > $ hg pull -u > $ hg log > > to see what is new. The fact that many normal commands show all the > bookmarks makes them disruptive. The ability to customize those commands or > modify them to restrict to the current bookmark is besides the point > because the default is overwhelming. See my above recommendation. You don't need bookmarks or anything else fancy. Just remote-branches, really. >> As for having multiple heads, I wouldn't recommend that workflow for >> this group just yet. > > Okay, so you're retracting your recommendation that Barry push on a > bookmark? I didn't mean to imply that Barry should use bookmarks (in fact, he shouldn't). Only that you could achieve most of what you're describing about git's branches, etc. I like the fork / pull-request model because, 1) it's simple to understand 2) everyone can clean up their history at their own pace 3) a developer can pull another dev's repo (and keep track of it) with the remote-branches extension; but it isn't necessary 4) it's a minimal (if any) disruption of people's current workflow, yet gains a lot of features mentioned before (cleaner history, more stability in petsc-dev, etc.) [1] - http://mercurial.selenic.com/wiki/RemoteBranchesExtension
