Re: git guidance

Re: git guidance

[Jing Xue]

Quoting Al Boldi <a1426z@gawab.com>:

> Sure, browsing is the easy part, but Version Control starts when things
> become writable.

But how is that supposed to work?  What happens when you make some
changes to a file and save it?  Do you want the "git file system" to
commit it right aways or wait until you to issue a "commit" command?
The first behavior would obviously be wrong, and the second would make
the "file system" not operationally transparent anyways. Right?

By the way, the only SCM I have worked with that tries to mount its
repository (or a view on top of it) as a file system is ClearCase with
its dynamic views. And, between the buggy file system implementation,
the intrusion on workflow, and the lack of scalability, at least in
the organization I worked for, it turned out to be a horrible,
horrible, horrible idea.

Cheers.
-- 
Jing Xue

Re: git guidance

[Linus Torvalds]

On Thu, 29 Nov 2007, Jing Xue wrote:
> 
> By the way, the only SCM I have worked with that tries to mount its
> repository (or a view on top of it) as a file system is ClearCase with
> its dynamic views. And, between the buggy file system implementation,
> the intrusion on workflow, and the lack of scalability, at least in
> the organization I worked for, it turned out to be a horrible,
> horrible, horrible idea.

Doing a read-only mount setup tends to be pretty easy, but it's largely 
pointless except for specialty uses. Ie it's obviously not useful for 
actual *development*, but it can be useful for some other cases.

For example, a read-only revctrl filesystem can be a _very_ useful thing 
for test-farms, where you may have hundreds of clients that run tests on 
possibly different versions at the same time. In situations like that, the 
read-only mount can actually often be done as a user-space NFS server on 
some machine.

The advantage is that you don't need to export close to infinite amounts 
of versions from a "real" filesystem, or make the clients have their own 
copies. And if you do it as a user-space NFS server (or samba, for that 
matter), it's even portable, unlike many other approaches. The read-only 
part also makes 99% of all the complexity go away, and it turns out to be 
a fairly easy exercise to do.

So I don't think the filesystem approach is _wrong_ per se. But yes, doing 
it read-write is almost invariably a big mistake. On operatign systems 
that support a "union mount" approach, it's likely much better to have a 
read-only revctl thing, and then over-mount a regular filesystem on top of 
it.

Trying to make it read-write from the revctl engine standpoint is almost 
certainly totally insane.

				Linus

Re: git guidance

[Al Boldi]

Jing Xue wrote:
> Quoting Al Boldi <a1426z@gawab.com>:
> > Sure, browsing is the easy part, but Version Control starts when things
> > become writable.
>
> But how is that supposed to work?  What happens when you make some
> changes to a file and save it?  Do you want the "git file system" to
> commit it right aways or wait until you to issue a "commit" command?
> The first behavior would obviously be wrong, and the second would make
> the "file system" not operationally transparent anyways. Right?

Not sure what you mean by operationally transparent?  It would be transparent 
for the updating client,  and the rest of the git-users would need to wait 
for the commit from the updating client; which is ok, as this transparency 
is not meant to change the server-side git-update semantic.

Linus Torvalds wrote:
> On Thu, 29 Nov 2007, Jing Xue wrote:
> > By the way, the only SCM I have worked with that tries to mount its
> > repository (or a view on top of it) as a file system is ClearCase with
> > its dynamic views. And, between the buggy file system implementation,
> > the intrusion on workflow, and the lack of scalability, at least in
> > the organization I worked for, it turned out to be a horrible,
> > horrible, horrible idea.

Judging an idea, based on a flawed implementation, doesn't prove that the 
idea itself is flawed.

And...
> Doing a read-only mount setup tends to be pretty easy, but it's largely
> pointless except for specialty uses. Ie it's obviously not useful for
> actual *development*, but it can be useful for some other cases.
>
> For example, a read-only revctrl filesystem can be a _very_ useful thing
> for test-farms, where you may have hundreds of clients that run tests on
> possibly different versions at the same time. In situations like that, the
> read-only mount can actually often be done as a user-space NFS server on
> some machine.
>
> The advantage is that you don't need to export close to infinite amounts
> of versions from a "real" filesystem, or make the clients have their own
> copies. And if you do it as a user-space NFS server (or samba, for that
> matter), it's even portable, unlike many other approaches. The read-only
> part also makes 99% of all the complexity go away, and it turns out to be
> a fairly easy exercise to do.
>
> So I don't think the filesystem approach is _wrong_ per se. But yes, doing
> it read-write is almost invariably a big mistake. On operatign systems
> that support a "union mount" approach, it's likely much better to have a
> read-only revctl thing, and then over-mount a regular filesystem on top of
> it.

You could probably do that, or you could instead use cp -al.  Both would 
require some hacks to allow some basic version control.

> Trying to make it read-write from the revctl engine standpoint is almost
> certainly totally insane.

Sure, you wouldn't want to change the git-engine update semantics, as that 
sits on the server and handles all users.  But what the git model is 
currently missing is a client manager.  Right now, this is being worked 
around by replicating the git tree on the client, which still doesn't 
provide the required transparency.

IOW, git currently only implements the server-side use-case, but fails to 
deliver on the client-side.  By introducing a git-client manager that 
handles the transparency needs of a single user, it should be possible to 
clearly isolate update semantics for both the client and the server, each 
handling their specific use-case.


Thanks!

--
Al

Re: git guidance

[Phillip Susi]

Al Boldi wrote:
> Judging an idea, based on a flawed implementation, doesn't prove that the 
> idea itself is flawed.

It isn't the implementation that is flawed, it is the idea.  The entire 
point of a change control system is that you explicitly define change 
sets and add comments to the set.  The filesystem was designed to allow 
changes to be made willy-nilly.  If your goal is to perform change 
control only with filesystem semantics, then you have a non starter as 
their goals are opposing.  Requiring an explicit command command is 
hardly burdensome, and otherwise, a git tree is perfectly transparent to 
non git aware tools.

> Sure, you wouldn't want to change the git-engine update semantics, as that 
> sits on the server and handles all users.  But what the git model is 
> currently missing is a client manager.  Right now, this is being worked 
> around by replicating the git tree on the client, which still doesn't 
> provide the required transparency.

It isn't missing a client manager, it was explicitly designed to not 
have one, at least not as a distinct entity from a server, because it 
does not use a client/server architecture.  This is very much by design, 
not a work around.

What transparency are you requiring here?  You can transparently read 
your git tree with all non git aware tools, what other meaning of 
transparency is there?

> IOW, git currently only implements the server-side use-case, but fails to 
> deliver on the client-side.  By introducing a git-client manager that 
> handles the transparency needs of a single user, it should be possible to 
> clearly isolate update semantics for both the client and the server, each 
> handling their specific use-case.

Any talk of client or server makes no sense since git does not use a 
client/server model.  If you wish to use a centralized repository, then 
git can be set up to transparently push/pull to/from said repository if 
you wish via hooks or cron jobs.

Re: git guidance

[Andreas Ericsson]

Al Boldi wrote:
> Phillip Susi wrote:
>> Al Boldi wrote:
>>> IOW, git currently only implements the server-side use-case, but fails
>>> to deliver on the client-side.  By introducing a git-client manager that
>>> handles the transparency needs of a single user, it should be possible
>>> to clearly isolate update semantics for both the client and the server,
>>> each handling their specific use-case.
>> Any talk of client or server makes no sense since git does not use a
>> client/server model.
> 
> Whether git uses the client/server model or not does not matter; what matters 
> is that there are two distinct use-cases at work here:  one on the 
> server/repository, and the other on the client.  
> 

Git is distributed. The repository is everywhere. No server is actually needed.
Many use one anyway since it can be convenient. It's not, however, necessary.

>> If you wish to use a centralized repository, then
>> git can be set up to transparently push/pull to/from said repository if
>> you wish via hooks or cron jobs.
> 
> Again, this only handles the interface to/from the server/repository, but 
> once you pulled the sources, it leaves you without Version Control on the 
> client.
> 

No, that's CVS, SVN and other centralized scm's. With git you have perfect
version control on each peer. That's the entire idea behind "fully
distributed".

> By pulling the sources into a git-client manager mounted on some dir, it 
> should be possible to let the developer work naturally/transparently in a 
> readable/writeable manner, and only require his input when reverting locally 
> or committing to the server/repository.
> 

How is that different from what every SCM, including git, is doing today? The
user needs to tell the scm when it's time to take a snapshot of the current
state. Git is distributed though, so committing is usually not the same as
publishing. Is that lack of a single command to commit and publish what's
nagging you? If it's not, I completely fail to see what you're getting at,
unless you've only ever looked at repositories without a worktree attached,
or you think that git should work like an editor's "undo" functionality,
which would be quite insane.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: git guidance

[Johannes Schindelin]

Hi,

On Fri, 7 Dec 2007, Al Boldi wrote:

> Andreas Ericsson wrote:
> > Al Boldi wrote:
> >
> > > By pulling the sources into a git-client manager mounted on some 
> > > dir, it should be possible to let the developer work 
> > > naturally/transparently in a readable/writeable manner, and only 
> > > require his input when reverting locally or committing to the 
> > > server/repository.
> >
> > How is that different from what every SCM, including git, is doing 
> > today? The user needs to tell the scm when it's time to take a 
> > snapshot of the current state. Git is distributed though, so 
> > committing is usually not the same as publishing. Is that lack of a 
> > single command to commit and publish what's nagging you? If it's not, 
> > I completely fail to see what you're getting at, unless you've only 
> > ever looked at repositories without a worktree attached, or you think 
> > that git should work like an editor's "undo" functionality, which 
> > would be quite insane.
> 
> You need to re-read the thread.

I don't know why you write that, and then say thanks.  Clearly, what you 
wrote originally, and what Andreas pointed out, were quite obvious 
indicators that git already does what you suggest.

You _do_ work "transparently" (whatever you understand by that overused 
term) in the working directory, unimpeded by git.

And whenever it is time to revert or commit, you cry for help, invoking 
git.

So either you succeeded in making yourself misunderstood, or Andreas had 
quite the obvious and correct comment for you.

Not that diffcult,
Dscho

Re: git guidance

[Phillip Susi]

Al Boldi wrote:
> When you read server, don't read it as localized; a server can be 
> distributed.  What distinguishes a server from an engine is that it has to 
> handle a multi-user use-case.  How that is implemented, locally or remotely 
> or distributed, is another issue.

And again, git handles both use cases, so what's your point?

> As explained before in this thread, replicating the git tree on the client 
> still doesn't provide the required transparency.

It has been pointed out to you that it DOES.  Either that or nobody else 
understands your nebulous use of "transparency" so maybe you should 
define it like we've been asking you.  Furthermore, the comment you 
replied to said nothing about transparency, nor did your comment it was 
in reply to; rather it was pointing out the fact that your statement 
that the git can not perform version control on the client is patently 
false.

>> How is that different from what every SCM, including git, is doing today?
>> The user needs to tell the scm when it's time to take a snapshot of the
>> current state. Git is distributed though, so committing is usually not the
>> same as publishing. Is that lack of a single command to commit and publish
>> what's nagging you? If it's not, I completely fail to see what you're
>> getting at, unless you've only ever looked at repositories without a
>> worktree attached, or you think that git should work like an editor's
>> "undo" functionality, which would be quite insane.
> 
> You need to re-read the thread.

Perhaps you should.  We have been trying to get you to explain how you 
think git isn't "transparent" while at the same time pointing out how we 
think it is.  You have failed to demonstrate any evidence to back up 
your claims, all of which have been shown to be false.

Re: git guidance

[Al Boldi]

Johannes Schindelin wrote:
> Hi,

Hi

> On Fri, 7 Dec 2007, Al Boldi wrote:
> > You need to re-read the thread.
>
> I don't know why you write that, and then say thanks.  Clearly, what you
> wrote originally, and what Andreas pointed out, were quite obvious
> indicators that git already does what you suggest.
>
> You _do_ work "transparently" (whatever you understand by that overused
> term) in the working directory, unimpeded by git.

If you go back in the thread, you may find a link to a gitfs client that 
somebody kindly posted.  This client pretty much defines the transparency 
I'm talking about.  The only problem is that it's read-only.

To make it really useful, it has to support versioning locally, disconnected 
from the server repository.  One way to implement this, could be by 
committing every update unconditionally to an on-the-fly created git 
repository private to the gitfs client.

With this transparently created private scratch repository it should then be 
possible for the same gitfs to re-expose the locally created commits, all 
without any direct user-intervention.

Later, this same scratch repository could then be managed by the normal 
git-management tools/commands to ultimately update the backend git 
repositories.

BTW:  Sorry for my previous posts that contained the wrong date; it seems 
that hibernation sometimes advances the date by a full 24h.  Has anybody 
noticed this as well?


Thanks!

--
Al

Re: git guidance

[Andreas Ericsson]

Al Boldi wrote:
> Johannes Schindelin wrote:
>> Hi,
> 
> Hi
> 
>> On Fri, 7 Dec 2007, Al Boldi wrote:
>>> You need to re-read the thread.
>> I don't know why you write that, and then say thanks.  Clearly, what you
>> wrote originally, and what Andreas pointed out, were quite obvious
>> indicators that git already does what you suggest.
>>
>> You _do_ work "transparently" (whatever you understand by that overused
>> term) in the working directory, unimpeded by git.
> 
> If you go back in the thread, you may find a link to a gitfs client that 
> somebody kindly posted.  This client pretty much defines the transparency 
> I'm talking about.  The only problem is that it's read-only.
> 
> To make it really useful, it has to support versioning locally, disconnected 
> from the server repository.  One way to implement this, could be by 
> committing every update unconditionally to an on-the-fly created git 
> repository private to the gitfs client.
> 

Earlier you said that you need to be able to tell git when you want to make
a commit, which means pretty much any old filesystem could serve as gitfs.
Now you're saying you want every single update to be committed, which would
make it mimic an editor's undo functionality. I still don't get what it is
you really want.

> With this transparently created private scratch repository it should then be 
> possible for the same gitfs to re-expose the locally created commits, all 
> without any direct user-intervention.
> 
> Later, this same scratch repository could then be managed by the normal 
> git-management tools/commands to ultimately update the backend git 
> repositories.
> 

That's exactly what's happening today. I imagine whoever wrote the gitfs
thing did so to facilitate testing, or as some form of intellectual
masturbation.


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 ###

If you could just answer that question and stop writing "transparent" or
any synonym thereof six times in each email, we can possibly help you.

As it stands now though, nobody is very interested because you haven't
explained how you want this "transparency" of yours to work in an every
day scenario.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: git guidance

[Al Boldi]

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.


Thanks!

--
Al

Re: git guidance

[Jakub Narebski]

Al Boldi <a1426z@gawab.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

Re: git guidance

[Andreas Ericsson]

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 ###
> 

So you *do* want an editor's undo function, but for an entire filesystem.
That's a handy thing to have every now and then, but it's not what git
(or any other scm) does.

> 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.
> 

One other thing that's fairly important to note is that this can never
ever handle changesets, since each write() of each file will be a commit
on its own. It's so far from what git does that I think you'd be better
off just implementing it from scratch, or looking at a versioned fs, like
Jakub suggested in his reply.

You're also neglecting one very important aspect of what an SCM provides
if you go down this road, namely project history. You basically have two
choices with this "implicit save on each edit":
* force the user to supply a commit message for each and every edit
* ignore commit messages altogether

Obviously, forcing a commit message each time is the only way to get some
sort of proper history to look at after it's done, but it's also such an
appalling nuisance that I doubt *anyone* will actually like that, and since
changesets aren't supported, you'll have "implement xniz api, commit 1 of X"
messages. Cumbersome, stupid, and not very useful.

Ignoring commit messages altogether means you ignore the entire history,
and the SCM then becomes a filesystem-wide "undo" cache. This could
ofcourse work, but it's something akin to building a nuclear powerplant
to power a single lightbulb.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: git guidance

[Al Boldi]

Phillip Susi wrote:
> Al Boldi wrote:
> > IOW, git currently only implements the server-side use-case, but fails
> > to deliver on the client-side.  By introducing a git-client manager that
> > handles the transparency needs of a single user, it should be possible
> > to clearly isolate update semantics for both the client and the server,
> > each handling their specific use-case.
>
> Any talk of client or server makes no sense since git does not use a
> client/server model.

Whether git uses the client/server model or not does not matter; what matters 
is that there are two distinct use-cases at work here:  one on the 
server/repository, and the other on the client.  

> If you wish to use a centralized repository, then
> git can be set up to transparently push/pull to/from said repository if
> you wish via hooks or cron jobs.

Again, this only handles the interface to/from the server/repository, but 
once you pulled the sources, it leaves you without Version Control on the 
client.

By pulling the sources into a git-client manager mounted on some dir, it 
should be possible to let the developer work naturally/transparently in a 
readable/writeable manner, and only require his input when reverting locally 
or committing to the server/repository.


Thanks!

--
Al

Re: git guidance

[Al Boldi]

Andreas Ericsson wrote:
> Al Boldi wrote:
> > Phillip Susi wrote:
> >> Al Boldi wrote:
> >>> IOW, git currently only implements the server-side use-case, but fails
> >>> to deliver on the client-side.  By introducing a git-client manager
> >>> that handles the transparency needs of a single user, it should be
> >>> possible to clearly isolate update semantics for both the client and
> >>> the server, each handling their specific use-case.
> >>
> >> Any talk of client or server makes no sense since git does not use a
> >> client/server model.
> >
> > Whether git uses the client/server model or not does not matter; what
> > matters is that there are two distinct use-cases at work here:  one on
> > the server/repository, and the other on the client.
>
> Git is distributed. The repository is everywhere. No server is actually
> needed. Many use one anyway since it can be convenient. It's not, however,
> necessary.

When you read server, don't read it as localized; a server can be 
distributed.  What distinguishes a server from an engine is that it has to 
handle a multi-user use-case.  How that is implemented, locally or remotely 
or distributed, is another issue.

> >> If you wish to use a centralized repository, then
> >> git can be set up to transparently push/pull to/from said repository if
> >> you wish via hooks or cron jobs.
> >
> > Again, this only handles the interface to/from the server/repository,
> > but once you pulled the sources, it leaves you without Version Control
> > on the client.
>
> No, that's CVS, SVN and other centralized scm's. With git you have perfect
> version control on each peer. That's the entire idea behind "fully
> distributed".

As explained before in this thread, replicating the git tree on the client 
still doesn't provide the required transparency.

> > By pulling the sources into a git-client manager mounted on some dir, it
> > should be possible to let the developer work naturally/transparently in
> > a readable/writeable manner, and only require his input when reverting
> > locally or committing to the server/repository.
>
> How is that different from what every SCM, including git, is doing today?
> The user needs to tell the scm when it's time to take a snapshot of the
> current state. Git is distributed though, so committing is usually not the
> same as publishing. Is that lack of a single command to commit and publish
> what's nagging you? If it's not, I completely fail to see what you're
> getting at, unless you've only ever looked at repositories without a
> worktree attached, or you think that git should work like an editor's
> "undo" functionality, which would be quite insane.

You need to re-read the thread.


Thanks!

--
Al

Re: git guidance

[Al Boldi]

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

Re: git guidance

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 505 bytes --]

On Fri, 07 Dec 2007 22:04:48 +0300, Al Boldi said:

> 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?

Imagine the number of commits a 'make clean; make' will do in a kernel tree, as
it commits all those .o files... :)


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: git guidance

[david]

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

Re: git guidance

[Björn Steinbrink]

[-- Attachment #1: Type: text/plain, Size: 3930 bytes --]

On 2007.12.07 13:53:11 +0300, 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.

Ouch... That looks worse than "plain" per-file versioning. Not only do
you per definition get "broken" commits if there's a change that affects
two dependent files, you also get an insane amount of commits just for
testing stuff, or fixing bugs.

And unless you use some kind of union-fs on top (or keep ignored files
in special unversioned area in your gitfs, which seems somewhat ugly),
you'll probably also have to track lots of files in the working
directory that are generated, unless you want to re-generate them after
each reboot. And that leads to even more absolutely useless revisions.

Just thinking of my vim .swp files (which I definitely don't want to
loose on a crash/power outtage/pkill -9 .<ENTER> dammit) makes me scream
because of the gazillion of commits they will produce (and no, I don't
want them in some special out of tree directory).

Plus, I have vim setup to _replace_ files on write, so that I can more
easily use hard-linked copies with changing all copies at once _unless_
I explicitly want to, meaning that I'd get full remove/add commits,
which are absolutely useless. And trying to detect such patterns
(rename, then write the changed file with the old name and then delete
the renamed file) is probably not worth the trouble, because you
coincidently might _want_ to have just these three steps recorded when
you happen to perform them manually. And if you go for heuristics,
you'll complain each time you get a false-positive/negative.


That said, out of pure curiousness I came up with the attached script
which just uses inotifywait to watch a directory and issue git commands
on certain events. It is extremely stupid, but seems to work. And at
least it hasn't got the drawbacks of a real gitfs regarding the need to
have a "separate" non-versioned storage area for the working directory,
because it simply uses the existing working directory wherever that
might be stored. It doesn't use GIT_DIR/WORK_DIR yet, but hey, should be
easy to add...

Feel free to mess with that thing, hey, maybe you even like it and
extend it to match your proposed workflow even more. I for sure won't
use or even extend it, so you're likely on your own there.

Side-note: Writing that script probably took less time than writing this
email and probably less time than was wasted on this topic. Makes me
want to use today's preferred "Code talks, b...s... walks" statement,
but I'll refrain from that... Just because I lack the credibility to say
that, and the script attached is quite crappy ;-)

Björn

[-- Attachment #2: git-watch --]
[-- Type: text/plain, Size: 814 bytes --]

#!/bin/bash
inotifywait -m -r --exclude ^\./\.git/.* -e close_write -e move -e create -e delete . 2>/dev/null |
while read FILE_PATH EVENT FILE_NAME
do
	FILE_NAME="$FILE_PATH$FILE_NAME"
	FILE_NAME=${FILE_NAME#./}

	# git doesn't care about directories
	if [ -d "$FILE_NAME" ]
	then
		continue
	fi

	case "$EVENT" in
		*CLOSE_WRITE*)
		ACTION=change
		;;
		*MOVED_TO*)
		ACTION=create
		;;
		*MODIFY*)
		ACTION=change
		;;
		*DELETE*)
		ACTION=delete
		;;
		*MOVED_FROM*)
		ACTION=delete
		;;
		*CREATE*)
		ACTION=create
		;;
		*)
		continue
		;;
	esac

	case $ACTION in
		create)
		git add "$FILE_NAME"
		git commit -m "$FILE_NAME created"
		;;
		delete)
		git rm --cached "$FILE_NAME"
		git commit -m "$FILE_NAME removed"
		;;
		change)
		git add "$FILE_NAME"
		git commit -m "$FILE_NAME changed"
		;;
	esac
done

Re: git guidance

[Luke Lu]

On Dec 7, 2007, at 11:36 AM, Valdis.Kletnieks@vt.edu wrote:
> On Fri, 07 Dec 2007 22:04:48 +0300, Al Boldi said:
>
>> 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?
>
> Imagine the number of commits a 'make clean; make' will do in a  
> kernel tree, as
> it commits all those .o files... :)

My guess is that Al is not really a developer (product management/ 
marketing?), what he has in mind is probably not an SCM but a backup  
system a la Mac's time machine or Netapp's snapshots that also  
support disconnected commits. I think that git could be a suitable  
engine for such systems, after a few tweaks to avoid compressing  
already compressed blobs like jpeg, mp3 and mpeg etc.

__Luke

Re: git guidance

[Al Boldi]

Valdis.Kletnieks@vt.edu wrote:
> On Fri, 07 Dec 2007 22:04:48 +0300, Al Boldi said:
> > 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?
>
> Imagine the number of commits a 'make clean; make' will do in a kernel
> tree, as it commits all those .o files... :)

.o files???

It probably goes without saying, that gitfs should have some basic 
configuration file to setup its transparent behaviour, and which would most 
probably contain an include / exclude file-filter mask, and probably other 
basic configuration options.  But this is really secondary to the 
implementation, and the question remains whether git is efficient enough.

IOW, how big is the git commit overhead as compared to a normal copy?


Thanks!

--
Al

Re: git guidance

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 621 bytes --]

On Sat, 08 Dec 2007 07:56:21 +0300, Al Boldi said:

> It probably goes without saying, that gitfs should have some basic 
> configuration file to setup its transparent behaviour

But then it's not *truly* transparent, is it?

And that leaves another question - if you make a config file that excludes
all the .o files - then what's backing the .o files?  Those data blocks need
to be *someplace*.  Maybe you can do something ugly like use unionfs to
combine your gitfs with something else to store the other files...

But at that point, you're probably better off just creating a properly
designed versioning filesystem.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: git guidance

[Martin Langhoff]

On Dec 1, 2007 7:50 PM, Al Boldi <a1426z@gawab.com> wrote:
> Not sure what you mean by operationally transparent?  It would be transparent
> for the updating client,  and the rest of the git-users would need to wait
> for the commit from the updating client; which is ok, as this transparency
> is not meant to change the server-side git-update semantic.

I guess what he means is that when your write to the file -- from your
editor -- it can't be considered a commit. During an editing session
you might write a dozen times, only to commit it once you are happy
(that it compiles, passes tests, etc).

> Sure, you wouldn't want to change the git-engine update semantics, as that
> sits on the server and handles all users.  But what the git model is
> currently missing is a client manager.  Right now, this is being worked
> around by replicating the git tree on the client, which still doesn't
> provide the required transparency.

If you want a dumb-ish client CVS-style, you can try git-cvsserver.
But the git model is definitely superior -- "replicating the tree on
the client" is not a workaround but a central strategy.

Have you used git and other DSCMs much? From your writing, it sounds
like you may have misunderstood how some of the principles of git work
out in practice.

cheers,


m

Re: git guidance

[Al Boldi]

Valdis.Kletnieks@vt.edu wrote:
> On Sat, 08 Dec 2007 07:56:21 +0300, Al Boldi said:
> > It probably goes without saying, that gitfs should have some basic
> > configuration file to setup its transparent behaviour
>
> But then it's not *truly* transparent, is it?

Don't mistake transparency with some form of auto-heuristic.  Transparency 
only means that it inserts functionality without impeding your normal 
workflow.

> And that leaves another question - if you make a config file that excludes
> all the .o files - then what's backing the .o files?  Those data blocks
> need to be *someplace*.  Maybe you can do something ugly like use unionfs
> to combine your gitfs with something else to store the other files...

Or any number of other possible implementation scenarios...

> But at that point, you're probably better off just creating a properly
> designed versioning filesystem.

But gitfs is not about designing a versioning filesystem, it's about 
designing a transparent interface into git to handle an SCM use-case.


Thanks!

--
Al

Re: git guidance

[Johannes Schindelin]

Hi,

On Fri, 7 Dec 2007, Al Boldi wrote:

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

The question is not if git is efficient enough to handle workflow C, but 
if that worflow is efficient enough to help anybody.

Guess what takes me the longest time when committing?  The commit message.  
But it is really helpful, so there is a _point_ in writing one, and there 
is a _point_ in committing when I do it: it is a point in time where I 
expect the tree to be in a good shape, to be compilable, and to solve a 
specific problem which I describe in the commit message.

So I absolutely hate this "transparency".  Git _is_ transparent; it does 
not affect any of my other tools; they still work very well 
thankyouverymuch.

What your version of "transparency" would do: destroy bisectability, make 
an absolute gibberish of the history, and more!

Nobody could read the output of "git log" and form an understanding what 
was done.  Nobody could read the commit message for a certain "git blame"d 
line that she tries to make sense of.

IOW you would revert the whole meaning of the term Source Code Management.

Hth,
Dscho

Re: git guidance

[Haavard Skinnemoen]

On Thu, 29 Nov 2007 13:45:44 +0100
Tilman Schmidt <tilman@imap.cc> wrote:

> Haavard Skinnemoen schrieb:
> > 
> > No, use "git rebase --interactive" ;-)  
> 
> What's that? I can't find it in "man git-rebase".

I think it was added very recently; most distributions probably don't
have a recent enough version. git 1.5.3.4 includes "git rebase
--interactive", and you can read about it here.

http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html

Haavard

Re: git guidance

[Kyle Moffett]

On Nov 29, 2007, at 00:27:04, Al Boldi wrote:
> Jakub Narebski wrote:
>> Besides, you can always use "git show <revision>:<file>". For  
>> example gitweb (and I think other web interfaces) can show any  
>> version of a file or a directory, accessing only repository.
>
> Sure, browsing is the easy part, but Version Control starts when  
> things become writable.

But... git history is very inherently completely immutable once  
created... that's the only way you can index everything with a simple  
SHA-1.  If you want to write to the "git filesystem" by adding new  
commits then you need to use the appropriate commands, same as every  
other VCS on the planet.

Cheers,
Kyle Moffett

Re: git guidance

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 578 bytes --]

Arkadiusz Miskiewicz schrieb:
> You should watch this one http://youtube.com/watch?v=8dhZ9BXQgc4 . It's better 
> 8-)

Thanks for that. It really cleared up a lot of things.

Now if I could get all that information in a less awkward form,
for example a nice text document I can read at leisure instead
of having to sit through a one hour videostream, that would be
nice.

-- 
Tilman Schmidt                    E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: git guidance

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 325 bytes --]

Haavard Skinnemoen schrieb:
> 
> No, use "git rebase --interactive" ;-)

What's that? I can't find it in "man git-rebase".

-- 
Tilman Schmidt                    E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: git guidance

[Al Boldi]

Jakub Narebski wrote:
> Al Boldi wrote:
> > Johannes Schindelin wrote:
> >> By that definition, no SCM, not even CVS, is transparent.  Nothing
> >> short of unpacked directories of all versions (wasting a lot of disk
> >> space) would.
> >
> > Who said anything about unpacking?
> >
> > I'm talking about GIT transparently serving a Virtual Version Control
> > dir to be mounted on the client.
>
> Are you talking about something like (in alpha IIRC) gitfs?
>
>   http://www.sfgoth.com/~mitch/linux/gitfs/

This looks like a good start.

> Besides, you can always use "git show <revision>:<file>". For example
> gitweb (and I think other web interfaces) can show any version of a file
> or a directory, accessing only repository.

Sure, browsing is the easy part, but Version Control starts when things 
become writable.


Thanks for the link!

--
Al

Re: git guidance

[Haavard Skinnemoen]

On Wed, 28 Nov 2007 00:20:46 +0100 (CET)
Jan Engelhardt <jengelh@computergmbh.de> wrote:

> On Nov 27 2007 23:33, Tilman Schmidt wrote:
> >
> >It didn't work too well. The first result was one of maximal
> >embarrassment: I produced a patch that didn't even compile when
> >applied to the official tree. This shouldn't happen with git, right?
> >Well, it did. So now I'm back to keeping a virgin kernel source tree
> >alongside my development area in order to produce diffs. That can't
> >be right?
> >  
> No, it can't. Use stgit/quilt ;p

No, use "git rebase --interactive" ;-)

I've tried stgit/guilt/quilt as well, but I could never quite get the
hang of it (adding the files _before_ editing is the difficult part.) On
the other hand, git rebase --interactive fit right into my workflow and
improved it massively.

But I guess it's all a matter of personal preference.

Haavard

Re: git guidance

[Willy Tarreau]

On Wed, Nov 28, 2007 at 02:38:02PM +0100, Tilman Schmidt wrote:
> Willy,
> 
> thanks for your kind answer.
> 
> Am Mi 28 Nov 2007 00:52:38 +0100, Willy Tarreau schrieb:
> > Tilman, there was a howto by Jeff Garzik I believe.
> 
> Yes, I started from that and it's fine as far as it goes. The
> "Everyday GIT With 20 Commands Or So" document was quite helpful
> too, especially the section "Individual Developer (Participant)".
> But they don't quite cover my workflow yet.
> 
> > The tutorials
> > on the GIT site are quite good too. You must read them entirely and
> > proceed with the examples as you read them. Believe me, it helps you
> > understand a lot of things, specially about the split in 3 parts
> > (objects, cache, and working dir).
> 
> I think I got that part. My questions concern practical things
> like when to make a new branch, how to resubmit a patch following
> post-commit changes, what to do when "git format-patch" doesn't
> produce the desired result

I don't see how it can fail, I use it a lot (I would say exclusively)
to move patch between branches and never had a problem with it.

> or when "git pull" obstinately declares "Already up-to-date" even
> though I know that isn't true,

As frustrating as it can be, git is true. It is possible that you
have already merged the branch at an earlier step and that there
is nothing new to be merged. I really think that there is a little
thing wrong in your workflow that you need to find out to solve
your problems.

> how to
> track a patch after submission to LKML to see when or whether it
> appears in the main tree, or how to scrub the history to stop
> "git log origin..HEAD" from listing (and "git format-patch" from
> formatting) long-merged changes as new. Well, I'll take that up on
> the git@vger.kernel.org list then, as proposed by J. Bruce Fields,
> in order not to annoy LKML readers any longer.

Yes, at this stage it's more a GIT-specific topic.

> > Anyway, don't get demotivated about the tool or the workflow. If
> > you find it inconvenient to use, you're doing something wrong and
> > you don't know it.
> 
> That's what I'm thinking. What I'm trying to do can't be that
> different from what all those happy git users are doing. I guess
> if I could just watch an experienced git user at work for a day
> most of my problems would vanish.

That's probably true. When I started, I whined about it because I
didn't understand it (nor the workflow). Marcello took the time
to explain me how he proceeded and from that point I started to
understand my mistakes and to become more and more a happy user.

Try to be descriptive about the things you do that don't work and
that you don't understand why, and post that to the GIT ML. I'm
sure someone there will be able to wipe out all your problems.

Regards,
Willy

Re: git guidance

[Dave Quigley]

On Wed, 2007-11-28 at 20:10 +0100, willem wrote:
> Dave Quigley wrote:
> > On Wed, 2007-11-28 at 16:57 +0100, Tilman Schmidt wrote:
> >   
> >> Dave Quigley schrieb:
> >>     
> >>> There is a project listed on the kernel.org git page called guilt. I
> >>> find it very useful. It is much more responsive than stgit and it
> >>> actually has a git backend which quilt does not.
> >>>
> >>> On Wed, 2007-11-28 at 00:20 +0100, Jan Engelhardt wrote:
> >>>       
> >>>> On Nov 27 2007 23:33, Tilman Schmidt wrote:
> >>>>         
> >>>>> Well, it did. So now I'm back to keeping a virgin kernel source tree
> >>>>> alongside my development area in order to produce diffs. That can't
> >>>>> be right?
> >>>>>
> >>>>>           
> >>>> No, it can't. Use stgit/quilt ;p
> >>>>         
> >> In which respect would stgit/quilt/guilt help me? At first glance
> >> they just seem to add another level of complexity.
> >>
> >> Thanks,
> >> Tilman
> >>
> >>     
> >
> > These tools allow you to maintain a set of patches with very little
> > effort. More importantly it removes a lot of the git specifics from your
> > development process. For example this is how I use guilt for a new patch
> > set.
> >
> > I take my fresh tree and do a guilt-init in the base. This will create a
> > new patch series. I then need to create a patch to modify something LSM
> > related (guilt-new <patch_name>). Things like stgit/quilt/git use the
> > idea of a stack of patches. At this point if you were to type
> > guilt-series you would only see the one patch we just created. This
> > patch is going to be one logical set of changes (it should also produce
> > a compilable and working kernel). You can make whatever modifications
> > you need to make to your files and at this point you need to do one of
> > two things. If they were already in the tree you just type guilt-refresh
> > and under your .git/patches/<branch_name> directory you will see a file
> > named <patch_name> which contains your patch. Otherwise you need to do a
> > guilt-add <file_name> and then a guilt-refresh. The idea here is that
> > you have a moved your workflow from managing a series of commits and
> > then breaking out patches from a final version to one where you think in
> > terms of the patches and make modifications to them instead. In my
> > example I said I was doing something LSM related. Lets say the first
> > patch added a new hook and its implementation in the various modules. We
> > can now add a second patch using the guilt-new command and this one will
> > add uses of that new hook. At this point we have a stack that looks like
> > this.
> >
> > <patch that adds users>
> > <patch that adds hook>
> >
> > I can pop and push patches onto this stack to have a version of my
> > kernel tree at any state within the patch set. At this point lets say we
> > have posted the patch set and have feedback. I need to apply this
> > feedback to the patch that adds the LSM hook. Since my top patch
> > (guilt-top) is currently at the one that adds the users of the hook I
> > need to pop off that patch and get to the one that creates the hook
> > (guilt-pop). After doing this I'm at a kernel tree state which just has
> > the changes which add the hook. I make my modifications, type
> > guilt-refresh to create a new patch and then guilt-push my second patch
> > on and make sure everything is still working.
> >
> > As you can see there is almost no git knowledge required to use this
> > system and it allows you to focus on development instead of the
> > versioning system. One useful feature is that when Linus adds new
> > patches and I want to rebase my set against the current tree It only
> > takes 3 commands to rebase the patch set (Assuming all goes well).
> >
> > guilt-push -a #push all patches onto the stack
> > git-fetch #pull down the index
> > guilt-rebase FETCH_HEAD #Rebase our patches should do a merge and
> > #reapply all patches
> >
> > These are just some basics about guilt. Jeff has written a better
> > tutorial with a sample repository for you to work with if your
> > interested. I don't know if this will help your development process but
> > I can tell you from experience breaking patches by hand was a pain in
> > the ass and a huge waste of time and I'm glad to have a tool like this
> >   
> Where can I find that tutorial ?
> 
> regards
> > now.
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> >
> >   

Hmm actually the tutorial in the docs is somewhat minimal. However you
can find it in the Documentation/HOWTO file under the guilt tree once
you clone it. Maybe I can write a better one some day not on work time
though :)

Re: git guidance

[willem]

Dave Quigley wrote:
> On Wed, 2007-11-28 at 16:57 +0100, Tilman Schmidt wrote:
>   
>> Dave Quigley schrieb:
>>     
>>> There is a project listed on the kernel.org git page called guilt. I
>>> find it very useful. It is much more responsive than stgit and it
>>> actually has a git backend which quilt does not.
>>>
>>> On Wed, 2007-11-28 at 00:20 +0100, Jan Engelhardt wrote:
>>>       
>>>> On Nov 27 2007 23:33, Tilman Schmidt wrote:
>>>>         
>>>>> Well, it did. So now I'm back to keeping a virgin kernel source tree
>>>>> alongside my development area in order to produce diffs. That can't
>>>>> be right?
>>>>>
>>>>>           
>>>> No, it can't. Use stgit/quilt ;p
>>>>         
>> In which respect would stgit/quilt/guilt help me? At first glance
>> they just seem to add another level of complexity.
>>
>> Thanks,
>> Tilman
>>
>>     
>
> These tools allow you to maintain a set of patches with very little
> effort. More importantly it removes a lot of the git specifics from your
> development process. For example this is how I use guilt for a new patch
> set.
>
> I take my fresh tree and do a guilt-init in the base. This will create a
> new patch series. I then need to create a patch to modify something LSM
> related (guilt-new <patch_name>). Things like stgit/quilt/git use the
> idea of a stack of patches. At this point if you were to type
> guilt-series you would only see the one patch we just created. This
> patch is going to be one logical set of changes (it should also produce
> a compilable and working kernel). You can make whatever modifications
> you need to make to your files and at this point you need to do one of
> two things. If they were already in the tree you just type guilt-refresh
> and under your .git/patches/<branch_name> directory you will see a file
> named <patch_name> which contains your patch. Otherwise you need to do a
> guilt-add <file_name> and then a guilt-refresh. The idea here is that
> you have a moved your workflow from managing a series of commits and
> then breaking out patches from a final version to one where you think in
> terms of the patches and make modifications to them instead. In my
> example I said I was doing something LSM related. Lets say the first
> patch added a new hook and its implementation in the various modules. We
> can now add a second patch using the guilt-new command and this one will
> add uses of that new hook. At this point we have a stack that looks like
> this.
>
> <patch that adds users>
> <patch that adds hook>
>
> I can pop and push patches onto this stack to have a version of my
> kernel tree at any state within the patch set. At this point lets say we
> have posted the patch set and have feedback. I need to apply this
> feedback to the patch that adds the LSM hook. Since my top patch
> (guilt-top) is currently at the one that adds the users of the hook I
> need to pop off that patch and get to the one that creates the hook
> (guilt-pop). After doing this I'm at a kernel tree state which just has
> the changes which add the hook. I make my modifications, type
> guilt-refresh to create a new patch and then guilt-push my second patch
> on and make sure everything is still working.
>
> As you can see there is almost no git knowledge required to use this
> system and it allows you to focus on development instead of the
> versioning system. One useful feature is that when Linus adds new
> patches and I want to rebase my set against the current tree It only
> takes 3 commands to rebase the patch set (Assuming all goes well).
>
> guilt-push -a #push all patches onto the stack
> git-fetch #pull down the index
> guilt-rebase FETCH_HEAD #Rebase our patches should do a merge and
> #reapply all patches
>
> These are just some basics about guilt. Jeff has written a better
> tutorial with a sample repository for you to work with if your
> interested. I don't know if this will help your development process but
> I can tell you from experience breaking patches by hand was a pain in
> the ass and a huge waste of time and I'm glad to have a tool like this
>   
Where can I find that tutorial ?

regards
> now.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>   

Re: git guidance

[Jakub Narebski]

Al Boldi wrote:
> Johannes Schindelin wrote:

>> By that definition, no SCM, not even CVS, is transparent.  Nothing short
>> of unpacked directories of all versions (wasting a lot of disk space)
>> would.
> 
> Who said anything about unpacking?
> 
> I'm talking about GIT transparently serving a Virtual Version Control dir to 
> be mounted on the client.

Are you talking about something like (in alpha IIRC) gitfs?

  http://www.sfgoth.com/~mitch/linux/gitfs/


Besides, you can always use "git show <revision>:<file>". For example
gitweb (and I think other web interfaces) can show any version of a file
or a directory, accessing only repository.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: git guidance

[Al Boldi]

Johannes Schindelin wrote:
> By that definition, no SCM, not even CVS, is transparent.  Nothing short
> of unpacked directories of all versions (wasting a lot of disk space)
> would.

Who said anything about unpacking?

I'm talking about GIT transparently serving a Virtual Version Control dir to 
be mounted on the client.


Thanks!

--
Al

Re: git guidance

[Johannes Schindelin]

Hi,

On Wed, 28 Nov 2007, Al Boldi wrote:

> git@vger sometimes bounces, so let's leave lkml as backup.

Fair enough.

> Johannes Schindelin wrote:
> > On Wed, 28 Nov 2007, Rogan Dawes wrote:
> > > Al Boldi wrote:
> > > > Willy Tarreau wrote:
> > > > > It should not turn into an endless thread led by people who want 
> > > > > to redefine GIT's roadmap, but experience sharing helps a lot 
> > > > > with GIT.
> > > >
> > > > Well, now that you mentioned it, if there is one thing I dislike, 
> > > > it's for version control to start mutilating your sources.  
> > > > Version Control should be completely transparent.  GIT isn't.
> > >
> > > Care to explain? Git is quite happy handling arbitrary binary 
> > > content, so I find it difficult to believe that it is changing your 
> > > source code in strange ways.
> >
> > It is nice of you to ask him to explain: Unless this handwaving claim 
> > is substantiated, it is quite hard to argue with.
> 
> Sure, the problem with GIT is that it stores the sources inside a 
> backend container that is only accessible via GIT; iow, you can't 
> retrieve your sources directly / transparently.

That is a very funny way to define a "transparent SCM".  Are you 
complaining about SQL servers being "not transparent"?

By that definition, no SCM, not even CVS, is transparent.  Nothing short 
of unpacked directories of all versions (wasting a lot of disk space) 
would.

IOW the issue you raised is a non-issue.

Ciao,
Dscho

Re: git guidance

[Al Boldi]

Johannes Schindelin wrote:
> Hi,

Hi!

git@vger sometimes bounces, so let's leave lkml as backup.

> On Wed, 28 Nov 2007, Rogan Dawes wrote:
> > Al Boldi wrote:
> > > Willy Tarreau wrote:
> > > > It should not turn into an endless thread led by people who want to
> > > > redefine GIT's roadmap, but experience sharing helps a lot with GIT.
> > >
> > > Well, now that you mentioned it, if there is one thing I dislike, it's
> > > for version control to start mutilating your sources.  Version Control
> > > should be completely transparent.  GIT isn't.
> >
> > Care to explain? Git is quite happy handling arbitrary binary content,
> > so I find it difficult to believe that it is changing your source code
> > in strange ways.
>
> It is nice of you to ask him to explain: Unless this handwaving claim is
> substantiated, it is quite hard to argue with.

Sure, the problem with GIT is that it stores the sources inside a backend 
container that is only accessible via GIT; iow, you can't retrieve your 
sources directly / transparently.

One way to achieve transparency could be to allow mounting GIT on a dir-mount 
point.  And just use that dir normally, while GIT manages all the rest in 
the background.


Thanks!

--
Al

Re: git guidance

[Dave Quigley]

On Wed, 2007-11-28 at 16:57 +0100, Tilman Schmidt wrote:
> Dave Quigley schrieb:
> > There is a project listed on the kernel.org git page called guilt. I
> > find it very useful. It is much more responsive than stgit and it
> > actually has a git backend which quilt does not.
> > 
> > On Wed, 2007-11-28 at 00:20 +0100, Jan Engelhardt wrote:
> >> On Nov 27 2007 23:33, Tilman Schmidt wrote:
> >> >
> >> >Well, it did. So now I'm back to keeping a virgin kernel source tree
> >> >alongside my development area in order to produce diffs. That can't
> >> >be right?
> >> >
> >> No, it can't. Use stgit/quilt ;p
> 
> In which respect would stgit/quilt/guilt help me? At first glance
> they just seem to add another level of complexity.
> 
> Thanks,
> Tilman
> 

These tools allow you to maintain a set of patches with very little
effort. More importantly it removes a lot of the git specifics from your
development process. For example this is how I use guilt for a new patch
set.

I take my fresh tree and do a guilt-init in the base. This will create a
new patch series. I then need to create a patch to modify something LSM
related (guilt-new <patch_name>). Things like stgit/quilt/git use the
idea of a stack of patches. At this point if you were to type
guilt-series you would only see the one patch we just created. This
patch is going to be one logical set of changes (it should also produce
a compilable and working kernel). You can make whatever modifications
you need to make to your files and at this point you need to do one of
two things. If they were already in the tree you just type guilt-refresh
and under your .git/patches/<branch_name> directory you will see a file
named <patch_name> which contains your patch. Otherwise you need to do a
guilt-add <file_name> and then a guilt-refresh. The idea here is that
you have a moved your workflow from managing a series of commits and
then breaking out patches from a final version to one where you think in
terms of the patches and make modifications to them instead. In my
example I said I was doing something LSM related. Lets say the first
patch added a new hook and its implementation in the various modules. We
can now add a second patch using the guilt-new command and this one will
add uses of that new hook. At this point we have a stack that looks like
this.

<patch that adds users>
<patch that adds hook>

I can pop and push patches onto this stack to have a version of my
kernel tree at any state within the patch set. At this point lets say we
have posted the patch set and have feedback. I need to apply this
feedback to the patch that adds the LSM hook. Since my top patch
(guilt-top) is currently at the one that adds the users of the hook I
need to pop off that patch and get to the one that creates the hook
(guilt-pop). After doing this I'm at a kernel tree state which just has
the changes which add the hook. I make my modifications, type
guilt-refresh to create a new patch and then guilt-push my second patch
on and make sure everything is still working.

As you can see there is almost no git knowledge required to use this
system and it allows you to focus on development instead of the
versioning system. One useful feature is that when Linus adds new
patches and I want to rebase my set against the current tree It only
takes 3 commands to rebase the patch set (Assuming all goes well).

guilt-push -a #push all patches onto the stack
git-fetch #pull down the index
guilt-rebase FETCH_HEAD #Rebase our patches should do a merge and
#reapply all patches

These are just some basics about guilt. Jeff has written a better
tutorial with a sample repository for you to work with if your
interested. I don't know if this will help your development process but
I can tell you from experience breaking patches by hand was a pain in
the ass and a huge waste of time and I'm glad to have a tool like this
now.

Re: git guidance

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 791 bytes --]

Dave Quigley schrieb:
> There is a project listed on the kernel.org git page called guilt. I
> find it very useful. It is much more responsive than stgit and it
> actually has a git backend which quilt does not.
> 
> On Wed, 2007-11-28 at 00:20 +0100, Jan Engelhardt wrote:
>> On Nov 27 2007 23:33, Tilman Schmidt wrote:
>> >
>> >Well, it did. So now I'm back to keeping a virgin kernel source tree
>> >alongside my development area in order to produce diffs. That can't
>> >be right?
>> >
>> No, it can't. Use stgit/quilt ;p

In which respect would stgit/quilt/guilt help me? At first glance
they just seem to add another level of complexity.

Thanks,
Tilman

-- 
Tilman Schmidt                    E-Mail: tilman@imap.cc
Bonn, Germany
Yes, I have searched Google!


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: git guidance

[Dave Quigley]

There is a project listed on the kernel.org git page called guilt. I
find it very useful. It is much more responsive than stgit and it
actually has a git backend which quilt does not.

git-clone git://git.kernel.org/pub/scm/linux/kernel/git/jsipek/guilt.git

There is a tutorial associated with guilt which explains the commands
pretty well. The only thing that I find a problem with guilt is
sometimes I forget to pop/push the patches to the right place before
editing them. Actually that is less of a problem with guilt and more of
a problem with me :) Two of the main features that I find very useful
since I track the head of Linus's tree are guilt-rebase and then
guilt-patchbomb for sending patches.

On Wed, 2007-11-28 at 00:20 +0100, Jan Engelhardt wrote:
> On Nov 27 2007 23:33, Tilman Schmidt wrote:
> >
> >It didn't work too well. The first result was one of maximal
> >embarrassment: I produced a patch that didn't even compile when
> >applied to the official tree. This shouldn't happen with git, right?
> >Well, it did. So now I'm back to keeping a virgin kernel source tree
> >alongside my development area in order to produce diffs. That can't
> >be right?
> >
> No, it can't. Use stgit/quilt ;p
> 
> >Does somebody have a step by step tutorial for doing the standard
> >"edit - test - modify - retest - submit - edit - resubmit" sequence
> >with GIT? Is there a GIT newsgroup or mailinglist? Or should I just
> >post my silly questions to LKML?
> >
> http://www.linuxworld.com/video/?bcpid=1138309735&bclid=1213841149&bctid=1221911905
> 
> James Bottomley's intro helps a lot.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: git guidance

[Rogan Dawes]

Al Boldi wrote:
> Willy Tarreau wrote:
>> It should not turn into an endless thread led by people who want to
>> redefine GIT's roadmap, but experience sharing helps a lot with GIT.
> 
> Well, now that you mentioned it, if there is one thing I dislike, it's for 
> version control to start mutilating your sources.  Version Control should be 
> completely transparent.  GIT isn't.
> 
> Thanks!
> 
> --
> Al
> 

Care to explain? Git is quite happy handling arbitrary binary content, 
so I find it difficult to believe that it is changing your source code 
in strange ways.

Rogan

Re: git guidance

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 1899 bytes --]

Willy,

thanks for your kind answer.

Am Mi 28 Nov 2007 00:52:38 +0100, Willy Tarreau schrieb:
> Tilman, there was a howto by Jeff Garzik I believe.

Yes, I started from that and it's fine as far as it goes. The
"Everyday GIT With 20 Commands Or So" document was quite helpful
too, especially the section "Individual Developer (Participant)".
But they don't quite cover my workflow yet.

> The tutorials
> on the GIT site are quite good too. You must read them entirely and
> proceed with the examples as you read them. Believe me, it helps you
> understand a lot of things, specially about the split in 3 parts
> (objects, cache, and working dir).

I think I got that part. My questions concern practical things
like when to make a new branch, how to resubmit a patch following
post-commit changes, what to do when "git format-patch" doesn't
produce the desired result or when "git pull" obstinately declares
"Already up-to-date" even though I know that isn't true, how to
track a patch after submission to LKML to see when or whether it
appears in the main tree, or how to scrub the history to stop
"git log origin..HEAD" from listing (and "git format-patch" from
formatting) long-merged changes as new. Well, I'll take that up on
the git@vger.kernel.org list then, as proposed by J. Bruce Fields,
in order not to annoy LKML readers any longer.

> Anyway, don't get demotivated about the tool or the workflow. If
> you find it inconvenient to use, you're doing something wrong and
> you don't know it.

That's what I'm thinking. What I'm trying to do can't be that
different from what all those happy git users are doing. I guess
if I could just watch an experienced git user at work for a day
most of my problems would vanish.

Thanks,
Tilman

-- 
Tilman Schmidt                    E-Mail: tilman@imap.cc
Bonn, Germany
Yes, I have searched Google!


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: git guidance

[Al Boldi]

Willy Tarreau wrote:
> It should not turn into an endless thread led by people who want to
> redefine GIT's roadmap, but experience sharing helps a lot with GIT.

Well, now that you mentioned it, if there is one thing I dislike, it's for 
version control to start mutilating your sources.  Version Control should be 
completely transparent.  GIT isn't.


Thanks!

--
Al

Re: git guidance

[Kristoffer Ericson]

On Wed, 28 Nov 2007 12:23:48 +0100
Tilman Schmidt <tilman@imap.cc> wrote:

> Kristoffer Ericson schrieb:
> > Google is your friend.
> 
> Sigh.
> 
> In case you didn't guess, I *have* of course searched Google,
> and not just that. I thought the wording of my request would
> have made that sufficiently clear. Do I really have to add the
> phrase "Yes, I have searched Google!" to my sig?
> 
A visit to #git on freenode.net would clear up any problems you might have, thats all Im saying.

> -- 
> Tilman Schmidt                    E-Mail: tilman@imap.cc
> Bonn, Germany
> Yes, I have searched Google!
> 
> 

Re: git guidance

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 417 bytes --]

Kristoffer Ericson schrieb:
> Google is your friend.

Sigh.

In case you didn't guess, I *have* of course searched Google,
and not just that. I thought the wording of my request would
have made that sufficiently clear. Do I really have to add the
phrase "Yes, I have searched Google!" to my sig?

-- 
Tilman Schmidt                    E-Mail: tilman@imap.cc
Bonn, Germany
Yes, I have searched Google!


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: git guidance

[Arkadiusz Miskiewicz]

On Tuesday 27 of November 2007, Tilman Schmidt wrote:
> So I've watched Linus' Google Tech Talk about git and let him convince
> me that I've been stupid to use CVS, that Subversion is even worse,
> and the only sensible approach is to use git. Went ahead and tried to
> convert my driver development to git.

You should watch this one http://youtube.com/watch?v=8dhZ9BXQgc4 . It's better 
8-)

> TIA

-- 
Arkadiusz Miśkiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/

Re: git guidance

[Randy Dunlap]

On Wed, 28 Nov 2007 00:52:38 +0100 Willy Tarreau wrote:

> Tilman, there was a howto by Jeff Garzik I believe. It helped me
> a lot when I didn't understand a damn command, even if it was in
> the very old ages (version 0.5 or something like this). The tutorials
> on the GIT site are quite good too. You must read them entirely and
> proceed with the examples as you read them. Believe me, it helps you
> understand a lot of things, specially about the split in 3 parts
> (objects, cache, and working dir).

FYI, Jeff's git info is at
  http://linux.yyz.us/git-howto.html

---
~Randy

Re: git guidance

[Kristoffer Ericson]

On Wed, 28 Nov 2007 00:52:38 +0100
Willy Tarreau <w@1wt.eu> wrote:

> On Tue, Nov 27, 2007 at 11:55:11PM +0100, Kristoffer Ericson wrote:
> > Greetings,
> > 
> > Google is your friend. If you're looking for irc channels you can always try #git at irc.freenode.net
> > Git howto/tutorial/... doesn't belong in the kernel mailinglist.
> 
> Well, I don't agree with you. His question is about how to use GIT to
> develop his driver.
>    1) linux-kernel is a development ML.
>    2) he needs help from people how already encountered such beginner's
>       issues and who might git very good advices.
Agreed, my main concern was turning list into a "git-support" list and since I used the tutorials myself to get started, I felt
they are quite satisfactory. However as you pointed out, needing help to develope his driver is a kernel matter. Point taken. :)

> 
> It should not turn into an endless thread led by people who want to
> redefine GIT's roadmap, but experience sharing helps a lot with GIT.
> 
> Tilman, there was a howto by Jeff Garzik I believe. It helped me
> a lot when I didn't understand a damn command, even if it was in
> the very old ages (version 0.5 or something like this). The tutorials
> on the GIT site are quite good too. You must read them entirely and
> proceed with the examples as you read them. Believe me, it helps you
> understand a lot of things, specially about the split in 3 parts
> (objects, cache, and working dir).
> 
> I really think that if your patches do not apply, it's because you
> have lost some changes due to a wrong initial use possibly caused
> by a mis-understanding of the tool. It happened to me too, but in
> this case you can almost certainly find your old changes in older
> commits.
> 
> I really hope that soon someone will come up with a big 400-pages
> book called "GIT" with a lot of good advices. It would be awesome.
I second that :)

> 
> Anyway, don't get demotivated about the tool or the workflow. If
> you find it inconvenient to use, you're doing something wrong and
> you don't know it.
> 
> Regards,
> Willy
> 

Re: git guidance

[Willy Tarreau]

On Tue, Nov 27, 2007 at 11:55:11PM +0100, Kristoffer Ericson wrote:
> Greetings,
> 
> Google is your friend. If you're looking for irc channels you can always try #git at irc.freenode.net
> Git howto/tutorial/... doesn't belong in the kernel mailinglist.

Well, I don't agree with you. His question is about how to use GIT to
develop his driver.
   1) linux-kernel is a development ML.
   2) he needs help from people how already encountered such beginner's
      issues and who might git very good advices.

It should not turn into an endless thread led by people who want to
redefine GIT's roadmap, but experience sharing helps a lot with GIT.

Tilman, there was a howto by Jeff Garzik I believe. It helped me
a lot when I didn't understand a damn command, even if it was in
the very old ages (version 0.5 or something like this). The tutorials
on the GIT site are quite good too. You must read them entirely and
proceed with the examples as you read them. Believe me, it helps you
understand a lot of things, specially about the split in 3 parts
(objects, cache, and working dir).

I really think that if your patches do not apply, it's because you
have lost some changes due to a wrong initial use possibly caused
by a mis-understanding of the tool. It happened to me too, but in
this case you can almost certainly find your old changes in older
commits.

I really hope that soon someone will come up with a big 400-pages
book called "GIT" with a lot of good advices. It would be awesome.

Anyway, don't get demotivated about the tool or the workflow. If
you find it inconvenient to use, you're doing something wrong and
you don't know it.

Regards,
Willy

Re: git guidance

[Jan Engelhardt]

On Nov 27 2007 23:33, Tilman Schmidt wrote:
>
>It didn't work too well. The first result was one of maximal
>embarrassment: I produced a patch that didn't even compile when
>applied to the official tree. This shouldn't happen with git, right?
>Well, it did. So now I'm back to keeping a virgin kernel source tree
>alongside my development area in order to produce diffs. That can't
>be right?
>
No, it can't. Use stgit/quilt ;p

>Does somebody have a step by step tutorial for doing the standard
>"edit - test - modify - retest - submit - edit - resubmit" sequence
>with GIT? Is there a GIT newsgroup or mailinglist? Or should I just
>post my silly questions to LKML?
>
http://www.linuxworld.com/video/?bcpid=1138309735&bclid=1213841149&bctid=1221911905

James Bottomley's intro helps a lot.

Re: git guidance

[Kristoffer Ericson]

Greetings,

Google is your friend. If you're looking for irc channels you can always try #git at irc.freenode.net
Git howto/tutorial/... doesn't belong in the kernel mailinglist.

Best wishes
Kristoffer Ericson

On Tue, 27 Nov 2007 23:33:21 +0100
Tilman Schmidt <tilman@imap.cc> wrote:

> So I've watched Linus' Google Tech Talk about git and let him convince
> me that I've been stupid to use CVS, that Subversion is even worse,
> and the only sensible approach is to use git. Went ahead and tried to
> convert my driver development to git.
> 
> It didn't work too well. The first result was one of maximal
> embarrassment: I produced a patch that didn't even compile when
> applied to the official tree. This shouldn't happen with git, right?
> Well, it did. So now I'm back to keeping a virgin kernel source tree
> alongside my development area in order to produce diffs. That can't
> be right?
> 
> Obviously I'm still being stupid. (Probably an aftereffect of using
> CVS for too long.) But where do I turn for guidance? I read all the
> docs and READMEs I could find, but I still don't understand why GIT
> doesn't produce the results I need, and what to do differently.
> 
> Does somebody have a step by step tutorial for doing the standard
> "edit - test - modify - retest - submit - edit - resubmit" sequence
> with GIT? Is there a GIT newsgroup or mailinglist? Or should I just
> post my silly questions to LKML?
> 
> TIA
> 
> -- 
> Tilman Schmidt                          E-Mail: tilman@imap.cc
> Bonn, Germany
> Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
> Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
> 
> 

Re: git guidance

[J. Bruce Fields]

On Tue, Nov 27, 2007 at 11:33:21PM +0100, Tilman Schmidt wrote:
> Does somebody have a step by step tutorial for doing the standard
> "edit - test - modify - retest - submit - edit - resubmit" sequence
> with GIT? Is there a GIT newsgroup or mailinglist? Or should I just
> post my silly questions to LKML?

It's git@vger.kernel.org.

If you post there more specifics about what you tried and what the
results were, they might be able to figure out what happened.

Also, specifics about which documentation you read would help improve
the docs.  I believe that the in-tree beginner's documentation (the
"tutorial" and the "user manual"--also the first hits for "git tutorial"
and "git user manual" on google) explain how to do what you need, but
perhaps it's not obvious where.

--b.

git guidance

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 1325 bytes --]

So I've watched Linus' Google Tech Talk about git and let him convince
me that I've been stupid to use CVS, that Subversion is even worse,
and the only sensible approach is to use git. Went ahead and tried to
convert my driver development to git.

It didn't work too well. The first result was one of maximal
embarrassment: I produced a patch that didn't even compile when
applied to the official tree. This shouldn't happen with git, right?
Well, it did. So now I'm back to keeping a virgin kernel source tree
alongside my development area in order to produce diffs. That can't
be right?

Obviously I'm still being stupid. (Probably an aftereffect of using
CVS for too long.) But where do I turn for guidance? I read all the
docs and READMEs I could find, but I still don't understand why GIT
doesn't produce the results I need, and what to do differently.

Does somebody have a step by step tutorial for doing the standard
"edit - test - modify - retest - submit - edit - resubmit" sequence
with GIT? Is there a GIT newsgroup or mailinglist? Or should I just
post my silly questions to LKML?

TIA

-- 
Tilman Schmidt                          E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]