On Mon, Aug 08, 2016 at 09:56:00AM -0400, Jeff King wrote:
> On Fri, Jul 29, 2016 at 10:47:46AM +0300, Kirill Smelkov wrote:
>
> > @@ -2527,7 +2528,7 @@ static int get_object_list_from_bitmap(struct
> > rev_info *revs)
> > if (prepare_bitmap_walk(revs) < 0)
> > return -1;
> >
>
Kirill Smelkov writes:
>> > ...
>> > Suggested-by: Junio C Hamano
>> > Discussed-with: Jeff King
>> > ---
>>
>> I do not think I suggested much of this to deserve credit like this,
>> though, as I certainly haven't thought about the
Hi Torsten,
I remember that you did a ton of work on t0027. Now I see problems, and
not only that the entire script now takes a whopping 4 minutes 20 seconds
to run on my high-end Windows machine.
It appears that t0027 fails randomly for me, in seemingly random places.
Sometimes all 1388 cases
Jeff King writes:
> On Mon, Aug 08, 2016 at 03:37:35PM +0300, Kirill Smelkov wrote:
> ...
> static int want_object_in_pack(...)
> {
> ...
> if (!exclude && local && has_loose_object_nonlocal(sha1))
> return 0;
>
> if (*found_pack) {
>
On Sat, Aug 06, 2016 at 08:19:28PM +0200, Lars Schneider wrote:
> > I dunno. It's not _that_ big a deal to code around. I was just surprised
> > not to see an up-front status when responding to a request. It seems
> > like the normal thing in just about every protocol I've ever used.
>
>
Jeff King writes:
>> It worries me a lot to lose the warning unconditionally, though.
>> That's the (only) coal-mine canary that lets us notice a problem
>> when we actually start hitting that last-ditch cycle breaking too
>> often.
>
> The dedicated cycle-detection will lose that
Am 07.08.2016 um 22:34 schrieb Ramsay Jones:
On 05/08/16 23:26, Johannes Sixt wrote:
When refs.c is being compiled, the only mention of enum
iterator_selection is in this piece of code pulled in from
refs-internal.h(have a look at the preprocessed code):
typedef enum iterator_selection
On Mon, Aug 08, 2016 at 09:28:29AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Here's a list of approaches I think we can use to fix this:
> >
> > 1. squelch the warning and ignore it. The downside here, besides not
> > warning the user about true in-pack
Jeff King writes:
> Here's a list of approaches I think we can use to fix this:
>
> 1. squelch the warning and ignore it. The downside here, besides not
> warning the user about true in-pack cycles, is that we have no
> opportunity to actually find a new delta (because
Johannes Schindelin writes:
> I think you both got it wrong. The original citizens were the mail
> clients that allowed you to communicate with other human beings.
> ... It is our usage to transport machine-readable content (and not
> as an attachment!) that is the
Duy Nguyen writes:
> git-notes was mentioned in this thread back in 2015, but I think it's
> discarded because of the argument that's part of the cover letter was
> not meant to be kept permanently.
I do not think the reason why we didn't think the notes mechanism
was a good
On Thu, Sep 10, 2015 at 9:28 AM, Jacob Keller wrote:
> Hey,
>
> does anyone know of any tricks for storing a cover letter for a patch
> series inside of git somehow? I'd guess the only obvious way currently
> is to store it at the top of the series as an empty commit.. but
> On 08 Aug 2016, at 17:02, Jeff King wrote:
>
> On Sat, Aug 06, 2016 at 08:19:28PM +0200, Lars Schneider wrote:
>
>>> I dunno. It's not _that_ big a deal to code around. I was just surprised
>>> not to see an up-front status when responding to a request. It seems
>>> like the
On Mon, Aug 08, 2016 at 06:21:18PM +0200, Lars Schneider wrote:
> >> Happy answer with no content:
> >>
> >> packet: git< status=success\n
> >>
> >
> > This can just be spelled:
> >
> > git< status=success
> > git<
> > git<
Jeff Hostetler writes:
> +test_expect_success pre_initial_commit_0 '
> + ...
> + git status --porcelain=v2 --branch --untracked-files=normal >actual &&
> + test_cmp expect actual
> +'
> +
> +
> +test_expect_success pre_initial_commit_1 '
> + git add file_x
Lars Schneider writes:
> ... then I am always super
> eager to send out a new roll just because I don't want any other reviewer
> to waste time on obviously wrong patches. However, I have the impression
> that frequent re-rolls are frowned upon.
To libify `git apply` functionality we have to signal errors to the
caller instead of die()ing.
To do that in a compatible manner with the rest of the error handling
in "builtin/apply.c", check_apply_state() should return -1 instead of
calling die().
Signed-off-by: Christian Couder
To libify `git apply` functionality we have to signal errors to the
caller instead of die()ing.
To do that in a compatible manner with the rest of the error handling
in "builtin/apply.c", add_index_file() should return -1 instead of
calling die().
Signed-off-by: Christian Couder
On Mon, Aug 8, 2016 at 11:02 PM, Christian Couder
wrote:
>
> I will send a diff between this version and the previous one, as a
> reply to this email.
Here is the diff:
diff --git a/apply.c b/apply.c
index a73889e..2ec2a8a 100644
--- a/apply.c
+++ b/apply.c
@@
To libify `git apply` functionality we have to signal errors to the
caller instead of exit()ing.
To do that in a compatible manner with the rest of the error handling
in "builtin/apply.c", create_one_file() should return -1 instead of
calling exit().
Signed-off-by: Christian Couder
To avoid possible mistakes and to uniformly show the errno
related messages, let's use error_errno() where possible.
Signed-off-by: Christian Couder
---
apply.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/apply.c b/apply.c
The constants for the "inaccurate-eof" and the "recount" options will
be used in both "apply.c" and "builtin/apply.c", so they need to go
into "apply.h", and therefore they need a name that is more specific
to the API they belong to.
Signed-off-by: Christian Couder
---
Let's make it possible to get the current error_routine and warn_routine,
so that we can store them before using set_error_routine() or
set_warn_routine() to use new ones.
This way we will be able put back the original routines, when we are done
with using new ones.
Signed-off-by: Christian
To libify `git apply` functionality we have to signal errors to the
caller instead of die()ing.
To do that in a compatible manner with the rest of the error handling
in "builtin/apply.c", remove_file() should return -1 instead of
calling die().
Signed-off-by: Christian Couder
This changes 'int apply_verbosely' into 'enum apply_verbosity', and
changes the possible values of the variable from a bool to
a tristate.
The previous 'false' state is changed into 'verbosity_normal'.
The previous 'true' state is changed into 'verbosity_verbose'.
The new added state is
There are already set_die_routine() and set_error_routine(),
so let's add set_warn_routine() as this will be needed in a
following commit.
Signed-off-by: Christian Couder
---
git-compat-util.h | 1 +
usage.c | 5 +
2 files changed, 6 insertions(+)
diff
To libify `git apply` functionality we have to signal errors to the
caller instead of exit()ing.
To do that in a compatible manner with the rest of the error handling
in "builtin/apply.c", write_out_one_result() should just return what
remove_file() and create_file() are returning instead of
To avoid printing anything when applying with
`state->apply_verbosity == verbosity_silent`, let's save the
existing warn and error routines before applying, and let's
replace them with a routine that does nothing.
Then after applying, let's restore the saved routines.
Helped-by: Stefan Beller
Parsing `git apply` options can be useful to other commands that
want to call the libified apply functionality, because this way
they can easily pass some options from their own command line to
the libified apply functionality.
This will be used by `git am` in a following patch.
To make this
The gitdiff_*() functions that are called as p->fn() in parse_git_header()
should return 1 instead of -1 in case of end of header or unrecognized
input, as these are not real errors. It just instructs the parser to break
out.
This makes it possible for gitdiff_*() functions to return -1 in case
As these functions are going to be part of the libified
apply api, let's give them a name that is more specific
to the apply api.
Signed-off-by: Christian Couder
---
builtin/apply.c | 40
1 file changed, 20 insertions(+), 20
To libify `git apply` functionality we have to signal errors to the
caller instead of die()ing.
To do that in a compatible manner with the rest of the error handling
in "builtin/apply.c", die_on_unsafe_path() should return a negative
integer instead of calling die(), so while doing that let's
When apply_verbosity is set to verbosity_silent nothing should be
printed on both stderr and stdout.
To avoid printing on stdout, we can just skip calling the following
functions:
- stat_patch_list(),
- numstat_patch_list(),
- summary_patch_list().
It is safe to do that
To libify `git apply` functionality we must make check_apply_state()
usable outside "builtin/apply.c".
Let's do that by moving it into "apply.c".
Signed-off-by: Christian Couder
---
apply.c | 32
apply.h | 1 +
To libify `git apply` functionality we have to signal errors to the
caller instead of die()ing.
To do that in a compatible manner with the rest of the error handling
in "builtin/apply.c", gitdiff_*() functions should return -1 instead
of calling die().
A previous patch made it possible for
To prepare for some structs and constants being moved from
builtin/apply.c to apply.h, we should give them some more
specific names to avoid possible name collisions in th global
namespace.
Signed-off-by: Christian Couder
---
builtin/apply.c | 20 ++--
1
To finish libifying the apply functionality, apply_all_patches() should not
die() or exit() in case of error, but return either 128 or 1, so that it
gives the same exit code as when die() or exit(1) is called. This way
scripts relying on the exit code don't need to be changed.
While doing that we
To libify `git apply` functionality we have to signal errors to the
caller instead of die()ing.
To do that in a compatible manner with the rest of the error handling
in builtin/apply.c, parse_single_patch() should return a negative
integer instead of calling die().
Let's do that by using error()
To libify `git apply` functionality we have to signal errors to the
caller instead of die()ing.
To do that in a compatible manner with the rest of the error handling
in "builtin/apply.c", try_create_file() should return -1 in case of
error.
Unfortunately try_create_file() currently returns -1 to
This replaces run_apply() implementation with a new one that
uses the apply api that has been previously prepared in
apply.c and apply.h.
This shoud improve performance a lot in certain cases.
As the previous implementation was creating a new `git apply`
process to apply each patch, it could be
To libify `git apply` functionality we have to signal errors to the
caller instead of die()ing.
To do that in a compatible manner with the rest of the error handling
in builtin/apply.c, parse_whitespace_option() should return -1 instead
of calling die().
Signed-off-by: Christian Couder
To libify `git apply` functionality we have to signal errors to the
caller instead of die()ing.
To do that in a compatible manner with the rest of the error handling
in "builtin/apply.c", build_fake_ancestor() should return -1 instead
of calling die().
Helped-by: Eric Sunshine
To libify `git apply` functionality we must make init_apply_state()
usable outside "builtin/apply.c".
Let's do that by moving it into a new "apply.c".
Helped-by: Eric Sunshine
Signed-off-by: Christian Couder
---
Makefile| 1 +
apply.c
To libify `git apply` functionality we have to signal errors to the
caller instead of die()ing. Let's do that by returning -1 instead of
die()ing in read_patch_file().
Helped-by: Stefan Beller
Signed-off-by: Christian Couder
---
builtin/apply.c | 8
To libify `git apply` functionality we have to signal errors to the
caller instead of die()ing or exit()ing.
To do that in a compatible manner with the rest of the error handling
in builtin/apply.c, parse_chunk() should return a negative integer
instead of calling die() or exit().
As
To libify `git apply` functionality we have to signal errors
to the caller instead of die()ing.
As a first step in this direction, let's make apply_patch() return
-1 or -128 in case of errors instead of dying. For now its only
caller apply_all_patches() will exit(128) when apply_patch()
return
To libify `git apply` functionality we have to signal errors to the
caller instead of die()ing.
To do that in a compatible manner with the rest of the error handling
in "builtin/apply.c", parse_ignorewhitespace_option() should return
-1 instead of calling die().
Signed-off-by: Christian Couder
To libify `git apply` functionality we have to signal errors to the
caller instead of die()ing.
To do that in a compatible manner with the rest of the error handling
in builtin/apply.c, let's make find_header() return -128 instead of
calling die().
We could make it return -1, unfortunately
To libify `git apply` functionality we have to signal errors to the
caller instead of exit()ing.
To do that in a compatible manner with the rest of the error handling
in "builtin/apply.c", init_apply_state() should return -1 instead of
calling exit().
Signed-off-by: Christian Couder
To libify `git apply` functionality we have to signal errors to the
caller instead of exit()ing.
To do that in a compatible manner with the rest of the error handling
in "builtin/apply.c", create_file() should just return what
add_conflicted_stages_file() and add_index_file() are returning
Introduce set_index_file() to be able to temporarily change the
index file.
Yeah, this is a short cut and this new function should not be used
by other code.
It adds a small technical debt, because unfortunately a very big
technical debt already exists as the apply code and a lot of other
To libify `git apply` functionality we must make 'struct apply_state'
usable outside "builtin/apply.c".
Let's do that by creating a new "apply.h" and moving
'struct apply_state' there.
Signed-off-by: Christian Couder
---
apply.h | 100
To libify `git apply` functionality we have to signal errors to the
caller instead of die()ing.
To do that in a compatible manner with the rest of the error handling
in "builtin/apply.c", add_conflicted_stages_file() should return -1
instead of calling die().
Helped-by: Eric Sunshine
To libify `git apply` functionality we have to signal errors to the
caller instead of die()ing.
To do that in a compatible manner with the rest of the error handling
in "builtin/apply.c", parse_traditional_patch() should return -1
instead of calling die().
Signed-off-by: Christian Couder
Some parsing functions that were used in both "apply.c" and
"builtin/apply.c" are now only used in the former, so they
can be made static to "apply.c".
Signed-off-by: Christian Couder
---
apply.c | 6 +++---
apply.h | 5 -
2 files changed, 3 insertions(+), 8
To libify `git apply` functionality we have to signal errors to the
caller instead of exit()ing.
To do that in a compatible manner with the rest of the error handling
in "builtin/apply.c", write_out_results() should return -1 instead of
calling exit().
Helped-by: Eric Sunshine
Signed-off-by: Christian Couder
---
.mailmap | 1 +
1 file changed, 1 insertion(+)
diff --git a/.mailmap b/.mailmap
index a714e69..9441a54 100644
--- a/.mailmap
+++ b/.mailmap
@@ -33,6 +33,7 @@ Cheng Renquan
Chris Shoemaker
Christian Couder writes:
> Now if someone really needs to use this new function, it should be
> used like this:
>
> /* Save current index file */
> old_index_file = get_index_file();
> set_index_file((char *)tmp_index_file);
>
> /* Do stuff that will
Christian Couder writes:
> diff --git a/apply.h b/apply.h
> index 27a3a7a..e2b89e8 100644
> --- a/apply.h
> +++ b/apply.h
> @@ -16,7 +16,7 @@ enum apply_ws_ignore {
> enum apply_verbosity {
> verbosity_silent = -1,
> verbosity_normal = 0,
> -
On 08/04/2016 05:58 PM, Johannes Schindelin wrote:
> [...]
> Even requiring every contributor to register with GitHub would be too much
> of a limitation, I would wager.
> [...]
Is it *really* so insane to consider moving collaboration on the Git
project to GitHub or some other similar platform?
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.
Many topics in "Cooking" section
Michael Haggerty writes:
> Is it *really* so insane to consider moving collaboration on the Git
> project to GitHub or some other similar platform?
I only know how "pull requests" and "issues" discussion in GitHub
Web interface _currently_ looks like, so if you have even
On Mon, Aug 8, 2016 at 3:32 PM, Junio C Hamano wrote:
>
> * sb/submodule-clone-rr (2016-08-06) 6 commits
> - clone: reference flag is used for submodules as well
> - submodule update: add super-reference flag
> - submodule--helper update-clone: allow multiple references
> -
Johannes Schindelin writes:
> I wonder, however, if we could somhow turn things around by introducing
> something like
>
> split_and_do_for_each(item_p, length, string, delimiter)
> ... ...
>
> that both string_list_split() *and* add_strategies()
On 08/08/16 19:28, Ramsay Jones wrote:
>
>
> On 08/08/16 17:30, Johannes Sixt wrote:
>> Am 07.08.2016 um 22:34 schrieb Ramsay Jones:
>>> On 05/08/16 23:26, Johannes Sixt wrote:
> [snip]
>>> At this point 'enum iterator_selection' is an incomplete type and may
>>> be used when the size of the
Since 6b8fda2d (pack-objects: use bitmaps when packing objects) there
are two codepaths in pack-objects: with & without using bitmap
reachability index.
However add_object_entry_from_bitmap(), despite its non-bitmapped
counterpart add_object_entry(), in no way does check for whether --local
or
Kirill Smelkov writes:
> Thanks for the info. I did not knew about show-index when I was starting
> to work on this and later it just came out of sight. Please find
> corrected patch below.
>
> 8<
> From: Kirill Smelkov
> Date: Fri, 29 Jul 2016
On Sat, Aug 6, 2016 at 10:29 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> Some submodules in the referenced superproject may not be there,
>> (they are just not initialized/cloned/checked out), which yields
>> an error for now.
>
> Perhaps you
( updated patch is in the end of this mail )
Jeff, first of all thanks for commenting,
On Mon, Aug 08, 2016 at 09:50:20AM -0400, Jeff King wrote:
> On Mon, Aug 08, 2016 at 03:37:35PM +0300, Kirill Smelkov wrote:
>
> > @@ -958,15 +958,30 @@ static int want_object_in_pack(const unsigned char
>
On 08/08/16 17:30, Johannes Sixt wrote:
> Am 07.08.2016 um 22:34 schrieb Ramsay Jones:
>> On 05/08/16 23:26, Johannes Sixt wrote:
[snip]
>> At this point 'enum iterator_selection' is an incomplete type and may
>> be used when the size of the object is not required. It is not needed,
>> for
Starting from 6b8fda2d (pack-objects: use bitmaps when packing objects)
if a repository has bitmap index, pack-objects can nicely speedup
"Counting objects" graph traversal phase. That however was done only for
case when resultant pack is sent to stdout, not written into a file.
The reason here
On Mon, Aug 08, 2016 at 11:28:02AM -0700, Junio C Hamano wrote:
> Kirill Smelkov writes:
>
> > Another question: I'm preparing another version of "pack-objects: Teach
> > --use-bitmap-index codepath to respect --local ..." and was going to
> > put
> >
> > ( updated patch is
On 2016-08-08 17.05, Johannes Schindelin wrote:
> Hi Torsten,
>
> I remember that you did a ton of work on t0027. Now I see problems, and
> not only that the entire script now takes a whopping 4 minutes 20 seconds
> to run on my high-end Windows machine.
>
> It appears that t0027 fails randomly
Kirill Smelkov writes:
> Another question: I'm preparing another version of "pack-objects: Teach
> --use-bitmap-index codepath to respect --local ..." and was going to
> put
>
> ( updated patch is in the end of this mail )
>
> in the top of the message. Is it ok or better
Jeff King writes:
>> +if grep -qFf nonlocal-loose 1.objects; then
>> +echo "Non-local object present in pack generated with --local"
>> +return 1
>> +fi
>> +'
>
> grep -f isn't portable. However, I think:
>
> echo $objsha1 >expect &&
> git
Josh Triplett writes:
> I didn't realize you had already taken the patch series into next; I'd
> assumed from the various comments that you expected me to reroll it
> before you'd take it.
>
> Would you like me to write something up for the release notes regarding
> plans
On Mon, Aug 08, 2016 at 11:08:34AM -0700, Junio C Hamano wrote:
> Kirill Smelkov writes:
>
> > Thanks for the info. I did not knew about show-index when I was starting
> > to work on this and later it just came out of sight. Please find
> > corrected patch below.
> >
> > 8<
On Fri, Jul 29, 2016 at 08:02:51AM -0700, Junio C Hamano wrote:
> > So it's possible that the resulting pack
> > is not as small as it could be (i.e., we break the chain with a base
> > object, but it's possible if we looked that we could have broken the
> > chain by making a delta against an
On Mon, Aug 08, 2016 at 05:05:07PM +0200, Johannes Schindelin wrote:
> I remember that you did a ton of work on t0027. Now I see problems, and
> not only that the entire script now takes a whopping 4 minutes 20 seconds
> to run on my high-end Windows machine.
>
> It appears that t0027 fails
On Mon, Aug 08, 2016 at 11:29:26AM -0400, Jeff King wrote:
> On Mon, Aug 08, 2016 at 05:05:07PM +0200, Johannes Schindelin wrote:
>
> > I remember that you did a ton of work on t0027. Now I see problems, and
> > not only that the entire script now takes a whopping 4 minutes 20 seconds
> > to run
Kirill Smelkov writes:
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index bc1c433..4ba0c4a 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -2244,6 +2244,9 @@ pack.useBitmaps::
> to stdout (e.g., during the server side
Goal
This is a patch series about libifying `git apply` functionality, and
using this libified functionality in `git am`, so that no 'git apply'
process is spawn anymore. This makes `git am` significantly faster, so
`git rebase`, when it uses the am backend, is also significantly
faster.
Junio C Hamano writes:
> If the input comes from the end user, we certainly would want to
> allow "word1 word2\tword3 " as input (i.e. squishing repeated
Any intelligent reader may have guessed already, but before I
stupidly told Emacs to refill the paragraph, the above
Stefan Beller writes:
> On Thu, Sep 10, 2015 at 9:28 AM, Jacob Keller wrote:
>> Hey,
>>
>> does anyone know of any tricks for storing a cover letter for a patch
>> series inside of git somehow? I'd guess the only obvious way currently
>> is to store
Kirill Smelkov writes:
> 8<
> From: Kirill Smelkov
> Subject: [PATCH v3] pack-objects: Teach --use-bitmap-index codepath to respect
> --local, --honor-pack-keep and --incremental
(Not a question to Kirill)
Hmph. I suspect that handling of in-body
On Mon, Aug 08, 2016 at 12:06:13PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> >> + if grep -qFf nonlocal-loose 1.objects; then
> >> + echo "Non-local object present in pack generated with --local"
> >> + return 1
> >> + fi
> >> +'
> >
> > grep -f
On 08/09/2016 12:36 AM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> Is it *really* so insane to consider moving collaboration on the Git
>> project to GitHub or some other similar platform?
>
> I only know how "pull requests" and "issues" discussion in GitHub
>
Reproduction:
$ echo "*.ignoreme" >> .gitignore
# (and commit)
$ touch "fooo-€.ignoreme"
$ find . -print | grep fooo | xargs git check-ignore
"./fooo-\342\202\254.ignoreme"
You could view that git-check-ignore isn't corrupting anything, it is
just outputting another form for the file
Tests consisting of one line each can be consolidated to have fewer tests
to run as well as fewer lines of code.
When having just a few git commands, do not create a new shell but
use the -C flag in Git to execute in the correct directory.
Signed-off-by: Stefan Beller
---
Allow users to pass in multiple references, just as clone accepts multiple
references as well.
Signed-off-by: Stefan Beller
---
builtin/submodule--helper.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/builtin/submodule--helper.c
No functional change intended. This commit only changes formatting
to the style we recently use, e.g. starting the body of a test with a
single quote on the same line as the header, and then having the test
indented in the following lines.
Whenever we change directories, we do that in subshells.
v3:
Thanks to Junios critial questions regarding the design, I took a step back
to look at the bigger picture.
--super-reference sounds confusing. (what is the super referring to?)
So drop that approach.
Instead we'll compute where the reference might be in the superproject scope
and ask the
In a later patch we need to pass optional references
through to git clone, so add the capability for it.
Signed-off-by: Stefan Beller
---
builtin/submodule--helper.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git
In a later patch we want to try to create alternates for
all submodules, but they might not exist in the referenced
superproject. So add a way to skip the non existing references
and report them.
Signed-off-by: Stefan Beller
---
Documentation/git-clone.txt | 5 -
On Tue, Aug 9, 2016 at 12:20 AM, Michael Haggerty wrote:
> On 08/04/2016 05:58 PM, Johannes Schindelin wrote:
>> [...]
>> Even requiring every contributor to register with GitHub would be too much
>> of a limitation, I would wager.
>> [...]
>
> Is it *really* so insane to
In the next patch we introduce optional references; To better distinguish
between optional and required references we rename the variable.
Signed-off-by: Stefan Beller
---
builtin/clone.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
When we have a another clone of a superproject, we may want to
mirror the submodules using alternates. Introduce an option
`--super-reference` that let's a user point to another superproject,
which is assumed to have the same structure as the one they are
running the "submodule update" command
When giving a --reference while also giving --recurse, the alternates
for the submodules are assumed to be in the superproject as well.
In case they are not, we error out when cloning the submodule.
However we error out completely, we did not record the alternates yet,
so a following update
Signed-off-by: Stefan Beller
---
Documentation/git-clone.txt| 4
builtin/submodule--helper.c| 47 ++
t/t7408-submodule-reference.sh | 29 +-
3 files changed, 79 insertions(+), 1 deletion(-)
diff
Allow the user to pass in multiple references to update_clone.
Currently this is only internal API, but once the shell script is
replaced by a C version, this is needed.
This fixes an API bug between the shell script and the helper.
Currently the helper accepts "--reference" "--reference=foo"
as
1 - 100 of 116 matches
Mail list logo