I can't see how bk's difftool could possibly have any relevance to the
"reasonable to stick with CVS" decision, but hey, I'm always surprised by
peoples inventiveness in rationalizing their decisions ;)
I don't know what difftool does that a simple
git diff -U99 | viewdiff -
wouldn't do, but in all honesty, I don't think I ever used difftool (I
found the other tools in bk much more useful - eg mergetool, renametool)
I don't actually know of any sane programs to view unified diffs, but you
can script one with little trouble. Here's a really hacky one I just came
up with:
#!/bin/sh
cat "$@" > /tmp/diff
grep '^[ -]' /tmp/diff > /tmp/orig
grep '^[ +]' /tmp/diff > /tmp/result
meld /tmp/orig /tmp/result
which fools 'meld' into showing a unified diff in a nice graphical manner.
[ Quite frankly, I don't understand why tools like meld and kdiff3 can't
just take the unified diff directly - they have *all* the logic, it
should be trivial to do, and very useful to view diffs for those people
who like that graphical bling. ]
Hmm. Converting from git to bk should not be that hard at least
conceptually, but no, I have no idea how to script it sanely and
efficiently. The obvious solutions all would want to have multiple active
heads of development open at the same time (Larry calls them "LOD's" not
branches), and would also require some way to set the result of a merge.
Neither of which I would know how to do in BK (I created a lot of merges
in BK, but I always let BK do the merging - I wouldn't know how to specify
the merge result by hand).
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html