From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Cooper Date: Thu, 11 Oct 2012 07:53:24 -0400 Subject: [U-Boot] U-Boot git usage model In-Reply-To: <20121011071922.0EE66203409@gemini.denx.de> References: <1349906538.21493.12@snotra> <5075F48A.2080504@wwwdotorg.org> <20121011071922.0EE66203409@gemini.denx.de> Message-ID: <20121011115324.GL12330@titan.lakedaemon.net> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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.