Question

I'm writing a script that makes some trivial changes and then commits them to git. Because these are trivial changes, I want to do git commit --amend whenever I can get away with it -- specifically, when an amend won't "mess up" any other branches' history. If an amend would mess up another branch, I want to do a standard git commit instead.

For example, if my branches looked like this (a la "Visualize all branch history" in Git GUI):

* [experimental branch] Added feature.
* [master branch] Trivial change from script
* ...

and I'm running this script on the master branch, then I don't want to do an amend, because I would be replacing part of the experimental branch's history. Technically, this won't actually break anything -- the original commit will still be part of experimental's history, and will still be referenced so it won't get garbage collected -- but having nearly-but-not-quite-identical commits in two different branches makes life difficult when I later want to rebase or merge, so it's a situation I want to avoid.

How can I make my script automatically detect whether a commit has anything branched from it?

If simplifying assumptions help, I always run this script on the head of master, and I only use git as a local repository -- I don't push or pull changes anywhere.

This script is in Ruby, so I can either shell out to the git command line, or I can use Ruby bindings for git -- whichever would make this task easier.

Was it helpful?

Solution

Just run git branch --contains HEAD to get a list of branches that "contain" this commit. If the list is empty, that commit should be safe for ammending. You also might want to include the -a flag to list local AND remote branches.

Alternatively, you could compare the output of git rev-parse HEAD with git merge-base HEAD other-branch. If these commit IDs are identical, the current commit is in other-branch's commit history.

OTHER TIPS

The commit graph is one-way: given a commit, you know all of its ancestors, but not any of its children. You'll have to start at the endpoints and backtrack until you get to the commit(s) that you want.

Use git rev-list [some commit] --children (HEAD is the default):

$ git rev-list HEAD --children
6edbee61c87fb063700751815f0ad53907d0b7a4
aee452860ecd772b8bdcd27227e6a72e6f4435fd 6edbee61c87fb063700751815f0ad53907d0b7a4
ef8a1487b03256a489d135e76d1f0b01872f2349 aee452860ecd772b8bdcd27227e6a72e6f4435fd
6910dc5833f6cd26133e32bef40ed54cf9337017 ef8a1487b03256a489d135e76d1f0b01872f2349
bbef0da56efe048f70293bd20bad0cb37b5e84f0 6910dc5833f6cd26133e32bef40ed54cf9337017
[...]

The left-hand column is a list of commit SHA-1s in reverse chronological order. Anything to that commit's right are the children (--children) of that commit. The top commit is HEAD and thus has no children.

Thus, if you grep for your SHA-1 in this list and it has anything to its right, it has at least one child:

$ git rev-list --children | grep '^6910'
6910dc5833f6cd26133e32bef40ed54cf9337017 ef8a1487b03256a489d135e76d1f0b01872f2349

In the above example, commit 6910... has a child, ef8a....

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top