> 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/