This is the mail archive of the
mailing list for the GCC project.
Re: Moving to git
- From: Ramana Radhakrishnan <ramana dot gcc at googlemail dot com>
- To: Jason Merrill <jason at redhat dot com>
- Cc: Jeff Law <law at redhat dot com>, "gcc at gnu dot org" <gcc at gnu dot org>, Jakub Jelinek <jakub at redhat dot com>
- Date: Fri, 21 Aug 2015 11:44:37 +0100
- Subject: Re: Moving to git
- Authentication-results: sourceware.org; auth=none
- References: <55D61512 dot 8010002 at redhat dot com> <55D61B23 dot 3000309 at redhat dot com> <55D63403 dot 4000603 at redhat dot com>
- Reply-to: ramrad01 at arm dot com
> Absolutely, a non-fast-forward push is anathema for anything other people
> might be working on. The git repository already prohibits this; people that
> want to push-rebase-push their own branches need to delete the branch before
> pushing again.
On the FSF trunk and the main release branches - I agree this is a
A push-rebase-push development model is possible / may be useful when
the developers collaborating on that branch agree on that model.
git config branch.<branch-name>.rebase true - tells git to rebase
instead of merging when pulling into <branch-name> branch.
In private development branches, instead of creating bazillion
branches and deleting them for ever for something like this - when
trying to maintain a set of patches on top of trunk it's been useful
in the past to allow for a push rebase push style workflow. While
rebasing in this flow, what we also did was to create tags for each of
the rebase points which essentially meant that at any point of time it
was possible to have a linear view of history for everything on that
particular branch. This was useful in cases where we had particularly
long running branches. However when we transitioned to this there was
a bit of pain in that every developer working on those branches needed
to mark the appropriate branches as rebase only.
Given current practice of merging development branches into mainline
being effectively a "rebase" which allows for the linear history on
mainline to be retained, we should document very clearly how git merge
should be used on mainline from development branches.
> There are many opinions about best practices, but I don't think any of them
> are enough better than what we already do to justify a change.
> 'git help workflow' describes how development of git itself works: they have
> "maint", "master" and "next" branches that would roughly correspond to our
> latest release branch, trunk, and next-stage-1-trunk. Having a "next"
> branch could be useful, but I think we deliberately don't have one currently
> in order to focus people on release preparation during stage 3 rather than
> it always being stage 1 somewhere.
The "next" name seems to be abused in many tools around git. This
suggestion from git workflow is one, the other use of "next" I've seen
is with gerrit, where "next" refers to a "next" commit that's been put
up for code review.
> One interesting thing that they do is to keep earlier branches merged into
> later branches, so 4.9 into 5, 5 into trunk, trunk into next. This is an
> interesting discipline, but I'm not sure it is of much practical value.
I don't see how that fits with our development model.