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

31–40 of 67 posts

Re: Correct Git commits with git-autofixup

#31

Post by jpeloquin »

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.

That works. My habit is to make the fix, commit it as "!fixup whatever", start an interactive rebase, move the fixup commit just after the bad commit (M-↑), press f on the fixup commit to tell rebase to merge it with the bad commit, and run the rebase (C-c C-c). This is pretty much the same method as yours, but committing first means the fixup will still be there if you have to cancel & redo the rebase for some reason, such as unexpected and confusing merge conflicts.

Re: Correct Git commits with git-autofixup

#32

Post by chrismorgan »

taisalie wrote: post #27
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.

If it grew much bigger I’d do that, but until it’s definitely too large, keeping all of this stuff in ~/.gitconfig is simpler, especially for sharing across heterogeneous machines.

Re: Correct Git commits with git-autofixup

#33

Post by taisalie »

chrismorgan wrote: post #32
taisalie wrote: post #27

Earlier quoted context omitted.

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

If it grew much bigger I’d do that, but until it’s definitely too large, keeping all of this stuff in ~/.gitconfig is simpler, especially for sharing across heterogeneous machines.

You can add a version-controlled directory to your PATH and put scripts in it. This can be in the same repository as your .gitconfig. So you can graduate aliases to scripts.

Re: Correct Git commits with git-autofixup

#34

Post by globular-toast »

jpeloquin wrote: post #31
shepmaster wrote: post #15

Earlier quoted context omitted.

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.

That works. My habit is to make the fix, commit it as "!fixup whatever", start an interactive rebase, move the fixup commit just after the bad commit (M-↑), press f on the fixup commit to tell rebase to merge it with the bad commit, and run the rebase (C-c C-c). This is pretty much the same method as yours, but committing first means the fixup will still be there if you have to cancel & redo the rebase for some reaso…

> move the fixup commit just after the bad commit (M-↑), press f on the fixup commit to tell rebase to merge it with the bad commit,

That's what --autosquash is for. If you do fixup commits correctly (using --fixup), it will put them in the correct place and mark them as fixups for you.

Re: Correct Git commits with git-autofixup

#35

Post by shepmaster »

jpeloquin wrote: post #31
shepmaster wrote: post #15

Earlier quoted context omitted.

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.

That works. My habit is to make the fix, commit it as "!fixup whatever", start an interactive rebase, move the fixup commit just after the bad commit (M-↑), press f on the fixup commit to tell rebase to merge it with the bad commit, and run the rebase (C-c C-c). This is pretty much the same method as yours, but committing first means the fixup will still be there if you have to cancel & redo the rebase for some reaso…

Right, that process is what I do now, outside of Magit. The point of this article is a tool that (attempts to) automatically find the correct commit to combine with. Conceptually it removes the effort taken to move the fixup commit to the right spot; both keystroke-wise and mental effort wise.

That’s what I’m looking for: a Magit-native way to make my little fixups without having to manually track which fixup should be applied where in history.

Re: Correct Git commits with git-autofixup

#36

Post by globular-toast »

ruffel wrote: post #24
globular-toast wrote: post #13

Earlier quoted context omitted.

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)

That's not a fixup commit, it's a rebase. It's missing the point of fixup commits which is to commit now and defer the rebase until later.

It's also completely missing the point of the feature under discussion here which is to automatically decide which commit to squash the fix into.

Re: Correct Git commits with git-autofixup

#37

Post by muxator »

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…

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

Re: Correct Git commits with git-autofixup

#38

Post by globular-toast »

Vinnl wrote: post #25
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.

Unfortunately I think fixup commits are one of the least understood parts of git. People seem to confuse them with rebasing. They support rebasing but don't replace it.

Re: Correct Git commits with git-autofixup

#39

Post by globular-toast »

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.

I typed it out but HN seems to be rate limiting me or something and tells me I'm "posting too fast". I seem to be able to post shorter comments, though.

I've been meaning to write an article on a fixup workflow for a while now. Just need to find somewhere to host it.

Re: Correct Git commits with git-autofixup

#40

Post by tomxor »

hashkb wrote: post #21
tomxor wrote: post #14

Earlier quoted context omitted.

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.

That's a fair point, if you are working against a fast moving target that forces you to rebase onto it often then you really want a short and simple history... a trail of WIPs or changes on top of changes tend blow up into a cascade of conflicts.

However in my original comment I was actually just referring to the scenario where you only want to rewrite history onto the same base, in which case I stand by my suggestion... In fact I find this can be a good strategy if your history has grown and you also need to rebase onto a new upstream - i.e first clean up your history onto the same base with a `git rebase -i current-base` and squash it all down and tidy it up, then do the `git rebase upstream` so you can do conflict resolution with more holistic commit diffs.

Post reply on HN