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
>>> b77c7cd17... refs/tags/1.1.0
>>
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 Duy
>> ---
>> refs/files-ba
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 ?
This is what strbuf
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 means that we exercise
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
>> ---
>> refs/refs-internal.h | 2 +-
>> 1 file changed, 1 inser
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 in
> the previous patch! Also
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 insertions(+), 5 deletions(-)
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 function,
> but the submodul
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 Hostetler
Signed-off-by: Joh
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
Signed-off-by: Johannes Sc
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 reuse that computed hash fo
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 multi
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 directory. This can save memih
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 rehash() calls to reallo
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 X
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 be avoided by
>
Hi Junio,
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 of
> > the MSVC runtime are modified in order to redirect std
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 the official repo.
>
> The
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_ ...
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 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 initi
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);
> - m
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 deletions(-)
di
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 dupl
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(-)
diff --git a/bu
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 HEAD.
>>>
>>> Signed-off-by: Nguyễn Thái Ngọc Duy
>>> ---
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.
>
> builtin/clean.c | 19
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
Pe
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 cm
Hello,
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 comment here.
So we'd
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 cannot fail.
>>
>> So now we have both a get_
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 of
the MSVC runtime are modifi
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 revisio
On 02/14, Jeff King wrote:
> - /* Is it a rev? */
> - if (!get_sha1_with_context(arg, 0, sha1, &oc)) {
> - struct object *object = parse_object_or_die(sha1, arg);
> - if (!seen_dashdash)
> - verify_non_filen
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
> ---
> builtin/show-branch.c | 16 ++
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
> patches, he can easily cherry-pic
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 (!strcmp(
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.
>
> The patch f
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 turnaround.
>>
>
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 keep a seen_dashdas
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]: show-branch: use skip
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.
> > +
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 (starts_w
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 variable
> > [2/3]: s
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 var
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 c
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 ".gi
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 putting the "RFC" in the subject line because this is clearly a
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 does not handle: "git
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/
$ echo one 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.
> Ri
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, though.
For me it complains in line
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 identified commit on GitHub
>
> Good.
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 test breakages and
>> > then upload comments to the ident
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 signifies the start of a
>> list of files which are to be
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 specified elsewhere than the
curre
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 specifying a ref, further non-option
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 series I ended up with:
>> >
>> >
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
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 git-checkout.
>
> This commit ensures
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
> > message" wouldn't.
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
> > + -m|--message)
> > +
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 mistake of having the (nam
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 patt
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 going to keep track
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 is explicitly
>
"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 function which provides a struct
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 operati
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 = .
>> ...
>>
>> and the "path -> name/UID" mapping would
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 --show-decorations add
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 '--' are completed as refs, w
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 = git://example.org
>>> branch = .
>>> ...
>>>
>>> and t
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 file, we might have it as
[submodule "path"]
url = git:
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 purpose to not have d
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 behavior, a user who wants som
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.
---
lib/commit.tcl | 3 +++
1 file
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 top
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 CI job that tests the four
>>> > upstream Git integration branches to *also*
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 Avery [*1*], where he explain
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:
> That is why I taught the Git for Windows CI job that tests the four
> upstream Git integration branches t
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 end users are not supp
"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.
[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 ev
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 decorations in 4202 are also
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 setu
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 +
2 files changed, 7
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: St
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
In later patches we introduce the options and flag for commands
that modify the working directory, e.g. git-checkout.
This piece of code will be used universally for
all these working tree modifications as it
* supports dry run to answer the question:
"Is it safe to change the submodule to this
In later patches we introduce the --recurse-submodule flag for commands
that modify the working directory, e.g. git-checkout.
It is potentially expensive to check if a submodule needs an update,
because a common theme to interact with submodules is to spawn a child
process for each interaction.
S
The check (which uses the old oid) is yet to be implemented, but this part
is just a refactor, so it can go separately first.
Signed-off-by: Stefan Beller
---
unpack-trees.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/unpack-trees.c b/unpack-trees.c
ind
In a later patch we'll use connect_work_tree_and_git_dir when the
directory for the gitlink file doesn't exist yet. Safely create
the directory first.
Signed-off-by: Stefan Beller
---
dir.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/dir.c b/dir.c
index 4541f9e146..69ca3d1411 100644
--
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
--- a/unpack-trees.c
+++ b/un
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 b/builtin/grep.c
inde
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 "streaming.h"
+#include "subm
Signed-off-by: Stefan Beller
---
read-cache.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/read-cache.c b/read-cache.c
index 9054369dd0..c0776b93b0 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -18,6 +18,7 @@
#include "varint.h"
#include "split-index.h"
#include "utf8.h"
+#include
1 - 100 of 115 matches
Mail list logo
