Re: pw/add-p-select, was Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux