We need to drop GNU diff

Dev
1

In order to have as few problems as possible for people who install bk, our install package includes a number of tools for people who install bk. One of those in GNU diff in src/gnu/difftutils

This copy of diff is rather old (v2.7) and will cause people trying to package bk headaches. In does have some custom modifications to add special support for ignoring differences on line-ending conditions.

However, bk no longer uses GNU diff internally because we implemented our own diff algorithm to have more control and better alignment in the weave. We do still have a _BK_USE_EXTERNAL_DIFF override int the environment that we use for testing.

We should just remove that diff.

2

I did start down this path once… ob sent me some diffs, I can’t remember
where we left off but I could pick this up again fairly soon.

3

To the various lurkers on this forum. Ideally existing bk users…

So the code changes for this are coming together, but we are trying to decide what to do with the existing ‘bk diff’ command.

Currently bk has that behavior that when your type ‘bk cmd’ and ‘cmd’ is not a command for BitKeeper then it runs ‘cmd’ in the context of the PATH bk uses internally.

example:

$ bk whoami
wscott

(whoami is not a bk command)

Previously ‘bk diff’ would run our modified GNU diff that ships with bk. We also have a ‘bk ndiff’ that runs our internal diff code which is mostly command-line compatible with GNU diff.

So I see 3 options:

  1. do nothing so ‘bk diff file1 file2’ will run the system’s diff on two files
  • most compatible with customers who used ‘bk diff’ as a diff
  1. alias diff to ndiff, so it will run our internal diff and generate similar output
  • most compatible with our internal code that expected --ignore-trailing-cr that we added
  1. alias diff to diffs
  • least surprising to new users who expect ‘bk diff’ to actually compare files to the revision history.
  • might break stuff for existing customers who might have used the previous behavior over the last 15 years.

I am leaning towards #3 but don’t want to cause compatibility issues.

4

fyi, I’m feature-creeping this work to also jettison our copy of gnu patch.

5

What do people think?

  • ‘bk diff’ should call the system’s diff command
  • ‘bk diff’ should call bk’s internal diff command
  • ‘bk diff’ should alias ‘bk diffs’ and compare a file to the revision history

0 voters

Show results
6

A little blurb describing why BK has an internal diff command (ie what problem(s) are(were) solved) might be useful. Else why would anybody outside of BK staff vote for the internal diff command?

7

FYI, we have settled on having ‘bk diff’ be an alias for ‘bk diffs’ and in fact ‘bk diff’ will be the preferred/documented usage.

This will probably be released as bk-7.3 to indicate the minor incompatibility change.