* Re: What's in git.git
From: Junio C Hamano @ 2006-03-22 5:46 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <867j6nm47b.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
>>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
>
>>> But this wastes a commit. Is there any way to get an index that simply
>>> includes the file from that other branch?
>
> Junio> $ git checkout master
> Junio> $ git checkout next git-cvsimport.perl
>
> Yow. How simple is *that*? Thanks.
There is one thing you would want to be careful about.
This updates the index.
^ permalink raw reply
* Re: What's in git.git
From: Randal L. Schwartz @ 2006-03-22 5:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vacbjawyu.fsf@assigned-by-dhcp.cox.net>
>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
>> But this wastes a commit. Is there any way to get an index that simply
>> includes the file from that other branch?
Junio> $ git checkout master
Junio> $ git checkout next git-cvsimport.perl
Yow. How simple is *that*? Thanks.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: What's in git.git
From: Junio C Hamano @ 2006-03-22 5:07 UTC (permalink / raw)
To: git
In-Reply-To: <86hd5rma75.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
> For example, I can do this:
>
> $ git-checkout next
> $ cp git-cvsimport.perl DUMMY
> $ git-checkout -b my-playground
> $ mv DUMMY git-cvsimport.perl
> $ git-commit -a -m 'trying that other version'
>
> But this wastes a commit. Is there any way to get an index that simply
> includes the file from that other branch?
$ git checkout master
$ git checkout next git-cvsimport.perl
^ permalink raw reply
* git daemon and v6-only
From: Jeff Garzik @ 2006-03-22 5:04 UTC (permalink / raw)
To: Git Mailing List
Regarding the following code in daemon.c socksetup():
> #ifdef IPV6_V6ONLY
> if (ai->ai_family == AF_INET6) {
> int on = 1;
> setsockopt(sockfd, IPPROTO_IPV6, IPV6_V6ONLY,
> &on, sizeof(on));
> /* Note: error is not fatal */
> }
> #endif
On Linux this causes you to bind separately to v4 and v6 interfaces,
avoiding the default (desired) behavior of using a single socket for
both v4 and v6.
Jeff
^ permalink raw reply
* Re: Cloning from sites with 404 overridden
From: Linus Torvalds @ 2006-03-22 4:13 UTC (permalink / raw)
To: Shawn Pearce; +Cc: linux, git
In-Reply-To: <20060322031200.GB17954@spearce.org>
On Tue, 21 Mar 2006, Shawn Pearce wrote:
>
> '0' x 40. :-) There's some places already in the GIT source
> which would have ``issues'' if they got an object with this hash.
> Not sure if it is actually an entirely impossible hash or just one
> that is highly improbable.
The all-zeroes hash is as improbable as any other one, and finding a
"collision" (ie a "real object") with that hash is as improbable as any
other collision, ie we can (and do) depend on it beign a unique identifier
for "does not exist".
Linus
^ permalink raw reply
* [PATCH] Clean up after failed "git merge" in the tutorial script
From: Pavel Roskin @ 2006-03-22 4:07 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
From: Pavel Roskin <proski@gnu.org>
Failed "git merge" in the tutorial script leaves some damage to the
working directory. Use cg-reset to clean up the mess.
This eliminates conflicts in the final merge. Adjust code accordingly,
remove unused fixup scripts.
Adjust 0017-alice-bob-fixup.ed to deal with merge conflict from cg-merge
rather than "git merge".
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
.../tutorial-script/0017-alice-bob-fixup.ed | 4 ++--
.../tutorial-script/0021-bob-alice-fixup1.ed | 4 ----
.../tutorial-script/0022-bob-alice-fixup2.ed | 5 -----
.../tutorial-script/0023-bob-alice-fixup3.ed | 4 ----
Documentation/tutorial-script/script.sh | 18 ++++--------------
5 files changed, 6 insertions(+), 29 deletions(-)
diff --git a/Documentation/tutorial-script/0017-alice-bob-fixup.ed b/Documentation/tutorial-script/0017-alice-bob-fixup.ed
index ad04eb7..1b06f4e 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
+/^<<<<<<< master/d
/^=======/,/^=======/+1d
-/^>>>>>>> \.merge_file_/d
+/^>>>>>>> bob/d
w
q
diff --git a/Documentation/tutorial-script/0021-bob-alice-fixup1.ed b/Documentation/tutorial-script/0021-bob-alice-fixup1.ed
deleted file mode 100644
index df703d5..0000000
--- a/Documentation/tutorial-script/0021-bob-alice-fixup1.ed
+++ /dev/null
@@ -1,4 +0,0 @@
-/^<<<<<<< master/,/^=======/d
-/^>>>>>>> origin/d
-w
-q
diff --git a/Documentation/tutorial-script/0022-bob-alice-fixup2.ed b/Documentation/tutorial-script/0022-bob-alice-fixup2.ed
deleted file mode 100644
index d8c5746..0000000
--- a/Documentation/tutorial-script/0022-bob-alice-fixup2.ed
+++ /dev/null
@@ -1,5 +0,0 @@
-/^#include "stack\.h"/+1d
-/^#include "lexer\.h"/+1,/^#include "stack\.h"/d
-/^<<<<<<< master/-1,/^>>>>>>> origin/d
-w
-q
diff --git a/Documentation/tutorial-script/0023-bob-alice-fixup3.ed b/Documentation/tutorial-script/0023-bob-alice-fixup3.ed
deleted file mode 100644
index fea2fc7..0000000
--- a/Documentation/tutorial-script/0023-bob-alice-fixup3.ed
+++ /dev/null
@@ -1,4 +0,0 @@
-/^#endif/s;^#endif.*;#endif /* STACK_H */;
-w
-q
-
diff --git a/Documentation/tutorial-script/script.sh b/Documentation/tutorial-script/script.sh
index 0401954..f07dfc1 100755
--- a/Documentation/tutorial-script/script.sh
+++ b/Documentation/tutorial-script/script.sh
@@ -222,12 +222,13 @@ git merge "Integrate changes from Bob an
# Automatic 3-way merge fails! Have to do it step by step
+cg-reset
cg-merge bob && should_fail
# Merge fails:
#: ...
-#: <<<<<<< Makefile
+#: <<<<<<< master
#: $(CC) $(CFLAGS) $^ -lm -o $@
#: =======
#: $(CC) $(CFLAGS) $^ -o $@
@@ -235,7 +236,7 @@ cg-merge bob && should_fail
#: rpn.o: stack.h
#: stack.o: stack.h
#: lexer.o:
-#: >>>>>>> .merge_file_iNhznP
+#: >>>>>>> bob
ed Makefile < $TOP/0017-alice-bob-fixup.ed
@@ -313,18 +314,7 @@ cg-fetch
git verify-tag rpn-0.4 && should_fail
# Everything's OK, integrate the changes
-echo "Merge with 0.4" | cg-merge && should_fail
-
-# Merge conflicts in Makefile, rpn.c
-ed Makefile < $TOP/0021-bob-alice-fixup1.ed
-ed rpn.c < $TOP/0022-bob-alice-fixup2.ed
-# Resolve conflicting addition of two versions of stack.h
-rm stack.h~master
-mv stack.h~origin stack.h
-cg-add stack.h
-
-# Now commit the whole
-cg-commit -m "Merge with 0.4"
+cg-merge
# Great, we are done.
trap - exit
^ permalink raw reply related
* Re: [PATCH] Don't use merge labels in the ed scripts
From: Pavel Roskin @ 2006-03-22 4:07 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060321214818.GY19263@pasky.or.cz>
Hi, Petr!
On Tue, 2006-03-21 at 22:48 +0100, Petr Baudis wrote:
> > > 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.
It turns out those labels were produced by "git merge". Either "git
merge" should be removed from the test, or "cg-reset" should be used
after the failure. I prefer the later since it's another test for
Cogito.
Once the mess from "git merge" is cleaned up, it turns out that the last
merge in the testsuite doesn't fail, and several final fixups are no
longer needed. I think it should be OK to remove corresponding code.
It has no Cogito commands other than cg-commit, which is already tested
elsewhere.
I'm sending you the new patch.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: What's in git.git
From: Randal L. Schwartz @ 2006-03-22 3:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <86y7z3mdcz.fsf@blue.stonehenge.com>
>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
Randal> I'm waiting for that CVS tree to change again. It changes every
Randal> 4-5 days.
Speaking of which, I *know* you sent me a patch to apply to incorporate the
one difference, but is there a more automatic way of cherry-picking
git-cvsimport.perl from "next" into a new topic branch of mine?
For example, I can do this:
$ git-checkout next
$ cp git-cvsimport.perl DUMMY
$ git-checkout -b my-playground
$ mv DUMMY git-cvsimport.perl
$ git-commit -a -m 'trying that other version'
But this wastes a commit. Is there any way to get an index that simply
includes the file from that other branch?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: Cloning from sites with 404 overridden
From: Shawn Pearce @ 2006-03-22 3:12 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20060322025921.1722.qmail@science.horizon.com>
'0' x 40. :-) There's some places already in the GIT source
which would have ``issues'' if they got an object with this hash.
Not sure if it is actually an entirely impossible hash or just one
that is highly improbable.
My own website has this problem and its because I'm using WordPress
to handle all URLs on the site; I haven't yet found a way to
configure WordPress to return a proper 404 when the URL can't be
mapped to something on the server. Note that 404 status codes can
in fact return pretty HTML content for the user, and many websites
do this and many browsers display that pretty HTML. But a bot can
then also recognize the status code and DTRT.
The webservers are just plain broken, mine included. I think the
best option is to delay corrupt object reporting to the end of
the download process if you get only one corrupt object and that
corrupt object was actually attainable from a pack. And in this
case its just a minor warning:
Warning: The server appears to not return proper HTTP status
codes on missing files. The files were found in one or
more packs so the download is OK, but the server administrator
should really fix their server. If you know the server
administrator you might want to prod them to do so.
But that's already been suggested and I thought someone worked up
a patch based on that idea? If not I could try to do so since my
own damn server has the problem. :-)
linux@horizon.com wrote:
> If someone feels ambitious, you can detect this condition automatically
> by searching for a file that you know won't be there and seeing if you
> get a 404 response to that.
>
> To avoid punishing good servers, it would be nice to defer the test
> until reciving the first corrupted object.
>
> I'm not sure what the best "object that's not supposed to be there" is.
> It could just be a random hash, or would a malformed object file name
> be better? Any fixed name has a finite chance of being created by
> someone somewhere, but generating 160-bit random numbers is a PITA on
> non-freenix platforms.
>
>
> (As an aside, I suspect this is all caused by Microsoft's "friendly HTML
> error messages" invention.)
--
Shawn.
^ permalink raw reply
* Re: Cloning from sites with 404 overridden
From: linux @ 2006-03-22 2:59 UTC (permalink / raw)
To: git
If someone feels ambitious, you can detect this condition automatically
by searching for a file that you know won't be there and seeing if you
get a 404 response to that.
To avoid punishing good servers, it would be nice to defer the test
until reciving the first corrupted object.
I'm not sure what the best "object that's not supposed to be there" is.
It could just be a random hash, or would a malformed object file name
be better? Any fixed name has a finite chance of being created by
someone somewhere, but generating 160-bit random numbers is a PITA on
non-freenix platforms.
(As an aside, I suspect this is all caused by Microsoft's "friendly HTML
error messages" invention.)
^ permalink raw reply
* Re: What's in git.git
From: Randal L. Schwartz @ 2006-03-22 2:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodzzb5q3.fsf@assigned-by-dhcp.cox.net>
>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
Junio> - cvsimport post-import checkout fix.
Junio> Earlier we had a workaround to deal with people who import
Junio> into the current branch by not checking out. After
Junio> incrementally importing from the same CVS repository again,
Junio> however, the code did update the branch head. This made the
Junio> working tree and the index stale and was causing more
Junio> confusion than it avoided.
Junio> This fix is to make re-importing act more like git-pull, not
Junio> git-fetch. So if you run an incremental import into the
Junio> current branch, it tries to fast-forward the working tree and
Junio> index (your current branch head, index and working tree had
Junio> better be pristine with respect to the CVS repository for
Junio> this, but that is already an requirement for a tracking
Junio> branch anyway) when your current branch is the tracking
Junio> branch, or merge the imported result into your current branch
Junio> if you are using a separate tracking branch.
Junio> I've done some testing on this myself, but am waiting for
Junio> independent confirmations from cvsimport users. Merlyn?
I'm waiting for that CVS tree to change again. It changes every
4-5 days.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* What's in git.git
From: Junio C Hamano @ 2006-03-22 1:58 UTC (permalink / raw)
To: git
* The 'master' branch has these since the last announcement.
- git.el updates (Alexandre Julliard)
- git-svn updates (Eric Wong)
- git-blame updates (Fredrik Kuivinen)
- documentation updates (Francis Daly, Jon Loeliger)
- Makefile: Add TAGS and tags targets (Fredrik Kuivinen)
- http-push support for deleting remote branches (Nick Hengeveld)
- assorted minor fixes and tweaks (Alexandre Julliard, Mark
Hollomon, Shawn Pearce, Yasushi SHOJI, Nicolas Pitre, Randal
L. Schwartz and me)
* The 'next' branch, in addition, has two important fixes and
enhancements, and it probably is a good time to do a 1.3
release when they graduate to "master" and prove stable.
- quicker and dirtier rename detection by Linus and me.
I've been using this myself and haven't seen major
misdetection so far, but I do not use much renames. Maybe
it's time to push this out and see what happens. This is
_not_ the "important" part.
- cvsimport post-import checkout fix.
Earlier we had a workaround to deal with people who import
into the current branch by not checking out. After
incrementally importing from the same CVS repository again,
however, the code did update the branch head. This made the
working tree and the index stale and was causing more
confusion than it avoided.
This fix is to make re-importing act more like git-pull, not
git-fetch. So if you run an incremental import into the
current branch, it tries to fast-forward the working tree and
index (your current branch head, index and working tree had
better be pristine with respect to the CVS repository for
this, but that is already an requirement for a tracking
branch anyway) when your current branch is the tracking
branch, or merge the imported result into your current branch
if you are using a separate tracking branch.
I've done some testing on this myself, but am waiting for
independent confirmations from cvsimport users. Merlyn?
- refs/remotes support.
This has been the recent hot topic, on git-clone.
First, not so controversial one. A new option --reference
can be used to help cloning a project similar to what you
already have over thin wire:
$ git clone --reference /git/linux-2.6.git \
git://git.kernel.org/pub/.../jgarzik/libata-dev.git/ \
libata-dev
What happens here is that the new repository (libata-dev you
are creating by cloning from Jeff) is set up to borrow from
vanilla Linus repository you already keep track of, and the
initial clone downloads and expands objects that are only
present in Jeff's tree.
Another new option, --use-separate-remote, changes the way
$GIT_DIR/remotes/origin file and your tracking branches are
set up after the initial cloning. Without it, all the remote
heads are copied to your $GIT_DIR/refs/heads/ and a copy of
the remote HEAD is made as $GIT_DIR/refs/heads/origin, and
remotes/origin file is set up to keep this structure up to
date. This is the traditional behaviour.
When --use-separate-remote is in effect, the tracking
branches are created in $GIT_DIR/refs/remotes/origin/ and you
will not get the extra "origin" head. Your local branch
namespace under $GIT_DIR/refs/heads/ will only have "master".
In addition, a symref $GIT_DIR/refs/remotes/origin/HEAD
points at the primary branch of the remote repository.
Similar to a filename in $GIT_DIR/refs/{heads,tags} that can
be used to name a ref (e.g. when you say "git diff frotz",
you are telling git to read from $GIT_DIR/refs/heads/frotz
and use that commit ID to diff your working tree against), a
directory that has such a symref under $GIT_DIR/refs/remotes
can be used to name the ref. IOW, "git diff origin" in a
repository a cloned this way means you want a diff against
$GIT_DIR/refs/remotes/origin/HEAD.
I've done reasonable amount of testing over git:// transport,
and some with http:// as well, but I do not know if rsync://
works at all (I never use rsync:// transport myself). If
anybody cares about rsync:// transport, please test it while
it still is in "next" to keep things working for you.
A new configuration option, 'core.warnambiguousrefs', can be
set to warn you if you use "frotz" to name a ref when you
have more than one "frotz" under $GIT_DIR/refs (e.g. you have
both branch "frotz" and tag "frotz", and/or you have
refs/remotes/frotz/HEAD).
It also has changes by Eric Wong to teach git-fetch about
$GIT_DIR/refs/remotes hierarchy.
^ permalink raw reply
* [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
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