Using git diff-tree --stdin on 2.0.2 and 2.0.3 produces incorrect
commit messages.
Here's an example to reproduce the issue:
bturner@ubuntu:/tmp$ git init --bare test.git
Initialized empty Git repository in /tmp/test.git/
bturner@ubuntu:/tmp$ git clone test.git
Cloning into 'test'...
warning: You
[v13]: v12 was rejected because of redundant implementation of the new
functions,
hope this one is okay.
I am attaching the v13 with two new functions git_configset_get_string() &
git_configset_get_string_const().
Diff between v11 and v13 is appended below for easy review.
v11 can be see
Expose the `config_set` C API as a set of simple commands in order to
facilitate testing. Add tests for the `config_set` API as well as for
`git_config_get_*()` family for the usual config files.
Signed-off-by: Matthieu Moy
Signed-off-by: Tanay Abhra
---
.gitignore| 1 +
Makefile
Currently `git_config()` uses a callback mechanism and file rereads for
config values. Due to this approach, it is not uncommon for the config
files to be parsed several times during the run of a git program, with
different callbacks picking out different variables useful to themselves.
Add a `con
On 28/07/14 10:42, Bryan Turner wrote:
> Using git diff-tree --stdin on 2.0.2 and 2.0.3 produces incorrect
> commit messages.
>
> Here's an example to reproduce the issue:
>
> bturner@ubuntu:/tmp$ git init --bare test.git
> Initialized empty Git repository in /tmp/test.git/
> bturner@ubuntu:/tmp$
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
[PATCH V3]:All the suggestions in [3] applied. Built on top of [1].
[PATCH V2]: All the suggestions in [2] incorporated. git_config() now follows
correct parsing order. Reordered the patches. Removed xfuncname patch
as it was unnecssary.
This series builds on the top of topic[1] i
On Mon, Jul 28, 2014 at 07:42:16PM +1000, Bryan Turner wrote:
> Running a git bisect between v2.0.1, which does not manifest this
> issue, and v2.0.2 fingers the following commit:
> bturner@ubuntu:~/Development/oss/git/git$ git bisect bad
> c1b3c71f4b4571abb2b2a457122fd100dc9f7eb0 is the first bad
From: Matthieu Moy
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 just parsed during the
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: Ta
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
---
config.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/config.c b/config.c
index e5b7f10..5499108 100644
---
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
---
t/t1308-config-set.sh | 9 +
test-config.c | 10 ++
2 files changed, 19 insertio
Add `git_die_config` that dies printing the line number and the file name
of the highest priority value for the configuration variable `key`.
It has usage in non-callback based config value retrieval where we can
raise an error and die if there is a semantic error.
For example,
if (!git_c
I know wine is kind of second citizen but is there a cheap trick to
make it work on wine? Reverting fcd428f (Win32: fix broken pipe
detection - 2012-03-01) could result in conflicts in compat that I'm
not comfortable resolving. I don't have Windows at home. Wine is the
only option for me (or if som
Replace TODO introduced in commit 9c3c22 with documentation
explaining Git config API functions for writing configuration
files.
Signed-off-by: Tanay Abhra
---
Documentation/technical/api-config.txt | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git
On Mon, Jul 28, 2014 at 06:35:04AM -0400, Jeff King wrote:
> I haven't reproduced here yet, but this is almost certainly the bug
> where lookup_unknown_object causes a bogus commit->index field (and
> prior to the commit you found, diff-tree did not use commit->index).
>
> The series that Junio h
Some MUAs delete their "drafts" folder when it is empty, so
git imap-send should be able to create it if necessary.
This change checks that the folder exists immediately after
login and tries to create it if it is missing.
There was some vestigial code to handle a [TRYCREATE] response
from the se
Explicitly mention that leaving imap.authMethod unset makes
git imap-send use the basic IMAP plaintext LOGIN command.
---
Documentation/git-imap-send.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-imap-send.txt b/Documentation/git-imap-send.txt
index 87
On 28/07/14 11:33, Tanay Abhra wrote:
> Add `git_die_config` that dies printing the line number and the file name
> of the highest priority value for the configuration variable `key`.
>
> It has usage in non-callback based config value retrieval where we can
> raise an error and die if there is a
On 7/28/2014 4:25 PM, Ramsay Jones wrote:
> On 28/07/14 11:33, Tanay Abhra wrote:
>> Add `git_die_config` that dies printing the line number and the file name
>> of the highest priority value for the configuration variable `key`.
>>
>> It has usage in non-callback based config value retrieval where
Explicitly mention that leaving imap.authMethod unset makes
git imap-send use the basic IMAP plaintext LOGIN command.
---
Documentation/git-imap-send.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-imap-send.txt b/Documentation/git-imap-send.txt
index 87
Tanay Abhra writes:
> [v13]: v12 was rejected because of redundant implementation of the new
> functions,
> hope this one is okay.
It is to me at least.
Thanks,
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the bod
Tanay Abhra writes:
> +void git_die_config(const char *key)
> +{
> + const struct string_list *values;
> + struct key_value_info *kv_info;
> + values = git_config_get_value_multi(key);
> + kv_info = values->items[values->nr - 1].util;
> + if (!kv_info->linenr)
> +
Tanay Abhra writes:
> On 7/28/2014 4:25 PM, Ramsay Jones wrote:
>> On 28/07/14 11:33, Tanay Abhra wrote:
>>> + if (!kv_info->linenr)
>>> + die("unable to parse command-line config");
>>> + else
>>> + die("bad config file line %d in %s",kv_info->linenr,
>>> kv_info->filena
Tanay Abhra writes:
> +test_expect_success 'check line errors for malformed values' '
> + mv .git/config .git/config.old &&
> + test_when_finished "mv .git/config.old .git/config" &&
> + cat >.git/config <<-\EOF &&
> + [alias]
> + br
> + EOF
> + test_expect_cod
Tanay Abhra writes:
> [PATCH V3]:All the suggestions in [3] applied. Built on top of [1].
Except for the minor style fix in PATCH 5, the series looks OK to me.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a me
On 7/28/2014 4:52 PM, Matthieu Moy wrote:
> Tanay Abhra writes:
>
>> +test_expect_success 'check line errors for malformed values' '
>> +mv .git/config .git/config.old &&
>> +test_when_finished "mv .git/config.old .git/config" &&
>> +cat >.git/config <<-\EOF &&
>> +[alias]
>> +
I’m creating a git clone of a svn repository and am trying to set up an authors
file to map between the svn users and our git usernames. The svn repository
uses the full subject line of a ssl certificate for the user id and so it
contains ‘=’ which causes the authors file to be parsed incorrectl
Tanay Abhra writes:
> On 7/28/2014 4:52 PM, Matthieu Moy wrote:
>> Tanay Abhra writes:
>>
>>> +test_expect_success 'check line errors for malformed values' '
>>> + mv .git/config .git/config.old &&
>>> + test_when_finished "mv .git/config.old .git/config" &&
>>> + cat >.git/config <<-\EOF
This is the polished version of v2 [1], rebased on master (now that
split-index has graduated). I wanted to add some tests, but can't
think of any way to do it (at least it won't work on Windows).
Although with --strict turned on by default, it's less likely that
bugs in index-helper could propagat
Signed-off-by: Nguyễn Thái Ngọc Duy
---
read-cache.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/read-cache.c b/read-cache.c
index 5d3c8bd..949270b 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1324,7 +1324,7 @@ struct ondisk_cache_entry_extended {
Signed-off-by: Nguyễn Thái Ngọc Duy
---
cache.h | 3 +++
read-cache.c | 13 -
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/cache.h b/cache.h
index 1c84227..978e53d 100644
--- a/cache.h
+++ b/cache.h
@@ -306,10 +306,13 @@ struct index_state {
struct spli
trace_stats() is intended for GIT_TRACE_*_STATS variable group and
GIT_TRACE_PACK_STATS is more like an example how new vars can be added.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git.txt | 3 +++
cache.h | 2 ++
git.c | 1 +
sha1_file.c |
This allows signal handlers and atexit functions to realize this
situation and not clean up.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/gc.c | 2 +-
cache.h | 2 +-
daemon.c | 2 +-
setup.c | 4 +++-
4 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/builtin/gc.c b
There's are "holes" in the index-helper approach because the shared
memory is not verified again by git. If $USER is compromised, shared
memory could be modified. But then they can already modify
$GIT_DIR/index. A more realistic risk is some bugs in index-helper
produce corrupt shared memory. --str
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git.txt | 1 +
cache.h | 1 +
read-cache.c | 16
trace.c | 5 -
4 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/Documentation/git.txt b/Documentation/git.txt
index a12
Instead of reading the index from disk and worrying about disk
corruption, the index is cached in memory (memory bit-flips happen
too, but hopefully less often). The result is faster read.
The biggest gain is not having to verify the trailing SHA-1, which
takes lots of time especially on large ind
Windows supports shared memory, but the semantics is a bit different
than POSIX shm. The most noticeable thing is there's no way to get the
shared memory's size by the reader, and wrapping fstat to do that
would be hell. So the shm size is added near the end, hidden away from
shm users (storing it
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-index-helper.txt | 3 +++
index-helper.c | 10 --
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-index-helper.txt
b/Documentation/git-index-helper.txt
index 406856d..d8fbdab
On Mon, Jul 28, 2014 at 8:44 PM, Jeff King wrote:
> On Mon, Jul 28, 2014 at 06:35:04AM -0400, Jeff King wrote:
>
>> I haven't reproduced here yet, but this is almost certainly the bug
>> where lookup_unknown_object causes a bogus commit->index field (and
>> prior to the commit you found, diff-tree
Bryan Turner writes:
> It looks like refs ending in a dot are now legal in 2.1.0? Is that
> intentional? A quick git bisect is fingering:
> bturner@ubuntu:~/Development/oss/git/git$ git bisect bad
> 745224e04a03e4544c58d5d38d3c54f67100f8eb is the first bad commit
> commit 745224e04a03e4544c58d5d3
On Mon, Jul 28, 2014 at 08:35:52AM -0700, Junio C Hamano wrote:
> I am tempted to revert that series; it already caused "oops, this
> needs a further fix" before it hit 'master' at least once, and we do
> not want any more headaches at this point in the release cycle.
Yeah, that sounds reasonable
Hi Karsten,
The hashmap_entry documentation claims:
`struct hashmap_entry`::
An opaque structure representing an entry in the hash table,
which must be used as first member of user data structures.
Ideally it should be followed by an int-sized member to prevent
Jeff King writes:
> On Mon, Jul 28, 2014 at 07:42:16PM +1000, Bryan Turner wrote:
>
>> Running a git bisect between v2.0.1, which does not manifest this
>> issue, and v2.0.2 fingers the following commit:
>> bturner@ubuntu:~/Development/oss/git/git$ git bisect bad
>> c1b3c71f4b4571abb2b2a457122fd1
On Mon, Jul 28, 2014 at 10:32:45AM -0700, Junio C Hamano wrote:
> > Junio, we should consider a v2.0.4 with that series, I think. This is a
> > pretty serious regression in diff-tree (I didn't even realize that the
> > buffer-slab work went into the maint series; that may have been a little
> > am
On Fri, Jul 25, 2014 at 12:37 PM, Jonathan Nieder wrote:
> Ronnie Sahlberg wrote:
>
>> Add a new flag REFLOG_EMAIL_IS_COMMITTER to _update_reflog to tell it
>> that what we pass in as email is already the fully baked committer string
>> we can use as-is.
>
> With and without the new flag, the 'ema
On Mon, Jul 28, 2014 at 01:37:34PM -0400, Jeff King wrote:
> On Mon, Jul 28, 2014 at 10:32:45AM -0700, Junio C Hamano wrote:
>
> > > Junio, we should consider a v2.0.4 with that series, I think. This is a
> > > pretty serious regression in diff-tree (I didn't even realize that the
> > > buffer-sl
Jeff King writes:
> On Mon, Jul 28, 2014 at 01:37:34PM -0400, Jeff King wrote:
>
>> On Mon, Jul 28, 2014 at 10:32:45AM -0700, Junio C Hamano wrote:
>>
>> > > Junio, we should consider a v2.0.4 with that series, I think. This is a
>> > > pretty serious regression in diff-tree (I didn't even reali
Paths longer than PATH_MAX can be created and used on at least on some
file systems. Currently we use getcwd() generally with a PATH_MAX-
sized buffer. This series adds two functions, strbuf_getcwd() and
xgetcwd(), then uses them to reduce the number of fixed-sized buffers
and to allow us to hand
Add strbuf_getcwd(), which puts the current working directory into a
strbuf. Because it doesn't use a fixed-size buffer it supports
arbitrarily long paths, provided the platform's getcwd() does as well.
At least on Linux and FreeBSD it handles paths longer than PATH_MAX
just fine.
Suggested-by: K
Instead of using a PATH_MAX-sized buffer, which can be too small on some
file systems, use strbuf_getcwd(), which handles any path getcwd()
returns. Also preserve the errno set by strbuf_getcwd() instead of
setting it to ENAMETOOLONG; that way a more appropriate error message
can be shown based on
Convert setup_git_directory_gently_1() and its helper functions
setup_explicit_git_dir(), setup_discovered_git_dir() and
setup_bare_git_dir() to use a struct strbuf to hold the current working
directory. Replacing the PATH_MAX-sized buffer used before removes a
path length limition on some file sy
Store the original working directory in a strbuf instead of in a
fixed-sized buffer, in order to be able to handle longer paths.
Signed-off-by: Rene Scharfe
---
abspath.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/abspath.c b/abspath.c
index ca33558..911e931 100
Add the helper function xgetcwd(), which returns the current directory
or dies. The returned string has to be free()d after use.
Helped-by: Duy Nguyen
Signed-off-by: Rene Scharfe
---
git-compat-util.h | 1 +
wrapper.c | 8
2 files changed, 9 insertions(+)
diff --git a/git-com
Use strbuf instead of fixed-sized buffers in real_path() in order to
avoid the size limitations of the latter.
Signed-off-by: Rene Scharfe
---
abspath.c | 69 +++
1 file changed, 25 insertions(+), 44 deletions(-)
diff --git a/abspath.c
Convert several calls of getcwd() and die() to use xgetcwd() instead.
This way we get rid of fixed-size buffers (which can be too small
depending on the used file system) and gain consistent error messages.
Signed-off-by: Rene Scharfe
---
builtin/init-db.c | 17 -
builtin/rev-p
Instead of dying of a segmentation fault if getcwd() returns NULL, use
xgetcwd() to make sure to write a useful error message and then exit
in an orderly fashion.
Suggested-by: Jeff King
Signed-off-by: Rene Scharfe
---
builtin/init-db.c | 7 +++
git.c | 5 +++--
2 files changed,
Move most of the code of absolute_path() into the new function
strbuf_add_absolute_path() and in the process transform it to use
struct strbuf and xgetcwd() instead of a PATH_MAX-sized buffer,
which can be too small on some file systems.
Signed-off-by: Rene Scharfe
---
Documentation/technical/ap
Signed-off-by: Rene Scharfe
---
exec_cmd.c | 6 +-
sha1_file.c | 2 +-
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/exec_cmd.c b/exec_cmd.c
index 125fa6f..698e752 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -86,11 +86,7 @@ const char *git_exec_path(void)
static void add_pa
Store the original working directory in a strbuf instead of in a
fixed-sized buffer, in order to be able to handle longer paths.
Signed-off-by: Rene Scharfe
---
Resent with corrected subject.
abspath.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/abspath.c b/absp
Feeding the result of a real_path() call to real_path() again doesn't
change that result -- the returned path won't get any more real. Avoid
such a double call in set_git_dir_init() and for the same reason stop
calling real_path() before feeding paths to set_git_work_tree(), as the
latter already
On Mon, Jul 28, 2014 at 08:25:40PM +0200, René Scharfe wrote:
> Instead of using a PATH_MAX-sized buffer, which can be too small on some
> file systems, use strbuf_getcwd(), which handles any path getcwd()
> returns. Also preserve the errno set by strbuf_getcwd() instead of
> setting it to ENAMET
On Fri, Jul 25, 2014 at 12:40 PM, Jonathan Nieder wrote:
> Ronnie Sahlberg wrote:
>
>> --- a/refs.c
>> +++ b/refs.c
>> @@ -2214,7 +2214,7 @@ static struct ref_lock *lock_ref_sha1_basic(const char
>> *refname,
>>*/
>> goto retry;
>> else
On Mon, Jul 28, 2014 at 08:28:30PM +0200, René Scharfe wrote:
> static const char *real_path_internal(const char *path, int die_on_error)
> {
> - static char bufs[2][PATH_MAX + 1], *buf = bufs[0], *next_buf = bufs[1];
> + static struct strbuf sb = STRBUF_INIT;
Hrm. I thought at first th
On Mon, Jul 28, 2014 at 08:33:55PM +0200, René Scharfe wrote:
> const char *absolute_path(const char *path)
> {
> - static char buf[PATH_MAX + 1];
> -
> - if (!*path) {
> - die("The empty string is not a valid path");
> - } else if (is_absolute_path(path)) {
> -
On Mon, Jul 28, 2014 at 08:28:30PM +0200, René Scharfe wrote:
> @@ -60,26 +58,22 @@ static const char *real_path_internal(const char *path,
> int die_on_error)
> goto error_out;
> }
>
> - if (strlcpy(buf, path, PATH_MAX) >= PATH_MAX) {
> - if (die_on_
On Mon, Jul 28, 2014 at 08:21:22PM +0200, René Scharfe wrote:
> Paths longer than PATH_MAX can be created and used on at least on some
> file systems. Currently we use getcwd() generally with a PATH_MAX-
> sized buffer. This series adds two functions, strbuf_getcwd() and
> xgetcwd(), then uses t
Jonathan Nieder writes:
> David Besen wrote:
>> Jonathan Nieder wrote:
>
>>> This is how pull --rebase works. It turns your single-parent commits
>>> into a sequence of patches on top of upstream and completely ignores
>>> your merge commits.
>>>
>>> There is a --rebase=preserve option that make
Sergei Organov wrote:
> Is there any scenario at all where pull --rebase=true wins over
> preserve?
Basically always in my book. ;-)
When people turn on 'pull --rebase', they are asking for a clean,
simplified history where their changes are small discrete patches in a
clump on top of upstream.
On Mon, Jul 28, 2014 at 11:33:23AM +, David Braden wrote:
> I’m creating a git clone of a svn repository and am trying to set up
> an authors file to map between the svn users and our git usernames.
> The svn repository uses the full subject line of a ssl certificate for
> the user id and so i
Jonathan Nieder writes:
> Sergei Organov wrote:
>
>> Is there any scenario at all where pull --rebase=true wins over
>> preserve?
>
> Basically always in my book. ;-)
>
> When people turn on 'pull --rebase', they are asking for a clean,
> simplified history where their changes are small discrete
Jeff King writes:
> On Mon, Jul 28, 2014 at 08:28:30PM +0200, René Scharfe wrote:
>
>> @@ -60,26 +58,22 @@ static const char *real_path_internal(const char *path,
>> int die_on_error)
>> goto error_out;
>> }
>>
>> -if (strlcpy(buf, path, PATH_MAX) >= PATH_MAX) {
>
On Mon, Jul 28, 2014 at 3:00 PM, Jonathan Nieder wrote:
> Sergei Organov wrote:
>
>> Is there any scenario at all where pull --rebase=true wins over
>> preserve?
>
> Basically always in my book. ;-)
>
> When people turn on 'pull --rebase', they are asking for a clean,
> simplified history where th
From: "Junio C Hamano"
Sent: Friday, July 25, 2014 11:08 PM
* po/everyday-doc (2014-01-27) 1 commit
- Make 'git help everyday' work
Let's disect it. I do not have time/concentration to finish all in
one message, so I'll do the first two.
Thanks for the guidance. I'll work on updating the
Am 28.07.2014 um 21:09 schrieb Jeff King:
On Mon, Jul 28, 2014 at 08:28:30PM +0200, René Scharfe wrote:
static const char *real_path_internal(const char *path, int die_on_error)
{
- static char bufs[2][PATH_MAX + 1], *buf = bufs[0], *next_buf = bufs[1];
+ static struct strbuf sb
Am 28.07.2014 um 21:15 schrieb Jeff King:
On Mon, Jul 28, 2014 at 08:33:55PM +0200, René Scharfe wrote:
const char *absolute_path(const char *path)
{
- static char buf[PATH_MAX + 1];
-
- if (!*path) {
- die("The empty string is not a valid path");
- } else if
Hi,
this is a reroll of the patch series that enables rudimentary support
of line options for git-rebase's to-do list commands and reimplements
the well-known commands `reword` and `squash` in terms of a
parameterised `do_pick`.
I tried to address all the issues raised by Junio in this reroll.
He
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 outp
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 chan
`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
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 `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 p
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 `r
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`
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 opti
`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
git-cher
`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 now
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 ver
`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 com
`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 i
The command line used to recreate root commits specifies the
effectless option `-C`. It makes git-commit reuse commit message and
authorship of the named commit. However, the commit being amended
here, which is the sentinel commit, already carries the authorship
and log message of the commit being
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 fixu
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
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 c
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 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 handli
On Mon, Jul 28, 2014 at 2:26 PM, René Scharfe wrote:
> Convert setup_git_directory_gently_1() and its helper functions
> setup_explicit_git_dir(), setup_discovered_git_dir() and
> setup_bare_git_dir() to use a struct strbuf to hold the current working
> directory. Replacing the PATH_MAX-sized buf
On Mon, Jul 28, 2014 at 2:01 PM, Ronnie Sahlberg wrote:
> On Fri, Jul 25, 2014 at 12:37 PM, Jonathan Nieder wrote:
>> Ronnie Sahlberg wrote:
>>> /*
>>> * Append a reflog entry for refname. If the REFLOG_TRUNCATE flag is set
>>> * this update will first truncate the reflog before writing the
Am 28.07.2014 um 23:42 schrieb Junio C Hamano:
Jeff King writes:
On Mon, Jul 28, 2014 at 08:28:30PM +0200, René Scharfe wrote:
@@ -60,26 +58,22 @@ static const char *real_path_internal(const char *path, int
die_on_error)
goto error_out;
}
- if (strlcpy
Noticed-by: Jeff King
---
abspath.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/abspath.c b/abspath.c
index cf9b404..5edb4e7 100644
--- a/abspath.c
+++ b/abspath.c
@@ -146,8 +146,8 @@ const char *real_path_if_valid(const char *path)
*/
const char *absolute_path(cons
1 - 100 of 112 matches
Mail list logo
