Question regarding dist-git aesthetics with branches

[Jesse Keating]

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

On 7/16/10 5:07 PM, Jesse Keating wrote:
> I've been struggling with a particular wrinkle in dist-git, how fedpkg
> is supposed to reliably discover what Fedora release a packager is
> working on.
> 
> In the CVS world, we used a "branch" file.  This is OK, but I think it
> would be cleaner if we didn't have to rely upon that.  It's the last
> file that wouldn't be exact across all the Fedora releases if a package
> is kept in sync.  So what I'd like to do is rely upon discovering the
> top level upstream branch, say F-13.  This gets difficult if we allow
> maintainers to create and operate on their own upstream branches (which
> we should), as I have not found a reliable way to work from a local
> branch to which remote branch it tracks to which top level remote branch
> it was created from.
> 
> One suggestion has been to make use of directory based branching, so
> that any maintainer created branch is in a subdir of a top level branch.
>  EG we'd a user could create an F-13/kernel-2.7 branch, and call it
> whatever they want locally.  fedpkg would be able to work from the local
> branch name to what it tracks (origin/F-13/kernel-2.7) and walk down the
> path from origin/ to discover F-13.  Then fedpkg can assume F-13 for the
> branch and do all the dist conversions and koji target discovery from
> that.  This doesn't put too much restraint on what maintainers call
> their branches, particularly locally.
> 
> The wrinkle with the above though is the base top level branch.  When we
> do this with directories, it's not possible to have a simple origin/F-13
> branch that a user could interact with ("git checkout F-13" would
> automatically detect that there is an origin/F-13 remote branch and
> setup a local F-13 branch to track it" and still allow for an
> F-13/foobar branch.  So we have to make the first base upstream branch
> F-13/<something>.  One suggested <something> has been to call it "HEAD",
> because git seems to have another short cut that would allow you to do
> "git checkout -b origin/F-13" and since it finds an origin/F-13/HEAD it
> will automatically use that.  HEAD seems to be a special name in this
> context.  However it is pointed out that using HEAD here could be
> confusing to people who are more familiar with git and naming
> conventions.  Another suggestion is to call it F-13/master since
> "master" is a more appropriate and expected name.  However that means
> you can't use the short cut and have to do a full "git checkout -b F-13
> origin/F-13/master".  Since you have to use the full path here, we
> aren't bound by the name "master" and we could name it anything we want,
> something that might make sense to Fedora or dist-git.
> 
> Now, these are fairly low details which can be hidden behind fedpkg
> (there is a proposed patch to give fedpkg a 'switch-branch' command that
> will switch you from one to the other, and we can make calls to "F-13"
> attempt origin/F-13/master or whatever), but I feel that this is a
> detail I shouldn't just decide on my own.  So, I welcome the discussion.
>  I also welcome anybody challenging the above assumptions and showing us
> an even better way of managing the branch naming and discovering client
> side what Fedora target a maintainer wishes to work against.  I will
> however put some constraints on that.  A maintainer shouldn't have to
> modify anything in their local clone to indicate what target, fedpkg
> should be able to do a clone of a repo, switch to a branch (which may be
> a branch of a branch of a branch) and be able to discover what the
> target should be.
> 
> Thanks!
> 

Seriously?  Nobody has an opinion here?  Or will this just be another
case of "ZOMG WHY DID YOU DO THIS STUPID THING" as soon as it rolls out...

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxEzSsACgkQ4v2HLvE71NUemwCcDatkXaTQV1+2Kji7AwtATWkO
dmYAoJaZMAkUY5lLWhIsDqa7moXyymKp
=K2b5
-----END PGP SIGNATURE-----