This is the mail archive of the
mailing list for the Archer project.
Re: Proposal to change branch maintenance
- From: Sergio Durigan Junior <sergiodj at redhat dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: Project Archer <archer at sourceware dot org>
- Date: Mon, 18 Feb 2013 08:46:27 -0300
- Subject: Re: Proposal to change branch maintenance
- References: <firstname.lastname@example.org>
On Monday, February 11 2013, Tom Tromey wrote:
> First, going back to something Jan proposed years ago, I think we ought
> to delete truly dead branches. That is, if a branch has been merged
> upstream and is no longer useful, let's just zap it.
> Second, let's change our naming approach for new branches. At the start
> of the project I was largely ignorant of git, so I made some
> obvious-in-retrospect mistakes here.
> I think we should adopt the more git-like "/" separator, and drop the
> "archer" prefix, as it is redundant given the repository.
> So, new branches would be like "tromey/project" rather than the current
> I don't propose renaming existing branches.
IMO it would be better to rename the existing branches so that we "start
fresh", instead of leaving old stuff behind.
> Third, what about adopting a convention for a "README.archer" file in
> the top-level of each branch? This file would explain the branch's
> purpose and would let us bypass the tedious step of updating the wiki
> whenever pushing a new branch.
Fine by me too.
> I think newer git even has some automated thing for documenting
> branches, but unfortunately I think we aren't all on a new-enough git
> yet. We could adopt that when we're ready.
I'd prefer this rather than the README.archer file, but I couldn't find
anything related (except the "--edit-description" option from
git-branch, which apparently doesn't do exactly what you described, as
pointed by others).
I would like to propose another thing: the archer repository should
accept "git push --force". It is annoying having to delete & re-create
the branch you're working on because you're using git-rebase to maintain
a series of patches. Maybe we could talk to Jim about that?