From: Carl Worth <cworth@cworth.org>
To: git@vger.kernel.org
Subject: Re: Difficulties in advertising a new branch to git newbies
Date: Mon, 05 Feb 2007 21:51:19 -0800 [thread overview]
Message-ID: <87y7nbdeaw.wl%cworth@cworth.org> (raw)
In-Reply-To: <87odognuhl.wl%cworth@cworth.org>
[-- Attachment #1: Type: text/plain, Size: 1823 bytes --]
On Tue, 30 Jan 2007 12:13:26 -0800, Carl Worth wrote:
> I'm finding that the instructions I'm having to write are much more
> complicated than I would like them to be. And some of this is due to
> incompatibility between git 1.5 and previous versions.
When I first brought up this thread we had lots of good discussion
about detached head that led to improved (or eliminated) warning
messages, and some good motivation for HEAD reflog.
Meanwhile, there's still a piece of the original problem that was not
addressed:
> git checkout -b build origin/proposed-fix
>
> I really like most of what separate-remotes does. But I don't like
> that branch names no longer resolve the same way they used to. Could
> we fix git to resolve "branch" as "remotes/*/branch" if unique? That
> would allow the old instructions and old habits to continue to work,
> (making the change to separate-remotes much more compatible).
Is there any feedback on the above? I just ran into this problem again
tonight, giving out instructions of "git checkout -b build
proposed-fix" and then bracing myself to have the user complain about
an error of:
git checkout: updating paths is incompatible with switching branches/forcing
Did you intend to checkout 'proposed-fix' which can not be resolved as commit?
To which I'd have to respond, "Oh, you're using a newer git. In your
case use 'git checkout -b build origin/proposed-fix'".
So, could we fix this so that a remote branch name will resolve
without the "origin/" prefix if it is not ambiguous?
I can imagine the resolution rules are already fairly complicated, (I
don't even know what they all are already). But when there is no
ambiguity, and when the behavior would be backwards compatible to git
before separate-remotes, is there any reason this would be a bad idea?
Thanks,
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2007-02-06 5:51 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-30 20:13 Difficulties in advertising a new branch to git newbies Carl Worth
2007-01-30 21:02 ` Jakub Narebski
2007-01-30 21:25 ` Yann Dirson
2007-01-30 21:31 ` Jakub Narebski
2007-01-30 21:32 ` Junio C Hamano
2007-01-30 21:40 ` Jakub Narebski
2007-01-30 22:33 ` Matthias Lederhofer
2007-01-30 22:36 ` Matthias Lederhofer
2007-01-30 23:10 ` Jeff King
2007-01-31 1:34 ` Junio C Hamano
2007-01-31 1:51 ` Nicolas Pitre
2007-01-31 3:22 ` Jeff King
2007-01-31 14:59 ` Nicolas Pitre
2007-01-31 17:07 ` Jeff King
2007-01-31 18:59 ` Nicolas Pitre
2007-01-31 22:53 ` Jeff King
2007-01-31 20:20 ` Junio C Hamano
2007-01-31 22:51 ` Theodore Tso
2007-01-31 23:03 ` Junio C Hamano
2007-01-31 23:18 ` Jakub Narebski
2007-01-31 1:48 ` Nicolas Pitre
2007-01-31 0:10 ` Daniel Barkalow
2007-01-31 1:55 ` Nicolas Pitre
2007-01-31 5:09 ` Daniel Barkalow
2007-01-31 14:31 ` Nicolas Pitre
2007-01-31 14:38 ` J. Bruce Fields
2007-01-31 14:53 ` Jakub Narebski
2007-01-31 15:15 ` Nicolas Pitre
2007-01-31 16:25 ` Daniel Barkalow
2007-01-31 18:25 ` Nicolas Pitre
2007-01-31 13:13 ` Guilhem Bonnefille
2007-01-31 16:06 ` Carl Worth
2007-01-31 16:15 ` Johannes Schindelin
2007-01-31 19:27 ` Santi Béjar
2007-01-31 19:50 ` Carl Worth
2007-02-01 0:20 ` Josef Weidendorfer
2007-02-01 9:02 ` Santi Béjar
2007-02-01 4:12 ` Jakub Narebski
2007-02-06 5:51 ` Carl Worth [this message]
2007-02-06 6:37 ` Junio C Hamano
2007-02-06 7:25 ` Junio C Hamano
2007-02-06 7:31 ` Jeff King
2007-02-06 18:53 ` Carl Worth
2007-02-06 19:14 ` Junio C Hamano
2007-02-06 19:39 ` Carl Worth
2007-02-06 19:58 ` Jakub Narebski
2007-02-06 7:28 ` Jeff King
2007-02-06 7:46 ` Junio C Hamano
2007-02-06 8:12 ` Jeff King
2007-02-06 15:33 ` Nicolas Pitre
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y7nbdeaw.wl%cworth@cworth.org \
--to=cworth@cworth.org \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).