Messages in this thread | | | From | Junio C Hamano <> | Subject | Re: [PATCH 0/2] [GIT PULL] ktest: A couple of fixes | Date | Tue, 01 May 2012 20:49:58 -0700 |
| |
Linus Torvalds <torvalds@linux-foundation.org> writes:
> 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 ;-)
| |