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."
The way he expressed it is not perfect... but seeing other comparisons claiming the opposite (permanent branches in hg are an issue), we might need some posts like that before people notice it's just a preference.
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.
Their opinion is wrong. There's no value to rewriting history because one's tools can't handle a sane mode of operation.
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 seemed to me that the entire point of this post was to explain how the other opinion is flawed.
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'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.
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."
For example with situation C: with cherry-picking, merging and other actions done by many people - how do you tell which commits are on the topic branch but not merged? How can you tell apart from the commit message, which could've been changed?
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.
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.
> 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.
12 comments
[ 3.2 ms ] story [ 32.2 ms ] thread"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.
> 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.
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.
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.