| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Now shows "Commit N of M" so there is a sense of progress while
reviewing commit history
|
| |
|
|
|
| |
Some authors are more likely to include delta entries in their commits than
others. Knowing who wrote a commit at a glance when reviewing it is helpful.
|
| |
|
|
|
| |
We don't usually reference git commits anymore in perldelta, so let's stop
git-deltatool from generating entries like that.
|
| |
|
|
|
| |
My $EDITOR is 'emacsclient -t'. system('emacsclient -t', 'more', 'args') won't
do the right thing.
|
| |
|
|
| |
The pager code is mostly stolen from Prophet::CLI.
|
| |
|
|
|
|
|
|
|
| |
Print output that's just displaying the progress of the tool to STDERR
instead of STDOUT. I can now do things like:
git-deltatool --mode summary --type blocking | awk '{print $1}'
And not have the first line be "Scanning".
|
| |
|
|
|
|
| |
Add an example of `git-deltatool --mode summary --type blocking`
usage. It's what you use for getting the list of commits that you
marked as needing help with.
|
| |
|
|
|
| |
Change the "summarize" misrefences to the "summary" option to
"summary".
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When porting/makerel runs, all files copied into the directory for the
tarball have the executable bit stripped and then only a specific set of
files have the executable bit restored.
There are many files in the repo that have the executable bit set in the
repo that will be stripped. So that the state of files in the repo is
as close as possible to the state of files in the release tarball, the
executable bit has been stripped from such files.
In one recent case, a file added from a dual-life module needed the
executable bit set. Because it had the bit in the repo but was
not listed in makerel to get an executable bit, tests using it
passed in the repo and failed in the tarball.
This commit refactors the list into a new file, Porting/exec-bit.txt
and add tests to detect a mismatch between files listed there
and actual executable bits in the repo.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Allows going 'back' from a section submenu to the main menu for each
commit.
Adds support for calling Porting/cherrymaint to recommend cherrypicking
while reviewing commits for perldelta.
One must recommend cherrymaint before specifying other actions in either
the assign or review modes. This is hack-ish, but should work well enough
to capture cherrymaint nominations while the release manager is
reviewing commits anyway.
|
| |
|
|
| |
Also fixes some docs and adds TODO notes
|
| |
|
|
|
|
|
| |
Refactors comment stripping to be sure it always is applied before
committing the note to git
Adds some white space between commits for easier reading
|
| | |
|
|
|
I've written this tool to help me annotate commits for perldelta.
It scans back through commits, prompting for a perldelta section
for each commit (or to ignore the commit). It then opens up an
editor to write a perldelta snippet into a git note on the commit.
It also supports some very primative workflow, including reviewing
existing annotations and "rendering" annotations properly grouped
by section to cut/paste into perldelta.
It does have some non-core dependencies including Git::Wrapper and
Term::ReadKey, so is intended to be run using an installed perl with
these module from CPAN, not the freshly built one.
Documentation is sparse.
N.B. Git notes are *local* -- they are kept in a detached branch and
will not be pushed upstream. This makes them well-suited for a
release manager to keep working notes (as for perldelta) that will
become irrelevant over time. It's not clear whether they have broader
utility.
|
