| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
The early version of the script used to support passing non-branch
arguments but as it evolved we lost that option. Let's use "--" as a
delimiter after the branch(es) to pass optional file names to filter
on. This is convenient to list missing patches on a specific set of
files.
|
| |
|
|
|
|
|
|
|
| |
It's cumbersome to copy-paste a commit ID into another window after having
typed "git cherry-pick -sx", so let's have the suggested output format of
git-show prepare this line just before the subject line, it remains at a
stable position on the terminal when searching for "/^commit". One just
has to copy-paste the line into another terminal will result in the commit
being properly picked.
|
| |
|
|
|
|
|
|
| |
We've never used the output of the rightmost branch with this tool,
and it systematically causes two identical outputs making the job
harder during backport sessions. Let's simply remove the right part
when it's identical to the left one. This also adds a few line feeds
to make the output more readable.
|
| |
|
|
|
|
| |
Given that some OSes have bash in /usr/local/bin and in order not to
give too easy an excuse to Olivier for not backporting fixes, let's
make a few scripts rely on /usr/bin/env bash instead of /bin/bash :-)
|
| |
|
|
|
| |
Since we're using signed-off-by tags for backports, let's add -s to
the command so that we can finally copy-paste it!
|
| |
|
|
|
| |
Two places were not properly protected, resulting in '*' in commit
subjects being interpreted!
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Sometimes certain commits don't contain useful tracking information but
we'd still like to be able to report them. Here we implement a hash on
the author's name, e-mail and date, the subject and the body before the
first s-o-b or cherry-picked line. These parts are supposed to be
reasonable invariant across backports and are usable to compute an
invariant hash of a given commit. When we don't find ancestry in a
commit, we try this method (if -H is specified) to compare commits
hashes and we can report a match. The equivalent commit is reported
as "XXXX+?" to indicate that it's an apparent backport but we don't
know how far it goes.
|
| |
|
|
|
| |
There was a double output redirection in this script while dumping the
current branch's refs which could cause either an error or an empty file.
|
| |
|
|
|
|
| |
This is very convenient for backport reviews as in a single
command you get all the patches one at a time with their
changelog and backport instructions.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When comparing very different branches, it can take a very long time
to scan all commits from the very old common ancestor (eg: haproxy
1.4 to 1.7). Now it is possible to specify a range of commits instead
of a specific branch, and the analysis will be limited to this range
for all commits. The user is responsible for ensuring that the range
covers all possible backports from base to ref, otherwise some of them
may be reported missing while they are not.
This also works with linux kernels, for example :
git-show-backports -u -q -m -r v3.14.69 -b v3.14.65 v3.10.101..HEAD
|
| |
|
|
|
|
|
|
|
| |
When git-show-backports is called with -u, instead of reporting the
commit IDs of the original branch on the left, it will display the
upstream commit IDs when such IDs are known, and will also display
them in the suggested "git cherry-pick" command line. This is useful
when the new branch is more recent than the one being checked and/or
it is desired to get rid of intermediary changes.
|
|
|
These ones have been used for several months already and are quite
convenient to emit new releases and backport fixes. I'm fed up with
having different versions on different machines, let's commit them
now.
|
