Re: unionmount branches

[Thomas Schwinge]

Hello!

On Wed, Nov 04, 2009 at 04:27:12PM +0200, Sergiu Ivanov wrote:
> On Thu, Oct 29, 2009 at 07:11:16AM +0100, olafBuddenhagen@gmx.net wrote:
> > On Sun, Oct 25, 2009 at 06:10:42PM +0200, Sergiu Ivanov wrote:
> > > On Sat, Oct 24, 2009 at 06:46:49AM +0200, olafBuddenhagen@gmx.net
> > > wrote:
> > > > While I do think that such main a "unionmount" branch is probably a
> > > > good idea, it should contain only the "approved" patches; while
> > > > those still in development would better be placed in true topic
> > > > branches...
> > > 
> > > OK.  I'll stick to this in the future.  Shall I move the yet
> > > not-completely-approved patches away from master-unionmount into
> > > corresponding topic branches?
> > 
> > I think so. However, it's probably better not to change the existing
> > master-unionmount branch, but rather drop it alltogether and create a
> > new one with a different name once you actually start adding the
> > approved patches. Otherwise, people who already checked out the original
> > branch will get in trouble...
> 
> OK, I'll do that.

Don't forget to remove the old master-unionmount branch afterwards: ``git
push savannah :master-unionmount''.

> > (Also, I still don't get the point of the "master-" prefix. This is not
> > CVS, where we needed to remember where the branch comes from, as it was
> > hard to figure it out from history; and it was crucial to know, because
> > merging had to be handled in a strictly controlled manner to work at
> > all...)

Ah, I still remember the pain with merging gnumach-1-branch into the Xen
working branch every now and then...  ;-)

> Frankly speaking, I'm generally inclined to doubt the usefulness of
> this prefix, too.  This is quite fortunate, since I can create a new
> branch ``unionmount'', thus both achieving a better name and creating
> a new branch of approved patches only.

Let me explain: the idea indeed was to construct a history line, but in
an easily, directly-visible way, which I explain on
<http://www.gnu.org/software/hurd/rules/source_repositories.html>.  Of
course you're correct that all this information is contained in the Git
repository itself, but for getting the big picture
(master-viengoos-on-bare-metal is based on master-viengoos is based on
master) I envisioned it to be helpful, especially so in repositories that
contain a number of non-history-sharing branches (like the incubator).
However, if you, the other contributors, disagree that this is useful,
then I surely won't object to dropping that scheme.


Regards,
 Thomas

signature.asc
Description: Digital signature