I used 1.9.2 before, it was installed with brew as well.
I didn’t found Git.pm under /usr/local/Cellar/git/,
/usr/local/Cellar/git/2.0.3/, and I looked at /usr/local/Cellar/git/1.9.2/,
there isn’t a Git.pm either.
type perl says:
perl is /usr/bin/perl
Additionally, perl --version says:
This is
brian m. carlson crustytoothpaste.net> writes:
>
> On Mon, Jul 28, 2014 at 05:56:28PM -0700, Michael Migdol wrote:
> > Sorry for error -- I meant: git stash list -p, not git stash -p.
> >
> > On Mon, Jul 28, 2014 at 5:38 PM, Michael Migdol
migdol.net> wrote:
> > > I recently upgraded from Ubun
On 07/27/2014 05:26 PM, Guang Chen wrote:
I use brew upgrade git to this version on OSX. And when I use git add -i, it
says:
Which version did you use before?
Was it installed with brew as well ?
Can't locate Git.pm in @INC (@INC contains: @@@/git/2.0.3/lib/perl5/site_perl
/Applications/Xcod
On 07/28/2014 12:39 PM, Duy Nguyen wrote:
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 hom
On 24.07.2014 06:39, Jeff King wrote:
> Since Stefan has recently started feeding git builds to coverity, I
> spent a few minutes poking through the results. There are tons of false
> positives, so there is some work to be done there with tweaking our
> coverity models. But there are some real issu
Remotes are stored as an array, so looking one up or adding one without
duplication is an O(n) operation. Reading an entire config file full of
remotes is O(n^2) in the number of remotes. For a repository with tens of
thousands of remotes, the running time can hit multiple minutes.
Hash tables a
On Mon, Jul 28, 2014 at 05:56:28PM -0700, Michael Migdol wrote:
> Sorry for error -- I meant: git stash list -p, not git stash -p.
>
> On Mon, Jul 28, 2014 at 5:38 PM, Michael Migdol
> wrote:
> > I recently upgraded from Ubuntu 13.10 to Ubuntu 14.04. After doing so,
> > "git stash -p" stopped w
On Tue, Jul 29, 2014 at 10:11 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
Yeah, I'm fine with a straight revert, too (I think it is fine to keep
in master, though). I think jk/alloc-commit-id is built right on top of
the original commit-slab topic, so it should be easy to
Sorry for error -- I meant: git stash list -p, not git stash -p.
On Mon, Jul 28, 2014 at 5:38 PM, Michael Migdol wrote:
> I recently upgraded from Ubuntu 13.10 to Ubuntu 14.04. After doing so,
> "git stash -p" stopped working. (It apparently is ignoring the -p
> parameter). I'm not sure what v
I recently upgraded from Ubuntu 13.10 to Ubuntu 14.04. After doing so,
"git stash -p" stopped working. (It apparently is ignoring the -p
parameter). I'm not sure what version I was using previously, but after
some experimentation, I see that:
version 1.7.12.2 : stash -p DOES work
version 1.9.3
Junio C Hamano writes:
>>> Yeah, I'm fine with a straight revert, too (I think it is fine to keep
>>> in master, though). I think jk/alloc-commit-id is built right on top of
>>> the original commit-slab topic, so it should be easy to do either way.
>>>
>>> Thanks for dealing with it.
>>
>> Whate
Noticed-by: Jeff King
---
abspath.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/abspath.c b/abspath.c
index 16e7fa2..6aa328f 100644
--- a/abspath.c
+++ b/abspath.c
@@ -58,7 +58,7 @@ static const char *real_path_internal(const char *path, int
die_on_error)
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
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
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
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
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
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.
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 `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`
`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. 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
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
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
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
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
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
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
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) {
>
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
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
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.
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
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
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: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:
> 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 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: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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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 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
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
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
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
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
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 |
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 {
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
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
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
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]
>> +
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
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:
> 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:
> +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:
> [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
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 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
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
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
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
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
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
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
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
1 - 100 of 112 matches
Mail list logo
