* Re: git-subtree
From: David A. Greene @ 2012-01-05 16:26 UTC (permalink / raw)
To: Jeff King; +Cc: Ramkumar Ramachandra, David Greene, git
In-Reply-To: <20120105154740.GA11475@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I think this is also somewhat different in that git-subtree has a
> multi-year history in git that we may want to keep. So it is more
I agree there may be some value in preserving this history.
> The biggest decision is whether or not to import the existing history.
I agree. I will leave that decision to the more experienced git
developers. I'm happy to work either way.
> If we want to throw away the existing history, then I think you end up
> doing the same munging as the latter option above, and then just make a
> single patch out of it instead of a merge.
Right. That's the approach I've taken for now but it's easy to switch.
There aren't that many changes.
> I don't use git-subtree, but just glancing over the repo, it looks like
> that munging is mostly:
>
> 1. git-subtree.sh stays, and gets added to git.git's top-level Makefile
Done.
> 2. the test.sh script gets adapted into t/tXXXX-subtree.sh
Done.
> 3. git-subtree.txt goes into Documentation/
Done.
> 4. The rest of the files are infrastructure that can go away, as they
> are a subset of what git.git already contains.
Done.
I have a patch that does all of the above but it is one monolithic blob.
Like I said, the changes aren't extensive so it's easy for me to change
strategies.
> I'd favor keeping the history and doing the munge-overlay thing.
Ok, that sounds fine to me. I'll do that in a private branch. What
should I send as patches to the mailing list? I'm assuming we don't
want [PATCH 235/12342], etc. sent to the list chronicling the entire
history. :)
> Although part of me wants to join the histories in a subtree so that we
> can use "git subtree" to do it (which would just be cool),
Heh. I thought about that too. :)
> I think the resulting code layout doesn't make much sense unless
> git-subtree is going to be maintained separately.
Yeah, I agree.
-Dave
^ permalink raw reply
* Re: git-subtree
From: David A. Greene @ 2012-01-05 22:16 UTC (permalink / raw)
To: Jeff King; +Cc: Ramkumar Ramachandra, David Greene, git
In-Reply-To: <20120105154740.GA11475@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I think this is also somewhat different in that git-subtree has a
> multi-year history in git that we may want to keep. So it is more
I agree there may be some value in preserving this history.
> The biggest decision is whether or not to import the existing history.
I agree. I will leave that decision to the more experienced git
developers. I'm happy to work either way.
> If we want to throw away the existing history, then I think you end up
> doing the same munging as the latter option above, and then just make a
> single patch out of it instead of a merge.
Right. That's the approach I've taken for now but it's easy to switch.
There aren't that many changes.
> I don't use git-subtree, but just glancing over the repo, it looks like
> that munging is mostly:
>
> 1. git-subtree.sh stays, and gets added to git.git's top-level Makefile
Done.
> 2. the test.sh script gets adapted into t/tXXXX-subtree.sh
Done.
> 3. git-subtree.txt goes into Documentation/
Done.
> 4. The rest of the files are infrastructure that can go away, as they
> are a subset of what git.git already contains.
Done.
I have a patch that does all of the above but it is one monolithic blob.
Like I said, the changes aren't extensive so it's easy for me to change
strategies.
> I'd favor keeping the history and doing the munge-overlay thing.
Ok, that sounds fine to me. I'll do that in a private branch. What
should I send as patches to the mailing list? I'm assuming we don't
want [PATCH 235/12342], etc. sent to the list chronicling the entire
history. :)
> Although part of me wants to join the histories in a subtree so that we
> can use "git subtree" to do it (which would just be cool),
Heh. I thought about that too. :)
> I think the resulting code layout doesn't make much sense unless
> git-subtree is going to be maintained separately.
Yeah, I agree.
-Dave
^ permalink raw reply
* Re: [PATCH] Submodules always use a relative path to gitdir
From: Jens Lehmann @ 2012-01-05 22:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Antony Male, git, iveqy
In-Reply-To: <7vhb0csa6w.fsf@alter.siamese.dyndns.org>
Am 03.01.2012 23:17, schrieb Junio C Hamano:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>
>> Not if we would implement a "if no worktree is set but we came here via
>> a gitfile, then take the directory the gitfile was found in as worktree"
>> heuristic. And that heuristic looks quite sane to me, as a gitfile can
>> only be found in a work tree, or am I missing something obvious here?
>
> Like it wouldn't work without changes to the core side?
I totally agree that when just talking about being able to move the
superproject around that approach is more invasive than just adding
a relative core.worktree setting and is just not worth the hassle.
But I was also thinking about moving the submodule around inside the
superproject. Until the gitfile was used that meant just mv'ing the
submodule and changing the path in .gitmodules accordingly. Now you
also have to adjust the core.worktree setting and maybe also the
gitfile content (if you move the submodule out of the directory level
it lived in before).
One solution I can think of is to teach "git mv" about submodules and
let it do the necessary changes to .gitmodules (which seems to be a
good idea anyways), core.worktree and the gitfile. The manipulation of
core.worktree could be obsoleted by not using that setting but instead
implementing the heuristic I described above. And if the gitfile could
be taught somehow that a path in there is relative to the superprojects
root directory, then it would never have to be changed either, restoring
the behavior we had before introducing the gitfile.
So in the long run I suspect we might have to change core git anyways
to make moving submodules easy for the user (surely "git mv" and maybe
also the setup and gitfile code). Does that make more sense?
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.
^ permalink raw reply
* Re: [PATCH] Submodules always use a relative path to gitdir
From: Junio C Hamano @ 2012-01-06 0:11 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Antony Male, git, iveqy
In-Reply-To: <4F0629C6.9010908@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> So in the long run I suspect we might have to change core git anyways
> to make moving submodules easy for the user (surely "git mv" and maybe
> also the setup and gitfile code). Does that make more sense?
If you need to change "git mv" anyway to help moving submodule checkout,
then how gitfile points into .git/modules/ hierarchy of the superproject
becomes an implementation detail the end users should not have to care
about.
What does "if we reached thru a gitfile, then the working tree is where
you found that gitfile" really solve? The way you found that gitfile is by
traversing the directory hierarchy upwards from a subdirectory of a
working tree of a submodule, and you already know where the top of that
working tree is, no?
And the heuristics would not work if somebody goes into the $GIT_DIR/ that
governs the submodule as going upwards from there will not hit gitfile, so
we would need help from core.worktree anyway. A non-submodule setting that
uses gitfile would need to worry about core.worktree, too, so I'd rather
avoid loading more heuristics to gitfile handling unless there is a clear
advantage for doing so, which I am not really seeing here.
That is not really a "If not" below (i.e. I am not saying it is _not_ OK.
I am saying I don't know what the advantage of that approach is), but ...
> 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.
^ permalink raw reply
* Re: git-subtree
From: David A. Greene @ 2012-01-06 1:53 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: David Greene, git, Junio C Hamano
In-Reply-To: <87sjjuyur3.fsf@smith.obbligato.org>
greened@obbligato.org (David A. Greene) writes:
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>
>> Hi again,
>>
>> [+CC: Junio Hamano, our maintainer]
>>
>> David A. Greene wrote:
>>> I've read that document. The issue is that I didn't develop the code,
>>> Avery did.
>>
>> Not an issue as long as you have Avery's signoff.
Argh. Sorry about all the duplicate replies. I got delivery bounces on
all of them. Must have been a stuck queue or something. So again,
apologies for the noise.
-Dave
^ permalink raw reply
* Re: [PATCH 1/2] daemon: add tests
From: Brian Gernhardt @ 2012-01-06 6:17 UTC (permalink / raw)
To: Clemens Buchacher
Cc: Junio C Hamano, git, Jonathan Nieder, Jeff King, Erik Faye-Lund,
Ilari Liusvaara, Nguyễn Thái Ngọc Duy
In-Reply-To: <1325692539-26748-1-git-send-email-drizzd@aon.at>
On Jan 4, 2012, at 10:55 AM, Clemens Buchacher wrote:
> On Tue, Jan 03, 2012 at 11:34:08AM -0800, Junio C Hamano wrote:
>>> + # kill git-daemon child of git
>>> + say >&3 "Stopping git daemon ..."
>>> + pkill -P "$DAEMON_PID"
>>
>> How portable is this one (I usually do not trust use of pkill anywhere)?
>
> I read that it is supposed to be more portable than skill or killall.
> But I have no way to research this. I have implemented a workaround
> using only 'ps' and 'kill' in [PATCH 3/6] avoid use of pkill.
As a data point: pkill and skill do not exist on OS X 10.7, but killall does.
~~ Brian Gernhardt
^ permalink raw reply
* [PATCH v3] Limit refs to fetch to minimum in shallow clones
From: Nguyễn Thái Ngọc Duy @ 2012-01-06 7:11 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Shawn O. Pearce,
Nguyễn Thái Ngọc Duy
In-Reply-To: <1325743516-14940-1-git-send-email-pclouds@gmail.com>
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>
---
- add --no-single-branch so t5500 works without big changes.
- die() if we cannot find suitable branch to fetch (and suggest --no-single-branch)
- and a bit more tests to exercise new code
--branch=<tag> (or something similar) has to wait until my other
patch gets in a good shape (or gets dropped)
There may be something slightly wrong with shallow code. I expect it
to fetch only 3 objects (1 commit, 1 tree, 1 blob) with --depth=1
in my new test but it fetches 6 (one more commit).
Documentation/git-clone.txt | 12 ++++++++-
builtin/clone.c | 54 ++++++++++++++++++++++++++++++++++++++----
t/t5500-fetch-pack.sh | 34 ++++++++++++++++++++++++++-
3 files changed, 92 insertions(+), 8 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 4b8b26b..58f21d6 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -13,7 +13,8 @@ SYNOPSIS
[-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror]
[-o <name>] [-b <name>] [-u <upload-pack>] [--reference <repository>]
[--separate-git-dir <git dir>]
- [--depth <depth>] [--recursive|--recurse-submodules] [--] <repository>
+ [--depth <depth> [--[no-]single-branch]]
+ [--recursive|--recurse-submodules] [--] <repository>
[<directory>]
DESCRIPTION
@@ -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.
+
--recursive::
--recurse-submodules::
After the clone is created, initialize all submodules within,
diff --git a/builtin/clone.c b/builtin/clone.c
index efe8b6c..3424e1c 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -37,7 +37,7 @@ static const char * const builtin_clone_usage[] = {
NULL
};
-static int option_no_checkout, option_bare, option_mirror;
+static int option_no_checkout, option_bare, option_mirror, option_single_branch = 1;
static int option_local, option_no_hardlinks, option_shared, option_recursive;
static char *option_template, *option_depth;
static char *option_origin = NULL;
@@ -48,6 +48,7 @@ static int option_verbosity;
static int option_progress;
static struct string_list option_config;
static struct string_list option_reference;
+static const char *src_ref_prefix = "refs/heads/";
static int opt_parse_reference(const struct option *opt, const char *arg, int unset)
{
@@ -92,6 +93,8 @@ static struct option builtin_clone_options[] = {
"path to git-upload-pack on the remote"),
OPT_STRING(0, "depth", &option_depth, "depth",
"create a shallow clone of that depth"),
+ OPT_BOOL(0, "single-branch", &option_single_branch,
+ "do not limit fetched refs in shallow clones"),
OPT_STRING(0, "separate-git-dir", &real_git_dir, "gitdir",
"separate git dir from working tree"),
OPT_STRING_LIST('c', "config", &option_config, "key=value",
@@ -427,9 +430,29 @@ static struct ref *wanted_peer_refs(const struct ref *refs,
struct ref *local_refs = head;
struct ref **tail = head ? &head->next : &local_refs;
- get_fetch_map(refs, refspec, &tail, 0);
- if (!option_mirror)
- get_fetch_map(refs, tag_refspec, &tail, 0);
+ if (!(option_depth && option_single_branch)) {
+ get_fetch_map(refs, refspec, &tail, 0);
+ if (!option_mirror)
+ get_fetch_map(refs, tag_refspec, &tail, 0);
+ } else {
+ struct ref *remote_head = NULL;
+
+ 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");
+ get_fetch_map(remote_head, refspec, &tail, 0);
+ }
return local_refs;
}
@@ -448,6 +471,21 @@ static void write_remote_refs(const struct ref *local_refs)
clear_extra_refs();
}
+static void write_followtags(const struct ref *refs, const char *msg)
+{
+ const struct ref *ref;
+ for (ref = refs; ref; ref = ref->next) {
+ if (prefixcmp(ref->name, "refs/tags/"))
+ continue;
+ if (!suffixcmp(ref->name, "^{}"))
+ continue;
+ if (!has_sha1_file(ref->old_sha1))
+ continue;
+ update_ref(msg, ref->name, ref->old_sha1,
+ NULL, 0, DIE_ON_ERR);
+ }
+}
+
static int write_one_config(const char *key, const char *value, void *data)
{
return git_config_set_multivar(key, value ? value : "true", "^$", 0);
@@ -478,7 +516,6 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
struct strbuf key = STRBUF_INIT, value = STRBUF_INIT;
struct strbuf branch_top = STRBUF_INIT, reflog_msg = STRBUF_INIT;
struct transport *transport = NULL;
- char *src_ref_prefix = "refs/heads/";
int err = 0;
struct refspec *refspec;
@@ -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);
+ }
transport_set_verbosity(transport, option_verbosity, option_progress);
@@ -663,6 +703,8 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
clear_extra_refs();
write_remote_refs(mapped_refs);
+ if (option_depth && option_single_branch)
+ write_followtags(refs, reflog_msg.buf);
remote_head = find_ref_by_name(refs, "HEAD");
remote_head_points_at =
diff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh
index bafcca7..c76a53b 100755
--- a/t/t5500-fetch-pack.sh
+++ b/t/t5500-fetch-pack.sh
@@ -115,7 +115,7 @@ pull_to_client 2nd "B" $((64*3))
pull_to_client 3rd "A" $((1*3))
test_expect_success 'clone shallow' '
- git clone --depth 2 "file://$(pwd)/." shallow
+ git clone --no-single-branch --depth 2 "file://$(pwd)/." shallow
'
test_expect_success 'clone shallow object count' '
@@ -248,4 +248,36 @@ test_expect_success 'clone shallow object count' '
grep "^count: 52" count.shallow
'
+test_expect_success 'clone shallow without --no-single-branch' '
+ git clone --depth 1 "file://$(pwd)/." shallow2
+'
+
+test_expect_success 'clone shallow object count' '
+ (
+ cd shallow2 &&
+ git count-objects -v
+ ) > count.shallow2 &&
+ grep "^in-pack: 6" count.shallow2
+'
+
+test_expect_success 'shallow clone pulling tags' '
+ git tag -a -m A TAGA1 A &&
+ git tag -a -m B TAGB1 B &&
+ git tag TAGA2 A &&
+ git tag TAGB2 B &&
+ git clone --depth 1 "file://$(pwd)/." shallow3 &&
+
+ cat >taglist.expected <<\EOF &&
+TAGB1
+TAGB2
+EOF
+ GIT_DIR=shallow3/.git git tag -l >taglist.actual &&
+ test_cmp taglist.expected taglist.actual &&
+
+ echo "in-pack: 7" > count3.expected &&
+ GIT_DIR=shallow3/.git git count-objects -v |
+ grep "^in-pack" > count3.actual &&
+ test_cmp count3.expected count3.actual
+'
+
test_done
--
1.7.3.1.256.g2539c.dirty
^ permalink raw reply related
* Why usage function exit with code 129?
From: 徐迪 @ 2012-01-06 7:15 UTC (permalink / raw)
To: Git 邮件列表
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].
[1] http://tldp.org/LDP/abs/html/exitcodes.html
^ permalink raw reply
* 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
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