Browse Source
This makes git-rev-list use the same command line syntax to mark the commits as git-rev-tree does, and instead of just allowing a start and end commit, it allows an arbitrary list of "interesting" and "uninteresting" commits. For example, imagine that you had three branches (a, b and c) that you are interested in, but you don't want to see stuff that already exists in another persons three releases (x, y and z). You can do git-rev-list a b c ^x ^y ^z (order doesn't matter, btw - feel free to put the uninteresting ones first or otherwise swithc them around), and it will show all the commits that are reachable from a/b/c but not reachable from x/y/z. The old syntax "git-rev-list start end" would not be written as "git-rev-list start ^end", or "git-rev-list ^end start". There's no limit to the number of heads you can specify (unlike git-rev-tree, which can handle a maximum of 16 heads).maint
Linus Torvalds
20 years ago
1 changed files with 21 additions and 24 deletions
Loading…
Reference in new issue