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

Re: [PATCH 0/2] [GIT PULL] ktest: A couple of fixes

From
Junio C Hamano <gitster@pobox.com>
Date
May 2, 2012, 03:49 UTC
Message-ID
<7v62cf6y3d.fsf@alter.siamese.dyndns.org>
In-Reply-To
<CA+55aFy02d13HkfwY-TEGwu=2cd8en+_rnrnwcwixGKRmdJRtA@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
Show 17 quoted lines
> If you do a
>
>   git pull linus v3.4-rc5
>
> in order to just update to the state of my latest tag, then git will
> assume you want to do a new commit (and thus a non-fast-forward) just
> so that git can record the tag signature in the commit.
>
> The sad part is that I don't think you can even override the second
> case.
> ...
> That's inconvenient, and an unintended consequence of the behavior I
> wanted as a top-level maintainer. But I really do think it's wrong for
> normal developers who might validly just want to update to some
> particular tagged release.
>
> Junio? Any ideas?
"Ideas" meaning "recipe to do with deployed binaries"?

When a normal developer wants to _reset to_ a particular tagged release, in order to _start_ new work, she wouldn't be doing even the above "git pull linus v3.4-rc5". That will contaminate the result with whatever random stuff she happened to have on the current branch. A more natural sequence would be "git fetch --tags linus" followed by either

        git checkout v3.4-rc5 ;# to detach
or
        git checkout -b mywork v3.4-rc5 ;# to start
So the case to "reset to" is not very interesting.

But when a normal developer wants to _sync to_ a particular tagged release, in order to _continue_ working on her topic, she would need to have a merge (unless she does not have _anything_ herself), and at that point, merging v3.4-rc5 vs v3.4-rc5^0 would not make that much of a difference. If she absolutely detests the "mergetag" header, she could do a "git fetch --tags linus" followed by

	git merge v3.4-rc5^0
which admittedly is two more letters than she used to type.

If you mean by "Ideas" for additional features, obviously the last step could be enhanced to use a more intuitive command line that requires the user to type even more, i.e.

	git merge --ff v3.4-rc5

Once that is done, "git pull --ff linus v3.4-rc5" would fall out as a logical consequence.

But obviously these two would need new code ;-)
Previous: Stephen RothwellNext: Steven Rostedt
Message 3 of 9 in “Re: [PATCH 0/2] [GIT PULL] ktest: A couple of fixes”
  1. Linus TorvaldsMay 2, 2012
  2. Stephen RothwellMay 2, 2012
  3. Junio C HamanoMay 2, 2012
  4. Steven RostedtMay 2, 2012
  5. Junio C HamanoMay 2, 2012
  6. Steven RostedtMay 3, 2012
  7. Jakub NarebskiMay 3, 2012
  8. Steven RostedtMay 3, 2012
  9. Nguyen Thai Ngoc DuyMay 3, 2012

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.