Re: nsmux: Integration with the Hurd Git Repository

[Sergiu Ivanov]

Hello,

On Tue, Sep 22, 2009 at 01:40:29AM +0200, olafBuddenhagen@gmx.net wrote:
> On Mon, Sep 07, 2009 at 11:00:40PM +0300, Sergiu Ivanov wrote:
>
> > Firstly, as I have already said (and as you have already seen), the
> > majority of my commits to my nsmux repository are very ugly.
> > Everything is on a single branch, the commits are not grouped together
> > by functionality, etc.  I remember someone (either you or Thomas)
> > suggesting to throw away this dirty history and just start doing
> > normal source code management from what I have now.  Is this an
> > option, or should I try to tidy up the repository, or should I leave
> > things as they are?
> 
> Yes: I said that considering the situation, it might be best to throw
> away the existing history, and add the code in a single commit.

OK, this is clear.
 
> Sure, it would be nice if the various changes that happened in the past
> were reflected in the history -- but this would be a lot of work; and I
> don't think it's really worth the effort in this case. The code is still
> rather experimental; and AFAIK nobody ever tested it but yourself. All
> in all, it doesn't seem very likely that we will ever want to track
> regressions in the old commits...

Agreed.
 
> > Another serious issue is that my source code is full of weird stuff:
> > comment lines, improperly formatted comments, etc.  Should I try to
> > correct these?
> 
> Yes, you should definitely clean it up. This can probably happen after
> the merge -- especially if you also clean up the code itself, not only
> comments: in this case, it might indeed become necessary to track
> regressions in the cleanups :-)

OK.  nsmux has wanted to be cleaned up for a long time, I'd say :-)
 
> > If so, how should this go: a clean-up patch or a patch series?
> 
> One patch for each type of cleanup I'd say.

Clear.
 
> > And the last question is about the integration itself: how exactly do
> > I take my nsmux git repository and integrate it into the Hurd git
> > repository?
> 
> I've never done this myself, so I actually don't know for sure. I
> believe that it should be possible to simply do a normal merge. The
> tricky part is that after the merge the stuff needs to be in a
> subdirectory, while in the original repository it was top-level; so
> first it's necessary to move the code. Making the move part of the merge
> commit itself (rather than an extra commit before the merge) might
> require some magic...
> 
> But if we drop the old history, we don't need any of that. Just copy the
> whole directory (dropping the original .git/ ), add it to the index, and
> commit, with something like "initial import of nsmux" as commit message.

I see.  This doesn't sound really hard.
 
> Of course, you also need to adapt the build system somewhere along the
> way...

Which way would be preferred: adapting the build system before the
merge of after the merge?

I'd stand for the ``before the merge'' variant, since the current
``build system'' is actually a one-liner bash script invoking gcc.

Regards,
scolobb