git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Difficulties in advertising a new branch to git newbies

From
Jakub Narebski <jnareb@gmail.com>
Date
Jan 30, 2007, 21:02 UTC
Message-ID
<epobn1$jv8$1@sea.gmane.org>
In-Reply-To
<87odognuhl.wl%cworth@cworth.org>
Carl Worth wrote:
Show 8 quoted lines
> 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
Show 6 quoted lines
>       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).
Show 11 quoted lines
>       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.
> 
[...]
Show 23 quoted lines
> 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
Previous: Carl WorthNext: Yann Dirson
Message 2 of 50 in “Difficulties in advertising a new branch to git newbies”
  1. Carl WorthJan 30, 2007
  2. Jakub NarebskiJan 30, 2007
  3. Yann DirsonJan 30, 2007
  4. Jakub NarebskiJan 30, 2007
  5. Junio C HamanoJan 30, 2007
  6. Jakub NarebskiJan 30, 2007
  7. Matthias LederhoferJan 30, 2007
  8. Matthias LederhoferJan 30, 2007
  9. Jeff KingJan 30, 2007
  10. Junio C HamanoJan 31, 2007
  11. Nicolas PitreJan 31, 2007
  12. Jeff KingJan 31, 2007
  13. Nicolas PitreJan 31, 2007
  14. Jeff KingJan 31, 2007
  15. Nicolas PitreJan 31, 2007
  16. Jeff KingJan 31, 2007
  17. Junio C HamanoJan 31, 2007
  18. Theodore TsoJan 31, 2007
  19. Junio C HamanoJan 31, 2007
  20. Jakub NarebskiJan 31, 2007
  21. Nicolas PitreJan 31, 2007
  22. Daniel BarkalowJan 31, 2007
  23. Nicolas PitreJan 31, 2007
  24. Daniel BarkalowJan 31, 2007
  25. Nicolas PitreJan 31, 2007
  26. J. Bruce FieldsJan 31, 2007
  27. Jakub NarebskiJan 31, 2007
  28. Nicolas PitreJan 31, 2007
  29. Daniel BarkalowJan 31, 2007
  30. Nicolas PitreJan 31, 2007
  31. Guilhem BonnefilleJan 31, 2007
  32. Carl WorthJan 31, 2007
  33. Johannes SchindelinJan 31, 2007
  34. Santi BéjarJan 31, 2007
  35. Carl WorthJan 31, 2007
  36. Josef WeidendorferFeb 1, 2007
  37. Santi BéjarFeb 1, 2007
  38. Jakub NarebskiFeb 1, 2007
  39. Carl WorthFeb 6, 2007
  40. Junio C HamanoFeb 6, 2007
  41. Junio C HamanoFeb 6, 2007
  42. Jeff KingFeb 6, 2007
  43. Carl WorthFeb 6, 2007
  44. Junio C HamanoFeb 6, 2007
  45. Carl WorthFeb 6, 2007
  46. Jakub NarebskiFeb 6, 2007
  47. Jeff KingFeb 6, 2007
  48. Junio C HamanoFeb 6, 2007
  49. Jeff KingFeb 6, 2007
  50. Nicolas PitreFeb 6, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.