git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sandra Snan <sandra.snan@idiomdrottning.org>
To: <git@vger.kernel.org>, Dragan Simic <dsimic@manjaro.org>,
	<rsbecker@nexbridge.com>
Subject: Re: RE: first-class conflicts?
Date: Mon, 06 Nov 2023 22:45:03 +0000	[thread overview]
Message-ID: <Gr..Y5kkszDx87g@idiomdrottning.org> (raw)
In-Reply-To: <002901da1101$7d39a420$77acec60$@nexbridge.com>

[-- Attachment #1: Type: text/plain, Size: 1141 bytes --]

Randall, thank you for that.

I did mean of the first type, pure content conflicts (just like the examples 
on that jj page).

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.

I dunno… and I've really appreciated the naysayers so far, helps me sort 
out my thoughts in this. I personally really prefer the vanilla "explicit 
staging" workflow (with magit) over jj, got, gitless etc. I'm more scared 
of overcommitting by mistake than undercommitting. But this one feature 
seemed to me that it might be really good: just having the vc be aware of 
the conflicts it has created.

  reply	other threads:[~2023-11-06 22:45 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 [this message]
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
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=Gr..Y5kkszDx87g@idiomdrottning.org \
    --to=sandra.snan@idiomdrottning.org \
    --cc=dsimic@manjaro.org \
    --cc=git@vger.kernel.org \
    --cc=rsbecker@nexbridge.com \
    /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 NNTP newsgroup(s).