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

Correct Git commits with git-autofixup

symflower.com

Post reply on HN
Print view View original

21–30 of 67 posts

Re: Correct Git commits with git-autofixup

#21

Post by hashkb »

tomxor wrote: post #14
zimmski wrote: post #9

Earlier quoted context omitted.

Learning rebasing is one thing but wasting hours every week on rebasing because you are doing the same thing over and over again is another. When i do a one line fixup i just do not want to figure out the correct commit and then rebase i just want it to happen because i already know how i would rebase that: you just use git-autofixup or other similar tools discussed here to get it done.

It's possible the other reason is trying to manipulate git history too frequently. Keep in mind this comes from a prolific git history abuser and rebaser... if hacking on a branch, a trail of messy commits is fine, it's your work in progress, it's also useful if you messed up otherwise you are forced to use reflog. Rebase when you are at the final stage of tidying things up and squashing commits down into a legible h…

Rebase early and often. Always keep a close eye on upstream while you're working downstream. Otherwise you're making it harder on yourself when you do that final cleanup.

Re: Correct Git commits with git-autofixup

#22

Post by zimmski »

hashkb wrote: post #20
zimmski wrote: post #9

Earlier quoted context omitted.

Learning rebasing is one thing but wasting hours every week on rebasing because you are doing the same thing over and over again is another. When i do a one line fixup i just do not want to figure out the correct commit and then rebase i just want it to happen because i already know how i would rebase that: you just use git-autofixup or other similar tools discussed here to get it done.

Practice. You'll get better and faster. I do it tens of times daily and each fixup takes ten or fifteen seconds.

Yep. I have that practice too and i thought that was good enough but with git-autofixup and my posted alias i am down to under one second. So it will save you 1-14 sesconds of your life with every fixup you do... unless it cannot be done automatically. Try it and let us know what you think :-)

Re: Correct Git commits with git-autofixup

#23

Post by quesera »

hashkb wrote: post #7

For this issue and so many others, everyone should just get comfortable with interactive rebase. Crutches like this trap you in this space of never really learning git. And that's a tragedy. All because you're impatient? Afraid?

Coming from the other direction, I am very familiar with interactive rebase, and I use it on my working branch all the time before pushing.

I am struggling to understand the use case for autofixup and absorb. The descriptions talk about post-code-review changes, which means the branch has been pushed. So are these tools only for a flow that uses force-pushing regularly?

I don't think that would be a feature for my teams. We think of code review as an event in time, and changes post-code review should be clearly differentiated from changes pre-code review.

Am I missing the point?

Re: Correct Git commits with git-autofixup

#24

Post by ruffel »

globular-toast wrote: post #13
samwestdev wrote: post #6

Sublime Merge do the same thing in just a couple of clicks, just saying

I doubt it. There's an open feature request currently for adding fixup commits. This article goes a step beyond that. Are you sure you understood the article?

Select two commits. Edit Commit -> Squash Selected Commits, ignoring new messages (fixup)

Re: Correct Git commits with git-autofixup

#25

Post by Vinnl »

hashkb wrote: post #7

For this issue and so many others, everyone should just get comfortable with interactive rebase. Crutches like this trap you in this space of never really learning git. And that's a tragedy. All because you're impatient? Afraid?

This whole article seems to hinge on the fact that you already know how to run an interactive rebase though?

As in, I'm very comfortable doing an interactive rebase, but have to figure out the correct commit to fixup on is tedious, so it sounds very useful to me if a tool can help me with that.

Re: Correct Git commits with git-autofixup

#26

Post by Vinnl »

quesera wrote: post #23
hashkb wrote: post #7

For this issue and so many others, everyone should just get comfortable with interactive rebase. Crutches like this trap you in this space of never really learning git. And that's a tragedy. All because you're impatient? Afraid?

Coming from the other direction, I am very familiar with interactive rebase, and I use it on my working branch all the time before pushing. I am struggling to understand the use case for autofixup and absorb. The descriptions talk about post-code-review changes, which means the branch has been pushed. So are these tools only for a flow that uses force-pushing regularly? I don't think that would be a feature for my te…

I generally use autosquash when a code review of a PR turns up things I missed, which should have been part of a particular commit on that PR's branch. However, I don't want to amend the previous commit right away if I'd like another review for the new changes. Thus, I do a `git commit --fixup ` and push it. I can then ask the review to only look at the new commit, I won't break their local checkouts of the branch, and only when everything's been approved I run `git rebase --autosquash` and then merge it in.

(Before I started using autosquash for this, I'd do the same, except I had to figure out at the time of merging onto which commit every new commit had to be fixed up, rather than at the time of writing it.)

Re: Correct Git commits with git-autofixup

#27

Post by taisalie »

chrismorgan wrote: post #19

An excerpt from my ~/.gitconfig, showing a related approach (piggy-backing on git-revise): [alias] # Revise into the commit that last changed File rf = "!f() { if [ $# -eq 0 ]; then REV=\"$(git status --porcelain --untracked-files=no | sed '/^ /d;s/^.. //' | xargs -n1 git rev-list -1 HEAD --)\"; NUM_REVS=\"$(echo \"$REV\" | wc -l)\"; if [ $NUM_REVS -ne 1 ]; then >&2 echo Files in the index were not all last modified…

You know that can go in $PATH/git-rf, right.

Re: Correct Git commits with git-autofixup

#28

Post by vlovich123 »

quesera wrote: post #23
hashkb wrote: post #7

For this issue and so many others, everyone should just get comfortable with interactive rebase. Crutches like this trap you in this space of never really learning git. And that's a tragedy. All because you're impatient? Afraid?

Coming from the other direction, I am very familiar with interactive rebase, and I use it on my working branch all the time before pushing. I am struggling to understand the use case for autofixup and absorb. The descriptions talk about post-code-review changes, which means the branch has been pushed. So are these tools only for a flow that uses force-pushing regularly? I don't think that would be a feature for my te…

I rely on code review tools that can show me the difference between two patch sets. I really love Phabricator for that ability - push a set of commits and each gets a review. Absorb any fixes, push and suddenly each commit has a new version that you can diff against old ones if you care. It makes reviewing the patch set in totality trickier. However, since I’m practice you want individual commits within a set to be standalone ones, I’ve rarely missed the ability.

Re: Correct Git commits with git-autofixup

#29

Post by pjc50 »

Hmm. This sounds like my workflow with gerrit, which goes like this:

- each work item has its own branch. When pushed, gerrit turns this into a review.

- a git alias, "alias.fixlast=commit -a --amend --no-edit" which amends the last commit to match the working directory

Plus these configurations:

branch.autosetuprebase=local

branch.autosetupmerge=always

pull.rebase=true

The effect is that every branch I create off the main "develop" branch is automatically set up to rebase from that branch when I do "git pull". So when I get some review comments for review "xyz", I just do checkout - pull - make changes - fixup - push.

Gerrit's workflow is slighly unusual in that each review must be a single git change, but it keeps a history of its own of previous changes you made to that review.

Post reply on HN