Hello, On Tue, Sep 22, 2009 at 01:40:29AM +0200, olafbuddenha...@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
