Hi, On Sun, Oct 25, 2009 at 06:13:47PM +0200, Sergiu Ivanov wrote: > On Sat, Oct 24, 2009 at 06:51:57AM +0200, [email protected] > wrote: > > On Wed, Sep 30, 2009 at 02:35:14PM +0300, Sergiu Ivanov wrote:
> > > 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. > > > > Either before the merge, so you can test it by moving the existing > > repository to a subdirectory in the hurd/ tree and test it there; or > > directly in the merge process, without an extra commit for the build > > system change alone. Not sure which is better really. > > I think I have an extra argument for the second way: if I create a > separate commit before the merge, things will stop working, Yeah, you are right: you can't adapt the build system of the main Hurd tree before merging in the directory; and you can't merge the directory in without adapting the build system in the main Hurd... I forgot that adapting the build system requires changes in the global tree, not only in the subdirectory in question. > and, as you once said, a commit is a set of changes after which > everything works :-) Indeed. The established term for this is "bisectability" -- I just didn't know it at the time :-) -antrik-
