On 12/3/2010 18:34, Jesse Keating wrote:
The original thought was to have top level branches that are named
after
distribution releases, eg "f14", "f15", "el5". Then we
would force
branches of those branches use a naming structure of "f14/topic". The
reason was so that our tooling could look at the name of the branch and
easily work back to the "f14" part. This would work even if it was
"f14/user/fred/topic/mybranch" or other such craziness. When I went to
test this, I realized that git won't allow you to have both "f14" and
"f14/topic" as branches, because of the way the git metadata works on
the filesystem. When I encountered this, I made "f14/master" become the
top level branch, and then "f14/somethingelse" could coexist.
Unfortunately I also wanted to keep things easy for users and tried to
maintain tooling that would allow you to just say "f14". This didn't
get enough real world testing and in hindsight was a bad idea. Things
go wrong quickly in git if your local branch name doesn't match the
remote branch name.
When thinking about the above, and the two bugs I'm working on, I
realized that we don't have any real strong need to be using "/" as a
delineator. It makes some code easier, but makes other things more
complex and difficult. So what if we changed it?
What I'm thinking about now is switching from / to - as a delineator.
This would improve a couple things. First, we could achieve upstream
top level branch names that are short and simple: "f14", "f15",
"master". We can have branches that build upon those names:
"f14-rebase", "f15-cve223", "f15-user-jkeating-private".
We could keep
the simple fedpkg tooling that allows users to just type "f14" and the
like to reference a branch, and now the local branch will match the name
of the remote branch.
Yes, please! Getting rid of the '/' strangeness ought to make things a
little easier to understand and use across the board. I suspect that
few enough packages use shared feature or bugfix branches that a
transition won't trip up very many people. Perhaps a hook on Fedora's
repositories that prints transition instructions when one attempts to
push to old-style branches in conjunction with a fedpkg command that
attempts to migrate existing local branches and remotes would help somewhat.
As for the first two bugs I mentioned, it doesn't directly help
them.
However I would feel better about telling people that their local
branches must follow a naming scheme of<release>-<something> and then
we could easily guess what release the local branch is for if it isn't
tracking a remote branch. However the bug about what to do if there are
no remote branches is really not touched by any of this, it just got me
thinking about branches :)
Why tie branch names down to specific releases? While that scheme makes
it easy for fedpkg to guess what release to attempt to build against
when one only cares about one release, it makes little sense to call a
branch "f14-rh123456" when in reality that branch will merge into
"f13"
as well as "f14".