On Thu, Oct 11, 2012 at 09:19:22AM +0200, Wolfgang Denk wrote:
Dear Stephen Warren,
In message 5075F48A.2080504@wwwdotorg.org you wrote:
I believe that's (part of) why Linux is tending towards pull requests of a (signed) tag rather than a branch, since the tag always points at a specific commit, and incremental pull requests can just create a new tag name. Of course, the ability to sign tags also also a motivator.
I tend to disagree here. Tags can easily be removed. As such, they are in no way different from or better than a specific commit in a branch that does not get rebased.
I agree with Wolfgang, I move signed tags around all the time _before_ I push to a public branch. That tends to happen because I'm still learning the process, *not* as a part of a proper workflow.
For me, signed tags serve two purposes. The first is sub-maintainer verification. Arnd Bergmann and Olof Johansson both signed my gpg key at the last Kernel Summit. So, when they pull a branch, they know I created it. Second, using git v1.7.9 and newer, request-pull will insert the tag message into the body of the pull-request. This provides a nice summary of the branch in the email, as opposed to the branch-name chaos we see now. This summary, stays with the branch regardless of the number of times the maintainer merges it.
I suppose there is a third advantage. The signed tag is attached to a specific sha1 commit. If a maintainer inadvertently changes the commit history of a branch by doing a rebase or similar, the tag would disappear from the tip of the branch. Kind of like the canary in the mine.
Which brings me to another point I haven't seen mentioned in this thread yet, git-rerere (1). Arnd and Olof make extensive use of this command to remember how they have resolved merge conflicts. afaict, since I don't need it at my level, they are continuously merging branches over and over again. Against new branches, new versions of widespread changes (iomem, platform_data in the last window). rerere makes that workload possible.
hth,
Jason.