Live data from Hacker News

Git-absorb: Git commit –fixup, but automatic

github.com

81–90 of 278 posts

Re: Git-absorb: Git commit –fixup, but automatic

#81

Maybe I am being to much of a purist, but retroactively modifying commits and history? Why? Stuff happens, so do mistakes. Fix the mistakes, make another commit, and go on with your life.

Why store git history at all? It's useless if you don't take care of it. Have you ever used git history for anything? People use it to find the source of regressions (you can do it quite quickly using git bisect).

the git history of the linux kernel documents the Linux kernel detailed Design, the reasoning how things fit together.

I've used it several times to understand why things are done the way they are.

The discussion leading to this design is encoded in the revisions of the patch series, browsable on patchworks.

I agree to your point that the git history has to be taken care of to be useful.

Re: Git-absorb: Git commit –fixup, but automatic

#82

Earlier quoted context omitted.

Criticism isn't negativity. We're not Pollyannas here, we're adults who can handle critique.

I had to look up the reference, and based on the wikipedia plot summary at least, I admit I don't quite get the relevance. I expected a plot where someone handles criticism quite badly and suffers as a result, but in fact the plot was actually about someone who handled criticism very well instead, and improved the lives of others as a result? So now I'm curious! In what way does Pollyanna relate to adults who can't h…

I’ve also thought about that based on the same info, i.e. not reading the source completely.

There is a notion of a “Pollyanna mode” in schematherapy. What it means is ignoring negative facts and challenges with an outwardly positive attitude and avoiding addressing the issues themselves.

This certainly can be harmful to oneself. Another harmful thing is hating and bashing oneself for mistakes and faults and I won’t make a comparative judgement, but a healthy way is supposed to be along the lines of speaking up openly about what bothers you and thinking what can be done about it if at all.

Re: Git-absorb: Git commit –fixup, but automatic

#83

This seems neat in theory but I would be perpetually concerned that it is going to pull some change I don't mean to commit and put it into something for review. How well does it do at that, anecdotally?

It deals with things that have been staged, so if you don't want to commit then don't stage it. I believe a dirty working tree is fine (and gets ignored).

Re: Git-absorb: Git commit –fixup, but automatic

#84

The negativity in the comments here is unwarranted in my opinion. I've been using `git absorb` for years and it works amazingly well. I use it in addition to manual fixups. My most common uses of git-absorb, but definitely not the only, are when I submit a PR with multiple commits and it fails CI for whatever reason. If fixing CI requires changes across multiple commits (say, lint violations), then git-absorb will al…

I’ve been using autofixup for this and it’s been ok but not great, it can be quite slow as things grown, and it doesn’t say anything when there was no match so it’s easy to miss. How does absorb surface that? > Perhaps partially due to how GitHub works. That’s definitely a major factor, I’d like to use stacked PRs they sound really neat, but GitHub. Also even with stacked PRs I figure sometimes you’re at the top of t…

The term Stacked PRs already sounds like a term that was invented specifically in order to communicate in a GitHub-influenced context. Because Stacked PRs are just a reinvention of being able to review a commit at a time (the stack part is straightforward).

Re: Git-absorb: Git commit –fixup, but automatic

#85

Am I the only one who doesn't like atomic commits (or stacked PRs like graphite)? When I work on large PRs I often rewrite and move things around so much that trying to keep all commits in sync is a nightmare. I do try to split the work if it is very clearly isolated, but that usually means less than 3 PRs. I have tried graphite `gt absorb` (which might use this project?) and it still creates a mess. What I do that I…

I think this really boils down how your team is using Git and which code review tool you're using. (I've never used Gerrit personally, but as far as I understand it, we wouldn't have this conversation, since it aims to refine a single change by re-submitting a commit over and over again?)

For GitHub/GitLab reviews, I'm totally with you - this makes it more convenient for the reviewer to check that/how you've responded to feedback.

But now if you merge this without squashing, your Git history on the main branch contains all your revisions, which makes operations like bisecting or blame more complicated.

For me personally, the sweet spot is currently a mix of stacked-commits and the PR workflow: Use a single commit as the unit of review, and polish that commit using a PR, and use the commit descriptions within that PR to tell the story of you responding to feedback. Then, squash merge that commit.

This provides both a good review experience and a tidy history. If you find a strange bug later and can't grasp how someone could have come up with that, the PR still has all the history.

Together with tools such as git-branchless, this also makes working on stacked-PRs a breeze.

Re: Git-absorb: Git commit –fixup, but automatic

#86

Earlier quoted context omitted.

I had to look up the reference, and based on the wikipedia plot summary at least, I admit I don't quite get the relevance. I expected a plot where someone handles criticism quite badly and suffers as a result, but in fact the plot was actually about someone who handled criticism very well instead, and improved the lives of others as a result? So now I'm curious! In what way does Pollyanna relate to adults who can't h…

I’ve also thought about that based on the same info, i.e. not reading the source completely. There is a notion of a “Pollyanna mode” in schematherapy. What it means is ignoring negative facts and challenges with an outwardly positive attitude and avoiding addressing the issues themselves. This certainly can be harmful to oneself. Another harmful thing is hating and bashing oneself for mistakes and faults and I won’t…

This makes sense. Thank you for your comment! Learnt something new today :)

Re: Git-absorb: Git commit –fixup, but automatic

#87
post #42

This sounds great,but kind of an anti pattern in git. I definitely want to have a "fixes" commit on my feature branch. You should do whatever you want on a feature branch so long as your trunk has a clean history. This sounds like someone wanted to lift a feature of changesets in mercurial into git. I don't think this is safe and probably breaks a lot of people's mental model of git changelogs being an immutable data…

At some point the changes are going to get merged in, no? And that that point I would really like the commits to be nice.

That's why you squash and make the commit message readable.

Re: Git-absorb: Git commit –fixup, but automatic

#88
post #35

Earlier quoted context omitted.

How helpful is it if it points you to a commit with 10 different changes? Will you go back to the PR to see the context of each change, and try to guess where the issue is based on the behavior? You're right back at manual debugging at that point. This workflow really shines when it points you to the actual atomic commit that introduced the issue. Then you're simply a `git revert` away from undoing it, without riskin…

I'm with you (see my other top level comment), but > Then you're simply a `git revert` away from undoing it, without risking breaking anything else This needs careful qualification. On GitHub at least, it is difficult to ensure every commit passes CI. This can result in skipping during bisect for a busted commit. It doesn't happen often enough in my experience too convince me to give up a cleaner history, but it's a…

A revert two weeks after the fact will create a new and unique tree (untested) in any case. I don’t if you’re saying that the original commit or the revert might be untested.

In either case the brand new revert could break something. Who knows, it’s a new state.

> It doesn't happen often enough in my experience too convince me to give up a cleaner history, but it's a downside we should acknowledge.

There are tools for that.

https://github.com/mhagger/git-test

Re: Git-absorb: Git commit –fixup, but automatic

#89

Maybe I am being to much of a purist, but retroactively modifying commits and history? Why? Stuff happens, so do mistakes. Fix the mistakes, make another commit, and go on with your life.

Because it's easier to understand later on when it's not spread out

Re: Git-absorb: Git commit –fixup, but automatic

#90
post #87

Earlier quoted context omitted.

At some point the changes are going to get merged in, no? And that that point I would really like the commits to be nice.

That's why you squash and make the commit message readable.

Squash all the commits I worked so hard to make atomic?
Post reply on HN