Filter to only include hunks?

[ErichDonGubler]

First: congrats on the release, and props for creatively putting together the pieces that make this work!

Anyway: It'd be really neat if this could be used as an alternative to the default pager in Git -- this is REALLY nice-looking, and I'd love to use this as a pager. Would you be open to a PR or implementing yourself a feature to filter out everything that's not a hunk in a diff? I'm not sure if this should be a special way to process diff/patch files or just integrated with libgit2 directly -- the latter is probably easier, since you're already using libgit2 as a dependency.

[sharkdp]

Thank you for the feedback!

Nice idea! I actually was on a similar track here: #12 (see --context option).

Would you be open to a PR

Definitely! However, maybe it would be worth to first discuss some details here in this ticket?

For example, how would the command line interface (subcommand, option/flag) for that feature look like?

I'm not sure if this should be a special way to process diff/patch files or just integrated with libgit2 directly -- the latter is probably easier, since you're already using libgit2 as a dependency.

Yes, libgit2 sounds like the better option to me.

[ErichDonGubler]

I think that at this point a single flag or subcommand would be appropriate -- the assumption with a libgit2-based diff is that you're operating inside of a Git repository.

Requirements I'm confident should be part of this

This flag/subcommand (hereafter referred to as diff, which is definitely subject to bikeshedding):

• will fail the entire command if not inside of a Git repo
• should take a reasonable subset of options that map to common git diff invocations; some example invocations might be:
  • bat diff would display all unstaged changes, minus untracked files (a la git diff)
  • bat diff cached would display all staged changes (a la git diff --cached)
    • Alternative invocations for this use case could look like bat --diff --cached

Unresolved questions

• Should this be a subcommand or a flag?

  • Flags would be unambiguous, but a subcommand might look more ergonomic (git-esque, in this case).
  • If a subcommand is desired, then maybe the following design would work:
    • bat print or some similar subcommand would be the default when only file paths are provided. For instance, given the following file structure: foo:

      $ tree
      .
      ├── diff
      ├── foo.txt
      └── print
      

        ...then:
      

      • bat foo.txt would be equivalent to today's functionality, inferred to be bat [print] foo.txt.
      • bat print would be ambiguous and return an error reporting that a file and a subcommand exist with that name. This can be resolved by using bat print print. This case could also just print a warning to stderr, since in this case the intent to print a file is NOT ambiguous.
      • bat diff would likewise report an ambiguity, as with print. This would have to be a hard error, and resolved with either bat print diff or bat diff --, depending on the intended subcommand.
    • Alternatively, bat <file> shorthand could simply be removed and get rid of the ambiguous cases in the above design.

• Should bat diff be a filter of the format we get from bat print, or more of a diff pager?

  • The difference is that a filter would only show diff number column marks, while a diff pager would actually show the deleted/added lines a la git diff.
  • IIUC, treating this flag as a filter more closely matches the spirit of the --context idea in the issue you linked.

[sharkdp]

@ErichDonGubler Thank you very much for writing this up! It might take me a few days before I get back to you on this.

[sharkdp]

What I don't really like about adding a diff subcommand (or option) is that we open up a completely new field with that functionality. While we are not truly following the UNIX "do one thing and do it well" philosophy with bat, it is mainly a program that is intended to display file contents.

So here is a slightly different proposal that I would like to discuss:

• Add a --diff-context=<lines> option (didn't come up with a better name for now), which, when enabled, would only show <lines> lines of context around modified parts of the specified files (the default would be "--diff-context=infinite").
• Write a tool to provide git diff-like functionality. This could be as simple as

  git diff --name-only | xargs bat --diff-context=3

Edit: changed --hunk-context to --diff-context

[ErichDonGubler]

Your first bullet point sounds like a waaay-streamlined version of what I just proposed. I would definitely choose that over what I suggested. :)

I would also vote for only doing the first bullet point as a first iteration -- I'd be happy with that, and I don't know how straightforward it would be to highlight things without the full file.

[bendem]

Since we are speaking about this and it's being considered, is there any plan for also supporting diff-highlight type of highlighting?

[sharkdp]

@bendem Could you elaborate what that means?

[sharkdp]

I think my proposal above should be rather straightforward to implement.

I think we should first (possibly in a separate PR) update the --line-range option to be accepted multiple times.

In a second step, we would then use the Git modifications and the value given in the --diff-context option to generate a list of line-ranges that could be processed by the already existing line-range functionality

[bendem]

@bendem Could you elaborate what that means?

I mean that git supports highlighting inside of lines, which I don't think bat does yet. That would be an awesome feature to have.

diff-highlight

no diff-highlight

[sharkdp]

@bendem Thank you for your feedback. This is not really related to this ticket. I don't currently plan to implement inline-diffs and I think that would be quite a substantial feature. If you think this should be discussed, please open a new ticket.

[sharkdp]

I think we should first (possibly in a separate PR) update the --line-range option to be accepted multiple times.

That first part has been implemented in #368

[fdcds]

@ErichDonGubler: Are you aware of https://github.com/dandavison/delta, which implements a pager for git diffs?

[sharkdp]

We are aware of delta. That's why we added it to the README.

[sharkdp]

It's been almost two years, but I finally found the time to implement this. See #940 for details and screenshot.

[ErichDonGubler]

@sharkdp: Not enough emojis to express my excitement. :)

[Mouvedia]

@sharkdp can you publish a new release?

[sharkdp]

Released in v0.15.0.