Re: git guidance

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Dec 8, 2007, 11:13 UTC
Message-ID: <Pine.LNX.4.64.0712081106200.27959@racer.site>
In-Reply-To: <200712072204.48410.a1426z@gawab.com>

Hi,

On Fri, 7 Dec 2007, Al Boldi wrote:

Show 14 quoted lines

> Jakub Narebski wrote:
>
> > Version control system is all about WORKFLOW B, where programmer 
> > controls when it is time to commit (and in private repository he/she 
> > can then rewrite history to arrive at "Perfect patch series"[*1*]); 
> > something that for example CVS failed at, requiring programmer to do a 
> > merge if upstream has any changes when trying to commit.
> 
> Because WORKFLOW C is transparent, it won't affect other workflows.  So 
> you could still use your normal WORKFLOW B in addition to WORKFLOW C, 
> gaining an additional level of version control detail at no extra cost 
> other than the git-engine scratch repository overhead.
> 
> BTW, is git efficient enough to handle WORKFLOW C?

The question is not if git is efficient enough to handle workflow C, but if that worflow is efficient enough to help anybody.

Guess what takes me the longest time when committing? The commit message. But it is really helpful, so there is a _point_ in writing one, and there is a _point_ in committing when I do it: it is a point in time where I expect the tree to be in a good shape, to be compilable, and to solve a specific problem which I describe in the commit message.

So I absolutely hate this "transparency". Git _is_ transparent; it does not affect any of my other tools; they still work very well thankyouverymuch.

What your version of "transparency" would do: destroy bisectability, make an absolute gibberish of the history, and more!

Nobody could read the output of "git log" and form an understanding what was done. Nobody could read the commit message for a certain "git blame"d line that she tries to make sense of.

IOW you would revert the whole meaning of the term Source Code Management.

Hth, Dscho