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
