Re: git guidance
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 -- 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/
Re: git guidance
[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 -- 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/
Re: git guidance
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 -- 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/
Re: git guidance
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. pgprg99Rd8pc6.pgp Description: PGP signature
Re: git guidance
[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 -- 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/
Re: git guidance
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 -- 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/
Re: git guidance
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 . 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
#!/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"
;;
Re: git guidance
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 -- 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/
Re: git guidance
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... :) pgp6T6CMqNVtk.pgp Description: PGP signature
Re: git guidance
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 -- 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/
Re: git guidance
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 www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 -- 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/
Re: git guidance
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 -- 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/
Re: git guidance
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 -- 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/
Re: git guidance
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 www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 -- 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/
Re: git guidance
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 -- 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/
Re: git guidance
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. -- 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/
Re: git guidance
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 -- 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/
Re: git guidance
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 www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 -- 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/
Re: git guidance
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 -- 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/
Re: git guidance
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 -- 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/
Re: git guidance
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. -- 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/
Re: git guidance
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 -- 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/
Re: git guidance
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 - 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/
Re: git guidance
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 - 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/
Re: git guidance
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 - 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/
Re: git guidance
On Nov 29, 2007, at 00:27:04, Al Boldi wrote: Jakub Narebski wrote: Besides, you can always use "git show :". 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 - 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/
Re: git guidance
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 SchmidtE-Mail: [EMAIL PROTECTED] Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite) signature.asc Description: OpenPGP digital signature
Re: git guidance
Haavard Skinnemoen schrieb: > > No, use "git rebase --interactive" ;-) What's that? I can't find it in "man git-rebase". -- Tilman SchmidtE-Mail: [EMAIL PROTECTED] Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite) signature.asc Description: OpenPGP digital signature
Re: git guidance
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 :". 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 - 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/
Re: git guidance
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 - 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/
Re: git guidance
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 - 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/
Re: git guidance
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 ). 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/ directory you will see a file named which contains your patch. Otherwise you need to do a guilt-add 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. 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/ - 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/
Re: git guidance
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 ). 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/ directory you will see a file > > named which contains your patch. Otherwise you need to do a > > guilt-add 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. > > > > > > > > > > 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 :) - 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/lkm
Re: git guidance
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 :". 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 - 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/
Re: git guidance
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 - 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/
Re: git guidance
Hi, On Wed, 28 Nov 2007, Al Boldi wrote: > [EMAIL PROTECTED] 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 - 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/
Re: git guidance
Johannes Schindelin wrote: > Hi, Hi! [EMAIL PROTECTED] 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 - 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/
Re: git guidance
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 ). 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/ directory you will see a file named which contains your patch. Otherwise you need to do a guilt-add 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. 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. - 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/
Re: git guidance
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 SchmidtE-Mail: [EMAIL PROTECTED] Bonn, Germany Yes, I have searched Google! signature.asc Description: OpenPGP digital signature
Re: git guidance
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/ - 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/
Re: git guidance
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 - 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/
Re: git guidance
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 SchmidtE-Mail: [EMAIL PROTECTED] Bonn, Germany Yes, I have searched Google! signature.asc Description: OpenPGP digital signature
Re: git guidance
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 - 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/
Re: git guidance
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 SchmidtE-Mail: [EMAIL PROTECTED] > Bonn, Germany > Yes, I have searched Google! > > - 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/
Re: git guidance
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 SchmidtE-Mail: [EMAIL PROTECTED] Bonn, Germany Yes, I have searched Google! signature.asc Description: OpenPGP digital signature
Re: git guidance
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śkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ - 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/
Re: git guidance
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 - 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/
Re: git guidance
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 > - 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/
Re: git guidance
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 - 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/
Re: git guidance
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/
Re: git guidance
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) > > - 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/
Re: git guidance
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. - 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/
git guidance
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) signature.asc Description: OpenPGP digital signature
