lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <m3prxiu3oo.fsf@roke.D-201> Date: Fri, 07 Dec 2007 03:47:49 -0800 (PST) From: Jakub Narebski <jnareb@...il.com> To: Al Boldi <a1426z@...ab.com> Cc: Andreas Ericsson <ae@....se>, Johannes Schindelin <Johannes.Schindelin@....de>, Phillip Susi <psusi@....rr.com>, Linus Torvalds <torvalds@...ux-foundation.org>, Jing Xue <jingxue@...izenstudio.com>, linux-kernel@...r.kernel.org, git@...r.kernel.org Subject: Re: git guidance Al Boldi <a1426z@...ab.com> writes: > 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 ### It looks like it is WORKFLOW A (with the fact that each ',' is file save stated explicitely rather than implicitely). > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists