* Re: Updated git HOWTO for kernel hackers
From: Linus Torvalds @ 2005-06-23 2:39 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Greg KH, Linux Kernel, Git Mailing List
In-Reply-To: <42BA1B68.9040505@pobox.com>
On Wed, 22 Jun 2005, Jeff Garzik wrote:
>
> The problem is still that nothing says "oh, btw, I created 'xyz' tag for
> you" AFAICS?
>
> IMO the user (GregKH and me, at least) just wants to know their set of
> tags and heads is up-to-date on local disk. Wants to know what tags are
> out there. It's quite annoying when two data sets are out of sync
> (.git/objects and .git/refs/tags).
Well, I really think this is the exact same issue as when you write any
annoucement, and say "please pull from branch xyz of repo abc".
What I'm saying is that for a tagged release, that really translates to
"please pull tag xyz from repo abc" and the tools like git-ssh-pull will
just do the right thing: they'll pull the tag itself _and_ they'll pull
the objects it points to.
Of course, right now "git fetch" is hardcoded to always write FETCH_HEAD
(not the tag name), but I'm saying ythat _literally_ you can do this
already:
git fetch repo-name tags/xyz &&
( cat .git/FETCH_HEAD > .git/tags/xyz )
and it should do exactly what you want. Hmm?
So if we script this (maybe teach "git-fetch-script" to take "tag" as its
first argument and do this on its own), and people learn to just do
git fetch tag v2.6.18.5
when Chris or Greg make an announcement about "v2.6.18.5", then you're all
done, no?
The change to "git-fetch-script" would look something like the appended..
Totally untested, of course. Give it a try,
Linus
---
diff --git a/git-fetch-script b/git-fetch-script
--- a/git-fetch-script
+++ b/git-fetch-script
@@ -1,5 +1,12 @@
#!/bin/sh
#
+destination=FETCH_HEAD
+
+if [ "$1" = "tag" ]; then
+ shift
+ destination="refs/tags/$2"
+fi
+
merge_repo=$1
merge_name=${2:-HEAD}
@@ -35,7 +42,7 @@ download_objects () {
}
echo "Getting remote $merge_name"
-download_one "$merge_repo/$merge_name" "$GIT_DIR"/FETCH_HEAD || exit 1
+download_one "$merge_repo/$merge_name" "$GIT_DIR/$dest" || exit 1
echo "Getting object database"
-download_objects "$merge_repo" "$(cat "$GIT_DIR"/FETCH_HEAD)" || exit 1
+download_objects "$merge_repo" "$(cat "$GIT_DIR/$dest")" || exit 1
^ permalink raw reply
* Re: Updated git HOWTO for kernel hackers
From: Jeff Garzik @ 2005-06-23 3:06 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Greg KH, Linux Kernel, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0506221929430.11175@ppc970.osdl.org>
Linus Torvalds wrote:
> What I'm saying is that for a tagged release, that really translates to
> "please pull tag xyz from repo abc" and the tools like git-ssh-pull will
> just do the right thing: they'll pull the tag itself _and_ they'll pull
> the objects it points to.
Yes, everything does the right there here.
> Of course, right now "git fetch" is hardcoded to always write FETCH_HEAD
> (not the tag name), but I'm saying ythat _literally_ you can do this
> already:
>
> git fetch repo-name tags/xyz &&
> ( cat .git/FETCH_HEAD > .git/tags/xyz )
>
> and it should do exactly what you want. Hmm?
No, not at all. This sub-thread is all about tags/ dir updates. Users
should be able to do
git pull-more rsync://...
and get ALL of .git/refs/tags/* that have appeared since their last update.
Concrete example: I have a git tree on local disk. I need to find out
where, between 2.6.12-rc1 and 2.6.12, a driver broke. This requires
that I have -ALL- linux-2.6.git/refs/tags on disk already, so that I can
bounce quickly and easily between tags.
It is valuable to have a local copy of -all- tags, -before- you need
them. That is why people like me and GregKH use rsync directly. We
want EVERYTHING in the kernel.org linux-2.6.git tree, not just what we
know we need right now.
Jeff
^ permalink raw reply
* Re: Updated git HOWTO for kernel hackers
From: Linus Torvalds @ 2005-06-23 3:24 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Greg KH, Linux Kernel, Git Mailing List
In-Reply-To: <42BA271F.6080505@pobox.com>
On Wed, 22 Jun 2005, Jeff Garzik wrote:
>
> Concrete example: I have a git tree on local disk. I need to find out
> where, between 2.6.12-rc1 and 2.6.12, a driver broke. This requires
> that I have -ALL- linux-2.6.git/refs/tags on disk already, so that I can
> bounce quickly and easily between tags.
Absolutely not.
I might have my private tags in my kernel, and you might have your private
tags ("tested") in your kernel, so there is no such thing as "ALL".
The fact that BK had it was a BK deficiency, and just meant that you
basically couldn't use tags at all with BK, the "official ones" excepted.
It basically meant that nobody else than me could ever tag a tree. Do you
not see how that violates the very notion of "distributed"?
This is _exactly_ the same thing as if you said "I want to merge with ALL
BRANCHES". That notion doesn't exist. You can rsync the whole repository,
and you'll get all branches from that repository, that's really by virtue
of doing a filesystem operation, not because you asked git to get you all
branches.
A tag is even _implemented_ exactly like a branch, except it allows (but
does not require) that extra step of signing an object. The only
difference is literally whether it is in refs/branches or refs/tags.
> It is valuable to have a local copy of -all- tags, -before- you need
> them.
You seem to not realize that "all tags" is a nonsensical statement in a
distributed system.
If you want to have a list of official tags, why not just do exactly that?
What's so hard with saying "ok, that place has a list of 'official' tags,
let's fetch them".
How would you fetch them? You might use rsync, for example. Or maybe wget.
Or whatever. The point is that this works already. You're asking for
something nonsensical, outside of just a script that does
rsync -r --ignore-existing repo/refs/tags/ .git/refs/tags/
See? What's your complaint with just doing that?
Linus
^ permalink raw reply
* Re: Patch (apply) vs. Pull
From: Daniel Barkalow @ 2005-06-23 3:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.58.0506221504370.2353@ppc970.osdl.org>
On Wed, 22 Jun 2005, Linus Torvalds wrote:
> I've been doing unified diffs for a _loong_ time, and I edit patches in my
> sleep. The rules for line numbers etc are really quite simple, and yes, I
> do edit patches before I apply them.
Ah, okay. I actually know the rules for line numbers, and I still can't
change the lines and line numbers reliably in sync.
> Similarly, the "remove patch fragments" is often because somebody mixes up
> two things in a patch, and I decide to take one of them but there's some
> problem with the other. Sometimes that patch fragment thing means that I
> have to edit even within one fragment, and fix up the patch line-counters
> etc.
Right; I do this myself, when I turn a mass of changes into a set of
patches. I think it would be worth having a good tool for applying a
patch while discarding undesired hunks and editing the regions it applies
to. This is, of course, not immediately relevant, aside from it making the
tracking more useful, because more people would be able to reliably modify
patches. In any case, though, after you've fixed a patch, you apply it
rather than sending it to anyone or archiving it or something, right?
> NOTE! This is "rare" in the sense that it doesn't happen for most patches,
> but that said, I get a _lot_ of patches, and it's not rare in the sense
> that it doesn't happen weekly.
I think it would we worthwhile for the common case for the system to
recognize that a patch went in unmodified, but potentially after a
different patch which caused it to have fuzz, and have a header that would
get the developer's update to recognize what happened.
> I don't want crap in my code. I disagree very strongly with people who say
> that "you can just fix it later". That's not how people work, and worst of
> all, not only does it not get fixed up, even _if_ it is fixed up the wrong
> version inevitably ends up showing up somewhere else, just because
> somebody ended up using the original patch.
If you can modify patches, that's better; I think most maintainers would
fall back to applying the patch and fixing things in the working directory
before committing; the history still doesn't get dirty, which is what
actually matters.
> > I believe there are separate issues here:
> >
> > 1. pure history rewriting: maintainer merges a developer's
> > intermediate head; developer generates a new history in which
> > everything later is based on the new mainline.
> > 2. patches: changes are transferred as diffs over SMTP instead of trees
> > inside git.
> > 3. cherry-picking: maintainer applies some set of changes from a
> > developer which is not merging a head the developer created.
> >
> > I think (1) is easily handled as a merge script that goes through a series
> > of commits and makes a new series out of merging each of them, rather than
> > merging the last of them only.
>
> Yes. And I think (1) is pretty useful on its own, and that git could
> support that with a nice helper script.
I think that this, by itself, is likely to be a sufficiently common case
to be worth just doing. Once the script exists, it makes it worthwhile for
developers to organize things such that it works.
E.g., yesterday, I'd have had:
You -- A1 -- A2
\ \
----- B ------ Stuff I've sent -- Stuff I'm working on
If you pulled A1 or A2, and/or B, the script would take care of everything
without any fuss. I didn't actually make this structure of commits,
however, because I didn't have the script that would make it useful.
> > I think (2) should be as transparent as possible, and, in cases where
> > there was no cherry-picking, be equivalent in the system's behavior to the
> > result of pull and merge (with the possibility for various cleanup
> > happening on top of or along with the merge in either method).
>
> I really see patches as something totally different than merging. I
> literally see them as a way to move between different systems.
>
> For example, the git model just doesn't work very well for "fluid"
> development: git ends up setting history entirely in stone, which means
> that you can't fix up mistakes later. And this is where patches come in:
> they work as a way to transfer the information, while at the same time
> totally breaking the connection with the original messy tree.
I certainly use patches internally as a way of going from my messy
development tree to my clean patch tree. But that's mostly a developer's
own usage. (I suppose developers might diff their latest commit against
the mainline, and then hand-edit it into a series without regenerating
patches, but I think that would be really awkward and failure-prone for
non-experts in unified diff.)
But I think that the real value of patches for submission as opposed to
merges is that you can review them conveniently. It's not just that
they're machine-readable and can apply with fuzz; they're also pretty easy
for humans to read, which is why unified diffs are better than context
diffs, despite having the same expressive power. In this case, then, they
aren't being used for cherry-picking or any other history cleaning; you'll
tend to apply the patch straight (or reject it), and then it would be
useful to have it act like a merge, with respect to further operations
understanding what happened.
> So I really think our view on what "patches" are is very fundamentally
> different. I don't think SMTP is a good medium for merges: BK actually
> supports that with "bk send" (or something like that) and I refused to use
> it. It was a "worst of both worlds" thing.
Certainly, if you trust the result enough to merge, there's no need to
review anything and therefore no need to go through email.
> > The tricky part is (3), which is currently only possible by going outside
> > of git. But I think that this is something to tackle separately from
> > (1) and (2) (where (2) does not involve doing (3)).
>
> I think the cherry-picking kind of goes hand in hand with 1/2, though.
> Patches are really the perfect form of cherry-picking, exactly because
> they do _not_ imply a very strong ordering or even a very strong
> dependency on the state of the rest of the sources. So patches end up
> being the perfect medium for cherry-picking, and SMTP ends up being one of
> the best ways to transport them and let them evolve.
I think that cherry-picking depends on 1/2, but that each of them has a
non-cherry-picking case worth supporting specifically.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Patch (apply) vs. Pull
From: Linus Torvalds @ 2005-06-23 4:23 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.21.0506221821260.30848-100000@iabervon.org>
On Wed, 22 Jun 2005, Daniel Barkalow wrote:
>
> Ah, okay. I actually know the rules for line numbers, and I still can't
> change the lines and line numbers reliably in sync.
Heh. I usually just edit the fragment, and ignore the line numbers, and
then I go back and just count ;)
So I don't even try to keep things in sync, I just fix them up
after-the-fact.
> Right; I do this myself, when I turn a mass of changes into a set of
> patches. I think it would be worth having a good tool for applying a
> patch while discarding undesired hunks and editing the regions it applies
> to.
There at least one GNU emacs "patch mode" editing thing to help you, and I
think there is even a tool specifically geared to splitting up a patch
into several sub-patches. I've been pointed at it occasionally, I just do
it by hand.
> I think it would we worthwhile for the common case for the system to
> recognize that a patch went in unmodified, but potentially after a
> different patch which caused it to have fuzz, and have a header that would
> get the developer's update to recognize what happened.
Note that I don't even apply patches with fuzz at all. "git-apply" refuses
to recognize anything with fuzz, although it _will_ move the patch around
to make it match.
I've got this theory that if you apply a thousand patches, and one of them
applies with fuzz, you want to stop right there and see what's wrong.
This was what I did before I wrote "git-apply":
patch -E -u --no-backup-if-mismatch -f -p1 --fuzz=0 --input=$PATCHFILE
ie pretty unambiguous. I don't trust the "automatically guess the depth of
the patch" thing, for example, since it, together with allowing fuzz, has
several times caused nasty problems for me with things like the wrong
Makefile being modified by a patch..
So as far as I'm concerned, you really could just take the SHA1 of the
patch (leave out the '@@' lines with line numbers), and you'd have a
reliable ID for it.
In fact, you could probably replace every run of contiguous whitespace
with a single space, and then you'd not have to worry about whitespace
differences either. That would be very simple to do, and quite workable: I
certainly think it sounds more reliable than just hoping that people
always pass on a "patch ID" in their emails..
> > I don't want crap in my code. I disagree very strongly with people who say
> > that "you can just fix it later". That's not how people work, and worst of
> > all, not only does it not get fixed up, even _if_ it is fixed up the wrong
> > version inevitably ends up showing up somewhere else, just because
> > somebody ended up using the original patch.
>
> If you can modify patches, that's better; I think most maintainers would
> fall back to applying the patch and fixing things in the working directory
> before committing; the history still doesn't get dirty, which is what
> actually matters.
The reason I much prefer editing patches is my batch-mode approach to then
applying them. If I were to fix things up after applying a patch, I'd have
to break up the series: apply <n> patches, fix up, apply <m> patches, fix
up, etc. In contrast, now I just fix up the mbox directly (at a minimum,
add the sign-off, even if I don't actually touch the patch itself), and
just apply it all in one go.
But yes, if it's a nasty case, I'll just apply it, edit it, re-create a
diff, and then re-apply it with the re-created diff (since all my tools
are geared towards getting the log message etc with the patch, I don't
just commit it after fixing it up: that would screw up the author
information etc).
> > Yes. And I think (1) is pretty useful on its own, and that git could
> > support that with a nice helper script.
>
> I think that this, by itself, is likely to be a sufficiently common case
> to be worth just doing. Once the script exists, it makes it worthwhile for
> developers to organize things such that it works.
Yeah. It probably works well in 99% of the cases to just do a simple
"export as patch" + "apply on top with old commit message, author and
author-date".
> But I think that the real value of patches for submission as opposed to
> merges is that you can review them conveniently.
Yes, agreed (with the exception of how I tend to merge with Andrew, where
it's really more of a regular merge in the sense of "I pull from Andrew
because I trust him, not because I look at every patch").
> It's not just that
> they're machine-readable and can apply with fuzz; they're also pretty
> easy for humans to read, which is why unified diffs are better than
> context diffs, despite having the same expressive power. In this case,
> then, they aren't being used for cherry-picking or any other history
> cleaning; you'll tend to apply the patch straight (or reject it), and
> then it would be useful to have it act like a merge, with respect to
> further operations understanding what happened.
I've _occasionally_ wanted patches to work that way, just because they
don't apply, but they'd apply to the right version and then I could just
merge them. So yes, sometimes a patch might be more of a merge thing. Most
of the time, the patch has really been around the block several times, and
it's really lost it's position in the history tree.. So it really ends up
being "just apply it to the top" 99% of the time anyway.
Linus
^ permalink raw reply
* Re: Updated git HOWTO for kernel hackers
From: Daniel Barkalow @ 2005-06-23 4:23 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linux Kernel, Git Mailing List
In-Reply-To: <42B9E536.60704@pobox.com>
On Wed, 22 Jun 2005, Jeff Garzik wrote:
> 5) check in your own modifications (e.g. do some hacking, or apply a patch)
>
> # go to repo
> $ cd linux-2.6
>
> # make some modifications
> $ patch -sp1 < /tmp/my.patch
> $ diffstat -p1 < /tmp/my.patch
>
> # NOTE: add '--add' and/or '--remove' if files were added or removed
> $ git-update-cache <list of all files changed>
There's actually "git add" for when you add a file (if you're actually
developing with git, rather than just applying patching with it). No
script, so far as I can tell, for removing a file, though.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Updated git HOWTO for kernel hackers
From: Adam Kropelin @ 2005-06-23 3:52 UTC (permalink / raw)
To: Linus Torvalds, Jeff Garzik; +Cc: Linux Kernel, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0506221915280.11175@ppc970.osdl.org>
Linus Torvalds wrote:
> On Wed, 22 Jun 2005, Jeff Garzik wrote:
>> git commit --figure-out-for-me-what-files-changed
>
> Well, it _does_ do that. That's what the "git status" thing does, and
> look at the initial commit message comments that it prepares for you:
> it
> tells you which files are modified but haven't been marked for
> check-in
> etc.
>
> But the thing is, you need to have a graphical tool for that. I don't
> want to have some silly command line that asks for each modified file
> whether you want to include that file in the commit or not.
I know I shouldn't invoke this particular acronym, but I rather like
CVS's approach. If the user does not specify any files on the command
line, assume he wants to check in everything that has changed (added and
removed files excluded). When you see the initial commit message you can
review the list of affected files and you can always abort and specify
files explictly if you realize you want to exclude some.
I like that method because it gives you a kick in the pants for having
mixed multiple unrelated changes in your working directory. "Oh, you
were lazy and changed six unrelated things without comitting, eh? You
will now pay for your lack of rigor by typing filenames..." On the flip
side, you get rewarded with less typing if you keep your working
directory clean.
--Adam
^ permalink raw reply
* Re: Updated git HOWTO for kernel hackers
From: Linus Torvalds @ 2005-06-23 4:54 UTC (permalink / raw)
To: Adam Kropelin; +Cc: Jeff Garzik, Linux Kernel, Git Mailing List
In-Reply-To: <07be01c577a7$05108660$03c8a8c0@kroptech.com>
On Wed, 22 Jun 2005, Adam Kropelin wrote:
>
> I know I shouldn't invoke this particular acronym, but I rather like
> CVS's approach.
The problem I have with "git commit" committing everything dirty by
default is that it encourages exactly the wrong kind of behaviour, ie the
"commit it all in one go without thinking about it".
Also, CVS really doesn't have much choice, since CVS doesn't _have_ the
notion of marking files for commits. In contrast, in git the index file
really does end up beign a good way to say which files are ready to be
committed.
And "git status" really isn't that hard to type, and it will tell you
exactly what you've already marked for commit, and what you have dirty in
the tree but isn't marked for commit yet.
So I think the "git commit <file-list>" thing is very convenient, but it's
convenient exactly because it's concise yet still precise and doesn't
encourage the "just commit whatever random dirty state I have right now"
mentality.
And if you have more than a few files dirty in your tree, I really think
it's much better to do "git status" and think about it a bit and select
the files you do want to commit than it is to just do "git commit" and let
it rip.
Now, I could well imagine adding an "--all" flag (and not even allow the
shorthane version) to both git-update-cache and "git commit". So that you
could say "commit all the dirty state", but you'd at least have to think
about it before you did so.
Linus
^ permalink raw reply
* Re: Updated git HOWTO for kernel hackers
From: Jeff Garzik @ 2005-06-23 5:16 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Greg KH, Linux Kernel, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0506222014000.11175@ppc970.osdl.org>
Linus Torvalds wrote:
> rsync -r --ignore-existing repo/refs/tags/ .git/refs/tags/
>
> See? What's your complaint with just doing that?
No complaint with that operation. The complaint is that it's an
additional operation. Re-read what Greg said:
> Is there some reason why git doesn't pull the
> tags in properly when doing a merge? Chris and I just hit this when I
> pulled his 2.6.12.1 tree and and was wondering where the tag went.
Multiple users -- not just me -- would prefer that git-pull-script
pulled the tags, too.
Suggested solution: add '--tags' to git-pull-script
(git-fetch-script?), which calls
rsync -r --ignore-existing repo/refs/tags/ .git/refs/tags/
> You seem to not realize that "all tags" is a nonsensical statement in a
> distributed system.
>
> If you want to have a list of official tags, why not just do exactly that?
> What's so hard with saying "ok, that place has a list of 'official' tags,
> let's fetch them".
I know how tags work, and I like the new flexibility above and beyond BK.
Kernel hackers are surprised when the tags aren't pulled, along with the
objects. BK and CVS trained us that tags came with the repo, no
additional steps needed. Why not give us the OPTION of working like
we've always worked?
Let the kernel hacker say "yes, I really do want to download the tags
Linus publicly posted in linux-2.6.git/refs/tags" because this was a
common operation in the previous workflow, a common operation that we
-made use of-.
Jeff
^ permalink raw reply
* Re: Patch (apply) vs. Pull
From: Daniel Barkalow @ 2005-06-23 5:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.58.0506222059150.11175@ppc970.osdl.org>
On Wed, 22 Jun 2005, Linus Torvalds wrote:
> On Wed, 22 Jun 2005, Daniel Barkalow wrote:
> > I think it would we worthwhile for the common case for the system to
> > recognize that a patch went in unmodified, but potentially after a
> > different patch which caused it to have fuzz, and have a header that would
> > get the developer's update to recognize what happened.
>
> Note that I don't even apply patches with fuzz at all. "git-apply" refuses
> to recognize anything with fuzz, although it _will_ move the patch around
> to make it match.
I bet I'm misunderstanding fuzz; what I actually mean is that, if a patch
applies after moving it, then regenerating it from the result would give
the a patch with different line numbers; if these affect the hash, the
author's tools will be sad.
> So as far as I'm concerned, you really could just take the SHA1 of the
> patch (leave out the '@@' lines with line numbers), and you'd have a
> reliable ID for it.
>
> In fact, you could probably replace every run of contiguous whitespace
> with a single space, and then you'd not have to worry about whitespace
> differences either. That would be very simple to do, and quite workable: I
> certainly think it sounds more reliable than just hoping that people
> always pass on a "patch ID" in their emails..
That's actually quite plausible. The only case it wouldn't handle is when
you actually discard parts, and I'm not sure at this point what other
people should see there.
> But yes, if it's a nasty case, I'll just apply it, edit it, re-create a
> diff, and then re-apply it with the re-created diff (since all my tools
> are geared towards getting the log message etc with the patch, I don't
> just commit it after fixing it up: that would screw up the author
> information etc).
I think most people's scripts stash the information needed for the commit
somewhere, and pick it back up at commit time, at least for merges.
> > > Yes. And I think (1) is pretty useful on its own, and that git could
> > > support that with a nice helper script.
> >
> > I think that this, by itself, is likely to be a sufficiently common case
> > to be worth just doing. Once the script exists, it makes it worthwhile for
> > developers to organize things such that it works.
>
> Yeah. It probably works well in 99% of the cases to just do a simple
> "export as patch" + "apply on top with old commit message, author and
> author-date".
I think that you'll get better results out of "merge with top" + "commit
with old commit info, but not listing old commit as a parent". At least,
that's what StGIT is doing, IIRC, and using merge instead of patch seems
like it'll make the remaining 1% a lot more pleasant. In fact, isn't it
necessary if you want to make sense out of "half of my patch got applied",
as a bunch of "still needed" hunks and a bunch of "already applied" hunks
that disappear after the message?
> > It's not just that
> > they're machine-readable and can apply with fuzz; they're also pretty
> > easy for humans to read, which is why unified diffs are better than
> > context diffs, despite having the same expressive power. In this case,
> > then, they aren't being used for cherry-picking or any other history
> > cleaning; you'll tend to apply the patch straight (or reject it), and
> > then it would be useful to have it act like a merge, with respect to
> > further operations understanding what happened.
>
> I've _occasionally_ wanted patches to work that way, just because they
> don't apply, but they'd apply to the right version and then I could just
> merge them. So yes, sometimes a patch might be more of a merge thing. Most
> of the time, the patch has really been around the block several times, and
> it's really lost it's position in the history tree.. So it really ends up
> being "just apply it to the top" 99% of the time anyway.
It should be fine as a merge if you apply it to the top; the case that's
cherry-picking is when you apply a patch that was second in a series
without applying the first. By "like a merge" I really mean "someone
changed <old> to <patched>; I want to make that change to <new>, such that
future merges aren't confused." In this case, you'd actually generate only
an "apply" commit, not recreate (or fetch) "patched-old" and generate a
merge commit. But, if you put the hash of the patch (as above) in a commit
header, other people who have the same patch (including the author) can
identify the commonality and not be confused. (I think putting
it in a header is likely necessary for efficiency reasons, so that it
isn't necessary to unpack/diff/hash all of the trees while updating.)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: git-prune-script eats data
From: Jeff Garzik @ 2005-06-23 5:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0506221857410.11175@ppc970.osdl.org>
Linus Torvalds wrote:
> And now I realize what the problem is. It's _not_ that "git prune" has
> removed too much, like the obvious implication would be: it's that "git
> prune" has not removed _enough_.
Makes a lot of sense. Looking at the repo, I did indeed forget to copy
the tags.
> So the trivial fix is to just remove the lines from fsck-cache.c that say
>
> /* Don't bother with tag reachability. */
> if (obj->type == tag_type)
> continue;
>
> and that will fix it for you.
Sounds good, thanks.
> It's exactly the same thing that Jens had. You have a tag object for the
> v2.6.11-tree thing, but you don't have the reference to the tag.
Ref email just sent: Kernel hackers expect tags to come with the pull.
Four kernel hackers, and counting.
Just accept that our brains are wired that way ;-) We like having
Linus-blessed-and-pushed-to-kernel.org tags from linux-2.6.git public
tree follow us around.
git-pull-script --tags $url
should accomplish that.
Jeff
^ permalink raw reply
* Re: Updated git HOWTO for kernel hackers
From: Jeff Garzik @ 2005-06-23 5:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Adam Kropelin, Linux Kernel, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0506222146460.11175@ppc970.osdl.org>
Linus Torvalds wrote:
> The problem I have with "git commit" committing everything dirty by
> default is that it encourages exactly the wrong kind of behaviour, ie the
> "commit it all in one go without thinking about it".
100% agreed
> And "git status" really isn't that hard to type, and it will tell you
> exactly what you've already marked for commit, and what you have dirty in
> the tree but isn't marked for commit yet.
Having found about it recently, 'git status' is quite useful.
> So I think the "git commit <file-list>" thing is very convenient, but it's
> convenient exactly because it's concise yet still precise and doesn't
> encourage the "just commit whatever random dirty state I have right now"
> mentality.
>
> And if you have more than a few files dirty in your tree, I really think
> it's much better to do "git status" and think about it a bit and select
> the files you do want to commit than it is to just do "git commit" and let
> it rip.
For me at least, providing a file list is a pain, because I am so
precise [read: obsessive] about keeping an otherwise clean working dir
:) Except in rare occasions, I know precisely that the changes in the
working dir comprise 100% of what I plan to commit.
Locally I have scripted
git-diff-cache -p HEAD | diffstat -p1 | awk '{print $1}' > /tmp/lst
git-update-cache `cat /tmp/lst`
because of this.
[again, clearly doesn't work with remove/add/mode change]
> Now, I could well imagine adding an "--all" flag (and not even allow the
> shorthane version) to both git-update-cache and "git commit". So that you
> could say "commit all the dirty state", but you'd at least have to think
> about it before you did so.
That's pretty much what I suggested when I said
git commit --figure-out-for-me-what-files-changed
:)
So I certainly agree there.
Jeff
^ permalink raw reply
* Re: Updated git HOWTO for kernel hackers
From: Linus Torvalds @ 2005-06-23 5:58 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Greg KH, Linux Kernel, Git Mailing List
In-Reply-To: <42BA45B1.7060207@pobox.com>
On Thu, 23 Jun 2005, Jeff Garzik wrote:
>
> No complaint with that operation. The complaint is that it's an
> additional operation. Re-read what Greg said:
Please re-read what I said.
Pulling a regular head _cannot_ and _must_not_ update tags. Tags are not
associated with the tree, and they _cannot_ and _must_not_ be so, exactly
because that would make them global instead of private, and it would
fundamentally make them not be distributed, and would mean that they'd be
pointless as anything but "Linus' official tags".
That's what we had in BK _AND IT DOES NOT WORK_!
Does it help when I scream?
> > Is there some reason why git doesn't pull the
> > tags in properly when doing a merge? Chris and I just hit this when I
> > pulled his 2.6.12.1 tree and and was wondering where the tag went.
And I suggested that if you want that, then you pull on the TAG. You take
my modification, you test it, and you see if
git fetch tag ..repo.. tagname
works.
That solves exactly the case that Greg is complaining about, and it solves
it in a _sane_ manner: you tell git that you want a tag, and git fetches
it for you. It's that simple, and it does not introduce the _BROKEN_
notion that tags are associated directly with the commit itself and
somehow visible to all.
> Multiple users -- not just me -- would prefer that git-pull-script
> pulled the tags, too.
And multiple users -- clearly including you -- aren't listening to me.
Tags are separate from the source they tag, and they HAVE TO BE. There is
no "you automatically get the tags when you get the tree", because the two
don't have a 1:1 relationship.
And not making them separate breaks a lot of things. As mentioned, it
fundamentally breaks the distributed nature, but that also means that it
breaks whenever two people use the same name for a tag, for example. You
can't "merge" tags. BK had a very strange form of merging, which was (I
think) to pick the one last in the BK ChangeSet file, but that didn't make
it "right". You just never noticed, because Linux could never use tags at
all due to the lack of privacy, except for big releases..
> Suggested solution: add '--tags' to git-pull-script
> (git-fetch-script?), which calls
> rsync -r --ignore-existing repo/refs/tags/ .git/refs/tags/
How is this AT ALL different from just having a separate script that does
this? You've introduced nothing but syntactic fluff, and you've made it
less flexible at the same time. First off, you might want to get new tags
_without_ fetching anything else, and you might indeed want to get the
tags _first_ in order to decide what you want to fetch. In fact, in many
cases that's exactly what you want, namely you want to fetch the data
based on the tag.
Secondly, if your worry is that you forget, then hell, write a small shell
function, and be done with it.
BUT DO NOT MESS UP THINGS FOR OTHER PEOPLE.
When I fetch somebody elses head, I had better not fetch his tags. His
tags may not even make _sense_ in what I have - he may tag things in other
branches that I'm not fetching at all. In fact, his tag-namespace might be
_different_ from mine, ie he might have tagged something "broken" in his
tree, and I tagged something _else_ "broken" in mine, just because it
happens to be a very useful tag for when you want to mark "ok, that was a
broken tree".
It is wrong, wrong, _wrong_ to think that fetching somebody elses tree
means that you should fetch his tags. The _only_ reason you think it's
right is because you've only ever seen centralized tags: tags were the one
thing that BK kept centralized.
But once people realize that they can use tags in their own trees, and
nobody else will ever notice, they'll slowly start using them. Maybe it
takes a few months or even longer. But it will happen. And I refuse to
make stupid decisions that makes it not work.
And thinking that "fetching a tree fetches all the tags from that tree"
really _is_ a stupid decision. It's missing the big picture. It's missing
the fact that tags _should_ be normal every-day things that you just use
as "book-marks", and that the kind of big "synchronization point for many
people" tag should actually be the _rare_ case.
The fact that global tags make that private "bookmark" usage impossible
should be a big red blinking sign saying "don't do global tags".
> Let the kernel hacker say "yes, I really do want to download the tags
> Linus publicly posted in linux-2.6.git/refs/tags" because this was a
> common operation in the previous workflow, a common operation that we
> -made use of-.
And I already suggested a trivial script. Send me the script patch,
instead of arguing for stupid things.
Linus
^ permalink raw reply
* Re: Patch (apply) vs. Pull
From: Linus Torvalds @ 2005-06-23 6:09 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.21.0506230025420.30848-100000@iabervon.org>
On Thu, 23 Jun 2005, Daniel Barkalow wrote:
>
> I bet I'm misunderstanding fuzz; what I actually mean is that, if a patch
> applies after moving it, then regenerating it from the result would give
> the a patch with different line numbers; if these affect the hash, the
> author's tools will be sad.
What GNU patch calls "fuzz" is how badly the context can "not match". A
"fuzz factor" of one allows the patch to apply even if the "outermost" of
the context lines don't match up. See "man patch".
What you talk about is what they (and I) call "offset", and yes, you must
ignore the line numbers when considering two patches identical, exactly
because other patches may change their offsets.
So "git-apply" does apply patches that are offset from where the patch
claims (and the "claimed position" is really nothing more than a "start
searching here" parameter), but git-apply does not allow any fuzz.
> > In fact, you could probably replace every run of contiguous whitespace
> > with a single space, and then you'd not have to worry about whitespace
> > differences either. That would be very simple to do, and quite workable: I
> > certainly think it sounds more reliable than just hoping that people
> > always pass on a "patch ID" in their emails..
>
> That's actually quite plausible. The only case it wouldn't handle is when
> you actually discard parts, and I'm not sure at this point what other
> people should see there.
Yes. One small note of warning: different "diff" algorithms may under some
(mostly unlikely) circumstances result in different patches for the
difference between the same two files. So when comparin SHA1's of diffs
this way, you should also hopefully have the same diff generation
algorithm.
That's not likely to be a problem in practice, but it migh be something to
keep in mind as a _possible_ source of confusion, where a patch isn't
recognized only because it was generated differently from the one that we
compare against.
In practice, this can happen today with the "-C" and "-M" flags to diff,
of course: two patches look different (and get different SHA1 values) just
because one was generated with "rename logic" turned on and the other
wasn't..
> > Yeah. It probably works well in 99% of the cases to just do a simple
> > "export as patch" + "apply on top with old commit message, author and
> > author-date".
>
> I think that you'll get better results out of "merge with top" + "commit
> with old commit info, but not listing old commit as a parent".
If I understand you correctly, that assumes that you followed the whole
chain, though, and that there was no cherry-picking.
I'd like to keep the door open here for cherry-picking or other
transformations ("recreate tree _without_ that one commit"), because it
would seem to also be a potentially good way to clean up history, not
just move it forward, no?
Linus
^ permalink raw reply
* Re: Updated git HOWTO for kernel hackers
From: Miles Bader @ 2005-06-23 6:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Adam Kropelin, Jeff Garzik, Linux Kernel, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0506222146460.11175@ppc970.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> And if you have more than a few files dirty in your tree, I really think
> it's much better to do "git status" and think about it a bit and select
> the files you do want to commit than it is to just do "git commit" and let
> it rip.
>
> Now, I could well imagine adding an "--all" flag (and not even allow the
> shorthane version) to both git-update-cache and "git commit". So that you
> could say "commit all the dirty state", but you'd at least have to think
> about it before you did so.
I think both modes of operation are useful -- sometimes I want to hack
in the tree and later decide what to commit, and sometimes I know
exactly what sequence of commits I want to make and do a series of
"change-some-files then commit everything" steps.
In the latter case, it's very convenient to have commit just grab
everything and clear the slate for my next step. Morever, I use the
latter style enough that I think even the requirement of a long option
seems annoying and artificial; a short option would be fine though...
-Miles
--
Any man who is a triangle, has thee right, when in Cartesian Space, to
have angles, which when summed, come to know more, nor no less, than
nine score degrees, should he so wish. [TEMPLE OV THEE LEMUR]
^ permalink raw reply
* Re: Updated git HOWTO for kernel hackers
From: Greg KH @ 2005-06-23 6:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jeff Garzik, Linux Kernel, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0506222225010.11175@ppc970.osdl.org>
On Wed, Jun 22, 2005 at 10:58:13PM -0700, Linus Torvalds wrote:
> And I suggested that if you want that, then you pull on the TAG. You take
> my modification, you test it, and you see if
>
> git fetch tag ..repo.. tagname
>
> works.
Hm, that doesn't work right now. Both:
git fetch rsync://rsync.kernel.org/pub/scm/linux/kernel/git/chrisw/linux-2.6.12.y.git tag v2.6.12.1
or
git fetch tag rsync://rsync.kernel.org/pub/scm/linux/kernel/git/chrisw/linux-2.6.12.y.git v2.6.12.1
die. Or am I just trying to take a point you were making about not
pulling all tags (which I can live with, just was not aware it was this
way, and I agree that it does offer up a lot of possiblities of me using
local tags in the future), and taking it literally?
thanks,
greg k-h
^ permalink raw reply
* Re: Updated git HOWTO for kernel hackers
From: Linus Torvalds @ 2005-06-23 6:51 UTC (permalink / raw)
To: Greg KH; +Cc: Jeff Garzik, Linux Kernel, Git Mailing List
In-Reply-To: <20050623062045.GA11638@kroah.com>
On Wed, 22 Jun 2005, Greg KH wrote:
>
> Hm, that doesn't work right now.
Yeah, my suggested mod sucks.
Try the following slightly modified version instead, with
git fetch rsync://rsync.kernel.org/pub/scm/linux/kernel/git/chrisw/linux-2.6.12.y.git tag v2.6.12.1
and now it should work.
Linus
---
diff --git a/git-fetch-script b/git-fetch-script
--- a/git-fetch-script
+++ b/git-fetch-script
@@ -1,7 +1,13 @@
#!/bin/sh
#
+destination=FETCH_HEAD
+
merge_repo=$1
merge_name=${2:-HEAD}
+if [ "$2" = "tag" ]; then
+ merge_name="refs/tags/$3"
+ destination="$merge_name"
+fi
: ${GIT_DIR=.git}
: ${GIT_OBJECT_DIRECTORY="${SHA1_FILE_DIRECTORY-"$GIT_DIR/objects"}"}
@@ -35,7 +41,7 @@ download_objects () {
}
echo "Getting remote $merge_name"
-download_one "$merge_repo/$merge_name" "$GIT_DIR"/FETCH_HEAD || exit 1
+download_one "$merge_repo/$merge_name" "$GIT_DIR/$destination" || exit 1
echo "Getting object database"
-download_objects "$merge_repo" "$(cat "$GIT_DIR"/FETCH_HEAD)" || exit 1
+download_objects "$merge_repo" "$(cat "$GIT_DIR/$destination")" || exit 1
^ permalink raw reply
* Re: Updated git HOWTO for kernel hackers
From: Linus Torvalds @ 2005-06-23 6:37 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Adam Kropelin, Linux Kernel, Git Mailing List
In-Reply-To: <42BA4A29.7030601@pobox.com>
On Thu, 23 Jun 2005, Jeff Garzik wrote:
>
> Locally I have scripted
>
> git-diff-cache -p HEAD | diffstat -p1 | awk '{print $1}' > /tmp/lst
> git-update-cache `cat /tmp/lst`
>
> because of this.
Btw, that's some extremely convoluted computation.
This is exactly when you do _not_ want the diff in "patch" form, and you
really want the native git format (which is just a strange "this file
changed from this mode/sha1 to that mode/sha1" format).
So instead, try to do just
git-diff-cache HEAD | cut -f2
and now it's going to be a whole lot simpler and faster - it won't turn
things into a diff only to do a "diffstat" on it to turn it into a name
again. I bet it's more reliable too.
> [again, clearly doesn't work with remove/add/mode change]
Well, it actually can work with removes, and rewriting it to be a bit
more clean (and handle files that start with "-") gives you:
git-update-cache --remove -- $(git-diff-cache HEAD | cut -f2)
which should actually work fine for files that you have removed. But yes,
it fundamentally _cannot_ work for new files, of course, since git will
never even try to look for files you haven't told it about. So you always
have to add files by hand some way.
Note how the "--remove" parameter to git-update-cache really only means
"it's ok if some of the files mentioned don't exist any more, and that
means you should remove them from the cache".
Without the "--remove" flag, a filename that is listed but that doesn't
exist in the working tree is either considered an error, or is ignored
(depending on the "--ignore-missing" flag).
That's actually what "--add" means too: it means "it's ok if some of the
filenames on the command line don't currently exist in the index: if they
exist in the working directory, you should add them".
So even if it looks a bit strange, in a script it actually makes perfect
sense to write something that seems as _apparently_ senseless as:
git-update-cache --add --remove --refresh -- "$@"
and it will refresh all existing files, and add or remove any files
explicitly mentioned that either exist or have been removed in the working
directory.
Linus
^ permalink raw reply
* Re: Updated git HOWTO for kernel hackers
From: Jeff Garzik @ 2005-06-23 7:03 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Greg KH, Linux Kernel, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0506222225010.11175@ppc970.osdl.org>
Linus Torvalds wrote:
> Pulling a regular head _cannot_ and _must_not_ update tags. Tags are not
> associated with the tree, and they _cannot_ and _must_not_ be so, exactly
For general git implementation, strongly agreed.
> And not making them separate breaks a lot of things. As mentioned, it
> fundamentally breaks the distributed nature, but that also means that it
> breaks whenever two people use the same name for a tag, for example. You
> can't "merge" tags. BK had a very strange form of merging, which was (I
> think) to pick the one last in the BK ChangeSet file, but that didn't make
> it "right". You just never noticed, because Linux could never use tags at
> all due to the lack of privacy, except for big releases..
Agreed.
> How is this AT ALL different from just having a separate script that does
> this? You've introduced nothing but syntactic fluff, and you've made it
> less flexible at the same time. First off, you might want to get new tags
> _without_ fetching anything else, and you might indeed want to get the
> tags _first_ in order to decide what you want to fetch.
That's a fair point. A separate script would be better.
> because that would make them global instead of private, and it would
> fundamentally make them not be distributed, and would mean that they'd be
> pointless as anything but "Linus' official tags".
[...]
> the fact that tags _should_ be normal every-day things that you just use
> as "book-marks", and that the kind of big "synchronization point for many
> people" tag should actually be the _rare_ case.
For my use, I require all "Linus official tags" to be present in all my
kernel trees, precisely because it is a big sync point for many people.
User A sends me a patch against 2.6.12-rc2, user B sends me a patch
against 2.6.12-rc3, user C sends me a patch against 2.6.12... I create
a branch with
cp .git/refs/tags/$kversion .git/refs/heads/foo-net-drvr
git checkout -f foo-net-drvr
apply the patch, then pull linux-2.6.git to merge up to the latest version.
So in my case, the rare case is the 99% common case :)
I suppose this usage is just highly specific to me.
Jeff
^ permalink raw reply
* Re: Updated git HOWTO for kernel hackers
From: Jeff Garzik @ 2005-06-23 7:06 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0506221850030.11175@ppc970.osdl.org>
Linus Torvalds wrote:
> (Of course, since the rsync protocol doesn't know anything about git
> consistency, if the mirroring is half-way, you'll end up with something
> less than wonderful, and confusing. Details, details)
Would it make sense to add an fsck step to git-clone-script?
Jeff
^ permalink raw reply
* Re: Updated git HOWTO for kernel hackers
From: Jeff Garzik @ 2005-06-23 7:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0506221915280.11175@ppc970.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 1427 bytes --]
Linus Torvalds wrote:
> How about this patch? Then you can say
>
> git-apply --stat --summary --apply --index /tmp/my.patch
>
> and it will not only apply the patch, but also give a diffstat and a
> summary or renames etc..
Quite nice.
>>I usually want just two things:
>>
>>1) browse the log
>>
>>2) list changes in local tree that are not in $remote_tree, a la
>> bk changes -L ../linux-2.6
>>
>>I agree that seeing the merge csets is useful, that is why [being
>>ignorant of 'git log'] I used git-changes-script.
>
>
> For (1) "bk log" is good.
Chuckle. What does one call a Freudian slip, in computer-land?
> For (2) you'll have to use your own script, or
> just have the remote tree as a branch in the same tree, in which case you
> can do
>
> git log remotebranch..mybranch
Very neat. That makes some things a bit easier, since I usually carry a
'vanilla' branch as .git/refs/heads/master, and do all my modifications
on other branches.
FWIW, git-changes-script (attached) facilitates #2 for me right now. I
use it just like BK's '-L' feature:
cd netdev-2.6
git checkout -f ieee80211
git-changes-script -L ../linux-2.6 | less
That will produce the same output as the feature you just taught me,
git log master..ieee80211
WARNING: You have previously called git-changes-script quite ugly (not
surprising), and this 'git log x..y' will probably replace it in my
usage, long term.
Jeff
[-- Attachment #2: git-changes-script --]
[-- Type: text/plain, Size: 2373 bytes --]
#!/bin/bash
#
# Make a log of changes in a GIT branch.
#
# This script was originally written by (c) Ross Vandegrift.
# Adapted to his scripts set by (c) Petr Baudis, 2005.
# Major optimizations by (c) Phillip Lougher.
# Rendered trivial by Linus Torvalds.
# Added -L|-R option by James Bottomley
#
# options:
# script [-L <dir> | -R <dir> |-r <from_sha1> [ -r <to_sha1] ] [<sha1>]
#
# With no options shows all the revisions from HEAD to the root
# -L shows all the changes in the local tree compared to the tree at <dir>
# -R shows all the changes in the remote tree at <dir> compared to the local
# -r shows all the changes in one commit or between two
tmpfile=/tmp/git_changes.$$
r1=
r2=
showcommit() {
commit="$1"
echo commit ${commit%:*};
git-cat-file commit $commit | \
while read key rest; do
case "$key" in
"author"|"committer")
date=(${rest#*> })
sec=${date[0]}; tz=${date[1]}
dtz=${tz/+/+ }; dtz=${dtz/-/- }
pdate="$(date -Rud "1970-01-01 UTC + $sec sec $dtz" 2>/dev/null)"
if [ "$pdate" ]; then
echo $key $rest | sed "s/>.*/> ${pdate/+0000/$tz}/"
else
echo $key $rest
fi
;;
"")
echo; cat
;;
*)
echo $key $rest
;;
esac
done
}
while true; do
case "$1" in
-R) shift;
diffsearch=+
remote="$1"
shift;;
-L) shift;
diffsearch=-
remote="$1"
shift;;
-r) shift;
if [ -z "$r1" ]; then
r1="$1"
else
r2="$1"
fi
shift;;
*) base="$1"
break;;
esac
done
if [ -n "$r1" ]; then
if [ -z "$r2" ]; then
showcommit $r1
exit 0
fi
diffsearch=+
remote=`pwd`;
tobase="$r2";
base="$r1"
fi
if [ -z "$base" ]; then
base=$(cat .git/HEAD) || exit 1
fi
git-rev-tree $base | sort -rn > ${tmpfile}.base
if [ -n "$remote" ]; then
[ -d $remote/.git ] || exit 1
if [ -z "$tobase" ]; then
tobase=$(cat $remote/.git/HEAD) || exit 1
fi
pushd $remote > /dev/null
git-rev-tree $tobase | sort -rn > ${tmpfile}.remote
diff -u ${tmpfile}.base ${tmpfile}.remote | grep "^${diffsearch}[^${diffsearch}]" | cut -c 1- > ${tmpfile}.diff
rm -f ${tmpfile}.base ${tmpfile}.remote
mv ${tmpfile}.diff ${tmpfile}.base
if [ $diffsearch = "-" ]; then
popd > /dev/null
fi
fi
[ -s "${tmpfile}.base" ] || exit 0
cat ${tmpfile}.base | while read time commit parents; do
showcommit $commit
echo -e "\n--------------------------"
done
rm -f ${tmpfile}.base
^ permalink raw reply
* Re: Updated git HOWTO for kernel hackers
From: Greg KH @ 2005-06-23 7:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jeff Garzik, Linux Kernel, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0506222338290.11175@ppc970.osdl.org>
On Wed, Jun 22, 2005 at 11:51:40PM -0700, Linus Torvalds wrote:
>
>
> On Wed, 22 Jun 2005, Greg KH wrote:
> >
> > Hm, that doesn't work right now.
>
> Yeah, my suggested mod sucks.
>
> Try the following slightly modified version instead, with
>
> git fetch rsync://rsync.kernel.org/pub/scm/linux/kernel/git/chrisw/linux-2.6.12.y.git tag v2.6.12.1
>
> and now it should work.
Yes, that patch works for me.
thanks,
greg k-h
^ permalink raw reply
* 'dotest' fails, patch(1) succeeds
From: Jeff Garzik @ 2005-06-23 7:37 UTC (permalink / raw)
To: Linus Torvalds, Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 450 bytes --]
Trying to use git-tools' "dotest" script to merge an mbox into a kernel
git repo failed, but patch(1) was OK with it:
[jgarzik@pretzel netdev-2.6]$ dotest /g/tmp/mbox
Applying 'e1000: fix spinlock bug'
fatal: corrupt patch at line 10
[jgarzik@pretzel netdev-2.6]$ patch -sp1 < /g/tmp/mbox
[jgarzik@pretzel netdev-2.6]$
Ideas? Full data needed to reproduce is attached. .git/HEAD is
a4936044001694f033fe4ea94d6034d51a6b465c.
Jeff
[-- Attachment #2: mbox.bz2 --]
[-- Type: application/x-bzip2, Size: 1755 bytes --]
^ permalink raw reply
* Re: Updated git HOWTO for kernel hackers
From: Petr Baudis @ 2005-06-23 7:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jeff Garzik, Greg KH, Linux Kernel, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0506222225010.11175@ppc970.osdl.org>
Dear diary, on Thu, Jun 23, 2005 at 07:58:13AM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
> Does it help when I scream?
Nope. I still think you are wrong. :-) (BTW, Cogito always fetches all
the tags now - but it's not that I would have a huge problem with
changing that to some better behaviour.)
> > Multiple users -- not just me -- would prefer that git-pull-script
> > pulled the tags, too.
>
> And multiple users -- clearly including you -- aren't listening to me.
> Tags are separate from the source they tag, and they HAVE TO BE. There is
> no "you automatically get the tags when you get the tree", because the two
> don't have a 1:1 relationship.
>
> And not making them separate breaks a lot of things. As mentioned, it
> fundamentally breaks the distributed nature, but that also means that it
> breaks whenever two people use the same name for a tag, for example. You
> can't "merge" tags. BK had a very strange form of merging, which was (I
> think) to pick the one last in the BK ChangeSet file, but that didn't make
> it "right". You just never noticed, because Linux could never use tags at
> all due to the lack of privacy, except for big releases..
I think there should simply be two namespaces - public tags and private
tags. Private tags for stuff like "broken", "merged", or "funnychange".
Other people don't care about those, and they certainly shouldn't get
them by default (but they should have a way to get them explicitly, if
you tell them). But then there are the official tags, like "v2.6.13" or
even "v2.6.12-ck2" - if you merge with those branches, you should always
get those precisely for what Jeff says - they are big syncing points for
a lot of people and you should be always able to refer to v2.6.13 if you
have the commit in your tree.
Since there should be _few_ of those tags, you might even want to get
tags only from branches marked "tagtrusted" (Cogito's origin branch
would be by default), or want to interactively confirm new tag additions
during a pull. Also, ideally there would be no or only extremely rare
tag conflicts.
I think it would be simplest to use a special prefix for the private
tags. ~ and ! might get touched by shell, so what about %?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
<Espy> be careful, some twit might quote you out of context..
^ permalink raw reply
* Re: Updated git HOWTO for kernel hackers
From: Anton Altaparmakov @ 2005-06-23 8:01 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jeff Garzik, Linux Kernel, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0506221603120.11175@ppc970.osdl.org>
On Wed, 22 Jun 2005, Linus Torvalds wrote:
> On Wed, 22 Jun 2005, Jeff Garzik wrote:
> > 2) download a linux kernel tree for the very first time
> >
> > $ mkdir -p linux-2.6/.git
> > $ cd linux-2.6
> > $ rsync -a --delete --verbose --stats --progress \
> > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
> > \ <- word-wrapped backslash; sigh
> > .git/
>
> Gaah. I should do a "git-clone-script" or something that does this, and
> then you could just do
>
> git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
>
> Anybody?
What's wrong with Pasky's cogito scripts? There is a cg-pull as well as a
cg-clone in there already. If nothing else you could just copy the
relevant scripts and rename them to git-blah...
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox