* 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
* Re: [PATCH v2 1/3] t7700: demonstrate mishandling of objects in packs with a .keep file
From: Junio C Hamano @ 2008-11-04 19:55 UTC (permalink / raw)
To: Brandon Casey
Cc: Andreas Ericsson, Shawn O. Pearce, Git Mailing List,
Nicolas Pitre
In-Reply-To: <V78jOMhdYwpSlLU-YzsqEHZxJyrvKbXRQbKsuNPZOEtB8E0kZ5Wi7Q@cipher.nrlssc.navy.mil>
Brandon Casey <casey@nrlssc.navy.mil> writes:
> Andreas Ericsson wrote:
>
>> 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).
If your sed is GNU, and you are doing this for a small file, the startup
cost of it may dwarf such gain ;-)
> Except that I wanted all but the _last_ line though.
>
> I didn't think about using sed. Perhaps I could have used something like
>
> sed -n -e '$q' -e 'p'
You surely meant "sed -e '$d'", right?
> The grep works though.
Indeed.
^ 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 19:49 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Junio C Hamano, Shawn O. Pearce, Git Mailing List, Nicolas Pitre
In-Reply-To: <49109FD4.30003@op5.se>
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.
I didn't think about using sed. Perhaps I could have used something like
sed -n -e '$q' -e 'p'
The grep works though.
-brandon
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Junio C Hamano @ 2008-11-04 19:46 UTC (permalink / raw)
To: Sam Vilain
Cc: Dmitry Potapov, Jeff King, Sam Vilain, git, Johannes Schindelin,
Scott Chacon, Tom Preston-Werner, J.H., Christian Couder,
Kai Blin
In-Reply-To: <1225822231.6722.3.camel@maia.lan>
Sam Vilain <sam@vilain.net> writes:
> On Tue, 2008-11-04 at 12:18 +0300, Dmitry Potapov wrote:
> ...
>> The only one who does publishing to the official repository
>> is the maintainer, and the maintainer is most likely to run some tests
>> after merging all changes, which takes some time. So, it is rarely push
>> the current branch, it is usually the branch that has been tested, so
>> the name of the branch should be specified explicitly anyway.
>
> Why is that relevant? That person can still use the explicit version of
> the command.
Back when "git push $there :" were not available, the default matching
behaviour was the _only_ way to say "I know the set of branches I want to
publish, and I have many more private branches in my primary work
repository. I do not want to list the set of branches to publish every
time when I type 'git push', nor I want to configure it --- Heck, I
shouldn't have to list them, the public repository I am pushing to already
has that list, and it is the set of branches that exist there".
These days, people who would want the maching behaviour can explicitly ask
for it, so there is one less reason to resist changing the default
(i.e. earlier explicitly askinf for "matching" was impossible, but now we
can). The remaining reason of resistance is pure inertia (i.e. not
changing the behaviour of the command only because you upgraded your git),
and the only way to address it is to start issuing the warning when "git
push" or "git push $there" is used and the matching behaviour was chosen
without configuration (i.e. no "remote.<there>.push = :"), and keep it
that way for two release cycles, and finally change the default.
^ permalink raw reply
* Re: [PATCH] t7700: demonstrate mishandling of objects in packs with a .keep file
From: Andreas Ericsson @ 2008-11-04 19:25 UTC (permalink / raw)
To: Brandon Casey; +Cc: drafnel, git, gitster, nico
In-Reply-To: <76IhmMdjmr4jA4xApPpvlZ4vfjtqEDsUaFal2mN5MHfI0MChFmsj5g@cipher.nrlssc.navy.mil>
Brandon Casey wrote:
> Andreas Ericsson wrote:
>
>> So long as "git repack -a" still creates a mega-pack, I'm fine with
>> whatever.
>
> I don't think it will after pack-objects is taught about .keep files, and
In that case you're almost certainly breaking something.
> I don't think it will _now_ if all of your packs have .keep files.
>
It should, by copying the objects from the .keep-marked packfiles. Otherwise
either repack or the repack docs are in error.
> 'repack -a' will call pack-objects with either '--unpack=<packfile>' for
> each pack file without a .keep file, or with '--unpacked --incremental' if
> there are no pack files without .keep files.
>
> In the first case, the modifications to pack-objects that I propose
> will prevent objects that exist in local packs with .keep files
> from being packed into the new pack.
>
> In the second case, the --incremental option would have done the same thing.
>
> So this inconsistency already existed, but will now be removed in favor of
> honoring .keep files.
>
That means the nifty hack of incrementally and sometimes fully repack the
odb to speed up cloning over dumb protocols no longer works properly, then.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ 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