Re: git guidance

From: Jakub Narebski <jnareb@gmail.com>
Date: Dec 7, 2007, 11:47 UTC
Message-ID: <m3prxiu3oo.fsf@roke.D-201>
In-Reply-To: <200712071353.11654.a1426z@gawab.com>

Al Boldi <a1426z@gawab.com> writes:

> Andreas Ericsson wrote:

Show 29 quoted lines

>> So, to get to the bottom of this, which of the following workflows is it
>> you want git to support?
>>
>> ### WORKFLOW A ###
>> edit, edit, edit
>> edit, edit, edit
>> edit, edit, edit
>> Oops I made a mistake and need to hop back to "current - 12".
>> edit, edit, edit
>> edit, edit, edit
>> publish everything, similar to just tarring up your workdir and sending
>> out ### END WORKFLOW A ###
>>
>> ### WORKFLOW B ###
>> edit, edit, edit
>> ok this looks good, I want to save a checkpoint here
>> edit, edit, edit
>> looks good again. next checkpoint
>> edit, edit, edit
>> oh crap, back to checkpoint 2
>> edit, edit, edit
>> ooh, that's better. save a checkpoint and publish those checkpoints
>> ### END WORKFLOW B ###
> 
> ### WORKFLOW C ###
> for every save on a gitfs mounted dir, do an implied checkpoint, commit, or 
> publish (should be adjustable), on its privately created on-the-fly 
> repository.
> ### END WORKFLOW C ###

It looks like it is WORKFLOW A (with the fact that each ',' is file
save stated explicitely rather than implicitely).

Show 9 quoted lines

> For example:
> 
>   echo "// last comment on this file" >> /gitfs.mounted/file
> 
> should do an implied checkpoint, and make these checkpoints immediately 
> visible under some checkpoint branch of the gitfs mounted dir.
> 
> Note, this way the developer gets version control without even noticing, and 
> works completely transparent to any kind of application.

Why not use versioning filesystem for that, for example ext3cow (which looks suprisingly git-like, when you take into account that for ext3cow history is linear and centralized, so one can use date or sequential number to name commits).

See GitLinks page on Git Wiki, "Other links" section:
  http://www.ext3cow.com/

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.

[*1*] I have lost link to post at LKML about rewriting history to
      arrive at perfect patch _series_. IIRC I have found it first
      time on this mailing list. I would be grateful for sending this
      link if you have it. TIA.

-- 
Jakub Narebski
ShadeHawk on #git