Question regarding dist-git aesthetics with branches

Thu Jul 22 19:13:19 UTC 2010

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/22/2010 02:16 AM, Hans Ulrich Niedermann wrote:
> On Wed, 2010-07-21 at 11:48 -0700, Jesse Keating wrote: 
>> On 07/21/2010 01:55 AM, Hans Ulrich Niedermann wrote:
>>> On Tue, 2010-07-20 at 22:15 -0700, Jesse Keating wrote:
>>>> On 07/20/2010 08:55 PM, Garrett Holmstrom wrote:
>>>>> If rawhide development is supposed to happen on origin/master, then how 
>>>>> do branches for rawhide work?  Does fedpkg just default to building for 
>>>>> rawhide when a branch doesn't appear in a release's "branch namespace?"
>>>>
>>>> Yes. Branches of rawhide would be of the form origin/<branch> so if we
>>>> don't find one of our expected f(c)??,el?,olpc? we default to building
>>>> for rawhide.
>>>
>>> I was not aware that rawhide would be basically origin/master. In that
>>> case, it would be really obviously nice to be able to have branches
>>> "master", "f13" and "f12" (without any slashes) in the local repo and
>>> have things "just work" for that case.
>>>
>>> Perhaps fedpkg could support both "simple" clones where the developer's
>>> local repo has just three branches tracking upstream
>>>
>>>      master -> origin/master
>>>      f13    -> origin/f13/master
>>>      f12    -> origin/f12/master
>>>
>>> or for people with more complex needs
>>>
>>>      master     -> origin/master
>>>      f13/master -> origin/f13/master
>>>      f12/master -> origin/f12/master
>>
>> The problem is in inconsistency.  Makes things harder for scripted
>> rebuilds which I'd expect to run on the f13/master branch.
> 
> I would see
> 
>    f13/master -> origin/f13/master
> 
> as much more consistent than
> 
>    f13        -> origin/f13/master
> 
> so your consistency argument would mandate the local repo's branches to
> be structured like
> 
>       master     -> origin/master
>       f13/master -> origin/f13/master
>       f12/master -> origin/f12/master

As I stated in other messages, my concern for consistency only matters
on the remote branch names.  Local branch names can be named whatever
you want, and for me it's easier to type: git checkout f13, then to do
git checkout f13/master (provided the mapping of "f13" to
"origin/f13/master" has already been made, and fedpkg can do that for you)

> 
> or even better simply as
>  
>       master     -> origin/master
>       f13        -> origin/f13
>       f12        -> origin/f12

Can't do that and still have origin/f13/<topicbranch> which is pretty
critical to me being able to determine client side what Fedora release a
local branch is intended for.

> 
>> For the local clone, I was going to have fedpkg call the branches by
>> their base name, so
>>
>> master -> origin/master
>> f13 -> origin/f13/master
>> f12 -> origin/f12/master
> 
> This makes sense for the many occasions where the package maintainer
> local repo has exactly three branches on his system: f12, f13, and
> master. However, why have f13/master and f12/master on origin in the
> first place then? Shouldn't origin/master, origin/f13, and origin/f12
> cover all branches koji ever needs to directly build from?

no, many developers need to be able to additionally branch when they are
working on multiple releases of a package, eg one build is already in
updates-testing, but they are working on the build that will follow
that.  Happens with kernel, kde, etc...

> 
> Also, how would the proposed case of *local* "f13/foo" and "f13/bar"
> branches be handled here? Were we talking about having f13/foo in the
> official repos and building from branches like that?

Yes, we're talking about building directly from f13/foo on the remote side.

> 
> My reading now is that as my local repo already has a "f13" branch upon
> initial clone and I need more that one local branch to build for F13,
> then I must manually rename "f13" to some name like "f13/official" and
> only then can I fork off other f13/* branches. That would also require
> me to especially set up f13/official to be the new branch name to push
> to origin/f13... looks unnecessarily complicated.

You have something of a point here.  If the tool creates a local "f13"
branch for you, you would not be able to create subsequent local
"f13/<something" branches.  For the people needing these types of
branches, I'm not sure this is a concern, in that they may call their
local branches something that doesn't conflict, that's entirely up to them.

> 
>>> Which gives me an idea. What if we had
>>>
>>>      master     -> origin/master
>>>      f13        -> origin/f13
>>>      f12        -> origin/f12
>>>      F13/foo
>>>      F12/bar
>>>
>>> and in addition to that, any local branch named like "F13/*" would be
>>> built for f13? That would give direct 1:1 git repo cloning, with still
>>> making it possible to deduce the target from branch names if so desired
>>> by the packager.
>>
>> hrm, I'm not really in favor of having both "f13" and "F13/foo", that
>> just seems like a recipe for lots of typo disasters.
> 
> It also seems a recipe for allowing the easy per-branch determination of
> the build target from the branch name just as you suggested earlier -
> but it would work both for the directly cloned branches and also for a
> bunch of local branches.  And it would fulfil your requirement to work
> directly after a "git clone" of my local repo, without any additional
> setup.
> 
> 

I already have code to do the above, regardless of your local branch, so
long as the remote branches follow a naming scheme of f??/<something>

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxImE8ACgkQ4v2HLvE71NWxZQCcD4SUPxcYjnfvPCxvOQsDT5TA
0jsAnRRaL2C+40jGxaCARyIIogenBCpZ
=0x5k
-----END PGP SIGNATURE-----