Giters

torbiak / git-autofixup

create fixup commits for topic branches

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Have `git blame` do less work

torbiak opened this issue · comments

commented

We need to know if a line is blamed on the topic branch or upstream, but if it is blamed on upstream we don't care which commit exactly, so we should be able to save git blame some work by telling it to stop searching once it gets to the given upstream commit.

@krobelus: I think I have this working in the blameless branch. My initial, very limited measurements show a significant speedup even for small repos. I'm going to do some benchmarking before merging into master, but I thought you'd be interested in checking it out. See the commit message for details, particularly about the -S option to git blame.

commented

Great, thanks! This seems like an obvious improvement.

I did some testing on a repository where I'm some commits ahead and behind of
@{upstream}. I think we need pass the SHA of the common ancestor of HEAD and
the given upstream:

  • git autofixup @{upstream} prints an error: bad graft data: @{upstream}
  • git autofixup $(git rev-parse @{upstream}) prints no error, but is also not faster.
  • git autofixup $(git merge-base @{upstream} HEAD) works, and is roughly twice as fast as before!
commented

Seems like we want to automatically try to find a merge base. It'll be convenient and will also help give better behaviour and error messages in undesirable situations.

The cases I can think of so far:

  • if the given upstream is an ancestor of HEAD, then the merge-base is upstream. The simple case.
  • if the upstream branch has been added to after the topic branch forked then upstream isn't an ancestor of HEAD but there'll be a merge-base that we can use.
  • if a merge-base can't be found then we don't know how far back to blame, and I doubt it makes sense to even try to fixup anything. I can't think of a realistic scenario where this would happen. Prior to this change I think the git log $upstream..HEAD in summary_for_comits() would error out with fatal: no merge base.
commented

oh, and I meant to put the full SHA1 of $upstream into the grafts file, which would have avoided that "bad graft data" error you encountered.

commented

Yeah, I think it's okay to error out if HEAD and upstream have no common ancestor.

Git rebase has --root to deal with root commits but that's probably not very important for us.