Re: git guidance
- From
- Al Boldi <a1426z@gawab.com>
- Date
- Dec 7, 2007, 19:04 UTC
- Message-ID
- <200712072204.48410.a1426z@gawab.com>
- In-Reply-To
- <m3prxiu3oo.fsf@roke.D-201>
Jakub Narebski wrote:
Show 18 quoted lines
> Al Boldi <a1426z@gawab.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.
Show 5 quoted lines
> 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