"master" branch still invokes build in f17-candidate??

[Josh Boyer]

On Tue, Feb 28, 2012 at 11:18 AM, Richard W.M. Jones <rjones at redhat.com> wrote:
> On Mon, Feb 27, 2012 at 12:14:49PM -0800, Jesse Keating wrote:
>> On 2/27/12 8:37 AM, Tom Lane wrote:
>> >Orion Poplawski<orion at cora.nwra.com>  writes:
>> >>On 02/27/2012 09:09 AM, Tom Lane wrote:
>> >>>WTF?  Do I need to fix this, and if so how?
>> >
>> >>git pull
>> >>(to bring in the f17 branch and mark devel as f18)
>> >
>> >Hmm, that package indeed hadn't had f17 git pull'd yet.  (I had scripted
>> >a git pull in all my package directories after the branch, but I think
>> >that it failed in this one due to uncommitted changes.)
>> >
>> >So you're saying that fedpkg's behavior depends on the existence of
>> >other, un-checked-out, branches in my local repo?  This seems a
>> >tad ... unreliable.  Not to say surprising.
>> >
>> >                     regards, tom lane
>>
>> I was looking for a way to determine the behavior of the master
>> branch (for the sake of dist values) without hitting the network, as
>> that would break git's ability to work offline.  The best I could
>> come up with at the time this code was written was to check and see
>> what other branches existed, and just increment the biggest one by
>> one.  I welcome suggestions for better ways to manage this.
>
> Didn't RHEL-CVS use a file in the local directory called 'branch'(?)

I believe Fedora-CVS had the same.  Except it needed to be updated at branch
time, and fetched from the server across all checkouts.  Makefile.common is
what hid all that and nobody noticed because you had to be on the network to
do anything with CVS anyway.

Doing the same in git would still require a 'git pull' to get the updated file.

josh