On Tue, 23 Oct 2007, martin f krafft wrote:
>
> > So you can revert the data, but then if you want to get it back, you'll
> > need to revert the revert - you cannot just merge the branch again.
>
> Ouch!
Well, it's not necessarily "Ouch".
It actually depends on what you want to do. Sometimes this is a feature,
and the thing is, it actually works for other things that just merge
commits.
In other words, think of what happens when you merge some development
branch, and then "git revert" a single commit from that branch - the exact
same thing will happen - future merges of that branch will *not* re-do the
commit, because you "already have it", and you reverted it after-the-fact.
And in many ways, this is "obviously" what you want to happen!
Now, I say "obviously" in quotes, because it's not at all obvious in an
absolute sense - it may be that you reverted the commit not because it was
buggy, but because your stable branch wasn't ready for it yet, and maybe
in the future you do actually want the code that the revert reverted. So
in that sense, nothing is really "obvious", and this is simply how things
work. But I think that it's easier to explain why git does something like
this when you speak about normal commits, and it all makes sense.
When you revert the data from a merge, the exact same issue happens. A
revert (whether done by "git revert", or by the sequence of events I
described) very fundamentally undoes the *data* part, but leaves the
history intact, and that has implications for future events that think
about history - which is mostly "git merge", but there are other thigns
too.
As an example of "other things" that take history into account, think
about something like "git rebase". It's not a merge, but it also takes
history into account in certain ways: in particular, it may be effectively
a "series of cherry-picks", but it actually takes the history of both
branches into account, and will not re-apply a patch that already exists
in the target history.
What does that mean? Let's say that both histories contain a patch X (not
the same commit, but the same patch), but one history also contains the
revert of X. Again, the revert reverts the data, but it does *not* revert
the history, so when you cherry-pick all the stuff from the other branch,
X will *not* happen - even if it would apply cleanly, and even if a plain
"git cherry-pick" would have redone it!
Why? History, again. Because "git rebase" sees that the commit already
existed, it won't even try to apply it again, never mind that it could
have worked. The "revert" didn't undo the history, just the data.
So a "revert" is fundamentally different from a "undo". Most of the time
that's exactly what you want, and I'm not pointing this out as a problem,
I just wanted to point out that it has "effects". Sometimes the effects
are good, sometimes they are bad, and while they are always very reliable
and there's never any question about what git will do, people don't always
think like git, and whether the effects are "good" or "bad" is probably
entirely up to whether they match users expectations or not.
So sometimes the behaviour of "git revert" will be exactly what people
expected and wanted ("good, I'll never get that commit again when I pull,
because I told git that I don't want that commit"), and sometimes it will
_not_ be what people expected and wanted ("oh, I didn't get that commit,
even though I was now ready for it - because I had reverted it back when I
was *not* ready for it").
See? The logic is exactly the same in both cases, but one was good, the
other bad, and the only difference was really the mindset of the user.
A tool can't ever get "mindset of the user" differences right. At least
not until we add the "esp option" ;)
So I really don't want to push this as a problem or deficiency, I think
it's a good thing. But it's a good thing only when people are *aware* of
what "revert" really means.
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
