Re: Git in Outreachy December 2019?

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

 



Jeff King <peff@xxxxxxxx> writes:

> On Tue, Sep 24, 2019 at 04:25:45PM +0200, Johannes Schindelin wrote:
>
>> > I think it could make sense for merge-index to be able to directly run
>> > the merge-one-file code[1]. But I think we'd want to keep its ability to
>> > run an arbitrary script, and for people to call merge-one-file
>> > separately, since right now you can do:
>> >
>> >   git merge-index my-script
>> >
>> > and have "my-script" do some processing of its own, then hand off more
>> > work to merge-one-file.
>> 
>> Oh, sorry, I did not mean to say that we should do away with this at
>> all! Rather, I meant to say that `merge-index` could detect when it was
>> asked to run `git-merge-one-file` and re-route to internal code instead
>> of spawning a process. If any other script/program was specified, it
>> should be spawned off, just like it is done today.
>
> OK, great, then we are completely on the same page. :)

I wondered briefly if we want tospecial case the string
'git-merge-one-file' (iow, teaching merge-index a new option
"--use-builtin-merge-one-file" and update our own use in
git-merge-octopus.sh, git-merge-resolve.sh, etc. would be safer).

But "git merge-index git-merge-one-file" called in the context of
scrpted Porcelain has the directory that has *OUR*
git-merge-one-file as the first element on $PATH, I think, so it may
be perfectly safe to use the "ah, the command name we are asked to
run happens to be git-merge-one-file, so let's use the internal
version instead without spawning" short-cut.




[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