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

Re: Git terminology: remote, add, track, stage, etc.

From
Michael Haggerty <mhagger@alum.mit.edu>
Date
Oct 21, 2010, 08:44 UTC
Message-ID
<4CBFFD79.1010808@alum.mit.edu>
In-Reply-To
<m3ocar5fmo.fsf@localhost.localdomain>
On 10/18/2010 11:57 PM, Jakub Narebski wrote:
Show 6 quoted lines
> Well, there is different suggestion: make `git stage`, `git track` and
> `git mark-resolved` to be *specializations* of `git add`, with added
> safety checks: 'git stage' would work only on files known to git /
> under version control already, 'git track' would work only on
> untracked files (and do what 'git add -N' does), and 'git mark-resolved'
> would work only on files which were part of a merge conflict.

I think that is a great idea. The thing that I found most confusing when learning git is that variations on a single command often have very different effects. My pet peeve is the over-versatile "git checkout":

git checkout BRANCH : Check out a branch. This is the functionality that I would expect from a "checkout" command.

git checkout -b NEWBRANCH OLDBRANCH : For me this was unintuitive,
because (IMO) the main effect of the command is to create a new branch.
 (I consider that more significant than the checkout because it has a
persistent effect on the repository.)  Therefore, I would expect this
functionality to be provided by "git branch" (something like "git branch
--checkout NEWBRANCH OLDBRANCH").

git checkout -b NEWBRANCH : This is even more unintuitive, because no content is being checked out at all. This should be written "git branch --checkout NEWBRANCH".

git checkout -- PATH : To me this is again a totally different operation. The other uses of "git checkout" are safe; they don't lose any information. But this usage discards the working copy changes irretrievably. Such a different operation deserves a different command with a "dangerous-sounding" name. I think this functionality should be made more easily accessible via "git reset", as has been suggested elsewhere on this thread. (Unfortunately "git revert" is already taken.)

git checkout BRANCH -- PATH : This is even more perverse. Usually "check out" makes the working copy more similar to a version in the repository. But this command makes it more different.

Michael
-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
Previous: Jakub NarebskiNext: Drew Northup
Message 47 of 59 in “Git terminology: remote, add, track, stage, etc.”
  1. Thore HusfeldtOct 18, 2010
  2. Jonathan NiederOct 18, 2010
  3. reset: accept "git reset <removed file>"Jonathan Nieder, Oct 18, 2010
  4. Junio C HamanoOct 18, 2010
  5. Jonathan NiederOct 19, 2010
  6. Junio C HamanoOct 19, 2010
  7. Jonathan NiederOct 19, 2010
  8. Sverre RabbelierOct 18, 2010
  9. Junio C HamanoOct 19, 2010
  10. Ramkumar RamachandraOct 19, 2010
  11. Jonathan NiederOct 19, 2010
  12. Sverre RabbelierOct 19, 2010
  13. Thore HusfeldtOct 19, 2010
  14. User manual: "You cannot check out these remote-tracking branches"Jonathan Nieder, Oct 19, 2010
  15. Matthieu MoyOct 19, 2010
  16. Nicolas PitreOct 19, 2010
  17. Junio C HamanoOct 19, 2010
  18. 0/4 reset: be more flexible about <rev>Jonathan Nieder, Oct 19, 2010
  19. 1/4 reset -p: accept "git reset -p <tree>"Jonathan Nieder, Oct 19, 2010
  20. 2/4 reset: accept "git reset <tree> <path>"Jonathan Nieder, Oct 19, 2010
  21. 3/4 reset: accept "git reset -- <path>" from unborn branchJonathan Nieder, Oct 19, 2010
  22. 4/4 reset: accept "git reset HEAD <path>" from unborn branchJonathan Nieder, Oct 19, 2010
  23. Junio C HamanoOct 19, 2010
  24. Jonathan NiederOct 19, 2010
  25. Ramkumar RamachandraOct 27, 2010
  26. Drew NorthupOct 27, 2010
  27. Matthieu MoyOct 27, 2010
  28. Ramkumar RamachandraOct 28, 2010
  29. Matthieu MoyOct 28, 2010
  30. Matthieu MoyOct 18, 2010
  31. Miles BaderOct 19, 2010
  32. Wincent ColaiutaOct 19, 2010
  33. Miles BaderOct 19, 2010
  34. Wincent ColaiutaOct 19, 2010
  35. Eugene SajineOct 19, 2010
  36. Paul BolleOct 22, 2010
  37. Eugene SajineOct 22, 2010
  38. Drew NorthupOct 22, 2010
  39. Thore HusfeldtOct 20, 2010
  40. Matthieu MoyOct 20, 2010
  41. Drew NorthupOct 20, 2010
  42. Jakub NarebskiOct 18, 2010
  43. Matthijs KooijmanOct 19, 2010
  44. Jakub NarebskiOct 19, 2010
  45. Thore HusfeldtOct 19, 2010
  46. Jakub NarebskiOct 19, 2010
  47. Michael HaggertyOct 21, 2010
  48. Drew NorthupOct 21, 2010
  49. Thore HusfeldtOct 21, 2010
  50. Drew NorthupOct 21, 2010
  51. Thore HusfeldtOct 21, 2010
  52. Drew NorthupOct 21, 2010
  53. Miles BaderOct 22, 2010
  54. Drew NorthupOct 22, 2010
  55. Porcelain scripts: Rewrite cryptic "needs update" error messageRamkumar Ramachandra, Oct 19, 2010
  56. Ramkumar RamachandraOct 27, 2010
  57. Junio C HamanoNov 5, 2010
  58. Ævar Arnfjörð BjarmasonFeb 12, 2011
  59. Drew NorthupOct 19, 2010

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.