Hi Phillip, On Tue, 11 Dec 2018, Phillip Wood wrote: > On 11/12/2018 09:56, Johannes Schindelin wrote: > > > On Mon, 10 Dec 2018, Phillip Wood wrote: > > > > > On 09/12/2018 20:31, Johannes Schindelin wrote: > > > > > > > I could imagine, however, that it would make sense for `git add > > > > -p` to imitate that feature more closely: by allowing to stage a > > > > single line and then presenting the current hunk (re-computed) > > > > again. > > > > > > that sounds like it would be quite tedious to stage more than a > > > couple of lines, > > > > It would be. But then, if you want to do anything slightly more > > complicated than staging a hunk or a line, I personally prefer the > > `edit` command *a lot*, as it lets me even split unrelated changes in > > the same line into two commits. > > I was hoping for something simpler than editing patches just to stage a > subset of lines that do not need to be edited. Personally, I found that Git GUI's "Stage selected lines" worked well, even if I could only mark consecutive lines. That might be a valuable simplification in your case, too, to allow either individual lines to be staged, or alternatively a simple start-end range. The trick, of course, is to present the updated hunk after staging the line(s)... That's what makes it so fun to use in Git GUI. > > > and it could be awkward to get it to stage modified lines correctly > > > (While I was writing the feature I tried git gui, I think it is > > > supposed to be able to stage modified lines correctly but I never > > > persuaded it to do it for me. I also tried gitg, tig and hg commit > > > -i but I couldn't get them to do modified lines either) > > > > Git GUI works very reliably for me, but then, I have Git for Windows' > > patched Git GUI at my finger tips (oh how I wish we had a Git GUI > > maintainer again). > > > > It should not be awkward to stage a single modified line at all. > > Essentially, you take the hunk, strip out all `-` and `+` lines except > > the one you want to stage, then stage that with `git apply --cached > > --recount`, and then you simply re-generate that hunk. > > But that involves editing the hunk or have I misunderstood? The aim of > my series was that you'd select the '-' & '+' lines for the modification > and it would stage them properly as a modification so given > > 1 -a > 2 -b > 3 +c > > selecting 1,3 would stage > > -a > +c > b > > not > > -a > b > +c > > (see https://public-inbox.org/git/878ta8vyqe.fsf@xxxxxxxxxxxxxxxxxxx/ > for the background) Why not staging them as line 1 first, then seeing an updated hunk and staging the next one? That's an easier UI to begin with. Ciao, Dscho