`do_pick` is the git-cherry-pick wrapper in git-rebase--interactive
that is used to implement many of the to-do list commands.
Eventually, the complete `do_pick` interface will be exposed to the
user in some form or another and those commands will become simple
aliases for the `do_pick` options
The command line used to recreate root commits specifies the option
`-q` which suppresses the commit summary message. However,
git-rebase--interactive tends to tell the user about the commits it
creates in the final history, if she wishes (cf. command line option
`--verbose`). The code parts
Rewrite `squash` and `fixup` handling in `do_next` using the sequence
pick_one
commit
in order to test the correctness of a single `do_squash` or
parameterised `do_pick` and make the subsequent patch reimplementing
`squash` in terms of such a single function more readable.
Do not call
`do_pick` is the git-cherry-pick wrapper in git-rebase--interactive
that is currently used to implement most of the to-do list commands
and offers additional options that will eventually find their way
onto to-do lists.
To extend the repertoire of available options, add the git-commit and
The to-do list command `reword` replays a commit like `pick` but lets
the user also edit the commit's log message. If one thinks of `pick`
entries as scheduled `cherry-pick` command lines, then `reword`
becomes an alias for the command line `cherry-pick --edit`. The
porcelain `rebase--interactive`
The command line used to recreate root commits uses `-C` to suppress
the log message editor. This is unnecessarily confusing, though,
because that suppression is a secondary effect of the option. The
main purpose of `-C` is to pull the metadata from another commit, but
here we know that this is a
Using the to-do list command `squash` the user can specify two or
more commits and git-rebase creates one commit that introduces all
their changes combined. The authorship for the created commit is
taken from the first commit specified and the user can edit the log
message. There is a variant of
Since `do_pick` might be executed in a sub-shell (a modified author
environment for instance), calling `die` in `do_pick` has no effect
but exiting the sub-shell with a failure exit status. The
git-rebase--interactive script is not terminated. Moreover, if
`do_pick` is called while a squash or
There are two kinds of to-do list commands available. One kind
replays a commit (`pick`, `reword`, `edit`, `squash` and `fixup` that
is) and the other executes a shell command (`exec`). We will call the
first kind replay commands.
The two kinds of tasks are scheduled using different line formats.
The options passed to `do_pick` determine whether the picked commit
will be rewritten or not. If the commit gets rewritten, because the
user requested to edit the commit message for instance, let
`pick_one` merely apply the changes introduced by the commit and do
not commit the resulting tree yet.
The to-do list command `squash` and its close relative `fixup` replay
the changes of a commit like `pick` but do not recreate the commit.
Instead they replace the previous commit with a new commit that also
introduces the changes of the squashed commit. This is roughly like
cherry-picking without
pick and reword are atomic to-do list commands in the sense that they
open a new task which is closed after the respective command is
completed. squash and fixup are not atomic. They create a new task
which is not completed until the last squash or fixup is processed.
Lift the general unknown
Hi Jeff,
Jeff King writes:
On Tue, Jul 29, 2014 at 01:18:09AM +0200, Fabian Ruch wrote:
The options passed to `do_pick` determine whether the picked commit
will be rewritten or not. If the commit gets rewritten, because the
user requested to edit the commit message for instance, let
On Thu, Aug 7, 2014 at 7:34 AM, Jonathan Nieder jrnie...@gmail.com wrote:
Package: git
Version: 1:2.0.0-1
Tags: upstream
$ git init foo
Initialized empty Git repository in /tmp/t/foo/.git/
$ cd foo
$ echo hi README
$ git add -N README
$ git status
On branch master
I tried using escaped globs with git mv, but globs don't seem to be
expanded with git mv.
So, for example, I've got files file1 file2, and have been editing
them, so I've got file1~ and file2~ also, and *~ is in .gitignore.
If I do:
$ mkdir newdir
$ git mv file* newdir
I get a 'fatal: not in
On Thu, Aug 7, 2014 at 8:52 AM, Alan Grover alan.gro...@gmail.com wrote:
Since we can do git add file\*, I tried:
$ git mv file\* newdir
I get a 'bad source, source=file* destination=file*' error. It seems
to be looking for a file named 'file*' rather than performing glob
expansion.
This
On Wed, Aug 06, 2014 at 05:38:43PM -0700, Mike Stump wrote:
Oh, wait, maybe I have misunderstood the prohibition. I have:
upstream —— fsf
|
\
|
v
Me — master — coworker.
This looks a lot like what I meant about project repos.
On Fri, Aug 01, 2014 at 03:01:31PM -0700, Junio C Hamano wrote:
* jk/stash-list-p (2014-07-30) 7 commits
- SQUASH??? future-proof, log --cc should imply -p without being told
- stash: show combined diff with stash show
- stash: default listing to --cc --simplify-combined-diff
- add
Hi,
with rust's git repo -- located at
https://github.com/rust-lang/rust.git -- we see odd results from
git-describe for the latest tag.
$ git rev-parse HEAD
795f6ae829ab1bfd72394a5da9096e2717ec0f62
$ git describe --debug
searching to describe HEAD
finished search at
Junio C Hamano gits...@pobox.com writes:
Sergey Organov sorga...@gmail.com writes:
Previous description implicitly favored 'true' value for pull.rebase
and pull.branch.rebase options,
I do not share that impression. It is true that 'true' is described
first before 'preserve', which can be
Jonathan Nieder jrnie...@gmail.com writes:
Hi Sergei,
Sergei Organov wrote:
--C--
/ \
/ M topic,HEAD
/ /
A---B master
shouldn't
$ git rebase master
be a no-op here?
[...]
I'd expect --force-rebase to be required for this to happen:
-f, --force-rebase
Can I talk to you, I will be very glad if you permit me to talk to you for an
important deal.
Regards,
KM.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Patch v8]: git_die_config now allows custom error messages.
new tests are now not too reliant on specific strings. Diff
between v7 v8 is appended at the bottom. Thanks to Junio
Matthieu for their suggestions.
[Patch v7]: style nit corrected. (1/8) is Matthieu's
Currently `git_config()` returns an integer signifying an error code.
During rewrites of the function most of the code was shifted to
`git_config_with_options()`. `git_config_with_options()` normally
returns positive values if its `config_source` parameter is set as NULL,
as most errors are fatal,
From: Matthieu Moy matthieu@imag.fr
If a callback returns a negative value to `git_config*()` family,
they call `die()` while printing the line number and the file name.
Currently the printed line number is off by one, thus printing the
wrong line number.
Make `linenr` point to the line we
Store file name and line number for each key-value pair in the cache
during parsing of the configuration files.
Signed-off-by: Tanay Abhra tanay...@gmail.com
---
cache.h | 5 +
config.c | 16 ++--
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/cache.h b/cache.h
From: Matthieu Moy matthieu@imag.fr
Signed-off-by: Matthieu Moy matthieu@imag.fr
---
config.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/config.c b/config.c
index a191328..34940fd 100644
--- a/config.c
+++ b/config.c
@@ -457,9 +457,9 @@
Add `git_die_config` that dies printing the line number and the file name
of the highest priority value for the configuration variable `key`. A custom
error message is also printed before dying, specified by the caller, which can
be skipped if `err` argument is set to NULL.
It has usage in
Of all the functions in `git_config*()` family, `git_config()` has the
most invocations in the whole code base. Each `git_config()` invocation
causes config file rereads which can be avoided using the config-set API.
Use the config-set API to rewrite `git_config()` to use the config caching
layer
Add tests for `git_config_get_string_const()`, check whether it
dies printing the line number and the file name if a NULL
value is retrieved for the given key.
Signed-off-by: Tanay Abhra tanay...@gmail.com
---
t/t1308-config-set.sh | 10 ++
test-config.c | 10 ++
2 files
Semantic errors (for example, for alias.* variables NULL values are
not allowed) in configuration files cause a die printing the line
number and file name of the offending value.
Add a test documenting that such errors cause a die printing the
accurate line number and file name.
Signed-off-by:
Running on Windows with latest version of Git. 1.9.4. Also had this trouble
with 1.8.2 but upgraded hoping it would fix the problem.
When I do a reset on several files, it says they were successfully reverted
they still show up as modified when I do a git status. In this case it's just a
On 8/5/2014 12:29 AM, Eric Sunshine wrote:
On Mon, Aug 4, 2014 at 2:33 PM, Tanay Abhra tanay...@gmail.com wrote:
Use `git_config_get_bool()` family instead of `git_config()` to take
advantage of
the config-set API which provides a cleaner control flow.
Signed-off-by: Tanay Abhra
On 23.07.2014 21:33, Sergei Organov wrote:
What actually bothers me is the unfortunate consequence that git pull
is not always a no-op when nothing was changed at the origin since the
last git pull. THIS is really surprising and probably should better be
fixed. Requiring -f is just one (obvious)
Tanay Abhra tanay...@gmail.com writes:
--- a/cache.h
+++ b/cache.h
@@ -1406,8 +1406,14 @@ extern int git_config_get_bool(const char *key, int
*dest);
[...]
+struct key_value_info {
+ const char *filename;
+ int linenr;
+};
[...]
diff --git a/config.c b/config.c
index
Tanay Abhra tanay...@gmail.com writes:
+test_expect_success 'find string value for a key' '
+ check_config get_string case.baz hask
+ check_config expect_code 1 get_string case.ba Value not found for
\case.ba\
+'
+
+test_expect_success 'check line error when NULL string is
Philip Oakley wrote:
From: Mike Stump mikest...@comcast.net
Sent: Friday, August 01, 2014 11:24 PM
On Aug 1, 2014, at 12:01 PM, Jakub Narębski jna...@gmail.com wrote:
It can work in Subversion because Subversion stores information about
what was merged in (and this includes cherry-picks, or
On 8/6/2014 9:02 PM, Matthieu Moy wrote:
Tanay Abhra tanay...@gmail.com writes:
+test_expect_success 'find string value for a key' '
+check_config get_string case.baz hask
+check_config expect_code 1 get_string case.ba Value not found for
\case.ba\
+'
+
+test_expect_success
On 06/08/14 15:53, Tanay Abhra wrote:
Store file name and line number for each key-value pair in the cache
during parsing of the configuration files.
Signed-off-by: Tanay Abhra tanay...@gmail.com
---
cache.h | 5 +
config.c | 16 ++--
2 files changed, 19 insertions(+),
Tanay Abhra tanay...@gmail.com writes:
On 8/5/2014 12:29 AM, Eric Sunshine wrote:
On Mon, Aug 4, 2014 at 2:33 PM, Tanay Abhra tanay...@gmail.com wrote:
- if (skip_prefix(var, http., p)) {
- int i;
-
- for (i = 0; i ARRAY_SIZE(rpc_service); i++) {
-
W dniu 2014-08-06 17:04, Jared Brank pisze:
Running on Windows with latest version of Git. 1.9.4. Also had this
trouble with 1.8.2 but upgraded hoping it would fix the problem.
When I do a reset on several files, it says they were successfully
reverted they still show up as modified when I do a
W dniu 2014-08-01 22:55, Nico Williams pisze:
On Fri, Aug 1, 2014 at 3:50 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Jonathan Nieder wrote:
Do you mean that git merge should be aware of what changes you have
already cherry-picked?
It isn't, and that's deliberate
That said, when today's
On Wed, Aug 6, 2014 at 10:58 AM, Jakub Narębski jna...@gmail.com wrote:
W dniu 2014-08-01 22:55, Nico Williams pisze:
It would help if cherry-pick history where recorded somewhere (beyond
the reflog)...
Cherry-picks should record two parents, like merges.
(Of course, it does no good to know
Jeff King p...@peff.net writes:
On Fri, Aug 01, 2014 at 03:01:31PM -0700, Junio C Hamano wrote:
* jk/stash-list-p (2014-07-30) 7 commits
- SQUASH??? future-proof, log --cc should imply -p without being told
- stash: show combined diff with stash show
- stash: default listing to --cc
Is this even possible? The .gitmodule file has to be at the root of
the repository, AFAIK. So if the subtree is inherently not at the
root, how does it manage its own submodules?
Basically I have a common library that also keeps a submodule of third
party dependencies (binaries). Each super
Linus Arver linusar...@gmail.com writes:
No, the unindenting/removal of blank lines is a non-grammar change and
is not necessary, as it doesn't have any effect on the actual output
(html/txt/manpage).
I can either keep the same coding style with the rewording, or chop this
into two commits,
Bug v1.9.3: Spurious whitespace warnings when using git apply with the
--exclude option
REPRO STEPS:
1. Create a patch PATCH that modifies two files, A and B. Make sure the
modifications to file A add whitespace errors and the modifications to file B
do not.
2. Apply that patch to a repo using
Linus Arver linusar...@gmail.com writes:
On Tue, Aug 05, 2014 at 03:12:21PM -0700, Junio C Hamano wrote:
Linus Arver linusar...@gmail.com writes:
Signed-off-by: Linus Arver linusar...@gmail.com
---
You would need to work on your justification skills ;-) in the log
message. What does
Linus Arver linusar...@gmail.com writes:
On Tue, Aug 05, 2014 at 03:14:48PM -0700, Junio C Hamano wrote:
Linus Arver linusar...@gmail.com writes:
Signed-off-by: Linus Arver linusar...@gmail.com
---
Documentation/git-init.txt | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
Robert Dailey rcdailey.li...@gmail.com writes:
Is this even possible? The .gitmodule file has to be at the root of
the repository, AFAIK. So if the subtree is inherently not at the
root, how does it manage its own submodules?
Basically I have a common library that also keeps a submodule of
Hello,
I ran git on my newly-set-up OS X Mavericks machine, and get:
$ git
Agreeing to the Xcode/iOS license requires admin privileges,
please re-run as root via sudo.
Running 'git --verision' gives the same result. This seems
problematic in a few ways, and I am wondering if
On Wed, Aug 6, 2014 at 12:51 PM, Junio C Hamano gits...@pobox.com wrote:
My knee-jerk reaction would be subtree would break submodules
badly, don't use it ;-).
After all, I invented subtree merge as an ugly interim workaround
before submodule subsystem got into a usable shape, hoping that new
On Wed, Aug 6, 2014 at 6:26 PM, Nico Williams n...@cryptonector.com wrote:
On Wed, Aug 6, 2014 at 10:58 AM, Jakub Narębski jna...@gmail.com wrote:
W dniu 2014-08-01 22:55, Nico Williams pisze:
It would help if cherry-pick history where recorded somewhere (beyond
the reflog)...
Cherry-picks
On Wed, Aug 06, 2014 at 02:10:08PM -0400, Robert P Fischer wrote:
3. The version of git I ran is clearly NOT a plain vanilla official
git, it is a derivative work. Has Apple provided the source code of
the special version that I just ran? If not, that would seem to be a
violation of the
On Aug 6, 2014, at 8:43 AM, Jakub Narębski jna...@gmail.com wrote:
I gave a solution for git using branches and it works just fine. It
retains the simple 3-point merge as well.
It works for this simple case, but I think it has unfortunate potential
to go silently wrong.
That just means
On Wed, Aug 06, 2014 at 10:12:25AM -0700, Junio C Hamano wrote:
I think we want to drop the stash show patch, based on the discussion
we had. The first three patches are nominally prep for that final
patch, but actually are things I've often wanted over the years. I'd be
glad if they
On Wed, Aug 06, 2014 at 02:10:08PM -0400, Robert P Fischer wrote:
I ran git on my newly-set-up OS X Mavericks machine, and get:
$ git
Agreeing to the Xcode/iOS license requires admin privileges,
please re-run as root via sudo.
Running 'git --verision' gives the same
The number of loose objects at which git-gui shows a gc warning has
historically been hardcoded to ~2000, or ~200 on Windows. The warning can
only be disabled completely via gui.gcwarning=false.
Especially on Windows, the hardcoded threshold is so ridiculously low that
git-gui often complains
Am 05.08.2014 20:47, schrieb Jeff King:
On Mon, Aug 04, 2014 at 09:19:46PM +0200, Karsten Blees wrote:
Hmm, I wonder if it wouldn't be simpler to read / write the desired on-disk
structure directly, without copying to a uchar[6] first.
Probably. My initial attempt was to keep together the
On Aug 1, 2014, at 4:40 PM, Nico Williams n...@cryptonector.com wrote:
As for rebase, I still don't understand why it doesn't work for you.
http://git-scm.com/docs/git-rebase says:
Rebasing (or any other form of rewriting) a branch that others have based
work on is a bad idea
If you read
Karsten Blees karsten.bl...@gmail.com writes:
Am 05.08.2014 20:47, schrieb Jeff King:
On Mon, Aug 04, 2014 at 09:19:46PM +0200, Karsten Blees wrote:
Hmm, I wonder if it wouldn't be simpler to read / write the desired on-disk
structure directly, without copying to a uchar[6] first.
On Wed, Aug 06, 2014 at 12:11:16PM -0700, Mike Stump wrote:
On Aug 1, 2014, at 4:40 PM, Nico Williams n...@cryptonector.com wrote:
As for rebase, I still don't understand why it doesn't work for you.
http://git-scm.com/docs/git-rebase says:
Rebasing (or any other form of rewriting) a
On Wed, Aug 6, 2014 at 11:44 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Tanay Abhra tanay...@gmail.com writes:
On 8/5/2014 12:29 AM, Eric Sunshine wrote:
On Mon, Aug 4, 2014 at 2:33 PM, Tanay Abhra tanay...@gmail.com wrote:
- if (skip_prefix(var, http., p)) {
-
On Wed, Aug 06, 2014 at 08:31:18PM +0200, Jakub Narębski wrote:
On Wed, Aug 6, 2014 at 6:26 PM, Nico Williams n...@cryptonector.com wrote:
My proposal was to put this sort of ancillary history info in a
branch object (and that branches should be objects). This would
have a number of
Peyton Randolph prando...@apple.com writes:
Bug v1.9.3: Spurious whitespace warnings when using git apply with the
--exclude option
...
EXPECTED RESULT:
No warning about adding whitespace errors because no whitespace
errors are added to the tree since A is excluded and B has no
whitespace
On Wed, Aug 06, 2014 at 02:44:59PM -0500, Nico Williams wrote:
That means that you have/maintain an intermediate upstream, yes?
This is a bit trickier since once in a while that intermediate upstream
and everyone downstream of it has to catch up with the real upstream.
Here you have two
Am 06.08.2014 um 20:18 schrieb Robert Dailey:
On Wed, Aug 6, 2014 at 12:51 PM, Junio C Hamano gits...@pobox.com wrote:
My knee-jerk reaction would be subtree would break submodules
badly, don't use it ;-).
After all, I invented subtree merge as an ugly interim workaround
before submodule
On 08/06/2014 11:43 AM, Jeff King wrote:
snippage here 8 8
As it happens, though, they _do_ modify the git that they distribute. I know at least that they bake-in the osxkeychain helper config in away that the user cannot turn off. There
may be more changes, but I haven't done a full diff. And
Also, minor nit, but git is GPL, not LGPL.
But Apple put a LGPL license in side the folder. See:
https://www.opensource.apple.com/source/Git/Git-48/src/git/LGPL-2.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More
On Wed, Aug 06, 2014 at 01:23:00PM -0700, Tony wrote:
Also, minor nit, but git is GPL, not LGPL.
But Apple put a LGPL license in side the folder. See:
https://www.opensource.apple.com/source/Git/Git-48/src/git/LGPL-2.1
Interesting. It starts with:
While most of this project is under the
On Wed, Aug 06, 2014 at 12:53:56PM -0700, Bruce Ferrell wrote:
On 08/06/2014 11:43 AM, Jeff King wrote:
snippage here 8 8
As it happens, though, they _do_ modify the git that they distribute. I
know at least that they bake-in the osxkeychain helper config in away that
the user cannot turn
Matthieu Moy matthieu@grenoble-inp.fr writes:
Tanay Abhra tanay...@gmail.com writes:
...
+grep line 7.*.git/config\|.git/config.*line 7 result
+'
This is still dependant on the locale (line is translated). You need
to use test_i18ngrep instead of grep here (see its definition and
On Mon, Aug 04, 2014 at 08:51:42PM +0200, Fabian Ruch wrote:
though I would also not be opposed to some more uniform hook selection
mechanism (e.g., --no-verify=pre-commit or something).
While the --no-verify= mechanism doesn't add a new option to the
git-commit interface but lets one
On Mon, Aug 04, 2014 at 11:21:41PM +0200, Fabian Ruch wrote:
Thanks for laying out the differences in the user visible output. With
stock git we are seeing summaries for other commits, but not root
commits, _with the --verbose option_. It's the fault of my patch to show
the summary even in
Jens Lehmann wrote:
There were thoughts about having git branch optionally create a
branch in the submodule too. But in a lot of real world scenarios
that won't help because the same branch name won't necessarily make
sense in superproject and submodule at the same time
So, here is how I
This started as an attempt to fix a long-time bug, in which a
partial git apply with --exclude/--include still complained about
whitespace breakage in a part that was excluded from patch
application. The final patch fixes it.
Restructuring of the code necessary to fix it revealing another
We will be adding a caller to the function a bit earlier in this
file in a later patch.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/apply.c | 81 ++---
1 file changed, 43 insertions(+), 38 deletions(-)
diff --git
We parse each patchfile and find to what path it applies to and then
use that name to consult the attribute system to find what
whitespace rules to be applied, and also which target file (either
in the working tree or in the index) to replay the changes the patch
represents.
A non-Git patch is
Whitespace breakages are checked while the patch is being parsed.
Disable them at the beginning of parse_chunk(), where each
individual patch is parsed, immediately after we learn what path the
patch applies to and before we start parsing the changes.
One may naively think we should be able to
Jakub Narębski jna...@gmail.com writes:
There was (long time ago) a long thread about idea of adding some
kind of 'weak' references (links), 'weakparent' that can be
automatically used by Git but do not pollute the commit message,
and do not affect reachability calculations. Ultimately it
Junio C Hamano gits...@pobox.com writes:
Jakub Narębski jna...@gmail.com writes:
There was (long time ago) a long thread about idea of adding some
kind of 'weak' references (links), 'weakparent' that can be
automatically used by Git but do not pollute the commit message,
and do not affect
Jonathan Nieder jrnie...@gmail.com writes:
2. Submodules aware of their superproject and of the parent's branches.
In other words, submodules would act as thought under refs/ they
had a symlink
parent - ../../../refs
So you could do
git checkout
Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
2. Submodules aware of their superproject and of the parent's branches.
In other words, submodules would act as though under refs/ they
had a symlink
parent - ../../../refs
So you could do
git
Hi List,
this is the second reroll of the patch series fixing corner-case bugs
regarding empty commits, commits with no log message and root
commits, providing a uniform implementation of the to-do list
commands using the `do_pick` interface.
This reroll includes the following list of changes to
git-rebase--interactive handles empty log messages inconsistently
between enabled and disabled fast-forwards. By default, commits with
empty log messages are rebased successfully like in non-interactive
mode. In contrast, the `--no-ff` option aborts the replay of such
commits.
In line with not
The to-do list commands `squash` and `fixup` apply the changes
introduced by the named commit to the tree but instead of creating
a new commit on top of the current head it replaces the previous
commit with a new commit that records the updated tree. If the
result is an empty commit git-rebase
The to-do list command `reword` replays a commit like `pick` but lets
the user also edit the commit's log message. If `--keep-empty` is
passed as option to git-rebase--interactive, empty commits ought to
be replayed without complaints. However, if the users chooses to
reword an empty commit by
The to-do list command `reword` replays a commit like `pick` but lets
the user also edit the commit's log message. If the edited log
message is empty or is found ill-formatted by one of the commit
hooks, git-rebase--interactive prints three error messages to the
console.
1. The git-commit
git-rebase--interactive prints summary messages of the commits it
creates in the final history only if the `--verbose` option is
specified by the user and suppresses them otherwise. This behaviour
is implemented by wrapping git-commit calls in a shell function named
`output` which redirects stderr
The to-do list command `reword` replays a commit like `pick` but lets
the user also edit the commit's log message. This happens in two
steps. Firstly, the named commit is cherry-picked. Secondly, the
commit created in the first step is amended using an unchanged index
to edit the log message. The
Introduce the git-commit command line options `--no-pre-commit` and
`--no-commit-msg` to disable the pre-commit and commit-msg hooks,
respectively. Make `--no-verify` a synonym for specifying both at the
same time.
This change is motivated by an internal usage of git-commit in
`do_pick` is the git-cherry-pick wrapper in git-rebase--interactive
that is used to implement the to-do list command `pick`. To cater for
the different pick behaviours (like `reword`), `do_pick` accepts
several options not only from the git-cherry-pick but also the
git-commit interface. Add the
`do_pick` is the git-cherry-pick wrapper in git-rebase--interactive
that is used to implement the to-do list commands `pick`, `reword`
and `edit`. To cater for the different pick behaviours (like
`squash`), `do_pick` accepts several options not only from the
git-cherry-pick but also the git-commit
Read in to-do list lines as
command args
instead of
command sha1 rest
so that to-do list command lines can specify additional arguments
apart from the commit hash and the log message title, which become
the non-options in `args`. Loop over `args`, put all options (an
argument beginning
`do_pick` is the git-cherry-pick wrapper in git-rebase--interactive
that is used to implement the to-do list command `pick`, `reword` and
`edit`. To cater for the different pick behaviours (like `squash`),
`do_pick` accepts several options not only from the git-cherry-pick
but also the git-commit
95 matches
Mail list logo
