Hacker News Reader

Comment by cupofjoakim | Hacker News Reader

I support this fully. Juniors and intermediate engineers I work with still struggle with git quite often and I personally know how that feels firsthand.

Not sure if this solves the issue. I personally recommend using git, but keeping it simple by limiting the allowed operations.

- git switch - git checkout - git add - git commit - git pull - git push - git rebase - git reset

Note the absence of merge and and cherry pick. Most often when a junior has messed something up it seems to be because of merging in a weird order or cherry picking the wrong thing before merging or rebasing.

Either my juniors have stopped asking me for advice (totally possible) or this recommendation helps. As I find myself very seldom needing those commands I hope and believe it's the latter :)

View on HN

I support it, but I also wonder why other teams seem to spend so much time on git than we do. Our setup is fairly basic, you have a main branch, you can only push things too it by squash merge pull request that are linked to a work item, and you can only do so after whatever you’ve build has gone through the release pipeline, which among other things involve spinning up an instance of it for POs or whatever to test. When a dev wants to change something, they pick a work item on our “mostly kanban” board, and create a branch from there with a dev/name. Behind the scenes this spins up a build and a deployment to a dev/name deployment slot whenever something is pushed to it. They do their things, other devs do theirs, similarly on dev/othername branches and then when whatever is complete it gets squash merged into the main branch with a direct link to the kanban work item.

You’re mostly free to do what you want on your dev/name branch. The only thing you really need to teach “juniors” is that they will hate themselves unless they merge main into their dev branches regularly. But if you’re heading home and want to commit something, or you simply commit as often as you click cmd+s, you can do it with no useful comment because it’ll get squashed anyway. Most people where I work use GitKraken, mostly out of habit, but I think more and more are switching to VSC extensions and some might even use the cli.

The result is that we spend almost 0 time on “git” in our organisation. I wonder if we do things wrong somehow since git seems to cause issues for so many people.

Same, devs overthink it.

Others obsess over history, but personally didn’t find it worth the effort. We look back maybe twice a year, typically fixing issues moving forward.

I guess it does depend on the size of your commits. Ours being relatively small (one work item) we still have the history, while devs getting the freedom to not have to make every commit meaningful.

What's helped me much more lately is undotree for vim [1]. It basically logs every single time a file is saved. Its much more useful because commits have to be made by humans and they may not do it often (and usually there is an incentive for "clean or working commits"). There have been many times where I went back to copy something from the undotree.

[1]: https://github.com/mbbill/undotree

For me most people should not cherry pick-revert-merge-rebase.

They should create branch of development/trunk do commits with their work and create PR. Then PR merge in GitHub interface or something.

98% done other 2% get some git specialists.

That means on average your project must have 50 users to have 1 git specialist. Git problems however seem to happen far more than for 1 in 50 developers I've worked with.

I use git merge a lot (others might too, perhaps only via the Git(Hu|La)b interface though?).

I use git cherry-pick very occasionally. I agree it's probably a mistake in most cases, but there are valid heavily constrained circumstances where it's fine.

I had never heard of git switch. It looks like just another git checkout?

checkout is an older command and does more

switch just does what people think checkout does.

https://linuxhandbook.com/git-switch-checkout/amp/

Rewriting history with rebase is a destructive operation and I would never advocate for it to juniors. Merges are much more straightforward because they follow the git mental model of acyclical directed graph.

> Rewriting history with rebase is a destructive operation.

It's not, because Git history is immutable [0], you can't change it. But I understand that from the user perspective it appears to change, and the consequences for public history "changes" have to be known to prevent any troubles.

[0] https://darekkay.com/blog/git-rewriting-history/

> It's not, because Git history is immutable [0], you can't change it.

> It is by design impossible to modify or delete an existing commit with regular Git commands.

These are both just straight up incorrect. Make the commit unreachable from all regular branches (this can be as simple as a reset or rebase - and at this point is effectively rewriting history), then gc. Oh, ah you say, there’s a reflog. But that can be pruned/expired with the very same regular reflog command you refer to in your post (or just change the unreachable expiry from 30 days to now). At that point the commit is truly unreachable and a gc will make it go away forever.

FYI the commands git reflog expire --expire=now --all && git gc --prune=now should do the trick about truly deleting commit objects for good.

Also the filter commands allow rewriting history.

This makes a difference because your wording implies that there is some inherent structural invariant that makes git history immutable - and there certainly isn’t, there’s just some default policy for how otherwise unreachable objects are recoverable.

Also I think when most people say (correctly [0]) that git history is mutable it is that by default it is easy to rewrite the history of any branch and basically manipulate the commit graph in any way, and all can be done with the standard command line tools. Bringing in the reflog is mostly irrelevant to the concept of history rewriting.

> But I understand that from the user perspective it appears to change

If you force push to a shared repo, there's no "perspective" about it - the history has changed, somebody else may basically get a completely unrelated graph to what they have in their own repo.

Bottom line: The person you're replying to is correct, rebase is a fundamentally destructive operation, because while the objects in git are immutable the references are not and that's all that matters - because a commit without a reference might as well not exist, it's not a history, it's just a commit. Starting with rebase you can prove to yourself that you can make the repo dispose of commit, tree and blob objects forever. I see the distinction that you are trying to make but I don't see why it is either pedagogically or practically a useful one.

[0] https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History (no scare quotes needed)

Thanks for your input. You're right, my statement is not fully correct and I will also update my post. What I mean with "regular" are commands like "rebase" - just running "git rebase" is not destructive in a way that your previous changes are truly gone (by default). That's actually a pretty important thing to know both pedagogically and practically, as it makes it trivial to undo a rebase. If rebase was actually "destructive", you couldn't do it.

You've stated a lot of ways to delete commits that I don't see as "regular" (gc, changing default expire date, filter, reflog, ...). There are even more plumbing commands to delete commits. But yes, I should have explained what I mean with "regular" and also make my point less absolute.

> If you force push to a shared repo, there's no "perspective" about it - the history has changed.

It depends on what "history" and "changing" means to you. If it's the entire Git graph, then every commit changes the history (which it does). What I mean by change in this context is that I can take a graph and alter the existing commits (change order, move, change the content, etc.), and that's not what happens with a rebase for example. I should have clarified this as well. It comes down to the "branches are just pointers" discussion, so for me, moving a branch does not "change" the history (= the commit graph). But I also understand that from a different perspective - viewing the branch as the pointer + the commits it reaches - the history actually changes (but not in the way I've meant it). It's important to state which of those one is talking about.

> You've stated a lot of ways to delete commits that I don't see as "regular" (gc, changing default expire date, filter, reflog, ...).

If reflog is not regular then by your own set of constraints you’ve “deleted” a commit the moment it’s unreachable from any regular branch or stash - which is what most people think when they say “deleted.” Deleting a line of code or a paragraph of text is still deleting even if I can undo it through the very system we’re discussing.

I don’t actually think gc is germane but it was to drive home the point that there’s nothing like cryptographic signatures or something that make objects undisposable.

Further a force push after rebase is destructive because there is no reflog on a remote bare repo.

The corollary is that force pushing deletes commits that are impossible to recover with any “regular” git command.

> That's actually a pretty important thing to know both pedagogically and practically, as it makes it trivial to undo a rebase.

Then just simply say things can be undone with the reflog.

> What I mean by change in this context is that I can take a graph and alter the existing commits (change order, move, change the content, etc.), and that's not what happens with a rebase for example.

> It's important to state which of those one is talking about.

Why?

> But I also understand that from a different perspective - viewing the branch as the pointer + the commits it reaches

I don’t understand what is “different” about this perspective, a branch is literally the pointer. A commit object is not a branch.

> moving a branch does not "change" the history (= the commit graph).

It will point to an entirely new commit graph. This is a change. The commit graph you refer to may very well be orphaned (ie deleted) at this point.

> Further a force push after rebase is destructive because there is no reflog on a remote bare repo. The corollary is that force pushing deletes commits that are impossible to recover with any “regular” git command.

That's somewhat true, there's a whole section about this in my post. But in that case it's not the rebase that is "destructive", it is the forced push. And even that is not destructive as in "unrecoverable". Those changes are not impossible to recover. I can undo my rebase and force-push it again. So can my colleagues working on the same branch. Yes, it's impossible to recover from the bare server's perspective, but this has nothing to do with my original claim that "rebase is not destructive by default".

> Then just simply say things can be undone with the reflog.

I did. That's why I have problem with the word "destructive", because the whole meaning of that word is that something cannot be undone. This was the main point I was trying to make.

>> moving a branch does not "change" the history (= the commit graph). > It will point to an entirely new commit graph. This is a change. > The commit graph you refer to may very well be orphaned (ie deleted) at this point.

No, the commit graph doesn't change when moving a branch. "git reset" will move the branch and not change the graph of the commits in any way. That's why "git reset" is as destructive as git rebase. Yeah, git gc can then actually alter the commit graph (i.e. drop orphaned commits), but that's another point I've explained and warned about in my post. It doesn't affect the non-destructivity of git rebase or git reset.

But maybe you're just seeing the reachable commits as "the commit graph" and the reflog as something special, leading to our misunderstanding. I don't - both reachable and unreachable commits are part of the commit graph internally.

The term destructive in both the case of the original commenter and in this well known lkml related email are in reference to "destroying" history: https://marc.info/?l=dri-devel&m=123836331025827&w=4

> That's why I have problem with the word "destructive", because the whole meaning of that word is that something cannot be undone.

The only problem with this definition is that it is a bit useless, nothing is destructive. Even without the reflog (or stash) you can always restore from backup, or even an ad-hoc locally cloned repo (git makes this especially easy). I agree it's good to know you can undo things and what the built-in facilities are, but it doesn't further elucidate the issues with rebasing as a workflow.

The original statement:

>> Rewriting history with rebase is a destructive operation and I would never advocate for it to juniors. Merges are much more straightforward because they follow the git mental model of acyclical directed graph.

Is clearly in the context of an ongoing workflow involving rebases. Doing an operation and then immediately or even later just undoing it by reverting from the reflog or some old ref is not what is referred to, nor is it relevant to their objections (obvious as they are comparing it to merges).

rebase is a destructive operation from the perspective of the branch the moment you do it, and then when you push it becomes someone else's problem very quickly. They are essentially on the conveyor belt to be destroyed. 30 days isn't even that long, and hoping that your coworkers didn't blow away their local repos doesn't scale.

I also don't see how quibbling with the wording "rewrite" vs "alter" is useful.

>> It will point to an entirely new commit graph. This is a change. > The commit graph you refer to may very well be orphaned (ie deleted) at this point.

There's no precise generally agreed upon definition of "commit graph" in git near as I can tell, even the commit-graph caching facility takes a --reachable option and this is commonly how it is used with many tools, and in books "commit graph" has often been used to refer to a graph starting from a specific commit (as in "git log --graph displays the commit graph", "...when using git log -g to examine the reflog instead of the commit graph ..."). Having said that I won't argue the point about wording and I don't disagree your definition is valid. But I don't think you can claim some authority without a mutually agreed definition. This is also an odd time to start being pedantic.

The actual brass tacks on this is that moving a branch is a change in the mutable repository state. This hangup on the commit objects being immutable while "only" the pointers change is a meaningless distinction for the matter at hand. Once you get to the most common use case of git, using shared repos, those commit pointers (branches/refs) are what get published, and that is what defines the shared constitution of "the commit graph", so they are what matter.

> But maybe you're just seeing the reachable commits as "the commit graph" and the reflog as something special, the reflog as something special

Well it is special. It's repo specific, not shared, and non-essential to the normal operation of git.

But that's not the objection. The main one can be boiled down to, what gets shared and why it gets shared and how the graph looks to clones is more important than defining what is the graph in a private repo. Especially when making someone understand the consequences of rebase vs merge.

> I don't - both reachable and unreachable commits are part of the commit graph internally.

I mean this isn't wrong for one general definition of commit graph, but it isn't always a terribly useful definition. git itself puts virtually no restrictions on this internal commit graph as defined. A git repo/packfile can contain any arbitrary collection of commit objects, you can have two completely unrelated set of trees with commits. You can clone the linux kernel source and then say fetch react into the same git repo, and now you have a disconnected commit graph. This is cool and all and there are some practical applications for it but I don't see it how it is related to the issue of history destruction/rewriting in the context of a shared rebase workflow. Thinking in terms of reachable, strictly non disconnected subgraphs is often more useful.

should use `git restore` alongside `git switch`, right?

And git add —p

fatal: pathspec '—p' did not match any files

Lol, it was 1 dash

I agree mostly but recommend avoiding rebase at all costs at all times always and always prefer merge. Rebase is pure evil plain and simple.

I rebase constantly and I love it. To each their own, I guess.

I do as well and I also cherry pick a lot specifically with —no-commit to pull together disparate ideas from various sources. I am always fascinated when git usage comes up in threads because there are so many ways people use it that differ from my own and we all seem to find value in it!

I use rebase to roll up all my commits before submitting a PR.

Don't see what the big deal is.

That's the simple and safe use of rebase. Rolling up your local wip commits into a coherent story of one or a few clearer commits.

The more-complicated but still safe use is to rebase your local branch on top of an advanced upstream before pushing. Some people prefer merge for this case, but it is somewhat impure.

The problematic use of rebase is on pushed branches. Especially if you have collaborators.

> The problematic use of rebase is on pushed branches. Especially if you have collaborators.

Yep. As soon as you have a PR out, and have to address comments, you have a public branch and can't safely rebase it. So you can't roll those new changes in to the "clean" history, If upstream also has changes before your PR gets merged, you'll also have to add a merge commit anyway.

This is a problem of GitHub, not Git. E.g. GitLab preserves comments as well across rebases as any commit changes.

"Don't rebase public branches" is an easy way to say "if someone has built something on top your branch, don't rebase unless you expect them to also rebase." 90% of the time this is not actually harder than merging, though, and still produces a better history and more atomic commits.

At this point I'm even only 99% firm on "never rebase master", as long as release tags are truly immutable.

The rebase crowd seems to be obsessed with it due to wanting linear history.

In my opinion, the reason for all of this is due to how `git log` shows history. If you merge a branch, then every commit in the branch is now scattered among your mainline history, making it confusing to see what is going on.

So, instead of fixing `git log`, you end up rebaseing (and possibly squashing) on top of the main branch, then doing a fast forward commit so you get a "clean, linear history".

But, if git just change the default of `git log` to `git log --first-parent`, then so much of this would go away.

Only top level commits (directly to the branch, fast-forward merged, or a merge commit) show up in the history.

Now, let's say I have a branch that I've been working on for 2 weeks. I have 20+ commits. During that time, I've already needed to merge the main branch into my branch to keep it up to date several times.

I can either rebase the whole thing, to clean up history, remove the merge commits from main, squash unnecessary changes, and so on, just so I can get a "clean" history in main, or, we can just do a merge commit bringing in my whole branch with a good commit message.

I prefer the merge commit because it is then very easy to track _all_ of the changes made in my branch by a single commit. I can do a diff on the merge commit and see all changes. I can cherry-pick just the merge commit and bring in all the changes. If I need to break down what the original developer of the branch was doing, I can walk through all the sub-commits.

There is no need for them to rewrite history and hide their workflow or their process.

But again, the problem is, by default, `git log` shows this as a huge mess, whereas `git log --first-parent` would _only_ show the merge commit, and would hide all the child commits that happened in the branch. After all, the top level merge commit is what is important, we only care about the subcommits when we need to dig in.

I don’t think ‘linear history’ captures everything.

In the orgs I’ve worked in, it was important that mainline always (bugs notwithstanding) always be ‘runnable’. Many people (myself included) will happily commit in-progress changes to branches they’re working on. If these in-progress changes get into the mainline branch - even as a result of a merge - they become part of its history and break the ‘always runnable’ property.

That's still not a problem, as long as you consider the first parent the canonical parent you can still make assumptions like this along the canonical history, without sabotaging the true history.

The “run on every commit” stance is an argument against rebasing. Without it you have even more freedom to rebase your branches. And there’s less reason to care about the “true history” (bogus concept).

> But, if git just change the default of `git log` to `git log --first-parent`, then so much of this would go away.

Not really.

If you don’t care about the individual commits that lead to a merge (you only care about the final merge) then you could just do `git commit --amend` through the whole process. The end result would be the same.

But presumably these people (who aren’t narrowly focused on a linear history) do care. And (as you seem to be saying) sometimes you want to go down into the second parent of the merge commit.

And in that history (with just merges) there’s a bunch of random “synch. points” where they merged the original branch into theirs. Why? Maybe because it had been three hours, maybe it was the start or end of the day, or something else?

Can you look at the three-way diff and see why?

And then there are all sorts of half thought out commits and missteps that could have been edited out if they used rebase.

Using rebase does have drawbacks. But you can get back value proportional to the time you invest in it. So it’s not a simple matter of discovering that `--first-parent` is a thing and then setting an alias for that (really, you thought that would be it?).

And using merges only (including synch. merges) also has its advantages. But no, using rebase is not just about hiding pull request branches.

Merge breaks your history. Most people start where you are, then eventually realize that merge is actually non-understandable, and switch to rebase.

Hint: “git rebase -i HEAD~3” is your friend. So is “git bisect”.

> Most people start where you are

I've used almost every source control system known to humans the past several decades and git for over a decade.

I've heard the git rebase preachers. I tried to get onboard with rebase.

All who read, avoid rebase at all costs at all times, always.

A bit overstated but yes. Merge squash works every time.

Rebase in my experience at work led to inexplicable conflicts several times I tried. When that happens the rebase preachers will be nowhere to be found, and you’re on your own.

> Merge squash works every time.

Which is a particular kind of rebase except the final commit gets cherry-picked to the target branch (instead of rewriting the original branch).

> Merge squash works every time.

Unless you've already started a follow-up branch before the first gets merged (eg. Waiting for QA, PO review etc.)

Then you at minimum will need to rebase your second branch after the first is merged. Not a disaster but it adds overhead.

Never did that exactly. Think I've either, started a new branch from the waiting one or, started a new branch from the main and then pulled from the older feature branch. Have no recollection of any problems, but it is rare enough to not have tried it recently.

Merge can always be used and rebase is a good tool for certain circumstances. And some people argue for using only one over the other.

Your preaching is contentless.

can you explain? to me SOP is feature branch, work there, commit occasionally, then when it's good review, squash and merge (99% of the times done on remote). the history is clean with the ticket ID attached to the final merge commit (as the feature branch is treated as atomic)

Reply on news.ycombinator.com