What comes after Git • Hacker News Board

Re: What comes after Git

#51

Post by torginus » Tue, Jul 05, 2022, 6:51 AM UTC

roganartu wrote: post #21

torginus wrote: post #13

My main issue with Git, other than the terrible UX of the CLI, is just how common it is for one to want to rewrite the commit history - an operation for which there's no version control. You better get it right, or otherwise you get to nuke the whole repository.

Perhaps this is a byproduct of the UI (which I totally agree is bad), but this is not true. `git reflog` contains a full history of all refs you’ve been on in chronological order. Unless you explicitly delete them, dangling refs are not cleaned up immediately. If you rewrite history and realise you made a mistake, you can likely recover by simply resetting the mutated branch to something from the reflog, even days or…

You learn something every day!

Re: What comes after Git

#52

Post by enasterosophes » Tue, Jul 05, 2022, 6:51 AM UTC

tedk-42 wrote: post #30

Oh god this author again going after clicks for hit pieces on technology without providing any alternatives. If you think you can do it better then go ahead and try build the product and then pitch it.

I didn't recognize the author, but came here to say the same thing: where are the ideas on how these improvements would be implemented?

Without making an attempt at implementation, you (the generic you, not the person I'm replying to) have no idea what the real issues are. Even failed or partial implementations are more instructive than armchair criticisms, or thought experiments where you can just handwave away all the competing constraints that need to be considered, whether in Git or in any erstwhile successor.

Re: What comes after Git

#53

Post by CuriousCosmic » Tue, Jul 05, 2022, 6:55 AM UTC

oivey wrote: post #44

dotancohen wrote: post #40

Earlier quoted context omitted.

> And do you seriously not see the need of rebasing? Git user for a decade. I never rebase, not professionally and not in my personal projects. I merge the work of other devs, no matter how ugly their history. I don't see any real problem that rebase solves, but I do see that it mangles history and makes troubleshooting e.g. git bisect much more difficult.

Rebasing other’s stuff feels gross since it is altering externally visible history. Rebasing your own stuff before you push can make commits more clear, understandable, and meaningful. git pull —rebase is pretty unobjectionable. How does rebasing break bisect?

Presumably they are referring to how the `--first-parent` flag works as it only uses the head of the branch from a given merge instead of including each commit from the merge.

Some projects prefer rebasing onto master instead of merging onto master or squashing onto master.

If you rebase onto master but don't clean up the commits at the end of the PR, this litters master with a bunch of "top level" commits that don't build and cause git-bisect's test to fail due to those commits not working in the first place.

If you rebase onto master but you do clean up your commits such that each commit onto master represents a fully functional version of the project, this isn't a problem however it can make a bisect take way longer than if just merge commits are tested.

If you are rebasing to this degree, I don't really understand the purpose of the rebase for a feature or issue branch (as to this degree, the last commit is the only "completed" commit of this type of branch and you are effectively squashing). It makes sense for say a release branch so you can integrate hotfixes/patches but that workflow can be just as if not more effectively handled via a merge or a squash as well.

Re: What comes after Git

#54

Post by CuriousCosmic » Tue, Jul 05, 2022, 6:58 AM UTC

5e92cb50239222b wrote: post #45

dotancohen wrote: post #40

Earlier quoted context omitted.

> And do you seriously not see the need of rebasing? Git user for a decade. I never rebase, not professionally and not in my personal projects. I merge the work of other devs, no matter how ugly their history. I don't see any real problem that rebase solves, but I do see that it mangles history and makes troubleshooting e.g. git bisect much more difficult.

You must not ever work with junior developers. Rarely do I see a properly created commit history, what you usually get is something like: add upd fix upd fix Rebasing that stuff before merging it into master feels mandatory, or you're left with history with a very low signal-to-noise ratio.

That or you are stuck with somebody fighting CI or issues that aren't reproducible in their environment. It's not necessarily a junior dev issue and can just be "our tooling sucks and management refuses to invest time or money into fixing it". It's not an ideal or sustainable work environment but it's something that even senior devs still have to deal with.

Of course that should still be rebased down to a reasonable history.

Re: What comes after Git

#55

Post by vaughan » Tue, Jul 05, 2022, 7:01 AM UTC

tedk-42 wrote: post #30

Oh god this author again going after clicks for hit pieces on technology without providing any alternatives. If you think you can do it better then go ahead and try build the product and then pitch it.

Usually problems arise before solutions. I’ve been thinking the same things and welcome this post.

Re: What comes after Git

#56

Post by rhdunn » Tue, Jul 05, 2022, 7:02 AM UTC

dotancohen wrote: post #40

gspr wrote: post #27

Earlier quoted context omitted.

With only push, pull and branch, how do you refer to an old version? Hence commits, or something like it, are needed. And do you seriously not see the need of rebasing? Furthermore, you seem to mistake git's distributed nature for some sort of backup scheme. That's not the case. The idea that every repo is equal is tremendously useful.

> And do you seriously not see the need of rebasing? Git user for a decade. I never rebase, not professionally and not in my personal projects. I merge the work of other devs, no matter how ugly their history. I don't see any real problem that rebase solves, but I do see that it mangles history and makes troubleshooting e.g. git bisect much more difficult.

On some projects I maintain a set of local fixes that I regularly rebase on top of the latest code. I don't need to run a bisect on those.

I've also managed other projects/branches like you have, merging the changes into my work.

I also use the cherry picking feature (which rebase builds on) a lot. That is for things like creating hot fixes, pulling in some upstream patches to my local fixes, reordering a branch, etc.

Re: What comes after Git

#57

Post by jraph » Tue, Jul 05, 2022, 7:02 AM UTC

Akronymus wrote: post #47

saxonww wrote: post #36

Earlier quoted context omitted.

In my experience they are correct all of the time for simple renames. It's when you move a file and make substantial edits that it gets confused. I think it's reasonable to argue that git shouldn't get confused in this scenario, but you could also do your renames in one commit and your changes in another.

Would it make sense to make one commit for the move and one for the changes?

I wish I didn't have to think about it and git supported file renaming properly so a unit of change that hasn't much sense when it is split can stay a unit, but without it yes, I think it makes sense to commit renames separately so history can be tracked more easily.

I think git can be configured on how hard it tries to find renames from similarity between a deleted file and an added file.

Re: What comes after Git

#58

Post by enasterosophes » Tue, Jul 05, 2022, 7:02 AM UTC

lloydatkinson wrote: post #46

tedk-42 wrote: post #30

Oh god this author again going after clicks for hit pieces on technology without providing any alternatives. If you think you can do it better then go ahead and try build the product and then pitch it.

What’s wrong with the author?

Well, you can look at the author's past HN submissions to see what was meant.

It's basically click-bait for hackers. "How to do X technology better" with a few paragraphs of ideas, and taking no responsibility for actually doing something about it, aside from hoping that their vision might inspire someone else to put in the hard work.

Re: What comes after Git

#59

Post by rswail » Tue, Jul 05, 2022, 7:05 AM UTC

I'd really like issues porcelain that is built over git so that when I clone I get all of the project's history, as well as it being merged with pull requests etc.

I hate that the github/lab hosting solutions end up with a central database to keep track of issues, CI, etc. It breaks the whole "distributed" model.

Re: What comes after Git

#60

Post by drewcoo » Tue, Jul 05, 2022, 7:06 AM UTC

tedk-42 wrote: post #30

Oh god this author again going after clicks for hit pieces on technology without providing any alternatives. If you think you can do it better then go ahead and try build the product and then pitch it.

I feel your pain.

And your pain is distributed systems. Not just of source control, but bug tracking. And general process-manager-y stuff.