TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Git-absorb: Git commit –fixup, but automatic

451 点作者 striking8 个月前

28 条评论

burntsushi8 个月前
The negativity in the comments here is unwarranted in my opinion. I&#x27;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 almost always find the right commit for each change automatically. It saves the tedium of finding the right commit for each change. False positives are virtually non-existent in my experience. False negatives do happen, but then you just fall back to the manual approach.<p>It seems like some would reply and say PRs should just be one commit. Or that they will be squashed anyway. And sure, that is sometimes the case. But not always. I tend to prefer logically small commits when possible, and it&#x27;s not always practical to break them up across multiple PRs. Perhaps partially due to how GitHub works.<p>I use this workflow on all of my projects on GitHub.
评论 #41658802 未加载
评论 #41654487 未加载
评论 #41661228 未加载
评论 #41654990 未加载
AndrewHampton8 个月前
FWIW, I&#x27;ve been using this alias for the past couple years for fixup commits, and I&#x27;ve been happy with it:<p>&gt; gfx=&#x27;git commit --fixup $(git log $(git merge-base main HEAD)..HEAD --oneline| fzf| cut -d&quot; &quot; -f1)&#x27;<p>It shows you the commits on the current branch and lets you select one via fzf. It then creates the fixup commit based on the commit you selected.
评论 #41653419 未加载
评论 #41653575 未加载
评论 #41660029 未加载
评论 #41663553 未加载
评论 #41654633 未加载
评论 #41660500 未加载
评论 #41653590 未加载
评论 #41653848 未加载
imiric8 个月前
I tried using this tool after seeing recommendations for it, but IME it got the parent commit wrong enough times that the work to undo the damage was more than if I had looked up the commit myself and used `--fixup` instead. So I moved back to this manual workflow pretty quickly.<p>I prefer having full control over my commit history, and this tool is too much magic for my taste. I&#x27;m sure that it could be improved so that mistakes are rare, but I&#x27;m not sure I would trust it enough to not have to review its work anyway.
评论 #41653865 未加载
评论 #41664789 未加载
评论 #41655192 未加载
评论 #41653943 未加载
评论 #41666506 未加载
bradley138 个月前
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.
评论 #41654886 未加载
评论 #41655129 未加载
评论 #41654878 未加载
评论 #41660334 未加载
评论 #41657690 未加载
评论 #41657585 未加载
评论 #41656003 未加载
评论 #41655169 未加载
评论 #41654786 未加载
评论 #41654968 未加载
评论 #41660540 未加载
评论 #41655599 未加载
评论 #41659219 未加载
metadat8 个月前
I haven&#x27;t used `git --fixup&#x27; or `git rebase --autosquash&#x27; before, but they sound pretty handy.<p><a href="https:&#x2F;&#x2F;jordanelver.co.uk&#x2F;blog&#x2F;2020&#x2F;06&#x2F;04&#x2F;fixing-commits-with-git-commit-fixup-and-git-rebase-autosquash&#x2F;" rel="nofollow">https:&#x2F;&#x2F;jordanelver.co.uk&#x2F;blog&#x2F;2020&#x2F;06&#x2F;04&#x2F;fixing-commits-wit...</a><p>git-absorb appears to take it one level further. However from the README I&#x27;m not clear on exactly what it will do in specific situations:<p>Does git-absorb automatically associate the most recent commit unique to a branch for a given file and apply the diff to said commit? Or what is the precise workflow and outcome in terms of which edits go into which commits?
tcoff918 个月前
Just use magit and easily make fixup! commits with like 3 key presses. Even if you don&#x27;t use emacs keeping it around just to use magit is worth it.<p>Edamagit for vscode users is not as good but it does this particular workflow great.
评论 #41654454 未加载
评论 #41654678 未加载
评论 #41655794 未加载
parasti8 个月前
TIL about `git commit --fixup` and `git rebase --autosquash`.<p>Interactive git rebase is by far my favorite Git tool to use, it scratches a particular itch to create perfect logically atomic commits.<p>That said, sometimes this kind of history editing tends to backfire spectacularly because these crafted perfect commits have actually never been compiled and tested.
评论 #41658081 未加载
ssijak8 个月前
Do people actually check commit history in detail so often that they absolutely find so much value in ultra clean commit history? I never understood that obsession with 100% clean history.
评论 #41658051 未加载
评论 #41657472 未加载
评论 #41656994 未加载
评论 #41664221 未加载
评论 #41657006 未加载
评论 #41663961 未加载
评论 #41656965 未加载
评论 #41658325 未加载
评论 #41660547 未加载
评论 #41657367 未加载
评论 #41660471 未加载
gorjusborg8 个月前
&#x27;git rebase -i&#x27; meets this need and more. Everyone using git should learn to use it eventually. With it you can squash, fixup, reword, or delete commits interactively.
评论 #41661588 未加载
评论 #41663922 未加载
评论 #41661515 未加载
评论 #41671116 未加载
MBlume8 个月前
I&#x27;ve been using this workflow with hg and it&#x27;s great, happy to see a git port
评论 #41656328 未加载
评论 #41653394 未加载
OJFord8 个月前
This makes no sense to me, why would a conflict-free modifiable commit within the last 10 be the one I want to fixup any more often than roughly 1 in 10?<p>I fixup^ frequently, often often with conflict to resolve in the process, and I have never ever thought &#x27;if only something would automatically choose the target commit for me&#x27;, even if it was advanced AI why would I trust it to be what I wanted?<p>^my alias is:<p><pre><code> !f(){ target=&quot;$(test -n &quot;$1&quot; &amp;&amp; git rev-parse &quot;$1&quot; || git fzsha rev-parse)&quot;; git commit --fixup=&quot;$target&quot; ${@:2} &amp;&amp; EDITOR=true git rebase -i --autostash --autosquash &quot;$target^&quot;; }; f </code></pre> `git fzsha` being another alias of mine to choose the target commit with fzf if not given. I rarely use that though, because usually I know it&#x27;s HEAD~5 or whatever from doing it a second ago, or I&#x27;ve already been looking at the log to work out what I want.
enw8 个月前
In what situations does this solve a problem?<p>In our projects we only enable squash merge in GitHub and the PRs can have any commits you want. The squashed commit includes link to PR, and PR has detailed summary (which wouldn’t be practical in the commit message).
评论 #41662235 未加载
评论 #41665451 未加载
Aissen8 个月前
This looks a lot like git-fixup[1], which I have been using for a few years. I might try git-absorb since it looks quite interesting.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;keis&#x2F;git-fixup">https:&#x2F;&#x2F;github.com&#x2F;keis&#x2F;git-fixup</a>
cocoto8 个月前
Small question to anyone with this workflow. Do you (re)run CI on every affected commit? If no, what is the point of small commits if you lose any guarantees? I much prefer the honest linear non-modified history.
评论 #41665434 未加载
globular-toast8 个月前
There seems to be an alternative implementation called git-autofixup: <a href="https:&#x2F;&#x2F;github.com&#x2F;torbiak&#x2F;git-autofixup">https:&#x2F;&#x2F;github.com&#x2F;torbiak&#x2F;git-autofixup</a><p>Has anyone compared the two?
评论 #41665270 未加载
评论 #41666778 未加载
taberiand8 个月前
This sounds very useful, I frequently reset soft and recommit in batches of related changes before PR and this sounds like it streamlines integrating updates quite nicely
adastra228 个月前
The thing that I never knew I needed, but I predict within a few days I won’t be able to live without. Thank you!
saagarjha8 个月前
This seems neat in theory but I would be perpetually concerned that it is going to pull some change I don&#x27;t mean to commit and put it into something for review. How well does it do at that, anecdotally?
评论 #41655490 未加载
juped8 个月前
If I understand the logic it uses correctly this will nearly always attach the fixup to the right commit. It&#x27;s not for me because I do this manually too fluidly but it seems like a good tool.
thecopy8 个月前
If i understand this will break &quot;changes since my last review&quot; and disconnect PR review comments in GitHub?
评论 #41657158 未加载
psanford8 个月前
I&#x27;m a huge fan of git absorb. I love tools that do-the-right-thing so I can think less. That is what git absorb is.
dmead8 个月前
This sounds great,but kind of an anti pattern in git.<p>I definitely want to have a &quot;fixes&quot; commit on my feature branch. You should do whatever you want on a feature branch so long as your trunk has a clean history.<p>This sounds like someone wanted to lift a feature of changesets in mercurial into git. I don&#x27;t think this is safe and probably breaks a lot of people&#x27;s mental model of git changelogs being an immutable data structure.
评论 #41662385 未加载
评论 #41654456 未加载
评论 #41660677 未加载
renewiltord8 个月前
Pretty clever impl of a tool. I&#x27;ll be using it, thanks.
tripdout8 个月前
How does it figure out which commit to add each change to?
评论 #41655743 未加载
评论 #41655780 未加载
a1o8 个月前
Uhm, I do a lot of git rebase -i HEAD~2 where I just squash the commit on the latest or sometimes I need to reorder and move the fix commits in specific commits in Pars that multiple commits, which I then need to push force. Is this for a similar use-case? I am not familiar with fixup or how it works.
评论 #41653605 未加载
评论 #41654380 未加载
评论 #41660668 未加载
评论 #41653672 未加载
lr4444lr8 个月前
<i>you don&#x27;t want to shove them all into an opaque commit that says fixes, because you believe in atomic commits.</i><p>Sure I do. The whole branch will be squashed anyway before it&#x27;s merged in, and a single &quot;fixes&quot; commit while still on its own branch will be easier to track in a PR for addressing everything pointed out earlier.<p>I mean, don&#x27;t let me stop anyone from using this or --fixup if this is your flow, but this solves a problem neither I nor anyone in my last 10 years of working with code has.
评论 #41653892 未加载
评论 #41654970 未加载
评论 #41654810 未加载
评论 #41655117 未加载
评论 #41653883 未加载
rglynn8 个月前
As a frequent user of fixups, this feels like a solution for already broken workflows.<p>&gt; Instead of manually finding commit SHAs for git commit --fixup<p>Assuming you are using fixups, is this actually a problem?<p>I could see this being a possibility if you are: A. not practicing atomic commits or B. have so many commits in your branch that this is a chore.<p>A. seems unlikely if you are already using fixups and B. seems like a problem worth solving properly rather than going around.<p>To sum up, I&#x27;m not convinced by the elevator pitch. However, I am keenly aware that the workflows of developers differ vastly across industry, company size, technology etc. I&#x27;d be interested to understand what problems this or similar tools solve?
评论 #41654660 未加载
评论 #41662405 未加载
评论 #41653928 未加载
评论 #41660694 未加载
DanielHB8 个月前
Am I the only one who doesn&#x27;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.<p>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.<p>What I do that I wish more people did is that I heavily comment my own PRs with information that doesn&#x27;t make sense in comments (for example on line X I add a comment: moved here from Y file).<p>&gt; You have fixes for the bugs, but you don&#x27;t want to shove them all into an opaque commit that says fixes<p>I actually like this, but split each fix in its own commit and during review I answer to comments with: &quot;fixed in commit {commit-sha}&quot;. So _often_ bugs are introduced during PR review, if the fixes are isolated it is easier to see what changes between review rounds.
评论 #41655516 未加载