* Re: Updated git HOWTO for kernel hackers
From: Dave Jones @ 2005-06-22 22:40 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linux Kernel, Git Mailing List
In-Reply-To: <42B9E536.60704@pobox.com>
On Wed, Jun 22, 2005 at 06:24:54PM -0400, Jeff Garzik wrote:
>
> Things in git-land are moving at lightning speed, and usability has
> improved a lot since my post a month ago: http://lkml.org/lkml/2005/5/26/11
>
>
>
> 1) installing git
>
> git requires bootstrapping, since you must have git installed in order
> to check out git.git (git repo), and linux-2.6.git (kernel repo). I
> have put together a bootstrap tarball of today's git repository.
>
> Download tarball from:
> http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-20050622.tar.bz2
<blatant self-promotion>
daily snapshots (refreshed once an hour) are available at:
http://www.codemonkey.org.uk/projects/git-snapshots/git/
</blatant self-promotion>
> tarball build-deps: zlib, libcurl, libcrypto (openssl)
>
> install tarball: unpack && make && sudo make prefix=/usr/local install
the sudo thing isn't necessary. make install by itself installs it
in ~/bin/ just fine.
> After reading the rest of this document, come back and update your copy
> of git to the latest:
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git
See above, which allows you to skip this step ;)
Dave
^ permalink raw reply
* Re: Updated git HOWTO for kernel hackers
From: Jeff Garzik @ 2005-06-22 22:47 UTC (permalink / raw)
To: Dave Jones; +Cc: Linux Kernel, Git Mailing List
In-Reply-To: <20050622224003.GA21298@redhat.com>
Dave Jones wrote:
> On Wed, Jun 22, 2005 at 06:24:54PM -0400, Jeff Garzik wrote:
> >
> > Things in git-land are moving at lightning speed, and usability has
> > improved a lot since my post a month ago: http://lkml.org/lkml/2005/5/26/11
> >
> >
> >
> > 1) installing git
> >
> > git requires bootstrapping, since you must have git installed in order
> > to check out git.git (git repo), and linux-2.6.git (kernel repo). I
> > have put together a bootstrap tarball of today's git repository.
> >
> > Download tarball from:
> > http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-20050622.tar.bz2
>
> <blatant self-promotion>
> daily snapshots (refreshed once an hour) are available at:
> http://www.codemonkey.org.uk/projects/git-snapshots/git/
> </blatant self-promotion>
>
> > tarball build-deps: zlib, libcurl, libcrypto (openssl)
> >
> > install tarball: unpack && make && sudo make prefix=/usr/local install
>
> the sudo thing isn't necessary. make install by itself installs it
> in ~/bin/ just fine.
Clearly this does not work if installing in /usr/local, as I and others
do (and as the example shows).
> > After reading the rest of this document, come back and update your copy
> > of git to the latest:
> > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git
>
> See above, which allows you to skip this step ;)
huh? Nothing allows you to skip that step. Regardless of when you suck
the tarball, even from your snapshots, the users should not skip this step.
Jeff
^ permalink raw reply
* Re: Updated git HOWTO for kernel hackers
From: Dave Jones @ 2005-06-22 22:52 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linux Kernel, Git Mailing List
In-Reply-To: <42B9EA67.1040407@pobox.com>
On Wed, Jun 22, 2005 at 06:47:03PM -0400, Jeff Garzik wrote:
> > > install tarball: unpack && make && sudo make prefix=/usr/local install
> >
> >the sudo thing isn't necessary. make install by itself installs it
> >in ~/bin/ just fine.
>
> Clearly this does not work if installing in /usr/local, as I and others
> do (and as the example shows).
Sure, it just seemed to imply that it doesn't work with a non-root install,
which isn't true.
> > > After reading the rest of this document, come back and update your copy
> > > of git to the latest:
> > > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git
> >
> >See above, which allows you to skip this step ;)
>
> huh? Nothing allows you to skip that step. Regardless of when you suck
> the tarball, even from your snapshots, the users should not skip this step.
At worse, users will have tools 59 minutes old. If a situation arises
where git from an hour ago isn't new enough to pull from the repository,
we have bigger problems.
You seem to be proposing that everyone needs the shiniest newest things,
which clearly isn't true, and suggesting so just complicates things
further imo.
Dave
^ permalink raw reply
* Re: Updated git HOWTO for kernel hackers
From: Greg KH @ 2005-06-22 23:09 UTC (permalink / raw)
To: Jeff Garzik, torvalds; +Cc: Linux Kernel, Git Mailing List
In-Reply-To: <42B9E536.60704@pobox.com>
On Wed, Jun 22, 2005 at 06:24:54PM -0400, Jeff Garzik wrote:
> 10) don't forget to download tags from time to time.
>
> git-pull-script only downloads sha1-indexed object data, and the
> requested remote head. This misses updates to the .git/refs/tags/ and
> .git/refs/heads directories. It is advisable to update your kernel .git
> directories periodically with a full rsync command, to make sure you got
> everything:
>
> $ 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/
Ok, this is annoying. 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.
thanks,
greg k-h
^ permalink raw reply
* Re: Updated git HOWTO for kernel hackers
From: Linus Torvalds @ 2005-06-22 23:16 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:
>
> 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?
> # 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>
>
> # check in changes
> $ git commit
A few notes on these things:
git-apply --index /tmp/my.patch
will not only apply the patch (unified patches only!), but will do the
index updates for you while it's at it, so if the patch contains new files
(or it deletes files), you don't need to worry about it.
Also, you can do
git commit <list-of-files-to-commit>
as a shorthand for
git-update-cache <list-of-files-to-commit>
git commit
which some people will probably find more natural.
> 6) List all changes in working dir, in diff format.
>
> $ git-diff-cache -p HEAD
Or, perhaps preferably:
git diff HEAD
since that is shorter ad will also show renames.
> 8) List all changesets:
>
> $ git-whatchanged
No, if you just want the changesets listed, then
git log
is a lot better, since it shows merges.
"git-whatchanged" is useful if you actually want to see what the commits
_changed_, and then you often want to use the "-p" flag to see it as
patches. Also, it's worth pointing out the fact that you can limit it to
certain subdirectories (or individual files) etc, ie:
git-whatchanged -p drivers/net
since that is often what people want.
But if you just want the log, "git log" is faster and simpler and more
correct.
> 16) obtain a diff between current branch, and master branch
>
> In most trees WITH BRANCHES, .git/refs/heads/master contains the current
> 'vanilla' upstream tree, for easy diffing and merging. (in trees
> without branches, 'master' simply contains your latest changes)
>
> $ git-diff-tree -p master HEAD
Again, I think is possibly more naturally expressed with "git diff":
git diff master..HEAD
which just says "show the differences from 'master' to 'HEAD'" and will
also show renames etc.
(A plain "git diff" will show just the difference to the index file, in
case you care).
Linus
^ permalink raw reply
* Re: Updated git HOWTO for kernel hackers
From: Linus Torvalds @ 2005-06-22 23:25 UTC (permalink / raw)
To: Greg KH; +Cc: Jeff Garzik, Linux Kernel, Git Mailing List
In-Reply-To: <20050622230905.GA7873@kroah.com>
On Wed, 22 Jun 2005, Greg KH wrote:
>
> Ok, this is annoying. 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.
Tags are private in git (the same way branches are), which means that you
can have a million of your own tags and never disturb anybody else.
But, like branches, it means that if you want a tag, you need to know the
tag you want, and download it the same way you download a branch.
Linus
^ permalink raw reply
* Re: Updated git HOWTO for kernel hackers
From: Jeff Garzik @ 2005-06-23 0:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Greg KH, Linux Kernel, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0506221623210.11175@ppc970.osdl.org>
Linus Torvalds wrote:
>
> On Wed, 22 Jun 2005, Greg KH wrote:
>
>>Ok, this is annoying. 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.
>
>
> Tags are private in git (the same way branches are), which means that you
> can have a million of your own tags and never disturb anybody else.
>
> But, like branches, it means that if you want a tag, you need to know the
> tag you want, and download it the same way you download a branch.
Still -- that's interesting data that no script currently tracks. You
gotta fall back to rsync.
Jeff
^ permalink raw reply
* Re: Updated git HOWTO for kernel hackers
From: Jeff Garzik @ 2005-06-23 0:14 UTC (permalink / raw)
To: Dave Jones; +Cc: Linux Kernel, Git Mailing List
In-Reply-To: <20050622225255.GB21298@redhat.com>
Dave Jones wrote:
> At worse, users will have tools 59 minutes old. If a situation arises
> where git from an hour ago isn't new enough to pull from the repository,
> we have bigger problems.
>
> You seem to be proposing that everyone needs the shiniest newest things,
> which clearly isn't true, and suggesting so just complicates things
> further imo.
For the purposes of the these instructions, it is highly recommended.
However, I was unaware that your snapshots were updated hourly. Yeah,
that's quite fine.
Jeff
^ permalink raw reply
* Re: The coolest merge EVER!
From: Jon Seymour @ 2005-06-23 0:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0506221433540.2353@ppc970.osdl.org>
On 6/23/05, Linus Torvalds <torvalds@osdl.org> wrote:
>
> Ok, Junio had some cool octopus merges, but I just one-upped him.
>
> I just merged the "gitk" repository into git, and I did it as a real git
> merge, which means that I actually retained all the original gitk
> repository information intact. IOW, it's not a "import the data" thing,
> it's literally a merge of the two trees, and the result has two roots.
>
> Now, the advantage of this kind of merge is that Paul's original gitk
> repository is totally unaffected by it, yet because I now have his history
> (and the exact same objects), the normal kind of git merge should work
> fine for me to continue to import Paul's work - we have the common parent
> needed to resolve all differences.
>
You do realise what this means, don't you?
The Borg can now start accumulating software into one massive
repository of everything ever written and it will never forget -
resistance will be futile.
Of course, it may run out of disk space.
jon.
^ permalink raw reply
* Re: Updated git HOWTO for kernel hackers
From: Jeff Garzik @ 2005-06-23 0:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0506221603120.11175@ppc970.osdl.org>
Linus Torvalds wrote:
[snip]
Thanks, this is all good stuff. I'll update it and post another, in a
few days or so.
git-clone-script would indeed be nice, even if its only a 2-line script.
Jeff
^ permalink raw reply
* Re: The coolest merge EVER!
From: Jeff Garzik @ 2005-06-23 0:24 UTC (permalink / raw)
To: jon; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <2cfc4032050622171258636771@mail.gmail.com>
Jon Seymour wrote:
> You do realise what this means, don't you?
>
> The Borg can now start accumulating software into one massive
> repository of everything ever written and it will never forget -
> resistance will be futile.
>
> Of course, it may run out of disk space.
The kernel.org robots will melt before that happens :)
git has already increased the kernel.org file publish time over an hour.
Hopefully inotify and an improved rsync will fix some of that.
Jeff
^ permalink raw reply
* Re: Updated git HOWTO for kernel hackers
From: Linus Torvalds @ 2005-06-23 0:29 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Greg KH, Linux Kernel, Git Mailing List
In-Reply-To: <42B9FCAE.1000607@pobox.com>
On Wed, 22 Jun 2005, Jeff Garzik wrote:
>
> > But, like branches, it means that if you want a tag, you need to know the
> > tag you want, and download it the same way you download a branch.
>
> Still -- that's interesting data that no script currently tracks. You
> gotta fall back to rsync.
Something like
git-ssh/http-pull -w tags/<tagname> tags/<tagname> <url>
_should_ hopefully work now (and the "-a" flag should mean that you also
get all the objects needed for the tag).
I've not tested it, as usual, but it should work as of today thanks to
Daniel Barkalow fixing the pulling of arbitrary objects.
Linus
^ permalink raw reply
* Re: Updated git HOWTO for kernel hackers
From: Linus Torvalds @ 2005-06-23 0:33 UTC (permalink / raw)
To: Jeff Garzik; +Cc: 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:
>
> A few notes on these things:
>
> git-apply --index /tmp/my.patch
>
> will not only apply the patch (unified patches only!), but will do the
> index updates for you while it's at it, so if the patch contains new files
> (or it deletes files), you don't need to worry about it.
Btw, if the patch contains rename/copy-patches or mode updates, you _need_
to use git-apply, since regular "patch" doesn't know about file modes and
can't handle file renames or copies.
Now, the rename/copy patches are easy to avoid by just not asking git to
generate them (so they'll show up as just straight file creates, with a
delete of the old file for a rename), but the file mode part in particular
is useful as more than just a way to create smaller (and more
human-readable) patches.
Linus
^ permalink raw reply
* Re: git testsuite failures
From: Jon Seymour @ 2005-06-23 0:54 UTC (permalink / raw)
To: David S. Miller; +Cc: git
In-Reply-To: <20050622.121835.78708158.davem@davemloft.net>
I posted a fix for this yesterday. The break was caused by a change in
behaviour of parse_commit that the --merge-order stuff was dependent
on. Now that parse_commit is sane, the --merge-order stuff needs to be
made sane too.
The fix was in this patch.
[PATCH 1/1] Fix --merge-order unit test breaks introduced by
6c88be169881c9223532796bd225e79afaa115e1
jon.
^ permalink raw reply
* Re: git testsuite failures
From: Linus Torvalds @ 2005-06-23 0:59 UTC (permalink / raw)
To: David S. Miller; +Cc: git
In-Reply-To: <20050622.121835.78708158.davem@davemloft.net>
On Wed, 22 Jun 2005, David S. Miller wrote:
>
> There are test cases failing in the testsuite over the
> past few days, is this expected?
Fixed now. It was the parent ordering cleanup that broke an assumption
about parents being in reverse order in the rev-list "epoch" code. I
checked in the fix from Jon,
Linus
^ permalink raw reply
* Re: Updated git HOWTO for kernel hackers
From: Jeff Garzik @ 2005-06-23 1:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Greg KH, Linux Kernel, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0506221724140.11175@ppc970.osdl.org>
Linus Torvalds wrote:
>
> On Wed, 22 Jun 2005, Jeff Garzik wrote:
>
>>>But, like branches, it means that if you want a tag, you need to know the
>>>tag you want, and download it the same way you download a branch.
>>
>>Still -- that's interesting data that no script currently tracks. You
>>gotta fall back to rsync.
>
>
> Something like
>
> git-ssh/http-pull -w tags/<tagname> tags/<tagname> <url>
>
> _should_ hopefully work now (and the "-a" flag should mean that you also
> get all the objects needed for the tag).
The problem isn't pulling tags, the problem is that nothing
automatically downloads the 41-byte tag files themselves. Pulling
linux-2.6.git after the 2.6.12 release did not cause refs/tags/v2.6.12
to be downloaded.
With BK, tags came with each pull. With git, you have to go "outside
the system" (rsync) just get the new tags.
Jeff
^ permalink raw reply
* Re: Updated git HOWTO for kernel hackers
From: Linus Torvalds @ 2005-06-23 1:53 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linux Kernel, Git Mailing List
In-Reply-To: <42B9FF3A.4010700@pobox.com>
On Wed, 22 Jun 2005, Jeff Garzik wrote:
>
> git-clone-script would indeed be nice, even if its only a 2-line script.
Ok, added. You can update your tutorial to make the initial setup of a
kernel archive slightly less scary, ie it's now
git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
cd linux-2.6
git checkout
which looks almost user-friendly.
(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)
Linus
^ permalink raw reply
* Re: Updated git HOWTO for kernel hackers
From: Linus Torvalds @ 2005-06-23 1:56 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Greg KH, Linux Kernel, Git Mailing List
In-Reply-To: <42BA14B8.2020609@pobox.com>
On Wed, 22 Jun 2005, Jeff Garzik wrote:
>
> With BK, tags came with each pull. With git, you have to go "outside
> the system" (rsync) just get the new tags.
You don't have to use rsync, and you don't have to go outside the system.
That was my point: you can use "git-ssh-pull" to pull the tags.
But yes, you have to explicitly ask for them by name, ie the other side
has to let you know: "Oh, btw, I created a 'xyz' tag for you". And having
another helper script to hide the details of how git-*-pull handles tags
is obviously also a good idea, although it's pretty low on my list of
things to worry about.
Linus
^ permalink raw reply
* [PATCH 2/2] Fix to how --merge-order handles multiple roots
From: Jon Seymour @ 2005-06-23 2:01 UTC (permalink / raw)
To: git; +Cc: torvalds, jon.seymour, paulus
This patch addresses the problem reported by Paul Mackerras such that --merge-order
did not report the last root of a graph with merge of two independent roots.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
---
epoch.c | 11 +++++++----
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/epoch.c b/epoch.c
--- a/epoch.c
+++ b/epoch.c
@@ -488,7 +488,7 @@ static void sort_first_epoch(struct comm
*
* Sets the return value to STOP if no further output should be generated.
*/
-static int emit_stack(struct commit_list **stack, emitter_func emitter)
+static int emit_stack(struct commit_list **stack, emitter_func emitter, int include_last)
{
unsigned int seen = 0;
int action = CONTINUE;
@@ -496,8 +496,11 @@ static int emit_stack(struct commit_list
while (*stack && (action != STOP)) {
struct commit *next = pop_commit(stack);
seen |= next->object.flags;
- if (*stack)
+ if (*stack || include_last) {
+ if (!*stack)
+ next->object.flags |= BOUNDARY;
action = (*emitter) (next);
+ }
}
if (*stack) {
@@ -553,7 +556,7 @@ static int sort_in_merge_order(struct co
} else {
struct commit_list *stack = NULL;
sort_first_epoch(next, &stack);
- action = emit_stack(&stack, emitter);
+ action = emit_stack(&stack, emitter, (base == NULL));
next = base;
}
}
@@ -636,7 +639,7 @@ int sort_list_in_merge_order(struct comm
}
}
- action = emit_stack(&stack, emitter);
+ action = emit_stack(&stack, emitter, (base==NULL));
}
if (base && (action != STOP)) {
------------
^ permalink raw reply
* Re: Updated git HOWTO for kernel hackers
From: Jeff Garzik @ 2005-06-23 2:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0506221603120.11175@ppc970.osdl.org>
Linus Torvalds wrote:
> A few notes on these things:
>
> git-apply --index /tmp/my.patch
>
> will not only apply the patch (unified patches only!), but will do the
> index updates for you while it's at it, so if the patch contains new files
> (or it deletes files), you don't need to worry about it.
The output isn't terribly helpful:
[jgarzik@pretzel netdev-2.6]$ git apply --index \
~/tmp/linux-2.6.12-rc4-cxgb2.1.1.patch
Fragment applied at offset 11
That is worse than no message at all... fragment? offset 11? did it
work? Did it apply only a "fragment" of my patch, not the whole thing?
I'm worried! </mental monologue>
Outputting the following (stolen from 'git commit') would be far more
useful:
modified: Documentation/networking/cxgb.txt
modified: drivers/net/chelsio/Makefile
deleted: drivers/net/chelsio/ch_ethtool.h
modified: drivers/net/chelsio/common.h
modified: drivers/net/chelsio/cphy.h
modified: drivers/net/chelsio/cpl5_cmd.h
modified: drivers/net/chelsio/cxgb2.c
deleted: drivers/net/chelsio/cxgb2.h
modified: drivers/net/chelsio/elmer0.h
modified: drivers/net/chelsio/espi.c
modified: drivers/net/chelsio/espi.h
modified: drivers/net/chelsio/gmac.h
modified: drivers/net/chelsio/mv88x201x.c
deleted: drivers/net/chelsio/osdep.h
modified: drivers/net/chelsio/pm3393.c
modified: drivers/net/chelsio/regs.h
modified: drivers/net/chelsio/sge.c
modified: drivers/net/chelsio/sge.h
modified: drivers/net/chelsio/subr.c
modified: drivers/net/chelsio/suni1x10gexp_regs.h
deleted: drivers/net/chelsio/tp.c
deleted: drivers/net/chelsio/tp.h
modified: include/linux/pci_ids.h
> Also, you can do
>
> git commit <list-of-files-to-commit>
>
> as a shorthand for
>
> git-update-cache <list-of-files-to-commit>
> git commit
>
> which some people will probably find more natural.
It would be natural if it functioned like 'bk citool' ;-)
git commit --figure-out-for-me-what-files-changed
'git diff' can do this, so it's certainly feasible.
Obviously added/removed files would still require git-update-cache or
git-commit<list of files>.
> "git-whatchanged" is useful if you actually want to see what the commits
> _changed_, and then you often want to use the "-p" flag to see it as
> patches. Also, it's worth pointing out the fact that you can limit it to
> certain subdirectories (or individual files) etc, ie:
>
> git-whatchanged -p drivers/net
>
> since that is often what people want.
>
> But if you just want the log, "git log" is faster and simpler and more
> correct.
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.
Jeff
^ permalink raw reply
* Re: git-prune-script eats data
From: Linus Torvalds @ 2005-06-23 2:04 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Git Mailing List
In-Reply-To: <42B8B629.1040208@pobox.com>
On Tue, 21 Jun 2005, Jeff Garzik wrote:
>
> $ git-prune-script
>
> $ git-fsck-cache
> error: cannot map sha1 file c39ae07f393806ccf406ef966e9a15afc43cc36a
> bad object in tag 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c
> bad sha1 entry '5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c'
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.
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_.
"git prune" normally never removes tag-objects, whether reachable or not.
That's because git-fsck-cache was explicitly ignoring them, which was
because early on, the way you found tags was you did
git-fsck-cache --tags
and then you created refs to them manually.
But now that special case causes problems (and is no longer needed
anyway), because it means that "git prune" will not remove unreachable
tags, but it _will_ remove everything that an unreachable tag points to
(because that is also unreachable).
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.
Will do.
Linus
^ permalink raw reply
* [PATCH 1/2] A test case that demonstrates a problem with merges with two roots.
From: Jon Seymour @ 2005-06-23 2:01 UTC (permalink / raw)
To: git; +Cc: torvalds, jon.seymour, paulus
git-rev-list --merge-order is omitting one of the roots when
displaying a merge containing two distinct roots.
A subsequent patch will fix the problem.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
---
t/t6001-rev-list-merge-order.sh | 61 +++++++++++++++++++++++++++++++++++++++
1 files changed, 61 insertions(+), 0 deletions(-)
diff --git a/t/t6001-rev-list-merge-order.sh b/t/t6001-rev-list-merge-order.sh
old mode 100644
new mode 100755
--- a/t/t6001-rev-list-merge-order.sh
+++ b/t/t6001-rev-list-merge-order.sh
@@ -172,6 +172,13 @@ on_committer_date "1971-08-16 00:00:17"
on_committer_date "1971-08-16 00:00:18" save_tag l5 unique_commit l5 tree -p l4
on_committer_date "1971-08-16 00:00:19" save_tag m1 unique_commit m1 tree -p a4 -p c3
on_committer_date "1971-08-16 00:00:20" save_tag m2 unique_commit m2 tree -p c3 -p a4
+on_committer_date "1971-08-16 00:00:21" hide_error save_tag alt_root unique_commit alt_root tree
+on_committer_date "1971-08-16 00:00:22" save_tag r0 unique_commit r0 tree -p alt_root
+on_committer_date "1971-08-16 00:00:23" save_tag r1 unique_commit r1 tree -p r0
+on_committer_date "1971-08-16 00:00:24" save_tag l5r1 unique_commit l5r1 tree -p l5 -p r1
+on_committer_date "1971-08-16 00:00:25" save_tag r1l5 unique_commit r1l5 tree -p r1 -p l5
+
+
#
# note: as of 20/6, it isn't possible to create duplicate parents, so this
# can't be tested.
@@ -483,6 +490,60 @@ EOF
test_expect_success "head ^head no --merge-order" 'git-rev-list a3 ^a3' <<EOF
EOF
+
+test_output_expect_success 'simple merge order (l5r1)' 'git-rev-list --merge-order --show-breaks l5r1' <<EOF
+= l5r1
+| r1
+| r0
+| alt_root
+^ l5
+| l4
+| l3
+| a4
+| c3
+| c2
+| c1
+^ b4
+| b3
+| b2
+| b1
+^ a3
+| a2
+| a1
+| a0
+| l2
+| l1
+| l0
+= root
+EOF
+
+test_output_expect_success 'simple merge order (r1l5)' 'git-rev-list --merge-order --show-breaks r1l5' <<EOF
+= r1l5
+| l5
+| l4
+| l3
+| a4
+| c3
+| c2
+| c1
+^ b4
+| b3
+| b2
+| b1
+^ a3
+| a2
+| a1
+| a0
+| l2
+| l1
+| l0
+| root
+^ r1
+| r0
+= alt_root
+EOF
+
+
#
#
------------
^ permalink raw reply
* Re: Updated git HOWTO for kernel hackers
From: Jeff Garzik @ 2005-06-23 2:16 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Greg KH, Linux Kernel, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0506221853280.11175@ppc970.osdl.org>
Linus Torvalds wrote:
>
> On Wed, 22 Jun 2005, Jeff Garzik wrote:
>
>>With BK, tags came with each pull. With git, you have to go "outside
>>the system" (rsync) just get the new tags.
>
>
> You don't have to use rsync, and you don't have to go outside the system.
> That was my point: you can use "git-ssh-pull" to pull the tags.
OK, understood.
> But yes, you have to explicitly ask for them by name, ie the other side
> has to let you know: "Oh, btw, I created a 'xyz' tag for you". And having
> another helper script to hide the details of how git-*-pull handles tags
> is obviously also a good idea, although it's pretty low on my list of
> things to worry about.
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).
Asking for the tag by name isn't useful at all, in that regard, because
that requires that the user already know what tags are available. To
get that info, one must use rsync, gitweb, or a subscription to Psychic
Friends Network.
Jeff
^ permalink raw reply
* Re: Updated git HOWTO for kernel hackers
From: Linus Torvalds @ 2005-06-23 2:28 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linux Kernel, Git Mailing List
In-Reply-To: <42BA18AF.2070406@pobox.com>
On Wed, 22 Jun 2005, Jeff Garzik wrote:
>
> The output isn't terribly helpful:
Yeah. The good news is that if something bad happens, it surely lets you
know, and it's very verbose about that.
I should probably remove the "Fragment applied at offset xx" thing, it was
basically a debugging message to make sure that I applied patch fragments
correctly even if the line offset given in the patch was sligthly off..
> Outputting the following (stolen from 'git commit') would be far more
> useful:
>
> modified: Documentation/networking/cxgb.txt
> modified: drivers/net/chelsio/Makefile
> deleted: drivers/net/chelsio/ch_ethtool.h
> modified: drivers/net/chelsio/common.h
> modified: drivers/net/chelsio/cphy.h
> modified: drivers/net/chelsio/cpl5_cmd.h
> modified: drivers/net/chelsio/cxgb2.c
> deleted: drivers/net/chelsio/cxgb2.h
> modified: drivers/net/chelsio/elmer0.h
> modified: drivers/net/chelsio/espi.c
> modified: drivers/net/chelsio/espi.h
> modified: drivers/net/chelsio/gmac.h
> modified: drivers/net/chelsio/mv88x201x.c
> deleted: drivers/net/chelsio/osdep.h
> modified: drivers/net/chelsio/pm3393.c
> modified: drivers/net/chelsio/regs.h
> modified: drivers/net/chelsio/sge.c
> modified: drivers/net/chelsio/sge.h
> modified: drivers/net/chelsio/subr.c
> modified: drivers/net/chelsio/suni1x10gexp_regs.h
> deleted: drivers/net/chelsio/tp.c
> deleted: drivers/net/chelsio/tp.h
> modified: include/linux/pci_ids.h
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..
This also removes the "Fragment.." debugging message.
Btw, "--stat" and "--summary" normally turn off the "apply" flag, so
"--apply" has to come _after_ the stat/summary thing, fwiw:
diff --git a/apply.c b/apply.c
--- a/apply.c
+++ b/apply.c
@@ -860,7 +860,6 @@ static int find_offset(const char *buf,
n = (i >> 1)+1;
if (i & 1)
n = -n;
- fprintf(stderr, "Fragment applied at offset %d\n", n);
return try;
}
@@ -1434,6 +1433,10 @@ int main(int argc, char **argv)
check_index = 1;
continue;
}
+ if (!strcmp(arg, "--apply")) {
+ apply = 1;
+ continue;
+ }
if (!strcmp(arg, "--show-files")) {
show_files = 1;
continue;
> > Also, you can do
> >
> > git commit <list-of-files-to-commit>
> >
> > as a shorthand for
> >
> > git-update-cache <list-of-files-to-commit>
> > git commit
> >
> > which some people will probably find more natural.
>
> It would be natural if it functioned like 'bk citool' ;-)
>
> git commit --figure-out-for-me-what-files-changed
>
> 'git diff' can do this, so it's certainly feasible.
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.
So this is where "git" ends, and a nice user interface (written by
somebody else than me) begins. Ie this is a cogito-like thing.
> > "git-whatchanged" is useful if you actually want to see what the commits
> > _changed_, and then you often want to use the "-p" flag to see it as
> > patches. Also, it's worth pointing out the fact that you can limit it to
> > certain subdirectories (or individual files) etc, ie:
> >
> > git-whatchanged -p drivers/net
> >
> > since that is often what people want.
> >
> > But if you just want the log, "git log" is faster and simpler and more
> > correct.
>
> 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. 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
and it will do what you expect. In fact, since "HEAD" is the default
branch for the final one, you can do
git log remotebranch..
and you'll get the log of everything that is in your HEAD but it _not_ in
the "remotebranch" branch.
Btw, if you have the remote as a branch in your own tree, you can also do
gitk remotebranch..mybranch
which is a really nice way of graphically seeing "what is in 'mybranch'
that is not in 'remotebranch'".
Linus
^ permalink raw reply
* 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
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