Hi Sandra

On 06/11/2023 22:45, Sandra Snan wrote:

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.

If you run "git status" it will list the files that have conflicts as 
"unmerged". To prevent "git commit" from creating a commit that contains 
conflict markers you can use a pre-commit hook that runs "git diff 
--cached--check". The sample hook that is created by default does this, 
to activate it run

	mv .git/hooks/pre-commit.sample .git/hooks/pre-commit

in the main worktree. You can also run "git config commit.verbose true" 
to make "git commit" show the diff of the changes that will be committed 
below the commit message when you're editing the message.

Best Wishes

Phillip