* Re: [PATCH 2/2] add a Makefile switch to avoid gettext translation in shell scripts
From: Junio C Hamano @ 2012-01-24 20:13 UTC (permalink / raw)
To: Alex Riesen
Cc: Git Mailing List, Ævar Arnfjörð, Jonathan Nieder
In-Reply-To: <CALxABCaGMabTLcCiYLv31YCiVY4OK7yEr4KL6e-0UMttMjGA_g@mail.gmail.com>
> Amen :)
Thanks.
^ permalink raw reply
* Re: {Spam?} push pull not working
From: Junio C Hamano @ 2012-01-24 20:12 UTC (permalink / raw)
To: Jeff King; +Cc: Rick Bragg, GIT Mailing-list
In-Reply-To: <20120124194153.GB19534@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> For example, imagine repo1 has two branches, "master" and "foo", and the
> "master" branch is checked out. When you clone it, the resulting repo2
> will have remote-tracking branches for both "master" and "foo", but will
> only checkout the "master" branch. Now imagine you make commits on
> "foo" in repo1, and then try to push. Git's default behavior is to push
> only branches which match (by name) a branch on the destination. So we
> would attempt to push "master" (which is up to date), but not "foo".
Technically you are not saying anything incorrect, but the above is not an
appropriate paragraph to give to a total newbie, I would have to say.
It does not make it clear that it is insane to push to repo2 with matching
push (or "current" or "upstream" for that matter), after cloning from a
repository repo1 with a working tree to repo2 with an working tree, and
making changes at the original repo1 repository. Instead, you are giving a
false impression that pushing both "master" and "foo" explicitly would
solve the problem OP is having, which is not true.
If repo1 and repo2 with working trees want to criss-cross-exchange their
histories, both should "git pull" from the other, not "git push", and if
one side cannot initiate a connection to the other, "git push" that goes
in the other direction should be pushing into remote tracking refs of the
other in order to emulate a "git pull" that goes in the other direction.
^ permalink raw reply
* Re: [PATCH/RFC 3/2] i18n: do not use gettext.sh by default when NO_GETTEXT is set
From: Alex Riesen @ 2012-01-24 20:06 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, Git Mailing List, Ævar Arnfjörð
In-Reply-To: <20120124003109.GB26980@burratino>
On Tue, Jan 24, 2012 at 01:31, Jonathan Nieder <jrnieder@gmail.com> wrote:
> + ifndef USE_GETTEXT_SCHEME
> + USE_GETTEXT_SCHEME = fallthrough
> + endif
We already use GNU make features (+=), so this can be just
USE_GETTEXT_SCHEME ?= fallthrough
I think...
^ permalink raw reply
* {Spam?} Re: push pull not working
From: Rick Bragg @ 2012-01-24 20:05 UTC (permalink / raw)
To: Jeff King; +Cc: GIT Mailing-list
In-Reply-To: <20120124194153.GB19534@sigill.intra.peff.net>
On Tue, 2012-01-24 at 14:41 -0500, Jeff King wrote:
> On Tue, Jan 24, 2012 at 02:00:31PM -0500, Rick Bragg wrote:
>
> > I cloned a repo from /home/me/repo1 to /home/me/repo2. Then made
> > changes and a new commit on repo1, then from repo1 did "git
> > push /home/me/repo2 and it says Everything is up-to-date. How could
> > this be?
>
> It's hard to say, since you didn't show us the exact commands you ran.
>
> One possible cause is that you made your commit on a detached HEAD, not
> on a branch, and therefore pushing branches will have no effect. You can
> check this by running "git status", which will report either your
> current branch or "not currently on any branch".
>
> Another possible cause is that git is not trying to push the branches
> that you think it is.
>
> For example, imagine repo1 has two branches, "master" and "foo", and the
> "master" branch is checked out. When you clone it, the resulting repo2
> will have remote-tracking branches for both "master" and "foo", but will
> only checkout the "master" branch. Now imagine you make commits on
> "foo" in repo1, and then try to push. Git's default behavior is to push
> only branches which match (by name) a branch on the destination. So we
> would attempt to push "master" (which is up to date), but not "foo".
>
> You can see which branches are being considered in the push with "git
> push -vv". If you want to push all branches, you can use "git push
> --all", or read up on refspecs in "git help push". If you want to change
> git-push's default behavior, read up on "push.default" in "git help
> config".
>
> -Peff
>
Thanks, I went back a few commits and tried again and it works. I'm not
sure what it was, I will have allot of reading to do.
Thanks again!
Rick
^ permalink raw reply
* Re: [PATCH 2/2] add a Makefile switch to avoid gettext translation in shell scripts
From: Alex Riesen @ 2012-01-24 20:00 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git Mailing List, Ævar Arnfjörð, Jonathan Nieder
In-Reply-To: <7vr4yq6poy.fsf_-_@alter.siamese.dyndns.org>
On Mon, Jan 23, 2012 at 23:04, Junio C Hamano <gitster@pobox.com> wrote:
> From: Alex Riesen <raa.lkml@gmail.com>
>
> Some systems have gettext.sh (GNU gettext) installed, but it is either
> broken or misconfigured in such a way so its output is not usable. In
> case the users of these systems are unable or not interested in fixing
> them, setting the new Makefile switch should help:
>
> make USE_GETTEXT_SCHEME=fallthrough
>
> This will replace the translation routines with fallthrough versions,
> that does not use gettext from the platform.
>
> Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Amen :)
^ permalink raw reply
* Re: [PATCH 2/2] add a Makefile switch to avoid gettext translation in shell scripts
From: Alex Riesen @ 2012-01-24 19:59 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, Git Mailing List, Ævar Arnfjörð
In-Reply-To: <20120123221256.GG20833@burratino>
On Mon, Jan 23, 2012 at 23:12, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Here's a patch to consider squashing in that makes the option take
> effect if it changes between builds.
Which actually bit me once, when I was playing with the code :)
^ permalink raw reply
* Re: {Spam?} push pull not working
From: Jeff King @ 2012-01-24 19:41 UTC (permalink / raw)
To: Rick Bragg; +Cc: GIT Mailing-list
In-Reply-To: <1327431631.21582.209.camel@thor>
On Tue, Jan 24, 2012 at 02:00:31PM -0500, Rick Bragg wrote:
> I cloned a repo from /home/me/repo1 to /home/me/repo2. Then made
> changes and a new commit on repo1, then from repo1 did "git
> push /home/me/repo2 and it says Everything is up-to-date. How could
> this be?
It's hard to say, since you didn't show us the exact commands you ran.
One possible cause is that you made your commit on a detached HEAD, not
on a branch, and therefore pushing branches will have no effect. You can
check this by running "git status", which will report either your
current branch or "not currently on any branch".
Another possible cause is that git is not trying to push the branches
that you think it is.
For example, imagine repo1 has two branches, "master" and "foo", and the
"master" branch is checked out. When you clone it, the resulting repo2
will have remote-tracking branches for both "master" and "foo", but will
only checkout the "master" branch. Now imagine you make commits on
"foo" in repo1, and then try to push. Git's default behavior is to push
only branches which match (by name) a branch on the destination. So we
would attempt to push "master" (which is up to date), but not "foo".
You can see which branches are being considered in the push with "git
push -vv". If you want to push all branches, you can use "git push
--all", or read up on refspecs in "git help push". If you want to change
git-push's default behavior, read up on "push.default" in "git help
config".
-Peff
^ permalink raw reply
* [BUG] Fail to add a module in a subdirectory if module is already cloned
From: Jehan Bing @ 2012-01-24 19:11 UTC (permalink / raw)
To: git
Hi,
I'm getting an error if I try to add a module in a subdirectory and that
module is already cloned.
Here are the steps to reproduce (git 1.7.8.3):
git init module
cd module
echo foo > foo
git add foo
git commit -m "init"
cd ..
git init super
cd super
echo foo > foo
git add foo
git commit -m "init"
git branch b1
git branch b2
git checkout b1
git submodule add ../module lib/module
git commit -m "module"
git checkout b2
rm -rf lib
git submodule add ../module lib/module
The last command returns:
fatal: Not a git repository: ../.git/modules/lib/module
Unable to checkout submodule 'lib/module'
The file lib/modules/.git contains:
gitdir: ../.git/modules/lib/module
(missing an additional "../")
In branch b1, after adding the module, the file contained the full path:
gitdir: /[...]/super/.git/modules/lib/module
Or contains the correct relative path after checking out b1 later:
gitdir: ../../.git/modules/lib/module
Regards,
Jehan
^ permalink raw reply
* {Spam?} push pull not working
From: Rick Bragg @ 2012-01-24 19:00 UTC (permalink / raw)
To: GIT Mailing-list
Hi,
I cloned a repo from /home/me/repo1 to /home/me/repo2. Then made
changes and a new commit on repo1, then from repo1 did "git
push /home/me/repo2 and it says Everything is up-to-date. How could
this be?
Thanks
Rick
^ permalink raw reply
* Re: What does "modified" in git status mean?
From: Jeff King @ 2012-01-24 18:57 UTC (permalink / raw)
To: Mikolas; +Cc: git
In-Reply-To: <loom.20120122T174204-274@post.gmane.org>
On Sun, Jan 22, 2012 at 04:57:52PM +0000, Mikolas wrote:
> So it looks something like this:
> $ git status
> # On branch master
> nothing to commit (working directory clean)
>
> $ cd foo
> $ git status
> # On branch master
> # Changes not staged for commit:
> # (use "git add <file>..." to update what will be committed)
> # (use "git checkout -- <file>..." to discard changes in working directory)
> #
> # modified: ../foo/bar
Modified files appearing only in some calls to status is definitely odd,
and may be a bug. How close is this to your actual invocation?
In particular, if "foo/bar" is modified, and you do "cd foo && git
status", then the relative path shown by "git status" should be simply
"bar", not "../foo/bar". If you did "cd other && git status", then I
would expect it to say "../foo/bar".
So was the directory you entered the same as the one that contains the
(supposedly) modified file, yielding the output above?
If that is the case, then I might suspect it has to do with path
normalization and case sensitivity. It might be worth seeing if you can
reproduce the problem with a more recent version of git. In particular,
v1.7.8 and later shipped with my 2548183 (fix phantom untracked files
when core.ignorecase is set, 2011-10-06), which fixes some weird bugs
surrounding case-insensitive file lookup.
(Actually, even if that is not the case, it would be worth upgrading and
seeing if the bug is reproducible).
> So my questions are
> 1) Is there some way how to tell status to tell me *why* the files are marked
> as modified?
Typically you would ask "diff" for more details. But since "diff" is not
reporting anything, that isn't helpful (and is probably indicative of a
bug).
> 2) Is it normal that git status behaves differently in different directories?
No.
-Peff
^ permalink raw reply
* Re: Finding all commits which modify a file
From: Santi Béjar @ 2012-01-24 18:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Neal Groothuis, Neal Kreitzinger, git, Junio C Hamano
In-Reply-To: <CA+gHt1AYrCv_9MJwBntt_+-GRb4N81PxxO8HXP-XU0pCiFWAVw@mail.gmail.com>
On Tue, Jan 24, 2012 at 2:36 AM, Santi Béjar <santi@agolina.net> wrote:
> On Tue, Jan 24, 2012 at 2:15 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>> On Mon, Jan 23, 2012 at 4:58 PM, Santi Béjar <santi@agolina.net> wrote:
>>>
>>> If you add parent rewriting (--parent, --graph or see it in gitk, with
>>> --full-history) you'll get your B2 commit as it adds commits to have a
>>> meaningful history. But I don't think this is what you are asking for.
>>>
>>> You could try the following patch (sorry for the whitespace damage,
>>> also attatched):
>>>
>>> Subject: [PATCH/RFC] revision: merging branches with different content
>>> is interesting in --full-history
>>
>> The concept seems sane.
>>
>> But please check the interaction with "--simplify-merges" too, just in
>> case. The merge simplification looks at TREESAME too, so I suspect
>> your change may break merge simplification.
>
> Indeed, there is a bad interaction with --simplify-merges. If you add
> --simplify-merges it not only increase the number of commit but
> changes them :-(
>
> $ ./git rev-list --full-history --simplify-merges HEAD Makefile >
> rev-list.simp-merges
> $ ./git rev-list --full-history HEAD Makefile > rev-list.new
> $ diff rev-list.new rev-list.simp-merges -u | diffstat
> rev-list.simp-merges | 1841 ++++++++++++++++++++++++++-------------------------
> 1 file changed, 944 insertions(+), 897 deletions(-)
Ops, it even happens without my patch...
I think it is OK, it just redefines what is TREESAME, and use the new
meaning in:
* If after this parent rewriting, `C'` is a root or merge commit (has
zero or >1 parents), a boundary commit, or !TREESAME, it remains.
Otherwise, it is replaced with its only parent.
We could keep the old meaning if --simplify-merges or we could have a
flag to just change the meaning of TREESAME for merges
(--with-all-interesting-merges? I'm not good at naming flags...)
Santi
^ permalink raw reply
* Re: Correct way to pull using subtree merge without guesswork?
From: Junio C Hamano @ 2012-01-24 18:27 UTC (permalink / raw)
To: Manuel Reimer; +Cc: git
In-Reply-To: <jfmr88$1p8$1@dough.gmane.org>
Manuel Reimer <Manuel.Spam@nurfuerspam.de> writes:
> git pull -s subtree -X subtree=path/to/subtree externalproject master
>
> Returns with success, but is "-X subtree=" the right way to force a
> subtree path and disallow git to autodetect the subtree?
More or less. Note that with the syntax, you cannot still express the
distinction between mapping the root of external to path/to/subtree of
your current tree and mapping the other way around, but that is not an
issue in practice.
By the way, I had an impression that "-X subtree" makes "-s subtree"
redundant and unnecessary.
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.7.9.rc2
From: Junio C Hamano @ 2012-01-24 18:11 UTC (permalink / raw)
To: fREW Schmidt; +Cc: git
In-Reply-To: <CADVrmKT2RAOC-n_-h4pGJw91imj28h0-HqwGH-NOu-m3XtqiJg@mail.gmail.com>
fREW Schmidt <frioux@gmail.com> writes:
> On Wed, Jan 18, 2012 at 7:16 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> * gitk updates accumulated since early 2011.
>
> Where might one go to find more detail on this one?
Hmm, http://git.kernel.org/?p=git/git.git;a=shortlog, perhaps?
^ permalink raw reply
* Re: Finding all commits which modify a file
From: Santi Béjar @ 2012-01-24 18:10 UTC (permalink / raw)
To: Neal Groothuis, Junio C Hamano, Linus Torvalds; +Cc: git
In-Reply-To: <52932.38.96.167.131.1327422884.squirrel@mail.lo-cal.org>
[ Do not cut the CC]
On Tue, Jan 24, 2012 at 5:34 PM, Neal Groothuis <ngroot@lo-cal.org> wrote:
>> On Mon, Jan 23, 2012 at 5:14 PM, Neal Groothuis <ngroot@lo-cal.org> wrote:
>>>> On 1/20/2012 3:35 PM, Neal Groothuis wrote:
>>>>> I'm trying to find /all/ commits that change a file in the
>>>>> repository...and its proving to be trickier than I thought. :-)
>>>
>>> On 1/21/2012 6:16 PM, Neal Kreitzinger wrote:
>>>> Does git-log --all help?
>>>
>>> I don't see how it would. The commits are all reachable from HEAD,
>>> which
>>> would seem to be the problem that --all would correct.
>>>
>>> What I'm trying to do is find the commits in which a file differs from
>>> that same file in any of its parents.
>>
>> If you add parent rewriting (--parent, --graph or see it in gitk, with
>> --full-history) you'll get your B2 commit as it adds commits to have a
>> meaningful history. But I don't think this is what you are asking for.
>
> Correct. If I add parent rewriting, I get all merges, even those in which
> the file is not changed from either parent.
>
> Based on what's in the man page for git log about the history
> simplification algorithm, it seems that B2 should be included in the
> output when I do a git log --full-history --simplify-history foo.txt, as
> per the steps I noted in the original post. Is my understanding of the
> algorithm faulty?
>
Following your steps in the first post, B2 is excluded in the
--simplify-merge phase because it is (originally) TREESAME, even if it
is not in the rewritten history...
HTH,
Santi
^ permalink raw reply
* Correct way to pull using subtree merge without guesswork?
From: Manuel Reimer @ 2012-01-24 17:49 UTC (permalink / raw)
To: git
Hello,
can someone please tell me, if this is the correct syntax for using "git pull"
to pull in "subtree merging strategy", if I don't want to allow git to guess
where to do the changes:
git pull -s subtree -X subtree=path/to/subtree externalproject master
Returns with success, but is "-X subtree=" the right way to force a subtree path
and disallow git to autodetect the subtree?
$ git --version
git version 1.7.4.4
Thank you very much in advance
Yours
Manuel
^ permalink raw reply
* Re: Finding all commits which modify a file
From: Neal Groothuis @ 2012-01-24 16:34 UTC (permalink / raw)
To: Santi Béjar; +Cc: git
In-Reply-To: <CA+gHt1DxY42W9g+gJQTFrXuXBN-Jny+Jg60gKssdftZ5wxu91A@mail.gmail.com>
> On Mon, Jan 23, 2012 at 5:14 PM, Neal Groothuis <ngroot@lo-cal.org> wrote:
>>> On 1/20/2012 3:35 PM, Neal Groothuis wrote:
>>>> I'm trying to find /all/ commits that change a file in the
>>>> repository...and its proving to be trickier than I thought. :-)
>>
>> On 1/21/2012 6:16 PM, Neal Kreitzinger wrote:
>>> Does git-log --all help?
>>
>> I don't see how it would. The commits are all reachable from HEAD,
>> which
>> would seem to be the problem that --all would correct.
>>
>> What I'm trying to do is find the commits in which a file differs from
>> that same file in any of its parents.
>
> If you add parent rewriting (--parent, --graph or see it in gitk, with
> --full-history) you'll get your B2 commit as it adds commits to have a
> meaningful history. But I don't think this is what you are asking for.
Correct. If I add parent rewriting, I get all merges, even those in which
the file is not changed from either parent.
Based on what's in the man page for git log about the history
simplification algorithm, it seems that B2 should be included in the
output when I do a git log --full-history --simplify-history foo.txt, as
per the steps I noted in the original post. Is my understanding of the
algorithm faulty?
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.7.9.rc2
From: fREW Schmidt @ 2012-01-24 16:16 UTC (permalink / raw)
To: git, Linux Kernel
In-Reply-To: <7vpqegjxu3.fsf@alter.siamese.dyndns.org>
On Wed, Jan 18, 2012 at 7:16 PM, Junio C Hamano <gitster@pobox.com> wrote:
> * gitk updates accumulated since early 2011.
Where might one go to find more detail on this one?
--
fREW Schmidt
http://blog.afoolishmanifesto.com
^ permalink raw reply
* Re: Most reliable method to detect a merge commit in pre-commit hook
From: Stefan Haller @ 2012-01-24 15:10 UTC (permalink / raw)
To: Sebastian Schuberth, git
In-Reply-To: <jfmegi$scg$1@dough.gmane.org>
Sebastian Schuberth <sschuberth@gmail.com> wrote:
> I'd like our pre-commit hook to skip some checks if the commit that's
> about to be made is a merge commit. What's the most reliable way to
> detect a merge commit from within a pre-commit hook script? Currently,
> the only way I see is to check whether .git/MERGE_MSG exists, but I'd
> feel safer to check whether the commit is going to have more than one
> parent or so. Is that possible / a better detection?
I haven't found a better way either, so this is the method we use too.
The problem is that it fails when you are amending a merge commit; so
the output of our pre-commit hook advises the user to manually do a "git
commit --no-verify" in that case.
--
Stefan Haller
Berlin, Germany
http://www.haller-berlin.de/
^ permalink raw reply
* Most reliable method to detect a merge commit in pre-commit hook
From: Sebastian Schuberth @ 2012-01-24 14:16 UTC (permalink / raw)
To: git
Hi,
I'd like our pre-commit hook to skip some checks if the commit that's
about to be made is a merge commit. What's the most reliable way to
detect a merge commit from within a pre-commit hook script? Currently,
the only way I see is to check whether .git/MERGE_MSG exists, but I'd
feel safer to check whether the commit is going to have more than one
parent or so. Is that possible / a better detection?
--
Sebastian Schuberth
^ permalink raw reply
* Re: rsync a *bunch* of git repos
From: Jason @ 2012-01-24 14:11 UTC (permalink / raw)
To: Seth Robertson; +Cc: git
In-Reply-To: <201201102124.q0ALOowL026941@no.baka.org>
Hi Seth,
On Tue, Jan 10, 2012 at 04:24:50PM -0500, Seth Robertson wrote:
>
> In message <20120110211548.GD10255@titan.lakedaemon.net>, Jason writes:
>
> The nuts and bolts of this aren't difficult, the problem is I don't have
> a complete understanding of how git stores data. I've heard in the
> past that it uses a lot of hardlinks and softlinks. I need to make
> sure, that once I transfer the data, and reboot the machine with the new
> partition mounted under /home, that all my git repos will be okay.
>
> Under most circumstances, git will do the right thing. Only if you
> use specific flags on clone (like --shared or --reference) might
> something go wrong, and as the manual page explains, you can use
> git-repack to undo these.
>
> The real solution is, after you rsync, to:
>
> for f in */.git; do (cd $f; git fsck >&/dev/null || echo "$f is BAD!!"); done
Okay, I've been using the new system for a week or so now, and
everything looks good. Thanks!
Before the transfer, I went ahead and did the above to make sure the
repos were good to begin with. All 279 of them were fine, both before
and after.
thx,
Jason.
^ permalink raw reply
* [PATCH] clone: fix up delay cloning conditions
From: Nguyễn Thái Ngọc Duy @ 2012-01-24 11:10 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King, Nguyễn Thái Ngọc Duy
6f48d39 (clone: delay cloning until after remote HEAD checking -
2012-01-16) allows us to perform some checks on remote refs before the
actual cloning happens. But not all transport types support
this. Remote helper with "import" capability will not return complete
ref information until fetch is performed and therefore the clone cannot
be delayed.
foreign_vcs field in struct remote was used to detect this kind of transport
and save the result. This is a mistake because foreign_vcs is designed
to override url-based transport detection. As a result, if the same
"struct transport *" object is used on many different urls and one of
them attached remote transport, the following urls will be mistakenly
attached to the same transport. This fault is worked around by dad0b3d
(push: do not let configured foreign-vcs permanently clobbered -
2012-01-23)
To fix this, detect incomplete refs from transport_get_remote_refs()
by SHA-1. Incomplete ones must have null SHA-1 (*). Then revert
changes related to foreign_cvs field in 6f48d39 and dad0b3d.
A good thing from this change is that cloning smart http transport can
also be delayed. Earlier it falls into the same category "remote
transport, no delay".
(*) Theoretically if one of the remote refs happens to have null SHA-1,
it will trigger false alarm and the clone will not be delayed. But
that chance may be too small for us to pay attention to.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin/clone.c | 20 ++++++++++++++------
builtin/push.c | 2 --
transport.c | 5 +----
3 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/builtin/clone.c b/builtin/clone.c
index 72eebca..379cafa 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -631,12 +631,13 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
const struct ref *remote_head_points_at;
const struct ref *our_head_points_at;
struct ref *mapped_refs;
+ const struct ref *ref;
struct strbuf key = STRBUF_INIT, value = STRBUF_INIT;
struct strbuf branch_top = STRBUF_INIT, reflog_msg = STRBUF_INIT;
struct transport *transport = NULL;
const char *src_ref_prefix = "refs/heads/";
struct remote *remote;
- int err = 0;
+ int err = 0, complete_refs_before_fetch = 1;
struct refspec *refspec;
const char *fetch_pattern;
@@ -816,15 +817,22 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
mapped_refs = refs ? wanted_peer_refs(refs, refspec) : NULL;
/*
- * mapped_refs may be updated if transport-helper is used so
- * we need fetch it early because remote_head code below
- * relies on it.
+ * transport_get_remote_refs() may return refs with null sha-1
+ * in mapped_refs (see struct transport->get_refs_list
+ * comment). In that case we need fetch it early because
+ * remote_head code below relies on it.
*
* for normal clones, transport_get_remote_refs() should
* return reliable ref set, we can delay cloning until after
* remote HEAD check.
*/
- if (!is_local && remote->foreign_vcs && refs)
+ for (ref = refs; ref; ref = ref->next)
+ if (is_null_sha1(ref->old_sha1)) {
+ complete_refs_before_fetch = 0;
+ break;
+ }
+
+ if (!is_local && !complete_refs_before_fetch && refs)
transport_fetch_refs(transport, mapped_refs);
if (refs) {
@@ -856,7 +864,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
if (is_local)
clone_local(path, git_dir);
- else if (refs && !remote->foreign_vcs)
+ else if (refs && complete_refs_before_fetch)
transport_fetch_refs(transport, mapped_refs);
update_remote_refs(refs, mapped_refs, remote_head_points_at,
diff --git a/builtin/push.c b/builtin/push.c
index 5fb98a0..35cce53 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -204,13 +204,11 @@ static int do_push(const char *repo, int flags)
url_nr = remote->url_nr;
}
if (url_nr) {
- const char *configured_foreign_vcs = remote->foreign_vcs;
for (i = 0; i < url_nr; i++) {
struct transport *transport =
transport_get(remote, url[i]);
if (push_with_options(transport, flags))
errs++;
- remote->foreign_vcs = configured_foreign_vcs;
}
} else {
struct transport *transport =
diff --git a/transport.c b/transport.c
index 4366639..a99b7c9 100644
--- a/transport.c
+++ b/transport.c
@@ -895,10 +895,8 @@ struct transport *transport_get(struct remote *remote, const char *url)
while (is_urlschemechar(p == url, *p))
p++;
- if (!prefixcmp(p, "::")) {
+ if (!prefixcmp(p, "::"))
helper = xstrndup(url, p - url);
- remote->foreign_vcs = helper;
- }
}
if (helper) {
@@ -940,7 +938,6 @@ struct transport *transport_get(struct remote *remote, const char *url)
char *handler = xmalloc(len + 1);
handler[len] = 0;
strncpy(handler, url, len);
- remote->foreign_vcs = handler;
transport_helper_init(ret, handler);
}
--
1.7.8.36.g69ee2
^ permalink raw reply related
* Re: [Q] Determing if a commit is reachable from the HEAD ?
From: Brian Foster @ 2012-01-24 8:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git mailing list, Sitaram Chamarty
In-Reply-To: <7vk44i9z99.fsf@alter.siamese.dyndns.org>
On Monday 23 January 2012 17:09:38 Junio C Hamano wrote:
> Brian Foster <brian.foster@maxim-ic.com> writes:
> > I am probably misunderstanding ‘--quiet’, which the
> > man page cryptically describes as “... allow the
> > caller to test the exit status to see if a range
> > of objects is fully connected (or not).” What is
> > meant here by “fully connected” ?
>
> If the real history looks like this:
>
> ---Y---x---HEAD
>
> i.e. the commit at HEAD says "parent x" in it, and your [repository]
> lacks "x" for whatever reason, Y..HEAD is not fully connected.
Ah, Ok. Thanks! Then YES, I misunderstood ‘--quiet’.
The man page caused me to think it was functionally
equivalent to ‘git rev-list STUFF >/dev/null’.
cheers!
-blf-
--
Brian Foster
Principal MTS, Software | La Ciotat, France
Maxim Integrated Products | Web: http://www.maxim-ic.com/
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2012, #05; Mon, 23)
From: Michael Haggerty @ 2012-01-24 8:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmx9d6hpw.fsf@alter.siamese.dyndns.org>
On 01/24/2012 01:56 AM, Junio C Hamano wrote:
> Here are the topics that have been cooking. [...]
> * mh/ref-api-rest (2011-12-12) 35 commits
> . [...]
>
> I had to remove this temporarily out of 'pu' as I didn't want to deal with
> merge conflicts with the mh/ref-clone-without-extra-refs topic that
> removes yet another caller of add_extra_ref() that this series touches.
Yes, I agree; the branch can be put on ice. After I find the time to
remove the last user of extra_refs, I plan to rework the branch with no
support for extra_refs at all.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [Q] Determing if a commit is reachable from the HEAD ?
From: Brian Foster @ 2012-01-24 8:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git mailing list, Sitaram Chamarty
In-Reply-To: <7vk44i9z99.fsf@alter.siamese.dyndns.org>
On Monday 23 January 2012 17:09:38 Junio C Hamano wrote:
> Brian Foster <brian.foster@maxim-ic.com> writes:
> > I am probably misunderstanding ‘--quiet’, which the
> > man page cryptically describes as “... allow the
> > caller to test the exit status to see if a range
> > of objects is fully connected (or not).” What is
> > meant here by “fully connected” ?
>
> If the real history looks like this:
>
> ---Y---x---HEAD
>
> i.e. the commit at HEAD says "parent x" in it, and your lacks "x"
> for whatever reason, Y..HEAD is not fully connected.
Junio, and my _what_ lacks "x"? Sorry, it looks like
you typo'ed, but I cannot decipher what you meant.
cheers!
-blf-
--
Brian Foster
Principal MTS, Software | La Ciotat, France
Maxim Integrated Products | Web: http://www.maxim-ic.com/
^ permalink raw reply
* Re: [PATCH v3 06/10] clone: delay cloning until after remote HEAD checking
From: Nguyen Thai Ngoc Duy @ 2012-01-24 7:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King
In-Reply-To: <7vvco253xx.fsf@alter.siamese.dyndns.org>
2012/1/24 Junio C Hamano <gitster@pobox.com>:
> Recently, 6f48d39 (clone: delay cloning until after remote HEAD checking,
> 2012-01-16) tried to record if a remote helper needs to be called after
> parsing the remote when transport_get() is called, by overwriting the
> field meant to store the configured remote helper name in the remote
> structure.
>
> This is OK when a remote represents a single remote repository, but fails
> miserably when pushing to locations with multiple URLs, like this:
>
> $ cat .git/config
> [remote "origin"]
> url = https://code.google.com/p/git-htmldocs/
> url = github.com:gitster/git-htmldocs.git
> push = refs/heads/master:refs/heads/master
My bad. remote.*.vcs (or remote->foreign_vcs) is designed to override
remote helper detection based on url. Once you have pushed over https,
the following urls will be over https too. Luckily no other places
perform an operation over multiple urls like push so we're safe with
your bandage.
We should have another way to detect whether remote helper being used
(comparing some function pointers like transport->connect or
transport->disconnect may help). But I need to think a bit about
delaying cloning for http(s) too even though remote helper is used.
--
Duy
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox