* Re: [PATCH v2 1/3] t7700: demonstrate mishandling of objects in packs with a .keep file
From: Junio C Hamano @ 2008-11-04 23:55 UTC (permalink / raw)
To: Brandon Casey; +Cc: Shawn O. Pearce, Git Mailing List, Nicolas Pitre
In-Reply-To: <muOuA1nLBoljLnZoguxeFeKt-8Q-I9Y3ljvxnLWLt9KyA8HwVtMa4Q@cipher.nrlssc.navy.mil>
Thanks; queued.
^ permalink raw reply
* Re: [PATCH 5/5] git send-email: turn --compose on when more than one patch.
From: Junio C Hamano @ 2008-11-04 23:54 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <1225815858-30617-6-git-send-email-madcoder@debian.org>
Pierre Habouzit <madcoder@debian.org> writes:
> Automatically turn --compose on when there is more than one patch, and
> that the output is a tty.
I do not think this is a good idea. I suspect I am not the only person
who uses "format-patch --cover-letter", edit the files to review and
prepare, and runs send-email to fire them off.
^ permalink raw reply
* Re: [PATCH 4/5] git send-email: ask less questions when --compose is used.
From: Junio C Hamano @ 2008-11-04 23:54 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <1225815858-30617-5-git-send-email-madcoder@debian.org>
Pierre Habouzit <madcoder@debian.org> writes:
> + print C <<EOT;
> +From $tpl_sender # This line is ignored.
> +GIT: Lines beginning in "GIT: " will be removed.
> +GIT: Consider including an overall diffstat or table of contents
> +GIT: for the patch you are writing.
> +GIT:
> +GIT: Clear the body content if you don't wish to send a summary.
> +From: $tpl_sender
> +Subject: $tpl_subject
> +In-Reply-To: $tpl_reply_to
> +
Somebody already suggested this but I really think GIT: lines should be at
the end and use '# ' prefix instead.
With the ability to give --cover-letter option to underlying format-patch
do you still need this?
> + my $editor = $ENV{GIT_EDITOR} || Git::config(@repo, "core.editor") || $ENV{VISUAL} || $ENV{EDITOR} || "vi";
> +
> + if ($annotate) {
> + do_edit($compose_filename, @files);
> + } else {
> + do_edit($compose_filename);
> + }
Don't we want to abort the whole process when the user kills the editor
instead of normal exit (iow, do_edit() which is system() reports that the
editor was killed)?
^ permalink raw reply
* Re: [PATCH 2/5] git send-email: interpret unknown files as revision lists
From: Junio C Hamano @ 2008-11-04 23:54 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <1225815858-30617-3-git-send-email-madcoder@debian.org>
Pierre Habouzit <madcoder@debian.org> writes:
> diff --git a/git-send-email.perl b/git-send-email.perl
> index aaace02..c29868a 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -22,8 +22,11 @@ use Term::ReadLine;
> use Getopt::Long;
> use Data::Dumper;
> use Term::ANSIColor;
> +use File::Temp qw/ tempdir /;
We seem to use File::Temp::tempdir already elsewhere, but they are in
archimport, cvsexportcommit and cvsserver, all of which are rather rarely
used ones. I think this is Perl 5.6.1 addition. Is everybody Ok with
this dependency? Just double checking.
> @@ -363,10 +366,22 @@ if (@alias_files and $aliasfiletype and defined $parse_alias{$aliasfiletype}) {
>
> ($sender) = expand_aliases($sender) if defined $sender;
>
> +sub check_file_rev_conflict($) {
> + my $f = shift;
> + if ($repo->command('rev-parse', '--verify', '--quiet', $f)) {
> + die("revision/filename conflict on `$f'");
Perhaps wording this a bit more to the point? This is triggered when
'$f' can be both a filename or a revision, so...
File '$f' exists but it could also be the range of commits
to produce patches for. Please disambiguate by...
* Saying "./$f" if you mean a file; or
* Giving -F option if you mean a range.
Earlier I suggested that "origin^0" is a way for the user to disambiguate
favouring a rev, but such a filename can exist, so we cannot blindly
suggest to say "$f^0" here. I think adding -F (or --format-patch) option
to send-email to explicitly disable file/directory interpretation would be
a cleaner solution for this (and it would allow you to drive this from a
script without worrying about what garbage files you happen to have in the
working tree).
^ permalink raw reply
* Re: [(v2) PATCH 2/2] tag: Add more tests about mixing incompatible modes and options
From: Junio C Hamano @ 2008-11-04 23:47 UTC (permalink / raw)
To: Samuel Tardieu; +Cc: git
In-Reply-To: <20081104232036.19090.6085.stgit@arrakis.enst.fr>
Thanks; will queue.
^ permalink raw reply
* Re: git log -S doesn't find some commits
From: Junio C Hamano @ 2008-11-04 23:45 UTC (permalink / raw)
To: Bernt Hansen; +Cc: Johannes Schindelin, git
In-Reply-To: <alpine.DEB.1.00.0811050014310.30769@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Tue, 4 Nov 2008, Bernt Hansen wrote:
>
>> Commits B, C, and D are not included in the git log -S output even
>> though with gitk you can see that 'org-publish-validate-link' is in the
>> patch.
>
> It is not sufficient for it to be in the patch, it has to be added or
> deleted in whole. So for example if you had a line
>
> org-publish-validate-link Hello
>
> and you changed it to
>
> org-publish-validate-link World
>
> git log -SWorld will find the commit, but git log
> -Sorg-publish-validate-link will not.
It seems nobody has looked at the actual commits, but Dscho got it 80%
right.
There seems to be a misconception on what -S<foo> does. It does *NOT*
grep for string <foo> in the patch text. It counts number of <foo> in
preimage and postimage and decides that the commit is worth showing iff
they differ.
If you look at, for example (B):
http://repo.or.cz/w/org-mode.git?a=commitdiff;h=837c81ce51
You can see that in org-publish.el, org-publish-validate-link appears once
as removed and once as added, so the total number of the appearance of the
symbol in preimage and postimage are the same.
^ permalink raw reply
* Re: git pull regression?
From: Junio C Hamano @ 2008-11-04 23:37 UTC (permalink / raw)
To: Carlos R. Mafra; +Cc: git
In-Reply-To: <20081104222749.GA9296@localhost.aei.mpg.de>
"Carlos R. Mafra" <crmafra2@gmail.com> writes:
> It looks like a regression to me. I can finish
> the bisection if people in the list say that
> I am not making a mistake somewhere :-)
Interesting, and _sounds_ like a regression, but I do not think anybody
can tell if it is without looking at what .git/config and exact command
sequence you are using for this "git pull" and where you are starting
from.
^ permalink raw reply
* [(v2) PATCH 2/2] tag: Add more tests about mixing incompatible modes and options
From: Samuel Tardieu @ 2008-11-04 23:20 UTC (permalink / raw)
To: git
In-Reply-To: <20081104232031.19090.47633.stgit@arrakis.enst.fr>
Signed-off-by: Samuel Tardieu <sam@rfc1149.net>
---
t/t7004-tag.sh | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
index f0edbf1..f377fea 100755
--- a/t/t7004-tag.sh
+++ b/t/t7004-tag.sh
@@ -1090,4 +1090,15 @@ test_expect_success 'filename for the message is relative to cwd' '
git cat-file tag tag-from-subdir-2 | grep "in sub directory"
'
+# mixing modes and options:
+
+test_expect_success 'mixing incompatibles modes and options is forbidden' '
+ test_must_fail git tag -a
+ test_must_fail git tag -l -v
+ test_must_fail git tag -n 100
+ test_must_fail git tag -l -m msg
+ test_must_fail git tag -l -F some file
+ test_must_fail git tag -v -s
+'
+
test_done
^ permalink raw reply related
* [(v2) PATCH 1/2] tag: Check that options are only allowed in the appropriate mode
From: Samuel Tardieu @ 2008-11-04 23:20 UTC (permalink / raw)
To: git
If "git tag -d -l -v ..." is called, only "-l" is honored, which is
arbitrary and wrong. Also, unrecognized options are accepted in the
wrong modes, causing for example "git tag -n 100" to create a tag
named "100" while the user may have wanted to type "git tag -n100".
This patch checks that "git tag" knows in what mode it operates before
performing any operation and accepts only the related options.
Signed-off-by: Samuel Tardieu <sam@rfc1149.net>
---
builtin-tag.c | 19 ++++++++++++-------
1 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/builtin-tag.c b/builtin-tag.c
index 84db156..d339971 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -344,7 +344,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
const char *object_ref, *tag;
struct ref_lock *lock;
- int annotate = 0, sign = 0, force = 0, lines = 0,
+ int annotate = 0, sign = 0, force = 0, lines = -1,
list = 0, delete = 0, verify = 0;
const char *msgfile = NULL, *keyid = NULL;
struct msg_arg msg = { 0, STRBUF_INIT };
@@ -380,9 +380,19 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
}
if (sign)
annotate = 1;
+ if (argc == 0 && !(delete || verify))
+ list = 1;
+ if ((annotate || msg.given || msgfile || force) &&
+ (list || delete || verify))
+ usage_with_options(git_tag_usage, options);
+
+ if (list + delete + verify > 1)
+ usage_with_options(git_tag_usage, options);
if (list)
- return list_tags(argv[0], lines);
+ return list_tags(argv[0], lines == -1 ? 0 : lines);
+ if (lines != -1)
+ die("-n option is only allowed with -l.");
if (delete)
return for_each_tag_name(argv, delete_tag);
if (verify)
@@ -406,11 +416,6 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
}
}
- if (argc == 0) {
- if (annotate)
- usage_with_options(git_tag_usage, options);
- return list_tags(NULL, lines);
- }
tag = argv[0];
object_ref = argc == 2 ? argv[1] : "HEAD";
^ permalink raw reply related
* Re: [PATCH 1/3] tag: Do not allow to call "git tag" in more than one operating mode
From: Samuel Tardieu @ 2008-11-04 23:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vej1rqfar.fsf@gitster.siamese.dyndns.org>
* Junio C Hamano <gitster@pobox.com> [2008-11-04 14:47:40 -0800]
| I think this patch breaks "git tag -a" or "git tag -s", but I didn't try.
| Run
|
| $ git tag -s
|
| with and without your patch.
That's right. I didn't notice it because I developped the 2/3 at
the same time and tested with both applied at the same time.
I will resubmit the serie with the first two merged together,
as they are both short, on the same topic and fix the same
problem.
^ permalink raw reply
* Re: git log -S doesn't find some commits
From: Johannes Schindelin @ 2008-11-04 23:15 UTC (permalink / raw)
To: Bernt Hansen; +Cc: git
In-Reply-To: <87fxm7rtb7.fsf@gollum.intra.norang.ca>
Hi,
On Tue, 4 Nov 2008, Bernt Hansen wrote:
> Commits B, C, and D are not included in the git log -S output even
> though with gitk you can see that 'org-publish-validate-link' is in the
> patch.
It is not sufficient for it to be in the patch, it has to be added or
deleted in whole. So for example if you had a line
org-publish-validate-link Hello
and you changed it to
org-publish-validate-link World
git log -SWorld will find the commit, but git log
-Sorg-publish-validate-link will not.
Hth,
Dscho
^ permalink raw reply
* Re: git log -S doesn't find some commits
From: Pieter de Bie @ 2008-11-04 23:06 UTC (permalink / raw)
To: Bernt Hansen; +Cc: git
In-Reply-To: <87fxm7rtb7.fsf@gollum.intra.norang.ca>
On Nov 4, 2008, at 11:59 PM, Bernt Hansen wrote:
> o--o--o--o-------------------M--F--o-- .. --o master
> / /
> A--o-- .. --o--o-------------o--o--B--C--X--D
>
>
> where commits A, B, C, D, and F all modify lines with
> 'org-publish-validate-link'. M is a merge commit and X has an empty
> log
> message.
>
> $ git checkout 8ea076e2de2b3721bd813ea5a2df1b53d0c25055 # commit F
> $ git log -Sorg-publish-validate-link
B,C,X and D are not part of 'F', so why should they be included?
You can do something like 'git log -S... F D' to show commits that are
also in D, or git log --all to show all commits.
^ permalink raw reply
* git log -S doesn't find some commits
From: Bernt Hansen @ 2008-11-04 22:59 UTC (permalink / raw)
To: git
Hi!
The org-mode repository at git://repo.or.cz/org-mode.git has history
that looks like this:
o--o--o--o-------------------M--F--o-- .. --o master
/ /
A--o-- .. --o--o-------------o--o--B--C--X--D
where commits A, B, C, D, and F all modify lines with
'org-publish-validate-link'. M is a merge commit and X has an empty log
message.
$ git checkout 8ea076e2de2b3721bd813ea5a2df1b53d0c25055 # commit F
$ git log -Sorg-publish-validate-link
reports 3 commits
F, A, and something earlier than A
Commits B, C, and D are not included in the git log -S output even
though with gitk you can see that 'org-publish-validate-link' is in the
patch.
Am I doing something wrong or is this a bug?
$ git --version
git version 1.6.0.3.523.g304d0
I've marked the commits in column one below.
$ git log --pretty=oneline
F 8ea076e2de2b3721bd813ea5a2df1b53d0c25055 Updated org-publish.el (now version 1.8
e322abfd14267a154a06deb1e7ef5a432b17f68a Merge branch 'add-recursion-to-org-publ
6208fb43cb1bbab852560cf506c7d12674307492 Minor docstring fix.
df54646ab324b11e99279dc0b6dfa161a1c72c7d Fixed the Timeline node.
D 4dcecb97bf4586c26f7e955980caa7e9630ae9a7 More cleaning.
X eda5a993cab01acd6878ab6c982b075d2cba167b *** empty log message ***
C b05bc10e6794c902df679b906d8bd6ec3f5633a9 Cleaned up code.
B 837c81ce51d90427bbcc32b06d84505b1a1e6b2a Use alist instead of a hashtable.
960449c9e93725f791bd450d3c85fd71339efb09 Cleaned up the buffer.
bf09955fec57307616926959b31e19af42520db0 Bugfix for `org-archive-subtree'.
f247d16417f17140a5bd5d03db164cc74191d9c1 Added support for :maxlevel and :skip-e
bd172412fafaa0386762826677f9929c9c4fc41c Added support for recursive publication
96e96fa684585e9916f4d6cdde20d4df7ff3f7d7 Added (require 'erc-log).
Thanks for git!
Bernt
^ permalink raw reply
* Re: exporting the last N days of a repository
From: Geoff Russell @ 2008-11-04 22:49 UTC (permalink / raw)
To: git
In-Reply-To: <cc29171c0811030855s2fb0d7a5ncdfdd6acd7c71537@mail.gmail.com>
Apologies to Johannes and Bob who have tried to help
but I'm still having difficulties, here is my current non-working script:
------------------------------------------------------------------
#!/bin/sh
DIR=/tmp/gitdemo
# for testing just arbitrarily
# select the 15th most recent commit as our new origin
NEWORIGIN=$(git rev-list master@{15} | head -1)
echo $NEWORIGIN
# checkout earlist point we are interested in
# we want to drop any history before this point
git checkout $NEWORIGIN
# now make a new directory, initialise with new origin
# and apply all commits after that point
mkdir $DIR && (cd $DIR ; git init) && \
rsync -aHv --exclude=.git ./ $DIR && \
(cd $DIR ; git add . ; git commit -m "starting point" </dev/null ) && \
git fast-export $NEWORIGIN..master | (cd $DIR ; git fast-import )
----------------- end of script
The fast-import gives me a message I don't understand and doesn't
do the import.
^ permalink raw reply
* Re: [PATCH 1/3] tag: Do not allow to call "git tag" in more than one operating mode
From: Junio C Hamano @ 2008-11-04 22:47 UTC (permalink / raw)
To: Samuel Tardieu; +Cc: git
In-Reply-To: <20081104124207.18273.31679.stgit@arrakis.enst.fr>
Samuel Tardieu <sam@rfc1149.net> writes:
> If "git tag -d -l -v ..." is called, only "-l" is honored, which is
> arbitrary and wrong.
>
> This patch checks that "git tag" knows in what mode it operates before
> performing any operation.
>
> Signed-Off-By: Samuel Tardieu <sam@rfc1149.net>
s/-Off-B/off-b/;
I think this patch breaks "git tag -a" or "git tag -s", but I didn't try.
Run
$ git tag -s
with and without your patch.
^ permalink raw reply
* git pull regression?
From: Carlos R. Mafra @ 2008-11-04 22:27 UTC (permalink / raw)
To: git
Hi,
I tested git v1.6.0.3 today and noticed that git pull is
behaving strangely, compared to what I was used to with
v1.5.6.3
It no longer tells me "Already up-to-date." when it used
to, now it simply says nothing.
And when I pulled Linus tree for the kernel this morning
it downloaded the new commits but git didn't show the
diffstat.
Furthermore, it kept saying to me
"Your branch is behind 'origin/master' by 31 commits,
and can be fast-forwarded"
and git log was not showing the new commits.
At first I thought I had made some mistake with my repo,
but I searched the mailing list and there was a similar
case which was "fixed" after using 'git status' followed
by another 'git pull'. But in my case it did not help.
So I went back to v1.5.6.3 and everything was back
to normal.
After that I made some tests, and v1.6.0 was good
and v1.6.0.1 was bad, but I didn't bisect it
further.
It looks like a regression to me. I can finish
the bisection if people in the list say that
I am not making a mistake somewhere :-)
^ permalink raw reply
* Re: More help needed on merging unrelated repos
From: Christian MICHON @ 2008-11-04 22:30 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Git Mailing List
In-Reply-To: <4910C6F4.5010407@op5.se>
On Tue, Nov 4, 2008 at 11:04 PM, Andreas Ericsson <ae@op5.se> wrote:
> Ah, right. Octopus merge always does merge head reduction, but to do
> that it needs to find a common ancestor. When no such ancestor exists,
> it will fail (with a message like "shouldn't be doing octopus merge"?).
>
> If there's no "--no-reduce-heads" option to "git merge", I think you're
> screwed with getting that to happen in a single commit.
:(
>
> Oh wait.
>
> git merge i1 && git merge --no-commit i2 && git commit --amend
>
> might work. I'm still shooting from the hip though, and now it's far too
> late for me to think more. gl though.
>
it's late for me too!
$ git merge i1/master
Merge made by recursive.
a | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 a
$ git merge --no-commit i2/master
Automatic merge went well; stopped before committing as requested
$ git commit --amend
fatal: You are in the middle of a merge -- cannot amend.
note the merge can work, but it's still done in 2 steps. :(
thanks for suggesting this.
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
^ permalink raw reply
* Re: More help needed on merging unrelated repos
From: Andreas Ericsson @ 2008-11-04 22:04 UTC (permalink / raw)
To: Christian MICHON; +Cc: Git Mailing List
In-Reply-To: <46d6db660811041308o19f1131dm4d49b6703fa6d22b@mail.gmail.com>
Christian MICHON wrote:
> Andreas Ericsson wrote:
>> Christian MICHON wrote:
>>> Hi,
>>>
>>> I previously posted here a question on how to merge unrelated repos,
>>> and I was quite happy with the answer.
>>> git pull repo_name repo_branch
>>>
>>> Yet, when I merge these repos (they're unrelated), I'd like to merge
>>> all of them at once.
>>>
>>> How do I pull for example 2 repos in 1 command ? I cannot figure out
>>> the exact syntax to use.
>>>
>>> I tried:
>>> git pull ../i1 0.5 ../i2 master
>>> git pull ../i1 0.5 -- ../i2 master
>>>
>>> I also tried to play with --no-commit and -s to no avail.
>>>
>>> Does anyone of you already use this and knows the trick ? Thanks in
>>> advance!
>>>
>> You can only pull from a single repository at a time. The first way of doing
>> what you want that comes to mind is:
>>
>> git remote add lib1 lib1url
>> git remote add lib2 lib2url
>> git fetch lib1 && git fetch lib2 && git merge lib1/master lib2/master
>>
>> --
>> Andreas Ericsson andreas.ericsson@op5.se
>> OP5 AB www.op5.se
>> Tel: +46 8-230225 Fax: +46 8-230231
>>
>
> and apparently this strategy (which I tried before too :( ) fails when merging.
>
> example:
> repo i1 contains file 'a'
> repo i2 contains file 'b'
> new repo z contains file 'readme' and I want to pull repo i1 and i2 at
> the same time inside repo z.
>
> typically, I've to pull 1 repo at a time, if I use pull. If I fetch
> both without merge, and then I try a merge, it fails.
> maybe I'm on a wild goose chase after all.
>
Ah, right. Octopus merge always does merge head reduction, but to do
that it needs to find a common ancestor. When no such ancestor exists,
it will fail (with a message like "shouldn't be doing octopus merge"?).
If there's no "--no-reduce-heads" option to "git merge", I think you're
screwed with getting that to happen in a single commit.
Oh wait.
git merge i1 && git merge --no-commit i2 && git commit --amend
might work. I'm still shooting from the hip though, and now it's far too
late for me to think more. gl though.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 4/4] Add support for 'namespace' history simplification
From: Clemens Buchacher @ 2008-11-04 21:33 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Brian Foster, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0811031139520.3419@nehalem.linux-foundation.org>
On Mon, Nov 03, 2008 at 11:43:00AM -0800, Linus Torvalds wrote:
> gitk --simplify-namespace
Very nice. git log --graph seems to give slightly different results though.
In particular, in git.git if I do
git for-each-ref --format="%(refname)" refs/remotes/origin | \
xargs git log --simplify-namespace --graph --pretty='format:%H%n' | \
git name-rev --stdin --name-only | \
less
some of the history is not connected. Is this a known limitation of
git log --graph?
^ permalink raw reply
* Re: More help needed on merging unrelated repos
From: Christian MICHON @ 2008-11-04 21:08 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Git Mailing List
In-Reply-To: <4910ACCA.7080007@op5.se>
Andreas Ericsson wrote:
> Christian MICHON wrote:
>>
>> Hi,
>>
>> I previously posted here a question on how to merge unrelated repos,
>> and I was quite happy with the answer.
>> git pull repo_name repo_branch
>>
>> Yet, when I merge these repos (they're unrelated), I'd like to merge
>> all of them at once.
>>
>> How do I pull for example 2 repos in 1 command ? I cannot figure out
>> the exact syntax to use.
>>
>> I tried:
>> git pull ../i1 0.5 ../i2 master
>> git pull ../i1 0.5 -- ../i2 master
>>
>> I also tried to play with --no-commit and -s to no avail.
>>
>> Does anyone of you already use this and knows the trick ? Thanks in
>> advance!
>>
>
> You can only pull from a single repository at a time. The first way of doing
> what you want that comes to mind is:
>
> git remote add lib1 lib1url
> git remote add lib2 lib2url
> git fetch lib1 && git fetch lib2 && git merge lib1/master lib2/master
>
> --
> Andreas Ericsson andreas.ericsson@op5.se
> OP5 AB www.op5.se
> Tel: +46 8-230225 Fax: +46 8-230231
>
and apparently this strategy (which I tried before too :( ) fails when merging.
example:
repo i1 contains file 'a'
repo i2 contains file 'b'
new repo z contains file 'readme' and I want to pull repo i1 and i2 at
the same time inside repo z.
typically, I've to pull 1 repo at a time, if I use pull. If I fetch
both without merge, and then I try a merge, it fails.
maybe I'm on a wild goose chase after all.
thanks
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
^ permalink raw reply
* [PATCH v2] push: fix local refs update if already up-to-date
From: Clemens Buchacher @ 2008-11-04 20:57 UTC (permalink / raw)
To: Jeff King, Junio C Hamano; +Cc: git
In-Reply-To: <20081104042643.GA31276@coredump.intra.peff.net>
git push normally updates local refs only after a successful push. If the
remote already has the updates -- pushed indirectly through another repository,
for example -- we forget to update local tracking refs.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
---
On Mon, Nov 03, 2008 at 11:26:44PM -0500, Jeff King wrote:
> Nit: Just reading the test, it is hard to see what is interesting about
> it (though obviously I can blame it back to your commit :) ). Maybe a
> more descriptive title like 'push updates uptodate local refs' would
> make sense.
That is all I changed in this update. Pending an Ack/Nack from Jeff I feel
that I'm done.
builtin-send-pack.c | 11 +++++------
t/t5516-fetch-push.sh | 18 ++++++++++++++++++
2 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/builtin-send-pack.c b/builtin-send-pack.c
index d68ce2d..c91c12f 100644
--- a/builtin-send-pack.c
+++ b/builtin-send-pack.c
@@ -230,7 +230,7 @@ static void update_tracking_ref(struct remote *remote, struct ref *ref)
{
struct refspec rs;
- if (ref->status != REF_STATUS_OK)
+ if (ref->status != REF_STATUS_OK && ref->status != REF_STATUS_UPTODATE)
return;
rs.src = ref->name;
@@ -444,15 +444,15 @@ static int do_send_pack(int in, int out, struct remote *remote, const char *dest
}
else
new_sha1 = ref->peer_ref->new_sha1;
+ hashcpy(ref->new_sha1, new_sha1);
-
- ref->deletion = is_null_sha1(new_sha1);
+ ref->deletion = is_null_sha1(ref->new_sha1);
if (ref->deletion && !allow_deleting_refs) {
ref->status = REF_STATUS_REJECT_NODELETE;
continue;
}
if (!ref->deletion &&
- !hashcmp(ref->old_sha1, new_sha1)) {
+ !hashcmp(ref->old_sha1, ref->new_sha1)) {
ref->status = REF_STATUS_UPTODATE;
continue;
}
@@ -480,14 +480,13 @@ static int do_send_pack(int in, int out, struct remote *remote, const char *dest
!ref->deletion &&
!is_null_sha1(ref->old_sha1) &&
(!has_sha1_file(ref->old_sha1)
- || !ref_newer(new_sha1, ref->old_sha1));
+ || !ref_newer(ref->new_sha1, ref->old_sha1));
if (ref->nonfastforward && !ref->force && !args.force_update) {
ref->status = REF_STATUS_REJECT_NONFASTFORWARD;
continue;
}
- hashcpy(ref->new_sha1, new_sha1);
if (!ref->deletion)
new_refs++;
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index f0030ad..a82ce5a 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -437,6 +437,24 @@ test_expect_success 'push updates local refs' '
'
+test_expect_success 'push updates up-to-date local refs' '
+
+ rm -rf parent child &&
+ mkdir parent &&
+ (cd parent && git init &&
+ echo one >foo && git add foo && git commit -m one) &&
+ git clone parent child1 &&
+ git clone parent child2 &&
+ (cd child1 &&
+ echo two >foo && git commit -a -m two &&
+ git push) &&
+ (cd child2 &&
+ git pull ../child1 master &&
+ git push &&
+ test $(git rev-parse master) = $(git rev-parse remotes/origin/master))
+
+'
+
test_expect_success 'push does not update local refs on failure' '
rm -rf parent child &&
--
1.6.0.3.617.ge4eb0
^ permalink raw reply related
* Re: [PATCH v2 1/3] t7700: demonstrate mishandling of objects in packs with a .keep file
From: Andreas Ericsson @ 2008-11-04 20:21 UTC (permalink / raw)
To: Brandon Casey
Cc: Junio C Hamano, Shawn O. Pearce, Git Mailing List, Nicolas Pitre
In-Reply-To: <V78jOMhdYwpSlLU-YzsqEHZxJyrvKbXRQbKsuNPZOEtB8E0kZ5Wi7Q@cipher.nrlssc.navy.mil>
Brandon Casey wrote:
> Andreas Ericsson wrote:
>> Brandon Casey wrote:
>>> From: Brandon Casey <drafnel@gmail.com>
>>>
>>> Objects residing in pack files that have an associated .keep file are not
>>> supposed to be repacked into new pack files, but they are.
>>>
>>> Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
>>> ---
>>>
>>>
>>> This version replaces the use of 'head -n -1' with a grep, and should
>>> work on
>>> all platforms.
>>>
>> sed 1q is faster, as it stops parsing after the first line (the same as
>> 'head
>> -n 1' does, but in a more portable fashion).
>
> Except that I wanted all but the _last_ line though.
>
Ach pooie. That's what I get for trying to review stuff while watching
old 70's samurai movies. I misread your 'head' command.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: More help needed on merging unrelated repos
From: Andreas Ericsson @ 2008-11-04 20:12 UTC (permalink / raw)
To: Christian MICHON; +Cc: Git Mailing List
In-Reply-To: <46d6db660811040514qc6c9663u17bd231e1ba662ad@mail.gmail.com>
Christian MICHON wrote:
> Hi,
>
> I previously posted here a question on how to merge unrelated repos,
> and I was quite happy with the answer.
> git pull repo_name repo_branch
>
> Yet, when I merge these repos (they're unrelated), I'd like to merge
> all of them at once.
>
> How do I pull for example 2 repos in 1 command ? I cannot figure out
> the exact syntax to use.
>
> I tried:
> git pull ../i1 0.5 ../i2 master
> git pull ../i1 0.5 -- ../i2 master
>
> I also tried to play with --no-commit and -s to no avail.
>
> Does anyone of you already use this and knows the trick ? Thanks in advance!
>
You can only pull from a single repository at a time. The first way of doing
what you want that comes to mind is:
git remote add lib1 lib1url
git remote add lib2 lib2url
git fetch lib1 && git fetch lib2 && git merge lib1/master lib2/master
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 4/5] git send-email: ask less questions when --compose is used.
From: Francis Galiegue @ 2008-11-04 20:09 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <1225815858-30617-5-git-send-email-madcoder@debian.org>
Le Tuesday 04 November 2008 17:24:17, vous avez écrit :
> + if ($summary_empty) {
> + print "Summary email is empty, --> skpping <-- it\n";
>
Typo...
--
fge
^ permalink raw reply
* Re: [PATCH v2 1/3] t7700: demonstrate mishandling of objects in packs with a .keep file
From: Brandon Casey @ 2008-11-04 20:01 UTC (permalink / raw)
To: Junio C Hamano
Cc: Andreas Ericsson, Shawn O. Pearce, Git Mailing List,
Nicolas Pitre
In-Reply-To: <7vmygfqn92.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Brandon Casey <casey@nrlssc.navy.mil> writes:
>> sed -n -e '$q' -e 'p'
>
> You surely meant "sed -e '$d'", right?
Your sed-fu is quite impressive.
-b
^ 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