I for my part have not migrated to GIT cause i do not need the extra hoops like staging area or syncing whole repos over network. I have always a server at my side and can work with checkout/checkin. This implies a hard requirement at interface definitions, cause people can't just alter them. Seeing people struggle with all the problems introduced with the git way of work I feel there is still a big market for not git. People are introduced to git and stop asking if there isn't something more good to there workfow. Excuse my english please, im a non native speaker
More on Version Control
21–30 of 44 posts
Re: More on Version Control
#22I for my part have not migrated to GIT cause i do not need the extra hoops like staging area or syncing whole repos over network. I have always a server at my side and can work with checkout/checkin. This implies a hard requirement at interface definitions, cause people can't just alter them. Seeing people struggle with all the problems introduced with the git way of work I feel there is still a big market for not gi…
At least jj tries to fix this partly, and I feel like its good enough for what I do. Most of my projects nowadays are solo, so I can keep it simple.
Re: More on Version Control
#23I for my part have not migrated to GIT cause i do not need the extra hoops like staging area or syncing whole repos over network. I have always a server at my side and can work with checkout/checkin. This implies a hard requirement at interface definitions, cause people can't just alter them. Seeing people struggle with all the problems introduced with the git way of work I feel there is still a big market for not gi…
Git is a decentralized version control system. Creating a new project is just a `git init` away.
Of course centralized VCS are less popular. You need to setup a server first then wrangle with the server every time you create a new project -> fewer projects -> fewer users.
Re: More on Version Control
#24> Git is very simple, reliable, and versatile, but it isn’t very functional.
Funny, I would probably swap the first and the last adjective in that sentence.
Re: More on Version Control
#25Earlier quoted context omitted.
It boggles my mind that instead of this being a UI projection, git instead ingrains a process where developers habitually destroy their history (and bisection options, and merge conflict resolution), therein loading an additional footgun that goes off every now and again when it turns out a now-squashed branch was the basis of (or merged into) some other branch
It’s important to note that not all history is worth keeping, and keeping a dozen commits titled “fix” fixing build / CI errors from the original changes are a lot worse for bisecting than squashing it all into just one. I very much prefer keeping histories by default (both my personal workflows and the tools I build default to that) but squash is a valuable tool.
> keeping a dozen commits titled “fix” fixing build / CI errors from the original changes are a lot worse for bisecting than squashing it all into just one.
How so? When I bisect I want to get down to a small diff, landing on a stretch of several commits (because some didn't build) is still better than landing on a big squashed commit that includes all those changes and more. The absolute worst case when you keep the original history is the same as the default case when you squash.
Re: More on Version Control
#26Earlier quoted context omitted.
It’s important to note that not all history is worth keeping, and keeping a dozen commits titled “fix” fixing build / CI errors from the original changes are a lot worse for bisecting than squashing it all into just one. I very much prefer keeping histories by default (both my personal workflows and the tools I build default to that) but squash is a valuable tool.
> keeping a dozen commits titled “fix” fixing build / CI errors from the original changes are a lot worse for bisecting than squashing it all into just one. How so? When I bisect I want to get down to a small diff, landing on a stretch of several commits (because some didn't build) is still better than landing on a big squashed commit that includes all those changes and more. The absolute worst case when you keep the…
Because they’re broken and their only purpose is to fix up the original change, so it’s functionally the same change.
> The absolute worst case when you keep the original history is the same as the default case when you squash.
No, now you have a bunch of worthless broken commits that you need to evaluate and skip because they’re not the problem you’re looking for.
Re: More on Version Control
#27Earlier quoted context omitted.
It boggles my mind that instead of this being a UI projection, git instead ingrains a process where developers habitually destroy their history (and bisection options, and merge conflict resolution), therein loading an additional footgun that goes off every now and again when it turns out a now-squashed branch was the basis of (or merged into) some other branch
Git doesn't do that. People needlessly destroying history do that. Git will happily let you merge branches and preserve the history there. GP seems to like that history being in PRs only on github instead. I don't get why, that just seems worse to me.
The why is that most people when given the merge option don’t clean up their history so you end up with tons of garbage fix up commits.
Re: More on Version Control
#28Earlier quoted context omitted.
> keeping a dozen commits titled “fix” fixing build / CI errors from the original changes are a lot worse for bisecting than squashing it all into just one. How so? When I bisect I want to get down to a small diff, landing on a stretch of several commits (because some didn't build) is still better than landing on a big squashed commit that includes all those changes and more. The absolute worst case when you keep the…
Because they’re broken and their only purpose is to fix up the original change, so it’s functionally the same change. > The absolute worst case when you keep the original history is the same as the default case when you squash. No, now you have a bunch of worthless broken commits that you need to evaluate and skip because they’re not the problem you’re looking for.
> Because they’re broken and their only purpose is to fix up the original change, so it’s functionally the same change.
Do you restrict yourself to 1 non-broken commit per PR? I don't, and nor does anyone I've worked with. If there were even 2 non-broken commits in the PR, then bisecting with the original history lands you on a diff half the size that bisecting with squashed history would, which is a significant win. (If you didn't care about that sort of thing you wouldn't be bisecting at all).
> No, now you have a bunch of worthless broken commits that you need to evaluate and skip because they’re not the problem you’re looking for.
What are you "evaluating"? If you want to ignore the individual commits and just look at the overall diff that's easy. If you want to ignore the individual messages and just look at the PR-time message that's easy too. Better to have the extra details and not need them than need them and not have them.
Re: More on Version Control
#29> Git is very simple, reliable, and versatile, but it isn’t very functional. Funny, I would probably swap the first and the last adjective in that sentence.
Git, the internals, are simple, but not very functional.
Git, the porcelain, isn't simple, is quite functional.
Re: More on Version Control
#30> Git is very simple, reliable, and versatile, but it isn’t very functional. Funny, I would probably swap the first and the last adjective in that sentence.
Git, the internals, are simple, but not very functional. Git, the porcelain, isn't simple, is quite functional.
The git porcelain is functional, like a toilet.