Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

More on Version Control

bramcohen.com

Post reply on HN
Print view View original

11–20 of 44 posts

Re: More on Version Control

#11

Post by rmunn »

anonymars wrote: post #10
rmunn wrote: post #9

Earlier quoted context omitted.

The team I work for tends to use GitHub's "Squash and merge" button a lot. I find it to be the best of both worlds: the `develop` branch gets a single commit per PR, with a summary of what was done (I always edit the summary commit message and reduce it from a copy of 20 commit messages down to just the most important 4-5, deleting the entirety of messages like "fixup" or "address review comments"). But the PR on Git…

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

Yes, a good Git log viewer that would auto-squash branches down to a summary, and allow "expanding" them, would be useful. But the way branching and merging creates confusing train-track graphs is IMHO one of the reasons why many teams end up using the squash-and-merge workflow. There's definitely room for improvement there...

Re: More on Version Control

#12

Post by sfink »

josephg wrote: post #4

> Oddly they don’t seem to have figured out the generation counting trick, which is something I did come up with over twenty years ago. Combining the two ideas is what allows for there to be no reference to commit ids in the history and have the entire algorithm be structural. Can you say more about this? What exactly is this trick you’re talking about? What are the benefits?

https://github.com/bramcohen/manyana?tab=readme-ov-file#why-...

But someone may need to explain it to me.

Re: More on Version Control

#14

Post by anonymars »

rmunn wrote: post #11
anonymars wrote: post #10

Earlier 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

Yes, a good Git log viewer that would auto-squash branches down to a summary, and allow "expanding" them, would be useful. But the way branching and merging creates confusing train-track graphs is IMHO one of the reasons why many teams end up using the squash-and-merge workflow. There's definitely room for improvement there...

For sure. It just bugs me that we're stuck between two bad options.

Now let's also talk about renames...

Re: More on Version Control

#15

Post by toomim »

sfink wrote: post #5

I've read much of the HN discussion on the previous post, a skimmed the rest, but I didn't see a couple of things addressed: First, how could you make this deal with copies and renames? It seems to me like the pure version of this would require a weave of your whole repository. Second, how different is this from something like jujutsu? As in, of course it's different, your primary data structure is a weave. But jj ke…

You can generically represent copies and renamed (aka "moves") in a CRDT, OT or CTM using a Portal: https://braid.org/meeting-62/portals

Re: More on Version Control

#16

Post by kadoban »

anonymars wrote: post #10
rmunn wrote: post #9

Earlier quoted context omitted.

The team I work for tends to use GitHub's "Squash and merge" button a lot. I find it to be the best of both worlds: the `develop` branch gets a single commit per PR, with a summary of what was done (I always edit the summary commit message and reduce it from a copy of 20 commit messages down to just the most important 4-5, deleting the entirety of messages like "fixup" or "address review comments"). But the PR on Git…

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.

Re: More on Version Control

#17

Post by collabs »

tcoff91 wrote: post #8

So many tools are tightly coupled to git or just assume that everybody uses git. I think that it's hard for any new VCS to gain traction without good git compatibility. For instance Pijul might very well be a lot better than git / jj. I wouldn't know, I haven't bothered trying it because all the projects I need to work in use git. But since jj has great git compatibility, I actually have been able to adopt it because…

You're talking about a new VCS but I don't know how even git with sha-256 will gain any traction because I don't see how you can support both...

Re: More on Version Control

#18

Post by esafak »

tcoff91 wrote: post #8

So many tools are tightly coupled to git or just assume that everybody uses git. I think that it's hard for any new VCS to gain traction without good git compatibility. For instance Pijul might very well be a lot better than git / jj. I wouldn't know, I haven't bothered trying it because all the projects I need to work in use git. But since jj has great git compatibility, I actually have been able to adopt it because…

The great thing about jj is that it is backend agnostic; it is the best gateway to newer version control systems.

Re: More on Version Control

#19

Post by masklinn »

anonymars wrote: post #10
rmunn wrote: post #9

Earlier quoted context omitted.

The team I work for tends to use GitHub's "Squash and merge" button a lot. I find it to be the best of both worlds: the `develop` branch gets a single commit per PR, with a summary of what was done (I always edit the summary commit message and reduce it from a copy of 20 commit messages down to just the most important 4-5, deleting the entirety of messages like "fixup" or "address review comments"). But the PR on Git…

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.

Re: More on Version Control

#20

Post by globular-toast »

anonymars wrote: post #10
rmunn wrote: post #9

Earlier quoted context omitted.

The team I work for tends to use GitHub's "Squash and merge" button a lot. I find it to be the best of both worlds: the `develop` branch gets a single commit per PR, with a summary of what was done (I always edit the summary commit message and reduce it from a copy of 20 commit messages down to just the most important 4-5, deleting the entirety of messages like "fixup" or "address review comments"). But the PR on Git…

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

I would assume most people who would enable an "auto squash" option also aren't carefully creating and curating commits. Bisect is useless if half your commits are broken. People regularly make commits that don't even build, much less pass QA and deliver a valid version of the software. These are works in progress, broken versions and should be deleted.

If you actually do like to deliver the correct number of commits then it's frustrating to work with people who don't care. In that case I would suggest making the squash optional but you could also try selling your team on doing smaller commits. In my experience you either "get it" or you don't, though. I've never successfully got someone to understand small commits.

Post reply on HN