* Re: [PATCH v2 00/10] reroll of ap/log-mailmap
From: Junio C Hamano @ 2013-01-08 8:02 UTC (permalink / raw)
To: Antoine Pelisse; +Cc: git
In-Reply-To: <7v4nisgm3l.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Antoine Pelisse <apelisse@gmail.com> writes:
>
>> Have you been able to measure a speed increase due to less copies ?
>
> No.
>
> This topic was not strictly my itch, but I did the rewrite because I
> couldn't stand staring at that *_extended() function ;-)
Now I have. The overall numbers are larger primarily because the
kernel history has more commits than back when I did the previous
commit (thanks for reminding me of that one, by the way), but the
basic trend is the same.
The patch with updated numbers in the log is attached.
I am not absolutely sure about the correctness of the third patch in
the series; a review on the logic that uses the insertion point
search to implement the prefix match is very much appreciated.
Thanks.
-- >8 --
Subject: [PATCH] log --use-mailmap: optimize for cases without --author/--committer search
When we taught the commit_match() mechanism to pay attention to the
new --use-mailmap option, we started to unconditionally copy the
commit object to a temporary buffer, just in case we need the author
and committer lines updated via the mailmap mechanism, and rewrite
author and committer using the mailmap.
It turns out that this has a rather unpleasant performance
implications. In the linux kernel repository, running
$ git log --author='Junio C Hamano' --pretty=short >/dev/null
under /usr/bin/time, with and without --use-mailmap (the .mailmap
file is 118 entries long, the particular author does not appear in
it), cost (with warm cache):
[without --use-mailmap]
5.42user 0.26system 0:05.70elapsed 99%CPU (0avgtext+0avgdata 2005936maxresident)k
0inputs+0outputs (0major+137669minor)pagefaults 0swaps
[with --use-mailmap]
6.47user 0.30system 0:06.78elapsed 99%CPU (0avgtext+0avgdata 2006288maxresident)k
0inputs+0outputs (0major+137692minor)pagefaults 0swaps
which incurs about 20% overhead. The command is doing extra work,
so the extra cost may be justified.
But it is inexcusable to pay the cost when we do not need
author/committer match. In the same repository,
$ git log --grep='fix menuconfig on debian lenny' --pretty=short >/dev/null
shows very similar numbers as the above:
[without --use-mailmap]
5.32user 0.30system 0:05.63elapsed 99%CPU (0avgtext+0avgdata 2005984maxresident)k
0inputs+0outputs (0major+137672minor)pagefaults 0swaps
[with --use-mailmap]
6.64user 0.24system 0:06.89elapsed 99%CPU (0avgtext+0avgdata 2006320maxresident)k
0inputs+0outputs (0major+137694minor)pagefaults 0swaps
The latter case is an unnecessary performance regression. We may
want to _show_ the result with mailmap applied, but we do not have
to copy and rewrite the author/committer of all commits we try to
match if we do not query for these fields.
Trivially optimize this performace regression by limiting the
rewrites for only when we are matching with author/committer fields.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
revision.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/revision.c b/revision.c
index 2cce85a..d7562ee 100644
--- a/revision.c
+++ b/revision.c
@@ -2283,7 +2283,7 @@ static int commit_match(struct commit *commit, struct rev_info *opt)
if (buf.len)
strbuf_addstr(&buf, commit->buffer);
- if (opt->mailmap) {
+ if (opt->grep_filter.header_list && opt->mailmap) {
if (!buf.len)
strbuf_addstr(&buf, commit->buffer);
--
1.8.1.304.gf036638
^ permalink raw reply related
* Re: [PATCH] git clone depth of 0 not possible.
From: Junio C Hamano @ 2013-01-08 8:05 UTC (permalink / raw)
To: Duy Nguyen
Cc: Jonathan Nieder, Stefan Beller, schlotter, Ralf.Wildenhues, git
In-Reply-To: <CACsJy8D9+KHT=YfU0+rPCbs+AwxQOpfKzPChDhk8d-MMkRzZug@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
> On Tue, Jan 8, 2013 at 1:54 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Sounds buggy. Would anything break if we were to make --depth=1 mean
>>> "1 deep, including the tip commit"?
>>
>> As long as we do not change the meaning of the "shallow" count going
>> over the wire (i.e. the number we receive from the user will be
>> fudged, so that user's "depth 1" that used to mean "the tip and one
>> behind it" is expressed as "depth 2" at the end-user level, and we
>> send over the wire the number that corresponded to the old "depth
>> 1"), I do not think anything will break, and then --depth=0 may
>> magically start meaning "only the tip; its immediate parents will
>> not be transferred and recorded as the shallow boundary in the
>> receiving repository".
>
> I'd rather we reserve 0 for unlimited fetch, something we haven't done
> so far [1]. And because "unlimited clone" with --depth does not make
> sense, --depth=0 should be rejected by git-clone.
I actually was thinking about changing --depth=1 to mean "the tip,
with zero commits behind it" (and that was consistent with my
description of "fudging"), but ended up saying "--depth=0" by
mistake. I too think "--depth=0" or "--depth<0" does not make
sense, so we are in agreement.
Thanks for a sanity check.
^ permalink raw reply
* [PATCH] add warning for depth=0 in git clone.
From: Stefan Beller @ 2013-01-08 8:07 UTC (permalink / raw)
To: Junio C Hamano, Duy Nguyen, Jonathan Nieder, schlotter,
Ralf.Wildenhues, git
Cc: Stefan Beller
---
builtin/clone.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/builtin/clone.c b/builtin/clone.c
index ec2f75b..5e91c1e 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -818,6 +818,9 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
remote = remote_get(option_origin);
transport = transport_get(remote, remote->url[0]);
+ if (option_depth && transport->smart_options->depth < 1)
+ die(_("--depth less or equal 0 makes no sense; read manpage."));
+
if (!is_local) {
if (!transport->get_refs_list || !transport->fetch)
die(_("Don't know how to clone %s"), transport->url);
--
1.8.1.166.g27cbb96
^ permalink raw reply related
* Re: [PATCH] add warning for depth=0 in git clone.
From: Stefan Beller @ 2013-01-08 8:09 UTC (permalink / raw)
To: Stefan Beller
Cc: Junio C Hamano, Duy Nguyen, Jonathan Nieder, schlotter,
Ralf.Wildenhues, git
In-Reply-To: <1357632422-5686-1-git-send-email-stefanbeller@googlemail.com>
Hi,
I am struggling a little with the development process,
is a sign-off strictly required for git as it is for kernel development?
If so here would be my sign-off:
Signed-off-by: Stefan Beller <stefanbeller@googlemail.com>
This adds a warning and the previous patch adds the documentation.
However I agree to Junio, that the meaning should actually
depth=0 -> just the tip and no (0) other commits before.
depth=n -> the tip and n other commits before.
On 01/08/2013 09:07 AM, Stefan Beller wrote:
> ---
> builtin/clone.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/builtin/clone.c b/builtin/clone.c
> index ec2f75b..5e91c1e 100644
> --- a/builtin/clone.c
> +++ b/builtin/clone.c
> @@ -818,6 +818,9 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
> remote = remote_get(option_origin);
> transport = transport_get(remote, remote->url[0]);
>
> + if (option_depth && transport->smart_options->depth < 1)
> + die(_("--depth less or equal 0 makes no sense; read manpage."));
> +
> if (!is_local) {
> if (!transport->get_refs_list || !transport->fetch)
> die(_("Don't know how to clone %s"), transport->url);
>
^ permalink raw reply
* Re: [PATCH] add warning for depth=0 in git clone.
From: Jonathan Nieder @ 2013-01-08 8:12 UTC (permalink / raw)
To: Stefan Beller; +Cc: Junio C Hamano, Duy Nguyen, schlotter, Ralf.Wildenhues, git
In-Reply-To: <1357632422-5686-1-git-send-email-stefanbeller@googlemail.com>
Stefan Beller wrote:
> --- a/builtin/clone.c
> +++ b/builtin/clone.c
> @@ -818,6 +818,9 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
> remote = remote_get(option_origin);
> transport = transport_get(remote, remote->url[0]);
>
> + if (option_depth && transport->smart_options->depth < 1)
> + die(_("--depth less or equal 0 makes no sense; read manpage."));
"Makes no sense" is a little harsh. Presumably it made sense to the
user, or she wouldn't have passed that option. The relevant point is
that git was not able to make sense of it.
How about something like
fatal: shallow clone must have positive depth
? The "see manpage" is always implied by die(), and I don't see any
particular reason to point to a specific section here.
Hope that helps,
Jonathan
^ permalink raw reply
* Re: [PATCH] add warning for depth=0 in git clone.
From: Jonathan Nieder @ 2013-01-08 8:14 UTC (permalink / raw)
To: Stefan Beller; +Cc: Junio C Hamano, Duy Nguyen, schlotter, Ralf.Wildenhues, git
In-Reply-To: <50EBD453.9050101@googlemail.com>
Stefan Beller wrote:
> I am struggling a little with the development process,
> is a sign-off strictly required for git as it is for kernel development?
Yes. Documentation/SubmittingPatches has more hints.
> Signed-off-by: Stefan Beller <stefanbeller@googlemail.com>
>
> This adds a warning and the previous patch adds the documentation.
Thanks for your work on this.
^ permalink raw reply
* Re: [PATCH] git clone depth of 0 not possible.
From: Junio C Hamano @ 2013-01-08 8:19 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Stefan Beller, schlotter, Ralf.Wildenhues, git
In-Reply-To: <7vd2xggm8a.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I think we need a protocol update to fix this; instead of sending
> "Now I want your tips and N commits behind it, please update my
> shallow bottom accordingly", which creates the above by giving you Z
> and 3 generations back and updates your cut-off point to W, the
> receiving end should be able to ask "I have a shallow history that
> cuts off at these commits. I want to get the history leading up to
> your tips, and also deepen the history further back from my current
> cut-off points by N commits", so that you would instead end up with
> something like this:
>
> (you)
> o---o---o---A---B---C---D---E---F---...---W---X---Y---Z
>
> That is, truly "deepen my history by 3". We could call that "git
> fetch --deepen=3" or something.
I take that back. If you start from
> (upstream)
> ---o---o---o---A---B
>
> (you)
> A---B
and you are interested in peeking the history a bit deeper, you
should be able to ask "I have a shallow history that cuts off at
these commits. I want my history deepened by N commits. I do not
care where your current tips are, by the way." with
git fetch --deepen=3
and end up with
> (you)
> o---o---o---A---B
without getting the new history leading to the updated tip at the
upstream. If you want the new history leading to the updated tip,
you can just say:
git fetch
without any --depth nor --deepen option to end up with:
> (you)
> A---B---C---D---E---F---...---W---X---Y---Z
instead.
^ permalink raw reply
* Re: [PATCH 1/8] Use %B for Split Subject/Body
From: greened @ 2013-01-08 10:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Techlive Zheng
In-Reply-To: <7vehi477er.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> The question was about the lossage of the blank line, which does not
> seem to be related to what this patch wants to do.
Ah, missed that.
>>>> -# 25
>>>> +#25
>>>
>>> Why the lossage of a SP?
>>
>> I think this got fixed later in the series.
>
> That is not a good excuse to introduce breakages in the first place, no?
Oh, I agree. I wasn't making excuses. :)
>>> It may make sense to lose these "# num" that will have to be touched
>>> every time somebody inserts new test pieces in the middle, as a
>>> preparatory step before any of these patches, by the way. That will
>>> reduce noise in the patches for real changes.
>>
>> Yeah, I know, but it makes it really easy to find a test when something
>> goes wrong.
>
> That is what "tXXXX-*.sh -i" is for, isn't it?
Oh, I didn't know about that!
-David
^ permalink raw reply
* Re: [PATCH 2/8] Add --unannotate
From: greened @ 2013-01-08 10:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, James Nylen
In-Reply-To: <7va9ss77bu.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> greened@obbligato.org writes:
>
>> In the meantime, will you apply the patch or do you prefer a new design?
>
> The --unannotate option will become a baggage you will have to keep
> working until the end of time, if we applied it. I think it is not
> too uch a baggage, so it probably is OK.
Ok. I think it's worth applying since people find it useful. It's not
very complicated.
-David
^ permalink raw reply
* [PATCH] upload-pack: only accept commits from "shallow" line
From: Nguyễn Thái Ngọc Duy @ 2013-01-08 11:32 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
We only allow cuts at commits, not arbitrary objects. upload-pack will
fail eventually in register_shallow if a non-commit is given with a
generic error "Object %s is a %s, not a commit". Check it early and
give a more accurate error.
This should never show up in an ordinary session. It's for buggy
clients, or when the user manually edits .git/shallow.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
upload-pack.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/upload-pack.c b/upload-pack.c
index 6142421..95d8313 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -603,6 +603,8 @@ static void receive_needs(void)
object = parse_object(sha1);
if (!object)
die("did not find object for %s", line);
+ if (object->type != OBJ_COMMIT)
+ die("invalid shallow object %s", sha1_to_hex(sha1));
object->flags |= CLIENT_SHALLOW;
add_object_array(object, NULL, &shallows);
continue;
--
1.8.0.rc0.19.g7bbb31d
^ permalink raw reply related
* Revised git-subtree Patches
From: David A. Greene @ 2013-01-08 12:09 UTC (permalink / raw)
To: git
Here is the set of revised patches to git-subtree. I think I've
got everything cleaned up now.
^ permalink raw reply
* [PATCH 1/7] Remove Test Number Comments
From: David A. Greene @ 2013-01-08 12:09 UTC (permalink / raw)
To: git; +Cc: David A. Greene
In-Reply-To: <1357646997-28675-1-git-send-email-greened@obbligato.org>
From: "David A. Greene" <greened@obbligato.org>
Delete the comments indicating test numbers as it causes maintenance
headaches. t*.sh -i will help us find any broken tests.
Signed-off-by: David A. Greene <greened@obbligato.org>
---
contrib/subtree/t/t7900-subtree.sh | 55 ------------------------------------
1 file changed, 55 deletions(-)
diff --git a/contrib/subtree/t/t7900-subtree.sh b/contrib/subtree/t/t7900-subtree.sh
index bc2eeb0..6cf9fb9 100755
--- a/contrib/subtree/t/t7900-subtree.sh
+++ b/contrib/subtree/t/t7900-subtree.sh
@@ -60,7 +60,6 @@ last_commit_message()
git log --pretty=format:%s -1
}
-# 1
test_expect_success 'init subproj' '
test_create_repo subproj
'
@@ -68,7 +67,6 @@ test_expect_success 'init subproj' '
# To the subproject!
cd subproj
-# 2
test_expect_success 'add sub1' '
create sub1 &&
git commit -m "sub1" &&
@@ -76,14 +74,12 @@ test_expect_success 'add sub1' '
git branch -m master subproj
'
-# 3
test_expect_success 'add sub2' '
create sub2 &&
git commit -m "sub2" &&
git branch sub2
'
-# 4
test_expect_success 'add sub3' '
create sub3 &&
git commit -m "sub3" &&
@@ -93,7 +89,6 @@ test_expect_success 'add sub3' '
# Back to mainline
cd ..
-# 5
test_expect_success 'add main4' '
create main4 &&
git commit -m "main4" &&
@@ -101,101 +96,85 @@ test_expect_success 'add main4' '
git branch subdir
'
-# 6
test_expect_success 'fetch subproj history' '
git fetch ./subproj sub1 &&
git branch sub1 FETCH_HEAD
'
-# 7
test_expect_success 'no subtree exists in main tree' '
test_must_fail git subtree merge --prefix=subdir sub1
'
-# 8
test_expect_success 'no pull from non-existant subtree' '
test_must_fail git subtree pull --prefix=subdir ./subproj sub1
'
-# 9
test_expect_success 'check if --message works for add' '
git subtree add --prefix=subdir --message="Added subproject" sub1 &&
check_equal ''"$(last_commit_message)"'' "Added subproject" &&
undo
'
-# 10
test_expect_success 'check if --message works as -m and --prefix as -P' '
git subtree add -P subdir -m "Added subproject using git subtree" sub1 &&
check_equal ''"$(last_commit_message)"'' "Added subproject using git subtree" &&
undo
'
-# 11
test_expect_success 'check if --message works with squash too' '
git subtree add -P subdir -m "Added subproject with squash" --squash sub1 &&
check_equal ''"$(last_commit_message)"'' "Added subproject with squash" &&
undo
'
-# 12
test_expect_success 'add subproj to mainline' '
git subtree add --prefix=subdir/ FETCH_HEAD &&
check_equal ''"$(last_commit_message)"'' "Add '"'subdir/'"' from commit '"'"'''"$(git rev-parse sub1)"'''"'"'"
'
-# 13
# this shouldn't actually do anything, since FETCH_HEAD is already a parent
test_expect_success 'merge fetched subproj' '
git merge -m "merge -s -ours" -s ours FETCH_HEAD
'
-# 14
test_expect_success 'add main-sub5' '
create subdir/main-sub5 &&
git commit -m "main-sub5"
'
-# 15
test_expect_success 'add main6' '
create main6 &&
git commit -m "main6 boring"
'
-# 16
test_expect_success 'add main-sub7' '
create subdir/main-sub7 &&
git commit -m "main-sub7"
'
-# 17
test_expect_success 'fetch new subproj history' '
git fetch ./subproj sub2 &&
git branch sub2 FETCH_HEAD
'
-# 18
test_expect_success 'check if --message works for merge' '
git subtree merge --prefix=subdir -m "Merged changes from subproject" sub2 &&
check_equal ''"$(last_commit_message)"'' "Merged changes from subproject" &&
undo
'
-# 19
test_expect_success 'check if --message for merge works with squash too' '
git subtree merge --prefix subdir -m "Merged changes from subproject using squash" --squash sub2 &&
check_equal ''"$(last_commit_message)"'' "Merged changes from subproject using squash" &&
undo
'
-# 20
test_expect_success 'merge new subproj history into subdir' '
git subtree merge --prefix=subdir FETCH_HEAD &&
git branch pre-split &&
check_equal ''"$(last_commit_message)"'' "Merge commit '"'"'"$(git rev-parse sub2)"'"'"' into mainline"
'
-# 21
test_expect_success 'Check that prefix argument is required for split' '
echo "You must provide the --prefix option." > expected &&
test_must_fail git subtree split > actual 2>&1 &&
@@ -207,7 +186,6 @@ test_expect_success 'Check that prefix argument is required for split' '
rm -f expected actual
'
-# 22
test_expect_success 'Check that the <prefix> exists for a split' '
echo "'"'"'non-existent-directory'"'"'" does not exist\; use "'"'"'git subtree add'"'"'" > expected &&
test_must_fail git subtree split --prefix=non-existent-directory > actual 2>&1 &&
@@ -219,7 +197,6 @@ test_expect_success 'Check that the <prefix> exists for a split' '
# rm -f expected actual
'
-# 23
test_expect_success 'check if --message works for split+rejoin' '
spl1=''"$(git subtree split --annotate='"'*'"' --prefix subdir --onto FETCH_HEAD --message "Split & rejoin" --rejoin)"'' &&
git branch spl1 "$spl1" &&
@@ -227,7 +204,6 @@ test_expect_success 'check if --message works for split+rejoin' '
undo
'
-# 24
test_expect_success 'check split with --branch' '
spl1=$(git subtree split --annotate='"'*'"' --prefix subdir --onto FETCH_HEAD --message "Split & rejoin" --rejoin) &&
undo &&
@@ -235,7 +211,6 @@ test_expect_success 'check split with --branch' '
check_equal ''"$(git rev-parse splitbr1)"'' "$spl1"
'
-# 25
test_expect_success 'check split with --branch for an existing branch' '
spl1=''"$(git subtree split --annotate='"'*'"' --prefix subdir --onto FETCH_HEAD --message "Split & rejoin" --rejoin)"'' &&
undo &&
@@ -244,13 +219,10 @@ test_expect_success 'check split with --branch for an existing branch' '
check_equal ''"$(git rev-parse splitbr2)"'' "$spl1"
'
-# 26
test_expect_success 'check split with --branch for an incompatible branch' '
test_must_fail git subtree split --prefix subdir --onto FETCH_HEAD --branch subdir
'
-
-# 27
test_expect_success 'check split+rejoin' '
spl1=''"$(git subtree split --annotate='"'*'"' --prefix subdir --onto FETCH_HEAD --message "Split & rejoin" --rejoin)"'' &&
undo &&
@@ -258,7 +230,6 @@ test_expect_success 'check split+rejoin' '
check_equal ''"$(last_commit_message)"'' "Split '"'"'subdir/'"'"' into commit '"'"'"$spl1"'"'"'"
'
-# 28
test_expect_success 'add main-sub8' '
create subdir/main-sub8 &&
git commit -m "main-sub8"
@@ -267,14 +238,12 @@ test_expect_success 'add main-sub8' '
# To the subproject!
cd ./subproj
-# 29
test_expect_success 'merge split into subproj' '
git fetch .. spl1 &&
git branch spl1 FETCH_HEAD &&
git merge FETCH_HEAD
'
-# 30
test_expect_success 'add sub9' '
create sub9 &&
git commit -m "sub9"
@@ -283,19 +252,16 @@ test_expect_success 'add sub9' '
# Back to mainline
cd ..
-# 31
test_expect_success 'split for sub8' '
split2=''"$(git subtree split --annotate='"'*'"' --prefix subdir/ --rejoin)"''
git branch split2 "$split2"
'
-# 32
test_expect_success 'add main-sub10' '
create subdir/main-sub10 &&
git commit -m "main-sub10"
'
-# 33
test_expect_success 'split for sub10' '
spl3=''"$(git subtree split --annotate='"'*'"' --prefix subdir --rejoin)"'' &&
git branch spl3 "$spl3"
@@ -304,7 +270,6 @@ test_expect_success 'split for sub10' '
# To the subproject!
cd ./subproj
-# 34
test_expect_success 'merge split into subproj' '
git fetch .. spl3 &&
git branch spl3 FETCH_HEAD &&
@@ -318,13 +283,11 @@ chkms_sub=$(echo $chkms | multiline | sed 's,^,subdir/,' | fixnl)
chks="sub1 sub2 sub3 sub9"
chks_sub=$(echo $chks | multiline | sed 's,^,subdir/,' | fixnl)
-# 35
test_expect_success 'make sure exactly the right set of files ends up in the subproj' '
subfiles=''"$(git ls-files | fixnl)"'' &&
check_equal "$subfiles" "$chkms $chks"
'
-# 36
test_expect_success 'make sure the subproj history *only* contains commits that affect the subdir' '
allchanges=''"$(git log --name-only --pretty=format:'"''"' | sort | fixnl)"'' &&
check_equal "$allchanges" "$chkms $chks"
@@ -333,20 +296,17 @@ test_expect_success 'make sure the subproj history *only* contains commits that
# Back to mainline
cd ..
-# 37
test_expect_success 'pull from subproj' '
git fetch ./subproj subproj-merge-spl3 &&
git branch subproj-merge-spl3 FETCH_HEAD &&
git subtree pull --prefix=subdir ./subproj subproj-merge-spl3
'
-# 38
test_expect_success 'make sure exactly the right set of files ends up in the mainline' '
mainfiles=''"$(git ls-files | fixnl)"'' &&
check_equal "$mainfiles" "$chkm $chkms_sub $chks_sub"
'
-# 39
test_expect_success 'make sure each filename changed exactly once in the entire history' '
# main-sub?? and /subdir/main-sub?? both change, because those are the
# changes that were split into their own history. And subdir/sub?? never
@@ -355,12 +315,10 @@ test_expect_success 'make sure each filename changed exactly once in the entire
check_equal "$allchanges" ''"$(echo $chkms $chkm $chks $chkms_sub | multiline | sort | fixnl)"''
'
-# 40
test_expect_success 'make sure the --rejoin commits never make it into subproj' '
check_equal ''"$(git log --pretty=format:'"'%s'"' HEAD^2 | grep -i split)"'' ""
'
-# 41
test_expect_success 'make sure no "git subtree" tagged commits make it into subproj' '
# They are meaningless to subproj since one side of the merge refers to the mainline
check_equal ''"$(git log --pretty=format:'"'%s%n%b'"' HEAD^2 | grep "git-subtree.*:")"'' ""
@@ -370,14 +328,12 @@ test_expect_success 'make sure no "git subtree" tagged commits make it into subp
mkdir test2
cd test2
-# 42
test_expect_success 'init main' '
test_create_repo main
'
cd main
-# 43
test_expect_success 'add main1' '
create main1 &&
git commit -m "main1"
@@ -385,14 +341,12 @@ test_expect_success 'add main1' '
cd ..
-# 44
test_expect_success 'init sub' '
test_create_repo sub
'
cd sub
-# 45
test_expect_success 'add sub2' '
create sub2 &&
git commit -m "sub2"
@@ -402,7 +356,6 @@ cd ../main
# check if split can find proper base without --onto
-# 46
test_expect_success 'add sub as subdir in main' '
git fetch ../sub master &&
git branch sub2 FETCH_HEAD &&
@@ -411,7 +364,6 @@ test_expect_success 'add sub as subdir in main' '
cd ../sub
-# 47
test_expect_success 'add sub3' '
create sub3 &&
git commit -m "sub3"
@@ -419,20 +371,17 @@ test_expect_success 'add sub3' '
cd ../main
-# 48
test_expect_success 'merge from sub' '
git fetch ../sub master &&
git branch sub3 FETCH_HEAD &&
git subtree merge --prefix subdir sub3
'
-# 49
test_expect_success 'add main-sub4' '
create subdir/main-sub4 &&
git commit -m "main-sub4"
'
-# 50
test_expect_success 'split for main-sub4 without --onto' '
git subtree split --prefix subdir --branch mainsub4
'
@@ -442,19 +391,16 @@ test_expect_success 'split for main-sub4 without --onto' '
# have been sub3, but it was not, because its cache was not set to
# itself)
-# 51
test_expect_success 'check that the commit parent is sub3' '
check_equal ''"$(git log --pretty=format:%P -1 mainsub4)"'' ''"$(git rev-parse sub3)"''
'
-# 52
test_expect_success 'add main-sub5' '
mkdir subdir2 &&
create subdir2/main-sub5 &&
git commit -m "main-sub5"
'
-# 53
test_expect_success 'split for main-sub5 without --onto' '
# also test that we still can split out an entirely new subtree
# if the parent of the first commit in the tree is not empty,
@@ -487,7 +433,6 @@ joincommits()
echo "$commit $all"
}
-# 54
test_expect_success 'verify one file change per commit' '
x= &&
list=''"$(git log --pretty=format:'"'commit: %H'"' | joincommits)"'' &&
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/7] contrib/subtree: Use %B for Split Subject/Body
From: David A. Greene @ 2013-01-08 12:09 UTC (permalink / raw)
To: git; +Cc: Techlive Zheng, David A. Greene
In-Reply-To: <1357646997-28675-1-git-send-email-greened@obbligato.org>
From: Techlive Zheng <techlivezheng@gmail.com>
Use %B to format the commit message and body to avoid an extra newline
if a commit only has a subject line.
Signed-off-by: Techlive Zheng <techlivezheng@gmail.com>
Signed-off-by: David A. Greene <greened@obbligato.org>
---
contrib/subtree/git-subtree.sh | 6 +++++-
contrib/subtree/t/t7900-subtree.sh | 15 +++++++++++++++
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index 920c664..5341b36 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -296,7 +296,11 @@ copy_commit()
# We're going to set some environment vars here, so
# do it in a subshell to get rid of them safely later
debug copy_commit "{$1}" "{$2}" "{$3}"
- git log -1 --pretty=format:'%an%n%ae%n%ad%n%cn%n%ce%n%cd%n%s%n%n%b' "$1" |
+ # Use %B rather than %s%n%n%b to handle the special case of a
+ # commit that only has a subject line. We don't want to
+ # introduce a newline after the subject, causing generation of
+ # a new hash.
+ git log -1 --pretty=format:'%an%n%ae%n%ad%n%cn%n%ce%n%cd%n%B' "$1" |
(
read GIT_AUTHOR_NAME
read GIT_AUTHOR_EMAIL
diff --git a/contrib/subtree/t/t7900-subtree.sh b/contrib/subtree/t/t7900-subtree.sh
index 6cf9fb9..3f17f55 100755
--- a/contrib/subtree/t/t7900-subtree.sh
+++ b/contrib/subtree/t/t7900-subtree.sh
@@ -74,6 +74,10 @@ test_expect_success 'add sub1' '
git branch -m master subproj
'
+# Save this hash for testing later.
+
+subdir_hash=`git rev-parse HEAD`
+
test_expect_success 'add sub2' '
create sub2 &&
git commit -m "sub2" &&
@@ -211,6 +215,17 @@ test_expect_success 'check split with --branch' '
check_equal ''"$(git rev-parse splitbr1)"'' "$spl1"
'
+test_expect_success 'check hash of split' '
+ spl1=$(git subtree split --prefix subdir) &&
+ undo &&
+ git subtree split --prefix subdir --branch splitbr1test &&
+ check_equal ''"$(git rev-parse splitbr1test)"'' "$spl1"
+ git checkout splitbr1test &&
+ new_hash=$(git rev-parse HEAD~2) &&
+ git checkout mainline &&
+ check_equal ''"$new_hash"'' "$subdir_hash"
+'
+
test_expect_success 'check split with --branch for an existing branch' '
spl1=''"$(git subtree split --annotate='"'*'"' --prefix subdir --onto FETCH_HEAD --message "Split & rejoin" --rejoin)"'' &&
undo &&
--
1.7.10.4
^ permalink raw reply related
* [PATCH 4/7] contrib/subtree: Better Error Handling for add
From: David A. Greene @ 2013-01-08 12:09 UTC (permalink / raw)
To: git; +Cc: David A. Greene
In-Reply-To: <1357646997-28675-1-git-send-email-greened@obbligato.org>
From: "David A. Greene" <greened@obbligato.org>
Check refspecs for validity before passing them on to other commands.
This lets us generate more helpful error messages.
Signed-off-by: David A. Greene <greened@obbligato.org>
---
contrib/subtree/git-subtree.sh | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index cac0680..d53eaee 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -508,12 +508,18 @@ cmd_add()
ensure_clean
if [ $# -eq 1 ]; then
- "cmd_add_commit" "$@"
+ git rev-parse -q --verify "$1^{commit}" >/dev/null ||
+ die "'$1' does not refer to a commit"
+
+ "cmd_add_commit" "$@"
elif [ $# -eq 2 ]; then
- "cmd_add_repository" "$@"
+ git rev-parse -q --verify "$2^{commit}" >/dev/null ||
+ die "'$2' does not refer to a commit"
+
+ "cmd_add_repository" "$@"
else
say "error: parameters were '$@'"
- die "Provide either a refspec or a repository and refspec."
+ die "Provide either a commit or a repository and commit."
fi
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 7/7] contrib/subtree: Make the Manual Directory if Needed
From: David A. Greene @ 2013-01-08 12:09 UTC (permalink / raw)
To: git; +Cc: Jesper L. Nielsen, David A. Greene
In-Reply-To: <1357646997-28675-1-git-send-email-greened@obbligato.org>
From: "Jesper L. Nielsen" <lyager@gmail.com>
Before install git-subtree documentation, make sure the manpage
directory exists.
Signed-off-by: Jesper L. Nielsen <lyager@gmail.com>
Signed-off-by: David A. Greene <greened@obbligato.org>
---
contrib/subtree/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/contrib/subtree/Makefile b/contrib/subtree/Makefile
index 36ae3e4..b507505 100644
--- a/contrib/subtree/Makefile
+++ b/contrib/subtree/Makefile
@@ -35,6 +35,7 @@ install: $(GIT_SUBTREE)
install-doc: install-man
install-man: $(GIT_SUBTREE_DOC)
+ $(INSTALL) -d -m 755 $(DESTDIR)$(man1dir)
$(INSTALL) -m 644 $^ $(DESTDIR)$(man1dir)
$(GIT_SUBTREE_DOC): $(GIT_SUBTREE_XML)
--
1.7.10.4
^ permalink raw reply related
* [PATCH 5/7] contrib/subtree: Fix Synopsis
From: David A. Greene @ 2013-01-08 12:09 UTC (permalink / raw)
To: git; +Cc: David A. Greene
In-Reply-To: <1357646997-28675-1-git-send-email-greened@obbligato.org>
From: "David A. Greene" <greened@obbligato.org>
Fix the documentation of add to show that a repository can be
specified along with a commit.
Suggested by Yann Dirson <dirson@bertin.fr>.
Signed-off-by: David A. Greene <greened@obbligato.org>
---
contrib/subtree/git-subtree.sh | 6 ++++++
contrib/subtree/git-subtree.txt | 3 ++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index d53eaee..0e9ea0f 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -9,6 +9,7 @@ if [ $# -eq 0 ]; then
fi
OPTS_SPEC="\
git subtree add --prefix=<prefix> <commit>
+git subtree add --prefix=<prefix> <repository> <commit>
git subtree merge --prefix=<prefix> <commit>
git subtree pull --prefix=<prefix> <repository> <refspec...>
git subtree push --prefix=<prefix> <repository> <refspec...>
@@ -513,6 +514,11 @@ cmd_add()
"cmd_add_commit" "$@"
elif [ $# -eq 2 ]; then
+ # Technically we could accept a refspec here but we're
+ # just going to turn around and add FETCH_HEAD under the
+ # specified directory. Allowing a refspec might be
+ # misleading because we won't do anything with any other
+ # branches fetched via the refspec.
git rev-parse -q --verify "$2^{commit}" >/dev/null ||
die "'$2' does not refer to a commit"
diff --git a/contrib/subtree/git-subtree.txt b/contrib/subtree/git-subtree.txt
index 75aa690..078d4ac 100644
--- a/contrib/subtree/git-subtree.txt
+++ b/contrib/subtree/git-subtree.txt
@@ -9,7 +9,8 @@ git-subtree - Merge subtrees together and split repository into subtrees
SYNOPSIS
--------
[verse]
-'git subtree' add -P <prefix> <commit>
+'git subtree' add -P <prefix> <refspec>
+'git subtree' add -P <prefix> <repository> <refspec>
'git subtree' pull -P <prefix> <repository> <refspec...>
'git subtree' push -P <prefix> <repository> <refspec...>
'git subtree' merge -P <prefix> <commit>
--
1.7.10.4
^ permalink raw reply related
* [PATCH 6/7] contrib/subtree: Honor DESTDIR
From: David A. Greene @ 2013-01-08 12:09 UTC (permalink / raw)
To: git; +Cc: Adam Tkac, David A. Greene
In-Reply-To: <1357646997-28675-1-git-send-email-greened@obbligato.org>
From: Adam Tkac <atkac@redhat.com>
Teach git-subtree's Makefile to honor DESTDIR.
Signed-off-by: Adam Tkac <atkac@redhat.com>
Signed-off-by: David A. Greene <greened@obbligato.org>
---
contrib/subtree/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/subtree/Makefile b/contrib/subtree/Makefile
index 05cdd5c..36ae3e4 100644
--- a/contrib/subtree/Makefile
+++ b/contrib/subtree/Makefile
@@ -30,12 +30,12 @@ $(GIT_SUBTREE): $(GIT_SUBTREE_SH)
doc: $(GIT_SUBTREE_DOC)
install: $(GIT_SUBTREE)
- $(INSTALL) -m 755 $(GIT_SUBTREE) $(libexecdir)
+ $(INSTALL) -m 755 $(GIT_SUBTREE) $(DESTDIR)$(libexecdir)
install-doc: install-man
install-man: $(GIT_SUBTREE_DOC)
- $(INSTALL) -m 644 $^ $(man1dir)
+ $(INSTALL) -m 644 $^ $(DESTDIR)$(man1dir)
$(GIT_SUBTREE_DOC): $(GIT_SUBTREE_XML)
xmlto -m $(MANPAGE_NORMAL_XSL) man $^
--
1.7.10.4
^ permalink raw reply related
* [PATCH 3/7] contrib/subtree: Add --unannotate
From: David A. Greene @ 2013-01-08 12:09 UTC (permalink / raw)
To: git; +Cc: James Nylen, David A. Greene
In-Reply-To: <1357646997-28675-1-git-send-email-greened@obbligato.org>
From: James Nylen <jnylen@gmail.com>
Teach git-subtree about --unannotate. This option strips a prefix
from a commit message when doing a subtree split.
Signed-off-by: James Nylen <jnylen@gmail.com>
Signed-off-by: David A. Greene <greened@obbligato.org>
---
contrib/subtree/git-subtree.sh | 11 +++++++++--
contrib/subtree/git-subtree.txt | 15 +++++++++++++++
contrib/subtree/t/t7900-subtree.sh | 12 ++++++++++--
3 files changed, 34 insertions(+), 4 deletions(-)
diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index 5341b36..cac0680 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -21,6 +21,7 @@ P,prefix= the name of the subdir to split out
m,message= use the given message as the commit message for the merge commit
options for 'split'
annotate= add a prefix to commit message of new commits
+unannotate= remove a prefix from new commit messages (supports bash globbing)
b,branch= create a new branch from the split subtree
ignore-joins ignore prior --rejoin commits
onto= try connecting new tree to an existing one
@@ -43,6 +44,7 @@ onto=
rejoin=
ignore_joins=
annotate=
+unannotate=
squash=
message=
@@ -80,6 +82,8 @@ while [ $# -gt 0 ]; do
-d) debug=1 ;;
--annotate) annotate="$1"; shift ;;
--no-annotate) annotate= ;;
+ --unannotate) unannotate="$1"; shift ;;
+ --no-unannotate) unannotate= ;;
-b) branch="$1"; shift ;;
-P) prefix="$1"; shift ;;
-m) message="$1"; shift ;;
@@ -314,8 +318,11 @@ copy_commit()
GIT_COMMITTER_NAME \
GIT_COMMITTER_EMAIL \
GIT_COMMITTER_DATE
- (echo -n "$annotate"; cat ) |
- git commit-tree "$2" $3 # reads the rest of stdin
+ (
+ read FIRST_LINE
+ echo "$annotate${FIRST_LINE#$unannotate}"
+ cat # reads the rest of stdin
+ ) | git commit-tree "$2" $3
) || die "Can't copy commit $1"
}
diff --git a/contrib/subtree/git-subtree.txt b/contrib/subtree/git-subtree.txt
index c5bce41..75aa690 100644
--- a/contrib/subtree/git-subtree.txt
+++ b/contrib/subtree/git-subtree.txt
@@ -198,6 +198,21 @@ OPTIONS FOR split
git subtree tries to make it work anyway, particularly
if you use --rejoin, but it may not always be effective.
+--unannotate=<annotation>::
+ This option is only valid for the split command.
+
+ When generating synthetic history, try to remove the prefix
+ <annotation> from each commit message (using bash's "strip
+ shortest match from beginning" command, which supports
+ globbing). This makes sense if you format library commits
+ like "library: Change something or other" when you're working
+ in your project's repository, but you want to remove this
+ prefix when pushing back to the library's upstream repository.
+ (In this case --unannotate='*: ' would work well.)
+
+ Like --annotate, you need to use the same <annotation>
+ whenever you split, or you may run into problems.
+
-b <branch>::
--branch=<branch>::
This option is only valid for the split command.
diff --git a/contrib/subtree/t/t7900-subtree.sh b/contrib/subtree/t/t7900-subtree.sh
index 3f17f55..de45e34 100755
--- a/contrib/subtree/t/t7900-subtree.sh
+++ b/contrib/subtree/t/t7900-subtree.sh
@@ -143,7 +143,7 @@ test_expect_success 'merge fetched subproj' '
test_expect_success 'add main-sub5' '
create subdir/main-sub5 &&
- git commit -m "main-sub5"
+ git commit -m "subproj: main-sub5"
'
test_expect_success 'add main6' '
@@ -153,7 +153,7 @@ test_expect_success 'add main6' '
test_expect_success 'add main-sub7' '
create subdir/main-sub7 &&
- git commit -m "main-sub7"
+ git commit -m "subproj: main-sub7"
'
test_expect_success 'fetch new subproj history' '
@@ -226,6 +226,14 @@ test_expect_success 'check hash of split' '
check_equal ''"$new_hash"'' "$subdir_hash"
'
+test_expect_success 'check --unannotate' '
+ spl1=$(git subtree split --unannotate='"subproj:"' --prefix subdir --onto FETCH_HEAD --message "Split & rejoin" --rejoin) &&
+ undo &&
+ git subtree split --unannotate='"subproj:"' --prefix subdir --onto FETCH_HEAD --branch splitunann &&
+ check_equal ''"$(git rev-parse splitunann)"'' "$spl1" &&
+ check_equal ''"$(git log splitunann | grep subproj)"'' ""
+'
+
test_expect_success 'check split with --branch for an existing branch' '
spl1=''"$(git subtree split --annotate='"'*'"' --prefix subdir --onto FETCH_HEAD --message "Split & rejoin" --rejoin)"'' &&
undo &&
--
1.7.10.4
^ permalink raw reply related
* [PATCH] fetch,upload-pack: make --depth=0 or --depth=inf for infinite depth
From: Nguyễn Thái Ngọc Duy @ 2013-01-08 12:19 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
The user can do fetch --depth=2147483647 for infinite depth now. But
it's hard to remember. Any other large numbers would also do if it's
longer than the longest commit chain in repository (some guessing may
be involved). Make --depth=0 or --depth=inf an alias for
--depth=2147483647. JGit and older C Git store depth as "int" so both
are OK with this number. Dulwich does not support shallow clone.
fetch-pack is not changed because it's a plumbing and the plumber is
expected to write this number explicitly.
Make upload-pack recognize this special number as infinite depth. The
effect is essentially the same as before, except that upload-pack is
more efficient in this case as it does not have to traverse the commit
DAG to the bottom any more. The chance of a user actually wanting
exactly 2147483647 commits depth, not infinite, is probably too small
to consider.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
This is a patch from the graveyard, the third patch of a series [1].
The series, nd/clone-depth-zero, has been merged. Although I don't know
only the first patch in the original series got in.
http://thread.gmane.org/gmane.comp.version-control.git/154267/focus=154268
Documentation/fetch-options.txt | 2 ++
Documentation/technical/shallow.txt | 3 +++
commit.h | 3 +++
t/t5500-fetch-pack.sh | 8 ++++++++
transport.c | 5 +++++
upload-pack.c | 13 ++++++++++---
6 files changed, 31 insertions(+), 3 deletions(-)
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index 6e98bdf..140d0cd 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -12,6 +12,8 @@
`git clone` with `--depth=<depth>` option (see linkgit:git-clone[1])
to the specified number of commits from the tip of each remote
branch history. Tags for the deepened commits are not fetched.
+ Depth 0 or "inf" is infinite, which may turn repository to a
+ non-shallow one again.
ifndef::git-pull[]
--dry-run::
diff --git a/Documentation/technical/shallow.txt b/Documentation/technical/shallow.txt
index 0502a54..ea2f69f 100644
--- a/Documentation/technical/shallow.txt
+++ b/Documentation/technical/shallow.txt
@@ -53,3 +53,6 @@ It also writes an appropriate $GIT_DIR/shallow.
You can deepen a shallow repository with "git-fetch --depth 20
repo branch", which will fetch branch from repo, but stop at depth
20, updating $GIT_DIR/shallow.
+
+The special depth 2147483647 (or 0x7fffffff, the largest positive
+number a signed 32-bit integer can contain) means infinite depth.
diff --git a/commit.h b/commit.h
index 0f469e5..fbde106 100644
--- a/commit.h
+++ b/commit.h
@@ -162,6 +162,9 @@ extern struct commit_list *get_merge_bases(struct commit *rev1, struct commit *r
extern struct commit_list *get_merge_bases_many(struct commit *one, int n, struct commit **twos, int cleanup);
extern struct commit_list *get_octopus_merge_bases(struct commit_list *in);
+/* largest postive number a signed 32-bit integer can contain */
+#define INFINITE_DEPTH 0x7fffffff
+
extern int register_shallow(const unsigned char *sha1);
extern int unregister_shallow(const unsigned char *sha1);
extern int for_each_commit_graft(each_commit_graft_fn, void *);
diff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh
index 6322e8a..2d40073 100755
--- a/t/t5500-fetch-pack.sh
+++ b/t/t5500-fetch-pack.sh
@@ -264,6 +264,14 @@ test_expect_success 'clone shallow object count' '
grep "^count: 52" count.shallow
'
+test_expect_success 'infinite deepening (full repo)' '
+ (
+ cd shallow &&
+ git fetch --depth=inf &&
+ ! test -f .git/shallow
+ )
+'
+
test_expect_success 'clone shallow without --no-single-branch' '
git clone --depth 1 "file://$(pwd)/." shallow2
'
diff --git a/transport.c b/transport.c
index 2673d27..a938ba0 100644
--- a/transport.c
+++ b/transport.c
@@ -12,6 +12,7 @@
#include "url.h"
#include "submodule.h"
#include "string-list.h"
+#include "commit.h"
/* rsync support */
@@ -475,11 +476,15 @@ static int set_git_option(struct git_transport_options *opts,
} else if (!strcmp(name, TRANS_OPT_DEPTH)) {
if (!value)
opts->depth = 0;
+ else if (!strcmp(value, "inf"))
+ opts->depth = INFINITE_DEPTH;
else {
char *end;
opts->depth = strtol(value, &end, 0);
if (*end)
die("transport: invalid depth option '%s'", value);
+ if (opts->depth == 0)
+ opts->depth = INFINITE_DEPTH;
}
return 0;
}
diff --git a/upload-pack.c b/upload-pack.c
index 6142421..88f0029 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -670,10 +670,17 @@ static void receive_needs(void)
if (depth == 0 && shallows.nr == 0)
return;
if (depth > 0) {
- struct commit_list *result, *backup;
+ struct commit_list *result = NULL, *backup = NULL;
int i;
- backup = result = get_shallow_commits(&want_obj, depth,
- SHALLOW, NOT_SHALLOW);
+ if (depth == INFINITE_DEPTH)
+ for (i = 0; i < shallows.nr; i++) {
+ struct object *object = shallows.objects[i].item;
+ object->flags |= NOT_SHALLOW;
+ }
+ else
+ backup = result =
+ get_shallow_commits(&want_obj, depth,
+ SHALLOW, NOT_SHALLOW);
while (result) {
struct object *object = &result->item->object;
if (!(object->flags & (CLIENT_SHALLOW|NOT_SHALLOW))) {
--
1.8.0.rc2.23.g1fb49df
^ permalink raw reply related
* Understanding When to Use Branches
From: gw1500 @ 2013-01-08 13:46 UTC (permalink / raw)
To: git@vger.kernel.org
As a git noobie I am beginning get get my head around git's version
control philosophy. I am now trying to understand the purposes of
branches or rather when to use them. In my case I have a Java
application under version control with git. I am planning to port it
into a mobile app. Is that an appropriate use of branches or should it
be created as a new repository? What is the relationship between the
same source code in different branches? Do changes to code in one branch
get ported to another branch somehow or do all changes then have to be
made twice? The documentation tells how to branch but not the general
philosophy behind it from a best practices standpoint. Thanks in advance
for any insight.
^ permalink raw reply
* Re: [PATCH] clone: forbid --bare --separate-git-dir <dir>
From: Duy Nguyen @ 2013-01-08 14:16 UTC (permalink / raw)
To: Jonathan Nieder, Jens Lehmann
Cc: git, Junio C Hamano, Heiko Voigt, Manlio Perillo, W. Trevor King
In-Reply-To: <20130106101948.GD10956@elie.Belkin>
On Sun, Jan 06, 2013 at 02:19:48AM -0800, Jonathan Nieder wrote:
> Unfortunately we forgot to forbid the --bare
> --separate-git-dir combination. In practice, we know no one
> could be using --bare with --separate-git-dir because it is
> broken in the following way: <explanation here>. So it is
> safe to make good on our mistake and forbid the combination,
> making the command easier to explain.
>
> I don't know what would go in the <explanation here> blank above,
> though. Is it possible that some people are relying on this option
> combination?
I can't say it's broken in what way. Maybe it's easier to just support
this case, it's not much work anyway. Jens, maybe squash this to your
original patch?
-- 8< --
diff --git a/builtin/clone.c b/builtin/clone.c
index 8d23a62..c8b09ad 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -375,6 +375,7 @@ static void clone_local(const char *src_repo, const char *dest_repo)
static const char *junk_work_tree;
static const char *junk_git_dir;
+static const char *junk_git_file;
static pid_t junk_pid;
static void remove_junk(void)
@@ -392,6 +393,8 @@ static void remove_junk(void)
remove_dir_recursively(&sb, 0);
strbuf_reset(&sb);
}
+ if (junk_git_file)
+ unlink(junk_git_file);
}
static void remove_junk_on_signal(int signo)
@@ -772,6 +775,8 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
set_git_dir_init(git_dir, real_git_dir, 0);
if (real_git_dir) {
+ if (option_bare)
+ junk_git_file = git_dir;
git_dir = real_git_dir;
junk_git_dir = real_git_dir;
}
diff --git a/t/t5600-clone-fail-cleanup.sh b/t/t5600-clone-fail-cleanup.sh
index 4435693..231bc8a 100755
--- a/t/t5600-clone-fail-cleanup.sh
+++ b/t/t5600-clone-fail-cleanup.sh
@@ -49,4 +49,14 @@ test_expect_success 'failed clone --separate-git-dir should not leave any direct
rmdir foo/.git/objects.bak
'
+test_expect_success 'failed clone --separate-git-dir --bare should not leave any directories' '
+ mkdir foo/.git/objects.bak/ &&
+ mv foo/.git/objects/* foo/.git/objects.bak/ &&
+ test_must_fail git clone --bare --separate-git-dir gitdir foo baaar &&
+ test_must_fail test -e gitdir &&
+ test_must_fail test -e baaar &&
+ mv foo/.git/objects.bak/* foo/.git/objects/ &&
+ rmdir foo/.git/objects.bak
+'
+
test_done
-- 8< --
^ permalink raw reply related
* Re: [PATCH] git clone depth of 0 not possible.
From: Duy Nguyen @ 2013-01-08 14:28 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jonathan Nieder, Stefan Beller, schlotter, Ralf.Wildenhues, git
In-Reply-To: <7vd2xggm8a.fsf@alter.siamese.dyndns.org>
On Tue, Jan 8, 2013 at 2:36 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Speaking of --depth, I think in Git 2.0 we should fix the semantics
> of "deepening" done with "git fetch".
Speaking of 2.0, we should support depth per ref. Well we don't have
to wait until 2.0 because we could just add shallow2 extension to the
pack protocol. We should also apply depth to new refs when fetching
them the first time.
--
Duy
^ permalink raw reply
* Re: Moving (renaming) submodules, recipe/script
From: W. Trevor King @ 2013-01-08 14:32 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Jonathan Nieder, Git, Peter Collingbourne
In-Reply-To: <50EA7269.1080006@web.de>
[-- Attachment #1: Type: text/plain, Size: 2345 bytes --]
On Mon, Jan 07, 2013 at 07:59:53AM +0100, Jens Lehmann wrote:
> Am 07.01.2013 02:39, schrieb Jonathan Nieder:
> > (just cc-ing Jens and Peter, who might be interested)
>
> I´m currently working on teaching mv to move submodules and intend
> to send those patches to the list after finishing submodule deinit.
> Please see
> https://github.com/jlehmann/git-submod-enhancements/commits/mv-submodules
> for the current state of this series.
Thinking about this a bit more, I'm not clear on how out-of-tree
updates (i.e. worktree in .git/modules/*/config) propogated during
branch checkouts (merges, rebases, etc.). I just got a broken rebase
trying to move a trivial patch back before the submodule move, and Git
was confused about what had happened to the submodules. Here's a
simple script that illustrates the problem:
#!/bin/sh
rm -rf a b c
mkdir a
(cd a
git init
echo a > README
git add README
git commit -am 'a'
)
git clone a b
(cd b
git submodule add ../a submod-1
git commit -am 'add submodule at submod-1'
)
git clone b c
(cd c
git submodule update --init
)
(cd b
git-submodule-mv.sh submod-1 submod-2
git commit -am 'move submodule from submod-1 to submod-2'
)
(cd c
git pull
ls -d .git/modules/*
cat .git/modules/submod-1/config
ls -a submod*
)
The end result is that `c` gets the `.gitmodules` path updates and new
gitlinked directory from the submodule move in `b` (using my
git-submodule-mv.sh posted earlier in this thread), but `submod-1` is
left lying around (because Git doesn't know that it can remove
submod-1/.git and submod-1/README). The Git directory for the
submodule stays in .git/modules/submod-1/ (good), but the worktree in
.git/modules/submod-1/config still points to ../../../submod-1 (bad).
This means that submodule moves are possible, but anyone trying to
share them between several repositories (or trying to rebase across
the move within their own repository) is in for a world of suffering
;). I'm not sure how this should be addressed, but I didn't see
anything handling it in Jens' new series.
Thanks,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] git clone depth of 0 not possible.
From: Stefan Beller @ 2013-01-08 14:32 UTC (permalink / raw)
To: Duy Nguyen
Cc: Junio C Hamano, Jonathan Nieder, schlotter, Ralf.Wildenhues, git
In-Reply-To: <CACsJy8BJ3eBv-wjq=eTzR4SeEXW2MF5k1w5SFRt7fWRU4vKb_Q@mail.gmail.com>
On 01/08/2013 03:28 PM, Duy Nguyen wrote:
> On Tue, Jan 8, 2013 at 2:36 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Speaking of --depth, I think in Git 2.0 we should fix the semantics
>> of "deepening" done with "git fetch".
>
> Speaking of 2.0, we should support depth per ref. Well we don't have
> to wait until 2.0 because we could just add shallow2 extension to the
> pack protocol. We should also apply depth to new refs when fetching
> them the first time.
>
Would this mean I could do something along?
$ git clone --since v1.8.0 git://github.com/gitster/git.git
So tags would be allowed as anchors?
^ permalink raw reply
* Re: [PATCH] git clone depth of 0 not possible.
From: Duy Nguyen @ 2013-01-08 14:45 UTC (permalink / raw)
To: Stefan Beller
Cc: Junio C Hamano, Jonathan Nieder, schlotter, Ralf.Wildenhues, git
In-Reply-To: <50EC2DE5.2050704@googlemail.com>
On Tue, Jan 8, 2013 at 9:32 PM, Stefan Beller
<stefanbeller@googlemail.com> wrote:
> On 01/08/2013 03:28 PM, Duy Nguyen wrote:
>> On Tue, Jan 8, 2013 at 2:36 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Speaking of --depth, I think in Git 2.0 we should fix the semantics
>>> of "deepening" done with "git fetch".
>>
>> Speaking of 2.0, we should support depth per ref. Well we don't have
>> to wait until 2.0 because we could just add shallow2 extension to the
>> pack protocol. We should also apply depth to new refs when fetching
>> them the first time.
>>
>
> Would this mean I could do something along?
> $ git clone --since v1.8.0 git://github.com/gitster/git.git
>
> So tags would be allowed as anchors?
No. This is what I had in mind:
git clone --branch=master --depth=2 git.git # get branch master with depth 2
git fetch --depth=10 origin next # get branch next with depth 10
# master's depth remains 2
git fetch origin # get (new) branch 'pu' with default depth 2
But your case is interesting. We could specify --depth=v1.8.0.. or
even --depth=v1.8.0~200.. (200 commits before v1.8.0). Somebody may
even go crazy and make --depth=v1.6.0..v1.8.0 work. --depth is
probably not the right name anymore. Any SHA-1 would be allowed as
anchor. But I think we need to wait for reachability bitmap feature to
come first so that we can quickly verify the anchor is reachable from
the public refs.
--
Duy
^ 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