* RE: new file leaked onto release branch
From: Johannes Schindelin @ 2005-12-14 23:34 UTC (permalink / raw)
To: Brown, Len; +Cc: Junio C Hamano, git
In-Reply-To: <F7DC2337C7631D4386A2DF6E8FB22B30056B8748@hdsmsx401.amr.corp.intel.com>
Hi,
On Wed, 14 Dec 2005, Brown, Len wrote:
> >BTW, are 5165, 3410, 5452, 5571... topic branch names?
>
> yes, the are bugzilla ids
So, it could have been
git pull . 5165
which mistakes 5165 for a short SHA1?
Hth,
Dscho
^ permalink raw reply
* Re: Tracking files across tree reorganizations
From: H. Peter Anvin @ 2005-12-14 23:12 UTC (permalink / raw)
To: Petr Baudis; +Cc: Git Mailing List
In-Reply-To: <20051214223656.GJ22159@pasky.or.cz>
Petr Baudis wrote:
> Hah, here we go again. :-)
>
> Dear diary, on Wed, Dec 14, 2005 at 10:15:59PM CET, I got a letter
> where "H. Peter Anvin" <hpa@zytor.com> said that...
>
>>Did anything ever happen with that?
>
> Linus is against it.
>
I don't think so. Linus is against the user having to explicitly record
the moves, but we can detect the moves at the point of reorganization.
> Cogito will do it anyway ;-), when someone sends me a nice patch or when
> I get to it (probably not very soon). I imagine it like this:
>
> (a) User can explicitly note file moves / renames. We follow those notes.
> Probably the most viable for recording the notes is appending them at
> the tail of the commit message.
>
> (b) If there are no notes for the given commit, we do the rename
> autodetection already implemented in GIT. If it yields something,
> we follow it.
I don't see anything in Linus' posts that says (b) is unacceptable.
-hpa
^ permalink raw reply
* [ANNOUNCE] Cogito-0.16.2
From: Petr Baudis @ 2005-12-14 23:10 UTC (permalink / raw)
To: git; +Cc: linux-kernel
Hello,
this is Cogito version 0.16.2, the next stable release of the
human-friendly version control UI for the Linus' GIT tool. Share
and enjoy at:
http://www.kernel.org/pub/software/scm/cogito/
Very few changes since the last release - one testcase, trivial fix,
documentation improvements. And one important bugfix! If you are a
cg-clean user, certainly upgrade - cg-clean in 0.16.1 had a serious bug
which would cause it remove all subdirectories when running from the
source root with the -d option - which is rather nasty if you have any
uncommitted local changes there.
Now we finally have a testcase for cg-clean, and the cg-clean code was
further tweaked to reduce potential for any more code mistakes. The
major reason for both 0.16.1 and 0.16.2 were cg-clean bugs, but
hopefully no more problems are waiting for us in this realm, and the
rest of Cogito seems to be thankfully pretty stable throughout the 0.16
line, so I expect things to finally calm down a bit here.
I spent the last two hours making a large patch fixing all potentially
whitespace-unsafe Cogito code, but I've decided to keep it for 0.17 only
- Cogito meeting with whitespaces is a very rare occasion, and such
a large patch is bound to contain some new bugs coming from trivial
mistakes and such.
Also, Cogito is now very ineffective when cloning big-packed
repositories over the git protocol or over ssh, since git-fetch-pack
unpacks the objects on the local side, which bogs things down a lot and
makes the repository grow into enormous proportions - I'm not yet sure
if I will backport the fix to 0.16 since I want to be maximally careful
not to gravely break anything again and keep 0.16 as stable as possible.
(Hm. Call this "the Debian dilemma". ;-)
The new stuff since 0.16.1 is:
Pavel Roskin:
cg-clean test
cg-clean: be safer by running everything from relpath
Petr Baudis:
cg-clean testcase: Minor tidyup
cg-clean testcase: Clarify description
Fixed cg-clean removing ALL subdirs when invoked from root
(Discovered and originally fixed by Pavel Roskin.)
Fix cg-status reporting every merge as a squash-merge
Improve cg-admin-setuprepo documentation
In the cg-commit text, give the user hint on how to abort
cogito-0.16.2
Happy hacking,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* RE: new file leaked onto release branch
From: Brown, Len @ 2005-12-14 22:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
>BTW, are 5165, 3410, 5452, 5571... topic branch names?
yes, the are bugzilla ids
^ permalink raw reply
* git rebase loses author name/email if given bad email address
From: Amos Waterland @ 2005-12-14 22:48 UTC (permalink / raw)
To: junkio; +Cc: git, mostrows
If GIT_AUTHOR_EMAIL is of a certain form, `git rebase master' will blow
away the author name and email when fast-forward merging commits. I
have not tracked it down, but here is a testcase that demonstrates the
behavior.
Signed-off-by: Amos Waterland <apw@us.ibm.com>
Acked-by: Michal Ostrowski <mostrows@watson.ibm.com>
---
t/t3400-rebase.sh | 34 ++++++++++++++++++++++++++++++++++
1 files changed, 34 insertions(+), 0 deletions(-)
create mode 100755 t/t3400-rebase.sh
6a31c31a8e6bf4328fab39f39926af6bcc794bf2
diff --git a/t/t3400-rebase.sh b/t/t3400-rebase.sh
new file mode 100755
index 0000000..b9d3131
--- /dev/null
+++ b/t/t3400-rebase.sh
@@ -0,0 +1,34 @@
+#!/bin/sh
+#
+# Copyright (c) 2005 Amos Waterland
+#
+
+test_description='git rebase should not destroy author information
+
+This test runs git rebase and checks that the author information is not lost.
+'
+. ./test-lib.sh
+
+export GIT_AUTHOR_EMAIL=bogus_email_address
+
+test_expect_success \
+ 'prepare repository with topic branch, then rebase against master' \
+ 'echo First > A &&
+ git-update-index --add A &&
+ git-commit -m "Add A." &&
+ git checkout -b my-topic-branch &&
+ echo Second > B &&
+ git-update-index --add B &&
+ git-commit -m "Add B." &&
+ git checkout -f master &&
+ echo Third >> A &&
+ git-update-index A &&
+ git-commit -m "Modify A." &&
+ git checkout -f my-topic-branch &&
+ git rebase master'
+
+test_expect_failure \
+ 'the rebase operation should not have destroyed author information' \
+ 'git log | grep "Author:" | grep "<>"'
+
+test_done
--
0.99.9.GIT
^ permalink raw reply related
* Re: Tracking files across tree reorganizations
From: Petr Baudis @ 2005-12-14 22:36 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List
In-Reply-To: <43A08B8F.1000901@zytor.com>
Hah, here we go again. :-)
Dear diary, on Wed, Dec 14, 2005 at 10:15:59PM CET, I got a letter
where "H. Peter Anvin" <hpa@zytor.com> said that...
> Did anything ever happen with that?
Linus is against it.
Cogito will do it anyway ;-), when someone sends me a nice patch or when
I get to it (probably not very soon). I imagine it like this:
(a) User can explicitly note file moves / renames. We follow those notes.
Probably the most viable for recording the notes is appending them at
the tail of the commit message.
(b) If there are no notes for the given commit, we do the rename
autodetection already implemented in GIT. If it yields something,
we follow it.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: new file leaked onto release branch
From: Junio C Hamano @ 2005-12-14 22:16 UTC (permalink / raw)
To: Brown, Len; +Cc: git
In-Reply-To: <F7DC2337C7631D4386A2DF6E8FB22B30056B86DD@hdsmsx401.amr.corp.intel.com>
"Brown, Len" <len.brown@intel.com> writes:
> I'm not stuck by this problem, since I created a new release
> branch based before the funny merge and it seems to be
> working properly. I'm sorry I can't re-create the problem
> again. Next time something like this happens and I notice it
> I'll be sure to keep the ingredients for the failure on hand.
Thanks.
BTW, are 5165, 3410, 5452, 5571... topic branch names?
^ permalink raw reply
* RE: new file leaked onto release branch
From: Brown, Len @ 2005-12-14 22:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
>I pointed out one anomaly which is the commit should never have
>been created because it was not even a fast forward but already
>up-to-date case, and it was followed up with exchange of a few
>messages between Linus and you. But even if we got that mixed
>up, the resulting merge should not have contained the file
>neither parents had. That part worries me the most.
>
>One question. You mentioned these in your message, you have
>a "git.commit wrapper" that contains these lines:
>
> git-update-index --add --remove `quilt files`
> git commit
>
>I am not familiar with 'quilt', but is "quilt files" the command
>to show the list of files with patches applied to the working
>tree?
yes, but only by the last applied "on the top of the stack."
When I do a commit, there is only 1 patch applied so this works okay.
(then I push the next patch after the commit and repeat...)
>If so, the above do tell git about the modified (including added
>or removed) files that the applied quilt patches touch, which
>sounds like the correct thing to do.
>
>But the resulting commit from that procedure would not be a
>merge commit, and the commit in question that had the rsinfo
>file magically appeared from nowhere is a merge, so this does
>not seem to have much to do with the current problem...
>
>Still puzzlled, sorry.
I'm not stuck by this problem, since I created a new release
branch based before the funny merge and it seems to be
working properly. I'm sorry I can't re-create the problem
again. Next time something like this happens and I notice it
I'll be sure to keep the ingredients for the failure on hand.
thanks,
-Len
^ permalink raw reply
* RE: new file leaked onto release branch
From: Brown, Len @ 2005-12-14 21:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
>That's what I get when I try this:
>
> git checkout -b test-merge 0a47c906342e2447003e207d23917dfa5c912071
> git merge "Testing merging" HEAD d2149b542382bfc206cb28485108f6470c979566
>
>results in a very immediate
>
> "Already up-to-date."
>
>message. Does it do that for you too?
Yes.
>I think this list has been pretty responsive to reports of strange
>behaviour, so yes.
Agreed.
If I see anything strange like this in the future I'll report it immediately.
thanks,
-Len
^ permalink raw reply
* Re: [PATCH] Do not ignore errors during make check
From: Amos Waterland @ 2005-12-14 21:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1x0fxt7b.fsf@assigned-by-dhcp.cox.net>
On Wed, Dec 14, 2005 at 01:30:16PM -0800, Junio C Hamano wrote:
> Good point but "|| exit" would be more appropriate. With the
> above patch, I suspect "make check" merely stops at the first
> error but resulting return code would still be zero, wouldn't
> it?
Yes, here is a patch that uses exit instead of break.
---
Do not let errors pass by unnoticed when running `make check'.
Signed-off-by: Amos Waterland <apw@us.ibm.com>
---
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
bc721e2d99487c0240514a848ac1cb84c086e008
diff --git a/Makefile b/Makefile
index 01b6643..d494ad4 100644
--- a/Makefile
+++ b/Makefile
@@ -449,7 +449,7 @@ test-delta$X: test-delta.c diff-delta.o
$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $^
check:
- for i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i; done
+ for i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i || exit; done
--
0.99.9.GIT
^ permalink raw reply related
* RE: new file leaked onto release branch
From: Brown, Len @ 2005-12-14 21:31 UTC (permalink / raw)
To: Tom Prince, Junio C Hamano; +Cc: Linus Torvalds, git
>> I pointed out one anomaly which is the commit should never have
>> been created because it was not even a fast forward but already
>> up-to-date case, and it was followed up with exchange of a few
>> messages between Linus and you.
>>
>
>I don't remember any of the details now, but I remember that an old
>version of git or cogito would create bogus fast-forward
>merges, if they
>were used without GNU coreutils. The machine it happend on was running
>FreeBSD 4.10, but current versions work fine.
I'm running SuSE Linux 10.0 x86_64 on this box
# rpm -q coreutils
coreutils-5.3.0-20
^ permalink raw reply
* Re: [PATCH] Do not ignore errors during make check
From: Junio C Hamano @ 2005-12-14 21:30 UTC (permalink / raw)
To: Amos Waterland; +Cc: git
In-Reply-To: <20051214210932.GA2642@kvasir.watson.ibm.com>
Amos Waterland <apw@us.ibm.com> writes:
> Do not let errors pass by unnoticed when running `make check'.
> ...
> check:
> - for i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i; done
> + for i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i || break; done
Good point but "|| exit" would be more appropriate. With the
above patch, I suspect "make check" merely stops at the first
error but resulting return code would still be zero, wouldn't
it?
$ cat Makefile
check1:
for i in 1 2 3 4; do echo testing $$i; test $$i -le 2 || break; done
check2:
for i in 1 2 3 4; do echo testing $$i; test $$i -le 2 || exit; done
$ make check1
for i in 1 2 3 4; do echo testing $i; test $i -le 2 || break; done
testing 1
testing 2
testing 3
$ make check2
for i in 1 2 3 4; do echo testing $i; test $i -le 2 || exit; done
testing 1
testing 2
testing 3
make: *** [check2] Error 1
$ exit
^ permalink raw reply
* Re: new file leaked onto release branch
From: Tom Prince @ 2005-12-14 21:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brown, Len, Linus Torvalds, git
In-Reply-To: <7virtrxv9c.fsf@assigned-by-dhcp.cox.net>
On Wed, Dec 14, 2005 at 12:45:51PM -0800, Junio C Hamano wrote:
>
> I pointed out one anomaly which is the commit should never have
> been created because it was not even a fast forward but already
> up-to-date case, and it was followed up with exchange of a few
> messages between Linus and you.
>
I don't remember any of the details now, but I remember that an old
version of git or cogito would create bogus fast-forward merges, if they
were used without GNU coreutils. The machine it happend on was running
FreeBSD 4.10, but current versions work fine.
Tom
^ permalink raw reply
* Re: git cole give unexpected error message
From: Sam Ravnborg @ 2005-12-14 21:20 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051213222829.GE22159@pasky.or.cz>
On Tue, Dec 13, 2005 at 11:28:29PM +0100, Petr Baudis wrote:
> Dear diary, on Tue, Dec 13, 2005 at 10:28:20PM CET, I got a letter
> where Sam Ravnborg <sam@ravnborg.org> said that...
> > cogito being a nice porcelain gives the git errormessage but manage to
> > clean up when the clone fails.
> > So also cogito would benefit from a more descriptive errormessage.
>
> Well, git clone can fail for many reasons and I don't think the "no such
> repository" one is completely overwhelming, so hinting that by Cogito
> could be quite confusing (theme of the day: usability ;-)).
>
> The real solution would be proper error reporting by the git daemon.
Which was my point too.
When using cogito it displyed the git error message so having git to
print a sensible error message would also benefit cogito.
Sam
^ permalink raw reply
* Tracking files across tree reorganizations
From: H. Peter Anvin @ 2005-12-14 21:15 UTC (permalink / raw)
To: Git Mailing List
Did anything ever happen with that?
-hpa
^ permalink raw reply
* [PATCH] Do not ignore errors during make check
From: Amos Waterland @ 2005-12-14 21:09 UTC (permalink / raw)
To: junkio; +Cc: git
Do not let errors pass by unnoticed when running `make check'.
Signed-off-by: Amos Waterland <apw@us.ibm.com>
---
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
20898ba8a3c6f78bb136626fddc34221df427116
diff --git a/Makefile b/Makefile
index 01b6643..3f62bcb 100644
--- a/Makefile
+++ b/Makefile
@@ -449,7 +449,7 @@ test-delta$X: test-delta.c diff-delta.o
$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $^
check:
- for i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i; done
+ for i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i || break; done
--
0.99.9.GIT
^ permalink raw reply related
* Re: new file leaked onto release branch
From: Junio C Hamano @ 2005-12-14 20:45 UTC (permalink / raw)
To: Brown, Len; +Cc: Linus Torvalds, Junio C Hamano, git
In-Reply-To: <F7DC2337C7631D4386A2DF6E8FB22B30056B83F2@hdsmsx401.amr.corp.intel.com>
"Brown, Len" <len.brown@intel.com> writes:
> Should I be using something different than git merge?
> is Documentation/howto/using-topic-branches out of date?
I reviewed it once again right now. The document claims to be
last updated for 0.99.9f, but I do not see anything outdated in
there for the latest. Tony's procedure looks valid [*1*], so do
the scripts you sent in this thread.
Sorry, but I do not seem to be able to spot anything obviously
wrong with your troubled commits nor scripts. I'll do some more
digging, including rewinding to an older git and trying them,
but I am pessimistic.
I pointed out one anomaly which is the commit should never have
been created because it was not even a fast forward but already
up-to-date case, and it was followed up with exchange of a few
messages between Linus and you. But even if we got that mixed
up, the resulting merge should not have contained the file
neither parents had. That part worries me the most.
One question. You mentioned these in your message, you have
a "git.commit wrapper" that contains these lines:
git-update-index --add --remove `quilt files`
git commit
I am not familiar with 'quilt', but is "quilt files" the command
to show the list of files with patches applied to the working
tree?
If so, the above do tell git about the modified (including added
or removed) files that the applied quilt patches touch, which
sounds like the correct thing to do.
But the resulting commit from that procedure would not be a
merge commit, and the commit in question that had the rsinfo
file magically appeared from nowhere is a merge, so this does
not seem to have much to do with the current problem...
Still puzzlled, sorry.
[Footnote]
*1* Except that the rsync transport is probably suboptimal for
people who stay reasonably up-to-date with Linus and I would
apply the following change if I were Tony, but that shouldn't
have anything to do with the trouble we are discussing here.
---
diff --git a/Documentation/howto/using-topic-branches.txt b/Documentation/howto/using-topic-branches.txt
index 4698abe..4944297 100644
--- a/Documentation/howto/using-topic-branches.txt
+++ b/Documentation/howto/using-topic-branches.txt
@@ -31,7 +31,7 @@ test tree and then pull to the release t
patches blocked in the test tree waiting for complex changes to accumulate
enough test time to graduate.
-Back in the BitKeeper days I achieved this my creating small forests of
+Back in the BitKeeper days I achieved this by creating small forests of
temporary trees, one tree for each logical grouping of patches, and then
pulling changes from these trees first to the test tree, and then to the
release tree. At first I replicated this in GIT, but then I realised
@@ -42,7 +42,8 @@ So here is the step-by-step guide how th
First create your work tree by cloning Linus's public tree:
- $ git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git work
+ $ git clone \
+ master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6.git work
Change directory into the cloned tree you just created
@@ -52,7 +53,7 @@ Set up a remotes file so that you can fe
branch into a local branch named "linus":
$ cat > .git/remotes/linus
- URL: rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
+ URL: master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Pull: master:linus
^D
^ permalink raw reply related
* RE: new file leaked onto release branch
From: Linus Torvalds @ 2005-12-14 20:10 UTC (permalink / raw)
To: Brown, Len; +Cc: Junio C Hamano, git
In-Reply-To: <F7DC2337C7631D4386A2DF6E8FB22B30056B83F2@hdsmsx401.amr.corp.intel.com>
On Wed, 14 Dec 2005, Brown, Len wrote:
>
> >So Len, since you seem to use "git merge" in your scripts, I
> >suspect you have an old version of git lying around. Can you try doing just
>
> Should I be using something different than git merge?
No, "git merge" should be fine. It's what "git pull" ends up doing
internally, which is why I suspected an old git version: "git merge"
should be well-tested, since it's very much what I end up using every day
when I pull stuff.
> > git merge-base -a 0a47c906342e2447003e207d23917dfa5c912071 d2149b542382bfc206cb28485108f6470c979566
> >
> >to see what the result is for you?
>
> $ git merge-base -a 0a47c906342e2447003e207d23917dfa5c912071 d2149b542382bfc206cb28485108f6470c979566
> d2149b542382bfc206cb28485108f6470c979566
Ok, that's correct.
git-merge does:
common=$(git-merge-base --all $head "$@")
and then it _should_ have triggered this case:
case "$#,$common,$no_commit" in
..
1,"$1",*)
# If head can reach all the merge then we are up to date.
# but first the most common case of merging one remote
echo "Already up-to-date."
dropsave
exit 0
;;
..
and thus never have created any merge messages.
That's what I get when I try this:
git checkout -b test-merge 0a47c906342e2447003e207d23917dfa5c912071
git merge "Testing merging" HEAD d2149b542382bfc206cb28485108f6470c979566
results in a very immediate
"Already up-to-date."
message. Does it do that for you too?
I tested not only with current git, but also the gits that were valid on
Nov 29 and Nov 30. All of them did this.
> Doesn't appear to be the case, as I don't have a /usr/bin/git
> IIR, months ago I tried to install the rpm and
> it failed due to some incompatibility like not groking
> a SuSE destination. I got Dave's git tarball according
> to Jeff's howto: http://linux.yyz.us/git-howto.html
> and have been building and installing from a git repo since.
> (I found git-current tarball dated 7/21/05, so maybe it was then)
> I did, however a few months ago copy my i386 home directory over to the
> x86_64 box I use now, re-build and re-install. Dunno
> if there may have been a hickup in that process...
> I found a backup copy of my i386 bin directory from 2005-08-25 --
> binaries still in i386 format. But I don't think I ran that b/c
> it isn't on any PATH. Git lives in ~/bin which is 1st in my PATH.
Hmm. It really looks like it should have been impossible to generate that
commit with current git, which is why I'm still a bit suspicious.
> I think the lesson I'm taking away from this is that
> as I continue to stumble forward using git I should
> immediately report anything that doesn't look quite right
> while I can still guarantee that all the clues are still
> at the scene of the crime.
I think this list has been pretty responsive to reports of strange
behaviour, so yes.
Linus
^ permalink raw reply
* RE: new file leaked onto release branch
From: Brown, Len @ 2005-12-14 19:20 UTC (permalink / raw)
To: Linus Torvalds, Junio C Hamano; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 1813 bytes --]
>So Len, since you seem to use "git merge" in your scripts, I
>suspect you have an old version of git lying around. Can you try doing just
Should I be using something different than git merge?
is Documentation/howto/using-topic-branches out of date?
> git merge-base -a
>0a47c906342e2447003e207d23917dfa5c912071
>d2149b542382bfc206cb28485108f6470c979566
>
>to see what the result is for you?
$ git merge-base -a 0a47c906342e2447003e207d23917dfa5c912071 d2149b542382bfc206cb28485108f6470c979566
d2149b542382bfc206cb28485108f6470c979566
>Also, maybe the _reason_ you have an old git lying around is
>that you have two installations
Doesn't appear to be the case, as I don't have a /usr/bin/git
IIR, months ago I tried to install the rpm and
it failed due to some incompatibility like not groking
a SuSE destination. I got Dave's git tarball according
to Jeff's howto: http://linux.yyz.us/git-howto.html
and have been building and installing from a git repo since.
(I found git-current tarball dated 7/21/05, so maybe it was then)
I did, however a few months ago copy my i386 home directory over to the
x86_64 box I use now, re-build and re-install. Dunno
if there may have been a hickup in that process...
I found a backup copy of my i386 bin directory from 2005-08-25 --
binaries still in i386 format. But I don't think I ran that b/c
it isn't on any PATH. Git lives in ~/bin which is 1st in my PATH.
I think the lesson I'm taking away from this is that
as I continue to stumble forward using git I should
immediately report anything that doesn't look quite right
while I can still guarantee that all the clues are still
at the scene of the crime. I expect that I've re-built
and re-installed git several times since the merge
in question was made.
-Len
[-- Attachment #2: to-linus --]
[-- Type: application/octet-stream, Size: 141 bytes --]
git merge-base -a 0a47c906342e2447003e207d23917dfa5c912071 d2149b542382bfc206cb28485108f6470c979566
d2149b542382bfc206cb28485108f6470c979566
^ permalink raw reply
* Re: [PATCH] Make git-send-pack exit with error when some refs cou ldn't be pushed out
From: Petr Baudis @ 2005-12-14 19:01 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Git List
In-Reply-To: <1134576909.2478.53.camel@cashmere.sps.mot.com>
Dear diary, on Wed, Dec 14, 2005 at 05:15:09PM CET, I got a letter
where Jon Loeliger <jdl@freescale.com> said that...
> On Tue, 2005-12-13 at 20:30, Petr Baudis wrote:
> > Jonas only reported it on IRC as weird cg-commit behaviour (which it
>
> Gah. Are we IRCing now too these days? Did I miss a step
> or an announcment?
I mentioned the #git channel on the FreeNode network in several Cogito
announcements, but this problem report was actually in a different
channel (#elinks, since it occurred during work on ELinks) and it
wouldn't make a difference if it was on a query or in a private mail.
> I thought we were all doing a reasonably good job of communicating
> here on list...
Sure, all important things are going on here, but it's often much more
convenient to do some troubleshooting and stuff over IRC, and way too
many people also mail me privately (sometimes it makes sense, sometimes
they would be better off cc'ing the list).
#git serves mainly as quick help wrt. GIT usage, sometimes people report
problems there (but for non-Cogito problems, I usually redir them to the
mailing list), and sometimes (but quite rarely) larger feature-wise
discussion spins out; but if it's about to get anything near real, it
usually hits the mailing list anyway. Oh, and CIA reports Cogito commits
on the channel.
The only IRC-only effort ever (so far) was I believe adding the
cg-switch command.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* RE: new file leaked onto release branch
From: Brown, Len @ 2005-12-14 18:27 UTC (permalink / raw)
To: Linus Torvalds, Junio C Hamano; +Cc: git
>Len, how old a git are you using? "git-merge" really should
>_never_ have done this, but old (and I mean really old)
>git merges sometimes got confused with the base parent
>and would create a merge even when it was unnecessary.
should be the top of tree on the day the merge was made.
I generally pull from git://git.kernel.org/pub/scm/git/git.git
at the beginning of the day, build it and install it.
Right now git --version answers 0.99.9.GIT
-Len
^ permalink raw reply
* Re: StGIT usage
From: Don Zickus @ 2005-12-14 17:02 UTC (permalink / raw)
To: git
In-Reply-To: <20051214165304.GA9272@ferdyx.org>
> If import will do once at a time, and you are sure all of them apply
> cleanly; why don't you just use a for + import over the patches ?
>
Patch ordering is important to me. I didn't want re-invent the wheel,
so to speak. :)
I can easily create my own 'series' file and iterate through that
while importing patches, but I wanted to see if that was already
built-in.
Cheers,
Don
^ permalink raw reply
* Re: new file leaked onto release branch
From: Linus Torvalds @ 2005-12-14 16:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Len Brown, git
In-Reply-To: <Pine.LNX.4.64.0512140822540.3292@g5.osdl.org>
On Wed, 14 Dec 2005, Linus Torvalds wrote:
>
> Argh.
>
> Len, how old a git are you using? "git-merge" really should _never_ have
> done this, but old (and I mean really old) git merges sometimes got
> confused with the base parent and would create a merge even when it was
> unnecessary.
Going through the real kernel tree, this has happened before:
commit 8e9887cc3b8d9f1c88c6f3842346a9478e52718f
Merge: 0a47c906342e2447003e207d23917dfa5c912071 d2149b542382bfc206cb28485108f6470c979566
Author: Len Brown <len.brown@intel.com>
Date: Wed Nov 30 22:22:52 2005 -0500
Auto-update from upstream
and doing a
git-merge-base -a 0a47c906342 d2149b542
results in the second parent: d2149b542382bfc206cb28485108f6470c979566.
We also have two old ones:
commit b129a8ccd53f74c43e4c83c8e0031a4990040830
commit 603fff54420a0ccc4c3b48bfef43896fb4e33161
but both of those are from June, and of known causes (Russell King using
an old git that didn't clean up after a failed merge, and he ended up
committing a perfectly normal change as a bogus merge because git would
remember that broken MERGE_HEAD).
So Len, since you seem to use "git merge" in your scripts, I suspect you
have an old version of git lying around. Can you try doing just
git merge-base -a 0a47c906342e2447003e207d23917dfa5c912071 d2149b542382bfc206cb28485108f6470c979566
to see what the result is for you?
Also, maybe the _reason_ you have an old git lying around is that you have
two installations - if you have at some point installed both an RPM _and_
recompiled your own git, you may have different git versions in ~/bin and
in /usr/bin, and then depending on how you log in to the machine, you may
end up with different versions being used..
Linus
^ permalink raw reply
* Re: StGIT usage
From: Fernando J. Pereda @ 2005-12-14 16:53 UTC (permalink / raw)
To: git
In-Reply-To: <68948ca0512140844u677fea36ob94bdf213a6a110@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 574 bytes --]
On Wed, Dec 14, 2005 at 11:44:34AM -0500, Don Zickus wrote:
| I couldn't find in the StGIT documentation on how to use a 'series'
| file or to pull a whole bunch of patches from a directory. It seems
| the import command could only handle a patch at a time. Any
| tips/help?
If import will do once at a time, and you are sure all of them apply
cleanly; why don't you just use a for + import over the patches ?
Cheers,
Ferdy
--
Fernando J. Pereda Garcimartín
Gentoo Developer (Alpha,net-mail,mutt,git)
20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* StGIT usage
From: Don Zickus @ 2005-12-14 16:44 UTC (permalink / raw)
Cc: git
I couldn't find in the StGIT documentation on how to use a 'series'
file or to pull a whole bunch of patches from a directory. It seems
the import command could only handle a patch at a time. Any
tips/help?
Cheers,
Don
^ 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