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

51–60 of 67 posts

Re: Correct Git commits with git-autofixup

#51

Post by krobelus »

NateEag wrote: post #4
Tobu wrote: post #2

git-absorb is another implementation: - https://github.com/tummychow/git-absorb - https://lib.rs/crates/git-absorb

Can anyone give a comparison of the two from experience? I'm painfully familiar with the problem they solve and am delighted to discover they exist. I'd love some input about how they differ.

I have looked at both but only used git-autofixup. Some observations:

- git-autofixup has a changelog

- git-autofixup includes sober, technical documentation that actually explains how it works. OTOH, git-absorb has a great elevator pitch for users that are not so familiar with Git.

- git-autofixup does not have unresolved bugs, unlike git-absorb

- git-absorb creates fixup commits for the last 10 commits, which seems really odd. It's better to use symbolic references like @{upstream}, but it looks like they dont' support this yet?

- git-autofixup is stable and mostly done software, while git-absorb has a sizeable list of todos

- git-autofixup is written in Perl (like some tools in Git itself), making it easier to install than git-absorb which uses Rust.

Then again, as author of this article, I'm obviously biased ;)

Re: Correct Git commits with git-autofixup

#52

Post by krobelus »

Ambroisie wrote: post #47
NateEag wrote: post #4

Earlier quoted context omitted.

Can anyone give a comparison of the two from experience? I'm painfully familiar with the problem they solve and am delighted to discover they exist. I'd love some input about how they differ.

I have only used `git-absorb`, but one difference from reading the article is that it does its own analysis of your previous commits to choose what each line should `fixup`. Because of this, `git-absorb` can only fix up commits up to a specified base (10 commits earlier by default) when you use it.

> does its own analysis of your previous commits

Not really; you can pass any commit ref to git-autofixup, and it will create commits only for commits since that ref. So it's for the user to decide :)

Re: Correct Git commits with git-autofixup

#53

Post by jpeloquin »

shepmaster wrote: post #46
jpeloquin wrote: post #44

Earlier quoted context omitted.

So I guess what I should be doing is make fix → magit-blame to get the commit ID for the last prior edit → copy commit ID or message to clipboard → magit commit with `c F`, C-s to the commit ID I just copied, and C-c C-c to set up and run the autosquash rebase.

This process is what I think the article describes and what I’m curious if can be automated by magit itself.

Magit appears to have an integration with 'git absorb'. The issue that tracked the integration discussed git absorb as providing similar function to git autofixup. I don't particularly desire unsupervised changes to my commit history though so don't plan on looking into it further.

https://github.com/magit/magit/issues/3053

Re: Correct Git commits with git-autofixup

#54

Post by smaddox »

Vinnl wrote: post #26
quesera wrote: post #23

Earlier quoted context omitted.

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, a…

Thanks for the tip!

Re: Correct Git commits with git-autofixup

#55

Post by alblue »

I wrote my own tool for this which allows you to fix up a file based on the last time you changed that file, or on a specific commit. It will then execute an interactive rebase to that point as well as taking care of stashing and then restoring unrelated files.

https://github.com/alblue/scripts/blob/master/git-fixup

I like the idea of having the editor definition return “true” instead of showing it; I’ll have to add that later.

Re: Correct Git commits with git-autofixup

#56

Post by StavrosK »

chrismorgan wrote: post #45
muxator wrote: post #37

Earlier quoted context omitted.

hg incoming and hg outgoing are really useful. When I am in git, I use this version from https://github.com/sympy/sympy/wiki/Git-hg-rosetta-stone#set... : [alias] outgoing = !git fetch && git log FETCH_HEAD.. incoming = !git fetch && git log ..FETCH_HEAD Feature-wise, the mercurial command is way more powerful: https://www.mercurial-scm.org/doc/hg.1.html#incoming

My aliases for those two deals with remote-tracking branches (see git-rev-parse(1) for documentation of the @{upstream} part if you’re not familiar with it). Might as well provide a more full excerpt: # I almost always use glog rather than log. glog = log --graph # “Short log” slog = log --graph --oneline # `git id` = `git rev-list --max-count=1` with default refspec HEAD. id = "!f() { case \"x$1\" in x-*|x) refspec=…

Is there one of these `@{}` tags that means "the point where this branch split off from master"? That'd be very useful, because that's usually the scope of my rebases.

Re: Correct Git commits with git-autofixup

#57

Post by chrismorgan »

StavrosK wrote: post #56
chrismorgan wrote: post #45

Earlier quoted context omitted.

My aliases for those two deals with remote-tracking branches (see git-rev-parse(1) for documentation of the @{upstream} part if you’re not familiar with it). Might as well provide a more full excerpt: # I almost always use glog rather than log. glog = log --graph # “Short log” slog = log --graph --oneline # `git id` = `git rev-list --max-count=1` with default refspec HEAD. id = "!f() { case \"x$1\" in x-*|x) refspec=…

Is there one of these `@{}` tags that means "the point where this branch split off from master"? That'd be very useful, because that's usually the scope of my rebases.

I recommend reading the git-rev-parse(1) man page in full, it’ll give you good ideas for this sort of thing.

What you’re looking for could be spelled $(git merge-base HEAD master) (that’s a subshell invocation, outputting a single commit ID). In some circumstances dotted range notation might do: master.. includes all the commits after master and HEAD diverge. That’s good for logging, for example, but not so useful for the sort of rebasing you’re describing, where you may wish to use the merge base instead.

Re: Correct Git commits with git-autofixup

#58

Post by piotrkaminski »

vlovich123 wrote: post #28
quesera wrote: post #23

Earlier quoted context omitted.

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 s…

In https://reviweable.io, you can have both matching-commit diffs and whole-PR diffs, all in the same review.

Re: Correct Git commits with git-autofixup

#59

Post by hashkb »

zimmski wrote: post #22
hashkb wrote: post #20

Earlier quoted context omitted.

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 :-)

Challenge accepted.

Re: Correct Git commits with git-autofixup

#60

Post by quodlibetor »

shepmaster wrote: post #15
globular-toast wrote: post #12

Earlier quoted context omitted.

It doesn't do it magically, but it makes it a lot easier to do. Easy enough that I've never really wanted a tool like this. Having said that, if autofixup works well it might be worth integrating it into magit via a plugin as it would certainly reduce the repetition.

Could you share what your workflow would be? I’m assuming you put the point on the line you want to fix, then use Magit to start a rebase at the last commit that changed that line, then apply your changes, then continue? I’m a casual Magit user, so learning from other users would be very beneficial.

If you start doing a commit (via `c` in the magit status buffer, with the standard semantics of "you're going to commit everything that's currently staged") you can press capital F for an instant fixup, or capital S for instant squash.

When you press either of those, magit pops up a commit picker which shows the current git log. Selecting a commit will then instantaneously apply your staged changes to the selected commit. It's much simpler than any of the other workflows I've seen in response to your question.

The gif in this repo (for a tool I made that simulates this behavior as a cli tool for some jealous coworkers) tries to show the workflow: https://github.com/quodlibetor/git-fixup

That said, this _doesn't_ support the "automatically figure out which commits to apply hunks to" workflow. I personally find that I use both workflows depending on the nature of my changes.

Post reply on HN