From: Junio C Hamano <gitster@pobox.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: Sandra Snan <sandra.snan@idiomdrottning.org>,
git@vger.kernel.org, Dragan Simic <dsimic@manjaro.org>,
rsbecker@nexbridge.com
Subject: Re: first-class conflicts?
Date: Mon, 13 Nov 2023 08:25:25 +0900 [thread overview]
Message-ID: <xmqqr0kumu56.fsf@gitster.g> (raw)
In-Reply-To: <20231112152143.GD35991@mit.edu> (Theodore Ts'o's message of "Sun, 12 Nov 2023 10:21:43 -0500")
"Theodore Ts'o" <tytso@mit.edu> writes:
> On Sat, Nov 11, 2023 at 10:31:54AM +0900, Junio C Hamano wrote:
>> ...
>> I wonder if it would help users to add a new configuration option
>> for those who want to live safer that tells "commit -a" to leave
>> unmerged paths alone and require the unmerged paths to be added
>> explicitly (which may have to extend to cover things like "add -u"
>> and "add .").
>>
>> Perhaps not. I often find myself doing "git add -u" after resolving
>> conflicts and re-reading the result, without an explicit pathspec.
>
> Maybe the configuration option would also forbit "git add -u" from
> adding diffs with conflict markers unless --force is added?
Historically we left it to pre-commit hooks, but I agree that
protection at the time of "git add" may be more helpful.
I also alluded to being careful about "git add" with an overly vague
pathspec (like "." to add everything addable under the sun), but I
do not think it is possible to define "overly vague" in a way that
satisfies everybody (would "git add \*.h" be still overly vague when
5% of your header files have conflicts in the merge you are
concluding?) and keep the new users safe.
Unless the configuration forbids patterns and say "each and every
individual path must be named to add and resolve conflicted paths",
that is. Come to think of it, that may not be too bad.
> I dunno. I personally wouldn't use it myself, because I've always
> made a point of running "git diff", or "git status", and almost
> always, a command like "make -j16 && make -j16 check" (or an aliased
> equivalent) before commiting a merge.
>
> But that's because I'm a paranoid s.o.b. and in my long career, I've
> learned is that "you can't be paranoid enough", and "hope is not a
> strategy". :-)
Being careful and paranoid is good ;-) I wouldn't use it myself,
either, but the discussion started while trying to allay new users'
worries about recording a half-resolved state by mistake, and in
that context, I think it would have non-empty audiences.
Thanks.
next prev parent reply other threads:[~2023-11-12 23:25 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-06 21:17 first-class conflicts? Sandra Snan
2023-11-06 22:01 ` Dragan Simic
2023-11-06 22:34 ` Sandra Snan
2023-11-06 22:34 ` rsbecker
2023-11-06 22:45 ` Sandra Snan
2023-11-07 0:50 ` Theodore Ts'o
2023-11-11 1:31 ` Junio C Hamano
2023-11-11 7:48 ` Sandra Snan
2023-11-12 15:21 ` Theodore Ts'o
2023-11-12 23:25 ` Junio C Hamano [this message]
2023-11-07 11:23 ` Phillip Wood
2023-11-07 11:24 ` Sandra Snan
2023-11-07 8:16 ` Elijah Newren
2023-11-07 8:21 ` Dragan Simic
2023-11-07 9:16 ` Sandra Snan
2023-11-07 11:49 ` Phillip Wood
2023-11-07 17:38 ` Martin von Zweigbergk
2023-11-08 7:31 ` Elijah Newren
2023-11-08 18:22 ` Martin von Zweigbergk
2023-11-10 21:41 ` Elijah Newren
2023-11-12 7:05 ` Martin von Zweigbergk
2023-11-09 14:50 ` phillip.wood123
2023-11-08 6:31 ` Elijah Newren
2023-11-09 14:45 ` Phillip Wood
2023-11-10 22:57 ` Elijah Newren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqr0kumu56.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=dsimic@manjaro.org \
--cc=git@vger.kernel.org \
--cc=rsbecker@nexbridge.com \
--cc=sandra.snan@idiomdrottning.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).