linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: david@lang.hm
To: Al Boldi <a1426z@gawab.com>
Cc: Andreas Ericsson <ae@op5.se>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	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
Date: Fri, 7 Dec 2007 13:17:38 -0800 (PST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0712071259020.12607@asgard.lang.hm> (raw)
In-Reply-To: <200712071353.11654.a1426z@gawab.com>

On Fri, 7 Dec 2007, Al Boldi wrote:

> Andreas Ericsson wrote:
>> 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 ###
>
> 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.

so if you have a script that does

echo "mail header" >tmpfile
echo "subject: >>tmpfile
echo >>tmpfile
echo "body" >>tmpfile

you want to have four seperate commits

what if you have a perl script

open outfile ">tmpfile";
print outfile "mail header\n";
print outfile "subject:\n\n";
print outfile "body\n";
close ourfile;

how many seperate commits do you think should take place?

what if $|=1 (unbuffered output, so that each print statement becomes 
visable to other programs immediatly)?

what if the file is changed via mmap? should each byte/word written to 
memory be a commit? or when the mmap is closed? or when the kernel happens 
to flush the page to disk?

'recording every change to a filesystem' is a very incomplete definition 
of a goal.

David Lang

  parent reply	other threads:[~2007-12-07 20:09 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-29 15:52 git guidance Jing Xue
2007-11-29 16:19 ` Linus Torvalds
2007-12-01  6:50   ` Al Boldi
2007-12-04 22:21     ` Phillip Susi
2007-12-07 17:35       ` Al Boldi
2007-12-06 18:24         ` Andreas Ericsson
2007-12-07 18:55           ` Al Boldi
2007-12-06 20:22             ` Johannes Schindelin
2007-12-07  4:37               ` Al Boldi
2007-12-07  8:40                 ` Andreas Ericsson
2007-12-07 10:53                   ` Al Boldi
2007-12-07 11:47                     ` Jakub Narebski
2007-12-07 19:04                       ` Al Boldi
2007-12-07 19:36                         ` Valdis.Kletnieks
2007-12-07 22:07                           ` Luke Lu
2007-12-08  4:56                           ` Al Boldi
2007-12-08  5:16                             ` Valdis.Kletnieks
2007-12-08 10:41                               ` Al Boldi
2007-12-08 11:13                         ` Johannes Schindelin
2007-12-07 12:30                     ` Andreas Ericsson
2007-12-07 21:17                     ` david [this message]
2007-12-07 22:00                     ` Björn Steinbrink
2007-12-06 21:46             ` Phillip Susi
2007-12-08  6:33     ` Martin Langhoff
  -- strict thread matches above, loose matches on Subject: below --
2007-11-27 22:33 Tilman Schmidt
2007-11-27 22:54 ` J. Bruce Fields
2007-11-27 22:55 ` Kristoffer Ericson
2007-11-27 23:52   ` Willy Tarreau
2007-11-28  0:43     ` Kristoffer Ericson
2007-11-28  0:49     ` Randy Dunlap
2007-11-28 12:49     ` Al Boldi
2007-11-28 13:45       ` Rogan Dawes
     [not found]         ` <Pine.LNX.4.64.0711281545170.27959@racer.site>
2007-11-28 17:14           ` Al Boldi
2007-11-28 18:14             ` Johannes Schindelin
2007-11-28 18:30               ` Al Boldi
2007-11-28 18:41                 ` Jakub Narebski
2007-11-29  5:27                 ` Al Boldi
2007-11-29 12:57                   ` Kyle Moffett
2007-11-28 13:38     ` Tilman Schmidt
2007-11-28 21:20       ` Willy Tarreau
2007-11-28 11:23   ` Tilman Schmidt
2007-11-28 12:31     ` Kristoffer Ericson
2007-11-27 23:20 ` Jan Engelhardt
2007-11-28 15:15   ` Dave Quigley
2007-11-28 15:57     ` Tilman Schmidt
2007-11-28 16:37       ` Dave Quigley
2007-11-28 19:10         ` willem
2007-11-28 19:18           ` Dave Quigley
2007-11-28 23:22   ` Haavard Skinnemoen
2007-11-29 12:45     ` Tilman Schmidt
2007-11-29 13:03       ` Haavard Skinnemoen
2007-11-28  7:41 ` Arkadiusz Miskiewicz
2007-11-29 12:51   ` Tilman Schmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.0712071259020.12607@asgard.lang.hm \
    --to=david@lang.hm \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=a1426z@gawab.com \
    --cc=ae@op5.se \
    --cc=git@vger.kernel.org \
    --cc=jingxue@digizenstudio.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=psusi@cfl.rr.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).