Re: git versus CVS (versus bk)

From: Joel Becker <Joel.Becker@oracle.com>
Date: 2005-11-01 08:36:16
On Mon, Oct 31, 2005 at 01:00:18PM -0800, Junio C Hamano wrote:
> Do you think anybody is that perfect?

	I was being slightly facetious.  Of course everyone makes
mistakes and corrects them.  But if you _want_ the history, you have to
take it.  Otherwise, you are required to throw away the history
completely.  And that -- do you want the whole history or none of it --
is the crux of my question.

> What happens in reality is something like this:

[ understood work model snipped ]

> 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 ;-).

	I could care less about preserving my public image.  I'm an
idiot, I screw up all the time.  I only care that the tip of my tree is
respectable.
	I've seen arguments from folks on both sides -- the intermediate
history is important, warts and all, vs throw it all out for a clean
public history.  It seems that you fall into the second camp.
	That's fine, but can we make that work model a first-class
citizen?  Can we get a script that pulls one branch as a single,
un-historied (sic) commit into the current branch?  If this is The Way,
I should have to be mucking about with many steps of diff/patch (at
least unless my change is large enough to require split patches).

Joel
 

-- 

"It is not the function of our government to keep the citizen from
 falling into error; it is the function of the citizen to keep the
 government from falling into error."
	- Robert H. Jackson

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Received on Tue Nov 01 08:36:55 2005

This archive was generated by hypermail 2.1.8 : 2005-11-01 08:36:59 EST