* Re: ignore blank line removals
From: Junio C Hamano @ 2016-11-15 18:51 UTC (permalink / raw)
To: John Rood; +Cc: git
In-Reply-To: <CALj-rGdRDa0EU6AeMHWYketr5QBOnV7-3RKraiuPCk=Aepz=pQ@mail.gmail.com>
John Rood <mr.john.rood@gmail.com> writes:
> On Thu, Nov 3, 2016 at 10:57 AM, John Rood <mr.john.rood@gmail.com> wrote:
>> If the contents of a file initially are:
>> one
>>
>> three
>> and on branch A there is a commit, removing the blank line:
>> one
>> three
>> and on branch B there is a commit, adding 'two':
>> one
>> two
>> three
>> Normally, if you try to merge A into B (or B into A), git recognizes a
>> decision needs to be made between removing the second line or add
>> "two" to the second line. It would be convenient to have a merge
>> strategy that defaults to the latter in cases where the removed line
>> was a blank line (or a line containing only whitespace) ...something
>> like -Xignore-blank-line-removals.
>
> Is there any push-back on this, or is there a backlog that we can add
> this feature to?
If you mean by "push-back" objections that say "this feature is evil
and should not be added to Git, ever", I do not think we saw any on
the list. The lack of response is most likely that everybody
thought "Meh." aka "It is not useful/interesting/valuable enough
feature to bother discussing."
One thing I wondered was what you would want if the contents were
one/three without blank, A added blank between the two and B
replaced blank with two. As your example shows, in the filetype you
are dealing with, a blank line has no significant meaning (otherwise
you won't be ignoring the change A made to remove the blank in your
original example). The outcome desired by you may be one/two/three
without any blank in that case because of that. Which would lead to
the suspicion that ignore-blank-line-removals is not a good general
feature (i.e. in this other example, you want to ignore blank line
addition). Which further leads to the suspicion that the desire you
expressed in the original post is not well thought through to be a
useful specifification to build anything out of (yet), but is merely
a potentially interesting discussion starter. And nobody so far
found it interesting enough to spend time discussing it further to
make the wish detailed enough to be called a "design" of a new
feature.
Having said all that.
I suspect that you may not have to make any change to Git to do what
you want; can't you just use the 'merge' attribute with a custom
3-way merge driver that removes an empty line?
^ permalink raw reply
* [PATCH] git-gc.txt: expand discussion of races with other processes
From: Matt McCutchen @ 2016-11-15 19:08 UTC (permalink / raw)
To: git; +Cc: Jeff King
In-Reply-To: <20161115174028.zvohfcw4jse3jrmm@sigill.intra.peff.net>
In general, "git gc" may delete objects that another concurrent process
is using but hasn't created a reference to. Git has some mitigations,
but they fall short of a complete solution. Document this in the
git-gc(1) man page and add a reference from the documentation of the
gc.pruneExpire config variable.
Based on a write-up by Jeff King:
http://marc.info/?l=git&m=147922960131779&w=2
Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
---
Documentation/config.txt | 4 +++-
Documentation/git-gc.txt | 34 ++++++++++++++++++++++++++--------
2 files changed, 29 insertions(+), 9 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 21fdddf..3f1d931 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1409,7 +1409,9 @@ gc.pruneExpire::
Override the grace period with this config variable. The value
"now" may be used to disable this grace period and always prune
unreachable objects immediately, or "never" may be used to
- suppress pruning.
+ suppress pruning. This feature helps prevent corruption when
+ 'git gc' runs concurrently with another process writing to the
+ repository; see the "NOTES" section of linkgit:git-gc[1].
gc.worktreePruneExpire::
When 'git gc' is run, it calls
diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
index bed60f4..852b72c 100644
--- a/Documentation/git-gc.txt
+++ b/Documentation/git-gc.txt
@@ -63,11 +63,10 @@ automatic consolidation of packs.
--prune=<date>::
Prune loose objects older than date (default is 2 weeks ago,
overridable by the config variable `gc.pruneExpire`).
- --prune=all prunes loose objects regardless of their age (do
- not use --prune=all unless you know exactly what you are doing.
- Unless the repository is quiescent, you will lose newly created
- objects that haven't been anchored with the refs and end up
- corrupting your repository). --prune is on by default.
+ --prune=all prunes loose objects regardless of their age and
+ increases the risk of corruption if another process is writing to
+ the repository concurrently; see "NOTES" below. --prune is on by
+ default.
--no-prune::
Do not prune any loose objects.
@@ -138,17 +137,36 @@ default is "2 weeks ago".
Notes
-----
-'git gc' tries very hard to be safe about the garbage it collects. In
+'git gc' tries very hard not to delete objects that are referenced
+anywhere in your repository. In
particular, it will keep not only objects referenced by your current set
of branches and tags, but also objects referenced by the index,
remote-tracking branches, refs saved by 'git filter-branch' in
refs/original/, or reflogs (which may reference commits in branches
that were later amended or rewound).
-
-If you are expecting some objects to be collected and they aren't, check
+If you are expecting some objects to be deleted and they aren't, check
all of those locations and decide whether it makes sense in your case to
remove those references.
+On the other hand, when 'git gc' runs concurrently with another process,
+there is a risk of it deleting an object that the other process is using
+but hasn't created a reference to. This may just cause the other process
+to fail or may corrupt the repository if the other process later adds a
+reference to the deleted object. Git has two features that significantly
+mitigate this problem:
+
+. Any object with modification time newer than the `--prune` date is kept,
+ along with everything reachable from it.
+
+. Most operations that add an object to the database update the
+ modification time of the object if it is already present so that #1
+ applies.
+
+However, these features fall short of a complete solution, so users who
+run commands concurrently have to live with some risk of corruption (which
+seems to be low in practice) unless they turn off automatic garbage
+collection with 'git config gc.auto 0'.
+
HOOKS
-----
--
2.7.4
^ permalink raw reply related
* Re: Protecting old temporary objects being reused from concurrent "git gc"?
From: Matt McCutchen @ 2016-11-15 19:12 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20161115174028.zvohfcw4jse3jrmm@sigill.intra.peff.net>
On Tue, 2016-11-15 at 12:40 -0500, Jeff King wrote:
> On Tue, Nov 15, 2016 at 12:33:04PM -0500, Matt McCutchen wrote:
>
> >
> > On Tue, 2016-11-15 at 12:06 -0500, Jeff King wrote:
> > >
> > > - when an object write is optimized out because we already have the
> > > object, git will update the mtime on the file (loose object or
> > > packfile) to freshen it
> >
> > FWIW, I am not seeing this happen when I do "git read-tree --prefix"
> > followed by "git write-tree" using the current master (3ab2281). See
> > the attached test script.
>
> The optimization I'm thinking about is the one from write_sha1_file(),
> which learned to freshen in 33d4221c7 (write_sha1_file: freshen existing
> objects, 2014-10-15).
>
> I suspect the issue is that read-tree populates the cache-tree index
> extension, and then write-tree omits the object write before it even
> gets to write_sha1_file(). The solution is that it should probably be
> calling one of the freshen() functions (possibly just replacing
> has_sha1_file() with check_and_freshen(), but I haven't looked).
>
> I'd definitely welcome patches in this area.
Cool, it's nice to have an idea of what's going on. I don't think I'm
going to try to fix it myself though.
By the way, thanks for the fast response to my original question!
Matt
^ permalink raw reply
* Re: ignore blank line removals
From: John Rood @ 2016-11-15 19:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqqr36ctw47.fsf@gitster.mtv.corp.google.com>
Yes that makes sense.
I was not aware of custom merge drivers, but indeed that may address
my situation. I'll look into it.
Thanks!
On Tue, Nov 15, 2016 at 12:51 PM, Junio C Hamano <gitster@pobox.com> wrote:
> John Rood <mr.john.rood@gmail.com> writes:
>
>> On Thu, Nov 3, 2016 at 10:57 AM, John Rood <mr.john.rood@gmail.com> wrote:
>>> If the contents of a file initially are:
>>> one
>>>
>>> three
>>> and on branch A there is a commit, removing the blank line:
>>> one
>>> three
>>> and on branch B there is a commit, adding 'two':
>>> one
>>> two
>>> three
>>> Normally, if you try to merge A into B (or B into A), git recognizes a
>>> decision needs to be made between removing the second line or add
>>> "two" to the second line. It would be convenient to have a merge
>>> strategy that defaults to the latter in cases where the removed line
>>> was a blank line (or a line containing only whitespace) ...something
>>> like -Xignore-blank-line-removals.
>>
>> Is there any push-back on this, or is there a backlog that we can add
>> this feature to?
>
> If you mean by "push-back" objections that say "this feature is evil
> and should not be added to Git, ever", I do not think we saw any on
> the list. The lack of response is most likely that everybody
> thought "Meh." aka "It is not useful/interesting/valuable enough
> feature to bother discussing."
>
> One thing I wondered was what you would want if the contents were
> one/three without blank, A added blank between the two and B
> replaced blank with two. As your example shows, in the filetype you
> are dealing with, a blank line has no significant meaning (otherwise
> you won't be ignoring the change A made to remove the blank in your
> original example). The outcome desired by you may be one/two/three
> without any blank in that case because of that. Which would lead to
> the suspicion that ignore-blank-line-removals is not a good general
> feature (i.e. in this other example, you want to ignore blank line
> addition). Which further leads to the suspicion that the desire you
> expressed in the original post is not well thought through to be a
> useful specifification to build anything out of (yet), but is merely
> a potentially interesting discussion starter. And nobody so far
> found it interesting enough to spend time discussing it further to
> make the wish detailed enough to be called a "design" of a new
> feature.
>
> Having said all that.
>
> I suspect that you may not have to make any change to Git to do what
> you want; can't you just use the 'merge' attribute with a custom
> 3-way merge driver that removes an empty line?
>
^ permalink raw reply
* Re: [PATCH 1/2] push: --dry-run updates submodules when --recurse-submodules=on-demand
From: Johannes Sixt @ 2016-11-15 19:46 UTC (permalink / raw)
To: Brandon Williams; +Cc: git
In-Reply-To: <20161115172909.GA66382@google.com>
Am 15.11.2016 um 18:29 schrieb Brandon Williams:
> I'm assuming the reason we want to avoid sub-shells is
> for performance reasons right?
Yes, every fork() saved is a win on Windows. (No pun intended ;)
-- Hannes
^ permalink raw reply
* Re: Protecting old temporary objects being reused from concurrent "git gc"?
From: Junio C Hamano @ 2016-11-15 20:01 UTC (permalink / raw)
To: Jeff King; +Cc: Matt McCutchen, git
In-Reply-To: <20161115174028.zvohfcw4jse3jrmm@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I suspect the issue is that read-tree populates the cache-tree index
> extension, and then write-tree omits the object write before it even
> gets to write_sha1_file(). The solution is that it should probably be
> calling one of the freshen() functions (possibly just replacing
> has_sha1_file() with check_and_freshen(), but I haven't looked).
I think the final writing always happens via write_sha1_file(), but
an earlier cache-tree update that says "if we have a tree object
already, then use it, otherwise even though we know the object name
for this subtree, do not record it in the cache-tree" codepath may
decide to record the subtree's sha1 without refreshing the referent.
A fix may look like this.
cache-tree.c | 2 +-
cache.h | 1 +
sha1_file.c | 9 +++++++--
3 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/cache-tree.c b/cache-tree.c
index 345ea35963..3ae6d056b4 100644
--- a/cache-tree.c
+++ b/cache-tree.c
@@ -401,7 +401,7 @@ static int update_one(struct cache_tree *it,
if (repair) {
unsigned char sha1[20];
hash_sha1_file(buffer.buf, buffer.len, tree_type, sha1);
- if (has_sha1_file(sha1))
+ if (freshen_object(sha1))
hashcpy(it->sha1, sha1);
else
to_invalidate = 1;
diff --git a/cache.h b/cache.h
index 5cdea6833e..1f5694f308 100644
--- a/cache.h
+++ b/cache.h
@@ -1126,6 +1126,7 @@ extern int sha1_object_info(const unsigned char *, unsigned long *);
extern int hash_sha1_file(const void *buf, unsigned long len, const char *type, unsigned char *sha1);
extern int write_sha1_file(const void *buf, unsigned long len, const char *type, unsigned char *return_sha1);
extern int hash_sha1_file_literally(const void *buf, unsigned long len, const char *type, unsigned char *sha1, unsigned flags);
+extern int freshen_object(const unsigned char *);
extern int pretend_sha1_file(void *, unsigned long, enum object_type, unsigned char *);
extern int force_object_loose(const unsigned char *sha1, time_t mtime);
extern int git_open_cloexec(const char *name, int flags);
diff --git a/sha1_file.c b/sha1_file.c
index e030805497..1daeb05dcd 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -3275,6 +3275,11 @@ static int freshen_packed_object(const unsigned char *sha1)
return 1;
}
+int freshen_object(const unsigned char *sha1)
+{
+ return freshen_packed_object(sha1) || freshen_loose_object(sha1);
+}
+
int write_sha1_file(const void *buf, unsigned long len, const char *type, unsigned char *sha1)
{
char hdr[32];
@@ -3284,7 +3289,7 @@ int write_sha1_file(const void *buf, unsigned long len, const char *type, unsign
* it out into .git/objects/??/?{38} file.
*/
write_sha1_file_prepare(buf, len, type, sha1, hdr, &hdrlen);
- if (freshen_packed_object(sha1) || freshen_loose_object(sha1))
+ if (freshen_object(sha1))
return 0;
return write_loose_object(sha1, hdr, hdrlen, buf, len, 0);
}
@@ -3302,7 +3307,7 @@ int hash_sha1_file_literally(const void *buf, unsigned long len, const char *typ
if (!(flags & HASH_WRITE_OBJECT))
goto cleanup;
- if (freshen_packed_object(sha1) || freshen_loose_object(sha1))
+ if (freshen_object(sha1))
goto cleanup;
status = write_loose_object(sha1, header, hdrlen, buf, len, 0);
^ permalink raw reply related
* [PATCH] worktree: fix a sparse 'Using plain integer as NULL pointer' warning
From: Ramsay Jones @ 2016-11-15 20:28 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Junio C Hamano, GIT Mailing-list
Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
---
Hi Duy,
If you need to re-roll your 'nd/worktree-move' branch, could you
please squash this into the relevant patch [commit c49e92f5c
("worktree move: refuse to move worktrees with submodules", 12-11-2016)].
Also, one of the new tests introduced by commit 31a8f3066 ("worktree move:
new command", 12-11-2016), fails for me, thus:
$ ./t2028-worktree-move.sh -i -v
...
--- expected 2016-11-15 20:22:50.647241458 +0000
+++ actual 2016-11-15 20:22:50.647241458 +0000
@@ -1,3 +1,3 @@
worktree /home/ramsay/git/t/trash directory.t2028-worktree-move
-worktree /home/ramsay/git/t/trash directory.t2028-worktree-move/destination
worktree /home/ramsay/git/t/trash directory.t2028-worktree-move/elsewhere
+worktree /home/ramsay/git/t/trash directory.t2028-worktree-move/destination
not ok 12 - move worktree
#
# git worktree move source destination &&
# test_path_is_missing source &&
# git worktree list --porcelain | grep "^worktree" >actual &&
# cat <<-EOF >expected &&
# worktree $TRASH_DIRECTORY
# worktree $TRASH_DIRECTORY/destination
# worktree $TRASH_DIRECTORY/elsewhere
# EOF
# test_cmp expected actual &&
# git -C destination log --format=%s >actual2 &&
# echo init >expected2 &&
# test_cmp expected2 actual2
#
$
Is there an expectation that the submodules will be listed in
any particular order by 'git worktree list --porcelain' ?
Thanks!
ATB,
Ramsay Jones
builtin/worktree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/worktree.c b/builtin/worktree.c
index e738142..abdf462 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -526,7 +526,7 @@ static int unlock_worktree(int ac, const char **av, const char *prefix)
static void validate_no_submodules(const struct worktree *wt)
{
- struct index_state istate = {0};
+ struct index_state istate = { NULL };
int i, found_submodules = 0;
if (read_index_from(&istate, worktree_git_path(wt, "index")) > 0) {
--
2.10.0
^ permalink raw reply related
* Re: [PATCH v7 00/17] port branch.c to use ref-filter's printing options
From: Junio C Hamano @ 2016-11-15 20:43 UTC (permalink / raw)
To: Karthik Nayak; +Cc: git, jacob.keller
In-Reply-To: <20161108201211.25213-1-Karthik.188@gmail.com>
Karthik Nayak <karthik.188@gmail.com> writes:
> This is part of unification of the commands 'git tag -l, git branch -l
> and git for-each-ref'. This ports over branch.c to use ref-filter's
> printing options.
>
> Karthik Nayak (17):
> ref-filter: implement %(if), %(then), and %(else) atoms
> ref-filter: include reference to 'used_atom' within 'atom_value'
> ref-filter: implement %(if:equals=<string>) and
> %(if:notequals=<string>)
> ref-filter: modify "%(objectname:short)" to take length
> ref-filter: move get_head_description() from branch.c
> ref-filter: introduce format_ref_array_item()
> ref-filter: make %(upstream:track) prints "[gone]" for invalid
> upstreams
> ref-filter: add support for %(upstream:track,nobracket)
> ref-filter: make "%(symref)" atom work with the ':short' modifier
> ref-filter: introduce refname_atom_parser_internal()
> ref-filter: introduce symref_atom_parser() and refname_atom_parser()
> ref-filter: make remote_ref_atom_parser() use
> refname_atom_parser_internal()
> ref-filter: add `:dir` and `:base` options for ref printing atoms
> ref-filter: allow porcelain to translate messages in the output
> branch, tag: use porcelain output
> branch: use ref-filter printing APIs
> branch: implement '--format' option
This is not a new issue, but --format='%(HEAD)' you stole from
for-each-ref is broken when you are on an unborn branch, and the
second patch from the tip makes "git branch" (no other args) on
an unborn branch to segfault, when there are real branches that
have commits.
Something like this needs to go before that step.
ref-filter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ref-filter.c b/ref-filter.c
index 944671af5a..c71d7360d2 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -1318,7 +1318,7 @@ static void populate_value(struct ref_array_item *ref)
head = resolve_ref_unsafe("HEAD", RESOLVE_REF_READING,
sha1, NULL);
- if (!strcmp(ref->refname, head))
+ if (head && !strcmp(ref->refname, head))
v->s = "*";
else
v->s = " ";
^ permalink raw reply related
* Re: [PATCH] worktree: fix a sparse 'Using plain integer as NULL pointer' warning
From: Ramsay Jones @ 2016-11-15 20:50 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Junio C Hamano, GIT Mailing-list
In-Reply-To: <5b7d7d0b-8a6c-d516-4eb9-4e4ea13dce73@ramsayjones.plus.com>
On 15/11/16 20:28, Ramsay Jones wrote:
>
> Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
> ---
>
> Hi Duy,
>
> If you need to re-roll your 'nd/worktree-move' branch, could you
> please squash this into the relevant patch [commit c49e92f5c
> ("worktree move: refuse to move worktrees with submodules", 12-11-2016)].
>
> Also, one of the new tests introduced by commit 31a8f3066 ("worktree move:
> new command", 12-11-2016), fails for me, thus:
>
> $ ./t2028-worktree-move.sh -i -v
> ...
> --- expected 2016-11-15 20:22:50.647241458 +0000
> +++ actual 2016-11-15 20:22:50.647241458 +0000
> @@ -1,3 +1,3 @@
> worktree /home/ramsay/git/t/trash directory.t2028-worktree-move
> -worktree /home/ramsay/git/t/trash directory.t2028-worktree-move/destination
> worktree /home/ramsay/git/t/trash directory.t2028-worktree-move/elsewhere
> +worktree /home/ramsay/git/t/trash directory.t2028-worktree-move/destination
> not ok 12 - move worktree
> #
> # git worktree move source destination &&
> # test_path_is_missing source &&
> # git worktree list --porcelain | grep "^worktree" >actual &&
> # cat <<-EOF >expected &&
> # worktree $TRASH_DIRECTORY
> # worktree $TRASH_DIRECTORY/destination
> # worktree $TRASH_DIRECTORY/elsewhere
> # EOF
> # test_cmp expected actual &&
> # git -C destination log --format=%s >actual2 &&
> # echo init >expected2 &&
> # test_cmp expected2 actual2
> #
> $
>
> Is there an expectation that the submodules will be listed in
Er, that should read 'worktrees', of course! :(
ATB,
Ramsay Jones
^ permalink raw reply
* Re* [PATCH v7 00/17] port branch.c to use ref-filter's printing options
From: Junio C Hamano @ 2016-11-15 20:57 UTC (permalink / raw)
To: Karthik Nayak; +Cc: git, jacob.keller
In-Reply-To: <xmqqbmxgtqxv.fsf@gitster.mtv.corp.google.com>
Junio C Hamano <gitster@pobox.com> writes:
> Something like this needs to go before that step.
This time with a log message and an additional test. The second
paragraph of the proposed log message is written expecting that this
patch will come before your "branch: use ref-filter printing APIs",
which I think is a good place to avoid breakage in the series.
-- >8 --
Subject: [PATCH] for-each-ref: do not segv with %(HEAD) on an unborn branch
The code to flip between "*" and " " prefixes depending on what
branch is checked out used in --format='%(HEAD)' did not consider
that HEAD may resolve to an unborn branch and dereferenced a NULL.
This will become a lot easier to trigger as the codepath will now be
shared with "git branch [--list]".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
ref-filter.c | 2 +-
t/t3203-branch-output.sh | 8 ++++++++
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/ref-filter.c b/ref-filter.c
index 944671af5a..c71d7360d2 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -1318,7 +1318,7 @@ static void populate_value(struct ref_array_item *ref)
head = resolve_ref_unsafe("HEAD", RESOLVE_REF_READING,
sha1, NULL);
- if (!strcmp(ref->refname, head))
+ if (head && !strcmp(ref->refname, head))
v->s = "*";
else
v->s = " ";
diff --git a/t/t3203-branch-output.sh b/t/t3203-branch-output.sh
index d8edaf27e9..1a8dbca8c8 100755
--- a/t/t3203-branch-output.sh
+++ b/t/t3203-branch-output.sh
@@ -37,6 +37,14 @@ test_expect_success 'git branch --list shows local branches' '
test_cmp expect actual
'
+test_expect_success 'same, but on an unborn branch' '
+ test_when_finished "git checkout master" &&
+ git checkout --orphan naster &&
+ git branch --list >actual &&
+ sed -e "s/\* / /" expect >expect-unborn &&
+ test_cmp expect-unborn actual
+'
+
cat >expect <<'EOF'
branch-one
branch-two
--
2.11.0-rc1-154-gcd2a643dcd
^ permalink raw reply related
* Re: [PATCH v15 04/27] bisect--helper: `bisect_clean_state` shell function in C
From: Stephan Beyer @ 2016-11-15 21:09 UTC (permalink / raw)
To: Pranit Bauva, git
In-Reply-To: <01020157c38b1a82-dc1c5b57-3e93-4996-87e7-4a1d83cb5817-000000@eu-west-1.amazonses.com>
Hi,
On 10/14/2016 04:14 PM, Pranit Bauva wrote:
> diff --git a/bisect.c b/bisect.c
> index 6f512c2..45d598d 100644
> --- a/bisect.c
> +++ b/bisect.c
> @@ -1040,3 +1046,40 @@ int estimate_bisect_steps(int all)
>
> return (e < 3 * x) ? n : n - 1;
> }
> +
> +static int mark_for_removal(const char *refname, const struct object_id *oid,
> + int flag, void *cb_data)
> +{
> + struct string_list *refs = cb_data;
> + char *ref = xstrfmt("refs/bisect%s", refname);
> + string_list_append(refs, ref);
> + return 0;
> +}
> +
> +int bisect_clean_state(void)
> +{
> + int result = 0;
> +
> + /* There may be some refs packed during bisection */
> + struct string_list refs_for_removal = STRING_LIST_INIT_NODUP;
> + for_each_ref_in("refs/bisect", mark_for_removal, (void *) &refs_for_removal);
> + string_list_append(&refs_for_removal, xstrdup("BISECT_HEAD"));
> + result = delete_refs(&refs_for_removal, REF_NODEREF);
> + refs_for_removal.strdup_strings = 1;
> + string_list_clear(&refs_for_removal, 0);
Does it have advantages to populate a list (with duplicated strings),
hand it to delete_refs(), and clear the list (and strings), instead of
just doing a single delete_ref() (or whatever name the singular function
has) in the callback?
I am only seeing the disadvantage: a list with duped strings.
> + unlink_or_warn(git_path_bisect_expected_rev());
[...]
> + unlink_or_warn(git_path_bisect_start());
Comparing it with the original shell code (which uses "rm -f"), I was
wondering a little after reading the function name unlink_or_warn()
here... Looking it up helped: despite its name, unlink_or_warn() is
really the function you have to use here ;D
> diff --git a/builtin/bisect--helper.c b/builtin/bisect--helper.c
> index 65cf519..4254d61 100644
> --- a/builtin/bisect--helper.c
> +++ b/builtin/bisect--helper.c
> @@ -5,10 +5,15 @@
> #include "refs.h"
>
> static GIT_PATH_FUNC(git_path_bisect_terms, "BISECT_TERMS")
> +static GIT_PATH_FUNC(git_path_bisect_expected_rev, "BISECT_EXPECTED_REV")
> +static GIT_PATH_FUNC(git_path_bisect_ancestors_ok, "BISECT_ANCESTORS_OK")
> +static GIT_PATH_FUNC(git_path_bisect_log, "BISECT_LOG")
> +static GIT_PATH_FUNC(git_path_bisect_start, "BISECT_START")
This is perhaps a non-issue, but you do not need any of these new path
functions in *this* patch. I think nobody really cares, though, because
you will need them later.
Cheers
Stephan
^ permalink raw reply
* Re: [PATCH v15 04/27] bisect--helper: `bisect_clean_state` shell function in C
From: Junio C Hamano @ 2016-11-15 21:40 UTC (permalink / raw)
To: Stephan Beyer; +Cc: Pranit Bauva, git
In-Reply-To: <13aa642a-2272-c5b8-4a30-382ab5e73b98@gmx.net>
Stephan Beyer <s-beyer@gmx.net> writes:
>> +int bisect_clean_state(void)
>> +{
>> + int result = 0;
>> +
>> + /* There may be some refs packed during bisection */
>> + struct string_list refs_for_removal = STRING_LIST_INIT_NODUP;
>> + for_each_ref_in("refs/bisect", mark_for_removal, (void *) &refs_for_removal);
>> + string_list_append(&refs_for_removal, xstrdup("BISECT_HEAD"));
>> + result = delete_refs(&refs_for_removal, REF_NODEREF);
>> + refs_for_removal.strdup_strings = 1;
>> + string_list_clear(&refs_for_removal, 0);
>
> Does it have advantages to populate a list (with duplicated strings),
> hand it to delete_refs(), and clear the list (and strings), instead of
> just doing a single delete_ref() (or whatever name the singular function
> has) in the callback?
Depending on ref backends, removing multiple refs may be a lot more
efficient than calling a single ref removal for the same set of
refs, and the comment upfront I think hints that the code was
written in the way exactly with that in mind. Removing N refs from
a packed refs file will involve a loop that runs N times, each
iteration loading the file, locating an entry among possibly 100s of
refs to remove, and then rewriting the file.
Besides, it is bad taste to delete each individual item being
iterated over in an interator in general, isn't it?
^ permalink raw reply
* Re: [PATCH v15 01/27] bisect--helper: use OPT_CMDMODE instead of OPT_BOOL
From: Stephan Beyer @ 2016-11-15 21:40 UTC (permalink / raw)
To: Junio C Hamano, git
Cc: Pranit Bauva, Christian Couder, Matthieu Moy, Alex Henrie,
Antoine Delaite
In-Reply-To: <xmqqvawd7mnr.fsf@gitster.mtv.corp.google.com>
Hi,
On 10/27/2016 06:59 PM, Junio C Hamano wrote:
> Does any of you (and others on the list) have time and inclination
> to review this series?
Me, currently. ;)
Besides the things I'm mentioning in respective patch e-mails, I wonder
why several bisect--helper commands are prefixed by "bisect"; I'm
talking about:
git bisect--helper --bisect-clean-state
git bisect--helper --bisect-reset
git bisect--helper --bisect-write
git bisect--helper --bisect-check-and-set-terms
git bisect--helper --bisect-next-check
git bisect--helper --bisect-terms
git bisect--helper --bisect-start
etc.
instead of
git bisect--helper --clean-state
git bisect--helper --reset
git bisect--helper --write
git bisect--helper --check-and-set-terms
git bisect--helper --next-check
git bisect--helper --terms
git bisect--helper --start
etc.
Well, I know *why* they have these names: because the shell function
names are simply reused. But I don't know why these prefixes are kept in
the bisect--helper command options. On the other hand, these command
names are not exposed to the user and may hence not be that important.(?)
~Stephan
^ permalink raw reply
* Re: [PATCH v15 04/27] bisect--helper: `bisect_clean_state` shell function in C
From: Stephan Beyer @ 2016-11-15 21:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pranit Bauva, git
In-Reply-To: <xmqq37istoay.fsf@gitster.mtv.corp.google.com>
On 11/15/2016 10:40 PM, Junio C Hamano wrote:
> Stephan Beyer <s-beyer@gmx.net> writes:
>
>>> +int bisect_clean_state(void)
>>> +{
>>> + int result = 0;
>>> +
>>> + /* There may be some refs packed during bisection */
>>> + struct string_list refs_for_removal = STRING_LIST_INIT_NODUP;
>>> + for_each_ref_in("refs/bisect", mark_for_removal, (void *) &refs_for_removal);
>>> + string_list_append(&refs_for_removal, xstrdup("BISECT_HEAD"));
>>> + result = delete_refs(&refs_for_removal, REF_NODEREF);
>>> + refs_for_removal.strdup_strings = 1;
>>> + string_list_clear(&refs_for_removal, 0);
>>
>> Does it have advantages to populate a list (with duplicated strings),
>> hand it to delete_refs(), and clear the list (and strings), instead of
>> just doing a single delete_ref() (or whatever name the singular function
>> has) in the callback?
>
> Depending on ref backends, removing multiple refs may be a lot more
> efficient than calling a single ref removal for the same set of
> refs, and the comment upfront I think hints that the code was
> written in the way exactly with that in mind. Removing N refs from
> a packed refs file will involve a loop that runs N times, each
> iteration loading the file, locating an entry among possibly 100s of
> refs to remove, and then rewriting the file.
Great, that's the reply I wanted to hear (and that I've considered but
wasn't sure of) ;)
[I did not want to dig into the sources and check if delete_refs() does
something smarter than invoking delete_ref() on each item of the list.]
~Stephan
^ permalink raw reply
* Re: [PATCH v3 1/4] serialize collection of changed submodules
From: Stefan Beller @ 2016-11-15 22:15 UTC (permalink / raw)
To: Heiko Voigt
Cc: Junio C Hamano, git@vger.kernel.org, Jeff King, Jens Lehmann,
Fredrik Gustafsson, Leandro Lucarella
In-Reply-To: <67e11474d4fd8ada2652809cf14f6c4d96be55ff.1479221071.git.hvoigt@hvoigt.net>
On Tue, Nov 15, 2016 at 6:56 AM, Heiko Voigt <hvoigt@hvoigt.net> wrote:
> @@ -560,6 +575,31 @@ static void find_unpushed_submodule_commits(struct commit *commit,
> diff_tree_combined_merge(commit, 1, &rev);
> }
>
> +struct collect_submodule_from_sha1s_data {
> + char *submodule_path;
> + struct string_list *needs_pushing;
> +};
> +
> +static int collect_submodules_from_sha1s(const unsigned char sha1[20],
> + void *data)
> +{
> + struct collect_submodule_from_sha1s_data *me =
> + (struct collect_submodule_from_sha1s_data *) data;
nit: no explicit cast needed when coming from void* ?
^ permalink raw reply
* Re: [PATCH v3 2/4] serialize collection of refs that contain submodule changes
From: Stefan Beller @ 2016-11-15 22:20 UTC (permalink / raw)
To: Heiko Voigt
Cc: Junio C Hamano, git@vger.kernel.org, Jeff King, Jens Lehmann,
Fredrik Gustafsson, Leandro Lucarella
In-Reply-To: <616038c9b59cfcccce180de480c2a168921b9a63.1479221071.git.hvoigt@hvoigt.net>
On Tue, Nov 15, 2016 at 6:56 AM, Heiko Voigt <hvoigt@hvoigt.net> wrote:
> +++ b/submodule.c
> @@ -500,6 +500,13 @@ static int has_remote(const char *refname, const struct object_id *oid,
> return 1;
> }
>
> +static int append_sha1_to_argv(const unsigned char sha1[20], void *data)
> +{
> + struct argv_array *argv = (struct argv_array *) data;
nit: no explicit cast needed when coming from a void pointer.
^ permalink raw reply
* Re: [PATCH v3 3/4] batch check whether submodule needs pushing into one call
From: Stefan Beller @ 2016-11-15 22:28 UTC (permalink / raw)
To: Heiko Voigt
Cc: Junio C Hamano, git@vger.kernel.org, Jeff King, Jens Lehmann,
Fredrik Gustafsson, Leandro Lucarella
In-Reply-To: <0f1aaa07e151f6be87eb61b434f8c9448f8dad75.1479221071.git.hvoigt@hvoigt.net>
On Tue, Nov 15, 2016 at 6:56 AM, Heiko Voigt <hvoigt@hvoigt.net> wrote:
> -static int submodule_needs_pushing(const char *path, const unsigned char sha1[20])
> +static int check_has_commit(const unsigned char sha1[20], void *data)
> {
> - if (add_submodule_odb(path) || !lookup_commit_reference(sha1))
> + int *has_commit = (int *) data;
nit: just as prior patches ;) void* can be cast implicitly.
^ permalink raw reply
* Re: [PATCH v3 4/4] submodule_needs_pushing() NEEDSWORK when we can not answer this question
From: Stefan Beller @ 2016-11-15 22:39 UTC (permalink / raw)
To: Heiko Voigt
Cc: Junio C Hamano, git@vger.kernel.org, Jeff King, Jens Lehmann,
Fredrik Gustafsson, Leandro Lucarella
In-Reply-To: <1d87628994df89751afdcc7e180ebcdc29dde722.1479221071.git.hvoigt@hvoigt.net>
On Tue, Nov 15, 2016 at 6:56 AM, Heiko Voigt <hvoigt@hvoigt.net> wrote:
> Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
> ---
> submodule.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/submodule.c b/submodule.c
> index e1196fd..29efee9 100644
> --- a/submodule.c
> +++ b/submodule.c
> @@ -531,6 +531,14 @@ static int submodule_has_commits(const char *path, struct sha1_array *commits)
> static int submodule_needs_pushing(const char *path, struct sha1_array *commits)
> {
> if (!submodule_has_commits(path, commits))
> + /* NEEDSWORK: The correct answer here is "We do not
style nit:
/*
* Usually we prefer comments with both the first and last line of the
comment "empty".
*/
/* or just a one liner */
AFAICT these are the only two modes that we prefer in Git.
For a discussion of all the other style, enjoy Linus' guidance. ;)
http://lkml.iu.edu/hypermail/linux/kernel/1607.1/00627.html
> "We do not know" ...
... because there is no way to check for us as we don't have the
submodule commits.
" We do consider it safe as no one in their sane mind would
have changed the submodule pointers without having the
submodule around. If a user did however change the submodules
without having the submodule commits around, this indicates an
expert who knows what they were doing."
> We currently
> + * proceed pushing here as if the submodules commits are
> + * available on a remote. Since we can not check the
> + * remote availability for this submodule we should
> + * consider changing this behavior to: Stop here and
> + * tell the user how to skip this check if wanted.
> + */
> return 0;
Thanks for adding the NEEDSWORK, I just wrote the above lines
to clarify my thought process, not as a suggestion for change.
Overall the series looks good to me; the nits are minor IMHO.
Thanks,
Stefan
^ permalink raw reply
* [RFC PATCH 00/16] Checkout aware of Submodules!
From: Stefan Beller @ 2016-11-15 23:06 UTC (permalink / raw)
Cc: git, bmwill, gitster, jrnieder, mogulguy10, David.Turner,
Stefan Beller
When working with submodules, nearly anytime after checking out
a different state of the projects, that has submodules changed
you'd run "git submodule update" with a current version of Git.
There are two problems with this approach:
* The "submodule update" command is dangerous as it
doesn't check for work that may be lost in the submodule
(e.g. a dangling commit).
* you may forget to run the command as checkout is supposed
to do all the work for you.
Integrate updating the submodules into git checkout, with the same
safety promises that git-checkout has, i.e. not throw away data unless
asked to. This is done by first checking if the submodule is at the same
sha1 as it is recorded in the superproject. If there are changes we stop
proceeding the checkout just like it is when checking out a file that
has local changes.
The integration happens in the code that is also used in other commands
such that it will be easier in the future to make other commands aware
of submodule.
This also solves d/f conflicts in case you replace a file/directory
with a submodule or vice versa.
The patches are still a bit rough, but the overall series seems
promising enough to me that I want to put it out here.
Any review, specifically on the design level welcome!
Thanks,
Stefan
Stefan Beller (16):
submodule.h: add extern keyword to functions, break line before 80
submodule: modernize ok_to_remove_submodule to use argv_array
submodule: use absolute path for computing relative path connecting
update submodules: add is_submodule_populated
update submodules: add submodule config parsing
update submodules: add a config option to determine if submodules are
updated
update submodules: introduce submodule_is_interesting
update submodules: add depopulate_submodule
update submodules: add scheduling to update submodules
update submodules: is_submodule_checkout_safe
teach unpack_trees() to remove submodule contents
entry: write_entry to write populate submodules
submodule: teach unpack_trees() to update submodules
checkout: recurse into submodules if asked to
completion: add '--recurse-submodules' to checkout
checkout: add config option to recurse into submodules by default
Documentation/config.txt | 6 +
Documentation/git-checkout.txt | 8 +
builtin/checkout.c | 31 ++-
cache.h | 2 +
contrib/completion/git-completion.bash | 2 +-
entry.c | 17 +-
submodule-config.c | 22 +++
submodule-config.h | 17 +-
submodule.c | 246 +++++++++++++++++++++--
submodule.h | 77 +++++---
t/lib-submodule-update.sh | 10 +-
t/t2013-checkout-submodule.sh | 344 ++++++++++++++++++++++++++++++++-
t/t9902-completion.sh | 1 +
unpack-trees.c | 103 ++++++++--
unpack-trees.h | 1 +
wrapper.c | 4 +
16 files changed, 806 insertions(+), 85 deletions(-)
--
2.10.1.469.g00a8914
^ permalink raw reply
* [PATCH 01/16] submodule.h: add extern keyword to functions, break line before 80
From: Stefan Beller @ 2016-11-15 23:06 UTC (permalink / raw)
Cc: git, bmwill, gitster, jrnieder, mogulguy10, David.Turner,
Stefan Beller
In-Reply-To: <20161115230651.23953-1-sbeller@google.com>
As the upcoming series will add a lot of functions to the submodule
header, it's good to start of a sane base. So format the header to
not exceed 80 characters a line and mark all functions to be extern.
Signed-off-by: Stefan Beller <sbeller@google.com>
---
submodule.h | 60 ++++++++++++++++++++++++++++++++++--------------------------
1 file changed, 34 insertions(+), 26 deletions(-)
diff --git a/submodule.h b/submodule.h
index d9e197a..afc58d0 100644
--- a/submodule.h
+++ b/submodule.h
@@ -29,50 +29,58 @@ struct submodule_update_strategy {
};
#define SUBMODULE_UPDATE_STRATEGY_INIT {SM_UPDATE_UNSPECIFIED, NULL}
-int is_staging_gitmodules_ok(void);
-int update_path_in_gitmodules(const char *oldpath, const char *newpath);
-int remove_path_from_gitmodules(const char *path);
-void stage_updated_gitmodules(void);
-void set_diffopt_flags_from_submodule_config(struct diff_options *diffopt,
+extern int is_staging_gitmodules_ok(void);
+extern int update_path_in_gitmodules(const char *oldpath, const char *newpath);
+extern int remove_path_from_gitmodules(const char *path);
+extern void stage_updated_gitmodules(void);
+extern void set_diffopt_flags_from_submodule_config(
+ struct diff_options *diffopt,
const char *path);
-int submodule_config(const char *var, const char *value, void *cb);
-void gitmodules_config(void);
-int parse_submodule_update_strategy(const char *value,
+extern int submodule_config(const char *var, const char *value, void *cb);
+extern void gitmodules_config(void);
+extern int parse_submodule_update_strategy(const char *value,
struct submodule_update_strategy *dst);
-const char *submodule_strategy_to_string(const struct submodule_update_strategy *s);
-void handle_ignore_submodules_arg(struct diff_options *diffopt, const char *);
-void show_submodule_summary(FILE *f, const char *path,
+extern const char *submodule_strategy_to_string(
+ const struct submodule_update_strategy *s);
+extern void handle_ignore_submodules_arg(struct diff_options *diffopt,
+ const char *);
+extern void show_submodule_summary(FILE *f, const char *path,
const char *line_prefix,
struct object_id *one, struct object_id *two,
unsigned dirty_submodule, const char *meta,
const char *del, const char *add, const char *reset);
-void show_submodule_inline_diff(FILE *f, const char *path,
+extern void show_submodule_inline_diff(FILE *f, const char *path,
const char *line_prefix,
struct object_id *one, struct object_id *two,
unsigned dirty_submodule, const char *meta,
const char *del, const char *add, const char *reset,
const struct diff_options *opt);
-void set_config_fetch_recurse_submodules(int value);
-void check_for_new_submodule_commits(unsigned char new_sha1[20]);
-int fetch_populated_submodules(const struct argv_array *options,
+extern void set_config_fetch_recurse_submodules(int value);
+extern void check_for_new_submodule_commits(unsigned char new_sha1[20]);
+extern int fetch_populated_submodules(const struct argv_array *options,
const char *prefix, int command_line_option,
int quiet, int max_parallel_jobs);
-unsigned is_submodule_modified(const char *path, int ignore_untracked);
-int submodule_uses_gitfile(const char *path);
-int ok_to_remove_submodule(const char *path);
-int merge_submodule(unsigned char result[20], const char *path, const unsigned char base[20],
- const unsigned char a[20], const unsigned char b[20], int search);
-int find_unpushed_submodules(unsigned char new_sha1[20], const char *remotes_name,
- struct string_list *needs_pushing);
-int push_unpushed_submodules(unsigned char new_sha1[20], const char *remotes_name);
-void connect_work_tree_and_git_dir(const char *work_tree, const char *git_dir);
-int parallel_submodules(void);
+extern unsigned is_submodule_modified(const char *path, int ignore_untracked);
+extern int submodule_uses_gitfile(const char *path);
+extern int ok_to_remove_submodule(const char *path);
+extern int merge_submodule(unsigned char result[20], const char *path,
+ const unsigned char base[20],
+ const unsigned char a[20],
+ const unsigned char b[20], int search);
+extern int find_unpushed_submodules(unsigned char new_sha1[20],
+ const char *remotes_name,
+ struct string_list *needs_pushing);
+extern int push_unpushed_submodules(unsigned char new_sha1[20],
+ const char *remotes_name);
+extern void connect_work_tree_and_git_dir(const char *work_tree,
+ const char *git_dir);
+extern int parallel_submodules(void);
/*
* Prepare the "env_array" parameter of a "struct child_process" for executing
* a submodule by clearing any repo-specific envirionment variables, but
* retaining any config in the environment.
*/
-void prepare_submodule_repo_env(struct argv_array *out);
+extern void prepare_submodule_repo_env(struct argv_array *out);
#endif
--
2.10.1.469.g00a8914
^ permalink raw reply related
* [PATCH 06/16] update submodules: add a config option to determine if submodules are updated
From: Stefan Beller @ 2016-11-15 23:06 UTC (permalink / raw)
Cc: git, bmwill, gitster, jrnieder, mogulguy10, David.Turner,
Stefan Beller
In-Reply-To: <20161115230651.23953-1-sbeller@google.com>
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 <sbeller@google.com>
---
submodule.c | 6 ++++++
submodule.h | 1 +
2 files changed, 7 insertions(+)
diff --git a/submodule.c b/submodule.c
index 97eaf7c..38b0573 100644
--- a/submodule.c
+++ b/submodule.c
@@ -16,6 +16,7 @@
#include "quote.h"
static int config_fetch_recurse_submodules = RECURSE_SUBMODULES_ON_DEMAND;
+static int config_update_recurse_submodules = RECURSE_SUBMODULES_DEFAULT;
static int parallel_jobs = 1;
static struct string_list changed_submodule_paths = STRING_LIST_INIT_NODUP;
static int initialized_fetch_ref_tips;
@@ -494,6 +495,11 @@ void set_config_fetch_recurse_submodules(int value)
config_fetch_recurse_submodules = value;
}
+void set_config_update_recurse_submodules(int value)
+{
+ config_update_recurse_submodules = value;
+}
+
static int has_remote(const char *refname, const struct object_id *oid,
int flags, void *cb_data)
{
diff --git a/submodule.h b/submodule.h
index d44b4f1..185ad18 100644
--- a/submodule.h
+++ b/submodule.h
@@ -56,6 +56,7 @@ extern void show_submodule_inline_diff(FILE *f, const char *path,
const char *del, const char *add, const char *reset,
const struct diff_options *opt);
extern void set_config_fetch_recurse_submodules(int value);
+extern void set_config_update_recurse_submodules(int value);
extern void check_for_new_submodule_commits(unsigned char new_sha1[20]);
extern int fetch_populated_submodules(const struct argv_array *options,
const char *prefix, int command_line_option,
--
2.10.1.469.g00a8914
^ permalink raw reply related
* [PATCH 08/16] update submodules: add depopulate_submodule
From: Stefan Beller @ 2016-11-15 23:06 UTC (permalink / raw)
Cc: git, bmwill, gitster, jrnieder, mogulguy10, David.Turner,
Stefan Beller
In-Reply-To: <20161115230651.23953-1-sbeller@google.com>
Implement the functionality needed to enable work tree manipulating
commands to that a deleted submodule should not only affect the index
(leaving all the files of the submodule in the work tree) but also to
remove the work tree of the superproject (including any untracked
files).
To do so, we need an equivalent of "rm -rf", which is already found in
entry.c, so expose that and for clarity add a suffix "_or_dir" to it.
That will only work properly when the submodule uses a gitfile instead of
a .git directory and no untracked files are present. Otherwise the removal
will fail with a warning (which is just what happened until now).
Signed-off-by: Stefan Beller <sbeller@google.com>
---
cache.h | 2 ++
entry.c | 8 ++++++++
submodule.c | 25 +++++++++++++++++++++++++
submodule.h | 1 +
4 files changed, 36 insertions(+)
diff --git a/cache.h b/cache.h
index a50a61a..65c47e4 100644
--- a/cache.h
+++ b/cache.h
@@ -2018,4 +2018,6 @@ void sleep_millisec(int millisec);
*/
void safe_create_dir(const char *dir, int share);
+void remove_subtree_or_die(const char *path);
+
#endif /* CACHE_H */
diff --git a/entry.c b/entry.c
index c6eea24..019826b 100644
--- a/entry.c
+++ b/entry.c
@@ -73,6 +73,14 @@ static void remove_subtree(struct strbuf *path)
die_errno("cannot rmdir '%s'", path->buf);
}
+void remove_subtree_or_die(const char *path)
+{
+ struct strbuf sb = STRBUF_INIT;
+ strbuf_addstr(&sb, path);
+ remove_subtree(&sb);
+ strbuf_release(&sb);
+}
+
static int create_file(const char *path, unsigned int mode)
{
mode = (mode & 0100) ? 0777 : 0666;
diff --git a/submodule.c b/submodule.c
index d34b721..0fa4613 100644
--- a/submodule.c
+++ b/submodule.c
@@ -308,6 +308,31 @@ static void print_submodule_summary(struct rev_info *rev, FILE *f,
strbuf_release(&sb);
}
+int depopulate_submodule(const char *path)
+{
+ int ret = 0;
+ char *dot_git = xstrfmt("%s/.git", path);
+
+ /* Is it populated? */
+ if (!resolve_gitdir(dot_git))
+ goto out;
+
+ /* Does it have a .git directory? */
+ if (!submodule_uses_gitfile(path)) {
+ warning(_("cannot remove submodule '%s' because it (or one of "
+ "its nested submodules) uses a .git directory"),
+ path);
+ ret = -1;
+ goto out;
+ }
+
+ remove_subtree_or_die(path);
+
+out:
+ free(dot_git);
+ return ret;
+}
+
/* Helper function to display the submodule header line prior to the full
* summary output. If it can locate the submodule objects directory it will
* attempt to lookup both the left and right commits and put them into the
diff --git a/submodule.h b/submodule.h
index 3df6881..8518cf3 100644
--- a/submodule.h
+++ b/submodule.h
@@ -65,6 +65,7 @@ extern void set_config_update_recurse_submodules(int value);
*/
extern int submodule_is_interesting(const char *path, const unsigned char *sha1);
extern int submodules_interesting_for_update(void);
+extern int depopulate_submodule(const char *path);
extern void check_for_new_submodule_commits(unsigned char new_sha1[20]);
extern int fetch_populated_submodules(const struct argv_array *options,
const char *prefix, int command_line_option,
--
2.10.1.469.g00a8914
^ permalink raw reply related
* [PATCH 11/16] teach unpack_trees() to remove submodule contents
From: Stefan Beller @ 2016-11-15 23:06 UTC (permalink / raw)
Cc: git, bmwill, gitster, jrnieder, mogulguy10, David.Turner,
Stefan Beller
In-Reply-To: <20161115230651.23953-1-sbeller@google.com>
Extend rmdir_or_warn() to remove the directories of those submodules which
are scheduled for removal. Also teach verify_clean_submodule() to check
that a submodule configured to be removed is not modified before scheduling
it for removal.
Signed-off-by: Stefan Beller <sbeller@google.com>
---
unpack-trees.c | 6 ++----
wrapper.c | 4 ++++
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/unpack-trees.c b/unpack-trees.c
index ea6bdd2..576e1d5 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -9,6 +9,7 @@
#include "refs.h"
#include "attr.h"
#include "split-index.h"
+#include "submodule.h"
#include "dir.h"
/*
@@ -1361,15 +1362,12 @@ static void invalidate_ce_path(const struct cache_entry *ce,
/*
* Check that checking out ce->sha1 in subdir ce->name is not
* going to overwrite any working files.
- *
- * Currently, git does not checkout subprojects during a superproject
- * checkout, so it is not going to overwrite anything.
*/
static int verify_clean_submodule(const struct cache_entry *ce,
enum unpack_trees_error_types error_type,
struct unpack_trees_options *o)
{
- return 0;
+ return submodule_is_interesting(ce->name, null_sha1) && is_submodule_modified(ce->name, 0);
}
static int verify_clean_subdirectory(const struct cache_entry *ce,
diff --git a/wrapper.c b/wrapper.c
index e7f1979..17c08de 100644
--- a/wrapper.c
+++ b/wrapper.c
@@ -2,6 +2,7 @@
* Various trivial helper wrappers around standard functions
*/
#include "cache.h"
+#include "submodule.h"
static void do_nothing(size_t size)
{
@@ -592,6 +593,9 @@ int unlink_or_warn(const char *file)
int rmdir_or_warn(const char *file)
{
+ if (submodule_is_interesting(file, null_sha1)
+ && depopulate_submodule(file))
+ return -1;
return warn_if_unremovable("rmdir", file, rmdir(file));
}
--
2.10.1.469.g00a8914
^ permalink raw reply related
* [PATCH 09/16] update submodules: add scheduling to update submodules
From: Stefan Beller @ 2016-11-15 23:06 UTC (permalink / raw)
Cc: git, bmwill, gitster, jrnieder, mogulguy10, David.Turner,
Stefan Beller
In-Reply-To: <20161115230651.23953-1-sbeller@google.com>
The walker of a tree is only expected to call `schedule_submodule_for_update`
and once done, to run `update_submodules`. This avoids directory/file
conflicts and later we can parallelize all submodule actions if needed.
Signed-off-by: Stefan Beller <sbeller@google.com>
---
submodule.c | 117 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
submodule.h | 4 +++
2 files changed, 121 insertions(+)
diff --git a/submodule.c b/submodule.c
index 0fa4613..2773151 100644
--- a/submodule.c
+++ b/submodule.c
@@ -308,6 +308,75 @@ static void print_submodule_summary(struct rev_info *rev, FILE *f,
strbuf_release(&sb);
}
+static int update_submodule(const char *path, const struct object_id *oid,
+ int force, int is_new)
+{
+ const char *git_dir;
+ struct child_process cp = CHILD_PROCESS_INIT;
+ const struct submodule *sub = submodule_from_path(null_sha1, path);
+
+ if (!sub || !sub->name)
+ return -1;
+
+ git_dir = resolve_gitdir(git_common_path("modules/%s", sub->name));
+
+ if (!git_dir)
+ return -1;
+
+ if (is_new)
+ connect_work_tree_and_git_dir(path, git_dir);
+
+ /* update index via `read-tree --reset sha1` */
+ argv_array_pushl(&cp.args, "read-tree",
+ force ? "--reset" : "-m",
+ "-u", sha1_to_hex(oid->hash), NULL);
+ prepare_submodule_repo_env(&cp.env_array);
+ cp.git_cmd = 1;
+ cp.no_stdin = 1;
+ cp.dir = path;
+ if (run_command(&cp)) {
+ warning(_("reading the index in submodule '%s' failed"), path);
+ child_process_clear(&cp);
+ return -1;
+ }
+
+ /* write index to working dir */
+ child_process_clear(&cp);
+ child_process_init(&cp);
+ argv_array_pushl(&cp.args, "checkout-index", "-a", NULL);
+ cp.git_cmd = 1;
+ cp.no_stdin = 1;
+ cp.dir = path;
+ if (force)
+ argv_array_push(&cp.args, "-f");
+
+ if (run_command(&cp)) {
+ warning(_("populating the working directory in submodule '%s' failed"), path);
+ child_process_clear(&cp);
+ return -1;
+ }
+
+ /* get the HEAD right */
+ child_process_clear(&cp);
+ child_process_init(&cp);
+ argv_array_pushl(&cp.args, "checkout", "--recurse-submodules", NULL);
+ cp.git_cmd = 1;
+ cp.no_stdin = 1;
+ cp.dir = path;
+ if (force)
+ argv_array_push(&cp.args, "-f");
+ argv_array_push(&cp.args, sha1_to_hex(oid->hash));
+
+ if (run_command(&cp)) {
+ warning(_("setting the HEAD in submodule '%s' failed"), path);
+ child_process_clear(&cp);
+ return -1;
+ }
+
+ child_process_clear(&cp);
+ return 0;
+}
+
int depopulate_submodule(const char *path)
{
int ret = 0;
@@ -1336,3 +1405,51 @@ void prepare_submodule_repo_env(struct argv_array *out)
}
argv_array_push(out, "GIT_DIR=.git");
}
+
+struct scheduled_submodules_update_type {
+ const char *path;
+ const struct object_id *oid;
+ /*
+ * Do we need to perform a complete checkout or just incremental
+ * update?
+ */
+ unsigned is_new:1;
+} *scheduled_submodules;
+#define SCHEDULED_SUBMODULES_INIT {NULL, NULL}
+
+int scheduled_submodules_nr, scheduled_submodules_alloc;
+
+void schedule_submodule_for_update(const struct cache_entry *ce, int is_new)
+{
+ struct scheduled_submodules_update_type *ssu;
+ ALLOC_GROW(scheduled_submodules,
+ scheduled_submodules_nr + 1,
+ scheduled_submodules_alloc);
+ ssu = &scheduled_submodules[scheduled_submodules_nr++];
+ ssu->path = ce->name;
+ ssu->oid = &ce->oid;
+ ssu->is_new = !!is_new;
+}
+
+int update_submodules(int force)
+{
+ int i;
+ gitmodules_config();
+
+ /*
+ * NEEDSWORK: As submodule updates can potentially take some
+ * time each and they do not overlap (i.e. no d/f conflicts;
+ * this can be parallelized using the run_commands.h API.
+ */
+ for (i = 0; i < scheduled_submodules_nr; i++) {
+ struct scheduled_submodules_update_type *ssu =
+ &scheduled_submodules[i];
+
+ if (submodule_is_interesting(ssu->path, null_sha1))
+ update_submodule(ssu->path, ssu->oid,
+ force, ssu->is_new);
+ }
+
+ scheduled_submodules_nr = 0;
+ return 0;
+}
diff --git a/submodule.h b/submodule.h
index 8518cf3..f01f87c 100644
--- a/submodule.h
+++ b/submodule.h
@@ -94,4 +94,8 @@ extern int parallel_submodules(void);
*/
extern void prepare_submodule_repo_env(struct argv_array *out);
+extern void schedule_submodule_for_update(const struct cache_entry *ce,
+ int new);
+extern int update_submodules(int force);
+
#endif
--
2.10.1.469.g00a8914
^ permalink raw reply related
* [PATCH 12/16] entry: write_entry to write populate submodules
From: Stefan Beller @ 2016-11-15 23:06 UTC (permalink / raw)
Cc: git, bmwill, gitster, jrnieder, mogulguy10, David.Turner,
Stefan Beller
In-Reply-To: <20161115230651.23953-1-sbeller@google.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
---
entry.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/entry.c b/entry.c
index 019826b..2330b6e 100644
--- a/entry.c
+++ b/entry.c
@@ -2,6 +2,7 @@
#include "blob.h"
#include "dir.h"
#include "streaming.h"
+#include "submodule.h"
static void create_directories(const char *path, int path_len,
const struct checkout *state)
@@ -211,6 +212,7 @@ static int write_entry(struct cache_entry *ce,
return error("cannot create temporary submodule %s", path);
if (mkdir(path, 0777) < 0)
return error("cannot create submodule directory %s", path);
+ schedule_submodule_for_update(ce, 1);
break;
default:
return error("unknown file mode for %s in index", path);
--
2.10.1.469.g00a8914
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox