Re: Request for adding a simple mechanism to exclude files from Git merge operation

[Sergey Organov <sorganov@gmail.com>]

Hi Elijah,

Elijah Newren <newren@gmail.com> writes:

> Hi Sergey,
>
> On Tue, Jun 23, 2020 at 1:19 PM Sergey Organov <sorganov@gmail.com> wrote:

[...]

>> I don't see how rebases are affected. I only suggested enhancements to
>> the merge-the-procedure, the "git merge" user command. Once merge is
>> finished and result is committed, there is (fortunately) now way for git
>> to know how exactly the resulting content has been achieved.
>
> Sorry, the original email from Tiran wanted to be able to record
> "branch-specific" files and have merge automatically handle them
> differently.  You also alluded to that when you said
>
> """
> As a
> more generic solution, a new syntax for "git merge" to specify what
> merge strategy to apply to what files could be designed, and then
> ability to put that syntax into a file for "git merge" to pick would
> solve the problem of quasi-static configuration problem. Alternatively,
> even more generic .gitignore way of doing things apparently could be
> re-used to some degree by adding support for .gitmerge files.
> """
>
> Once you record the information for which files it applies to, then
> you want it to happen whenever the merge machinery fires, right?

No. I didn't mean it, no way. I wanted only "git merge" to be affected.

> Rebasing, cherry-picking, and reverting are all created via the merge
> machinery (even if they end up recording one parent instead of more).
> Said another way, if merge automatically handles these special files,
> either rebase/cherry-pick/revert also handle the special files
> automatically or you've just created a very inconsistent and weird
> design.

I disagree. The fact that all of the mentioned commands reuse internal
merge implementation is a good thing, but it's irrelevant to the case at
hand. I never merge side-branches with either of
rebase/cherry-pick/revert, so it's only logical to ask for specific
branch-merging functionality only from "git merge".

I don't even want to think for now if it could be useful in
rebase/cherry-pick/revert/whatever, as it's already difficult enough.

As a side note, if anything, in my POV, having both rebase and
cherry-pick in porcelain is an overkill. Effectively, 'rebase' is a
'cherry-pick' on steroids, so adding a --cherry option to 'rebase' seems
to be logical.

>
> If you're disclaiming your last paragraph and saying that this would
> only be a manual operation where the user specifies which files they
> want to specially merge, then a lot of my complaints go away.

Nothing to disclaim, I think. What I thought was that it will affect
things automatically, but only for "git merge". Apparently generic merge
machinery will need support for this, but it will be used only for "git
merge", at least for a start. Alternatively, there could be generic
option that will turn this handling on, and this option will be turned
on by default only for "git merge". I'm not familiar with Git
implementation enough to even try suggest the right way to implement it
though.

> Although...
>
>> Nor do I see why to limit decisions to "ours" vs "theirs". I meant to
>> support arbitrary merge strategies for different files. Generic feature.
>>
>> My thought was: if git at all supports different merge strategies, why
>> not to support different strategies for different files? I don't see any
>> inherent contradiction in adding of such a feature.
>
> If you're interested in re-merging specific files, why not just call
> `git merge-file` to handle each one?  It supports e.g. --ours/--theirs
> (similar to merge's -Xours/-Xtheirs) and could possibly add more if
> there are ones missing.  So, it seems like we already have a command
> for this, even if it's less well known?

merge-file is likely some low-level utility... check... yeah, it is.
Extremely low-level. Three-way merge of 3 /files/. How does it help? How
much error-prone scripting will I need to get to the point of any
suitable result?

To me what you suggest here is basically what I've described as kludgy
way of achieving the goal. I can probably also make merges with
different strategies in 2 different repositories, then copy files
between them. Does it mean I already have all the needed tools to get
the job done?

Please consider the problem: I did a regular merge, and by analysis of
the resulting conflicts I realized I'd need to visit a few tens of files
and resolve conflicts exactly the way -X ours would. Suppose, for
simplicity, that all these files are in some sub-directory <subdir>.

git merge --force -X ours -- <subdir>

would solve this immediately, if it existed. Honestly, I can't even
estimate what would I need to do to achieve it using "git merge-file". I
mean, I guess it's possible, yet I don't believe it's practical.

>> >   * The pathspec limiting is going to be a bug factory for renaming
>> > handling.  (The simplest form of which is just renaming a special path
>> > to a non-special path or vice-versa and modifying both sides of
>> > history.)  Rename handling can already get some pretty hairy corner
>> > cases without dumping more in the mix.  I'd rather have users decide
>> > what to do with paths that switched from being one of the special
>> > "ours" paths to being a normal 3-way-conflict marker path.
>>
>> I admittedly didn't dive into such details, but I didn't suggest to
>> attach any additional attributes to paths either, so there is no need to
>> care about renames, as far as I'm able to see.
>>
>> Apparently you talk about some other feature here that I didn't suggest.
>
> Perhaps your comments on creating a ".gitmerge" file means something
> different than I understood.  If it indeed does not record pathnames,
> then the rename issue goes away (though then I don't understand what
> its purpose is nor the rest of your comments in that paragraph where
> you suggested it).  But if your .gitmerge comments did imply something
> similar to .gitattributes which specified how certain paths were to be
> handled, then renaming issues would certainly arise.

Well, I had no use for .gitattributes, so I didn't even recall they
exist. Maybe it's where needed support could be defined, so that
existing renames handling machinery is simply reused without additional
efforts. Will it work right now if I define custom merge driver that
does "git merge -X ours" and then assign it to the set of files? It'd
still be a kludge, but one that proves the point that such support could
be implemented without much effort.

OTOH, as I already said, my own use-case doesn't need any permanent
configuration, so what I say about it is mostly just thinking aloud. In
particular, the .gitattributes trick above is again too complex to solve
a casual but heavy problem I sometimes have, though I think I'd still
use it lacking better way.

Thanks,
-- Sergey