On Tue, Feb 14, 2017 at 12:56 PM, Maxim Kuvyrkov
wrote:
> I'm seeing the following memory corruption crash on a script-constructed repo
> when starting git bisect. I'm seeing this crash both with system git of
> Ubuntu Xenial and with freshly-compiled git master from
On 02/14/2017 10:04 AM, Jeff King wrote:
On Tue, Feb 14, 2017 at 08:53:04AM -0800, Jonathan Tan wrote:
On 02/13/2017 10:07 PM, Jeff King wrote:
diff --git a/builtin/grep.c b/builtin/grep.c
index e83b33bda..c4c632594 100644
--- a/builtin/grep.c
+++ b/builtin/grep.c
@@ -1176,6 +1176,12 @@ int
Johannes Sixt writes:
> Am 14.02.2017 um 15:47 schrieb Johannes Schindelin:
>
>>>From my point of view, it is not crucial. The next Git for Windows version
>> will have it, of course, and Hannes is always running with his set of
>> patches, he can easily cherry-pick this one, too.
Johannes Schindelin writes:
>> OK. Should this go directly to 'master', as the isatty thing is
>> already in?
>
> From my point of view, it is not crucial. The next Git for Windows version
> will have it, of course, and Hannes is always running with his set of
>
Jeff King writes:
> If we see "git grep pattern rev -- file" then we apply the
> usual rev/pathspec disambiguation rules: any "rev" before
> the "--" must be a revision, and we do not need to apply the
> verify_non_filename() check.
>
> But there are two bugs here:
>
> 1. We
hi!
I am using git-p4.py to migrate a lot of medium and large Perforce
depots into git. I almost exclusively go one way: from Perforce to
git. I also frequently re-clone/re-migrate as the Perforce migration
client spec is refined.
For this, I have added rudimentary caching in git-p4.py so that
Hello,
Am 14.02.2017 um 15:47 schrieb Johannes Schindelin:
On Mon, 13 Feb 2017, Junio C Hamano wrote:
Johannes Schindelin writes:
When removing the hack for isatty(), we actually removed more than just
an isatty() hack: we removed the hack where internal data structures
On 02/14, Jeff King wrote:
> - /* Is it a rev? */
> - if (!get_sha1_with_context(arg, 0, sha1, )) {
> - struct object *object = parse_object_or_die(sha1, arg);
> - if (!seen_dashdash)
> -
Hey Peff,
On Tue, Feb 14, 2017 at 10:58 PM, Jeff King wrote:
> We make several starts_with() calls, only to advance
> pointers. This is exactly what skip_prefix() is for, which
> lets us avoid manually-counted magic numbers.
>
> Signed-off-by: Jeff King
> ---
>
On Tue, Feb 14, 2017 at 08:53:04AM -0800, Jonathan Tan wrote:
> On 02/13/2017 10:07 PM, Jeff King wrote:
> > diff --git a/builtin/grep.c b/builtin/grep.c
> > index e83b33bda..c4c632594 100644
> > --- a/builtin/grep.c
> > +++ b/builtin/grep.c
> > @@ -1176,6 +1176,12 @@ int cmd_grep(int argc, const
Nguyễn Thái Ngọc Duy writes:
> All these warning() calls are preceded by a system call. Report the
> actual error to help the user understand why we fail to remove
> something.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> v2 dances with errno
Thanks.
On 02/14, Jeff King wrote:
> Originally, we set up the threads for grep before parsing
> the non-option arguments. In 53b8d931b (grep: disable
> threading in non-worktree case, 2011-12-12), the thread code
> got bumped lower in the function because it now needed to
> know whether we got any
This is my fault: this is a lightweight tag.
Thank you!
2017-02-13 21:35 GMT+01:00 Junio C Hamano :
> Kevin Daudt writes:
>
>> On Sun, Feb 12, 2017 at 01:15:22PM +0100, Istvan Pato wrote:
>>
>>> (master) [1] % git show-ref --tag
>>> 76c634390... refs/tags/1.0.0
On Tue, Feb 14, 2017 at 6:35 AM, Stefan Beller wrote:
>> + git_dir = read_gitfile(buf.buf);
>
> if buf.buf is a (git) directory as opposed to a git file,
> we error out in read_gitfile. Did you mean to use
> read_gitfile_gently here or rather even resolve_gitdir_gently ?
On Tue, Feb 14, 2017 at 6:55 AM, Stefan Beller wrote:
>>
>> +/*
>> + * Return the ref_store instance for the specified submodule. For the
>> + * main repository, use submodule==NULL; such a call cannot fail.
>
> So now we have both a get_main as well as a get_submodule
From: Jeff Hostetler
The existing code called memihash() to pass to the find_dir_entry()
function, and if not found, called memihash() again to pass to the
hashmap_add() function. Remove that duplicate memihash() call in
hash_dir_entry().
Signed-off-by: Jeff Hostetler
From: Jeff Hostetler
There are times when we compute the hash on
a full path and then the hash on just the path to the parent
directory. This can be expensive on large repositories.
With the new memihash_continue() function, we can hash the parent
directory first, and
On Windows, calls to memihash() and maintaining the istate.name_hash and
istate.dir_hash HashMaps take significant time on very large
repositories. This series of changes reduces the overall time taken for
various operations by reducing the number calls to memihash(), moving
some of them into
From: Jeff Hostetler
Precompute the istate.name_hash and istate.dir_hash values
for each cache-entry during the preload-index phase.
Move the expensive memihash() calculations from lazy_init_name_hash()
to the multi-threaded preload-index phase.
Signed-off-by: Jeff
From: Jeff Hostetler
Teach hash_dir_entry() to remember the previously found dir_entry during
lazy_init_name_hash() iteration. This is a performance optimization.
Since items in the index array are sorted by full pathname, adjacent
items are likely to be in the same
From: Jeff Hostetler
Specify an initial size for the istate.dir_hash hash map matching the
size of the istate.name_hash.
Previously hashmap_init() was given 0, causing a 64 bucket hashmap to be
created. When working with very large repositories, this would cause
numerous
I'm seeing the following memory corruption crash on a script-constructed repo
when starting git bisect. I'm seeing this crash both with system git of Ubuntu
Xenial and with freshly-compiled git master from the official repo.
The log of the crash is attached.
It is possible that the bug is in
All these warning() calls are preceded by a system call. Report the
actual error to help the user understand why we fail to remove
something.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
v2 dances with errno
builtin/clean.c | 19 ++-
1 file changed, 14
On Tue, Feb 14, 2017 at 3:58 AM, Ramsay Jones
wrote:
>> -void files_path(struct files_ref_store *refs, struct strbuf *sb,
>> - const char *fmt, ...) __attribute__((format (printf, 3, 4)));
>
> You only added this in the last commit, so maybe mark it static
On Tue, Feb 14, 2017 at 6:09 AM, Stefan Beller wrote:
>> +
>> + if (submodule) {
>> + refs->submodule = xstrdup_or_null(submodule);
>
> drop the _or_null here?
>
> So in this patch we have either
> * submodule set
> * or gitdir/gitcommondir set
>
> which
On Thu, Feb 09, 2017 at 12:20:34AM -0500, Jeff King wrote:
> On Wed, Feb 08, 2017 at 09:14:17PM -0800, Junio C Hamano wrote:
> > Jeff King writes:
> (I _do_ think Stefan's proposed direction is worth it simply because the
> result is easier to read, but I agree the whole thing can
On 02/13/2017 10:00 PM, Jeff King wrote:
I've fixed that, along with a few other bugs and cleanups. The complete
series is below. Patch 2 is your (untouched) patch. My suggestions for
your test are in patch 3, which can either remain on its own or be
squashed in.
[1/7]: grep: move thread
On Tue, Feb 14, 2017 at 1:40 AM, Duy Nguyen wrote:
> On Tue, Feb 14, 2017 at 5:37 AM, Stefan Beller wrote:
>> On Mon, Feb 13, 2017 at 7:20 AM, Nguyễn Thái Ngọc Duy
>> wrote:
>>> All refs outside refs/ directory is per-worktree, not just
On 02/13/2017 10:07 PM, Jeff King wrote:
diff --git a/builtin/grep.c b/builtin/grep.c
index e83b33bda..c4c632594 100644
--- a/builtin/grep.c
+++ b/builtin/grep.c
@@ -1176,6 +1176,12 @@ int cmd_grep(int argc, const char **argv, const char
*prefix)
break;
}
On Tue, Feb 14, 2017 at 04:48:16PM +0100, Christian Couder wrote:
> @@ -791,11 +791,11 @@ int cmd_show_branch(int ac, const char **av, const char
> *prefix)
> head_oid.hash, NULL);
> if (head_p) {
> head_len = strlen(head_p);
> -
This is a minimum fix for a crash with a long ref name.
Note that if the refname is too long (for example if you
use 100 instead of 50 in the test script) you could get
an error like:
fatal: cannot lock ref 'refs/heads/1_2_3_4_ ... _98_99_100_':
Unable to create '... /.git/refs/heads/1_2_3_4_
We copy the result of resolving HEAD into a buffer and keep
track of its length. But we never actually use the length
for anything besides the copy. Let's stop passing it around.
Signed-off-by: Jeff King
---
builtin/show-branch.c | 8 ++--
1 file changed, 2 insertions(+), 6
We resolve HEAD and copy the result to a fixed-size buffer
with memcpy, never checking that it actually fits. This bug
dates back to 8098a178b (Add git-symbolic-ref, 2005-09-30).
Before that we used readlink(), which took a maximum buffer
size.
We can fix this by using resolve_refdup(), which
We make several starts_with() calls, only to advance
pointers. This is exactly what skip_prefix() is for, which
lets us avoid manually-counted magic numbers.
Signed-off-by: Jeff King
---
builtin/show-branch.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
On Tue, Feb 14, 2017 at 3:14 AM, Ramsay Jones
wrote:
>
>
> On 13/02/17 15:20, Nguyễn Thái Ngọc Duy wrote:
>> Created in 5f3c3a4e6f (files_log_ref_write: new function - 2015-11-10)
>> but probably never used outside refs-internal.c
>>
>> Signed-off-by: Nguyễn Thái Ngọc
On Tue, Feb 14, 2017 at 5:37 AM, Stefan Beller wrote:
> On Mon, Feb 13, 2017 at 7:20 AM, Nguyễn Thái Ngọc Duy
> wrote:
>> All refs outside refs/ directory is per-worktree, not just HEAD.
>>
>> Signed-off-by: Nguyễn Thái Ngọc Duy
>> ---
Duy Nguyen writes:
> Direct call sites are just middle men though, e.g.
> for_each_ref_submodule(). I'll attempt to clean this up at some point
> in future (probably at the same time I attempt to kill *_submodule ref
> api). But I think for now I'll just put a TODO or FIXME
On 02/14, Jeff King wrote:
> - /* Check revs and then paths */
> + /*
> + * We have to find "--" in a separate pass, because its presence
> + * influences how we will parse arguments that come before it.
> + */
> + for (i = 0; i < argc; i++) {
> + if
On Tue, Feb 14, 2017 at 2:04 AM, Duy Nguyen wrote:
> On Tue, Feb 14, 2017 at 6:55 AM, Stefan Beller wrote:
>>>
>>> +/*
>>> + * Return the ref_store instance for the specified submodule. For the
>>> + * main repository, use submodule==NULL; such a call
Jeff King writes:
> On Thu, Dec 29, 2016 at 07:48:45PM -0500, Jeff King wrote:
>
>> On Thu, Dec 29, 2016 at 04:11:14PM -0800, Jonathan Nieder wrote:
>>
>> > Thanks. Here's the patch again, now with commit messages and a test.
>> > Thanks for the analysis and sorry for the slow
Jeff King writes:
> This fixes the problem, but I think we can simplify it quite a bit by
> using resolve_refdup(). Here's the patch series I ended up with:
>
> [1/3]: show-branch: drop head_len variable
> [2/3]: show-branch: store resolved head in heap buffer
> [3/3]:
Hi,
On 02/13/2017 09:30 AM, Junio C Hamano wrote:
> Linus Torvalds writes:
>
>> On Sat, Feb 11, 2017 at 10:02 AM, Linus Torvalds
>> wrote:
>>>
>>> I've signed off on this, because I think it's an "obvious" improvement,
>>> but I'm
From: Jonathan Nieder
To push from or fetch to the current repository, remote helpers need
to know what repository that is. Accordingly, Git sets the GIT_DIR
environment variable to the path to the current repository when
invoking remote helpers.
There is a special case it
On Tue, Feb 14, 2017 at 8:55 PM, Jeff King wrote:
> On Tue, Feb 14, 2017 at 11:35:48AM -0800, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > This fixes the problem, but I think we can simplify it quite a bit by
>> > using resolve_refdup(). Here's the patch
Jeff King writes:
> ...
> The rationale for doing this with --no-index is that it is
> meant to be used outside a repository, and so parsing revs
> at all does not make sense.
>
> This patch gives --untracked the same treatment. While it
> _is_ meant to be used in a repository, it
On 02/14/2017 01:50 AM, SZEDER Gábor wrote:
> On Tue, Feb 14, 2017 at 12:33 AM, wrote:
>> From: Cornelius Weig
>>
>> The command line completion for git-checkout bails out when seeing '--'
>> as an isolated argument. For git-checkout this
On Tue, Feb 14, 2017 at 10:19:56AM -0800, Jonathan Tan wrote:
> > I wasn't sure if we wanted to treat "untracked" in the same way.
> > Certainly we can catch the error here for the seen_dashdash case, but is
> > it also the case that:
> >
> > echo content >master
> > git grep --untracked
On Wed, Feb 15, 2017 at 12:23:52AM +0530, Pranit Bauva wrote:
> Did you purposely miss the one in line number 278 of
> builtin/show-branch.c because I think you only touched up the parts
> which were related to "refs/" but didn't explicitly mention it in the
> commit message?
>
> if
On Tue, Feb 14, 2017 at 10:56:21AM -0800, Brandon Williams wrote:
> On 02/14, Jeff King wrote:
> > - /* Check revs and then paths */
> > + /*
> > +* We have to find "--" in a separate pass, because its presence
> > +* influences how we will parse arguments that come before it.
> > +
From: Cornelius Weig
The function __git_complete_revlist_file understands how to complete a
path such as 'topic:ref'. In that case, the revision (topic) and
the path component (ref) are both part of the same word. However,
some cases require that the revision is
Stefan Beller writes:
> If we were to redesign the .gitmodules file, we might have it as
>
> [submodule "path"]
> url = git://example.org
> branch = .
> ...
>
> and the "path -> name/UID" mapping would be inside $GIT_DIR.
I am not sure how you are
On Tue, Feb 14, 2017 at 11:35:48AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > This fixes the problem, but I think we can simplify it quite a bit by
> > using resolve_refdup(). Here's the patch series I ended up with:
> >
> > [1/3]: show-branch: drop head_len
How is git send-email and git am supposed to handle a text file which
lacks a newline at the very end? This is about git 2.11.0.
Right now the patch in an email generated with 'git send-email' ends
with '\ No newline at end of file', which 'git am' can not handle. To
me it looks like whatever
Sorry for dropping the ball here, I was stressed out a bit.
On Thu, Feb 9, 2017 at 3:32 PM, Junio C Hamano wrote:
>> Do we need
>>
>> * an opinionated way to check for a specific state of a submodule
>> * (submodule helper to be plumbing?)
>> * expose the design
"brian m. carlson" writes:
> This is another series in the continuing conversion to struct object_id.
>
> This series converts more of the builtin directory and some of the refs
> code to use struct object_id. Additionally, it implements an
> nth_packed_object_oid
Olaf Hering writes:
> How is git send-email and git am supposed to handle a text file which
> lacks a newline at the very end? This is about git 2.11.0.
I think this has always worked, though.
$ cd /var/tmp/x
$ git init am-incomplete-line
$ cd am-incomplete-line/
On Tue, Feb 14, 2017 at 09:11:04PM +0100, Olaf Hering wrote:
> How is git send-email and git am supposed to handle a text file which
> lacks a newline at the very end? This is about git 2.11.0.
That workflow should handle this case, and the resulting applied patch
should not have a newline.
>
cornelius.w...@tngtech.com writes:
> From: Cornelius Weig
>
> Git-checkout completes words starting with '--' as options and other
> words as refs. Even after specifying a ref, further words not starting
> with '--' are completed as refs, which is invalid for
On 02/14, Matthieu Moy wrote:
> Thomas Gummerer writes:
>
> > create_stash () {
> > - stash_msg="$1"
> > - untracked="$2"
> > + stash_msg=
> > + untracked=
> > + new_style=
> > + while test $# != 0
> > + do
> > + case "$1" in
> > +
On Tue, Feb 14, 2017 at 11:08:05AM -0800, Junio C Hamano wrote:
> Thanks for prodding. I'm tempted to just rip out everything other
> than the 5-liner fix to transport.c and apply it, expecting that a
> follow-up patch with updated tests to come sometime not in too
> distant future.
I think we
The "git ls-remote" command can be run outside of a
repository, but needs to look up configured remotes. The
config code is smart enough to handle this case itself, but
we also check the historical "branches" and "remotes" paths
in $GIT_DIR. The git_path() function causes us to blindly
look at
Hi,
On Mon, 13 Feb 2017, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > That is why I taught the Git for Windows CI job that tests the four
> > upstream Git integration branches to *also* bisect test breakages and
> > then upload comments to the
Am Tue, 14 Feb 2017 12:40:36 -0800
schrieb Junio C Hamano :
> Olaf Hering writes:
>
> > How is git send-email and git am supposed to handle a text file
> > which lacks a newline at the very end? This is about git 2.11.0.
>
> I think this has always worked,
Johannes Schindelin writes:
> On Mon, 13 Feb 2017, Junio C Hamano wrote:
>
>> Johannes Schindelin writes:
>>
>> > That is why I taught the Git for Windows CI job that tests the four
>> > upstream Git integration branches to *also* bisect
From: Cornelius Weig
Git-checkout completes words starting with '--' as options and other
words as refs. Even after specifying a ref, further words not starting
with '--' are completed as refs, which is invalid for git-checkout.
This commit ensures that after
On 02/13, Jeff King wrote:
> On Mon, Feb 13, 2017 at 04:57:34PM -0500, Jeff King wrote:
>
> > Yeah, I think your patch is actually fixing that case. But your search
> > is only part of the story. You found somebody using "-m" explicitly, but
> > what about somebody blindly calling:
> >
> > git
On 02/14, Matthieu Moy wrote:
> Thomas Gummerer writes:
>
> > I'm almost convinced of special casing "-p". (Maybe I'm easy to
> > convince as well, because it would be convenient ;) ) However it's a
> > bit weird that now "git stash -p file" would work, but "git stash -m
>
On Tue, Feb 14, 2017 at 12:31:46PM +0100, Johannes Schindelin wrote:
> On Windows, calls to memihash() and maintaining the istate.name_hash and
> istate.dir_hash HashMaps take significant time on very large
> repositories. This series of changes reduces the overall time taken for
> various
On Tue, Feb 14, 2017 at 10:08 PM, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
>> On Mon, 13 Feb 2017, Junio C Hamano wrote:
>>
>>> Johannes Schindelin writes:
>>>
>>> > That is why I taught the Git for Windows
Stefan Beller writes:
> I claim that the exposure into .gitmodules combined with
> the extreme similarity to its path is confusing. Maybe this
> can be fixed by a different default name.
I think that this may be worth thinking about it further.
The names are something the
On 02/14/2017 10:31 PM, Junio C Hamano wrote:
> cornelius.w...@tngtech.com writes:
>
>> From: Cornelius Weig
>>
>> Git-checkout completes words starting with '--' as options and other
>> words as refs. Even after specifying a ref, further words not starting
>> with
On Tue, Feb 14, 2017 at 2:17 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> On Tue, Feb 14, 2017 at 1:56 PM, Junio C Hamano wrote:
>>> Stefan Beller writes:
>>>
If we were to redesign the .gitmodules
[apologies for the accidental "smart" quotes and the resulting UTF8
encoding of the subject]
On 04/02/2017 06:01, Duy Nguyen wrote:
>
> But that would be local information only. We don't have ways to
> transfer branch metadata (and we definitely don't want to just share
> .git/config file with
On Tue, Feb 14, 2017 at 02:11:06PM -0800, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Thanks. We'd need to update the tests that expects the old style
> > output, though.
>
> The updates to the expectation look like this (already squashed).
> The --source
From: Bernhard Übelacker
In "New Commit" author name is set correctly.
But when doing "Amend Last Commit" the encoding gets wrong.
This patch adds in load_last_commit a similar assignment converting
to tcl encoding for commit_author as already exists for msg.
---
From: "Christian Couder"
On Tue, Feb 14, 2017 at 10:08 PM, Junio C Hamano
wrote:
Johannes Schindelin writes:
On Mon, 13 Feb 2017, Junio C Hamano wrote:
Johannes Schindelin writes:
>
Stefan Beller writes:
> On Tue, Feb 14, 2017 at 1:56 PM, Junio C Hamano wrote:
>> Stefan Beller writes:
>>
>>> If we were to redesign the .gitmodules file, we might have it as
>>>
>>> [submodule "path"]
>>> url =
Stefan Beller writes:
>> And then after doing the "git mv" you have pushed the result, which
>> I pulled. Now, how will your "internal mapping" propagate to me?
>
> The "name" inside your superprojects git dir may be different from mine,
> after all the name only serves the
Cornelius Weig writes:
> Hmm.. I'm a bit reluctant to let go of this just yet, because it was my
> original motivation for the whole patch. I admit that it may be
> confusing to not get completion in your example. However, I think that
> once acquainted with the new
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
Topic descriptions of some new
"Philip Oakley" writes:
> There are also a few ideas at the SO answers:
> http://stackoverflow.com/a/5652323/717355
I vaguely recall that I saw somebody said the same "mark tips of
topics as good" on the list and answered with why it does not quite
work, though.
On Tue, Feb 14, 2017 at 1:56 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> If we were to redesign the .gitmodules file, we might have it as
>>
>> [submodule "path"]
>> url = git://example.org
>> branch = .
>> ...
>>
>>
Junio C Hamano writes:
> Thanks. We'd need to update the tests that expects the old style
> output, though.
The updates to the expectation look like this (already squashed).
The --source decorations in 4202 are also shown at the end, which
probably is in line with the way
Christian Couder writes:
> By the way it should not be very difficult as a patch to do this and
> more was proposed a long time ago:
>
> https://public-inbox.org/git/4d3cddf9.6080...@intel.com/
Thanks for a link. The one I found most interesting in the thread
is by
Similar to b33a15b08 (push: add recurseSubmodules config option,
2015-11-17) and 027771fcb1 (submodule: allow erroneous values for the
fetchRecurseSubmodules option, 2015-08-17), we add submodule-config code
that is later used to parse whether we are interested in updating
submodules.
We need the
Currently lib-submodule-update.sh provides 2 functions
test_submodule_switch and test_submodule_forced_switch that are used by a
variety of tests to ensure that submodules behave as expected. The current
expected behavior is that submodules are not touched at all (see
42639d2317a for the exact
In later patches we introduce the options and flag for commands
that modify the working directory, e.g. git-checkout.
Have a central place to store such settings whether we want to update
a submodule.
Signed-off-by: Stefan Beller
---
submodule.c | 6 ++
submodule.h | 1
Redraw the ASCII art describing the setup using more space, such that
it is easier to understand. The leaf commits are now ordered the same
way the actual code is ordered.
Add empty lines to the setup code separating each of the leaf commits,
each starting with a "checkout -b".
Signed-off-by:
previous work:
https://public-inbox.org/git/20161203003022.29797-1-sbel...@google.com/
v3:
* moved tests from t2013 to the generic submodule library.
* factored out the refactoring patches to be up front
* As I redid the complete implementation, I have the impression this time
it is cleaner
Signed-off-by: Stefan Beller
---
unpack-trees.c | 98 --
unpack-trees.h | 1 +
2 files changed, 90 insertions(+), 9 deletions(-)
diff --git a/unpack-trees.c b/unpack-trees.c
index 616a0ae4b2..6805cb9549 100644
---
We need the gentle version in a later patch. As we have just one caller,
migrate the caller.
Signed-off-by: Stefan Beller
---
builtin/grep.c | 2 +-
submodule.c| 4 ++--
submodule.h| 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/builtin/grep.c
In a later patch we need to prepare the submodule environment with
another git directory, so split up the function.
Also move it up in the file such that we do not need to declare the
function later before using it.
Signed-off-by: Stefan Beller
---
submodule.c | 29
Signed-off-by: Stefan Beller
---
entry.c | 28
1 file changed, 28 insertions(+)
diff --git a/entry.c b/entry.c
index c6eea240b6..bc6295d41a 100644
--- a/entry.c
+++ b/entry.c
@@ -2,6 +2,7 @@
#include "blob.h"
#include "dir.h"
#include
SZEDER Gábor writes:
>> If you feel uncomfortable and want these to cook longer, please tell
>> me so.
>
> Well, it was mainly my surprise that a 20+ patch series arriving so
> late that it gets queued on top of -rc0 would still make it into the
> release.
It all depends
Duy Nguyen writes:
> Long term, I think that's what Mike wants. Though the filter_ref_store
> might return an (opaque) iterator instead of a ref store and
> for_each_refstore() becomes a thin wrapper around the iterator
> interface.
Ah, yes, an iterator would be a lot more
On Tue, Feb 14, 2017 at 04:34:10PM -0800, Stefan Beller wrote:
> create_lib_submodule_repo () {
> git init submodule_update_repo &&
> (
> @@ -49,10 +54,11 @@ create_lib_submodule_repo () {
> git config submodule.sub1.ignore all &&
> git add .gitmodules &&
>
On Tue, Feb 14, 2017 at 04:34:18PM -0800, Stefan Beller wrote:
> + prepare_submodule_repo_env_no_git_dir(_array);
> +
> + cp.git_cmd = 1;
> + cp.no_stdin = 1;
> + cp.dir = path;
> +
> + argv_array_pushf(, "--super-prefix=%s/", path);
> + argv_array_pushl(, "read-tree",
On Tue, Feb 14, 2017 at 10:24 PM, wrote:
> From: Cornelius Weig
>
> Git-checkout completes words starting with '--' as options and other
> words as refs. Even after specifying a ref, further words not starting
> with '--' are completed as
On Wed, Feb 15, 2017 at 1:24 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> Direct call sites are just middle men though, e.g.
>> for_each_ref_submodule(). I'll attempt to clean this up at some point
>> in future (probably at the same time I attempt to
1 - 100 of 115 matches
Mail list logo