[lkml]   [2002]   [Mar]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Problems using new Linux-2.4 bitkeeper repository.
Date said:
> Then you get to save them as diffs, unedit the files, and put them
> back after the merge.

I can do better than that. If I save them as diffs, I don't get to use your
cute merge tools. I could commit them with a throwaway changelog, do the
pull and use the merge tools, then copy the resulting files, undo both the
pull and the previous merge, do the pull again and then lock the files and
drop the previously-saved copies into place.

It's a bit contrived though - it would be nice if BK would do something
like that for me instead of just bailing out when files are modified.
Asking me if I'm really sure I want to continue is fine. Aborting
unconditionally less so.

> citool is a tcl program, how about you hack it in? Look for
> $diffsOpts, that's what you'll need to modify. You need to get the
> diffs parsing code to do the right thing with -up style diffs though.

Er, actually I can't get 'bk diffs -up' to give output the same as (GNU)
'diff -up' either. What I was after was stuff like:

@@ -331,6 +331,7 @@ int jffs2_decompress(unsigned char compr

> We don't have this feature. We've talked about it, but that's all
> we've done.

Which? Actually tracking functions that move between files, or the hack in
the merge tool? I appreciate that the former is a _lot_ harder to achieve.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:21    [W:0.081 / U:3.248 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site