Re: Problems using new Linux-2.4 bitkeeper repository.

[David Woodhouse <dwmw2@infradead.org>]

lm@bitmover.com said:
>  BK works that way on purpose.  If we merge changes into your local
> changes, there is no automatic way to "unmerge".  It is way to easy to
> do a pull, do the merge, and then realize you lost work in the merge
> because you told it to do the wrong thing.

> Short summary: commit your changes before you pull and you'll be fine.

If it was changes that deserved a changelog, I'd have committed them. But 
it's typically one-line hacks to make it compile, which I know will be 
obsoleted by 'correct' fixes in Linus' tree later. I don't want them (and 
the subsequent merges and conflicting new files) cluttering up my tree, 
especially as AFAICT BK won't let me undo the change later if I commit any 
changes after it - even if the later changes are _completely_ unrelated.

Btw, the citool is cute but would be cuter if
 - the diffs were '-up' format - showing the function that the hunk is in.
 - You could select a hunk and say "omit this change from what's committed"

Again, the latter is because some stuff really does live as local hacks in 
a build tree and never deserves the honour of a changelog entry.

Another thing I have a distinct feeling I'm going to want is tracking
functions across files. I sometimes shuffle functions between files for
portability - selective compilation is nicer with your Linux-specific
functions in one file and eCos-specific functions in another than with a
litter of ifdefs. If Linus' tree gets a patch to a file that I moved, BK can
work it out. If Linus' tree gets a patch to a _function_ that I moved to a
different file while leaving the rest of the original file in place, AFAICT
not even the merge tool deals with that nicely. Did I miss an option to
'apply this diff hunk to a different file'?


--
dwmw2