

Labelled branches: why mercurial is better than git - bryanlarsen
http://jhw.dreamwidth.org/2049.html

======
mbanana
> All this is possible because Mercurial stores the name of the branch in the
> changeset header

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.

------
wnoise
I'm one of those people that don't see a problem. I don't care what branch
work happened on. I care whether it was merged or not. If I'm missing
something, could someone correct me? My responses would be as follows:

> 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.

~~~
stevelosh
Here are a few examples of where it's nice to have that extra information:

\- "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."

------
burgerbrain
tl;dr: Person finds a legitimate difference between Git and Hg and doesn't
seem to understand that different people could have different but equally
legitimate opinions on the situation.

 _"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.

~~~
bryanlarsen
I found the article itself very persuasive, your comment much less so.

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.

------
peterbotond
this is more of an argument on preference than quality of either process. yes,
we can use clay, wood or stone for sculpting.

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.

------
lann
I came here expecting to see this suggestion: add the branch name to your
commit message with a hook. Is this really not a common practice?

