linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Al Boldi <a1426z@gawab.com>
To: Jakub Narebski <jnareb@gmail.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 22:04:48 +0300	[thread overview]
Message-ID: <200712072204.48410.a1426z@gawab.com> (raw)
In-Reply-To: <m3prxiu3oo.fsf@roke.D-201>

Jakub Narebski wrote:
> 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.  

> 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


  reply	other threads:[~2007-12-07 19:06 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 [this message]
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
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=200712072204.48410.a1426z@gawab.com \
    --to=a1426z@gawab.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=ae@op5.se \
    --cc=git@vger.kernel.org \
    --cc=jingxue@digizenstudio.com \
    --cc=jnareb@gmail.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).