Re: What's in git.git

From: Junio C Hamano <junkio@cox.net>
Date: Feb 10, 2006, 00:47 UTC
Message-ID: <7vpslw3uqg.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <43EB290A.6060407@op5.se>

Andreas Ericsson <ae@op5.se> writes:

> But wouldn't rebase detect the commits as being the same, unless
> you've made changes to them? If it doesn't, can we teach it to discard
> parent info and re-hash the commits if they conflict? That should
> solve most such merge-conflicts, really.

Yes, rebase would help somewhat (I said that didn't I?). But the thing is, with the "pu" workflow of mine so far, I _did_ rewrite/replace commits on my topic branches, especially when they are young and not in a good shape.

For example, the topic branch jc/nostat ("Assume unchanged" git) has four commits since it forked from the mainline:

 + [jc/nostat] "Assume unchanged" git: --really-refresh fix.
 + [jc/nostat^] ls-files: debugging aid for CE_VALID changes.
 + [jc/nostat~2] "Assume unchanged" git: do not set CE_VALID with --refresh
 + [jc/nostat~3] "Assume unchanged" git

With the "pu" workflow, I would have merged the "do not set CE_VALID" commit and "--really-refresh fix" commit into the first "Assume unchanged" commit after I found out about these two small mistakes. So one day "pu" would have contained what is there right now as "jc/nostat~3", but the next day it would have a commit, perhaps with slightly modified log message from what is there as "jc/nostat~3" to contain fixes jc/nostat~2 and jc/nostat have right now (the ls-files one is a debugging aid so I would have left it separate even with the rewriting-history workflow).

That kind of rewriting history is not being honest, but the end result is that people do not have to see intermediate states and earlier mistakes when things are fully cooked and ready to be merged into the mainline. By promising not to rewind "next" and topic branches that go to "next", I am closing the door for me to do this kind of history rewrite freely. I can still rewrite things I have not pushed out yet, though.

BTW, it is always a judgement call if it is a good thing to squash commits into one like this. Being too honest hurts the usability of the history. Especially if you have a trivial "Oh, what I checked in does not even compile" kind of mistakes left in the development trail, that would inconvenience bisection. Being too sanitized OTOH tends to drop a single big ball of wax into the history, and makes correcting things harder if it is found later that only parts of that change are desired and the other parts are not.