* Re: git-checkout silently throws away the dirty status of index without a warning?
From: Andrew Ardill @ 2011-09-02 1:52 UTC (permalink / raw)
To: Tzu-Jung Lee; +Cc: Junio C Hamano, git
In-Reply-To: <CAEvN+1hA1mUjDc0cQidEBOf5LhJ9LrVbTjyV5qPkUKNM6f7urQ@mail.gmail.com>
> I accidentally switch to the switched-to branch without committing the
> intermediate status.
> The 'work' was gone, and I had no idea how to bring it back.
Forgive me if I am missing something here, but can't you use reflog to
go back to the point just before you checked the switched-to branch
out?
I guess the question is in general, how do you revert to a previous
instance of the working index AND previous checked out branch? I don't
know the 'switch branch with modified working index' mapping well
enough to be able to determine if there is a bijection possible, a
concise description of it would probably show us. If not, the only way
to achieve this is to keep the history available.
Regards,
Andrew Ardill
^ permalink raw reply
* [PATCHv2 2/2] remote: "rename o foo" should not rename ref "origin/bar"
From: Martin von Zweigbergk @ 2011-09-02 0:50 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King, Martin von Zweigbergk
In-Reply-To: <1314924634-12235-1-git-send-email-martin.von.zweigbergk@gmail.com>
When renaming a remote called 'o' using 'git remote rename o foo', git
should also rename any remote-tracking branches for the remote. This
does happen, but any remote-tracking branches starting with
'refs/remotes/o', such as 'refs/remotes/origin/bar', will also be
renamed (to 'refs/remotes/foorigin/bar' in this case).
Fix it by simply matching one more character, up to the slash
following the remote name.
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
---
No changes since v1.
builtin/remote.c | 2 +-
t/t5505-remote.sh | 10 ++++++++++
2 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/builtin/remote.c b/builtin/remote.c
index 6d08738..0df6ab0 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -570,7 +570,7 @@ static int read_remote_branches(const char *refname,
unsigned char orig_sha1[20];
const char *symref;
- strbuf_addf(&buf, "refs/remotes/%s", rename->old);
+ strbuf_addf(&buf, "refs/remotes/%s/", rename->old);
if (!prefixcmp(refname, buf.buf)) {
item = string_list_append(rename->remote_branches, xstrdup(refname));
symref = resolve_ref(refname, orig_sha1, 1, &flag);
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index 36c807c..15186c8 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -651,6 +651,16 @@ test_expect_success 'rename a remote with name part of fetch spec' '
'
+test_expect_success 'rename a remote with name prefix of other remote' '
+
+ git clone one four.three &&
+ (cd four.three &&
+ git remote add o git://example.com/repo.git &&
+ git remote rename o upstream &&
+ test "$(git rev-parse origin/master)" = "$(git rev-parse master)")
+
+'
+
cat > remotes_origin << EOF
URL: $(pwd)/one
Push: refs/heads/master:refs/heads/upstream
--
1.7.6.51.g07e0e
^ permalink raw reply related
* [PATCHv2 1/2] remote: write correct fetch spec when renaming remote 'remote'
From: Martin von Zweigbergk @ 2011-09-02 0:50 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King, Martin von Zweigbergk
When renaming a remote whose name is contained in a configured fetch
refspec for that remote, we currently replace the first occurrence of
the remote name in the refspec. This is correct in most cases, but
breaks if the remote name occurs in the fetch refspec before the
expected place. For example, we currently change
[remote "remote"]
url = git://git.kernel.org/pub/scm/git/git.git
fetch = +refs/heads/*:refs/remotes/remote/*
into
[remote "origin"]
url = git://git.kernel.org/pub/scm/git/git.git
fetch = +refs/heads/*:refs/origins/remote/*
Reduce the risk of changing incorrect sections of the refspec by
matching the entire ":refs/remotes/<name>/" instead of just "<name>".
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
---
Now matches more strictly, namely on ":/refs/remotes/$OLD/".
builtin/remote.c | 12 ++++++++----
t/t5505-remote.sh | 20 ++++++++++++++++++++
2 files changed, 28 insertions(+), 4 deletions(-)
diff --git a/builtin/remote.c b/builtin/remote.c
index f2a9c26..6d08738 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -621,7 +621,8 @@ static int mv(int argc, const char **argv)
OPT_END()
};
struct remote *oldremote, *newremote;
- struct strbuf buf = STRBUF_INIT, buf2 = STRBUF_INIT, buf3 = STRBUF_INIT;
+ struct strbuf buf = STRBUF_INIT, buf2 = STRBUF_INIT, buf3 = STRBUF_INIT,
+ old_remote_context = STRBUF_INIT;
struct string_list remote_branches = STRING_LIST_INIT_NODUP;
struct rename_info rename;
int i;
@@ -659,15 +660,18 @@ static int mv(int argc, const char **argv)
strbuf_addf(&buf, "remote.%s.fetch", rename.new);
if (git_config_set_multivar(buf.buf, NULL, NULL, 1))
return error("Could not remove config section '%s'", buf.buf);
+ strbuf_addf(&old_remote_context, ":refs/remotes/%s/", rename.old);
for (i = 0; i < oldremote->fetch_refspec_nr; i++) {
char *ptr;
strbuf_reset(&buf2);
strbuf_addstr(&buf2, oldremote->fetch_refspec[i]);
- ptr = strstr(buf2.buf, rename.old);
+ ptr = strstr(buf2.buf, old_remote_context.buf);
if (ptr)
- strbuf_splice(&buf2, ptr-buf2.buf, strlen(rename.old),
- rename.new, strlen(rename.new));
+ strbuf_splice(&buf2,
+ ptr-buf2.buf + strlen(":refs/remotes/"),
+ strlen(rename.old), rename.new,
+ strlen(rename.new));
if (git_config_set_multivar(buf.buf, buf2.buf, "^$", 0))
return error("Could not append '%s'", buf.buf);
}
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index 0d0222e..36c807c 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -631,6 +631,26 @@ test_expect_success 'rename a remote' '
'
+test_expect_success 'rename does not update a non-default fetch refspec' '
+
+ git clone one four.one &&
+ (cd four.one &&
+ git config remote.origin.fetch +refs/heads/*:refs/heads/origin/* &&
+ git remote rename origin upstream &&
+ test "$(git config remote.upstream.fetch)" = "+refs/heads/*:refs/heads/origin/*")
+
+'
+
+test_expect_success 'rename a remote with name part of fetch spec' '
+
+ git clone one four.two &&
+ (cd four.two &&
+ git remote rename origin remote &&
+ git remote rename remote upstream &&
+ test "$(git config remote.upstream.fetch)" = "+refs/heads/*:refs/remotes/upstream/*")
+
+'
+
cat > remotes_origin << EOF
URL: $(pwd)/one
Push: refs/heads/master:refs/heads/upstream
--
1.7.6.51.g07e0e
^ permalink raw reply related
* Re: [PATCH 2/2] remote: "rename o foo" should not rename ref "origin/bar"
From: Martin von Zweigbergk @ 2011-09-02 0:35 UTC (permalink / raw)
To: Jeff King; +Cc: Martin von Zweigbergk, git, Junio C Hamano
In-Reply-To: <20110901024617.GD31838@sigill.intra.peff.net>
On Wed, 31 Aug 2011, Jeff King wrote:
> On Wed, Aug 31, 2011 at 09:50:43PM -0400, Martin von Zweigbergk wrote:
>
> > When renaming a remote called 'o' using 'git remote rename o foo', git
> > should also rename any remote-tracking branches for the remote. This
> > does happen, but any remote-tracking branches starting with
> > 'refs/remotes/o', such as 'refs/remotes/origin/bar', will also be
> > renamed (to 'refs/remotes/foorigin/bar' in this case).
>
> To be totally correct, shouldn't this check each ref against the RHS of
> the remote's old refspec, and rename it according to the remote's new
> refspec?
That's what I thought too, but was planning on leaving it for a
separate patch. However, after changing patch 1 to only update the
fetch refspecs from "refs/remotes/$OLD" to "refs/remotes/$NEW", there
is no other place in the fetchspec where a remote name can occur and
'git remote rename' still understands it. So since we're now being
more conservative about updating refspecs, I guess we need to be
equally conservative about updating ref names.
Martin
^ permalink raw reply
* Re: [PATCH 1/2] remote: write correct fetch spec when renaming remote 'remote'
From: Martin von Zweigbergk @ 2011-09-02 0:02 UTC (permalink / raw)
To: Jeff King; +Cc: Martin von Zweigbergk, git, Junio C Hamano
In-Reply-To: <20110901024211.GC31838@sigill.intra.peff.net>
On Wed, 31 Aug 2011, Jeff King wrote:
> On Wed, Aug 31, 2011 at 09:50:42PM -0400, Martin von Zweigbergk wrote:
>
> > Reduce the risk of changing incorrect sections of the refspec by
> > requiring the string to be matched to have leading and trailing
> > slashes, i.e. match "/<name>/" instead of just "<name>".
>
> Doesn't this just mean that:
>
> git remote rename remotes foo
>
> will break in the same way?
Yes, "r", "ead" and such now work and only exactly "refs", "heads" and
"remotes" don't work. Sorry, forgot to mention that in the commit
message.
> > We could have required even a leading ":refs/remotes/", but that would
> > mean that we would limit the types of refspecs we could help the user
> > update.
>
> Actually, I think it's better to be more conservative [...]
I think you are right. That's what I did (match all the way from
"refs/...") at first, but then I thought that maybe the reason the
matching was relaxed was to allow non-default refspecs. However, as
you point out in the footnote to your reply to PATCH 2/2, that case is
not working consistently anyway, so it seems safe (w.r.t. backwards
compatibility too) to ignore it. Will switch back to matching
":refs/remotes/$OLD".
Martin
^ permalink raw reply
* Re: Dropping '+' from fetch = +refs/heads/*:refs/remotes/origin/*?
From: Jeff King @ 2011-09-02 0:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vliu8w25g.fsf@alter.siamese.dyndns.org>
On Thu, Sep 01, 2011 at 11:25:31AM -0700, Junio C Hamano wrote:
> Suggested reading:
>
> http://git-blame.blogspot.com/2011/08/how-to-inject-malicious-commit-to-git.html
>
> I am wondering if we are better off applying something along the lines of
> this patch, so that with the default configuration, users can notice if
> their upstream unexpectedly rewound their branches.
Hmm. This feels like it's subtly changing the meaning of
refs/remotes/$remote/*.
Right now, I think of it as a local cache for whatever the remote side
has. In other words, a way of separating the network-fetching parts of
the workflow from the local parts. And in that sense, it is perfectly
reasonable to overwrite with what the other side has, whether they
rewind or not, because we are just representing what they have. And
since we keep a reflog, it's not as if the previous state is lost to us
locally.
But with this change, we are making a policy judgement about what to
fetch. And as you noticed, it means that users need to start telling git
about their policy (e.g., mentioning in the refspecs that pu can rewind)
in order to keep fetch working.
So I consider that a downside, because it's extra work for the user[1].
What are the upsides?
Is this about preventing workflow-related mistakes where people
accidentally merge in rebased commits, creating annoying shadow
histories?
Is it about preventing malicious rewinds from infecting downstream
repositories?
If the former, then I suspect we need to give more guidance to the user
than saying "reject, non-fast-forward". What then? Should they "fetch
-f"? Or "pull --rebase" (actually, how do they even fetch the branch
now for such a pull --rebase)? Or talk out-of-band to the repo owner?
If the latter, then I think we should be specific about the attack
scenarios, and what happens with and without this config. And if it's a
security precaution, what cases doesn't it cover (e.g., initial clone is
still vulnerable, as is a one-off pull. As are are malicious insertion
attacks that don't involve rewinding).
And then we can weigh the upsides and the downsides.
-Peff
[1] What I really don't like is that cloning git.git is no longer:
git clone git://git.kernel.org/pub/scm/git/git.git
which is a minimal as it can be, but becomes:
git clone git://git.kernel.org/pub/scm/git/git.git
cd git
git config --add remote.origin.fetch +refs/heads/pu:refs/remotes/origin/pu
It's not that my fingers are too tired to do all that typing, but
rather that the first set of instructions is very easy to explain,
and the second one is full of magic and head-scratching about why
git isn't handling this magic itself.
It would be considerably nicer if the server had some way of saying
"I expect this branch to be rewound". Which has been discussed off
and on over the years, as I recall.
^ permalink raw reply
* Re: [PATCH 2/2] Add a remote helper to interact with mediawiki (fetch & push)
From: Jonathan Nieder @ 2011-09-01 23:44 UTC (permalink / raw)
To: Matthieu Moy
Cc: Sverre Rabbelier, Junio C Hamano, git, Jeremie Nikaes,
Arnaud Lacurie, Claire Fousse, David Amouyal,
Ramkumar Ramachandra, Dmitry Ivankov
In-Reply-To: <vpqobz53ig3.fsf@bauges.imag.fr>
Hi Matthieu,
Matthieu Moy wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>> Here's an old attempt to make the documentation a little easier to read,
>> and hopefully also to add to.
>
> Thanks, that helps. I wish we had all this earlier ;-).
Glad you like it.
>> +Git sends the remote helper a list of commands on standard input, one
>> +per line. The first command is always the 'capabilities' command,
>
> Do we want to set this in stone?
Yes, I think we should set it in stone. Helpers can use that as a
sanity check to know they are actually being used as a remote
helper. And specifying it makes the protocol more concrete.
> Wouldn't a Git implementation calling
> "option" before "capabilities" be correct?
At that point git doesn't know if the helper implements the "option"
capability.
>> +Capabilities
>> +~~~~~~~~~~~~
>
> (perhaps name the section "Overview of Capabilities"?)
Yes, good idea.
[...]
> Since this "Capabilities" section is meant to be an overview, I'd
> shorten this to
>
> +'refspec' <refspec>::
> + This modifies the 'import' capability, allowing the produced
> + fast-import stream to modify refs in a private namespace
> + instead of writing to refs/heads or refs/remotes directly.
>
> and drop the detailed explanation here.
Another good idea.
>> +Capabilities for Fetching
>> +~~~~~~~~~~~~~~~~~~~~~~~~~
> [...]
>> +'refspec' <refspec>::
>> + This modifies the 'import' capability.
>
> Since this would be the "detailed explanation" part, this is the one
> readers will read more carefully, so I'd put the recommandation right
> here:
>
> + It is recommended that all importers providing the 'import'
> + capability use this.
Yet another. :)
> and of course, keep this:
>
>> ++
>> +A helper advertising
>> +`refspec refs/heads/{asterisk}:refs/svn/origin/branches/{asterisk}`
>> +in its capabilities is saying that, when it handles
>> +`import refs/heads/topic`, the stream it outputs will update the
>> +`refs/svn/origin/branches/topic` ref.
>> ++
>> +This capability can be advertised multiple times. The first
>> +applicable refspec takes precedence. The left-hand of refspecs
>> +advertised with this capability must cover all refs reported by
>> +the list command. If no 'refspec' capability is advertised,
>> +there is an implied `refspec {asterisk}:{asterisk}`.
>> +
Thanks much! Will try to find time to resend later today.
^ permalink raw reply
* Re: Funnies with "git fetch"
From: Jeff King @ 2011-09-01 23:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpqjjnau1.fsf@alter.siamese.dyndns.org>
On Thu, Sep 01, 2011 at 03:42:46PM -0700, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > I think the breakages are:
> >
> > - The sending side does not give any indication that it _wanted_ to send
> > ce0136 but couldn't, and ended up sending another object;
This isn't fixable without the server re-hashing every outgoing object,
though, is it? It thinks it has ce0136, but the data is corrupted. The
only way to detect that is to rehash each object that we send. That's
pretty expensive when you consider decompression and delta
reconstruction.
Besides which, it doesn't help many malicious cases at all. It will
handle disk corruption or a malicious object-db tweak. But it does
nothing against an attacker who can trojan git, or who can spoof the
network session (which is probably hard to do if its straight ssh, but
keep in mind that traffic may be going through cleartext proxies).
So it seems that the receiving side is the only sensible place to put
such checks. It catches problems at more levels, and it can generally
afford the extra processing load (under the assumption that pushes to
servers are smaller and less frequent than fetches).
> > - The pack data sent over the wire was self consistent (no breakage here)
> > and sent three well-formed objects, but it was inconsistent with
> > respect to what history was being transferred (breakage is here);
I don't think this matters. We have thin packs, after all. What goes on
the wire doesn't have to be sensible unto itself; it's about whether
the receiving end can do something useful with it.
> > - The receiving end did not notice the inconsistency.
> >
> > The first one is of the lower priority, as the client side should be able
> > to notice an upstream with corruption in any case. Perhaps after asking
> > for objects between "have" and "want", "git fetch" should verify that it
> > can fully walk the subhistory that was supposed to be transferred down to
> > the blob level?
That seems like a sensible improvement to me.
> So I have a series to fix the latter "more important" half I'll be sending
> out in this thread.
If I understand correctly, your series is just about checking that we
have newly-referenced blobs. We were already checking commits and trees,
and we should already be hashing individual objects when we index the
pack. Right?
In that case, the performance change should be negligible.
-Peff
^ permalink raw reply
* Re: [PATCH] git-remote-helpers.txt: explain how import works with multiple refs
From: Jonathan Nieder @ 2011-09-01 23:17 UTC (permalink / raw)
To: Matthieu Moy
Cc: git, gitster, Sverre Rabbelier, Jeff King, Daniel Barkalow,
Ramkumar Ramachandra, Dmitry Ivankov
In-Reply-To: <1314809222-30528-1-git-send-email-Matthieu.Moy@imag.fr>
Hi Matthieu,
Matthieu Moy wrote:
> --- a/Documentation/git-remote-helpers.txt
> +++ b/Documentation/git-remote-helpers.txt
> @@ -241,7 +241,22 @@ Supported if the helper has the "fetch" capability.
> 'push' +<src>:<dst>::
> Pushes the given local <src> commit or branch to the
> remote branch described by <dst>. A batch sequence of
> - one or more push commands is terminated with a blank line.
> + one or more 'push' commands is terminated with a blank line
> + (if there is only one reference to push, a single 'push' command
> + is followed by a blank line). For example, the following would
> + be two batches of 'push', the first asking the remote-helper
> + to push the local ref 'master' to the remote ref 'master' and
> + the local 'HEAD' to the remote 'branch', and the second
> + asking to push ref 'foo' to ref 'bar' (forced update requested
> + by the '+').
> ++
> +------------
> +push refs/heads/master:refs/heads/master
> +push HEAD:refs/heads/branch
> +\n
> +push +refs/heads/foo:refs/heads/bar
> +\n
> +------------
Probably examples like this could go in a later EXAMPLES section.
At first I was worried about this not actually working, thinking
"push" might have traditionally had the newline-ends-command-stream
semantics that "connect" has. But the push codepath does not set the
no_disconnect_req flag, so I was worrying in vain. :) The stream
passed to the helper ends with two newlines when git pushes.
> +
> Zero or more protocol options may be entered after the last 'push'
> command, before the batch's terminating blank line.
> @@ -266,6 +281,11 @@ Supported if the helper has the "push" capability.
> Especially useful for interoperability with a foreign versioning
> system.
> +
> +Just like 'push', a batch sequence of one or more 'import' is
> +terminated with a blank line. For each batch of 'import', the remote
> +helper should produce a fast-import stream terminated by a 'done'
> +command.
> ++
> Supported if the helper has the "import" capability.
This documents v1.7.7-rc0~61^2~3 (transport-helper: change import
semantics, 2011-07-16). Such a documentation fix was desperately
needed; thank you!
For what it's worth, with or without a change to prevent the example
from interrupting the flow of description,
Acked-by: Jonathan Nieder <jrnieder@gmail.com>
^ permalink raw reply
* [PATCH 3/3] fetch: verify we have everything we need before updating our ref
From: Junio C Hamano @ 2011-09-01 22:43 UTC (permalink / raw)
To: git
In-Reply-To: <1314917015-3587-1-git-send-email-gitster@pobox.com>
The "git fetch" command works in two phases. The remote side tells us what
objects are at the tip of the refs we are fetching from, and transfers the
objects missing from our side. After storing the objects in our repository,
we update our remote tracking branches to point at the updated tips of the
refs.
A broken or malicious remote side could send a perfectly well-formed pack
data during the object transfer phase, but there is no guarantee that the
given data actually fill the gap between the objects we originally had and
the refs we are updating to.
Although this kind of breakage can be caught by running fsck after a
fetch, it is much cheaper to verify that everything that is reachable from
the tips of the refs we fetched are indeed fully connected to the tips of
our current set of refs before we update them.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin/fetch.c | 119 +++++++++++++++++++++++++++++--------------------------
1 files changed, 63 insertions(+), 56 deletions(-)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index f9c41da..bdb03ff 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -345,6 +345,64 @@ static int update_local_ref(struct ref *ref,
}
}
+/*
+ * The ref_map records the tips of the refs we are fetching. If
+ *
+ * $ git rev-list --verify-objects --stdin --not --all
+ *
+ * (feeding all the refs in ref_map on its standard input) does not
+ * error out, that means everything reachable from these updated refs
+ * locally exists and is connected to some of our existing refs.
+ *
+ * Returns 0 if everything is connected, non-zero otherwise.
+ */
+static int check_everything_connected(struct ref *ref_map, int quiet)
+{
+ struct child_process rev_list;
+ const char *argv[] = {"rev-list", "--verify-objects",
+ "--stdin", "--not", "--all", NULL, NULL};
+ char commit[41];
+ struct ref *ref;
+ int err = 0;
+
+ if (!ref_map)
+ return 0;
+
+ if (quiet)
+ argv[5] = "--quiet";
+
+ memset(&rev_list, 0, sizeof(rev_list));
+ rev_list.argv = argv;
+ rev_list.git_cmd = 1;
+ rev_list.in = -1;
+ rev_list.no_stdout = 1;
+ rev_list.no_stderr = quiet;
+ if (start_command(&rev_list))
+ return error(_("Could not run 'git rev-list'"));
+
+ sigchain_push(SIGPIPE, SIG_IGN);
+
+ memcpy(commit + 40, "\n", 2);
+ for (ref = ref_map; ref; ref = ref->next) {
+ memcpy(commit, sha1_to_hex(ref->old_sha1), 40);
+ if (write_in_full(rev_list.in, commit, 41) < 0) {
+ if (errno != EPIPE && errno != EINVAL)
+ error(_("failed write to rev-list: %s"),
+ strerror(errno));
+ err = -1;
+ break;
+ }
+ }
+ if (close(rev_list.in)) {
+ error(_("failed to close rev-list's stdin: %s"), strerror(errno));
+ err = -1;
+ }
+
+ sigchain_pop(SIGPIPE);
+
+ return finish_command(&rev_list) || err;
+}
+
static int store_updated_refs(const char *raw_url, const char *remote_name,
struct ref *ref_map)
{
@@ -364,6 +422,10 @@ static int store_updated_refs(const char *raw_url, const char *remote_name,
url = transport_anonymize_url(raw_url);
else
url = xstrdup("foreign");
+
+ if (check_everything_connected(ref_map, 0))
+ return error(_("%s did not send all necessary objects\n"), url);
+
for (rm = ref_map; rm; rm = rm->next) {
struct ref *ref = NULL;
@@ -457,24 +519,9 @@ static int store_updated_refs(const char *raw_url, const char *remote_name,
* We would want to bypass the object transfer altogether if
* everything we are going to fetch already exists and is connected
* locally.
- *
- * The refs we are going to fetch are in ref_map. If running
- *
- * $ git rev-list --objects --stdin --not --all
- *
- * (feeding all the refs in ref_map on its standard input)
- * does not error out, that means everything reachable from the
- * refs we are going to fetch exists and is connected to some of
- * our existing refs.
*/
static int quickfetch(struct ref *ref_map)
{
- struct child_process revlist;
- struct ref *ref;
- int err;
- const char *argv[] = {"rev-list",
- "--quiet", "--objects", "--stdin", "--not", "--all", NULL};
-
/*
* If we are deepening a shallow clone we already have these
* objects reachable. Running rev-list here will return with
@@ -484,47 +531,7 @@ static int quickfetch(struct ref *ref_map)
*/
if (depth)
return -1;
-
- if (!ref_map)
- return 0;
-
- memset(&revlist, 0, sizeof(revlist));
- revlist.argv = argv;
- revlist.git_cmd = 1;
- revlist.no_stdout = 1;
- revlist.no_stderr = 1;
- revlist.in = -1;
-
- err = start_command(&revlist);
- if (err) {
- error(_("could not run rev-list"));
- return err;
- }
-
- /*
- * If rev-list --stdin encounters an unknown commit, it terminates,
- * which will cause SIGPIPE in the write loop below.
- */
- sigchain_push(SIGPIPE, SIG_IGN);
-
- for (ref = ref_map; ref; ref = ref->next) {
- if (write_in_full(revlist.in, sha1_to_hex(ref->old_sha1), 40) < 0 ||
- write_str_in_full(revlist.in, "\n") < 0) {
- if (errno != EPIPE && errno != EINVAL)
- error(_("failed write to rev-list: %s"), strerror(errno));
- err = -1;
- break;
- }
- }
-
- if (close(revlist.in)) {
- error(_("failed to close rev-list's stdin: %s"), strerror(errno));
- err = -1;
- }
-
- sigchain_pop(SIGPIPE);
-
- return finish_command(&revlist) || err;
+ return check_everything_connected(ref_map, 1);
}
static int fetch_refs(struct transport *transport, struct ref *ref_map)
--
1.7.7.rc0.72.g4b5ea
^ permalink raw reply related
* [PATCH 2/3] rev-list --verify-object
From: Junio C Hamano @ 2011-09-01 22:43 UTC (permalink / raw)
To: git
In-Reply-To: <1314917015-3587-1-git-send-email-gitster@pobox.com>
Often we want to verify everything reachable from a given set of commits
are present in our repository and connected without a gap to the tips of
our refs. We used to do this for this purpose:
$ rev-list --objects $commits_to_be_tested --not --all
Even though this is good enough for catching missing commits and trees,
we show the object name but do not verify their existence, let alone their
well-formedness, for the blob objects at the leaf level.
Add a new "--verify-object" option so that we can catch missing and broken
blobs as well.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin/rev-list.c | 4 ++++
revision.c | 5 +++++
revision.h | 1 +
3 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/builtin/rev-list.c b/builtin/rev-list.c
index 920b91c..ab3be7c 100644
--- a/builtin/rev-list.c
+++ b/builtin/rev-list.c
@@ -180,7 +180,11 @@ static void show_object(struct object *obj,
const struct name_path *path, const char *component,
void *cb_data)
{
+ struct rev_info *info = cb_data;
+
finish_object(obj, path, component, cb_data);
+ if (info->verify_objects && !obj->parsed && obj->type != OBJ_COMMIT)
+ parse_object(obj->sha1);
show_object_with_name(stdout, obj, path, component);
}
diff --git a/revision.c b/revision.c
index 072ddac..5ef498b 100644
--- a/revision.c
+++ b/revision.c
@@ -1383,6 +1383,11 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
revs->tree_objects = 1;
revs->blob_objects = 1;
revs->edge_hint = 1;
+ } else if (!strcmp(arg, "--verify-objects")) {
+ revs->tag_objects = 1;
+ revs->tree_objects = 1;
+ revs->blob_objects = 1;
+ revs->verify_objects = 1;
} else if (!strcmp(arg, "--unpacked")) {
revs->unpacked = 1;
} else if (!prefixcmp(arg, "--unpacked=")) {
diff --git a/revision.h b/revision.h
index da00a58..648876b 100644
--- a/revision.h
+++ b/revision.h
@@ -53,6 +53,7 @@ struct rev_info {
tag_objects:1,
tree_objects:1,
blob_objects:1,
+ verify_objects:1,
edge_hint:1,
limited:1,
unpacked:1,
--
1.7.7.rc0.72.g4b5ea
^ permalink raw reply related
* [PATCH 1/3] list-objects: pass callback data to show_objects()
From: Junio C Hamano @ 2011-09-01 22:43 UTC (permalink / raw)
To: git
In-Reply-To: <1314917015-3587-1-git-send-email-gitster@pobox.com>
The traverse_commit_list() API takes two callback functions, one to show
commit objects, and the other to show other kinds of objects. Even though
the former has a callback data parameter, so that the callback does not
have to rely on global state, the latter does not.
Give the show_objects() callback the same callback data parameter.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin/pack-objects.c | 4 +++-
builtin/rev-list.c | 10 +++++++---
list-objects.c | 28 +++++++++++++++++-----------
list-objects.h | 5 ++---
upload-pack.c | 4 +++-
5 files changed, 32 insertions(+), 19 deletions(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index f402a84..fca6cb5 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -1936,7 +1936,9 @@ static void show_commit(struct commit *commit, void *data)
commit->object.flags |= OBJECT_ADDED;
}
-static void show_object(struct object *obj, const struct name_path *path, const char *last)
+static void show_object(struct object *obj,
+ const struct name_path *path, const char *last,
+ void *data)
{
char *name = path_name(path, last);
diff --git a/builtin/rev-list.c b/builtin/rev-list.c
index f5ce487..920b91c 100644
--- a/builtin/rev-list.c
+++ b/builtin/rev-list.c
@@ -168,15 +168,19 @@ static void finish_commit(struct commit *commit, void *data)
commit->buffer = NULL;
}
-static void finish_object(struct object *obj, const struct name_path *path, const char *name)
+static void finish_object(struct object *obj,
+ const struct name_path *path, const char *name,
+ void *cb_data)
{
if (obj->type == OBJ_BLOB && !has_sha1_file(obj->sha1))
die("missing blob object '%s'", sha1_to_hex(obj->sha1));
}
-static void show_object(struct object *obj, const struct name_path *path, const char *component)
+static void show_object(struct object *obj,
+ const struct name_path *path, const char *component,
+ void *cb_data)
{
- finish_object(obj, path, component);
+ finish_object(obj, path, component, cb_data);
show_object_with_name(stdout, obj, path, component);
}
diff --git a/list-objects.c b/list-objects.c
index 0fb44e7..39d80c0 100644
--- a/list-objects.c
+++ b/list-objects.c
@@ -12,7 +12,8 @@ static void process_blob(struct rev_info *revs,
struct blob *blob,
show_object_fn show,
struct name_path *path,
- const char *name)
+ const char *name,
+ void *cb_data)
{
struct object *obj = &blob->object;
@@ -23,7 +24,7 @@ static void process_blob(struct rev_info *revs,
if (obj->flags & (UNINTERESTING | SEEN))
return;
obj->flags |= SEEN;
- show(obj, path, name);
+ show(obj, path, name, cb_data);
}
/*
@@ -52,7 +53,8 @@ static void process_gitlink(struct rev_info *revs,
const unsigned char *sha1,
show_object_fn show,
struct name_path *path,
- const char *name)
+ const char *name,
+ void *cb_data)
{
/* Nothing to do */
}
@@ -62,7 +64,8 @@ static void process_tree(struct rev_info *revs,
show_object_fn show,
struct name_path *path,
struct strbuf *base,
- const char *name)
+ const char *name,
+ void *cb_data)
{
struct object *obj = &tree->object;
struct tree_desc desc;
@@ -80,7 +83,7 @@ static void process_tree(struct rev_info *revs,
if (parse_tree(tree) < 0)
die("bad tree object %s", sha1_to_hex(obj->sha1));
obj->flags |= SEEN;
- show(obj, path, name);
+ show(obj, path, name, cb_data);
me.up = path;
me.elem = name;
me.elem_len = strlen(name);
@@ -106,14 +109,17 @@ static void process_tree(struct rev_info *revs,
if (S_ISDIR(entry.mode))
process_tree(revs,
lookup_tree(entry.sha1),
- show, &me, base, entry.path);
+ show, &me, base, entry.path,
+ cb_data);
else if (S_ISGITLINK(entry.mode))
process_gitlink(revs, entry.sha1,
- show, &me, entry.path);
+ show, &me, entry.path,
+ cb_data);
else
process_blob(revs,
lookup_blob(entry.sha1),
- show, &me, entry.path);
+ show, &me, entry.path,
+ cb_data);
}
strbuf_setlen(base, baselen);
free(tree->buffer);
@@ -185,17 +191,17 @@ void traverse_commit_list(struct rev_info *revs,
continue;
if (obj->type == OBJ_TAG) {
obj->flags |= SEEN;
- show_object(obj, NULL, name);
+ show_object(obj, NULL, name, data);
continue;
}
if (obj->type == OBJ_TREE) {
process_tree(revs, (struct tree *)obj, show_object,
- NULL, &base, name);
+ NULL, &base, name, data);
continue;
}
if (obj->type == OBJ_BLOB) {
process_blob(revs, (struct blob *)obj, show_object,
- NULL, name);
+ NULL, name, data);
continue;
}
die("unknown pending object %s (%s)",
diff --git a/list-objects.h b/list-objects.h
index d65dbf0..3db7bb6 100644
--- a/list-objects.h
+++ b/list-objects.h
@@ -2,11 +2,10 @@
#define LIST_OBJECTS_H
typedef void (*show_commit_fn)(struct commit *, void *);
-typedef void (*show_object_fn)(struct object *, const struct name_path *, const char *);
-typedef void (*show_edge_fn)(struct commit *);
-
+typedef void (*show_object_fn)(struct object *, const struct name_path *, const char *, void *);
void traverse_commit_list(struct rev_info *, show_commit_fn, show_object_fn, void *);
+typedef void (*show_edge_fn)(struct commit *);
void mark_edges_uninteresting(struct commit_list *, struct rev_info *, show_edge_fn);
#endif
diff --git a/upload-pack.c b/upload-pack.c
index 970a1eb..6be6259 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -83,7 +83,9 @@ static void show_commit(struct commit *commit, void *data)
commit->buffer = NULL;
}
-static void show_object(struct object *obj, const struct name_path *path, const char *component)
+static void show_object(struct object *obj,
+ const struct name_path *path, const char *component,
+ void *cb_data)
{
show_object_with_name(pack_pipe, obj, path, component);
}
--
1.7.7.rc0.72.g4b5ea
^ permalink raw reply related
* [PATCH 0/3] Verify the objects fetch obtained before updating ref
From: Junio C Hamano @ 2011-09-01 22:43 UTC (permalink / raw)
To: git
In-Reply-To: <7vpqjkw3nb.fsf@alter.siamese.dyndns.org>
So here is a series to make the client side a bit more careful.
These patches apply on top of jc/traverse-commit-list beba25a (revision.c:
update show_object_with_name() without using malloc(), 2011-08-17) in
'next'.
Junio C Hamano (3):
list-objects: pass callback data to show_objects()
rev-list --verify-object
fetch: ensure we transferred everything we need before updating our
ref
builtin/fetch.c | 119 +++++++++++++++++++++++++----------------------
builtin/pack-objects.c | 4 +-
builtin/rev-list.c | 14 ++++-
list-objects.c | 28 +++++++----
list-objects.h | 5 +-
revision.c | 5 ++
revision.h | 1 +
upload-pack.c | 4 +-
8 files changed, 105 insertions(+), 75 deletions(-)
--
1.7.7.rc0.72.g4b5ea
^ permalink raw reply
* Re: Funnies with "git fetch"
From: Junio C Hamano @ 2011-09-01 22:42 UTC (permalink / raw)
To: git
In-Reply-To: <7vpqjkw3nb.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I think the breakages are:
>
> - The sending side does not give any indication that it _wanted_ to send
> ce0136 but couldn't, and ended up sending another object;
>
> - The pack data sent over the wire was self consistent (no breakage here)
> and sent three well-formed objects, but it was inconsistent with
> respect to what history was being transferred (breakage is here);
>
> - The receiving end did not notice the inconsistency.
>
> The first one is of the lower priority, as the client side should be able
> to notice an upstream with corruption in any case. Perhaps after asking
> for objects between "have" and "want", "git fetch" should verify that it
> can fully walk the subhistory that was supposed to be transferred down to
> the blob level?
So I have a series to fix the latter "more important" half I'll be sending
out in this thread.
^ permalink raw reply
* [PULL] various git-svn updates
From: Eric Wong @ 2011-09-01 22:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Bryan Jacobs, Sam Vilain, H Krishnan, Ray Chen, git
Please pull from "master" on git://bogomips.org/git-svn.git
Bryan Jacobs (1):
git-svn: Teach dcommit --mergeinfo to handle multiple lines
Eric Wong (1):
git-svn: fix fetch with moved path when using rewriteRoot
Ray Chen (1):
git-svn: New flag to emulate empty directories
commit 85f022e9c124ffeda31a50cab878e1418d694d87 (fix fetch with moved path)
is also suitable for cherry-picking into maint. All tests pass on
Debian 6.0 (x86_64).
--
Eric Wong
^ permalink raw reply
* Re: Cannot rewrite branch(es) with a dirty working directory
From: Jeff King @ 2011-09-01 21:53 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Junio C Hamano, James Blackburn, git
In-Reply-To: <20110901215003.GC16308@sigill.intra.peff.net>
On Thu, Sep 01, 2011 at 05:50:03PM -0400, Jeff King wrote:
> > No idea. It comes after a "git reset --hard", so it's supposed to be
> > clean.
>
> I wonder if there are racily clean entries[1] in the index, and
> diff-index reports them as potential changes.
>
> At any rate, filter-branch should probably be refreshing the index
> before checking for dirtiness, which would give the correct answer
> either way.
Actually, we've already factored this logic out, so let's use it.
-- >8 --
Subject: filter-branch: use require_clean_work_tree
Filter-branch already requires that we have a clean work
tree before starting. However, it failed to refresh the
index before checking, which means it could be wrong in the
case of stat-dirtiness.
Instead of simply adding a call to refresh the index, let's
switch to using the require_clean_work_tree function
provided by git-sh-setup. It does exactly what we want, and
with fewer lines of code and more specific output messages.
Signed-off-by: Jeff King <peff@peff.net>
---
git-filter-branch.sh | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 804a7f4..add2c02 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -108,9 +108,7 @@ OPTIONS_SPEC=
. git-sh-setup
if [ "$(is_bare_repository)" = false ]; then
- git diff-files --ignore-submodules --quiet &&
- git diff-index --cached --quiet HEAD -- ||
- die "Cannot rewrite branch(es) with a dirty working directory."
+ require_clean_work_tree 'rewrite branches'
fi
tempdir=.git-rewrite
--
1.7.6.10.g62f04
^ permalink raw reply related
* Re: Cannot rewrite branch(es) with a dirty working directory
From: Jeff King @ 2011-09-01 21:50 UTC (permalink / raw)
To: Matthieu Moy; +Cc: James Blackburn, git
In-Reply-To: <vpqmxeoqj61.fsf@bauges.imag.fr>
On Thu, Sep 01, 2011 at 07:14:30PM +0200, Matthieu Moy wrote:
> James Blackburn <jamesblackburn@gmail.com> writes:
>
> > Is there a particular reason why filter-branch thinks the tree is
> > dirty,
>
> No idea. It comes after a "git reset --hard", so it's supposed to be
> clean.
I wonder if there are racily clean entries[1] in the index, and
diff-index reports them as potential changes.
At any rate, filter-branch should probably be refreshing the index
before checking for dirtiness, which would give the correct answer
either way.
-Peff
[1] See Documentation/technical/racy-git.txt for more information.
^ permalink raw reply
* Re: Rebase & Trailing Whitespace
From: Jeff King @ 2011-09-01 21:26 UTC (permalink / raw)
To: Philip Oakley; +Cc: Hilco Wijbenga, Git Users
In-Reply-To: <29267EE41F9343E68AAAE2C33AA40E1A@PhilipOakley>
On Thu, Sep 01, 2011 at 10:00:38PM +0100, Philip Oakley wrote:
> >[1] If you don't remember the empty tree sha1, you can always derive it
> > with:
> >
> > git hash-object -t tree /dev/null
> >
>
> I've added this tip to the
> https://git.wiki.kernel.org/index.php/Aliases page
Thanks. By itself, I think many readers would ask "why would I want the
empty tree, so I threw in a few examples of use on the wiki, too.
-Peff
^ permalink raw reply
* Re: git 'new' alias
From: Jeff King @ 2011-09-01 21:17 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Thiago Farina, Git Mailing List
In-Reply-To: <vpqei00m4pf.fsf@bauges.imag.fr>
On Thu, Sep 01, 2011 at 09:40:28PM +0200, Matthieu Moy wrote:
> Thiago Farina <tfransosi@gmail.com> writes:
>
> > Hi,
> >
> > Could we change the 'new' alias in the wiki page,
> >
> > from:
> > new = !sh -c 'git log $1@{1}..$1@{0} "$@"'
> >
> > to:
> > new = !git log $1@{1}..$1@{0} "$@"
> >
> > ?
>
> Go on. I think I'm the one who added it, and I didn't know $1 and $@
> would work without "sh -c", but I guess my version results in calling
> stg like sh -c "sh -c 'git log ...'" which is a bit overkill ;-).
Hmm. Aren't both of these somewhat wrong?
Git will assume your alias is a shell snippet, append the
space-separated shell-quoted arguments provided to the alias to your
snippet, and then hand the result to the shell.
We can simulate the first one with:
$ git config alias.one
!sh -c 'echo $1@{1}..$1@{0} "$@"'
which gives:
$ git one foo
@{1}..@{0}
Oops, that's not right. You need a placeholder for $0. So make it:
$ git config alias.one
!sh -c 'echo $1@{1}..$1@{0} "$@"' --
and now you get:
$ git one foo
foo@{1}..foo@{0} foo
Wait, what's that extra "foo" on the end? I'm not sure of the intent.
Either it is totally superfluous, or perhaps it was meant to pass along
other options, like path limiters. In the former case, you just want:
!sh -c 'echo $1@{1}..$1@{0}' --
and in the latter case, you actually want to shift off $1 and provide
the rest of the options. Of course, for this particular alias, it so
happens that adding an extra $1 is equivalent to $1@{0}, which is
superfluous but harmless. More on that in a minute.
How about the second one:
$ git config alias.two
!echo $1@{1}..$1@{0} "$@"
which yields:
$ git two foo
foo@{1}..foo@{0} foo foo
Now we have two extra foos! One is from a superfluous use of "$@", which
is no longer necessary to pass along extra args, since we aren't
invoking a subshell. So we are better off with:
$ git config alias.two
!echo $1@{1}..$1@{0}
which yields:
$ git two foo
foo@{1}..foo@{0} foo
Better, but we still get our superfluous "foo" at the end. And there's
no way to get rid of it here, since it is appended to our shell snippet.
We can't just shift it away.
So in this particular alias, you can live without the subshell wrapper,
and the final alias.two I mentioned is OK. If you're satisfied with
that, you can stop reading now. I still find the repeated refname a
little hack-ish, though, as it doesn't extend to other aliases
naturally.
You mentioned the ugliness in having the shell call itself. Weep for the
quoting nightmare that is:
$ git config alias.one
!sh -c 'echo $1@{1}..$1@{0} "$@"' --
$ GIT_TRACE=1 git one foo
trace: exec: 'sh' '-c' 'sh -c '\''echo $1@{1}..$1@{0} "$@"'\'' -- "$@"' 'sh -c '\''echo $1@{1}..$1@{0} "$@"'\'' --' 'foo'
Fortunately, we can do a little better using shell functions. I would
write this as:
$ git config alias.one
!f() { r=$1; shift; echo $r@{1}..$r@{0} "$@"; }; f
$ git one foo
foo@{1}..foo@{0}
$ git one foo bar
foo@{1}..foo@{0} bar
which I think was the original intent (modulo me replacing "git log"
with "echo" for debugging, of course). And if you peek at GIT_TRACE
output, we only invoke a single shell.
Now back to the original complaint: no shell completion. For that, I
would simply add:
_git_new() {
__git_complete_revlist
}
to my .bashrc. Yeah, it's a little more work than having the completion
automatically figure out that "new" takes the same arguments as "git
log", but it works in the general case.
-Peff
^ permalink raw reply
* Re: Rebase & Trailing Whitespace
From: Philip Oakley @ 2011-09-01 21:00 UTC (permalink / raw)
To: Jeff King, Hilco Wijbenga; +Cc: Git Users
In-Reply-To: <20110901023127.GB31838@sigill.intra.peff.net>
From: "Jeff King" <peff@peff.net>
> On Wed, Aug 31, 2011 at 04:55:03PM -0700, Hilco Wijbenga wrote:
> problems that still exist in your current tree, you can diff against the
> empty tree with --check, like:
>
> git diff --check 4b825dc642cb6eb9a060e54bf8d69288fbee4904
>
> where "4b825dc..." is the well-known sha1 of an empty tree[1].
>
> [1] If you don't remember the empty tree sha1, you can always derive it
> with:
>
> git hash-object -t tree /dev/null
>
I've added this tip to the https://git.wiki.kernel.org/index.php/Aliases
page
Philip
^ permalink raw reply
* Re: Using git-svn fetch after a directory change with rewrite-root
From: Eric Wong @ 2011-09-01 20:54 UTC (permalink / raw)
To: H Krishnan; +Cc: git
In-Reply-To: <20110820191837.GA30509@dcvr.yhbt.net>
Eric Wong <normalperson@yhbt.net> wrote:
> H Krishnan <hetchkay@gmail.com> wrote:
> > I wonder if commit 3235b7053c45a734c1cdf9b117bda68b7ced29c9 handles
> > rewrite-root correctly. Should the comparison be made with
> > $gs->metadata_url instead of $gs->full_url?
>
> I think you're right, can you submit a test case? Current
> tests all pass with $gs->metadata_url so I can probably
> push it out in a bit regardless.
I've pushed the following out to git://bogomips.org/git-svn.git
>From 85f022e9c124ffeda31a50cab878e1418d694d87 Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@yhbt.net>
Date: Mon, 29 Aug 2011 00:45:44 +0000
Subject: [PATCH] git-svn: fix fetch with moved path when using rewriteRoot
The matching step in commit 3235b7053c45a734c1cdf9b117bda68b7ced29c9
did not properly account for users of the "rewriteRoot"
configuration parameter.
ref: <CANWsHyfHtr0EaJtNsDK9UTcmb_AbLg-1jUA-0uWJ-nEeNosb7w@mail.gmail.com>
Suggested-by: H Krishnan <hetchkay@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 96f373f..32792d3 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -3022,7 +3022,7 @@ sub other_gs {
my (undef, $max_commit) = $gs->rev_map_max(1);
last if (!$max_commit);
my ($url) = ::cmt_metadata($max_commit);
- last if ($url eq $gs->full_url);
+ last if ($url eq $gs->metadata_url);
$ref_id .= '-';
}
print STDERR "Initializing parent: $ref_id\n" unless $::_q > 1;
--
Eric Wong
^ permalink raw reply related
* Re: Dropping '+' from fetch = +refs/heads/*:refs/remotes/origin/*?
From: Shawn Pearce @ 2011-09-01 19:50 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Michael J Gruber, Junio C Hamano, git
In-Reply-To: <vpqippcm4x4.fsf@bauges.imag.fr>
On Thu, Sep 1, 2011 at 12:35, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
> By asking users to explicitely say "yes, I know, this branch can be
> rewond", we also ask them to think about it before making a mistake.
>
> That said, enabling the check by default may also become painful. I'd
> vote for a configuration option, defaulting to the current behavior for
> now. Then we can try living with it for a while and see how painful it
> is.
I suspect the vast majority of branches in the wild do not rewind
under normal conditions. Users who work against branches that rewind
(e.g. those of us basing on a topic in pu) are already sophisticated
enough with Git to understand what the fetch error would mean and fix
it.
IMHO, just change the default in clone, and better, add a warning to
fetch if that default pattern is still in the configuration file. Let
the user either remove the wildcarded force fetch spec, or add a new
configuration variable to his remote block to silence the warning.
--
Shawn.
^ permalink raw reply
* Re: git 'new' alias
From: Matthieu Moy @ 2011-09-01 19:40 UTC (permalink / raw)
To: Thiago Farina; +Cc: Git Mailing List
In-Reply-To: <CACnwZYfo2E0SFfFrYzUktAZYwqgyX_J4KgFQD5kqXToGmip3Lg@mail.gmail.com>
Thiago Farina <tfransosi@gmail.com> writes:
> Hi,
>
> Could we change the 'new' alias in the wiki page,
>
> from:
> new = !sh -c 'git log $1@{1}..$1@{0} "$@"'
>
> to:
> new = !git log $1@{1}..$1@{0} "$@"
>
> ?
Go on. I think I'm the one who added it, and I didn't know $1 and $@
would work without "sh -c", but I guess my version results in calling
stg like sh -c "sh -c 'git log ...'" which is a bit overkill ;-).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Dropping '+' from fetch = +refs/heads/*:refs/remotes/origin/*?
From: Matthieu Moy @ 2011-09-01 19:35 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Junio C Hamano, git
In-Reply-To: <4E5FDAFE.6050004@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> Thinking more about it, we try to encourage a workflow where locally
> history may be rewritten a lot, and distribution points fast-forward
> only. We have defaults and settings to discourage (pushes to checked out
> branches and) non-ff pushes, for example. So I think the above change is
> pretty much in line with that reasoning.
Agreed. It's not only a security thing, it's also about
teaching/encourraging workflows.
By asking users to explicitely say "yes, I know, this branch can be
rewond", we also ask them to think about it before making a mistake.
That said, enabling the check by default may also become painful. I'd
vote for a configuration option, defaulting to the current behavior for
now. Then we can try living with it for a while and see how painful it
is.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* git 'new' alias
From: Thiago Farina @ 2011-09-01 19:30 UTC (permalink / raw)
To: Git Mailing List
Hi,
Could we change the 'new' alias in the wiki page,
from:
new = !sh -c 'git log $1@{1}..$1@{0} "$@"'
to:
new = !git log $1@{1}..$1@{0} "$@"
?
The former doesn't get auto-completion, while the second yes.
https://git.wiki.kernel.org/index.php/Aliases#What.27s_new.3F
^ 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