Write yourself a Git (2018) • Hacker News Board

Re: Write yourself a Git (2018)

#71

Post by shandor » Thu, Mar 14, 2019, 3:09 PM UTC

ectospheno wrote: post #58

linkmotif wrote: post #53

Earlier quoted context omitted.

What makes it hard is that it’s taught wrong. All this pull/checkout/commit/push whereas for me it took a long time to discover that fetch/rebase/show-branch/reset/checkout —amend, and especially the interactive -p variants, are the core tools that really make it a pleasure to use. They give you flexibility and let you write and rewrite your story, whereas the commands you’re introduced with provide no control to the…

The rebase command is only safe if you never share a branch. Most people use a distributed revision control system to work with others and if you do work with others then rebase is dangerous and should not be used. Almost every rebase user I've spoken with has no idea what the danger is despite it being clearly discussed in the manual page for rebase and despite rebase being listed as dangerous every time it is menti…

Rebase is not dangerous. It can't be, since it only works on the local repo.

It's non-fast-forward pushes that are dangerous. And they're dangerous whether anyone uses rebase or not.

Re: Write yourself a Git (2018)

#72

Post by pjc50 » Thu, Mar 14, 2019, 3:11 PM UTC

shandor wrote: post #71

ectospheno wrote: post #58

Earlier quoted context omitted.

The rebase command is only safe if you never share a branch. Most people use a distributed revision control system to work with others and if you do work with others then rebase is dangerous and should not be used. Almost every rebase user I've spoken with has no idea what the danger is despite it being clearly discussed in the manual page for rebase and despite rebase being listed as dangerous every time it is menti…

Rebase is not dangerous. It can't be, since it only works on the local repo. It's non-fast-forward pushes that are dangerous. And they're dangerous whether anyone uses rebase or not.

Loss of un-pushed work can be an issue, which I think is the thing that makes people wary.

Re: Write yourself a Git (2018)

#73

Post by Deganta » Thu, Mar 14, 2019, 3:12 PM UTC

influx wrote: post #54

cabalamat wrote: post #34

Earlier quoted context omitted.

> It seems that it was developed without any concern for affording a good mental model of its operation to its users I think Linus' design goal was something that runs as quickly/efficiently as possible on large repositories. > it is just a complex black box you chant arcane rituals at and hope it doesn't decide to burn your world down My feeling too!

No, his design goal was to create a vcs for the Linux kernel. Frankly most people use git like svn version 2, completely skipping the distributed parts of it. Git actually doesn’t scale to really huge monorepos.

That's because most users don't actually need the distributed part of git. For most projects the sanest solution is to have a single master repository that all users pull/push from/to.

IMHO the only real advantages over SVN for most users are the better branch/merge functions.

Re: Write yourself a Git (2018)

#74

Post by incog-neato » Thu, Mar 14, 2019, 3:13 PM UTC

pierrebai wrote: post #68

incog-neato wrote: post #66

Earlier quoted context omitted.

This is overly broad dissuasion. `rebase` should not be used if the branch is already shared and built upon by others, but is completely harmless to use on a feature branch. In fact, it produces cleaner feature branches for review. Tracking the trunk branch with merges into your feature branch makes for a lot of noisy commits and difficult history to read through when the time comes to diagnose a bug. Rebasing, on th…

Not rebasing does not affect reviewing a branch in the least, unless your diff software is seriously broken. Comparing a branch to trunk shoudl only shows the actual difference. That you merged trunk multiple times shoudl have zero bearing. The only way it could ever confuse anyone is if they review every commit and somehow fail to pass over merge commits. The single most aggravating thing in git are its self-appoint…

There are 2 things I dispute here:

1. I didn't say this affects branch diffing, but rather trawling through history on a single branch.

2. "self-appointed super-users [...] [who break everything]" is a strawman and borderline ad-hominem. If you follow the guidelines I put forth, there won't be any issues collaborating with others.

Also, as a general note, it's actually very difficult to completely destroy information that's been committed at some point. If you're really running into issues with this, don't let fear direct you away from enjoying the greatest features of git. Experiment! Keep trying. Read a good git book (https://git-scm.com/book/en/v2). And learn to use the reflog. Everything you've committed is backed up for a long time even if you've removed all named references to those commits.

Re: Write yourself a Git (2018)

#75

Post by thanatropism » Thu, Mar 14, 2019, 3:22 PM UTC

jordigh wrote: post #55

sransara wrote: post #42

Thanks for sharing. I too agree on this: "... Git is complex is, in my opinion, a misconception... But maybe what makes Git the most confusing is the extreme simplicity and power of its core model. The combination of core simplicity and powerful applications often makes thing really hard to grasp..." If I may do a self plug, I had recently written a note on "Build yourself a DVCS (just like Git)"[0]. The note is an e…

While this is nice, I think it should be emphasised that the blob-tree-commit-ref data structure of git is not essential to a DVCS. One of the disadvantages of everything being git is that everyone can only think in terms of git. This makes things like Pijul's patch system, Mercurial's revlogs, or Fossil's sqlite-based data structures more obscure than they should be. People not knowing about them and considering the…

Worse is better.

Re: Write yourself a Git (2018)

#76

Post by slavik81 » Thu, Mar 14, 2019, 3:33 PM UTC

pierrebai wrote: post #68

incog-neato wrote: post #66

Earlier quoted context omitted.

This is overly broad dissuasion. `rebase` should not be used if the branch is already shared and built upon by others, but is completely harmless to use on a feature branch. In fact, it produces cleaner feature branches for review. Tracking the trunk branch with merges into your feature branch makes for a lot of noisy commits and difficult history to read through when the time comes to diagnose a bug. Rebasing, on th…

Not rebasing does not affect reviewing a branch in the least, unless your diff software is seriously broken. Comparing a branch to trunk shoudl only shows the actual difference. That you merged trunk multiple times shoudl have zero bearing. The only way it could ever confuse anyone is if they review every commit and somehow fail to pass over merge commits. The single most aggravating thing in git are its self-appoint…

Merge commits can contain changes not included in any parent commits. You can't just ignore them.

Re: Write yourself a Git (2018)

#77

Post by thomascgalvin » Thu, Mar 14, 2019, 3:45 PM UTC

asdkhadsj wrote: post #43

On the note of Git being difficult, I'm really curious to see if Pijul[1] ends up being easier to understand than Git. [1]: https://pijul.org

I really like the way Pijul "thinks". Unfortunately, I can't see myself using it (or Fossil, for that matter) for anything except toy code, because I have contract requirements to store everything in GitLab.

Re: Write yourself a Git (2018)

#78

Post by linkmotif » Thu, Mar 14, 2019, 3:48 PM UTC

ectospheno wrote: post #58

linkmotif wrote: post #53

Earlier quoted context omitted.

What makes it hard is that it’s taught wrong. All this pull/checkout/commit/push whereas for me it took a long time to discover that fetch/rebase/show-branch/reset/checkout —amend, and especially the interactive -p variants, are the core tools that really make it a pleasure to use. They give you flexibility and let you write and rewrite your story, whereas the commands you’re introduced with provide no control to the…

The rebase command is only safe if you never share a branch. Most people use a distributed revision control system to work with others and if you do work with others then rebase is dangerous and should not be used. Almost every rebase user I've spoken with has no idea what the danger is despite it being clearly discussed in the manual page for rebase and despite rebase being listed as dangerous every time it is menti…

This is exactly what I'm talking about! Thank you!

There is /nothing/ "dangerous" about rebasing. You just don't rebase branches that are publicly shared without coordinating with the other users, so for some cases (like "master" of an open source project) you don't rebase.

But for your internal workflow, rebase is a KEY TOOL. It's how you write your story of commits. You can't just perfectly nail your commit history the first time you code, unless you are a genius. And what if you're working on a feature, but then you want to commit a certain series chunk of changes to master, so that other features can use that change. Rebase is how you do anything like this. It's core to using and enjoying the beauty of git.

Not to mention reset...

Re: Write yourself a Git (2018)

#79

Post by V-2 » Thu, Mar 14, 2019, 3:57 PM UTC

incog-neato wrote: post #74

pierrebai wrote: post #68

Earlier quoted context omitted.

Not rebasing does not affect reviewing a branch in the least, unless your diff software is seriously broken. Comparing a branch to trunk shoudl only shows the actual difference. That you merged trunk multiple times shoudl have zero bearing. The only way it could ever confuse anyone is if they review every commit and somehow fail to pass over merge commits. The single most aggravating thing in git are its self-appoint…

There are 2 things I dispute here: 1. I didn't say this affects branch diffing, but rather trawling through history on a single branch. 2. "self-appointed super-users [...] [who break everything]" is a strawman and borderline ad-hominem. If you follow the guidelines I put forth, there won't be any issues collaborating with others. Also, as a general note, it's actually very difficult to completely destroy information…

> I didn't say this affects branch diffing, but rather trawling through history on a single branch.

Exactly. What's the point of all the "oops, a typo" or "applying code review remarks, part III" commits. Just rewrite. This is the workflow you get eg. with Gerrit.

Re: Write yourself a Git (2018)

#80

Post by palebluedot » Thu, Mar 14, 2019, 4:02 PM UTC

pierrebai wrote: post #68

incog-neato wrote: post #66

Earlier quoted context omitted.

This is overly broad dissuasion. `rebase` should not be used if the branch is already shared and built upon by others, but is completely harmless to use on a feature branch. In fact, it produces cleaner feature branches for review. Tracking the trunk branch with merges into your feature branch makes for a lot of noisy commits and difficult history to read through when the time comes to diagnose a bug. Rebasing, on th…

Not rebasing does not affect reviewing a branch in the least, unless your diff software is seriously broken. Comparing a branch to trunk shoudl only shows the actual difference. That you merged trunk multiple times shoudl have zero bearing. The only way it could ever confuse anyone is if they review every commit and somehow fail to pass over merge commits. The single most aggravating thing in git are its self-appoint…

Feature branches really should be rebased to have clean self-contained logical commits prior to merging, and this goes beyond just making it easier to review (although that is an important point). It's good git hygiene!

No individual commit should break the build; one reason is to keep git-bisect working well for future users bug-hunting, without getting stopped because someone didn't keep the commits on their dev branch clean prior to merging (N.B., a maintainer should also reject such PRs). And keeping commits clean usually means needing to rebase occasionally to organize the commits.

And each commit should be reviewed individually, in addition to the whole of the branch / PR.

Not to mention that each commit should be logically laid out, with well-defined changes and well-written commit messages. This usually means needing to rebase a branch when developing non-trivial features or bug fixes, to fold in review feedback.

But as mentioned elsewhere, generally on feature / dev branches, the expectation is that the commits are unstable, subject to change, and should not be built upon (without prior coordination, at least).

Master and stable release branches, on the other hand, should never change or be rebased.