* [PATCH] fix field width/precision warnings in blame.c
From: Luck, Tony @ 2006-03-21 23:28 UTC (permalink / raw)
To: git
Using "size_t" values for printf field width/precision upsets gcc, it
wants to see an "int".
Signed-off-by: Tony Luck <tony.luck@intel.com>
---
gcc -o blame.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' blame.c
blame.c: In function `main':
blame.c:864: warning: field width is not type int (arg 2)
blame.c:864: warning: field precision is not type int (arg 3)
blame.c:868: warning: field width is not type int (arg 2)
blame.c:868: warning: field precision is not type int (arg 3)
diff --git a/blame.c b/blame.c
index 9c97aec..7e88833 100644
--- a/blame.c
+++ b/blame.c
@@ -748,7 +748,7 @@ int main(int argc, const char **argv)
struct commit_info ci;
const char *buf;
int max_digits;
- size_t longest_file, longest_author;
+ int longest_file, longest_author;
int found_rename;
const char* prefix = setup_git_directory();
^ permalink raw reply related
* Re: Bad merging with stgit or git
From: Junio C Hamano @ 2006-03-21 23:02 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: git
In-Reply-To: <1142972313.4749.123.camel@praia>
Mauro Carvalho Chehab <mchehab@infradead.org> writes:
>From what I'm understanding now, I should do, when a conflict is
> detected:
>
> nano <files>
> git-update-index <files>
> git commit
>
> Previously (at git 1.1.4), I was doing:
> nano <files>
> git commit <files>
>
> git 1.2.4 don't allow this bad commit syntax anymore.
It is not a bad syntax, and it instead would say "you might have
meant to say -i paths...", and if you follow that suggestion to
say:
$ git commit -i this-and-that-file-I-resolved-by-hand
you would commit the cleanly auto-resolved paths _and_ the
result of your hand merge result. That is the same traditional
behaviour you are used to and is very convenient if you only had
a few paths to be hand resolved.
So I suspect there might be something else going on.
^ permalink raw reply
* Re: [PATCH] Don't use merge labels in the ed scripts
From: Petr Baudis @ 2006-03-21 21:48 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1142977465.8712.4.camel@dv>
Hi,
Dear diary, on Tue, Mar 21, 2006 at 10:44:25PM CET, I got a letter
where Pavel Roskin <proski@gnu.org> said that...
> On Tue, 2006-03-21 at 21:59 +0100, Petr Baudis wrote:
> > Dear diary, on Tue, Mar 21, 2006 at 09:54:14PM CET, I got a letter
> > where Pavel Roskin <proski@gnu.org> said that...
> > > From: Pavel Roskin <proski@gnu.org>
> > >
> > > Merge labels keep changing, and they are not required to identify
> > > specific lines uniquely for the test purposes.
> > >
> > > Signed-off-by: Pavel Roskin <proski@gnu.org>
> >
> > Well, I sincerely hope that they won't change again. ;-)
>
> Actually, it would be nice to never expose labels starting with
> ".merge_file_" - cogito should provide more meaningful labels instead.
we shouldn't ever expose them, though. If we do, that's a bug.
> If you prefer, I'll submit a minimal patch to 0017-alice-bob-fixup.ed
> instead. Once ".merge_file_" is gone, the "tutorial" testsuite would
> check that such labels never appear again.
Curious, it contains the old-style label yet does not fail here now.
Unfortunately I have no time to play with it now. :-( A patch will be
most welcome.
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: [PATCH] Don't use merge labels in the ed scripts
From: Pavel Roskin @ 2006-03-21 21:44 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060321205956.GX19263@pasky.or.cz>
Hi, Petr!
On Tue, 2006-03-21 at 21:59 +0100, Petr Baudis wrote:
> Dear diary, on Tue, Mar 21, 2006 at 09:54:14PM CET, I got a letter
> where Pavel Roskin <proski@gnu.org> said that...
> > From: Pavel Roskin <proski@gnu.org>
> >
> > Merge labels keep changing, and they are not required to identify
> > specific lines uniquely for the test purposes.
> >
> > Signed-off-by: Pavel Roskin <proski@gnu.org>
>
> Well, I sincerely hope that they won't change again. ;-)
Actually, it would be nice to never expose labels starting with
".merge_file_" - cogito should provide more meaningful labels instead.
If you prefer, I'll submit a minimal patch to 0017-alice-bob-fixup.ed
instead. Once ".merge_file_" is gone, the "tutorial" testsuite would
check that such labels never appear again.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] Don't use merge labels in the ed scripts
From: Petr Baudis @ 2006-03-21 20:59 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <20060321205414.8301.97041.stgit@dv.roinet.com>
Dear diary, on Tue, Mar 21, 2006 at 09:54:14PM CET, I got a letter
where Pavel Roskin <proski@gnu.org> said that...
> From: Pavel Roskin <proski@gnu.org>
>
> Merge labels keep changing, and they are not required to identify
> specific lines uniquely for the test purposes.
>
> Signed-off-by: Pavel Roskin <proski@gnu.org>
Well, I sincerely hope that they won't change again. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: Bad merging with stgit or git
From: Junio C Hamano @ 2006-03-21 20:57 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0603211219230.3622@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> And I _hope_ that no git that recent will commit a merge in progress.
Not even 1.1 series for that matter, no.
> However, it does look like the
>
> case "$all,$also" in
> ,t)
>
> case doesn't check for MERGE_HEAD. That could be the bug. Junio?
I do not think so.
"Also" (aka -i) means "run update-index for these paths for me
first, and commit them alongside with what I (or merge) have
already updated in the index".
^ permalink raw reply
* [PATCH] Don't use merge labels in the ed scripts
From: Pavel Roskin @ 2006-03-21 20:54 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
From: Pavel Roskin <proski@gnu.org>
Merge labels keep changing, and they are not required to identify
specific lines uniquely for the test purposes.
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
.../tutorial-script/0010-alice-bob-fixup.ed | 2 +-
.../tutorial-script/0017-alice-bob-fixup.ed | 4 ++--
.../tutorial-script/0018-alice-charlie-fixup1.ed | 4 ++--
.../tutorial-script/0019-alice-charlie-fixup2.ed | 4 ++--
.../tutorial-script/0021-bob-alice-fixup1.ed | 4 ++--
.../tutorial-script/0022-bob-alice-fixup2.ed | 2 +-
6 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/Documentation/tutorial-script/0010-alice-bob-fixup.ed b/Documentation/tutorial-script/0010-alice-bob-fixup.ed
index 81b1360..35ba0c3 100644
--- a/Documentation/tutorial-script/0010-alice-bob-fixup.ed
+++ b/Documentation/tutorial-script/0010-alice-bob-fixup.ed
@@ -1,3 +1,3 @@
-/^<<<<<<< bob/,/^>>>>>>> bobswork/d
+/^<<<<<<< /,/^>>>>>>> /d
w
q
diff --git a/Documentation/tutorial-script/0017-alice-bob-fixup.ed b/Documentation/tutorial-script/0017-alice-bob-fixup.ed
index ad04eb7..00626e3 100644
--- a/Documentation/tutorial-script/0017-alice-bob-fixup.ed
+++ b/Documentation/tutorial-script/0017-alice-bob-fixup.ed
@@ -1,5 +1,5 @@
-/^<<<<<<< Makefile/d
+/^<<<<<<< /d
/^=======/,/^=======/+1d
-/^>>>>>>> \.merge_file_/d
+/^>>>>>>> /d
w
q
diff --git a/Documentation/tutorial-script/0018-alice-charlie-fixup1.ed b/Documentation/tutorial-script/0018-alice-charlie-fixup1.ed
index 9682b4a..f73223c 100644
--- a/Documentation/tutorial-script/0018-alice-charlie-fixup1.ed
+++ b/Documentation/tutorial-script/0018-alice-charlie-fixup1.ed
@@ -1,7 +1,7 @@
-/^<<<<<<< master/d
+/^<<<<<<< /d
/^rpn\.o:/s/\.h.*$/.h lexer.h/
/^lexer\.o:/s/:.*$/: lexer.h/
-/^=======/,/^>>>>>>> charlie/d
+/^=======/,/^>>>>>>> /d
w
q
diff --git a/Documentation/tutorial-script/0019-alice-charlie-fixup2.ed b/Documentation/tutorial-script/0019-alice-charlie-fixup2.ed
index 5d531de..75832f1 100644
--- a/Documentation/tutorial-script/0019-alice-charlie-fixup2.ed
+++ b/Documentation/tutorial-script/0019-alice-charlie-fixup2.ed
@@ -1,5 +1,5 @@
-/^<<<<<<< master/,/^=======/d
-/^>>>>>>> charlie/d
+/^<<<<<<< /,/^=======/d
+/^>>>>>>> /d
w
q
diff --git a/Documentation/tutorial-script/0021-bob-alice-fixup1.ed b/Documentation/tutorial-script/0021-bob-alice-fixup1.ed
index df703d5..9950144 100644
--- a/Documentation/tutorial-script/0021-bob-alice-fixup1.ed
+++ b/Documentation/tutorial-script/0021-bob-alice-fixup1.ed
@@ -1,4 +1,4 @@
-/^<<<<<<< master/,/^=======/d
-/^>>>>>>> origin/d
+/^<<<<<<< /,/^=======/d
+/^>>>>>>> /d
w
q
diff --git a/Documentation/tutorial-script/0022-bob-alice-fixup2.ed b/Documentation/tutorial-script/0022-bob-alice-fixup2.ed
index d8c5746..df1c077 100644
--- a/Documentation/tutorial-script/0022-bob-alice-fixup2.ed
+++ b/Documentation/tutorial-script/0022-bob-alice-fixup2.ed
@@ -1,5 +1,5 @@
/^#include "stack\.h"/+1d
/^#include "lexer\.h"/+1,/^#include "stack\.h"/d
-/^<<<<<<< master/-1,/^>>>>>>> origin/d
+/^<<<<<<< /-1,/^>>>>>>> /d
w
q
^ permalink raw reply related
* Re: Bad merging with stgit or git
From: Linus Torvalds @ 2006-03-21 20:37 UTC (permalink / raw)
To: Petr Baudis; +Cc: Mauro Carvalho Chehab, Git List
In-Reply-To: <20060321200847.GS18185@pasky.or.cz>
On Tue, 21 Mar 2006, Petr Baudis wrote:
>
> With the old Git version (probably v1.1.4, but I'm not so sure when
> looking at 1.1.4's git-commit.sh), git-commit would happily do the
> commit, but wouldn't record the commit as a merge.
I considered that, but as far as I can tell, Mauro is actually using a
fairly recent version of "git". How do I know? The second merge (the
_real_ one) says
commit 86d720ef82ca09e75fac06be15da7cbe2721863a
Merge: e338b73... 8fce4d8...
Author: Mauro Carvalho Chehab <mchehab@infradead.org>
Date: Fri Mar 10 01:32:32 2006 -0300
Merge branch 'origin'
Conflicts:
drivers/media/video/saa7134/saa7134-dvb.c
nothing to commit
and that "Conflicts:" thing from git is actually reasonably recent (it's
from end of January), and almost certainly doesn't exist in v1.1.4 (I
don't think it exists in any 1.1.x version).
So it's 1.2.0 or newer (or some random build, of course).
And I _hope_ that no git that recent will commit a merge in progress.
However, it does look like the
case "$all,$also" in
,t)
case doesn't check for MERGE_HEAD. That could be the bug. Junio?
Linus
^ permalink raw reply
* Re: Bad merging with stgit or git
From: Mauro Carvalho Chehab @ 2006-03-21 20:18 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Git List, Linus Torvalds
In-Reply-To: <20060321193924.GD14579@fieldses.org>
Em Ter, 2006-03-21 às 14:39 -0500, J. Bruce Fields escreveu:
> On Tue, Mar 21, 2006 at 04:34:13PM -0300, Mauro Carvalho Chehab wrote:
> > It shouldn't have any conflicts here for Linus, since those patches came
> > from his tree.
>
> What do you mean by "those patches came from his tree"? If you're
> actually cherry-picking patches from his tree and applying them to
> yours, then you're not reproducing the same commits he has--you're just
> creating new commits that happen to have nearly identical content.
No, I'm not cherry-picking his patches.
>From the discussions on git IRC, I think it may be caused by a bad
procedure when solving a conflict, after merging from Linus tree.
>From what I'm understanding now, I should do, when a conflict is
detected:
nano <files>
git-update-index <files>
git commit
Previously (at git 1.1.4), I was doing:
nano <files>
git commit <files>
git 1.2.4 don't allow this bad commit syntax anymore.
>
> --b.
Cheers,
Mauro.
^ permalink raw reply
* Re: Bad merging with stgit or git
From: Petr Baudis @ 2006-03-21 20:08 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: Git List, Linus Torvalds
In-Reply-To: <1142969653.4749.109.camel@praia>
Dear diary, on Tue, Mar 21, 2006 at 08:34:13PM CET, I got a letter
where Mauro Carvalho Chehab <mchehab@infradead.org> said that...
> With git-cat-file, it shows:
>
> $ git-cat-file commit e338b736f1aee59b757130ffdc778538b7db18d6
> tree b233a18f740a2883e4863506175f671d821f1e5e
> parent cb31c70cdf1ac7034bed5f83d543f4888c39888a
> author Mauro Carvalho Chehab <mchehab@infradead.org> 1141965004 -0300
> committer Mauro Carvalho Chehab <mchehab@infradead.org> 1141965004 -0300
>
> Merging Linus tree
Our IRC hypothesis:
gitweb shows two commits in sequence there,
11 days ago Mauro Carvalho ... Merge branch 'origin'
11 days ago Mauro Carvalho ... Merging Linus tree
where the "Merge branch 'origin'" commit is a true merge commit, but a
rather boring one. There were conflicts during the merge, and according
to mchebab they were "resolved" by (incorrectly) doing:
...edit <files>...
git-commit <files>
With the old Git version (probably v1.1.4, but I'm not so sure when
looking at 1.1.4's git-commit.sh), git-commit would happily do the
commit, but wouldn't record the commit as a merge.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: Bad merging with stgit or git
From: Linus Torvalds @ 2006-03-21 19:42 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: Git List
In-Reply-To: <1142969653.4749.109.camel@praia>
On Tue, 21 Mar 2006, Mauro Carvalho Chehab wrote:
>
> I have a -git tree that generated a really bad result when committed by
> Linus, generating a really bad history log. My tree is located at:
> kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git.
Here's a mail that went to linux-kernel to explain some more..
Basically, the problem is that the DVB tree has a perfectly normal commit
(_not_ a merge commit), which has the commit message
"Merging Linus tree"
and is just a patch that apparently merged the changes in my tree at some
random state (don't know which, since the commit isn't a merge commit, and
doesn't point to the parent it merged from).
I thought it might be a cherry-pick of a merge, or something like that,
but the author/committer dates are the same, so that sounds unlikely.
However, I could imagine that "stgit" would do something like this if/when
it is used to cherry-pick a merge.
Apparently the DVB people also use Mercurial somewhere, so who knows..
Linus
---
Date: Tue, 21 Mar 2006 11:32:10 -0800 (PST)
From: Linus Torvalds <torvalds@osdl.org>
Subject: Re: [PATCH 000/141] V4L/DVB updates part 1
On Tue, 21 Mar 2006, Mauro Carvalho Chehab wrote:
>
> Weird, I can't see all those stuff here. It shows something like
> (running from master copy at kernel.org):
I just did the raw output, so my output was from
git show --pretty=fuller -r e338b7
which isn't the default, but it's useful if you want to see both committer
and author information (and the raw format is just because I wasn't
interested in the diff itself, just looking at how many files where
changed).
> So, after the merging message, I have a normal diff with:
>
> 179 files changed, 1274 insertions(+), 785 deletions(-)
Yeah, we're talking about the same commit.
> Seeming all perfect from my knowledge about git.
It's a perfectly good commit. BUT IT IS NOT A MERGE, AND IT IS NOT A DIFF
THAT I WANT TO SEE COMING IN FROM AN OUTSIDE TREE!
Basically, in the DVB tree you have absolutely _no_ business in "merging"
work from my tree as a patch, especially when the patch you merge has
absolutely zero to do with DVB. You just applied a 5000-line patch to the
tree, with no merge message other than "Merge from Linus tree", and no
attribution about what the f*ck was merged, and why.
THAT is the part I'm unhappy with. The git tree is not "corrupt" from a
technical standpoint (it passes fsck). It's "corrupt" because it contains
a patch that shouldn't be there, that is mis-attributed, and that
incorrectly claims to be a merge when it isn't - it's just a random patch
generated against my tree.
Linus
^ permalink raw reply
* Re: Bad merging with stgit or git
From: J. Bruce Fields @ 2006-03-21 19:39 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: Git List, Linus Torvalds
In-Reply-To: <1142969653.4749.109.camel@praia>
On Tue, Mar 21, 2006 at 04:34:13PM -0300, Mauro Carvalho Chehab wrote:
> It shouldn't have any conflicts here for Linus, since those patches came
> from his tree.
What do you mean by "those patches came from his tree"? If you're
actually cherry-picking patches from his tree and applying them to
yours, then you're not reproducing the same commits he has--you're just
creating new commits that happen to have nearly identical content.
--b.
^ permalink raw reply
* Bad merging with stgit or git
From: Mauro Carvalho Chehab @ 2006-03-21 19:34 UTC (permalink / raw)
To: Git List; +Cc: Linus Torvalds
I have a -git tree that generated a really bad result when committed by
Linus, generating a really bad history log. My tree is located at:
kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git.
I'll try to make a brief from what's happened:
According to him:
"
...
In particular, commit e338b736f1aee59b757130ffdc778538b7db18d6 is crap,
crap, CRAP.
It's "Merging Linus tree", but it's not a merge at all: you have just
applied the _patch_ to merge the changes in my tree, but you haven't
actually told git to do so.
I don't know how/why you did that, but it's totally bogus, and I refuse
to
pull from that tree. That's a 5000+ line diff, affecting about 180
files!
...
"
After a further analysis, it seemed that a merge conflict were badly
solved. It is showing this message to Linus:
diff-tree e338b736f1aee59b757130ffdc778538b7db18d6 (from
cb31c70cdf1ac7034bed5f83d543f4888c39888a)
Author: Mauro Carvalho Chehab <mchehab@infradead.org>
AuthorDate: Fri Mar 10 01:30:04 2006 -0300
Commit: Mauro Carvalho Chehab <mchehab@infradead.org>
CommitDate: Fri Mar 10 01:30:04 2006 -0300
Merging Linus tree
:100644 100644 be5ae600f5337dbb14daa8d4cace110486e14f79
81bc51369f59a413108fd8b150c3090541ba49f8 M
Documentation/feature-removal-schedule.txt
:100644 100644 75205391b335f85c9b8a599d0d3b4c0dd1a8b41b
fc99075e0af47f0b73a2ae2dfb7d19920c604dea M
Documentation/kernel-parameters.txt
:100644 100644 9006063e73691da7b68449955a135f7c9317e2cd
da677f829f7689966bf09aeda6d89fc4b6a876d1 M arch/alpha/kernel/irq.c
For me, those tree last lines, don't appear. Instead, it just shows,
with git-show:
diff-tree e338b736f1aee59b757130ffdc778538b7db18d6 (from
cb31c70cdf1ac7034bed5f83d543f4888c39888a)
Author: Mauro Carvalho Chehab <mchehab@infradead.org>
Date: Fri Mar 10 01:30:04 2006 -0300
Merging Linus tree
and a diff file, with:
179 files changed, 1274 insertions(+), 785 deletions(-)
With git-cat-file, it shows:
$ git-cat-file commit e338b736f1aee59b757130ffdc778538b7db18d6
tree b233a18f740a2883e4863506175f671d821f1e5e
parent cb31c70cdf1ac7034bed5f83d543f4888c39888a
author Mauro Carvalho Chehab <mchehab@infradead.org> 1141965004 -0300
committer Mauro Carvalho Chehab <mchehab@infradead.org> 1141965004 -0300
Merging Linus tree
It shouldn't have any conflicts here for Linus, since those patches came
from his tree.
My current procedure is:
branch origin - Linus tree replica
branch work - my stgit main tree
branch work-fixes - my stgit tree for bug fixes
branch master - patches to current kernel
branch devel - patches to next kernel
All patches are generated against work branch, with stgit.
Branch work-fixes receives patches by using:
stg pick <sha>@work
Before commiting to kernel.org, I do:
at origin:
git pull linus_tree
at master:
git pull . origin
git pull . work-fixes
at devel:
git pull . origin
git pull . work
My environment is:
Stacked GIT 0.8.1
git version 1.2.4.gfd662
Python version 2.4.2 (#2, Jan 30 2006, 18:33:58)
[GCC 4.0.2 (4.0.2-1mdk for Mandriva Linux release 2006.1)]
Any ideas?
^ permalink raw reply
* Re: efficient cloning
From: Petr Baudis @ 2006-03-21 11:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vy7z4f7x3.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Tue, Mar 21, 2006 at 10:45:12AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Jeff King <peff@peff.net> writes:
>
> > Then why not create .git/refs/remotes/$origin/HEAD at the time of clone
> > (or later)? Then the core looks for:
> > (current order, .git/refs, etc)
> > .git/refs/remotes/foo
> > .git/refs/remotes/foo/HEAD
> > The porcelain can take care of managing the contents of HEAD. If there
> > is no HEAD in the directory, then it cannot be looked up by 'foo'
> > ('foo/remote-branch' must be used instead).
>
> Yup, earlier I mentioned that possibility, and it does not seem
> too painful. On top of the "next", here is what is needed.
>
> -- >8 --
> [PATCH] get_sha1_basic(): try refs/... and finally refs/remotes/$foo/HEAD
>
> This implements the suggestion by Jeff King to use
> refs/remotes/$foo/HEAD to interpret a shorthand "$foo" to mean
> the primary branch head of a tracked remote. clone needs to be
> told about this convention as well.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
Excellent, yes, that's what I've meant. I'm happy now. :)
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: efficient cloning
From: Junio C Hamano @ 2006-03-21 9:45 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20060321091916.GA17125@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Then why not create .git/refs/remotes/$origin/HEAD at the time of clone
> (or later)? Then the core looks for:
> (current order, .git/refs, etc)
> .git/refs/remotes/foo
> .git/refs/remotes/foo/HEAD
> The porcelain can take care of managing the contents of HEAD. If there
> is no HEAD in the directory, then it cannot be looked up by 'foo'
> ('foo/remote-branch' must be used instead).
Yup, earlier I mentioned that possibility, and it does not seem
too painful. On top of the "next", here is what is needed.
-- >8 --
[PATCH] get_sha1_basic(): try refs/... and finally refs/remotes/$foo/HEAD
This implements the suggestion by Jeff King to use
refs/remotes/$foo/HEAD to interpret a shorthand "$foo" to mean
the primary branch head of a tracked remote. clone needs to be
told about this convention as well.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
sha1_name.c | 23 ++++++++++++-----------
1 files changed, 12 insertions(+), 11 deletions(-)
c51d13692d4e451c755dd7da3521c5db395df192
diff --git a/sha1_name.c b/sha1_name.c
index 74c479c..3adaec3 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -235,18 +235,21 @@ static int ambiguous_path(const char *pa
static int get_sha1_basic(const char *str, int len, unsigned char *sha1)
{
- static const char *prefix[] = {
- "",
- "refs",
- "refs/tags",
- "refs/heads",
- "refs/remotes",
+ static const char *fmt[] = {
+ "/%.*s",
+ "refs/%.*s",
+ "refs/tags/%.*s",
+ "refs/heads/%.*s",
+ "refs/remotes/%.*s",
+ "refs/remotes/%.*s/HEAD",
NULL
};
const char **p;
const char *warning = "warning: refname '%.*s' is ambiguous.\n";
char *pathname;
int already_found = 0;
+ unsigned char *this_result;
+ unsigned char sha1_from_ref[20];
if (len == 40 && !get_sha1_hex(str, sha1))
return 0;
@@ -255,11 +258,9 @@ static int get_sha1_basic(const char *st
if (ambiguous_path(str, len))
return -1;
- for (p = prefix; *p; p++) {
- unsigned char sha1_from_ref[20];
- unsigned char *this_result =
- already_found ? sha1_from_ref : sha1;
- pathname = git_path("%s/%.*s", *p, len, str);
+ for (p = fmt; *p; p++) {
+ this_result = already_found ? sha1_from_ref : sha1;
+ pathname = git_path(*p, len, str);
if (!read_ref(pathname, this_result)) {
if (warn_ambiguous_refs) {
if (already_found &&
--
1.2.4.gf1250
^ permalink raw reply related
* Re: efficient cloning
From: Jeff King @ 2006-03-21 9:19 UTC (permalink / raw)
To: git
In-Reply-To: <7v4q1sgpet.fsf@assigned-by-dhcp.cox.net>
On Tue, Mar 21, 2006 at 12:42:02AM -0800, Junio C Hamano wrote:
> The reason I would like to avoid .git/remotes/$origin is because
> it is designed to be Porcelainish thing. The underlying C-level
> git-fetch-pack never sees it; instead the information fed to
> C-level is prepared by the upper layer using that file. As far
> as I understand, Cogito does not understand it either, except
> that it ships with bash completion code that reads from
> filenames there.
Then why not create .git/refs/remotes/$origin/HEAD at the time of clone
(or later)? Then the core looks for:
(current order, .git/refs, etc)
.git/refs/remotes/foo
.git/refs/remotes/foo/HEAD
The porcelain can take care of managing the contents of HEAD. If there
is no HEAD in the directory, then it cannot be looked up by 'foo'
('foo/remote-branch' must be used instead).
-Peff
^ permalink raw reply
* Re: efficient cloning
From: Junio C Hamano @ 2006-03-21 8:42 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Petr Baudis, Josef Weidendorfer, git
In-Reply-To: <441FB715.1000500@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> That way the only extra dwimery would be to add "remotes" after
> "heads" under .git/refs and accept directory in .git/remotes/ as ref
> and tack on '/master' at the end of it as the last option to
> search. For a specific branch on an imported remote, one would have to
> say "jc/next". This means we still only handle 'master' specially so
> we don't introduce any new protected or special names.
Two things that holding me back from doing what you suggested
are (1) "master" is just a convention and indeed non-negligible
number of kernel.org trees have "test" and "release" instead
without "master"; (2) I'd really really really want to avoid
teaching get_sha1_basic() C-level about .git/remotes/$origin
file, even though that function is more of a UI level than the
rest of the really core C-level routines.
But if I were forced to choose between the above 2, I would
probably pick defaulting to "master".
The reason I would like to avoid .git/remotes/$origin is because
it is designed to be Porcelainish thing. The underlying C-level
git-fetch-pack never sees it; instead the information fed to
C-level is prepared by the upper layer using that file. As far
as I understand, Cogito does not understand it either, except
that it ships with bash completion code that reads from
filenames there.
^ permalink raw reply
* Re: efficient cloning
From: Junio C Hamano @ 2006-03-21 8:28 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git, Petr Baudis
In-Reply-To: <200603201730.19373.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> Shouldn't this be .git/refs/remotes/origin/?
> Ie. different namespaces for different remotes?
OK, here is a second try, that comes on top of the one from the
last night.
Together with another topic in the "next" branch, you can now do
this:
$ git clone --use-separate-remote --reference git.git \
git://git.kernel.org/pub/scm/git/git.git new.git
$ cd new.git
$ git branch
* master
$ git log --pretty=oneline master..origin/next | wc -l
72
What the last one shows is that sha1_basic() lets you omit
refs/remotes; it does not let you say "origin" to mean
"refs/remotes/origin/master", although I agree that abbreviation
would be useful. As I am still not yet convinced that using
what is in .git/remotes/origin is a good way to implement that
shorthand, and would rather avoid reading .git/remotes/origin
from the C level (even though sha1_basic() is not _that_ core
but a lot closer to the UI, compared to other C level routines),
I am leaving that part for later rounds.
-- >8 --
[PATCH] revamp git-clone (take #2).
This builds on top of the previous one.
* --use-separate-remote uses .git/refs/remotes/$origin/
directory to keep track of the upstream branches.
* The $origin above defaults to "origin" as usual, but the
existing "-o $origin" option can be used to override it.
I am not yet convinced if we should make "$origin" the synonym to
"refs/remotes/$origin/$name" where $name is the primary branch
name of $origin upstream, nor if so how we should decide which
upstream branch is the primary one, but that is more or less
orthogonal to what the clone does here.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-clone.sh | 50 +++++++++++++++++++++++++++++++-------------------
1 files changed, 31 insertions(+), 19 deletions(-)
47874d6d9a7f49ade6388df049597f03365961ca
diff --git a/git-clone.sh b/git-clone.sh
index 9db678b..3b54753 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -9,7 +9,7 @@
unset CDPATH
usage() {
- echo >&2 "Usage: $0 [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [-o <name>] [-n] <repo> [<dir>]"
+ echo >&2 "Usage: $0 [--use-separate-remote] [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [-o <name>] [-n] <repo> [<dir>]"
exit 1
}
@@ -61,8 +61,9 @@ use File::Path qw(mkpath);
use File::Basename qw(dirname);
my $git_dir = $ARGV[0];
my $use_separate_remote = $ARGV[1];
+my $origin = $ARGV[2];
-my $branch_top = ($use_separate_remote ? "remotes" : "heads");
+my $branch_top = ($use_separate_remote ? "remotes/$origin" : "heads");
my $tag_top = "tags";
sub store {
@@ -127,7 +128,12 @@ while
*,--reference=*)
reference=`expr "$1" : '--reference=\(.*\)'` ;;
*,-o)
- git-check-ref-format "$2" || {
+ case "$2" in
+ */*)
+ echo >&2 "'$2' is not suitable for an origin name"
+ exit 1
+ esac
+ git-check-ref-format "heads/$2" || {
echo >&2 "'$2' is not suitable for a branch name"
exit 1
}
@@ -165,14 +171,9 @@ then
no_checkout=yes
fi
-if test -z "$origin_override$origin"
+if test -z "$origin"
then
- if test -n "$use_separate_remote"
- then
- origin=remotes/master
- else
- origin=heads/origin
- fi
+ origin=origin
fi
# Turn the source into an absolute path if
@@ -317,7 +318,7 @@ test -d "$GIT_DIR/refs/reference-tmp" &&
if test -f "$GIT_DIR/CLONE_HEAD"
then
# Figure out where the remote HEAD points at.
- perl -e "$copy_refs" "$GIT_DIR" "$use_separate_remote"
+ perl -e "$copy_refs" "$GIT_DIR" "$use_separate_remote" "$origin"
fi
cd "$D" || exit
@@ -328,8 +329,18 @@ then
# Figure out which remote branch HEAD points at.
case "$use_separate_remote" in
'') remote_top=refs/heads ;;
- *) remote_top=refs/remotes ;;
+ *) remote_top="refs/remotes/$origin" ;;
esac
+
+ # What to use to track the remote primary branch
+ if test -n "$use_separate_remote"
+ then
+ origin_tracking="remotes/$origin/master"
+ else
+ origin_tracking="heads/$origin"
+ fi
+
+ # The name under $remote_top the remote HEAD seems to point at
head_points_at=$(
(
echo "master"
@@ -349,25 +360,26 @@ then
done
)
)
+
+ # Write out remotes/$origin file.
case "$head_points_at" in
?*)
mkdir -p "$GIT_DIR/remotes" &&
- echo >"$GIT_DIR/remotes/origin" \
+ echo >"$GIT_DIR/remotes/$origin" \
"URL: $repo
-Pull: refs/heads/$head_points_at:refs/$origin" &&
+Pull: refs/heads/$head_points_at:refs/$origin_tracking" &&
case "$use_separate_remote" in
t) git-update-ref HEAD "$head_sha1" ;;
*) git-update-ref "refs/$origin" $(git-rev-parse HEAD)
esac &&
- (cd "$GIT_DIR" && find "$remote_top" -type f -print) |
- while read ref
+ (cd "$GIT_DIR/$remote_top" && find . -type f -print) |
+ while read dotslref
do
- head=`expr "$ref" : 'refs/\(.*\)'` &&
- name=`expr "$ref" : 'refs/[^\/]*/\(.*\)'` &&
+ name=`expr "$dotslref" : './\(.*\)'` &&
test "$head_points_at" = "$name" ||
test "$origin" = "$head" ||
echo "Pull: refs/heads/${name}:$remote_top/${name}"
- done >>"$GIT_DIR/remotes/origin"
+ done >>"$GIT_DIR/remotes/$origin"
esac
case "$no_checkout" in
--
1.2.4.ge2fc
^ permalink raw reply related
* Re: efficient cloning
From: Andreas Ericsson @ 2006-03-21 8:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, Josef Weidendorfer, git
In-Reply-To: <7vfylcismx.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
>
>>I still don't get what's wrong on what I'm proposing. I'm not seeing the
>>disadvantages, if there are any.
>
>
> The only thing I think there is is that I do not get what you
> are proposing ;-), since I am not paying full attention while at
> day-job.
>
> If you are proposing to root --use-separate-remote not at
> refs/remotes but refs/remotes/origin/, I think it makes kind of
> sense. It would make tons of sense _if_ dealing more than one
> remote repository is the norm, but otherwise you would have an
> extra level of directory refs/remotes which almost always have
> only one subdirectory 'origin' and nothing else, which is
> pointless.
>
afaiu, this is exactly what Pasky's proposing, and I agree. We could
then teach 'git diff origin master' to mean 'origin/master' *if* no
other tag/branch is found in the lookup order. I think it makes sense to
do searching like this, for a ref named foo
(current order, with .git/, .git/refs/, etc...)
.git/refs/remotes/foo
.git/refs/remotes/foo/master
That way the only extra dwimery would be to add "remotes" after "heads"
under .git/refs and accept directory in .git/remotes/ as ref and tack on
'/master' at the end of it as the last option to search. For a specific
branch on an imported remote, one would have to say "jc/next". This
means we still only handle 'master' specially so we don't introduce any
new protected or special names.
> I am not sure if you are also advocating to map (somehow) origin
> to remotes/origin/master (or whatever branch remote's HEAD
> points at), but if so I am not quite sure what its semantics
> would be. Which remote branch would you pick (that would not
> necessarily be "master") and where are you going to record that
> and when. It all sounds to me complicating things
> unnecessarily.
>
Not too much so, I think. I'll look into it tonight, although I'm not
very familiar with the core stuff so possibly (/ hopefully) someone else
will beat me to it.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH] contrib/git-svn: allow rebuild to work on non-linear remote heads
From: Eric Wong @ 2006-03-21 4:51 UTC (permalink / raw)
To: Junio C Hamano, git
Because committing back to an SVN repository from different
machines can result in different lineages, two different
repositories running git-svn can result in different commit
SHA1s (but of the same tree). Sometimes trees that are tracked
independently are merged together (usually via children),
resulting in non-unique git-svn-id: lines in rev-list.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/git-svn.perl | 14 +++++++++++++-
1 files changed, 13 insertions(+), 1 deletions(-)
85bed4cd937921844574fe66da95977fdeece993
diff --git a/contrib/git-svn/git-svn.perl b/contrib/git-svn/git-svn.perl
index cf233ef..f3fc3ec 100755
--- a/contrib/git-svn/git-svn.perl
+++ b/contrib/git-svn/git-svn.perl
@@ -850,11 +850,23 @@ sub assert_revision_unknown {
}
}
+sub trees_eq {
+ my ($x, $y) = @_;
+ my @x = safe_qx('git-cat-file','commit',$x);
+ my @y = safe_qx('git-cat-file','commit',$y);
+ if (($y[0] ne $x[0]) || $x[0] !~ /^tree $sha1\n$/
+ || $y[0] !~ /^tree $sha1\n$/) {
+ print STDERR "Trees not equal: $y[0] != $x[0]\n";
+ return 0
+ }
+ return 1;
+}
+
sub assert_revision_eq_or_unknown {
my ($revno, $commit) = @_;
if (-f "$REV_DIR/$revno") {
my $current = file_to_s("$REV_DIR/$revno");
- if ($commit ne $current) {
+ if (($commit ne $current) && !trees_eq($commit, $current)) {
croak "$REV_DIR/$revno already exists!\n",
"current: $current\nexpected: $commit\n";
}
--
1.2.4.gb622a
^ permalink raw reply related
* Re: efficient cloning
From: Junio C Hamano @ 2006-03-21 0:57 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200603210126.59870.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
>> I think what is reasonable is something like this:
>>
>> - If you start from a repository cloned in the traditional
>> way, the upstream "master" is kept track of with your
>> "origin", so "diff origin master" would be "my changes on top
>> of the upstream".
>
> Yes. And it would be nice if the same would work with the new layout,
> assuming that there is no local "origin" branch, but a .git/remotes/origin
> file and .git/refs/remotes/origin directory.
My primary aversion comes from that I'd rather avoid teaching
the really core stuff about .git/remotes file, and the part that
interprets refname is fairly a low-level part.
We _could_ record refs/remotes/origin/HEAD that points at
refs/remotes/origin/master (or some other branch) upon cloning,
and if Pasky wants to do something similar upon fetching, that
fetch command could do the same thing.
^ permalink raw reply
* Re: efficient cloning
From: Josef Weidendorfer @ 2006-03-21 0:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7voe00iupp.fsf@assigned-by-dhcp.cox.net>
On Tuesday 21 March 2006 00:04, you wrote:
> > Linus wanted to still be able to say "origin" which automatically
> > would map to "remotes/origin/master", where the name of the remote
>
> I do not remember that,
See
http://www.gelato.unsw.edu.au/archives/git/0603/17405.html
I found it strange at first. But I think it is the right thing.
> I think what is reasonable is something like this:
>
> - If you start from a repository cloned in the traditional
> way, the upstream "master" is kept track of with your
> "origin", so "diff origin master" would be "my changes on top
> of the upstream".
Yes. And it would be nice if the same would work with the new layout,
assuming that there is no local "origin" branch, but a .git/remotes/origin
file and .git/refs/remotes/origin directory.
> - Regardless of how you started your cloned repository, with an
> $GIT_DIR/{remotes,refs/heads,refs/remotes} editor I hinted in
> a separate message, you can rearrange things to organize the
> refs/ hierarchy any way you want.
Yes.
Still it would be nice to have a fixed convention here.
Eg. gitk could decorate the namespace in a special way.
Even if it is most of the time "origin" only.
> [Footnote]
>
> *1* ... which currently I do not plan to do myself unless I have
> absolutely nothing else to do and really bored. A sound of huge
> hint dropping ;-).
It should be as simple as (probably with quite some errors)
~/> cat git-rename-remote.sh
mv .git/refs/remotes/$1 .git/refs/remotes/$2
sed -e "s|remotes/$1|remotes/$2" .git/remotes/$1 > .git/remotes/$2
rm .git/remotes/$1
If you allow more freedom regarding the use of refs/remotes, it gets more
complicated both for the script and for the user to understand.
Josef
^ permalink raw reply
* Re: efficient cloning
From: Junio C Hamano @ 2006-03-20 23:49 UTC (permalink / raw)
To: Petr Baudis; +Cc: Josef Weidendorfer, git
In-Reply-To: <20060320232101.GQ18185@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> I still don't get what's wrong on what I'm proposing. I'm not seeing the
> disadvantages, if there are any.
The only thing I think there is is that I do not get what you
are proposing ;-), since I am not paying full attention while at
day-job.
If you are proposing to root --use-separate-remote not at
refs/remotes but refs/remotes/origin/, I think it makes kind of
sense. It would make tons of sense _if_ dealing more than one
remote repository is the norm, but otherwise you would have an
extra level of directory refs/remotes which almost always have
only one subdirectory 'origin' and nothing else, which is
pointless.
I am not sure if you are also advocating to map (somehow) origin
to remotes/origin/master (or whatever branch remote's HEAD
points at), but if so I am not quite sure what its semantics
would be. Which remote branch would you pick (that would not
necessarily be "master") and where are you going to record that
and when. It all sounds to me complicating things
unnecessarily.
^ permalink raw reply
* Re: efficient cloning
From: Petr Baudis @ 2006-03-20 23:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Josef Weidendorfer, git
In-Reply-To: <7voe00iupp.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Tue, Mar 21, 2006 at 12:04:34AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> I think what is reasonable is something like this:
<insert all of the arguments in my other mail here ;>
> - If your repository was cloned with --use-separate-remote, the
> upstream "master" is refs/remotes/master, so the same diff
> can be had with "diff remotes/master master".
Which is ugly. There is no reason why you couldn't go on using 'origin'
which is shorter and we can usually still unambiguously decide what did
you mean (unless you have a local head/tag 'origin' _and_ a remote named
'origin' at the same time).
> - Regardless of how you started your cloned repository, with an
> $GIT_DIR/{remotes,refs/heads,refs/remotes} editor I hinted in
> a separate message, you can rearrange things to organize the
> refs/ hierarchy any way you want.
Yes, but that makes no sense to do when you usually need this only in
some very special cases (and then you ought to be able to set up the
weird thing yourself), while we can do the doubtlessly right thing in
the general case, WITHOUT confusing the user, WHILE keeping things tidy
and easy to use (and without excessive typing). In fact, you described
it yourself:
> - You could for example arrange to track all my branches in
> refs/remotes/junkio/, and if git-pasky were still alive,
> Pasky's branches in refs/remotes/pasky. If we had a "take
> the unique tail-name anywhere under refs/" logic, the same
> diff can be had with "diff junkio/master master".
Except that you can just name the refs/remotes/directory the same way
you name the remote repository identifier (be it a Git-style remote or
Cogito's remote branch).
I still don't get what's wrong on what I'm proposing. I'm not seeing the
disadvantages, if there are any.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: efficient cloning
From: Junio C Hamano @ 2006-03-20 23:07 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060320224123.GP18185@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Then you can make a simple change that if a refname matches a directory
> in refs/remotes/, you rewrite it as refs/remotes/<refname>/master. This
> makes 'origin' work seamlessly in a natural way and a lot more elegantly
> than if you make up an artifical rule like "if the remote's branch is
> master, save it as origin, but save all the other branches verbatim".
The "origin" rename applies only to the traditional one.
Separate remote stuff stores master in remotes/master.
At least that is the way I remember I designed it to work.
^ 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