From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stephen Warren <swarren@wwwdotorg.org>
Date: Thu, 11 Oct 2012 11:00:20 -0600
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: <5076FB24.1080600@wwwdotorg.org>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On 10/11/2012 01:19 AM, 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.

True, tags can be moved. However, the point wasn't that they're
immutable, but that using them can decouple the pull process from the
commit process. For example, I could:

git checkout -b foo bar
git am
git am
git am
git tag -s tag1 foo
send pull request
not wait for pull to complete
git am
git am
git am
git tag -s tag2 foo
send pull request

So, I can still apply stuff to a branch even in parallel with committing
new stuff. IIRC, the point I was originally responding to above was the
issue that by sending pull requests for somebody to pull a branch, if
you added commits to it before the pull was complete, they'd be pulled
in too. With tags, you can avoid that (or by creating a new branch too,
but anyway)