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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
