git-merge-recursive: command not found

[Duane Murphy]

After installing the dev env, I've discovered that git-merge-recursive is not included. 

This makes, rebasing, merging, etc quite difficult.

Suggestions for resolving this problem?

 ...Duane

[Sebastian Schuberth]

git-merge-recursive is not included as a separate executable as it's a
built-in command. That is, use "git merge-recursive" instead. I'm
aware that several scripts have "git-merge-recursive" hard-coded and
thus fail. I always wanted to submit a patch upstream that changes
this, but I never found the time to do so ...

--
Sebastian Schuberth

[Duane Murphy]

Thank you. That is fixable.

Are there other commands with a similar problem? I note there is a list of built-ins in the Makefile.

...Duane

[Sebastian Schuberth]

On Tue, Jul 29, 2014 at 9:55 PM, Duane Murphy <duane....@gmail.com> wrote:

>>> After installing the dev env, I've discovered that git-merge-recursive is
>>> not included.
>>>
>>> This makes, rebasing, merging, etc quite difficult.
>>>
>>> Suggestions for resolving this problem?
>>
>> git-merge-recursive is not included as a separate executable as it's a
>> built-in command. That is, use "git merge-recursive" instead. I'm
>> aware that several scripts have "git-merge-recursive" hard-coded and
>> thus fail. I always wanted to submit a patch upstream that changes
>> this, but I never found the time to do so ...
>
> Thank you. That is fixable.
>
> Are there other commands with a similar problem? I note there is a list of built-ins in the Makefile.

Right, all command listed in the Makefile's BUILT_INS variable are
likely to have the same problem. All of these need to be replaced in
scripts. However, it's not enough to just replace the dash with a
space. E.g. in Perl system() calls the part after the dash needs to
become a new argument. See [1] which I had sent to the list about a
year ago. That patch was a bit incomplete and would have required
reworking, but I was also getting some resistance as Junio explicitly
said that a Git distribution that ships without the builtins would not
be a Git distribution anymore, and not something that he would
endorse. Still I believe it's the right thing for Git for Windows to
get rid of them.

[1] http://markmail.org/message/rsbjugvidaicqh6w

--
Sebastian Schuberth

[Duane Murphy]

I can understand Junio's point. Those scripts are essentially an external API to git. The scripts can be changed, updated, or otherwise adapted as others see fit.

I (kind of) understand the bloat argument due to not having symbolic links (except that disk space is dirt cheap these days).

While Windows does not have symbolic links, what about a script that calls through to git?

e.g.
=== git-merge-recursive ==
#! /bin/sh
git merge-recursive "$@"
=== END ===

Space is cheap (less than a sector :-). Does cost an execution frame. Perhaps performance. Seems to be functional.

Just a thought.
...Duane

[Sebastian Schuberth]

On Wed, Jul 30, 2014 at 2:59 AM, Duane Murphy <duane....@gmail.com> wrote:

> While Windows does not have symbolic links, what about a script that calls through to git?
>
> e.g.
> === git-merge-recursive ==
> #! /bin/sh
> git merge-recursive "$@"
> === END ===
>
> Space is cheap (less than a sector :-). Does cost an execution frame. Perhaps performance. Seems to be functional.

Yeah, someone had proposed that in the past. Back then I didn't like
it so much because I personally really dislike the dashed version of
the commands. However, we still may find us doing this for the sake of
compatibility. More generically, we could do

=== git-merge-recursive ==
#!/bin/sh
git $(basename $0 | cut -d- -f2-) "$@"
=== END ===

That way we would not need to modify the file's contents but just copy
it under different names.

--
Sebastian Schuberth

[Philip Oakley]

From: "Sebastian Schuberth" <sschu...@gmail.com>

Just to say, this sounds an excellent idea that balances the desires of
Junio for his (Git's) backward compatibility and the desires of the team
to clear-out all the dashed forms of git-cmd from the base git
distribution (as per your earlier reference link [1]).

[1] http://markmail.org/message/rsbjugvidaicqh6w

--
Philip
</bikeshedding>

[Colin Bennett]

On Thursday, July 31, 2014 2:17:02 PM UTC-7, Sebastian Schuberth wrote:

#!/bin/sh
git $(basename $0 | cut -d- -f2-) "$@"

That way we would not need to modify the file's contents but just copy
it under different names.

And use `exec git...` instead of just `git...` to save memory otherwise held onto by the parent Bash process .

I suppose we could easily implement a C program "trampoline" to do the same thing as this simple shell script, to avoid one extra Bash invocation.

[Sebastian Schuberth]

On Mon, Oct 20, 2014 at 7:38 PM, Colin Bennett <sky...@gmail.com> wrote:

>> #!/bin/sh
>> git $(basename $0 | cut -d- -f2-) "$@"
>>
>> That way we would not need to modify the file's contents but just copy
>> it under different names.
>
>
> And use `exec git...` instead of just `git...` to save memory otherwise held
> onto by the parent Bash process .
>
> I suppose we could easily implement a C program "trampoline" to do the same
> thing as this simple shell script, to avoid one extra Bash invocation.

The latter is exactly what we're going to do with the MSYS2-based Git
for Windows SDK, see [1], as we already have that "trampoline" in the
form of our git-wrapper [2].

[1] https://github.com/git-for-windows/git/issues/34
[2] https://github.com/msysgit/msysgit/tree/master/src/git-wrapper

--
Sebastian Schuberth