371–380 of 407 posts
For the conflicts, note that in Git you can do git config --global merge.conflictstyle diff3 to get something like what is shown in the article.
Nearly every time I see a complaint about git, someone comes through with a command like this. Is there a collection of similar tips that makes git better to use? If not, there should be.
[flagged]
> it makes history a lie that eventually collapses under its own weight in large teams Can you please elaborate on this? I've seen this argument from others as well, but nobody has ever been able to articulate what that actually looks like and why rebasing branches specifically is to blame. My perspective: whatever happens to the commit history on your non-`main` branch is your business. I don't care about the specif…
Suppose a file contains a list of unique strings, one by line. A commit on a feature branch adds an element to the list. Later on, the branch is rebased on the main branch and pushed.
But the main branch had added the same element at another position in the list. Since there was a wide gap between the two positions, there was no conflict in Git's rebase. So the commit in the feature branch breaks the unicity constraint of the list.
For someone that pulled the feature branch, the commit seems stupid. But initial commit was fine, and the final (rebased) commit is a lie: nobody created a duplicate item.
I used to think the future of version control was semantic: E.g. I renamed a method, while someone else concurrently added another call to that (now differently named) method. Git doesn't catch this, nor would this new system. The solution seems obvious to a human: Use the new name at the new call-site too. But it requires operating at the level of the semantic meaning of a change, and not just the dumb textual chang…
This is the most common use case for any compiler or linter
Earlier quoted context omitted.
> it makes history a lie that eventually collapses under its own weight in large teams Can you please elaborate on this? I've seen this argument from others as well, but nobody has ever been able to articulate what that actually looks like and why rebasing branches specifically is to blame. My perspective: whatever happens to the commit history on your non-`main` branch is your business. I don't care about the specif…
I'm not the GP, but I've seen "rebase lies" in the wild. Suppose a file contains a list of unique strings, one by line. A commit on a feature branch adds an element to the list. Later on, the branch is rebased on the main branch and pushed. But the main branch had added the same element at another position in the list. Since there was a wide gap between the two positions, there was no conflict in Git's rebase. So the…
Earlier quoted context omitted.
The tooling can force resolution at any step desired.
What's the point of options when there only is one correct answer?
I think it is also not true that there's only one correct answer, although I don't know how valuable this is.
For committing let's say yes, only one correct answer. Say the tool doesn't let you commit after you've merged without resolving conflicts.
But continuing to work locally you may want to put off resolving the conflict temporarily. Like person A changed the support email to help@example.com and person B changed it to support@example.com - obviously some wires go crossed and I will have to talk to A or B before committing the merge and pushing, but I can also go ahead and test the rest of the merge just fine.
And heck, maybe even committing after merging is fine but pushing requires resolving. Then I can continue working and committing locally on whatever else I was working on, and I'll only resolve it if I need to push. Which may mean I never need to resolve it, because A or B resolve it and push first.
[flagged]
> it makes history a lie that eventually collapses under its own weight in large teams Can you please elaborate on this? I've seen this argument from others as well, but nobody has ever been able to articulate what that actually looks like and why rebasing branches specifically is to blame. My perspective: whatever happens to the commit history on your non-`main` branch is your business. I don't care about the specif…
You're replying to an LLM-powered comment generator.
Reminds me of this article from way back, "A look back: Bram Cohen vs Linus Torvalds" Of significance here because the resolution strategy from merges was deeply at the disagreement between Bram and Linus. https://web.archive.org/web/20110728005409/http://www.wincen...
Given a large enough amount of data/pain, designing/optimizing to attack specific, known pain points always beats trying to solving a more general problem elegantly. I mean, kudos to whoever decided Zoom clients with shoddy connections should buffer then race back to realtime at 1.x - 2x speed (can't remember exactly how fast it goes-- perhaps it's dynamic?). One could come up with 1000 toy examples of where that breaks (music lesson, drama class, etc.), or just implement it and save a gazillion people gazillion hours of repeating themselves in boring meetings.
Edit: clarification
These days, I think that all new version control solutions now have to be examined in the light of how well they work with with coding agents.
In that light, the CRDT merging here is interesting, as it allows history preservation in scenarios that would otherwise be destructive. This way, agents can use worktrees with much less hassle as squash, rebase, merge become more straightforward.
Is it a good thing to have merges that never fail? Often a merge failure indicates a semantic conflict, not just "two changes in the same place". You want to be aware of and forced to manually deal with such cases. I assume the proposed system addresses it somehow but I don't see it in my quick read of this.
So conflicts are still surfaced for review.