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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 7 Dec 2007 22:04:48 +0300 From: Al Boldi <a1426z@...ab.com> To: Jakub Narebski <jnareb@...il.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 Jakub Narebski wrote: > Al Boldi <a1426z@...ab.com> writes: > > 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/ Sure, Linus mentioned the cow idea before in this thread, but you would still need a few hacks to get some basic Version Control features. > 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? Thanks! -- Al -- 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