Why does the version skip from 19 to 20? What about 1A, 1B, 1C, 1D, 1E, and 1F?
Extremely Linear Git History
111–120 of 366 posts
Re: Extremely Linear Git History
#112I am writing a solo project. I only use main (aka master) and never use branching. Otherwise, I inevitably screw something up. It is good enough to keep me from losing stuff most of the time, and I almost never have to struggle with understanding what the heck Git is doing.
Re: Extremely Linear Git History
#113I want the 'merge' function completely deprecated. I simply don't trust it anymore. If there are no conflicts, you might as well rebase or cherry-pick. If there is any kind of conflict, you are making code changes in the merge commit itself to resolve it. Developer end up fixing additional issues in the merge commit instead of actual commits. If you use merge to sync two branches continously, you completely lose trac…
This work if you have only experienced professional developpers in the team. If you have juniors or non devs (mathematicians, geographers, qwants...) that just happen to also code, rebase is a minefield. This is espacially true in open source contributions.
Re: Extremely Linear Git History
#114I prefer a linear version number on the main branch and I have a really tiny version file that gets incremented on every change to the src/ directory. That's not entirely automated, but a commit queue could do that.
Brute-forcing hash collisions seems like an April Fool's joke. You can't really be serious that people are going to do this regularly?
Re: Extremely Linear Git History
#115I want the 'merge' function completely deprecated. I simply don't trust it anymore. If there are no conflicts, you might as well rebase or cherry-pick. If there is any kind of conflict, you are making code changes in the merge commit itself to resolve it. Developer end up fixing additional issues in the merge commit instead of actual commits. If you use merge to sync two branches continously, you completely lose trac…
What I would like to see is a way to enforce fast-forward only merges along with the forced creation of a merge commit that references the same git tree as the HEAD commit of the branch that was just merged.
This way, you know which set of commits was in the branch by looking at the parent commits of the merge commit, but the merge commit itself did not involve any automated conflict resolution.
Re: Extremely Linear Git History
#116I want the 'merge' function completely deprecated. I simply don't trust it anymore. If there are no conflicts, you might as well rebase or cherry-pick. If there is any kind of conflict, you are making code changes in the merge commit itself to resolve it. Developer end up fixing additional issues in the merge commit instead of actual commits. If you use merge to sync two branches continously, you completely lose trac…
This work if you have only experienced professional developpers in the team. If you have juniors or non devs (mathematicians, geographers, qwants...) that just happen to also code, rebase is a minefield. This is espacially true in open source contributions.
Merge and conflict resolution is a minefield if unexperienced developers do it too. Fortunately it can (often) be arranged that those with some understanding of the issues involved can do the resolution.
Re: Extremely Linear Git History
#117The fact that we use a hash as the main way to interact with commits shows how bad git interface is. Sure, you should be able to easily check the sha anytime, but expose the plumbing to end users on almost any interaction is mad. We just got used to it.
Re: Extremely Linear Git History
#118To make sure I've got it right. In order to get this 'beautiful' hashes, they're crunching numbers leveraging cpu power?
yep
Re: Extremely Linear Git History
#119To make sure I've got it right. In order to get this 'beautiful' hashes, they're crunching numbers leveraging cpu power?
Yep. If you squint it's similar to bitcoin mining in that particular aspect
Re: Extremely Linear Git History
#120I want the 'merge' function completely deprecated. I simply don't trust it anymore. If there are no conflicts, you might as well rebase or cherry-pick. If there is any kind of conflict, you are making code changes in the merge commit itself to resolve it. Developer end up fixing additional issues in the merge commit instead of actual commits. If you use merge to sync two branches continously, you completely lose trac…
This work if you have only experienced professional developpers in the team. If you have juniors or non devs (mathematicians, geographers, qwants...) that just happen to also code, rebase is a minefield. This is espacially true in open source contributions.
If you can’t rebase, I don’t want you pushing to my main branches. I would rather teach everyone how to rebase before I cave and allow merge commits.