* Re: Why usage function exit with code 129?
From: Nguyen Thai Ngoc Duy @ 2012-01-06 7:22 UTC (permalink / raw)
To: 徐迪; +Cc: Git 邮件列表
In-Reply-To: <CAMocUqSbiO2XC3PUEciyV3HxgqDPW_rTW-hYH4P=C=BFCSrQMQ@mail.gmail.com>
2012/1/6 徐迪 <xudifsd@gmail.com>:
> I did like this:
> $ git add --foo
> $ echo $?
> what I got is 129, should this code being used as program terminated
> due to a signal? Cause it's 128+1. According to this[1].
usage() (in your case) always returns 129, die() 128. See 5d1a5c0
([PATCH] Better error reporting for "git status")
> [1] http://tldp.org/LDP/abs/html/exitcodes.html
No it does not mean terminated by signals.
--
Duy
^ permalink raw reply
* Re: [PATCH] clone: allow detached checkout when --branch takes a tag
From: Nguyen Thai Ngoc Duy @ 2012-01-06 7:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7h16nmpy.fsf@alter.siamese.dyndns.org>
2012/1/5 Junio C Hamano <gitster@pobox.com>:
> Also, the user is likely to want to fetch and integrate from the origin
> with his own history. How should "git pull" and "git fetch" work in the
> resulting repository? What should the remote.origin.* look like?
fetch should behave the same regardless this patch. remote.origin.*
looks exactly the same. Branch tracking is not set up so pull works
half way.
> You clone a single lineage of the history, either shallowly or fully,
> either starting at the tip of one single branch or a named tag.
>
> What is the expected use scenario of a resulting repository of this new
> feature? As this is creating a repository, not a tarball extract, you
> certainly would want the user to build further history in the resulting
> repository, and it would need a real branch at some point, preferably
> before any new commit is made. Which makes me think that the only reason
> we would use a detached HEAD would be because we cannot decide what name
> to give to that single branch and make it the responsibility of the user
> to run "git checkout -b $whatever" as the first thing.
We can still commit with detached HEAD but I guess it's not
recommended. For a quick, throwaway repository, it's probably OK.
> I think the real cause of the above is because this patch and its previous
> companion patch conflate the meaning of the "--branch" option with the
> purpose of specifying which lineage of the history to copy. The option is
> described to name the local branch that is checked out, instead of using
> the the same name the remote's primary branch. But these patches abuse the
> option to name something different at the same time---the endpoint of the
> single lineage to be copied.
>
> These two may often be the same, and use of "clone --branch=master" in
> such a case would mean that you want to name the local branch of the final
> checkout to be "master" _and_ the endpoint of the single lineage you are
> copying is also their "master".
>
> But the "tag" extension proposed with this change is different.
>
> You are specifying an endpoint of the single lineage with the option that
> is different from any of the branches at the origin, and because you used
> the "--branch" option for that purpose, you lost the way to specify the
> primary thing the option wanted to express: what the name of the resulting
> checkout should be.
>
> Perhaps something like "clone --branch=master --$endpoint=v1.7.8" that
> says "I want a clone of the repository limited to a single lineage, whose
> history ends at the commit pointed by the v1.7.8 tag, and name the local
> checkout my master branch" be more appropriate?
Branch naming is a local thing. Maybe we could get away with always
name it "master" if fetched from a tag. Branch tracking is not set up
in this case, so if they want to follow up with upstream, they have to
do some more themselves (including renaming "master" to something else
for less confusion with upstream "master"). New option is not easily
discovered, while "git branch -r master foo" is quite easy.
--
Duy
^ permalink raw reply
* Re: Odd remote: error: packfile ./objects/pack/pack-FOO.pack cannot be accessed
From: Sudarshan Wadkar @ 2012-01-06 8:01 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20120103193349.GE20926@sigill.intra.peff.net>
Peff,
Sorry for the delay in reply. Yes, it's the same pack. And if I do `ll
./object/pack/ ` on remote I can see the pack with read perms for all.
However, I observed that the pack I am getting now, is different from
that in my previous email. I am not sure what caused it to change, as
I did lot of commits/push to the remote. I tested with some test
commits to see if it is caused by a particular branch, but the pack is
still the same. Also, previously, if I would push to the remote in
succession without committing anything, I would get "Everything up to
date". But now, it seems that post-receive hook is called second time
too, and I see the "error : packfile".
Here's a shell copy paste : http://pastie.org/3136111
$ git status
# On branch 0.0.4
nothing to commit (working directory clean)
$ git push ourCloud
Total 0 (delta 0), reused 0 (delta 0)
remote: error: packfile
./objects/pack/pack-ff7bb2bee430b314648c084970f6a6877b837a58.pack
cannot be accessed
remote: HEAD is now at cff7a3a Fix mapping action from keyword search to API
remote: HEAD is now at cff7a3a Fix mapping action from keyword search to API
remote: Successfully deployed master into /var/www/html/myProj-master
remote: HEAD is now at 85534ca Test remote error packfile 2
remote: Successfully deployed 0.0.4 into /var/www/html/myProj-0.0.4
To ssh://wadkar@192.168.1.177:7185/~wadkar/repo/bare/myProj
+ 85534ca...cff7a3a master -> master (forced update)
$ git push ourCloud
Total 0 (delta 0), reused 0 (delta 0)
remote: error: packfile
./objects/pack/pack-ff7bb2bee430b314648c084970f6a6877b837a58.pack
cannot be accessed
remote: HEAD is now at cff7a3a Fix mapping action from keyword search to API
remote: HEAD is now at cff7a3a Fix mapping action from keyword search to API
remote: Successfully deployed master into /var/www/html/myProj-master
remote: HEAD is now at 85534ca Test remote error packfile 2
remote: Successfully deployed 0.0.4 into /var/www/html/myProj-0.0.4
To ssh://wadkar@192.168.1.177:7185/~wadkar/repo/bare/myProj
+ 85534ca...cff7a3a master -> master (forced update)
$ vi README.txt #make changes
$ git commit -am 'Test error packfile 3'
Test error packfile 3
1 files changed, 0 insertions(+), 2 deletions(-)
$ git push ourCloud
Counting objects: 5, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 294 bytes, done.
Total 3 (delta 2), reused 0 (delta 0)
remote: error: packfile
./objects/pack/pack-ff7bb2bee430b314648c084970f6a6877b837a58.pack
cannot be accessed
remote: HEAD is now at cff7a3a Fix mapping action from keyword search to API
remote: HEAD is now at cff7a3a Fix mapping action from keyword search to API
remote: Successfully deployed master into /var/www/html/myProj-master
remote: HEAD is now at a0e3f87 Test error packfile 3
remote: Successfully deployed 0.0.4 into /var/www/html/myProj-0.0.4
To ssh://wadkar@192.168.1.177:7185/~wadkar/repo/bare/myProj
85534ca..a0e3f87 0.0.4 -> 0.0.4
+ 85534ca...cff7a3a master -> master (forced update)
$ ssh -p 7185 wadkar@192.168.1.177
##now on remote##
$ ll repo/bare/myProj/objects/pack/
total 672
-r--r--r-- 1 wadkar wadkar 47496 Jan 2 16:52
pack-ff7bb2bee430b314648c084970f6a6877b837a58.idx
-r--r--r-- 1 wadkar wadkar 634393 Jan 2 16:52
pack-ff7bb2bee430b314648c084970f6a6877b837a58.pack
$ logout
Connection to 192.168.1.177 closed.
##back to local##
$ git push ourCloud
Total 0 (delta 0), reused 0 (delta 0)
remote: error: packfile
./objects/pack/pack-ff7bb2bee430b314648c084970f6a6877b837a58.pack
cannot be accessed
remote: HEAD is now at cff7a3a Fix mapping action from keyword search to API
remote: HEAD is now at cff7a3a Fix mapping action from keyword search to API
remote: Successfully deployed master into /var/www/html/myProj-master
remote: HEAD is now at a0e3f87 Test error packfile 3
remote: Successfully deployed 0.0.4 into /var/www/html/myProj-0.0.4
To ssh://wadkar@192.168.1.177:7185/~wadkar/repo/bare/myProj
+ a0e3f87...cff7a3a master -> master (forced update)
$ git push ourCloud
Total 0 (delta 0), reused 0 (delta 0)
remote: error: packfile
./objects/pack/pack-ff7bb2bee430b314648c084970f6a6877b837a58.pack
cannot be accessed
remote: HEAD is now at cff7a3a Fix mapping action from keyword search to API
remote: HEAD is now at cff7a3a Fix mapping action from keyword search to API
remote: Successfully deployed master into /var/www/html/myProj-master
remote: HEAD is now at a0e3f87 Test error packfile 3
remote: Successfully deployed 0.0.4 into /var/www/html/myProj-0.0.4
To ssh://wadkar@192.168.1.177:7185/~wadkar/repo/bare/myProj
+ a0e3f87...cff7a3a master -> master (forced update)
$ ssh -p 7185 wadkar@192.168.1.177
##now on remote##
$ ll repo/bare/myProj/objects/pack/
total 672
-r--r--r-- 1 wadkar wadkar 47496 Jan 2 16:52
pack-ff7bb2bee430b314648c084970f6a6877b837a58.idx
-r--r--r-- 1 wadkar wadkar 634393 Jan 2 16:52
pack-ff7bb2bee430b314648c084970f6a6877b837a58.pack
$ logout
Connection to 192.168.1.177 closed.
##back to local##
$ git checkout master
Switched to branch 'master'
$ git status
# On branch master
nothing to commit (working directory clean)
$ echo 'Foo' >> README.txt
$ git push ourCloud
Counting objects: 5, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 305 bytes, done.
Total 3 (delta 2), reused 0 (delta 0)
remote: error: packfile
./objects/pack/pack-ff7bb2bee430b314648c084970f6a6877b837a58.pack
cannot be accessed
remote: HEAD is now at b220238 Test error packfile 4 (master)
remote: HEAD is now at b220238 Test error packfile 4 (master)
remote: Successfully deployed master into /var/www/html/myProj-master
remote: HEAD is now at a0e3f87 Test error packfile 3
remote: Successfully deployed 0.0.4 into /var/www/html/myProj-0.0.4
To ssh://wadkar@192.168.1.177:7185/~wadkar/repo/bare/myProj
+ a0e3f87...b220238 master -> master (forced update)
$ ssh -p 7185 wadkar@192.168.1.177
##now on remote##
$ ll repo/bare/myProj/objects/pack/
total 672
-r--r--r-- 1 wadkar wadkar 47496 Jan 2 16:52
pack-ff7bb2bee430b314648c084970f6a6877b837a58.idx
-r--r--r-- 1 wadkar wadkar 634393 Jan 2 16:52
pack-ff7bb2bee430b314648c084970f6a6877b837a58.pack
-Sudarshan Wadkar
"Success is getting what you want. Happiness is wanting what you get."
- Dale Carnegie
"It's always our decision who we are"
- Robert Solomon in Waking Life
"The truth is the truth, so all you can do is live with it."
--Systematic Chaos
On Wed, Jan 4, 2012 at 1:03 AM, Jeff King <peff@peff.net> wrote:
> On Mon, Jan 02, 2012 at 02:48:22PM +0530, Sudarshan Wadkar wrote:
>
>> But when I push, I get this odd error from remote
>>
>> $ git push --verbose --mirror
>> ssh://wadkar@192.168.1.177:7185/~wadkar/repo/bare/myproj.git
>> Pushing to ssh://wadkar@192.168.1.177:7185/~wadkar/repo/bare/myproj.git
>> Counting objects: 5, done.
>> Delta compression using up to 4 threads.
>> Compressing objects: 100% (3/3), done.
>> Writing objects: 100% (3/3), 323 bytes, done.
>> Total 3 (delta 2), reused 0 (delta 0)
>> remote: error: packfile
>> ./objects/pack/pack-17900952dc824651db15369a341eec8d3e8f39d2.pack
>> cannot be accessed
>> remote: HEAD is now at 4d5a6f1 Investigate and report odd error
>> To ssh://wadkar@192.168.1.177:7185/~wadkar/repo/bare/myproj.git
>> d066a2f..4d5a6f1 master -> master
>
> Is it always the same pack? If so, have you tried looking in the
> objects/pack directory to make sure it's not a permissions problem?
>
> -Peff
^ permalink raw reply
* Re: Why usage function exit with code 129?
From: 徐迪 @ 2012-01-06 8:06 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Git 邮件列表
In-Reply-To: <CACsJy8Amo_9-9oCgHbwOZvTaNOV3Jj6wLCTU7nZT5LeA55=NEA@mail.gmail.com>
>> [1] http://tldp.org/LDP/abs/html/exitcodes.html
>
> No it does not mean terminated by signals.
> --
In that case, why not just use another code instead of the code that
leads misunderstanding? I mean, as far as I know, exit code between
129 and 255 are used to indicate the program terminated by signal. So
that usage function can only exit with code between 1 and 127. Am I
wrong?
^ permalink raw reply
* Re: Why usage function exit with code 129?
From: Nguyen Thai Ngoc Duy @ 2012-01-06 8:11 UTC (permalink / raw)
To: 徐迪; +Cc: Git 邮件列表
In-Reply-To: <CAMocUqSmes+x_tkP6V0OM5rQ5wDGmMm=Q2MFBPhz6Qvzz_SOTg@mail.gmail.com>
2012/1/6 徐迪 <xudifsd@gmail.com>:
>>> [1] http://tldp.org/LDP/abs/html/exitcodes.html
>>
>> No it does not mean terminated by signals.
>> --
> In that case, why not just use another code instead of the code that
> leads misunderstanding? I mean, as far as I know, exit code between
> 129 and 255 are used to indicate the program terminated by signal. So
> that usage function can only exit with code between 1 and 127. Am I
> wrong?
Because that code has been there too long (since 2005) any probably
all git commands, including plumbing ones, rely on it. Changing it now
may break existing scripts.
--
Duy
^ permalink raw reply
* Managing signed git tags and expiring keys
From: Jonathan "Duke" Leto @ 2012-01-06 8:13 UTC (permalink / raw)
To: Git Users
Howdy,
My question is about the Git workflow in a repository which has signed
tags and uses expiring keys in a chain of trust.
When the key changes, all existing tags are signed with the previous
key in the chain of trust.
Do people:
1) resign all the tags, causing people to overwrite their local tags
2) keep all versions of the keys in the chain of trust
3) something else more involved?
Is anybody doing this currently?
Thanks!
Duke
--
Jonathan "Duke" Leto <jonathan@leto.net>
Leto Labs LLC
209.691.DUKE // http://labs.leto.net
NOTE: Personal email is only checked twice a day at 10am/2pm PST,
please call/text for time-sensitive matters.
^ permalink raw reply
* Re: Why usage function exit with code 129?
From: 徐迪 @ 2012-01-06 8:18 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Git 邮件列表
In-Reply-To: <CACsJy8D8uKGhtg4zjbHsJCGmqjTwodzFmAZ5w=aUx9CdadVAfw@mail.gmail.com>
在 2012年1月6日 下午4:11，Nguyen Thai Ngoc Duy <pclouds@gmail.com> 写道：
> 2012/1/6 徐迪 <xudifsd@gmail.com>:
>>>> [1] http://tldp.org/LDP/abs/html/exitcodes.html
>>>
>>> No it does not mean terminated by signals.
>>> --
>> In that case, why not just use another code instead of the code that
>> leads misunderstanding? I mean, as far as I know, exit code between
>> 129 and 255 are used to indicate the program terminated by signal. So
>> that usage function can only exit with code between 1 and 127. Am I
>> wrong?
>
> Because that code has been there too long (since 2005) any probably
> all git commands, including plumbing ones, rely on it. Changing it now
> may break existing scripts.
> --
> Duy
Ok, that sounds logical.
^ permalink raw reply
* Re: [PATCH] clone: allow detached checkout when --branch takes a tag
From: Nguyen Thai Ngoc Duy @ 2012-01-06 11:09 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20120105141844.GA26771@sigill.intra.peff.net>
2012/1/5 Jeff King <peff@peff.net>:
>> @@ -721,6 +722,14 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
>> strbuf_release(&head);
>>
>> if (!our_head_points_at) {
>> + strbuf_addstr(&head, "refs/tags/");
>> + strbuf_addstr(&head, option_branch);
>> + our_head_points_at =
>> + find_ref_by_name(mapped_refs, head.buf);
>> + strbuf_release(&head);
>> + }
>> +
>> + if (!our_head_points_at) {
>
> Hmm. The context just above your patch that got snipped does this:
>
> strbuf_addstr(&head, src_ref_prefix);
> strbuf_addstr(&head, option_branch);
> our_head_points_at =
> find_ref_by_name(mapped_refs, head.buf);
>
> where src_ref_prefix typically is "refs/heads/", and clearly you are
> meaning to do the same thing for tags. But the use of "src_ref_prefix"
> is interesting.
>
> It is always "refs/heads/" unless we are cloning into a bare mirror, in
> which case it is "refs/". So with your patch in the non-mirror case,
> doing "--branch=foo" would try "refs/heads/foo" followed by
> "refs/tags/foo". Which makes sense. But in the mirror case, it will try
> "refs/foo" followed by "refs/tags/foo", which is kind of odd.
>
> I wonder, though, if the original code makes any sense. By using
> "refs/", I would have to say "--branch=heads/foo", which is kind of
> weird and undocumented. I think it should probably always be
> "refs/heads/", no matter if we are mirroring or not.
--branch should not be used with --mirror in my opinion. --branch
changes HEAD so it's no longer an exact mirror.
--
Duy
^ permalink raw reply
* [PATCH] Documentation: rerere.enabled overrides [ -d rr-cache ]
From: Thomas Rast @ 2012-01-06 13:08 UTC (permalink / raw)
To: git
The wording seems to suggest that you can only globally disable rerere
with the rerere.enabled setting. But the code actually consults the
config first, and even creates rr-cache for the user if needed.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Noticed while discussing rerere on IRC. "Can be disabled by setting
this option to false" is of course correct, but insinuates that
setting it to 'true' still falls back to rr-cache, which it doesn't.
git-rerere(1) does not mention the rr-cache fallback; I decided not to
touch it as it's a bit of an implementation detail. OTOH the
auto-creation of rr-cache can cause strange behavior if a user has
rerere.enabled unset and tries it once, as in
git config rerere.enabled true
git merge ...
git config --unset rerere.enabled
Documentation/config.txt | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 68cf702..04f5e19 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1783,10 +1783,10 @@ rerere.autoupdate::
rerere.enabled::
Activate recording of resolved conflicts, so that identical
- conflict hunks can be resolved automatically, should they
- be encountered again. linkgit:git-rerere[1] command is by
- default enabled if you create `rr-cache` directory under
- `$GIT_DIR`, but can be disabled by setting this option to false.
+ conflict hunks can be resolved automatically, should they be
+ encountered again. By default, linkgit:git-rerere[1] is
+ enabled if there is an `rr-cache` directory under the
+ `$GIT_DIR`.
sendemail.identity::
A configuration identity. When given, causes values in the
--
1.7.8.2.479.g7c686
^ permalink raw reply related
* [PATCH 2/3] show_ref(): remove unused "flag" and "cb_data" arguments
From: mhagger @ 2012-01-06 14:12 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Jakub Narebski, Heiko Voigt, Johan Herland,
Michael Haggerty
In-Reply-To: <1325859153-31016-1-git-send-email-mhagger@alum.mit.edu>
From: Michael Haggerty <mhagger@alum.mit.edu>
The function is not used as a callback, so it doesn't need these
arguments. Also change its return type to void.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
I suppose, though I didn't verify, that the old function signature was
a vestige of its earlier having been used as a callback function. But
it doesn't really matter; the point is that the extra arguments are
currently not needed.
builtin/receive-pack.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index 08df17e..65d129c 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -115,7 +115,7 @@ static int receive_pack_config(const char *var, const char *value, void *cb)
return git_default_config(var, value, cb);
}
-static int show_ref(const char *path, const unsigned char *sha1, int flag, void *cb_data)
+static void show_ref(const char *path, const unsigned char *sha1)
{
if (sent_capabilities)
packet_write(1, "%s %s\n", sha1_to_hex(sha1), path);
@@ -125,10 +125,9 @@ static int show_ref(const char *path, const unsigned char *sha1, int flag, void
" report-status delete-refs side-band-64k",
prefer_ofs_delta ? " ofs-delta" : "");
sent_capabilities = 1;
- return 0;
}
-static int show_ref_cb(const char *path, const unsigned char *sha1, int flag, void *cb_data)
+static int show_ref_cb(const char *path, const unsigned char *sha1, int flag, void *unused)
{
path = strip_namespace(path);
/*
@@ -141,7 +140,8 @@ static int show_ref_cb(const char *path, const unsigned char *sha1, int flag, vo
*/
if (!path)
path = ".have";
- return show_ref(path, sha1, flag, cb_data);
+ show_ref(path, sha1);
+ return 0;
}
static void add_one_alternate_sha1(const unsigned char sha1[20], void *unused)
@@ -163,7 +163,7 @@ static void write_head_info(void)
sha1_array_clear(&sa);
for_each_ref(show_ref_cb, NULL);
if (!sent_capabilities)
- show_ref("capabilities^{}", null_sha1, 0, NULL);
+ show_ref("capabilities^{}", null_sha1);
clear_extra_refs();
/* EOF */
--
1.7.8.2
^ permalink raw reply related
* [PATCH 1/3] receive-pack: move more work into write_head_info()
From: mhagger @ 2012-01-06 14:12 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Jakub Narebski, Heiko Voigt, Johan Herland,
Michael Haggerty
In-Reply-To: <1325859153-31016-1-git-send-email-mhagger@alum.mit.edu>
From: Michael Haggerty <mhagger@alum.mit.edu>
Move some more code from the calling site into write_head_info(), and
inline add_alternate_refs() there. (Some more simplification is
coming, and it is easier if all this code is in the same place.)
Move some helper functions to avoid the need for forward declarations.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
builtin/receive-pack.c | 42 ++++++++++++++++++------------------------
1 files changed, 18 insertions(+), 24 deletions(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index d2dcb7e..08df17e 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -144,12 +144,30 @@ static int show_ref_cb(const char *path, const unsigned char *sha1, int flag, vo
return show_ref(path, sha1, flag, cb_data);
}
+static void add_one_alternate_sha1(const unsigned char sha1[20], void *unused)
+{
+ add_extra_ref(".have", sha1, 0);
+}
+
+static void collect_one_alternate_ref(const struct ref *ref, void *data)
+{
+ struct sha1_array *sa = data;
+ sha1_array_append(sa, ref->old_sha1);
+}
+
static void write_head_info(void)
{
+ struct sha1_array sa = SHA1_ARRAY_INIT;
+ for_each_alternate_ref(collect_one_alternate_ref, &sa);
+ sha1_array_for_each_unique(&sa, add_one_alternate_sha1, NULL);
+ sha1_array_clear(&sa);
for_each_ref(show_ref_cb, NULL);
if (!sent_capabilities)
show_ref("capabilities^{}", null_sha1, 0, NULL);
+ clear_extra_refs();
+ /* EOF */
+ packet_flush(1);
}
struct command {
@@ -869,25 +887,6 @@ static int delete_only(struct command *commands)
return 1;
}
-static void add_one_alternate_sha1(const unsigned char sha1[20], void *unused)
-{
- add_extra_ref(".have", sha1, 0);
-}
-
-static void collect_one_alternate_ref(const struct ref *ref, void *data)
-{
- struct sha1_array *sa = data;
- sha1_array_append(sa, ref->old_sha1);
-}
-
-static void add_alternate_refs(void)
-{
- struct sha1_array sa = SHA1_ARRAY_INIT;
- for_each_alternate_ref(collect_one_alternate_ref, &sa);
- sha1_array_for_each_unique(&sa, add_one_alternate_sha1, NULL);
- sha1_array_clear(&sa);
-}
-
int cmd_receive_pack(int argc, const char **argv, const char *prefix)
{
int advertise_refs = 0;
@@ -937,12 +936,7 @@ int cmd_receive_pack(int argc, const char **argv, const char *prefix)
unpack_limit = receive_unpack_limit;
if (advertise_refs || !stateless_rpc) {
- add_alternate_refs();
write_head_info();
- clear_extra_refs();
-
- /* EOF */
- packet_flush(1);
}
if (advertise_refs)
return 0;
--
1.7.8.2
^ permalink raw reply related
* [PATCH 3/3] write_head_info(): handle "extra refs" locally
From: mhagger @ 2012-01-06 14:12 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Jakub Narebski, Heiko Voigt, Johan Herland,
Michael Haggerty
In-Reply-To: <1325859153-31016-1-git-send-email-mhagger@alum.mit.edu>
From: Michael Haggerty <mhagger@alum.mit.edu>
The old code basically did:
generate array of SHA1s for alternate refs
for each unique SHA1 in array:
add_extra_ref(".have", sha1)
for each ref (including real refs and extra refs):
show_ref(refname, sha1)
But there is no need to stuff the alternate refs in extra_refs; we can
call show_ref() directly when iterating over the array, then handle
real refs separately. So change the code to:
generate array of SHA1s for alternate refs
for each unique SHA1 in array:
show_ref(".have", sha1)
for each ref (this now only includes real refs):
show_ref(refname, sha1)
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
builtin/receive-pack.c | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index 65d129c..8c9e91e 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -144,9 +144,9 @@ static int show_ref_cb(const char *path, const unsigned char *sha1, int flag, vo
return 0;
}
-static void add_one_alternate_sha1(const unsigned char sha1[20], void *unused)
+static void show_one_alternate_sha1(const unsigned char sha1[20], void *unused)
{
- add_extra_ref(".have", sha1, 0);
+ show_ref(".have", sha1);
}
static void collect_one_alternate_ref(const struct ref *ref, void *data)
@@ -159,12 +159,11 @@ static void write_head_info(void)
{
struct sha1_array sa = SHA1_ARRAY_INIT;
for_each_alternate_ref(collect_one_alternate_ref, &sa);
- sha1_array_for_each_unique(&sa, add_one_alternate_sha1, NULL);
+ sha1_array_for_each_unique(&sa, show_one_alternate_sha1, NULL);
sha1_array_clear(&sa);
for_each_ref(show_ref_cb, NULL);
if (!sent_capabilities)
show_ref("capabilities^{}", null_sha1);
- clear_extra_refs();
/* EOF */
packet_flush(1);
--
1.7.8.2
^ permalink raw reply related
* [PATCH 0/3] Eliminate one user of extra_refs
From: mhagger @ 2012-01-06 14:12 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Jakub Narebski, Heiko Voigt, Johan Herland,
Michael Haggerty
From: Michael Haggerty <mhagger@alum.mit.edu>
Receive pack currently uses "extra refs" to keep track of ".have"
references, which in turn are used to tell the source the SHA1s of
references that are already known to the repository via alternates.
But the code already creates an array holding the alternate SHA1s. So
just read the SHA1s out of this array rather then round-tripping them
through the extra_refs mechanism.
This is one step towards hopefully abolishing extra_refs altogether.
I still have to examine the other user.
Michael Haggerty (3):
receive-pack: move more work into write_head_info()
show_ref(): remove unused "flag" and "cb_data" arguments
write_head_info(): handle "extra refs" locally
builtin/receive-pack.c | 51 ++++++++++++++++++++---------------------------
1 files changed, 22 insertions(+), 29 deletions(-)
--
1.7.8.2
^ permalink raw reply
* Re: [PATCH] Submodules always use a relative path to gitdir
From: Phil Hord @ 2012-01-06 14:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jens Lehmann, Antony Male, git, iveqy
In-Reply-To: <7vlipllmfh.fsf@alter.siamese.dyndns.org>
On Thu, Jan 5, 2012 at 7:11 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>> If not I'm fine with just setting core.worktree to a relative path in
>> the git-submodule.sh script (like I did for the gitfile). And I'll look
>> into teaching "git mv" about submodules right after that.
>
> ... teaching "git mv" may be a good move, I would think. I do think keeping
> core.worktree pointing at the right directory is necessary, but I do not
> see much point in making it a relative path, though.
I do, in the case of submodules, as already discussed.
Do you see any _problem_ with making core.worktree a relative
directory in the specific case of git submodules?
Phil
^ permalink raw reply
* Re: Warning from AV software about kill.exe
From: Erik Blake @ 2012-01-06 13:51 UTC (permalink / raw)
To: kusmabite; +Cc: Pat Thoyts, Thomas Rast, git
In-Reply-To: <CABPQNSbd++dAOGu+5+WNMXzF6xtsdTpZq=xeXPbHwmxputXVRA@mail.gmail.com>
On 2012-01-05 17:33, Erik Faye-Lund wrote:
> On Wed, Jan 4, 2012 at 10:15 AM, Erik Blake<erik@icefield.yk.ca> wrote:
>> On 2011-12-22 19:19, Pat Thoyts wrote:
>>> Thomas Rast<trast@student.ethz.ch> writes:
>>>> Erik Blake<erik@icefield.yk.ca> writes:
>>>>
>>>>> I'm running git under Win7 64. As I selected "Repository|Visualize all
>>>>> branch history" in the git gui, my AV software (Trustport) trapped the
>>>>> bin\kill.exe program for "trying to modify system global settings
>>>>> (time, timezone, registry quota, etc.)"
>>>>>
>>>>> Does anyone know the details of this process and what it's function
>>>>> is? First time I've seen it, though I'm a relatively new user.
>>>> 'kill' is a standard unix utility that sends signals to processes, in
>>>> particular signals that cause the processes to exit or be killed
>>>> forcibly by the kernel, hence the name. (I don't know how the windows
>>>> equivalent works under the hood, but presumably it's something similar.)
>>>>
>>>> git-gui and gitk use kill to terminate background worker processes that
>>>> are no longer needed because you closed the window their output would
>>>> have been displayed in, etc.
>>> You might try replacing the command in the tcl scripts with 'exec
>>> taskkill /f /pid $pid' and see if that avoids the error. taskkill is
>>> present on XP and above as part of the OS distribution so shouldn't
>>> suffer any AV complaints.
>>>
>> Another way to implement this (on Windows) would be for the git programs to
>> tag themselves with a mutex. Then the "kill" program can determine which git
>> programs are running and send them user-defined windows messages to shut
>> themselves down. Alternatively, you could send the programs the standard
>> windows WM_CLOSE message, but the OS or an AV program might still be
>> troubled by that behaviour.
>>
>> This is how we implement this type of behaviour in our windows programs. It
>> does not raise the ire of the OS or AV since you do not have one process
>> trying to shut down another. It also bypasses all issues with process
>> privileges etc.
>>
>> Erik
>>
> No thanks. A process is allowed to terminate another process on
> Windows (as long as they are running as the same user, and the access
> token has not been messed with). If your AV detects this and prevents
> it, then your AV is broken. Re-building a kind of cooperative process
> termination for that reason is not the way forward.
>
> But the problem might be that MSYS' kill does more than it's supposed
> to (or misbehaves in some other way). This is, however, something you
> should take up with the MSYS developers, not the git development
> community.
>
> I would take this up with Trustport support. Overly eager AV
> heuristics is a fairly common problem, and usually gets fixed quickly.
>
Either solution should work, but "trying to modify system global
settings (time, timezone, registry quota, etc.)" suggests kill.exe is
overstepping the requirements for terminating another process. As you
suggest, I'll send a note to the MSYS developers. Maybe also ask
Trustport for details on that triggers this message.
e.
^ permalink raw reply
* Re: [PATCH] clone: allow detached checkout when --branch takes a tag
From: Jeff King @ 2012-01-06 14:42 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <CACsJy8BSzQiTScOhvQjLz8mQZC0g3fEOayBxn7n65t1tKwWnsw@mail.gmail.com>
On Fri, Jan 06, 2012 at 06:09:16PM +0700, Nguyen Thai Ngoc Duy wrote:
> > I wonder, though, if the original code makes any sense. By using
> > "refs/", I would have to say "--branch=heads/foo", which is kind of
> > weird and undocumented. I think it should probably always be
> > "refs/heads/", no matter if we are mirroring or not.
>
> --branch should not be used with --mirror in my opinion. --branch
> changes HEAD so it's no longer an exact mirror.
You could be making a repo that mirrors all of the refs, but has a
different HEAD (e.g., the upstream has "development" as the main branch,
but you want a local mirror with "production" as the HEAD).
I agree it's an unlikely combination (which is probably why nobody has
complained about the weird behavior), but I don't see a particular
reason to forbid it.
-Peff
^ permalink raw reply
* Re: [PATCH 0/3] Eliminate one user of extra_refs
From: Jeff King @ 2012-01-06 14:53 UTC (permalink / raw)
To: mhagger; +Cc: Junio C Hamano, git, Jakub Narebski, Heiko Voigt, Johan Herland
In-Reply-To: <1325859153-31016-1-git-send-email-mhagger@alum.mit.edu>
On Fri, Jan 06, 2012 at 03:12:30PM +0100, mhagger@alum.mit.edu wrote:
> Receive pack currently uses "extra refs" to keep track of ".have"
> references, which in turn are used to tell the source the SHA1s of
> references that are already known to the repository via alternates.
>
> But the code already creates an array holding the alternate SHA1s. So
> just read the SHA1s out of this array rather then round-tripping them
> through the extra_refs mechanism.
>
> This is one step towards hopefully abolishing extra_refs altogether.
> I still have to examine the other user.
Thanks, this is a nice simplification. The patches look good to me, and
they produce the same output for a simple test (I happened to be fiddling
with receive-pack and alternates yesterday, so I had a nice test case
right at hand :) ).
> receive-pack: move more work into write_head_info()
BTW, I have a patch to make sending ".have" refs configurable[1] (it
adds a receive.advertiseAlternates config variable), which this patch
conflicts with. I don't think that is your problem, but I thought I
would mention it since you are working in the area. Is that something we
want in git?
-Peff
[1] We are using it at GitHub because our alternates repos are so huge
that the overhead of advertising the refs outweighs the minor
benefits you get from avoiding object transfer.
^ permalink raw reply
* Re: [PATCH] Submodules always use a relative path to gitdir
From: Nguyen Thai Ngoc Duy @ 2012-01-06 15:07 UTC (permalink / raw)
To: Phil Hord; +Cc: Junio C Hamano, Jens Lehmann, Antony Male, git, iveqy
In-Reply-To: <CABURp0rFOFfX7eu-v6ZK07iTfXwhOne60d70GkCdOvx0k8BZkQ@mail.gmail.com>
On Fri, Jan 6, 2012 at 9:26 PM, Phil Hord <phil.hord@gmail.com> wrote:
> Do you see any _problem_ with making core.worktree a relative
> directory in the specific case of git submodules?
Not a problem per se, but you should look at the comment at the top of
t1510 to see where it is relative to. Two interesting rules:
2. .git file is relative to parent directory. .git file is basically
symlink in disguise. The directory where .git file points to will
become new git_dir.
3. core.worktree is relative to git_dir.
--
Duy
^ permalink raw reply
* Re: [PATCH 1/2] daemon: add tests
From: Jeff King @ 2012-01-06 15:52 UTC (permalink / raw)
To: Clemens Buchacher
Cc: Junio C Hamano, git, Jonathan Nieder, Erik Faye-Lund,
Ilari Liusvaara, Nguyễn Thái Ngọc Duy
In-Reply-To: <20120105160612.GA27251@ecki.lan>
On Thu, Jan 05, 2012 at 05:06:15PM +0100, Clemens Buchacher wrote:
> On Wed, Jan 04, 2012 at 09:55:59PM -0500, Jeff King wrote:
> >
> > It so happens that I have just the patch you need. I've been meaning to
> > go over it again and submit it:
> >
> > run-command: optionally kill children on exit
> > https://github.com/peff/git/commit/5523d7ebf2a0386c9c61d7bfbc21375041df4989
>
> Thanks, looks great. But if I add this on top (to enable this for
> "git daemon"), then t0001 kills my entire X session. Not sure yet
> what's going.
Yikes. Thanks for noticing.
What happens is we have a failure case in start_command, set pid to -1,
and then fall through to the end of the function. So we end up marking
"-1" for cleanup, which attempts to kill all processes.
I never noticed it because it can only happen when fork() fails, or when
a child process signals an exec failure (which happens all the time with
aliases, but could not be triggered until your patch).
The fix is to move the recording of the PID up to a spot where we are
certain that it's a real PID. Fixup patch is below, and I'll push a new
version out to my github repo.
-Peff
diff --git a/run-command.c b/run-command.c
index aeb9c6e..614b722 100644
--- a/run-command.c
+++ b/run-command.c
@@ -353,6 +353,8 @@ fail_pipe:
if (cmd->pid < 0)
error("cannot fork() for %s: %s", cmd->argv[0],
strerror(failed_errno = errno));
+ else if (cmd->clean_on_exit)
+ mark_child_for_cleanup(cmd->pid);
/*
* Wait for child's execvp. If the execvp succeeds (or if fork()
@@ -374,8 +376,6 @@ fail_pipe:
}
close(notify_pipe[0]);
- if (cmd->clean_on_exit)
- mark_child_for_cleanup(cmd->pid);
}
#else
{
^ permalink raw reply related
* Re: [RFD] Handling of non-UTF8 data in gitweb
From: Jakub Narebski @ 2012-01-06 16:35 UTC (permalink / raw)
To: git; +Cc: Jürgen Kreileder, John Hawley, Jeff King, Junio C Hamano
In-Reply-To: <201112041709.32212.jnareb@gmail.com>
On Sun, 4 Dec 2011, Jakub Narebski wrote:
>
> Currently gitweb converts data it receives from git commands to Perl
> internal utf8 representation via to_utf8() subroutine
[...]
> Each part of data must be handled separately. It is quite error prone
> process, as can be seen from quite a number of patches that fix handling
> of UTF-8 data (latest from Jürgen).
>
>
> Much, much simpler would be to force opening of all files (including
> output pipes from git commands) in ':utf8' mode:
>
> use open qw(:std :utf8);
>
> [Note: perhaps instead of ':utf8' it should be ':encoding(UTF-8)'
> there...]
>
> But doing this would change gitweb behavior. [...]
[...]
> I don't know if people are relying on the old behavior. I guess
> it could be emulated by defining our own 'utf-8-with-fallback'
> encoding, or by defining our own PerlIO layer with PerlIO::via.
> But it no longer be simple solution (though still automatic).
I have now created simple Encode::UTF8WithFallback module, so that
use Encode::UTF8WithFallback;
use open IN => ':encoding(utf8-with-fallback)';
should be able to replace all calls to to_utf8() without any change
in behavior; at least simple tests shows that.
There however are two problems with this solution:
1. Encode::UTF8WithFallback should really be a separate Perl module
in a separate file (e.g. 'gitweb/lib/Encode/UTF8WithFallback.pm');
I was not able to make it work without a separate file.
This means that it very much requires the change that allows splitting
gitweb into many files and/or load extra helper modules, and/or require
extra non-core modules but provide and install them with gitweb if they
are not available. These changes are ready, and can be find in
'gitweb/split'
branch in my git.git repositories:
http://repo.or.cz/w/git/jnareb-git.git
https://github.com/jnareb/git
2. It turned out that the "open" pragma 1.04 from Perl v5.8.6 does not
work correctly. We need at least "open" 1.06 (version 1.05 consists
supposedly only of documentation-only change).
Because "open" is a core Perl module (core pragma), this means that
gitweb will require in practice Perl v5.8.9 at least, increasing
version requirement from current v5.8.0
--
Jakub Narebski
Poland
^ permalink raw reply
* Aborting "git commit --interactive" discards updates to index (was: Re: [ANNOUNCE] Git 1.7.6)
From: demerphq @ 2012-01-06 16:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Ævar Arnfjörð Bjarmason
On 27 June 2011 17:59, Junio C Hamano <gitster@pobox.com> wrote:
> The latest feature release Git 1.7.6 is available at the usual
> places:
>
> http://www.kernel.org/pub/software/scm/git/
[snip]
> * Aborting "git commit --interactive" discards updates to the index
> made during the interactive session.
Hi, I am wondering why this change was made?
I can sort of understand if people do CTL-C during an interactive
commit that throwing the results away might be useful (although I
don't see why personally), but what I don't understand at all is why
it happens when the "add --interactive" is completed properly, but the
user decided not to actually commit. For me and a number of colleagues
the normal reason we exit the commit part (that is exit the editor
without modifying the commit message) is because we realize we forgot
something, such as adding a new file, and want to exit out and re-add
it. I am writing this after spending about 45 minutes showing a
colleague how to use git commit --interactive, when we realized that
we had forgotten to add a file. Needless to say he wasn't too happy
about losing 45 minutes work and having to redo it.
The new behavior potentially means that a lot of work (such as via the
'e' option) is instantly discarded. I don't understand why this is
perceived to be sensible behavior -- I thought the default policy for
git would be to not lose work!
I would really like an git config option to revert to the previous
behavior of not throwing away what I staged, or even better have git
commit --interactive ask me what I want to do, after all, it is an
interactive process so it seems reasonable it asks before it does
something like throw away work.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* [PATCH] xdiff: print post-image for common records instead of pre-image
From: René Scharfe @ 2012-01-06 17:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Joey Hess
In-Reply-To: <7vlipx4q3r.fsf@alter.siamese.dyndns.org>
Normally it doesn't matter if we show the pre-image or th post-image
for the common parts of a diff because they are the same. If
white-space changes are ignored they can differ, though. The
new text after applying the diff is more interesting in that case,
so show that instead of the old contents.
Note: GNU diff shows the pre-image.
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
t/t4015-diff-whitespace.sh | 14 +++++++-------
xdiff/xemit.c | 12 ++++++------
2 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/t/t4015-diff-whitespace.sh b/t/t4015-diff-whitespace.sh
index 9059bcd..cc3db13 100755
--- a/t/t4015-diff-whitespace.sh
+++ b/t/t4015-diff-whitespace.sh
@@ -103,7 +103,7 @@ test_expect_success 'another test, with -w --ignore-space-at-eol' 'test_cmp expe
git diff -w -b --ignore-space-at-eol > out
test_expect_success 'another test, with -w -b --ignore-space-at-eol' 'test_cmp expect out'
-tr 'Q' '\015' << EOF > expect
+tr 'Q_' '\015 ' << EOF > expect
diff --git a/x b/x
index d99af23..8b32fb5 100644
--- a/x
@@ -111,19 +111,19 @@ index d99af23..8b32fb5 100644
@@ -1,6 +1,6 @@
-whitespace at beginning
+ whitespace at beginning
- whitespace change
+ whitespace change
-whitespace in the middle
+white space in the middle
- whitespace at end
+ whitespace at end__
unchanged line
- CR at endQ
+ CR at end
EOF
git diff -b > out
test_expect_success 'another test, with -b' 'test_cmp expect out'
git diff -b --ignore-space-at-eol > out
test_expect_success 'another test, with -b --ignore-space-at-eol' 'test_cmp expect out'
-tr 'Q' '\015' << EOF > expect
+tr 'Q_' '\015 ' << EOF > expect
diff --git a/x b/x
index d99af23..8b32fb5 100644
--- a/x
@@ -135,9 +135,9 @@ index d99af23..8b32fb5 100644
+ whitespace at beginning
+whitespace change
+white space in the middle
- whitespace at end
+ whitespace at end__
unchanged line
- CR at endQ
+ CR at end
EOF
git diff --ignore-space-at-eol > out
test_expect_success 'another test, with --ignore-space-at-eol' 'test_cmp expect out'
diff --git a/xdiff/xemit.c b/xdiff/xemit.c
index 2e669c3..d11dbf9 100644
--- a/xdiff/xemit.c
+++ b/xdiff/xemit.c
@@ -87,7 +87,7 @@ static long def_ff(const char *rec, long len, char *buf, long sz, void *priv)
static int xdl_emit_common(xdfenv_t *xe, xdchange_t *xscr, xdemitcb_t *ecb,
xdemitconf_t const *xecfg) {
- xdfile_t *xdf = &xe->xdf1;
+ xdfile_t *xdf = &xe->xdf2;
const char *rchg = xdf->rchg;
long ix;
@@ -204,8 +204,8 @@ int xdl_emit_diff(xdfenv_t *xe, xdchange_t *xscr, xdemitcb_t *ecb,
/*
* Emit pre-context.
*/
- for (; s1 < xch->i1; s1++)
- if (xdl_emit_record(&xe->xdf1, s1, " ", ecb) < 0)
+ for (; s2 < xch->i2; s2++)
+ if (xdl_emit_record(&xe->xdf2, s2, " ", ecb) < 0)
return -1;
for (s1 = xch->i1, s2 = xch->i2;; xch = xch->next) {
@@ -213,7 +213,7 @@ int xdl_emit_diff(xdfenv_t *xe, xdchange_t *xscr, xdemitcb_t *ecb,
* Merge previous with current change atom.
*/
for (; s1 < xch->i1 && s2 < xch->i2; s1++, s2++)
- if (xdl_emit_record(&xe->xdf1, s1, " ", ecb) < 0)
+ if (xdl_emit_record(&xe->xdf2, s2, " ", ecb) < 0)
return -1;
/*
@@ -239,8 +239,8 @@ int xdl_emit_diff(xdfenv_t *xe, xdchange_t *xscr, xdemitcb_t *ecb,
/*
* Emit post-context.
*/
- for (s1 = xche->i1 + xche->chg1; s1 < e1; s1++)
- if (xdl_emit_record(&xe->xdf1, s1, " ", ecb) < 0)
+ for (s2 = xche->i2 + xche->chg2; s2 < e2; s2++)
+ if (xdl_emit_record(&xe->xdf2, s2, " ", ecb) < 0)
return -1;
}
--
1.7.8.2
^ permalink raw reply related
* Re: [PATCH v3] Limit refs to fetch to minimum in shallow clones
From: Junio C Hamano @ 2012-01-06 18:40 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Shawn O. Pearce
In-Reply-To: <1325833869-20078-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> The main purpose of shallow clones is to reduce download by only
> fetching objects up to a certain depth from the given refs. The number
> of objects depend on how many refs to follow. So:
>
> - Only fetch HEAD or the ref specified by --branch
> - Only fetch tags that reference to downloaded objects
>
> More tags/branches can be fetched later using git-fetch as usual.
>
> The old behaviour can still be called with --no-single-branch
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
Thanks.
> @@ -179,6 +180,15 @@ objects from the source repository into a pack in the cloned repository.
> with a long history, and would want to send in fixes
> as patches.
>
> +--single-branch::
> +--no-single-branch::
> + These options are only valid when --depth is given.
> + `--single-branch` only fetches one branch (either HEAD or
> + specified by --branch) and tags that point to the downloaded
> + history. `--no-single-branch` fetches all branches and tags
> + like in normal clones. `--single-branch` is implied by
> + default.
> +
My first reaction after reading "is implied by default" was "Huh? didn't
we just read these kick in only when --depth is given?" and I had to read
it again. Here is my attempt to rephrase it.
Clone only the history leading to the tip of a single branch,
either specified by the `--branch` option or the primary branch
remote's `HEAD` points at. When creating a shallow clone with the
`--depth` option, this is the default, unless `--no-single-branch`
is given to fetch the histories near the tips of all branches.
Currently this option only works when creating a shallow clone and
does not have any effect without the `--depth` option.
We might want to later enhance this to work also with a full-depth clone
that tracks only one branch, and the above phrasing would make it clear.
> + if (!option_branch)
> + remote_head = guess_remote_head(head, refs, 0);
> + else {
> + struct strbuf sb = STRBUF_INIT;
> + strbuf_addstr(&sb, src_ref_prefix);
> + strbuf_addstr(&sb, option_branch);
> + remote_head = find_ref_by_name(refs, sb.buf);
> + strbuf_release(&sb);
> + }
> +
> + if (!remote_head)
> + die(_("Remote branch \"%s\" not found. Nothing to clone.\n"
> + "Try --no-single-branch to fetch all refs."),
> + option_branch ? option_branch : "HEAD");
Switching upon option_branch to tweak the message is a good idea, but
strictly speaking, we would hit this die() when guess_remote_head() does
not find where HEAD points at because it is detached, and in that case,
the error is not "Nothing to clone", but "We couldn't tell which branch
you meant to limit this cloning to".
> @@ -642,9 +679,12 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
>
> transport_set_option(transport, TRANS_OPT_KEEP, "yes");
>
> - if (option_depth)
> + if (option_depth) {
> transport_set_option(transport, TRANS_OPT_DEPTH,
> option_depth);
> + transport_set_option(transport, TRANS_OPT_FOLLOWTAGS,
> + option_single_branch ? "1" : NULL);
Curious. Does anybody set FOLLOWTAGS to the transport by default becore we
come here (just asking)?
^ permalink raw reply
* Re: [PATCH] Submodules always use a relative path to gitdir
From: Junio C Hamano @ 2012-01-06 18:53 UTC (permalink / raw)
To: Phil Hord; +Cc: Jens Lehmann, Antony Male, git, iveqy
In-Reply-To: <CABURp0rFOFfX7eu-v6ZK07iTfXwhOne60d70GkCdOvx0k8BZkQ@mail.gmail.com>
Phil Hord <phil.hord@gmail.com> writes:
> On Thu, Jan 5, 2012 at 7:11 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Jens Lehmann <Jens.Lehmann@web.de> writes:
>>> If not I'm fine with just setting core.worktree to a relative path in
>>> the git-submodule.sh script (like I did for the gitfile). And I'll look
>>> into teaching "git mv" about submodules right after that.
>>
>> ... teaching "git mv" may be a good move, I would think. I do think keeping
>> core.worktree pointing at the right directory is necessary, but I do not
>> see much point in making it a relative path, though.
>
> I do, in the case of submodules, as already discussed.
Of course you are right.
^ permalink raw reply
* Re: [PATCH] xdiff: print post-image for common records instead of pre-image
From: Junio C Hamano @ 2012-01-06 19:10 UTC (permalink / raw)
To: René Scharfe; +Cc: git, Joey Hess
In-Reply-To: <4F072B9C.1030005@lsrfire.ath.cx>
Thanks.
^ 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