Carl Worth wrote:
> The things I haven't liked in the above are:
>
> 1. The doubled-up "branch:branch" thing in git-fetch, which
> just plain looks awkward. Yes, it's common for "git pull"
> to fetch something and not store it in any branch, but it
> seems that it could ask for that behavior explicitly and we
> could make "fetch URL branch" act as "fetch URL
> branch:branch".
If youd don't mind fetching more, you can ask just to do "git fetch".
But, currently:
* A parameter <ref> without a colon is equivalent to
<ref>: when pulling/fetching, so it merges <ref> into the current
branch without storing the remote branch anywhere locally
I don't think it would be bad if we changed <ref> to mean <ref>:<ref>
and require <ref>: to pull without storing remote branch anywhere locally;
the problem is that we probably want <ref>:<remote>/<ref>.
An alternative would be to tag a fix, and as to do the following
$ git fetch origin tag proposed-fix
> 2. The "-b build" thing in git-checkout. Worse than just
> looking awkward, this causes a real problem, since my
> git-fetch instructions only work the first time, (if they
> follow them later they're going to run into "branch build
> already exists"). Detached head in 1.5 should help here,
> but see below.
An alternative would be to have some branch used only to bring
working directory to given state, by using "git reset --hard <ref>"
while being on it.
E.g.
$ git checkout build
$ git reset --hard proposed-fix
(assuming that 'build' branch was created earlier).
> 3. The separation between how to clone and how to fetch into
> an existing repository is annoying. What I'd really like to
> do is just publish something like:
>
> git://git.project.org/~cworth/project proposed-fix
>
> and allow users to just cut-and-paste that to commands as
> needed. That is, I think it would be nice if "git fetch" or
> "git clone" could accept the "URL branch" string above and
> just do the right thing with it.
>
[...]
> Also, if I'm willing to assume (or insist) that users have git 1.5 or
> newer, it'd be nice to be able to drop the "-b build" thing thanks to
> the new detached HEAD support. But if I suggest doing just:
>
> git checkout origin/proposed-fix
>
> the user is presented with the following message which is much more
> scary than useful in this situation:
>
> warning: you are not on ANY branch anymore.
> If you meant to create a new branch from the commit, you need -b to
> associate a new branch with the wanted checkout. Example:
> git checkout -b <new_branch_name> origin/proposed-fix
>
> The user is getting warned, getting told they perhaps wanted to do
> something else, and getting told that if so they would need to use a
> different command. But the command I gave does exactly what they
> wanted, and following git's advice here would be a bad idea.
>
> I propose this warning be removed here. Otherwise, I either add text
> to my instructions telling the user to ignore the warning message they
> get, or else I go back to "-b build" and back to all the old problems
> it causes.
I rather leave warning, but (perhaps around 1.5.1) remove the
instructions. RTFM (err... I'm not sure we have one about detached HEAD).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html