3

When running git add --patch, it presents a series of "hunks" that can be applied or skipped with y or n respectively, along with other options for editing/etc.

On occasion, when working with a lot of files, I have unintentionally marked n to the last, or only, hunk in a file that I actually intended to mark y or e, resulting in me moving on to the next file. In such a case, is there any way when using the patch editor for me to move back 1 hunk to the previous file?

I know that there is a g option to go to a specific hunk within the same file, but I'm unsure how to arbitrarily move back 1 hunk if the hunk came from a previous file. Is there a way to just go "back" one hunk?

My options in such a case appear to be either to add -p all changes again (bad, since there may be a lot of files, with a lot of hunks that need to be skipped), or take note of the individual file that I messed up on and patch-add the single file alone (which may also have many hunks needed to be skipped again).

Human-Compiler
  • 11,022
  • 1
  • 32
  • 59
  • I don't think there is. The program that does this `add -p` trick is written in Perl, though—at least for the moment—so you can just hack on it yourself. Perl programs are interpreted so there's no need for any fancy compilation steps. The Git folks are doing a rewrite in C though, after which it will be much harder to fix this. – torek Sep 16 '21 at 21:39
  • Yah, for this use one of the editor plugins, fugitive (also I expect magit) makes this kind of thing go almost unbelievably fast. – jthill Sep 17 '21 at 02:20
  • It really could be a case where a decent GUI could be a better choice. – matt Sep 17 '21 at 02:45
  • 1
    there is a basic gui, that comes with git, that allows you to view your staged vs worktree version of your files, and to stage/unstage changes line by line : `git gui`. – LeGEC Sep 17 '21 at 14:14
  • However : if you end up looking for intricate ways to edit *patches* instead of *files*, this is a signal that maybe you'd be better off putting your changes away (`git stash -k`, or `cp thatfile thatfile.mine && git checkout thatfile`), and write the content you expect to stage in said files. – LeGEC Sep 17 '21 at 14:18
  • @LeGEC `git gui` looks like a good answer to me, I never did more than glance at it but it does what OPs asking for (except for the "using the patch editor" part). – jthill Sep 17 '21 at 17:24

1 Answers1

2

As suggested in the coment, if you need something more interactive, go for a gui tool.

git comes together with a basic gui tool, which you can invoke with git gui, and which allows you to :

  • view unstaged and staged files (list them, and view their content),
  • select lines within the existing patches (individual lines or blocks of lines) and stage them or unstage them,
  • along with a few other actions, like commiting (with or without amend) or stashing.

I don't know very much the other GUI tools, but I'm certain some of them offer good interfaces to run the equivalent of git add -p.

As a general remark : if you find yourself looking for refined ways of adding parts of patches and seeking how to edit diff chunks inline, perhaps it my be worth asking yourself if what you want isn't :

  • edit the file to the content you want, and stage that

git add -p is certainly a convenient way to select only regions of a file, but it is also a way to create commits you have never tested, because the staged content was never the exact content you had on disk.

LeGEC
  • 46,477
  • 5
  • 57
  • 104
  • 1
    I'm not sure where your closing remark is coming from; I never said I was using it to edit patches to be something unlike they appear on disk. I use patch-adding to stage specific changes so that commits can be semantically correct and detail only the atomic changes that they represent. Sometimes it's just necessary to either ditch or edit to ignore some things such as whitespace changes made by the editor that is unnecessary and will otherwise attribute line changes to me in the history that are not needed in practice. – Human-Compiler Sep 18 '21 at 04:34
  • you're right : `git add -p` *is* a useful tool, and sometimes splitting a changeset into smaller commits is definitely the "right" thing to do. I had situations like [this one](https://stackoverflow.com/questions/62896307) in mind, where obviously, the result of the actions on the applied patch will lead to an incorrect content (in that other question : although the intention of the coder would be clear, `package.json` wouldn't be a correct json file). – LeGEC Sep 18 '21 at 07:36