Hi Dscho
On 21/01/2019 20:58, Johannes Schindelin wrote:
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.
If you stage line 1 first then the hunk would look like
1 -b
2 +c
If you then select line 2 you end up with
b
+c
Which is not what you want if you're trying to stage the modified line a
-> c. git-gui has some magic to get around this [1] but I found it hard
to use when I tried it out a while ago - I think you have to stage the
lines in a particular order for it to work.
[1]
https://repo.or.cz/git-gui.git/commit/c7f7457026dc2f6979842f81cc17098579fec8d8
Best Wishes
Phillip
Ciao,
Dscho
