13

We have a project where the files contain unfortunately long lines, with no possibility of shortening them. We could streamline our workflow significantly if we could use git checkout --patch also with such files. This does not work since if there is any change in the whole huge line, the line gets flagged as changed.

Usually, we inspect such changes using git diff --word-diff. Is there a possibility to make checkout --patch work with similar format? Are there any other means to work around our problem?

aleator
  • 4,436
  • 20
  • 31
  • 1
    Purely out of curiosity, what do these long lines contain? – Bojangles Jan 10 '13 at 08:51
  • 6
    I really, really, hoped no one would ask that :) The long lines contain latex markup written by a teammate who refuses to press enter-key in the middle of a paragraph. (Although this could seem like problem that can be fixed socially, I can assure you that it is easier to handle it as a technical problem..) – aleator Jan 10 '13 at 09:11
  • In which case I apologise for my curiosity `;)`. Although it would be nice to get your teammate to write things properly, a technical solution will likely be easier. – Bojangles Jan 10 '13 at 13:27
  • It might not be a satisfiying answer, but you could try to pass those files to some script, which will automatically break those long lines into shorter ones. – Lord Bo Jan 10 '13 at 15:40
  • «The long lines contain latex markup written by a teammate who refuses to press enter-key in the middle of a paragraph.» Tell him how to use equivalent of `set fo+=at`/`set fo+=t`\* in his favorite editor. This should be perfectly possible to solve technically, but on the other side: make editor break lines for him. // \* (Vim, reformat paragraph to current textwidth (default: 80) as you type.) / (Default, break line automatically on whitespace when it extends current text width; neither is breaking on non-whitespace unless allowed by another option). – ZyX Jan 10 '13 at 17:41
  • @LordBo I thought of that as well. However, this would result in the lines being joined again in the next commit.. – aleator Jan 10 '13 at 18:48
  • @aleator Why? Unlike refusing to press Enter which can be considered laziness, joining lines back is sabotage because it requires effort to make problems for others. – ZyX Jan 10 '13 at 19:07
  • @ZyX You assume a rational person ;) But sneaking fo+=at in his .vimrc seems like a best bet, though it will still produce bit weird line-based diffs as the text gets reflown. Because of that I will let the question stand as it is. Also, using `--word-diff` style patching would be nicer even in case of short lines. – aleator Jan 11 '13 at 05:47
  • you could sneak in a pre-commit hook that linewraps files as he commits them :) and i suppose this is relevant: http://rhodesmill.org/brandon/2012/one-sentence-per-line/ – Eevee Jan 17 '13 at 01:05
  • There is a difference between a diff generated for human consumption (e.g., using `--word-diff` or `--color-words`), versus one intended for use as a patch. When generating & applying patches, Git generally assumes a line-based diff. My guess is that to get the desired behavior, you would have to modify a core Git script, sort of like this answer: http://stackoverflow.com/a/12297461/1207769 – ctrueden Jan 20 '13 at 14:34
  • Actually – what do you use `git checkout --patch` for in the first place? – Chronial Jan 28 '13 at 09:46
  • @Chronial, We use `git checkout --patch` when a person who is not the main author of a specific text does things like proofreading or suggesting edits and the main author needs to pick and choose which to apply. – aleator Jan 29 '13 at 07:33

1 Answers1

4

After some trying around, I got this answer to work and figured out how to use it for your checkout. I made some additional changes to squelch a warning that would sometimes be printed and had to fix the argument parsing to be a bit more flexible. (Since this is originally a plumbing script where the arguments get pre-processed by the git core, this is not necessary in the original version).

You can use this version of the file (raw file for save-link-as convenience) and copy it to somewhere in your PATH, as described in the linked answer. Be sure to also set its executable bit (chmod +x path/to/file) after downloading.

Assuming you named the file git-add--interactive--words as suggested, you can use the following command to define an alias for it:

git config --global alias.cop add--interactive--words --patch=checkout

Now you can do something like:

git cop HEAD~5 to do an interactive checkout of . (current dir) 5 commits ago, or
git cop master -- docs/README to interactively check out docs/README from branch master

You can call the alias anything you want, of course (I chose cop here for 'c'heck'o'ut --'p'atch).

I know this answer is really late so it's possibly not applicable for you anymore, but this question has been on the unanswered list for so long that I just had to figure it out today -- maybe it'll help someone else ;)

Community
  • 1
  • 1
Nevik Rehnel
  • 49,633
  • 6
  • 60
  • 50