All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Sandra Snan <sandra.snan@idiomdrottning.org>
Cc: git@vger.kernel.org, Dragan Simic <dsimic@manjaro.org>,
	rsbecker@nexbridge.com
Subject: Re: first-class conflicts?
Date: Mon, 6 Nov 2023 19:50:16 -0500	[thread overview]
Message-ID: <ZUmJyFs7z7wdmLVK@mit.edu> (raw)
In-Reply-To: <Gr..Y5kkszDx87g@idiomdrottning.org>

On Mon, Nov 06, 2023 at 10:45:03PM +0000, Sandra Snan wrote:
> Randall, thank you for that.
> 
> I just have sometimes wish git could be a little more aware of them beyond
> just storing them with ASCII art in the files themselves (and alerting /
> warning when they happen but I often can't properly see those warnings flash
> by so I end up having to search for the conflict markers manually). So if
> conflicts are a thing that *can* happen, it'd be better if vc could know
> about them which would make some of the rebases simpler as in jj. That
> doesn't mean we wanna adopt the jj workflow of deliberately checking in
> conflicts (not even locally), just be able to deal with them better if it
> does happen.

Well, if you miss them, "git status" does show that there are conflicts:

   Unmerged paths:
     (use "git add <file>..." to mark resolution)
           both modified:   version.h

And if you attempt to commit the merge without resolving the
conflicts, git won't let you:

   error: Committing is not possible because you have unmerged files.
   hint: Fix them up in the work tree, and then use 'git add/rm <file>'
   hint: as appropriate to mark resolution and make a commit.

So it's hard to miss the indications of the content conflict, because
if you try to commit without resolving them, it's not a warning, it's
an outright error.

Cheers,

					- Ted

  reply	other threads:[~2023-11-11  0:55 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 [this message]
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
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=ZUmJyFs7z7wdmLVK@mit.edu \
    --to=tytso@mit.edu \
    --cc=dsimic@manjaro.org \
    --cc=git@vger.kernel.org \
    --cc=rsbecker@nexbridge.com \
    --cc=sandra.snan@idiomdrottning.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.