Date: Sat, 8 Dec 2007 11:13:55 +0000 (GMT)
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Al Boldi <a1426z@gawab.com>
cc: Jakub Narebski <jnareb@gmail.com>, Andreas Ericsson <ae@op5.se>,
       Phillip Susi <psusi@cfl.rr.com>,
       Linus Torvalds <torvalds@linux-foundation.org>,
       Jing Xue <jingxue@digizenstudio.com>, linux-kernel@vger.kernel.org,
       git@vger.kernel.org
Subject: Re: git guidance
In-Reply-To: <200712072204.48410.a1426z@gawab.com>
Message-ID: <Pine.LNX.4.64.0712081106200.27959@racer.site>
References: <20071129105220.v40i22q4gw4cgoso@intranet.digizenstudio.com>
 <200712071353.11654.a1426z@gawab.com> <m3prxiu3oo.fsf@roke.D-201>
 <200712072204.48410.a1426z@gawab.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2044
Lines: 49

Hi,

On Fri, 7 Dec 2007, Al Boldi wrote:

> 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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/