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: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Unge?ffnet mindestens haltbar bis: (siehe R?ckseite)
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 [email protected].
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.
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 <[email protected]> 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: [email protected]
> Bonn, Germany
> Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
> Unge?ffnet mindestens haltbar bis: (siehe R?ckseite)
>
>
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.
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
On Wed, 28 Nov 2007 00:52:38 +0100
Willy Tarreau <[email protected]> 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
>
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
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/
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: [email protected]
Bonn, Germany
Yes, I have searched Google!
On Wed, 28 Nov 2007 12:23:48 +0100
Tilman Schmidt <[email protected]> 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: [email protected]
> Bonn, Germany
> Yes, I have searched Google!
>
>
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
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 [email protected] 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: [email protected]
Bonn, Germany
Yes, I have searched Google!
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
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
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: [email protected]
Bonn, Germany
Yes, I have searched Google!
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.
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
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
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
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
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 [email protected]
> > 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 :)
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
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 [email protected] 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
On Wed, 28 Nov 2007 00:20:46 +0100 (CET)
Jan Engelhardt <[email protected]> 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
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
Haavard Skinnemoen schrieb:
>
> No, use "git rebase --interactive" ;-)
What's that? I can't find it in "man git-rebase".
--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Unge?ffnet mindestens haltbar bis: (siehe R?ckseite)
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: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Unge?ffnet mindestens haltbar bis: (siehe R?ckseite)
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
On Thu, 29 Nov 2007 13:45:44 +0100
Tilman Schmidt <[email protected]> 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
Quoting Al Boldi <[email protected]>:
> 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
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
Jing Xue wrote:
> Quoting Al Boldi <[email protected]>:
> > 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
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.
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
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
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 [email protected]
OP5 AB http://www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
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
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.
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
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 [email protected]
OP5 AB http://www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
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
Al Boldi <[email protected]> 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
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 [email protected]
OP5 AB http://www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Jakub Narebski wrote:
> Al Boldi <[email protected]> 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
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... :)
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
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
On Dec 7, 2007, at 11:36 AM, [email protected] 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
[email protected] 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
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.
On Dec 1, 2007 7:50 PM, Al Boldi <[email protected]> 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
[email protected] 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
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