* [PATCH 1/3] fetch: free all the additional refspecs
From: Carlos Martín Nieto @ 2011-10-06 21:21 UTC (permalink / raw)
To: git; +Cc: Jeff King, Junio C Hamano, mathstuf
In-Reply-To: <1317936107-1230-1-git-send-email-cmn@elego.de>
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
---
builtin/fetch.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 7a4e41c..30b485e 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -883,7 +883,7 @@ static int fetch_one(struct remote *remote, int argc, const char **argv)
atexit(unlock_pack);
refspec = parse_fetch_refspec(ref_nr, refs);
exit_code = do_fetch(transport, refspec, ref_nr);
- free(refspec);
+ free_refspec(ref_nr, refspec);
transport_disconnect(transport);
transport = NULL;
return exit_code;
--
1.7.5.2.354.g349bf
^ permalink raw reply related
* [PATCH 2/3] fetch: honor the user-provided refspecs when pruning refs
From: Carlos Martín Nieto @ 2011-10-06 21:21 UTC (permalink / raw)
To: git; +Cc: Jeff King, Junio C Hamano, mathstuf
In-Reply-To: <1317936107-1230-1-git-send-email-cmn@elego.de>
If the user gave us refspecs on the command line, we should use those
when deciding whether to prune a ref instead of relying on the
refspecs in the config.
Previously, running
git fetch --prune origin refs/heads/master:refs/remotes/origin/master
would delete every other tag under the origin namespace because we
were using the refspec to filter the available refs but using the
configured refspec to figure out if a ref had been deleted on the
remote. This is clearly the wrong thing to do.
Teach get_stale_heads about user-provided refspecs and use them if
they're available.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
---
builtin/fetch.c | 6 ++--
builtin/remote.c | 2 +-
remote.c | 78 +++++++++++++++++++++++++++++++++++++++++++++++++-----
remote.h | 3 +-
4 files changed, 77 insertions(+), 12 deletions(-)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 30b485e..b937d71 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -505,10 +505,10 @@ static int fetch_refs(struct transport *transport, struct ref *ref_map)
return ret;
}
-static int prune_refs(struct transport *transport, struct ref *ref_map)
+static int prune_refs(struct transport *transport, struct refspec *refs, int n, struct ref *ref_map)
{
int result = 0;
- struct ref *ref, *stale_refs = get_stale_heads(transport->remote, ref_map);
+ struct ref *ref, *stale_refs = get_stale_heads(transport->remote, ref_map, refs, n);
const char *dangling_msg = dry_run
? _(" (%s will become dangling)\n")
: _(" (%s has become dangling)\n");
@@ -700,7 +700,7 @@ static int do_fetch(struct transport *transport,
return 1;
}
if (prune)
- prune_refs(transport, ref_map);
+ prune_refs(transport, refs, ref_count, ref_map);
free_refs(ref_map);
/* if neither --no-tags nor --tags was specified, do automated tag
diff --git a/builtin/remote.c b/builtin/remote.c
index b25dfb4..91a2148 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -349,7 +349,7 @@ static int get_ref_states(const struct ref *remote_refs, struct ref_states *stat
else
string_list_append(&states->tracked, abbrev_branch(ref->name));
}
- stale_refs = get_stale_heads(states->remote, fetch_map);
+ stale_refs = get_stale_heads(states->remote, fetch_map, NULL, 0);
for (ref = stale_refs; ref; ref = ref->next) {
struct string_list_item *item =
string_list_append(&states->stale, abbrev_branch(ref->name));
diff --git a/remote.c b/remote.c
index 7840d2f..28f7917 100644
--- a/remote.c
+++ b/remote.c
@@ -1684,26 +1684,88 @@ struct stale_heads_info {
struct remote *remote;
struct string_list *ref_names;
struct ref **stale_refs_tail;
+ struct refspec *refs;
+ int ref_count;
};
+/*
+ * Find a refspec to a remote's
+ * Returns 0 on success, -1 if it couldn't find a the refspec
+ */
+static int find_in_refs(struct refspec *refs, int ref_count, struct refspec *query)
+{
+ int i;
+ struct refspec *refspec;
+
+ for (i = 0; i < ref_count; ++i) {
+ refspec = &refs[i];
+
+ /* No dst means it can't be used for prunning. */
+ if (!refspec->dst)
+ continue;
+
+ /*
+ * No '*' means that it must match exactly. If it does
+ * have it, try to match it against the pattern. If
+ * the refspec matches, store the ref name as it would
+ * appear in the server in query->src.
+ */
+ if (!strchr(refspec->dst, '*')) {
+ if (!strcmp(query->dst, refspec->dst)) {
+ query->src = xstrdup(refspec->src);
+ return 0;
+ }
+ } else {
+ if (match_name_with_pattern(refspec->dst, query->dst,
+ refspec->src, &query->src)) {
+ return 0;
+ }
+ }
+ }
+
+ return -1;
+}
+
static int get_stale_heads_cb(const char *refname,
const unsigned char *sha1, int flags, void *cb_data)
{
struct stale_heads_info *info = cb_data;
struct refspec refspec;
+ int ret;
memset(&refspec, 0, sizeof(refspec));
refspec.dst = (char *)refname;
- if (!remote_find_tracking(info->remote, &refspec)) {
- if (!((flags & REF_ISSYMREF) ||
- string_list_has_string(info->ref_names, refspec.src))) {
- struct ref *ref = make_linked_ref(refname, &info->stale_refs_tail);
- hashcpy(ref->new_sha1, sha1);
- }
+
+ /*
+ * If the user speicified refspecs on the command line, we
+ * should only use those to check. Otherwise, look in the
+ * remote's configuration for the branch.
+ */
+ if (info->ref_count)
+ ret = find_in_refs(info->refs, info->ref_count, &refspec);
+ else
+ ret = remote_find_tracking(info->remote, &refspec);
+
+ /* No matches */
+ if (ret)
+ return 0;
+
+ /*
+ * If we did find a suitable refspec and it's not a symref and
+ * it's not in the list of refs that currently exist in that
+ * remote we consider it to be stale.
+ */
+ if (!((flags & REF_ISSYMREF) ||
+ string_list_has_string(info->ref_names, refspec.src))) {
+ struct ref *ref = make_linked_ref(refname, &info->stale_refs_tail);
+ hashcpy(ref->new_sha1, sha1);
}
+
+ free(refspec.src);
return 0;
}
-struct ref *get_stale_heads(struct remote *remote, struct ref *fetch_map)
+struct ref *get_stale_heads(struct remote *remote, struct ref *fetch_map,
+ struct refspec *refs, int ref_count)
{
struct ref *ref, *stale_refs = NULL;
struct string_list ref_names = STRING_LIST_INIT_NODUP;
@@ -1711,6 +1773,8 @@ struct ref *get_stale_heads(struct remote *remote, struct ref *fetch_map)
info.remote = remote;
info.ref_names = &ref_names;
info.stale_refs_tail = &stale_refs;
+ info.refs = refs;
+ info.ref_count = ref_count;
for (ref = fetch_map; ref; ref = ref->next)
string_list_append(&ref_names, ref->name);
sort_string_list(&ref_names);
diff --git a/remote.h b/remote.h
index 9a30a9d..2f753a0 100644
--- a/remote.h
+++ b/remote.h
@@ -164,6 +164,7 @@ struct ref *guess_remote_head(const struct ref *head,
int all);
/* Return refs which no longer exist on remote */
-struct ref *get_stale_heads(struct remote *remote, struct ref *fetch_map);
+struct ref *get_stale_heads(struct remote *remote, struct ref *fetch_map,
+ struct refspec *refs, int ref_count);
#endif
--
1.7.5.2.354.g349bf
^ permalink raw reply related
* Re: [PATCH] commit: teach --gpg-sign option
From: Junio C Hamano @ 2011-10-06 21:29 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Shawn Pearce, git
In-Reply-To: <20111006171107.GA10973@elie>
Jonathan Nieder <jrnieder@gmail.com> writes:
>> I like this approach better than the prior "push certificate" idea.
>> The signature information is part of the history graph
>
> I probably missed some earlier discussion (so please forgive me this),
Heh, you are not forgiven when the original message has a clear pointer to
the previous discussion ;-).
> but how is it intended to be used? Would projects
>
> a. require as a matter of policy that all commits be signed
Possible. Personally I would _not_ advise it but they can send in a patch
to add a configuration or two if they do want to run their project that
way.
> b. just sign releases as usual, but as commits in the history graph
> instead of tags
This is not meant to replace tags that is attached after the fact. If
anything...
> c. sign the occasional especially interesting commit
...with the definition of "interesting" being "this is tonight's tip of
branch Linus is pushing out between releases", "I shortly will ask Linus
to pull from the history leading up to this commit", etc., this is the
primary scenario I personally envision the feature would be used in.
Without having to have "nightly" signed tags that clutter the tag
namespace, we can gain more confidence in the integrity of the history
between officially tagged release points that may be a few months apart,
depending on projects.
> ... How
> does this relate to the "push certificate" use case, which seemed to
> be mostly about authenticating published branch tips with signatures
> that are not necessarily important in the long term?
To the upstream project whose participants are signing its history, these
publish points may not be important in the longer term, but for downstream
consumers that have to fork from an in-between point for the next embedded
device release track, it serves the same purpose as push certificates and
is equally important: it allows them to limit the length of near-tip
history that might have been tampered that needs to be validated. If the
downstream consumers fork only from a signed commit point, they only need
to audit their own history without worrying about imported stuff after
incident like what k.org had recently.
I am also somewhat disturbed by "have to sign when committing, long before
I am confident that this is worth pushing" aspect of this approach, but I
do not think it would be much of an issue in practice.
- If you are only pubishing one independent branch, it is just the matter
of either "commit --amend --gpg-sign" or "commit --allow-empty --gpg-sign"
before you push;
- If you are publishing multiple related branches (e.g. maint, master,
next) like I do, and want to correct a mistake discovered at a lower
branch (e.g. master) after it has been already merged in higher
branches (e.g. next), you have to either amend the tip of the lower
branch and rebuild the higher branches, or queue a fix-up to the tip of
the lower branch and merge the result to the higher branches _anyway_,
before you push.
^ permalink raw reply
* Re: [PATCH WIP 0/3] git log --exclude
From: Nguyen Thai Ngoc Duy @ 2011-10-06 21:47 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Jonathan Nieder
In-Reply-To: <20111006143441.GA21558@sigill.intra.peff.net>
2011/10/7 Jeff King <peff@peff.net>:
> I'm really just a bystander on this topic, and haven't given it too much
> thought. But one stumbling block I see for narrow clone is how narrow
> repositories will interact with object transfer from other repositories.
>
> For example, if I have a narrow git.git that omits Documentation, and I
> do a "git fetch" from a non-narrow repository, then how do we tell the
> non-narrow remote that we don't have blobs in Documentation, and that
> they should not be used as delta bases for any objects that are sent?
Pretty much how shallow cloned repos interacts. In shallow clone we
send depth info. In narrow clone, we send width info, in terms of
(restricted) pathspec. With pathspec (possibly plus exclude rules but
this possibility is getting smaller), I can express "fetch this
directory only", or "fetch this directory, but not this subdirectory
(because I already have it)".
We can prohibit certain use cases at client side just like shallow clone.
> The current protocol relies on certain repository properties on the
> remote end that narrow clone will violate. I don't see a way around that
> without a protocol extension to communicate the narrowness. What will
> that extension look like?
Something like this
http://thread.gmane.org/gmane.comp.version-control.git/155427/focus=155613
--
Duy
^ permalink raw reply
* Re: [PATCH] revert.c: defer writing CHERRY_PICK_HEAD till it is safe to do so
From: Junio C Hamano @ 2011-10-06 21:49 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, nicolas.dichtel, Jeff King
In-Reply-To: <CAG+J_Dx0W0oRL-MkoZSGuOfmUNCqmMRUigmgND_0o7kbKppu1Q@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> For that matter, I don't see how to distinguish "the merge did not
> even start" from "the merge had conflicts" when using
> try_merge_command().
I suspect you figured it out by now (sorry I have been tending other
topics and general project maintenance issues), but in case you haven't,
the exit values from the strategy backends are returned straight back to
the caller. The strategy backends are supposed to exit with 1 when they
left the conflicts, and 2 when they punted and did not touch the index nor
the working tree.
^ permalink raw reply
* Re: [PATCH v2] revert.c: defer writing CHERRY_PICK_HEAD till it is safe to do so
From: Junio C Hamano @ 2011-10-06 21:55 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, nicolas.dichtel, Jeff King
In-Reply-To: <CAG+J_Dw8w9UGBzq4xK+i+QtA4ZuwJ5w1+mPg15mPNcGLuRaXyg@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> On Thu, Oct 6, 2011 at 1:48 PM, Jay Soffian <jaysoffian@gmail.com> wrote:
>> Note that do_recursive_merge() aborts if the merge cannot start, while
>> try_merge_command() returns a non-zero value other than 1.
>
> Maybe you want this on-top:
Good thinking.
commit 4ed15ff067b548011b1eda8b12d46d887c4f056c
Author: Jay Soffian <jaysoffian@gmail.com>
Date: Thu Oct 6 13:58:01 2011 -0400
cherry-pick: do not give irrelevant advice when cherry-pick punted
If a cherry-pick did not even start because the working tree had local
changes that would overlap with the operation, we shouldn't be advising
the users to resolve conflicts nor to conclude it with "git commit".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Thanks. Care to sign-off?
^ permalink raw reply
* Re: Prompt for merge message?
From: Junio C Hamano @ 2011-10-06 22:02 UTC (permalink / raw)
To: Todd A. Jacobs; +Cc: git
In-Reply-To: <6eb7acc7-f4be-4b90-a2fa-a0c91ed9a5a8@t11g2000yqk.googlegroups.com>
"Todd A. Jacobs" <nospam+listmail@codegnome.org> writes:
> I often find myself using "--no-ff -m foo" for merging short-lived
> branches, because the merge commit usually needs to say something
> about having finished a feature rather than referring to a branch that
> will be deleted shortly anyway....
> ... Is there currently a way to get git to prompt for the merge message,
> rather than using the default or requiring the -m flag? If not, isn't
> this a common-enough use case to have that ability added to the merge
> function?
Others commented on the current practices and gave their own useful tips
already, but an additional hint is to name your branch more sensibly, so
that you do not feel it is useless to record it in the history.
As to a real longer-term solution, I wouldn't mind a patch that teaches
"git merge" an "-e" option just like "git commit" has.
$ git commit -m "Finish frotz feature" -e -a
... editor opens with the first line filled already here ...
is something I find myself using fairly often.
Thanks.
[offtopic: It is annoying that my MUA warns me
"nospam+listmail@domain" may be bogus; do you really want to send?
Could you do something about it please?]
^ permalink raw reply
* Re: [PATCH v2] revert.c: defer writing CHERRY_PICK_HEAD till it is safe to do so
From: Jay Soffian @ 2011-10-06 22:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, nicolas.dichtel, Jeff King
In-Reply-To: <7vzkhdyecy.fsf@alter.siamese.dyndns.org>
On Thu, Oct 6, 2011 at 5:55 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jay Soffian <jaysoffian@gmail.com> writes:
>
>> On Thu, Oct 6, 2011 at 1:48 PM, Jay Soffian <jaysoffian@gmail.com> wrote:
>>> Note that do_recursive_merge() aborts if the merge cannot start, while
>>> try_merge_command() returns a non-zero value other than 1.
>>
>> Maybe you want this on-top:
>
> Good thinking.
>
> commit 4ed15ff067b548011b1eda8b12d46d887c4f056c
> Author: Jay Soffian <jaysoffian@gmail.com>
> Date: Thu Oct 6 13:58:01 2011 -0400
>
> cherry-pick: do not give irrelevant advice when cherry-pick punted
>
> If a cherry-pick did not even start because the working tree had local
> changes that would overlap with the operation, we shouldn't be advising
> the users to resolve conflicts nor to conclude it with "git commit".
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
>
> Thanks. Care to sign-off?
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Thank you for making it a proper commit. :-)
j.
^ permalink raw reply
* Re: Prompt for merge message?
From: Shawn Pearce @ 2011-10-06 22:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Todd A. Jacobs, git
In-Reply-To: <7vsjn5ye0x.fsf@alter.siamese.dyndns.org>
On Thu, Oct 6, 2011 at 15:02, Junio C Hamano <gitster@pobox.com> wrote:
> "Todd A. Jacobs" <nospam+listmail@codegnome.org> writes:
>
>> I often find myself using "--no-ff -m foo" for merging short-lived
>> branches, because the merge commit usually needs to say something
>> about having finished a feature rather than referring to a branch that
>> will be deleted shortly anyway....
>> ... Is there currently a way to get git to prompt for the merge message,
>> rather than using the default or requiring the -m flag? If not, isn't
>> this a common-enough use case to have that ability added to the merge
>> function?
>
> Others commented on the current practices and gave their own useful tips
> already, but an additional hint is to name your branch more sensibly, so
> that you do not feel it is useless to record it in the history.
>
> As to a real longer-term solution, I wouldn't mind a patch that teaches
> "git merge" an "-e" option just like "git commit" has.
>
> $ git commit -m "Finish frotz feature" -e -a
> ... editor opens with the first line filled already here ...
>
> is something I find myself using fairly often.
What about adding something like:
if (isatty(0) && isatty(1) && isatty(2)) {
do_interactive_commit();
}
to git merge? I know the reason we don't want to do it all of the time
is because git merge is already used in a lot of scripts. But how many
of those are running with an active terminal on all 3 standard fds
when it runs git merge?
^ permalink raw reply
* Re: 66 patches and counting
From: Martin Fick @ 2011-10-06 22:16 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git
In-Reply-To: <4E8CCC55.9070408@alum.mit.edu>
On Wednesday, October 05, 2011 03:29:57 pm Michael Haggerty
wrote:
> My renovation of refs.c [1] is currently at 66 patches
> and counting. What can I say?: (1) I like to make
> changes in the smallest irreducible steps and (2) there
> is a lot that needed to be done in refs.c.
>
> When I'm done, is it OK to dump a patch series like that
> on the git mailing list? Is it pointless because nobody
> will review them anyway? Is a big pile of changes like
> this welcome in any form? Would it be better to convey
> the changes via git itself (e.g., github) rather than
> via emails?
>
> Michael
>
> [1] hierarchical-refs at git://github.com/mhagger/git.git
Michael,
I downloaded your patch series and tested it on my repos.
Here are some of the timings I saw with your branch as is:
* git clone 2:50m (same)
* full fetch changes (> 1 hour) (bad!)
* git branch (unpacked, ungced) .7s (good!)
* git branch (packed, gced) .18s (~>same)
* git checkout (unpacked, ungced) 10.5s (~>same)
* git checkout (packed, gced) 9.5 (~>same)
* noop fetch changes (unpacked, ungced) 14s (~>same)
* noop fetch changes (packed, gced) 12s (same)
For the full fetch, I estimated, things were scrolling by
slow enough that after about 15 min I interrupted it. I
suspect it might be at least 6 times longer (if rate stayed
the same).
Here are the best timings for all the good patches that
others have submitted to fix many of the previous problems I
brought up:
* git clone 2:50m
* full fetch changes 4:50m
* git branch (unpacked, ungced) 9s
* git branch (packed, gced) .05s
* git checkout (unpacked, ungced) 9s
* git checkout (packed, gced) 8s
* noop fetch changes (unpacked, ungced) 12s
* noop fetch changes (packed, gced) 12s
(my internal patches bring full fetch down to 2:50m)
It would be nice if you could rebase your work on top of
some of the other patches also so that I could see those
results. I might give that a try if I have the time and it
is easy (or I might rebase those patches on yours).
Thanks,
-Martin
--
Employee of Qualcomm Innovation Center, Inc. which is a
member of Code Aurora Forum
^ permalink raw reply
* Re: [PATCH] commit: teach --gpg-sign option
From: Robin H. Johnson @ 2011-10-06 22:24 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <7vaa9f3pk8.fsf@alter.siamese.dyndns.org>
On Wed, Oct 05, 2011 at 05:56:55PM -0700, Junio C Hamano wrote:
> And this uses the gpg-interface.[ch] to allow signing the commit, i.e.
>
> $ git commit --gpg-sign -m foo
> You need a passphrase to unlock the secret key for
> user: "Junio C Hamano <gitster@pobox.com>"
> 4096-bit RSA key, ID 96AFE6CB, created 2011-10-03 (main key ID 713660A7)
>
> [master 8457d13] foo
> 1 files changed, 1 insertions(+), 0 deletions(-)
I like it, but I have a couple of questions:
1. Are the sig lines used in computed SHA1/commitid of a given commit (I
see examples w/ --amend and that would usually change the SHA1)?
2. Can we allow more than one person sign a commit?
3. If I have prepared a series on a local branch, and I want to sign all
of them, is this a variant of rebase or?
I think this isn't a replacement for push certificates, but has value in
itself. It's certainly provides better integration than the
signature-in-note variants.
--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
^ permalink raw reply
* Re: Git Bug report
From: Aaron Schrab @ 2011-10-06 22:57 UTC (permalink / raw)
To: Junio C Hamano
Cc: Phil Hord, SZEDER Gábor, git, Fredrik Gustafsson,
Federico Lucifredi
In-Reply-To: <7vy5wy145q.fsf@alter.siamese.dyndns.org>
At 09:22 -0700 06 Oct 2011, Junio C Hamano <gitster@pobox.com> wrote:
>Yeah, after thinking about it a bit more, whenever we see ".git" during
>the upward discovery process, we should always warn if we know it is _not_
>a GIT_DIR before looking for another ".git" at higher levels, as anything
>in that directory cannot be added. If we cannot tell if it is or is not
>a GIT_DIR, we should error out---the reason we cannot tell most likely is
>because we cannot read it, and such a file, if it is not a GIT_DIR, cannot
>be tracked in the real GIT_DIR at a higher level, and if it is a GIT_DIR,
>we cannot use it to record updates or inspect existing history.
Yes, I think that sounds like a good idea. That should also solve a
related problem that I noticed while checking out the current behaviour.
Currently if the .git directory of a submodule is inaccessible running
`git status` from anywhere in the parent repository (including within
the submodule) will cause git to recursively call itself until enough
resources are used to prevent further forking. I then tried this with
the patch from earlier in the thread applied, but with the call to
error() changed to call die() instead. With that change it quickly
failed with a useful error message.
^ permalink raw reply
* Re: [PATCH 1/3] completion: unite --reuse-message and --reedit-message handling
From: Junio C Hamano @ 2011-10-06 23:14 UTC (permalink / raw)
To: Teemu Matilainen; +Cc: git, Shawn O. Pearce
In-Reply-To: <1317926431-609-1-git-send-email-teemu.matilainen@iki.fi>
All three patches make sense to me. Thanks.
^ permalink raw reply
* Re: Prompt for merge message?
From: Junio C Hamano @ 2011-10-06 23:17 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Todd A. Jacobs, git
In-Reply-To: <CAJo=hJvFytscxyx2z+Fdw9E1DS02wSXgoE3SHkxKq2OYOMQHgQ@mail.gmail.com>
Shawn Pearce <spearce@spearce.org> writes:
> to git merge? I know the reason we don't want to do it all of the time
> is because git merge is already used in a lot of scripts. But how many
> of those are running with an active terminal on all 3 standard fds
> when it runs git merge?
Ninety four?
$ git grep -l 'git merge' -- 't/t[0-9][0-9][0-9][0-9]-*.sh' | wc -l
^ permalink raw reply
* [PATCH] git-svn: Allow certain refs to be ignored
From: Michael Olson @ 2011-10-07 0:41 UTC (permalink / raw)
To: git
Implement a new --ignore-refs option which specifies a regex of refs
to ignore while importing svn history.
This is a useful supplement to the --ignore-paths option, as that
option only operates on the contents of branches and tags, not the
branches and tags themselves.
Signed-off-by: Michael Olson <mwolson@gnu.org>
---
Re-sent by request of Piotr Krukowiecki. This is against v1.7.4.1,
and I've been using it stably for a while.
git-svn.perl | 38 +++++++++++++++++++++++++++++++++-----
1 files changed, 33 insertions(+), 5 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 177dd25..541fa2d 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -90,7 +90,8 @@ $_q ||= 0;
my %remote_opts = ( 'username=s' => \$Git::SVN::Prompt::_username,
'config-dir=s' => \$Git::SVN::Ra::config_dir,
'no-auth-cache' => \$Git::SVN::Prompt::_no_auth_cache,
- 'ignore-paths=s' => \$SVN::Git::Fetcher::_ignore_regex );
+ 'ignore-paths=s' => \$SVN::Git::Fetcher::_ignore_regex,
+ 'ignore-refs=s' => \$Git::SVN::Ra::_ignore_refs_regex );
my %fc_opts = ( 'follow-parent|follow!' => \$Git::SVN::_follow_parent,
'authors-file|A=s' => \$_authors,
'authors-prog=s' => \$_authors_prog,
@@ -380,9 +381,12 @@ sub do_git_init_db {
command_noisy('config', "$pfx.$i", $icv{$i});
$set = $i;
}
- my $ignore_regex = \$SVN::Git::Fetcher::_ignore_regex;
- command_noisy('config', "$pfx.ignore-paths", $$ignore_regex)
- if defined $$ignore_regex;
+ my $ignore_paths_regex = \$SVN::Git::Fetcher::_ignore_regex;
+ command_noisy('config', "$pfx.ignore-paths", $$ignore_paths_regex)
+ if defined $$ignore_paths_regex;
+ my $ignore_refs_regex = \$Git::SVN::Ra::_ignore_refs_regex;
+ command_noisy('config', "$pfx.ignore-refs", $$ignore_refs_regex)
+ if defined $$ignore_refs_regex;
}
sub init_subdir {
@@ -1831,6 +1835,8 @@ sub read_all_remotes {
$r->{$1}->{svm} = {};
} elsif (m!^(.+)\.url=\s*(.*)\s*$!) {
$r->{$1}->{url} = $2;
+ } elsif (m!^(.+)\.ignore-refs=\s*(.*)\s*$!) {
+ $r->{$1}->{ignore_refs_regex} = $2;
} elsif (m!^(.+)\.(branches|tags)=$svn_refspec$!) {
my ($remote, $t, $local_ref, $remote_ref) =
($1, $2, $3, $4);
@@ -1867,6 +1873,16 @@ sub read_all_remotes {
}
} keys %$r;
+ foreach my $remote (keys %$r) {
+ foreach ( grep { defined $_ }
+ map { $r->{$remote}->{$_} } qw(branches tags) ) {
+ foreach my $rs ( @$_ ) {
+ $rs->{ignore_refs_regex} =
+ $r->{$remote}->{ignore_refs_regex};
+ }
+ }
+ }
+
$r;
}
@@ -4876,7 +4892,7 @@ sub apply_diff {
}
package Git::SVN::Ra;
-use vars qw/@ISA $config_dir $_log_window_size/;
+use vars qw/@ISA $config_dir $_ignore_refs_regex $_log_window_size/;
use strict;
use warnings;
my ($ra_invalid, $can_do_switch, %ignored_err, $RA);
@@ -5334,6 +5350,17 @@ sub get_dir_globbed {
@finalents;
}
+# return value: 0 -- don't ignore, 1 -- ignore
+sub is_ref_ignored {
+ my ($g, $p) = @_;
+ my $refname = $g->{ref}->full_path($p);
+ return 1 if defined($g->{ignore_refs_regex}) &&
+ $refname =~ m!$g->{ignore_refs_regex}!;
+ return 0 unless defined($_ignore_refs_regex);
+ return 1 if $refname =~ m!$_ignore_refs_regex!o;
+ return 0;
+}
+
sub match_globs {
my ($self, $exists, $paths, $globs, $r) = @_;
@@ -5370,6 +5397,7 @@ sub match_globs {
next unless /$g->{path}->{regex}/;
my $p = $1;
my $pathname = $g->{path}->full_path($p);
+ next if is_ref_ignored($g, $p);
next if $exists->{$pathname};
next if ($self->check_path($pathname, $r) !=
$SVN::Node::dir);
--
1.7.4.1
^ permalink raw reply related
* Re: git-svn: ignore-paths not enough (not ignoring refs?)
From: Michael Olson @ 2011-10-07 0:41 UTC (permalink / raw)
To: Piotr Krukowiecki; +Cc: Eric Wong, Git Mailing List
In-Reply-To: <CAA01CsqEdoqSRrPDTrfOQPS7q-1tVALE_5vjeLUAeh0iXZi3_A@mail.gmail.com>
I've resent my patch. I've been using it with v1.7.4.1.
On Thu, Oct 6, 2011 at 1:43 AM, Piotr Krukowiecki
<piotr.krukowiecki@gmail.com> wrote:
> Hi,
>
> I'm using --ignore-paths options but some paths which should be
> ignored (they math the regexp) are not ignored. I suspect this is
> because of http://thread.gmane.org/gmane.comp.version-control.git/145398
>
> It seems the patch from that url was never accepted to git. It does
> not apply anymore too. Is it possible to update the patch? From the
> discussion the patch looked ok (with exception to git-svn dying if a
> parent ref didn't exist :) )
>
>
> Here's my git-svn clone log, with some print lines added to is_path_ignored():
>
> $ git svn clone -s --no-follow-parent --ignore-paths='$REGEXP -r 1230:1240 $URL
> [...]
> is_path_ignored: 'xtest/tags/rel1' # this matches the regexp and
> should be ignored
> is_path_ignored: 'xtest/tags/rel1/common' # more paths which should be
> ignored follow
> [...]
> r1237 = c660a7e6ad81cafa0a64a7ec85a3e23f0c02bc09
> (refs/remotes/tags/rel1) # but it is not!
>
> # I can see the tag:
> $ git branch -a
> remotes/tags/rel1
>
> # There are no changes in this change:
> $ git show -p c660a7e6ad81cafa0a64a7ec85a3e23f0c02bc09
> [...]
> git-svn-id: $URL/rel1@1237 3e523551-a86b-4873-bcb6-76fcd93a4c5c
>
> # Under svn the r1237 is following:
> $ svn log -r 1237 -v $URL
> ------------------------------------------------------------------------
> r1237 | ...
> Changed paths:
> A /xtest/tags/rel1/common (from /xtest/branches/xtest44/common:1235)
>
> # The xtest/branches/xtest44/common does not match the ignore-paths
> and is not ignored.
>
>
> --
> Piotr Krukowiecki
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Michael Olson | http://mwolson.org/
^ permalink raw reply
* Fix another file leak
From: Chris Wilson @ 2011-10-07 1:41 UTC (permalink / raw)
To: git
Hi,
Vigilant Sentry (our C/C++ static analysis tool) found that
commit 6d4bb383, added a file leak to builtin/fetch.c.
static int store_updated_refs(...
{
FILE *fp;
...
fp = fopen(filename, "a");
if (!fp)
return error(_("cannot open %s: %s\n"), filename, strerror(errno));
....
if (check_everything_connected(iterate_ref_map, 0, &rm))
return error(_("%s did not send all necessary objects\n"), url);
Please close the file handle before returning from the function.
Thanks,
Chris
--
Chris Wilson
http://vigilantsw.com/
Vigilant Software, LLC
^ permalink raw reply
* Re: [RFC/PATCH]: reverse bisect v 2.0
From: Andrew Ardill @ 2011-10-07 1:57 UTC (permalink / raw)
To: Junio C Hamano
Cc: Christian Couder, Jeff King, Michal Vyskocil, git,
Sverre Rabbelier, Johannes Sixt
In-Reply-To: <7v62k4ban7.fsf@alter.siamese.dyndns.org>
Hi, I have given this some thought and have a slightly different
proposal for the options to use. I have written a commit message that
I think explains the need for the improvement, and justifies my
proposal. The options I propose are '--intoduced' and '--removed'.
--->8---
Bisect is used to look for a commit that causes a specific change.
Such a change can be classified by the user as either introducing
something, or removing something, and this distinction is arbitrary. A
change could be said to introduce a bug fix, or remove a bug - both
formulations have inherently the same meaning, but search behaviour
changes depending on which one we use.
Suppose I want to find the commit that removed a bug. If I examine a
snapshot and it contains the bug, the bug has not yet been *removed*
and I must look in the future for its removal. Conversely, if I
examine a snapshot and the bug fix exists, the bug fix must have been
*introduced* at some earlier point and so I must search backwards.
Confusion exists at this point because at each verification step a
question like 'Does this snapshot have X?' is asked, when what we
eventually want to know is 'When was X introduced?' or 'When was X
removed?'. Previously there has been no way to specify if we are
looking for X being introduced or removed; it was assumed that we were
looking for when something was introduced, for example when a bug was
introduced.
Teach git bisect if we are looking for when something was introduced
or when something was removed.
Examples.
Search for a feature add:
$ git bisect start --introduced='feature: git frotz says xyzzy' v0.99 master
Bisecting: 171 revisions left to test after this (roughly 8 steps)
$ ... build and then test ...
$ git bisect tested
Does this snapshot have 'feature: git frotz says xyzzy' [y/n]? yes
# already added, look backwards
Search for a feature regression:
$ git bisect start --removed='feature: git frotz says xyzzy' v0.99 master
Bisecting: 171 revisions left to test after this (roughly 8 steps)
$ ... build and then test ...
$ git bisect tested
Does this snapshot have 'feature: git frotz says xyzzy' [y/n]? yes
# not removed yet, look forwards
--->8---
Regards,
Andrew Ardill
^ permalink raw reply
* Re: 66 patches and counting
From: Martin Fick @ 2011-10-07 1:59 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git
In-Reply-To: <201110061616.39381.mfick@codeaurora.org>
On Thursday, October 06, 2011 04:16:39 pm Martin Fick wrote:
> On Wednesday, October 05, 2011 03:29:57 pm Michael
> Haggerty
> > [1] hierarchical-refs at
> > git://github.com/mhagger/git.git
>
> I downloaded your patch series and tested it on my repos.
>
> * full fetch changes (> 1 hour) (bad!)
I bisected this problem, it was introduced in this commit:
commit e12ce45b4f1bd8ed6652a742b7e6cf6f101b3604
Author: Michael Haggerty <mhagger@alum.mit.edu>
Date: Wed Oct 5 11:30:06 2011 +0200
Store references hierarchically
This slightly changes the order of iteration over
references; now
references are strictly sorted componentwise rather than
as
"/"-containing strings as before. For example,
"subspace/one" now
sorts before "subspace-x", whereas before the order was
reversed.
Tweak a test case to accept the new ordering.
Up until that point, the fetch looks pretty good,
-Martin
--
Employee of Qualcomm Innovation Center, Inc. which is a
member of Code Aurora Forum
^ permalink raw reply
* Re: Prompt for merge message?
From: Todd A. Jacobs @ 2011-10-07 1:15 UTC (permalink / raw)
To: git
In-Reply-To: <7vsjn5ye0x.fsf@alter.siamese.dyndns.org>
On Oct 6, 6:02 pm, Junio C Hamano <gits...@pobox.com> wrote:
> Others commented on the current practices and gave their own useful tips
> already, but an additional hint is to name your branch more sensibly, so
> that you do not feel it is useless to record it in the history.
While I can see your point of view, I don't think that it fits every
work-flow. In particular, if you want to maintain a linear history on
the master branch but record the completion of a feature as a commit
object separate from the last patch in a series, you have two choices
at the moment:
1. A fast-forward merge, followed by an empty commit with --allow-
empty. However, the empty commit seems to get discarded on merges, or
finds other ways to disappear outside of the feature branch on which
it was created. It probably isn't a bug, but it can be very surprising
to create an empty commit object on a feature branch, and then have it
disappear when you merge to master.
2. A merge commit with an explicit merge message, which is what we've
been talking about in this thread.
The point of the exercise is (mostly) to integrate with issue trackers
like Pivotal or GitHub, where a commit with certain keywords can
integrate with ticket history. But, IMHO, it doesn't necessarily make
sense that any given patch closes a ticket; sometimes they do, but
sometimes I really prefer a standalone commit to essentially say "and
now the ticket is really, really done."
The fact that there have been so many useful suggestions about how to
work around this issue seems to imply that it isn't a low bus-factor
issue. My personal vote is for your suggestion of an [-e|--edit] flag
for the merge; that would make it (mostly) consistent with commit's
behavior. I can certainly see that in the common case the default
merge message is the right thing to do, but I really do feel that
there ought to be *some* flag to allow a visual editor to edit the
merge message without having to amend the merge commit or merge
without a commit just so that the next commit will invoke the editor.
Ultimately, I guess what I'm really agitating for is just an editor
option for merge commits. If you take work-flow out of the equation,
isn't there still a case for easily-editable merge messages?
^ permalink raw reply
* Re: Prompt for merge message?
From: Junio C Hamano @ 2011-10-07 3:07 UTC (permalink / raw)
To: Todd A. Jacobs; +Cc: git
In-Reply-To: <403e37d1-bdd3-46fc-9a9a-e8aab3a2d3ba@f6g2000vbm.googlegroups.com>
"Todd A. Jacobs" <nospam+listmail@codegnome.org> writes:
> On Oct 6, 6:02 pm, Junio C Hamano <gits...@pobox.com> wrote:
>> Others commented on the current practices and gave their own useful tips
>> already, but an additional hint is to name your branch more sensibly, so
>> that you do not feel it is useless to record it in the history.
> ...
> Ultimately, I guess what I'm really agitating for is just an editor
> option for merge commits. If you take work-flow out of the equation,
> isn't there still a case for easily-editable merge messages?
I do not see any reason for you to be agitated. All you need to do is to
read beyond what you chose to quote from my message, read that part before
omitting from your quote ;-).
^ permalink raw reply
* Re: 66 patches and counting
From: Michael Haggerty @ 2011-10-07 3:14 UTC (permalink / raw)
To: Martin Fick; +Cc: git
In-Reply-To: <201110061616.39381.mfick@codeaurora.org>
[-- Attachment #1: Type: text/plain, Size: 2236 bytes --]
On 10/07/2011 12:16 AM, Martin Fick wrote:
> I downloaded your patch series and tested it on my repos.
Very cool (though a bit premature, as you discovered). The patch series
still has a known performance regression in the area of
do_for_each_ref(), which I hope to figure out soon. I will definitely
tell you when I think that the patch series is ready for more serious
testing (hopefully today) in the hopes that you can benchmark it against
your repo.
In the future, please tell me the SHA1 of any versions that you test, as
I am still frequently non-ff updating the hierarchical-refs branch.
> Here are the best timings for all the good patches that
> others have submitted to fix many of the previous problems I
> brought up:
What are, in your measurements, the "good patches" that you consider
contenders performance-wise? (I've lost track because there have been
so many suggestions in this area.)
It would be great if you would serve as a kind of benchmarking
referee/clearinghouse for the various suggested patches. I have been
benchmarking with some rough scripts that I wrote [1]; the current
status is appended below (the numbers are clock times in seconds). FWIW
the attached output was generated using roughly the following commands:
t/make-refperf-repo --refs=10000 --commits=20000
cp t/refperf-many .
# Adjust REFPERF_BRANCH in ./refperf-many:
$EDITOR ./refperf-many
revs="v1.7.6 v1.7.7 origin/master origin/hierarchical-refs^^
origin/hierarchical-refs^ origin/hierarchical-refs origin/master"
./refperf-many $revs
t/refperf-summary $revs >refperf-summary.out
See the comments at the top of the scripts for more details. Please
suggest more tests to be added to t/refperf!
> It would be nice if you could rebase your work on top of
> some of the other patches also so that I could see those
> results. I might give that a try if I have the time and it
> is easy (or I might rebase those patches on yours).
I believe that at least some of the other patches will be superseded by
mine. When I get my patch series done I will look into it in more detail...
Michael
[1] Branch "refperf" at git://github.com/mhagger/git.git
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
[-- Attachment #2: refperf-summary.out --]
[-- Type: text/plain, Size: 3535 bytes --]
=================================== ======= ======= ======= ======= ======= =======
Test name [0] [1] [2] [3] [4] [5]
=================================== ======= ======= ======= ======= ======= =======
branch-loose-cold 5.84 5.38 6.05 0.53 0.47 0.56
branch-loose-warm 0.12 0.11 0.13 0.00 0.02 0.03
for-each-ref-loose-cold 6.83 6.45 6.13 8.21 8.69 8.28
for-each-ref-loose-warm 0.25 0.25 0.25 0.84 0.84 0.84
checkout-loose-cold 4.55 5.08 5.76 0.73 0.60 0.68
checkout-loose-warm 0.11 0.11 0.12 0.03 0.02 0.04
checkout-orphan-loose 0.10 0.10 0.11 0.01 0.02 0.01
checkout-from-detached-loose 0.97 1.05 0.95 7.80 8.27 8.37
branch-contains-loose-cold 14.98 15.44 18.54 16.46 16.91 17.54
branch-contains-loose-warm 9.44 8.97 10.15 9.60 9.58 9.71
pack-refs-loose 0.97 1.00 1.37 1.69 1.62 1.65
branch-packed-cold 0.49 0.63 0.81 1.38 1.37 1.45
branch-packed-warm 0.02 0.02 0.05 0.77 0.74 0.80
for-each-ref-packed-cold 1.18 0.97 1.56 1.33 2.03 1.51
for-each-ref-packed-warm 0.15 0.15 0.16 0.52 0.52 0.50
checkout-packed-cold 0.84 0.60 0.70 0.96 0.94 1.28
checkout-packed-warm 0.02 0.09 0.04 0.41 0.41 0.44
checkout-orphan-packed 0.01 0.02 0.10 0.38 0.39 0.42
checkout-from-detached-packed 6.94 7.35 9.18 1.31 1.35 1.45
branch-contains-packed-cold 11.19 10.81 12.35 10.91 10.09 10.16
branch-contains-packed-warm 10.24 9.90 11.19 9.13 9.07 9.13
clone-loose-cold 93.77 90.65 98.07 99.03 103.72 101.85
clone-loose-warm 3.12 3.19 3.24 3.56 3.60 3.50
fetch-nothing-loose 0.85 0.84 0.87 1.20 1.18 1.21
pack-refs 0.12 0.13 0.14 0.51 0.54 0.51
fetch-nothing-packed 0.85 0.84 0.86 1.20 1.19 1.20
clone-packed-cold 2.17 2.38 2.50 2.28 2.46 2.34
clone-packed-warm 0.32 0.34 0.39 0.40 0.38 0.30
fetch-everything-cold 92.37 95.96 102.20 100.80 104.72 106.85
fetch-everything-warm 5.55 5.65 5.53 6.26 6.27 6.35
=================================== ======= ======= ======= ======= ======= =======
[0] v1.7.6 (refperf.times.d78c84e8698e750139667bc724b08eb34e795b65)
[1] v1.7.7 (refperf.times.a258e475eb74e183e9e68ca30e32c5253081356d)
[2] origin/master (refperf.times.27897d25f1b36d400b82b655701b87fd205dbc2f)
[3] origin/hierarchical-refs^^ (refperf.times.eabcf1ed884d95878f12ca5ea32a3e20c70194f2)
[4] origin/hierarchical-refs^ (refperf.times.be9118234275c4fa6002ef97d989b0d28c94c0bd)
[5] origin/hierarchical-refs (refperf.times.74d1ae38f70f4f97745caf235ef3f34b3e326ad4)
^ permalink raw reply
* [PATCH] fetch: plug two leaks on error exit in store_updated_refs
From: René Scharfe @ 2011-10-07 6:13 UTC (permalink / raw)
To: Chris Wilson; +Cc: git, Junio C Hamano
In-Reply-To: <20111007014136.GB10839@localhost>
Close FETCH_HEAD and release the string url even if we have to leave the
function store_updated_refs() early.
Reported-by: Chris Wilson <cwilson@vigilantsw.com>
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
builtin/fetch.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 7a4e41c..79db796 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -379,8 +379,12 @@ static int store_updated_refs(const char *raw_url, const char *remote_name,
url = xstrdup("foreign");
rm = ref_map;
- if (check_everything_connected(iterate_ref_map, 0, &rm))
- return error(_("%s did not send all necessary objects\n"), url);
+ if (check_everything_connected(iterate_ref_map, 0, &rm)) {
+ error(_("%s did not send all necessary objects\n"), url);
+ free(url);
+ fclose(fp);
+ return -1;
+ }
for (rm = ref_map; rm; rm = rm->next) {
struct ref *ref = NULL;
--
1.7.7
^ permalink raw reply related
* Re: Pull --rebase looses merge information
From: Philippe Vaucher @ 2011-10-07 6:46 UTC (permalink / raw)
To: in-gitvger; +Cc: Duane Murphy, git
In-Reply-To: <201110062031.p96KVvsv018248@no.baka.org>
> I personally believe all pull should be --rebase, all merges should be
> --no-ff, and all rebases should be -p. At least by default. But that
> is just me.
+1
Philippe
^ permalink raw reply
* Re: [PATCH] fetch: plug two leaks on error exit in store_updated_refs
From: Tay Ray Chuan @ 2011-10-07 6:49 UTC (permalink / raw)
To: René Scharfe; +Cc: Chris Wilson, git, Junio C Hamano
In-Reply-To: <4E8E98A7.8010008@lsrfire.ath.cx>
On Fri, Oct 7, 2011 at 2:13 PM, René Scharfe
<rene.scharfe@lsrfire.ath.cx> wrote:
> diff --git a/builtin/fetch.c b/builtin/fetch.c
> index 7a4e41c..79db796 100644
> --- a/builtin/fetch.c
> +++ b/builtin/fetch.c
> @@ -379,8 +379,12 @@ static int store_updated_refs(const char *raw_url, const char *remote_name,
> url = xstrdup("foreign");
>
> rm = ref_map;
> - if (check_everything_connected(iterate_ref_map, 0, &rm))
> - return error(_("%s did not send all necessary objects\n"), url);
> + if (check_everything_connected(iterate_ref_map, 0, &rm)) {
> + error(_("%s did not send all necessary objects\n"), url);
> + free(url);
> + fclose(fp);
> + return -1;
> + }
>
> for (rm = ref_map; rm; rm = rm->next) {
> struct ref *ref = NULL;
> --
> 1.7.7
How about reusing the function's cleanup calls, like this?
-- >8 --
diff --git a/builtin/fetch.c b/builtin/fetch.c
index fc254b6..56267c4 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -423,8 +423,10 @@ static int store_updated_refs(const char
*raw_url, const char *remote_name,
else
url = xstrdup("foreign");
- if (check_everything_connected(ref_map, 0))
- return error(_("%s did not send all necessary objects\n"), url);
+ if (check_everything_connected(ref_map, 0)) {
+ rc = error(_("%s did not send all necessary objects\n"), url);
+ goto abort;
+ }
for (rm = ref_map; rm; rm = rm->next) {
struct ref *ref = NULL;
@@ -506,12 +508,15 @@ static int store_updated_refs(const char
*raw_url, const char *remote_name,
fprintf(stderr, " %s\n", note);
}
}
- free(url);
- fclose(fp);
+
if (rc & STORE_REF_ERROR_DF_CONFLICT)
error(_("some local refs could not be updated; try running\n"
" 'git remote prune %s' to remove any old, conflicting "
"branches"), remote_name);
+
+abort:
+ free(url);
+ fclose(fp);
return rc;
}
--
--
Cheers,
Ray Chuan
^ permalink raw reply related
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