Hello! On Wed, Nov 04, 2009 at 04:27:12PM +0200, Sergiu Ivanov wrote: > On Thu, Oct 29, 2009 at 07:11:16AM +0100, [email protected] wrote: > > On Sun, Oct 25, 2009 at 06:10:42PM +0200, Sergiu Ivanov wrote: > > > On Sat, Oct 24, 2009 at 06:46:49AM +0200, [email protected] > > > 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
