Re: git versus CVS (versus bk)

From: Junio C Hamano <junkio@cox.net>
Date: Oct 31, 2005, 21:00 UTC
Message-ID: <7vr7a1e719.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20051031195010.GM11488@ca-server1.us.oracle.com>

Joel Becker <Joel.Becker@oracle.com> writes:

Show 11 quoted lines

> 	In the distributed world, a pull of the "feature" repository
> pulls in all changes - the full history of the work.  This includes
> aborted tries, rewritten pieces, bug fixes, etc.  Here, the main
> repository has the detritus of the development process, but that also
> contains the full context of the work.  It goes against your claim that:
>
>> So with the distributed model, you don't have to publicly humiliate 
>> yourself when you do something stupid. Similarly, you don't have to 
>
> because that history will contain all your something stupids, plus your
> fixes for them.

Do you think anybody is that perfect?

What happens in reality is something like this:

 - you have a master tree, and your own throwaway topic
   branches.

 - you play in your own topic branches.  you make stupid
   mistakes and redo your changes many times.

 - when the tips of your topic branches are in good shape, you
   review the changes from the master tree as a whole, without
   the history.

 - you decompose the diff between the tips of your topic branch
   and the master branch into logical steps.

 - you branch off "sanitized" branches from the tip of the
   master, and apply the decomposed diffs, making one commit per
   logical change, until all your decomposed diffs are applied.

 - after making sure that the tips of the sanitized branches
   match the tips of their corresponding topic branch you did
   your work on, you throw away your true history and pretend
   you are perfect human.  Either ask your peer to pull from
   your sanitized branch tips, or run git-format-patch between
   the master and the sanitized branch tips and send them out as
   patches.

I do not know about the kernel tree but I would be surprised if any self-respecting developer wouldn't be doing this. The review-decomposition-reapplication cycle is *very* important for both keeping the public history clean and reviewable, and preservign your public image ;-).