Labelled branches: why mercurial is better than git
jhw.dreamwidth.org
jhw.dreamwidth.org
Then, everyone who tells that Mercurial is 'distributed' is lying.
Not everyone uses the same VCS. Suppose developer A received the set of patches via e-mail and applied them to his branch. Developer B received the same e-mails and applied them to his own branch. If their local branch names are different, these branches are now diverged forever.
> A) I need to know which branch ab3e2afd was committed to know whether to include it in the change control review for the upcoming release;
Why? Is there more to it than you need to know whether it is going in this release, and whether it went in the last release?
> B) I need to know which change is the first change in the release branch because I'd like to start a new topic branch with that as my starting point so that I'll be as current as possible and still know that I can do a clean merge into master and release later;
You need the earliest on the release branch that has not also been on the master branch.
> C)I need to know where topic branch started so that I can gather all the patches up together and send them to a colleague for review.
You need to send them all the commits on the topic branch that aren't merged elsewhere.
git has nice syntax for specifying ranges of commits of these forms.
- "Show me all commits by Jimmy, but don't bother with those he made on the i18n branch."
- "Did Sally make this change on the 3.1 branch and then backport it to 3.0, or did she start on 3.0 and then merge forward into 3.1?"
- "Show me all the changesets Steve has made on the 'stable' branch, so I can make sure he's only putting bugfixes there and not sneaking in new features."
I think that this is his biggest issue. When the graph gets complex there is no way to tell what belongs to a topic branch, to some quick bugfix branch merged both ways, etc. etc.
"The saddening thing is that so many Git users seem to have a conceptual block against even recognizing there is a problem here. They embrace the need for historical revisionism that their tools force on them, and they call it a virtue."
Because they have a different opinion. Stunner.
It doesn't seem like the feature would be hard to add to git, and wouldn't affect anybody who doesn't use it or turns it off in their preferences.
It would never be used in the Linux kernel environment, but it does seem like something very useful in a standard corporate environment with their common shared central code repositories.
Git could fix this fairly trivially, and should. (Or, rather, they could fix it fairly trivially if not for the peculiar insistence on the use of rebase operations.)
It showed a concrete benefit to the Mercurial workflow (or a concrete disadvantage to the Git one, if you prefer).
"Well that's just your opinion" isn't a valid argument against a real, tangible advantage like this. There may be reasons why the Git users prefer their method, and those are the valid arguments.
i like that git lets me rewrite commit logs, merge them into one commit, break up commits and so on. this gives me a current-dev branch and a cleaned-up branch when needed.