Re: git rebase loses the additional changes in evil merges
From: Junio C Hamano gits...@pobox.com I think this is to be expected for git rebase, as it does not even look at merges. It is a way to find non-merge commits that haven't been applied yet, and apply them to the upstream to create a new linear history. I disagree. git rebase is not characterized as a way to find non-merge commits that haven't been applied yet, but rather (as described in the git-rebase manual page): git-rebase - Forward-port local commits to the updated upstream head All changes made by commits in the current branch but that are not in upstream are saved to a temporary area. [...] The commits that were previously saved into the temporary area are then reapplied to the current branch, one by one, in order. Now if you read far enough down the page, I'm sure it warns about merge commits. But the stated basic *intention* is to replicate the existing branch, re-rooted at a new place on the upstream branch. The current implementation fails this intention by losing changes made in merges. It fails this intention in a *dangerous* way by causing changes to be lost without warning. Dale -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git rebase loses the additional changes in evil merges
Dale Worley wor...@c-66-31-108-177.hsd1.ma.comcast.net writes: From: Junio C Hamano gits...@pobox.com I think this is to be expected for git rebase, as it does not even look at merges. It is a way to find non-merge commits that haven't been applied yet, and apply them to the upstream to create a new linear history. I disagree. git rebase is not characterized as ... The intention has always been I have these patches, some were applied upstream already, now what do I have left?. You do realize that you are disagreeing with somebody who designed the original git rebase (before the --preserve-merges was added), do you? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git rebase loses the additional changes in evil merges
From: Junio C Hamano gits...@pobox.com Sent: Tuesday, March 05, 2013 9:35 PM Dale Worley wor...@c-66-31-108-177.hsd1.ma.comcast.net writes: From: Junio C Hamano gits...@pobox.com I think this is to be expected for git rebase, as it does not even look at merges. It is a way to find non-merge commits that haven't been applied yet, and apply them to the upstream to create a new linear history. I disagree. git rebase is not characterized as ... The intention has always been I have these patches, some were applied upstream already, now what do I have left?. Given that many folk appear to trip up with their rebase mindset, does this suggest that a few tweaks to the manual may be in order to stop such misunderstandings? Perhaps: git-rebase - Forward-port local commits, not in upstream, to the updated upstream head and to avoid hidden asides, add a few more paragraph breaks into the description texts, and perhaps bring the Note that any commits in HEAD which introduce the same textual changes as a commit in HEAD..upstream are omitted sentence nearer the start. That is, don't let folks get a too simplistic view of rebase, missing its hidden powers. You do realize that you are disagreeing with somebody who designed the original git rebase (before the --preserve-merges was added), do you? However the broader userbase brings with it a better class of fool ;-) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git rebase loses the additional changes in evil merges
Philip Oakley philipoak...@iee.org writes: Given that many folk appear to trip up with their rebase mindset, does this suggest that a few tweaks to the manual may be in order to stop such misunderstandings? Perhaps. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git rebase loses the additional changes in evil merges
(git version 1.7.7.6) I've been learning how to use Git. While exploring git rebase, I've discovered that if the branch being rebased contains an evil merge, that is, a merge which contains changes that are in addition to the changes in any of the parent commits, the rebase operation will silenty lose those additional changes. I believe that this is a serious bug. The problem is not that Git does not propagate the additional changes (although I'd like it to do so), the problem is that the rebase *silently loses* changes in the code. It would be acceptable if Git detected the evil merge, notified me of it, and forced me to manually re-do it in order to finish the rebase. Throughout the Git design (as in other SCMs), care has been taken to not lose changes that the user has introduced. In this situation, that principle is violated. I have a script that demonstrates this failure, if that would be useful for testing purposes. Dale -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git rebase loses the additional changes in evil merges
Junio C Hamano gits...@pobox.com writes:
wor...@alum.mit.edu (Dale R. Worley) writes:
(git version 1.7.7.6)
I've been learning how to use Git. While exploring git rebase, I've
discovered that if the branch being rebased contains an evil merge,
that is, a merge which contains changes that are in addition to the
changes in any of the parent commits, the rebase operation will
silenty lose those additional changes.
I think this is to be expected for git rebase, as it does not even
look at merges. It is a way to find non-merge commits that haven't
been applied yet, and apply them to the upstream to create a new
linear history.
I can see the problem with --preserve-merges though. It will actually
just *redo* the merge; the name is wrong in the sense that it undertakes
nothing to preserve whatever evilness was in it.
I suppose in theory it could first redo the merge on the original
parents, and diff against the existing merge; that would be the evilness
component. Then it could attempt to apply the same evilness on the new
merge.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git rebase loses the additional changes in evil merges
Thomas Rast tr...@student.ethz.ch writes: Junio C Hamano gits...@pobox.com writes: wor...@alum.mit.edu (Dale R. Worley) writes: (git version 1.7.7.6) I've been learning how to use Git. While exploring git rebase, I've discovered that if the branch being rebased contains an evil merge, that is, a merge which contains changes that are in addition to the changes in any of the parent commits, the rebase operation will silenty lose those additional changes. I think this is to be expected for git rebase, as it does not even look at merges. It is a way to find non-merge commits that haven't been applied yet, and apply them to the upstream to create a new linear history. I can see the problem with --preserve-merges though. It will actually just *redo* the merge; the name is wrong in the sense that it undertakes nothing to preserve whatever evilness was in it. With or without evil, preserve-merges have other issues to make me not to trust it. Which side branches to take literally (i.e. just merge again) vs which side branches to also rebase (i.e. rebuild the history and then merge). It was suggested to make it apply the first-parent diff and record the result, I think. If that were an acceptable approach (I didn't think about it through myself, though), that would automatically cover the evil-merge case as well. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
