Messages in this thread | | | From | David Woodhouse <> | Subject | Re: Problems using new Linux-2.4 bitkeeper repository. | Date | Sun, 17 Mar 2002 16:23:21 +0000 |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |