* [PATCH] tests: make all test files executable
From: Mark Rada @ 2009-10-06 1:46 UTC (permalink / raw)
To: Junio C Hamano, Jeff King; +Cc: git
For consistency with the rest of the test files.
Signed-off-by: Mark Rada <marada@uwaterloo.ca>
---
No changes, just a resend. This should work; I assume
the problem last time was a human error (me :(), or
something weird that happens with saving e-mail drafts
between Apple Mail and Thunderbird (they share).
If this version is also messed up, then I give up.
Jeff, please explain what you meant by `inscrutable
binary'? It is an ASCII text file according to file.
¯\(°_o)/¯
0 files changed, 0 insertions(+), 0 deletions(-)
mode change 100644 => 100755 t/t5531-deep-submodule-push.sh
mode change 100644 => 100755 t/t9501-gitweb-standalone-http-status.sh
diff --git a/t/t5531-deep-submodule-push.sh b/t/t5531-deep-submodule-push.sh
old mode 100644
new mode 100755
diff --git a/t/t9501-gitweb-standalone-http-status.sh b/t/t9501-gitweb-standalone-http-status.sh
old mode 100644
new mode 100755
--
1.6.5.rc2
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Jeff King @ 2009-10-05 22:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jay Soffian, git
In-Reply-To: <alpine.DEB.1.00.0910052314580.4985@pacific.mpi-cbg.de>
On Mon, Oct 05, 2009 at 11:17:09PM +0200, Johannes Schindelin wrote:
> > $ git clone git://git.kernel.org/pub/scm/git/git.git
> > $ cd git
> > $ git checkout next
> > error: pathspec 'next' did not match any file(s) known to git.
> > To create a local branch from the same named remote branch, use
> > git checkout -b next origin/next
> >
> > Motivated by http://article.gmane.org/gmane.comp.version-control.git/129528
>
> Actually, we should really think long and hard why we should not
> automatically check out the local branch "next" in that case. I mean,
> really long and hard, and making sure to take user-friendliness into
> account at least as much as simplicity of implementation.
Some devil's advocate questions:
1. How do we find "origin/next" given "next"? What are the exact
lookup rules? Do they cover every case? Do they avoid surprising
the user?
2. What do we do if our lookup is ambiguous (e.g., "origin/next" and
"foobar/next" both exist)?
3. If our lookup does have ambiguities or corner cases, is it better
to simply be suggesting to the user, rather than proceeding with an
action?
-Peff
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Jeff King @ 2009-10-05 22:52 UTC (permalink / raw)
To: Jay Soffian; +Cc: git
In-Reply-To: <1254775583-49452-1-git-send-email-jaysoffian@gmail.com>
On Mon, Oct 05, 2009 at 04:46:23PM -0400, Jay Soffian wrote:
> +static int suggest_new_branch_name_compare(struct remote *remote, void *priv)
> +{
> + struct suggest_new_branch_name_data *data = priv;
> + unsigned char sha1[20];
> + struct strbuf buf = STRBUF_INIT;
> + strbuf_addf(&buf, "refs/remotes/%s/%s", remote->name, data->name);
> + if (resolve_ref(buf.buf, sha1, 1, NULL)) {
> + data->matches++;
> + if (data->found)
> + strbuf_release(&buf);
> + else
> + data->found = strbuf_detach(&buf, NULL);
> + }
> + return 0;
> +}
This assumes that remote X always has its tracking branches in
refs/remotes/X/*. But that is really dependent on how the fetch refspec
is set up. True, it will be like that for remotes set up by "git remote"
or "git clone", but it isn't universal (and we have tried not to make
that assumption elsewhere, like when finding upstream branches to merge
from). Doing it right would mean interpreting the refspecs in
remote.*.fetch.
But this is not necessarily about actual remotes, I don't think. It is
really about the names of refs we have, and that you could reference,
but that are not actual tracking branches. It's just that refs/remotes
is the obvious hierarchy there.
But I wonder if what you should do instead is to iterate through each
ref, removing refs/heads/* and refs/tags/* (which are uninteresting, as
they are already part of the normal ref lookup), and then suffix-match.
So looking for "next" would find "refs/remotes/origin/next", or even
"refs/foobar/next" if you had some "foobar" hierarchy.
It would also match "foo" to "refs/remotes/origin/jk/foo". I'm not sure
if that is a feature or a bug, though.
Aside from that, I can't think of anything wrong with the idea.
Personally I find it more chatty than I would want, because I know what
I'm doing. So I would suggest adding an advice.suggestBranchName config
option to voluntarily suppress it.
-Peff
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Johannes Schindelin @ 2009-10-05 22:45 UTC (permalink / raw)
To: Jay Soffian; +Cc: git
In-Reply-To: <76718490910051500m32878c7dgcc86489933cb2309@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 598 bytes --]
Hi,
On Mon, 5 Oct 2009, Jay Soffian wrote:
> On Mon, Oct 5, 2009 at 5:17 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > Actually, we should really think long and hard why we should not
> > automatically check out the local branch "next" in that case. I mean,
> > really long and hard, and making sure to take user-friendliness into
> > account at least as much as simplicity of implementation.
>
> Sure, why not? Are you asking for a patch, or just soliciting
> conversation?
I am asking for thoughtful arguments for and against my (shyly implied)
proposal.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Jay Soffian @ 2009-10-05 22:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0910052314580.4985@pacific.mpi-cbg.de>
On Mon, Oct 5, 2009 at 5:17 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Actually, we should really think long and hard why we should not
> automatically check out the local branch "next" in that case. I mean,
> really long and hard, and making sure to take user-friendliness into
> account at least as much as simplicity of implementation.
Sure, why not? Are you asking for a patch, or just soliciting conversation?
j.
^ permalink raw reply
* Re: Confusing git pull error message
From: Jeff King @ 2009-10-05 22:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, John Tapsell, Git List
In-Reply-To: <7vd451ab16.fsf@alter.siamese.dyndns.org>
On Mon, Oct 05, 2009 at 12:36:05PM -0700, Junio C Hamano wrote:
> -- >8 --
> Subject: [PATCH] git-pull: dead code removal
>
> Back when a74b170 (git-pull: disallow implicit merging to detached HEAD,
> 2007-01-15) added this check, $? referred to the error status of reading
> HEAD as a symbolic-ref; but cd67e4d (Teach 'git pull' about --rebase,
> 2007-11-28) moved the command away from where the check is, and nobody
> noticed the breakage. Ever since, $? has always been 0 (tr at the end of
> the pipe to find merge_head never fails) and other case arms were never
> reached.
>
> These days, error_on_no_merge_candidates function is prepared to handle a
> detached HEAD case, which was what the code this patch removes used to
> handle.
Looks good to me.
Acked-by: Jeff King <peff@peff.net>
-Peff
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Jay Soffian @ 2009-10-05 21:57 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Johannes Schindelin, git
In-Reply-To: <fabb9a1e0910051426n7f4f8602l8fad733ac3ba82b3@mail.gmail.com>
On Mon, Oct 5, 2009 at 5:26 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> @jay: you assume that if there is more than one matching remote the
> user is experienced (as they have multiple remotes) enough to know
> what to do?
That and it was just an RFC patch, so I just decided to ignore that
case initially.
j.
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Sverre Rabbelier @ 2009-10-05 21:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jay Soffian, git
In-Reply-To: <alpine.DEB.1.00.0910052314580.4985@pacific.mpi-cbg.de>
Heya,
On Mon, Oct 5, 2009 at 23:17, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Actually, we should really think long and hard why we should not
> automatically check out the local branch "next" in that case. I mean,
> really long and hard, and making sure to take user-friendliness into
> account at least as much as simplicity of implementation.
If git was a little more interactive I'd say prompt the user, problem solved?
$ git checkout next
No such branch 'next', do you want to check out a local branch for
'origin/next' instead? [Y/n]
@jay: you assume that if there is more than one matching remote the
user is experienced (as they have multiple remotes) enough to know
what to do?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] Teach 'rebase -i' the command "amend"
From: Johannes Schindelin @ 2009-10-05 21:26 UTC (permalink / raw)
To: Junio C Hamano
Cc: Anders Melchiorsen, Björn Gustavsson, Sverre Rabbelier, git
In-Reply-To: <7vbpkl8s8x.fsf@alter.siamese.dyndns.org>
Hi,
On Mon, 5 Oct 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> Being in an editor but still not able to fix typos is a nuisance.
> >
> > NAK.
> >
> > Supporting that would be totally out of line with the way rebase -i is
> > supposed to work.
>
> If the rebase insn sheet were richer, and had a way to show the full
> message, like this:
>
> pick 4973aa2 git-pull: dead code removal
> Back when a74b170 (git-pull: disallow implicit merging to detached HEAD,
> 2007-01-15) added this check, $? referred to the error status of reading
> HEAD as a symbolic-ref; but cd67e4d (Teach 'git pull' about --rebase,
> 2007-11-28) moved the command away from where the check is, and nobody
> noticed the breakage. Ever since, $? has always been 0 (tr at the end of
> the pipe to find merge_head never fails) and other case arms were never
> reached.
>
> These days, error_on_no_merge_candidates function is prepared to handle a
> detached HEAD case, which was what the code this patch removes used to
> handle.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
>
> I do not see why we shouldn't allow people to edit any part of the above
> to reword.
>
> I would even understand (but not necessarily agree) if somebody wants to
> give the patch text and let users edit to reapply.
>
> So I do not agree with your "totally out of line" at all.
Are you serious? "rebase -i" was _always_ about showing an edit script,
i.e. to tell Git _what_ you want to do with _which_ commits, identified by
short commit names.
The oneline was _always_ meant as a pure convenience for the user.
This paradigm has been true even to back when "rebase -i" was still called
"edit-patch-series", and that is the reason I claimed that it is totally
out of line. Because it is.
> > Besides, if you already have typos in the commit subject, you _better_
> > check the whole commit message, so: double NAK.
>
> That sounds a bit too dogmatic.
>
> But I tend to agree with you that we would be better off not accepting
> such a "retitle" patch, as it strongly encourages single-liner commit log
> messages.
Now, that is at least as dogmatic as what I proposed.
> Oh, there was no patch? Then nevermind...
Sorry, but I changed my mind on this attitude. Earlier, you would find me
valuing arguments only when backed up by code. But since the GitTogether
in Berlin I know of at least one discussion where somebody simply had not
enough time to back up a (submodule-related) argument, the validity of the
argument notwithstanding.
So not always is a "no patch? Nevermind" the correct thing to do.
In this particular case, however, I agree. Just touching up the first
line of commit messages is such a special case, and so removed from what a
"rebase" is about that I would claim that this case would be better
handled by a really trivial shell script that launches an editor and then
drives filter-branch based on what the user said.
Ciao,
Dscho
^ permalink raw reply
* Re: previous references
From: Sverre Rabbelier @ 2009-10-05 21:20 UTC (permalink / raw)
To: Daniele Segato; +Cc: Johan Herland, Octavian Râşniţă, git
In-Reply-To: <1254777067.26111.105.camel@localhost>
Heya,
On Mon, Oct 5, 2009 at 23:11, Daniele Segato <daniele.bilug@gmail.com> wrote:
> fatal: ambiguous argument 'HEAD^2': unknown revision or path not in the
> working tree.
> Use '--' to separate paths from revisions
Really? That's awful, shouldn't we at least say something about HEAD
not having that many parents?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Johannes Schindelin @ 2009-10-05 21:17 UTC (permalink / raw)
To: Jay Soffian; +Cc: git
In-Reply-To: <1254775583-49452-1-git-send-email-jaysoffian@gmail.com>
Hi,
On Mon, 5 Oct 2009, Jay Soffian wrote:
> A user who has just cloned a remote repository and wishes to then work on a
> branch other than master may not realize they first need to create the local
> branch. e.g.:
>
> $ git clone git://git.kernel.org/pub/scm/git/git.git
> $ cd git
> $ git checkout next
> error: pathspec 'next' did not match any file(s) known to git.
>
> This commit teaches git to make a suggestion to the user:
>
> $ git clone git://git.kernel.org/pub/scm/git/git.git
> $ cd git
> $ git checkout next
> error: pathspec 'next' did not match any file(s) known to git.
> To create a local branch from the same named remote branch, use
> git checkout -b next origin/next
>
> Motivated by http://article.gmane.org/gmane.comp.version-control.git/129528
Actually, we should really think long and hard why we should not
automatically check out the local branch "next" in that case. I mean,
really long and hard, and making sure to take user-friendliness into
account at least as much as simplicity of implementation.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Teach 'rebase -i' the command "amend"
From: Sverre Rabbelier @ 2009-10-05 21:13 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Anders Melchiorsen, Björn Gustavsson,
git
In-Reply-To: <7vbpkl8s8x.fsf@alter.siamese.dyndns.org>
Heya,
2009/10/5 Junio C Hamano <gitster@pobox.com>:
> If the rebase insn sheet were richer, and had a way to show the full
> message, like this:
But that's not what rebase -i's insn sheet is about is it? It's not
"rewrite my commits so that they are the way I want them", it's about
"change the order of my commits"/squash some/drop some. The polishing
of the commits itself is done after finishing the insn sheet.
> I do not see why we shouldn't allow people to edit any part of the above
> to reword.
Because it then becomes very hard to do any actual reordering. I'm not
saying it's a bad idea, just that it's a bad idea to do it in 'git
rebase -i', conceptually. Although what you suggest would be useful to
me, I just think it should be a different command, git rewrite perhaps
:P. Definitely not "git rebase -i --rewrite-message" though, becaue it
is not at all about rebasing anymore.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: previous references
From: Daniele Segato @ 2009-10-05 21:11 UTC (permalink / raw)
To: Johan Herland; +Cc: Octavian Râşniţă, git
In-Reply-To: <200910041127.29588.johan@herland.net>
Il giorno dom, 04/10/2009 alle 11.27 +0200, Johan Herland ha scritto:
> On Sunday 04 October 2009, Octavian Râşniţă wrote:
> > Are the following commands specifying the same reference?
> >
> > prompt> git log -1 HEAD^^^ ... log entry ...
> > prompt> git log -1 HEAD^~2 ... log entry ...
> > prompt> git log -1 HEAD~1^^ ... log entry ...
> > prompt> git log -1 HEAD~3 ... log entry ...
>
> Yes
the ~ is used to select the first parent of a commit and their
grand-parents
HEAD~ means the parent of the current head
HEAD~2 means the grand-parent
HEAD~3 the grand-grand-parent..
the ^ is used to select a direct parent of a commit
HEAD^ is the same as HEAD~
HEAD^^ is the same as HEAD~2 (parent of the parent)
HEAD^2 is NOT the same of HEAD~2, it means the "second parent" of HEAD:
this make sense only if HEAD has at least two parents (because it is a
merge commit) if it hasn't you'll get:
fatal: ambiguous argument 'HEAD^2': unknown revision or path not in the
working tree.
Use '--' to separate paths from revisions
you can read the same here: http://progit.org/book/ch6-1.html
regards,
Daniele
^ permalink raw reply
* Re: [PATCH] Teach 'rebase -i' the command "amend"
From: Junio C Hamano @ 2009-10-05 21:07 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Anders Melchiorsen, Björn Gustavsson, Sverre Rabbelier, git,
gitster
In-Reply-To: <alpine.DEB.1.00.0910052248500.4985@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> Being in an editor but still not able to fix typos is a nuisance.
>
> NAK.
>
> Supporting that would be totally out of line with the way rebase -i is
> supposed to work.
If the rebase insn sheet were richer, and had a way to show the full
message, like this:
pick 4973aa2 git-pull: dead code removal
Back when a74b170 (git-pull: disallow implicit merging to detached HEAD,
2007-01-15) added this check, $? referred to the error status of reading
HEAD as a symbolic-ref; but cd67e4d (Teach 'git pull' about --rebase,
2007-11-28) moved the command away from where the check is, and nobody
noticed the breakage. Ever since, $? has always been 0 (tr at the end of
the pipe to find merge_head never fails) and other case arms were never
reached.
These days, error_on_no_merge_candidates function is prepared to handle a
detached HEAD case, which was what the code this patch removes used to
handle.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
I do not see why we shouldn't allow people to edit any part of the above
to reword.
I would even understand (but not necessarily agree) if somebody wants to
give the patch text and let users edit to reapply.
So I do not agree with your "totally out of line" at all.
> Besides, if you already have typos in the commit subject, you _better_
> check the whole commit message, so: double NAK.
That sounds a bit too dogmatic.
But I tend to agree with you that we would be better off not accepting
such a "retitle" patch, as it strongly encourages single-liner commit log
messages.
Oh, there was no patch? Then nevermind...
^ permalink raw reply
* Re: [PATCH] Add the --submodule-summary option to the diff option family
From: Johannes Schindelin @ 2009-10-05 21:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jens Lehmann
In-Reply-To: <7vr5thacb4.fsf@alter.siamese.dyndns.org>
Hi,
On Mon, 5 Oct 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> > + if (prepare_revision_walk(&rev))
> >> > + message = "(revision walker failed)";
> >>
> >> If prepare_revision_walk() failed for whatever reason, can we trust
> >> fast_forward/fast_backward at this point?
> >
> > No, but it is not used in that case, either, because message is not NULL
> > anymore.
>
> It is used in that case a few lines below to decide if you add the third
> dot. That's why I asked.
Well, fair enough.
The answer is: yes, we can still trust fast_forward/fast_backward, as
there is no question that if the first merge base (which must be the only
merge base by definition, in this case) is either "left" or "right", it is
fast_forward or fast_backward, respectively.
So: no worries.
> > I have no idea why "submodule --summary" uses --first-parent, but
> > personally, I would _hate_ it not to see the merged commits in the
> > diff.
> >
> > For a summary, you might get away with seeing
> >
> > > Merge bla
> > > Merge blub
> > > Merge this
> > > Merge that
> >
> > but in a diff that does not cut it at all.
>
> As long as bla/blub/this/that are descriptive enough, I do not see at all
> why you think "summary" is Ok and "diff" is not. If your response were
> "it is just a matter of taste; to some people (or project) --first-parent
> is useful and for others it is not", I would understand it, and it would
> make sense to use (or not use) --first-parent consistently between this
> codepath and "submodule --summary", though.
You may be used to git.git's quality of naming the branches you merge.
Sadly, this is not the common case.
> > In any case, just to safe-guard against sick minds, I can add a check that
> > says that left, right, and all the merge bases _cannot_ have any flags
> > set, otherwise we output "(you should visit a psychiatrist)" or some such.
>
> I wouldn't suggest adding such a kludge. Being insulting to the user when
> we hit a corner case _we_ cannot handle does not help anybody, does it?
Well, I was a little exasperated when I wrote that that you want to handle
that case.
But of course, I should heed Postel's law, and handle the case. Maybe say
something like "(uses superproject's commits)".
> I see two saner options. Doing this list walking in a subprocess so that
> you wouldn't have to worry about object flags at all in this case would
> certainly be easier; the other option obviously is to have a separate
> object pool ala libgit2, but that would be a much larger change.
The reason why I insist avoiding a subprocess is performance. The same
reason holds for a separate object pool: it would just impede the speed,
AFAICT.
Besides, I vividly remember what happened to a patch I posted to be able
to just clear the current object pool. And I cannot imagine a patch
introducing a second pool to be any less complicated.
If you really want the case I illustrated (that the submodule actually
contains commits that already have been shown in the superproject) to be
handled showing the correct submodule summary (and with --first-parent, I
think you will agree that it is a summary, even if it is embedded in a
diff), I could imagine calling a subprocess (for simplicity reasons) _iff_
left, right, or any of the merge bases has a flag set.
But I really, really, really want to avoid a fork() in the common case. I
do have some users on Windows, and I do have a few submodules in that
project. Having too many fork() calls there would just give Git a bad
reputation. And it has enough of that, it does not need more.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Sverre Rabbelier @ 2009-10-05 21:03 UTC (permalink / raw)
To: Jay Soffian; +Cc: git
In-Reply-To: <1254775583-49452-1-git-send-email-jaysoffian@gmail.com>
Heya,
On Mon, Oct 5, 2009 at 22:46, Jay Soffian <jaysoffian@gmail.com> wrote:
> To create a local branch from the same named remote branch, use
> git checkout -b next origin/next
Since Dscho added the most useful "-t" option to git checkout, why not
suggest that?
$ git checkout -t origin/next # instant win
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Jay Soffian @ 2009-10-05 20:46 UTC (permalink / raw)
To: git; +Cc: Jay Soffian
A user who has just cloned a remote repository and wishes to then work on a
branch other than master may not realize they first need to create the local
branch. e.g.:
$ git clone git://git.kernel.org/pub/scm/git/git.git
$ cd git
$ git checkout next
error: pathspec 'next' did not match any file(s) known to git.
This commit teaches git to make a suggestion to the user:
$ git clone git://git.kernel.org/pub/scm/git/git.git
$ cd git
$ git checkout next
error: pathspec 'next' did not match any file(s) known to git.
To create a local branch from the same named remote branch, use
git checkout -b next origin/next
Motivated by http://article.gmane.org/gmane.comp.version-control.git/129528
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
---
builtin-checkout.c | 43 +++++++++++++++++++++++++++++++++++++++++--
1 files changed, 41 insertions(+), 2 deletions(-)
I dunno, this seems like a lot of code just to make a suggestion to the
user. Is it worth it?
Also, I initially was going to use for_each_remote_ref and compare every
remote ref name to see if it tail matched what the user gave us, but it was
easier to use for_each_remote and build up the remote ref name and then check
for its existence. Not sure if either approach is preferable.
Thoughts/comments?
diff --git a/builtin-checkout.c b/builtin-checkout.c
index d050c37..7f2e215 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -145,6 +145,38 @@ static void fill_mm(const unsigned char *sha1, mmfile_t *mm)
mm->size = size;
}
+struct suggest_new_branch_name_data {
+ const char *name, *found;
+ int matches;
+};
+
+static int suggest_new_branch_name_compare(struct remote *remote, void *priv)
+{
+ struct suggest_new_branch_name_data *data = priv;
+ unsigned char sha1[20];
+ struct strbuf buf = STRBUF_INIT;
+ strbuf_addf(&buf, "refs/remotes/%s/%s", remote->name, data->name);
+ if (resolve_ref(buf.buf, sha1, 1, NULL)) {
+ data->matches++;
+ if (data->found)
+ strbuf_release(&buf);
+ else
+ data->found = strbuf_detach(&buf, NULL);
+ }
+ return 0;
+}
+
+static void suggest_new_branch_name(const char *name)
+{
+ struct suggest_new_branch_name_data data;
+ data.name = name;
+ data.found = NULL;
+ data.matches = 0;
+ for_each_remote(suggest_new_branch_name_compare, &data);
+ if (data.matches == 1)
+ fprintf(stderr, "To create a local branch from the same named remote branch, use\n git checkout -b %s %s\n", name, prettify_refname(data.found));
+}
+
static int checkout_merged(int pos, struct checkout *state)
{
struct cache_entry *ce = active_cache[pos];
@@ -231,8 +263,13 @@ static int checkout_paths(struct tree *source_tree, const char **pathspec,
match_pathspec(pathspec, ce->name, ce_namelen(ce), 0, ps_matched);
}
- if (report_path_error(ps_matched, pathspec, 0))
+ if (report_path_error(ps_matched, pathspec, 0)) {
+ for (pos = 0; pathspec[pos]; pos++)
+ ;
+ if (pos == 1)
+ suggest_new_branch_name(pathspec[0]);
return 1;
+ }
/* Any unmerged paths? */
for (pos = 0; pos < active_nr; pos++) {
@@ -675,8 +712,10 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
arg = "@{-1}";
if (get_sha1(arg, rev)) {
- if (has_dash_dash) /* case (1) */
+ if (has_dash_dash) { /* case (1) */
+ suggest_new_branch_name(arg);
die("invalid reference: %s", arg);
+ }
goto no_reference; /* case (3 -> 2) */
}
--
1.6.4.2
^ permalink raw reply related
* Re: [PATCH] Teach 'rebase -i' the command "amend"
From: Johannes Schindelin @ 2009-10-05 20:50 UTC (permalink / raw)
To: Anders Melchiorsen; +Cc: Björn Gustavsson, Sverre Rabbelier, git, gitster
In-Reply-To: <87ab05r5hg.fsf@dylle.kalibalik.dk>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 624 bytes --]
Hi,
On Mon, 5 Oct 2009, Anders Melchiorsen wrote:
> Björn Gustavsson <bgustavsson@gmail.com> writes:
>
> > Thanks for the comments. "reword" it will be then. I'll send a new patch soon.
>
> If you could also make it possible to edit the commit summary line
> right in the git-rebase-todo buffer, that would be great.
>
> Being in an editor but still not able to fix typos is a nuisance.
NAK.
Supporting that would be totally out of line with the way rebase -i is
supposed to work.
Besides, if you already have typos in the commit subject, you _better_
check the whole commit message, so: double NAK.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add the --submodule-summary option to the diff option family
From: Johannes Schindelin @ 2009-10-05 20:39 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Junio C Hamano, Lars Hjemli, git
In-Reply-To: <4ACA2DBB.5030908@web.de>
Hi,
On Mon, 5 Oct 2009, Jens Lehmann wrote:
> A bug showed up in the tests, deleted submodules were labelled
> "(not checked out)" instead of "(submodule deleted)". This patch
> fixes that.
Good catch, thanks!
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Teach 'rebase -i' the command "reword"
From: Johannes Schindelin @ 2009-10-05 20:38 UTC (permalink / raw)
To: Björn Gustavsson; +Cc: git, gitster
In-Reply-To: <4ACA1BD1.6050905@gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 256 bytes --]
Hi,
On Mon, 5 Oct 2009, Björn Gustavsson wrote:
> Make it easier to edit just the commit message for a commit
> using 'git rebase -i' by introducing the "reword" command.
>
> Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
ACK!
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH] Teach 'rebase -i' the command "amend"
From: Anders Melchiorsen @ 2009-10-05 19:43 UTC (permalink / raw)
To: Björn Gustavsson; +Cc: Sverre Rabbelier, Johannes Schindelin, git, gitster
In-Reply-To: <6672d0160910050910x3a9aa6a3w742c09e7f2f42187@mail.gmail.com>
Björn Gustavsson <bgustavsson@gmail.com> writes:
> Thanks for the comments. "reword" it will be then. I'll send a new patch soon.
If you could also make it possible to edit the commit summary line
right in the git-rebase-todo buffer, that would be great.
Being in an editor but still not able to fix typos is a nuisance.
Cheers,
Anders.
^ permalink raw reply
* Re: Confusing git pull error message
From: Junio C Hamano @ 2009-10-05 19:36 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Johannes Sixt, John Tapsell, Git List
In-Reply-To: <20091005191257.GA24305@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Oct 05, 2009 at 12:08:38PM -0700, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>>
>> > So I think we need something like this. I wasn't able to figure out a
>> > test case to trigger the first code path below, though. It may not be
>> > possible; if we give a refspec on the command line, either it will be a
>> > candidate for merging or, if it does not exist, fetch will barf. So it
>> > may be that we can just collapse it down to a single case.
>>
>> I think you are right.
>
> Nope, I'm not. I figured out one more case that it needs to handle.
> Revised patch coming up in a few minutes.
>
>> By the way, I think the other case arms in the case statement that has the
>> sole caller of this function are never reached, no?
>>
>> Back when you added the check in a74b170 (git-pull: disallow implicit
>> merging to detached HEAD, 2007-01-15), $? referred to the error status of
>> reading HEAD as a symbolic-ref so the check did make sense, but cd67e4d
>> (Teach 'git pull' about --rebase, 2007-11-28) made a stupid mistake that
>> nobody noticed.
>
> Hmm. I'm not sure. I don't see how $? could not be zero, though, because
> the last thing we run is a subshell with sed and tr. But beyond that, we
> actually handle the detached case in error_on_no_merge_candidates
> already. So I think that case statement can simply be collapsed to the
> first case.
>
> -Peff
-- >8 --
Subject: [PATCH] git-pull: dead code removal
Back when a74b170 (git-pull: disallow implicit merging to detached HEAD,
2007-01-15) added this check, $? referred to the error status of reading
HEAD as a symbolic-ref; but cd67e4d (Teach 'git pull' about --rebase,
2007-11-28) moved the command away from where the check is, and nobody
noticed the breakage. Ever since, $? has always been 0 (tr at the end of
the pipe to find merge_head never fails) and other case arms were never
reached.
These days, error_on_no_merge_candidates function is prepared to handle a
detached HEAD case, which was what the code this patch removes used to
handle.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-pull.sh | 9 +--------
1 files changed, 1 insertions(+), 8 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index edf3ce3..66d73eb 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -182,14 +182,7 @@ merge_head=$(sed -e '/ not-for-merge /d' \
case "$merge_head" in
'')
- case $? in
- 0) error_on_no_merge_candidates "$@";;
- 1) echo >&2 "You are not currently on a branch; you must explicitly"
- echo >&2 "specify which branch you wish to merge:"
- echo >&2 " git pull <remote> <branch>"
- exit 1;;
- *) exit $?;;
- esac
+ error_on_no_merge_candidates "$@"
;;
?*' '?*)
if test -z "$orig_head"
--
1.6.5.rc2.77.g2ea4a
^ permalink raw reply related
* Re: Confusing git pull error message
From: Jeff King @ 2009-10-05 19:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, John Tapsell, Git List
In-Reply-To: <20091005191257.GA24305@coredump.intra.peff.net>
On Mon, Oct 05, 2009 at 03:12:57PM -0400, Jeff King wrote:
> > I think you are right.
>
> Nope, I'm not. I figured out one more case that it needs to handle.
> Revised patch coming up in a few minutes.
OK, here it is, which I think covers all of the cases. I also re-wrapped
the text, as I agree with JSixt that it was pretty ugly. I also
re-wrapped some of the existing text, as it gave the very choppy:
Your configuration specifies to merge the ref
'foo' from the remote, but no such ref
was fetched.
It would be really nice to just pipe it through 'fmt', but I suspect
that will create portability problems.
-- >8 --
Subject: [PATCH] pull: improve advice for unconfigured error case
There are several reasons a git-pull invocation might not
have anything marked for merge:
1. We're not on a branch, so there is no branch
configuration.
2. We're on a branch, but there is no configuration for
this branch.
3. We fetched from the configured remote, but the
configured branch to merge didn't get fetched (either
it doesn't exist, or wasn't part of the fetch refspec).
4. We fetched from the non-default remote, but didn't
specify a branch to merge. We can't use the configured
one because it applies to the default remote.
5. We fetched from a specified remote, and a refspec was
given, but it ended up not fetching anything (this is
actually hard to do; if the refspec points to a remote
branch and it doesn't exist, then fetch will fail and
we never make it to this code path. But if you provide
a wildcard refspec like
refs/bogus/*:refs/remotes/origin/*
then you can see this failure).
We have handled (1) and (2) for some time. Recently, commit
a6dbf88 added code to handle case (3).
This patch handles cases (4) and (5), which previously just
fell under other cases, producing a confusing message.
While we're at it, let's rewrap the text for case (3), which
looks terribly ugly as it is.
Signed-off-by: Jeff King <peff@peff.net>
---
git-pull.sh | 16 ++++++++++++----
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index edf3ce3..8b0b6f6 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -90,8 +90,17 @@ error_on_no_merge_candidates () {
curr_branch=${curr_branch#refs/heads/}
upstream=$(git config "branch.$curr_branch.merge")
+ remote=$(git config "branch.$curr_branch.remote")
- if [ -z "$curr_branch" ]; then
+ if [ $# -gt 1 ]; then
+ echo "There are no candidates for merging in the refs that you just fetched."
+ echo "Generally this means that you provided a wildcard refspec which had no"
+ echo "matches on the remote end."
+ elif [ $# -gt 0 ] && [ "$1" != "$remote" ]; then
+ echo "You asked to pull from the remote '$1', but did not specify"
+ echo "a branch to merge. Because this is not the default configured remote"
+ echo "for your current branch, you must specify a branch on the command line."
+ elif [ -z "$curr_branch" ]; then
echo "You are not currently on a branch, so I cannot use any"
echo "'branch.<branchname>.merge' in your configuration file."
echo "Please specify which branch you want to merge on the command"
@@ -116,9 +125,8 @@ error_on_no_merge_candidates () {
echo
echo "See git-config(1) for details."
else
- echo "Your configuration specifies to merge the ref"
- echo "'${upstream#refs/heads/}' from the remote, but no such ref"
- echo "was fetched."
+ echo "Your configuration specifies to merge the ref '${upstream#refs/heads/}' from the"
+ echo "remote, but no such ref was fetched."
fi
exit 1
}
--
1.6.5.rc2.219.g00ca
^ permalink raw reply related
* Re: [PATCH] Speedup bash completion loading
From: Ted Pavlic @ 2009-10-05 19:18 UTC (permalink / raw)
To: Kirill Smelkov; +Cc: Shawn O. Pearce, git
In-Reply-To: <20091005165802.GA24402@tugrik.mns.mnsspb.ru>
> The other possibility is to pregenerate all these lists at git build time, but
> are we going to do it for things under contrib/ ?
IIRC, that's what StGIT does with its completion script. As a
consequence, StGIT completion is substantially faster than git
completion.
--Ted
--
Ted Pavlic <ted@tedpavlic.com>
^ permalink raw reply
* Re: Confusing git pull error message
From: Jeff King @ 2009-10-05 19:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, John Tapsell, Git List
In-Reply-To: <7vljjpacax.fsf@alter.siamese.dyndns.org>
On Mon, Oct 05, 2009 at 12:08:38PM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > So I think we need something like this. I wasn't able to figure out a
> > test case to trigger the first code path below, though. It may not be
> > possible; if we give a refspec on the command line, either it will be a
> > candidate for merging or, if it does not exist, fetch will barf. So it
> > may be that we can just collapse it down to a single case.
>
> I think you are right.
Nope, I'm not. I figured out one more case that it needs to handle.
Revised patch coming up in a few minutes.
> By the way, I think the other case arms in the case statement that has the
> sole caller of this function are never reached, no?
>
> Back when you added the check in a74b170 (git-pull: disallow implicit
> merging to detached HEAD, 2007-01-15), $? referred to the error status of
> reading HEAD as a symbolic-ref so the check did make sense, but cd67e4d
> (Teach 'git pull' about --rebase, 2007-11-28) made a stupid mistake that
> nobody noticed.
Hmm. I'm not sure. I don't see how $? could not be zero, though, because
the last thing we run is a subshell with sed and tr. But beyond that, we
actually handle the detached case in error_on_no_merge_candidates
already. So I think that case statement can simply be collapsed to the
first case.
-Peff
^ 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