[PATCH 10/15] update submodules: add submodule_go_from_to

ret = -1; + goto out; + } + + if (!dry_run) { + if (new) { + struct child_process cp1 = CHILD_PROCESS_INIT; + /* also set the HEAD accordingly */ + cp1.git_cmd = 1; + cp1.no_stdin = 1;

[PATCH 06/15] update submodules: add submodule config parsing

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

[PATCH 09/15] update submodules: move up prepare_submodule_repo_env

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

[PATCH 07/15] update submodules: add a config option to determine if submodules are updated

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 <sbel...@google.com> --- submodule.c | 6 ++ submodule

Re: [PATCH 07/14] update submodules: introduce is_interesting_submodule

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. >> >> So let's introduce a function that pre checks if a submodule needs >> to be checked for an

Re: [PATCH 05/14] update submodules: add submodule config parsing

> + } > +} Proliferation of similarly looking config parser made me briefly wonder if they can somehow be shared, but I think it is correct to view that update/fetch/push have conceptually different set of allowed modes, whose names happen to overlap, so keeping them separate like this patch does (and its predecessors did to take us into the shape of the current code) makes sense, at least to me.

Re: [PATCH 07/14] update submodules: introduce is_interesting_submodule

On 02/14, Stefan Beller wrote: > 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

Re: [PATCH 09/14] update submodules: add submodule_go_from_to

On Tue, Feb 14, 2017 at 04:34:18PM -0800, Stefan Beller wrote: > + prepare_submodule_repo_env_no_git_dir(_array); > + > + cp.git_cmd = 1; > + cp.no_stdin = 1; > + cp.dir = path; > + > + argv_array_pushf(, "--super-prefix=%s/", path); > + argv_array_pushl(, "read-tree",

[PATCH 13/14] entry.c: update submodules when interesting

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

[PATCH 08/14] update submodules: move up prepare_submodule_repo_env

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

[PATCH 07/14] update submodules: introduce is_interesting_submodule

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

[PATCH 09/14] update submodules: add submodule_go_from_to

ret = -1; + goto out; + } + + if (!dry_run) { + if (new) { + struct child_process cp1 = CHILD_PROCESS_INIT; + /* also set the HEAD accordingly */ + cp1.git_cmd = 1; + cp1.no_stdin = 1;

[PATCH 06/14] update submodules: add a config option to determine if submodules are updated

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 <sbel...@google.com> --- submodule.c | 6 ++ submodule

[PATCH 05/14] update submodules: add submodule config parsing

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

[PATCH 1/3] handle_revision_opt(): do not update argv[left++] with an unknown arg

In future steps, we will make it possible for a rev or a revision range (i.e. what is understood by handle_revision_arg() helper) to begin with a dash. The setup_revisions() function however currently considers anything that begins with a dash to be: - an option it itself understands and

Re: [PATCH v2] rev-list-options.txt: update --all about HEAD

On Wed, Feb 08, 2017 at 01:06:41PM +0700, Nguyễn Thái Ngọc Duy wrote: > This is the document patch for f0298cf1c6 (revision walker: include a > detached HEAD in --all - 2009-01-16). > > Even though that commit is about detached HEAD, as Jeff pointed out, > always adding HEAD in that case may

[PATCH v2] rev-list-options.txt: update --all about HEAD

This is the document patch for f0298cf1c6 (revision walker: include a detached HEAD in --all - 2009-01-16). Even though that commit is about detached HEAD, as Jeff pointed out, always adding HEAD in that case may have subtle differences with --source or --exclude. So the document mentions nothing

Re: [PATCH] rev-list-options.txt: update --all about detached HEAD

On Tue, Feb 07, 2017 at 08:38:49PM +0700, Nguyễn Thái Ngọc Duy wrote: > This is the document patch for f0298cf1c6 (revision walker: include a > detached HEAD in --all - 2009-01-16) > [...] > --all:: > - Pretend as if all the refs in `refs/` are listed on the > - command line as ''. > +

[PATCH] rev-list-options.txt: update --all about detached HEAD

This is the document patch for f0298cf1c6 (revision walker: include a detached HEAD in --all - 2009-01-16) Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/rev-list-options.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

Re: [PATCH 00/11] nd/worktree-move update

On Sat, Feb 4, 2017 at 1:25 AM, Junio C Hamano wrote: > Even if you think "the right way" is to add to the iterators, I > suspect that we can still do incremental fixes? I agree with the > order of importance Michael listed in his message (i.e. the index > and the HEAD first,

Re: [PATCH 00/11] nd/worktree-move update

Junio C Hamano writes: > I do not recall seeing that. I however deliberately ignored another > statement because I thought it enough to answer, which was: Oops. "because I didn't think I thought it enough to answer" was what I meant.

Re: [PATCH 00/11] nd/worktree-move update

Duy Nguyen writes: > On Fri, Feb 3, 2017 at 3:21 AM, Junio C Hamano wrote: >> Johannes Schindelin writes: >> >>> Also, the more important reply was Peff's reply that suggested that the >>> proposed fix was incomplete, as it

Re: [PATCH 00/11] nd/worktree-move update

On Fri, Feb 3, 2017 at 3:21 AM, Junio C Hamano wrote: > Johannes Schindelin writes: > >> Also, the more important reply was Peff's reply that suggested that the >> proposed fix was incomplete, as it misses --unpack-unreachable: >>

Re: [PATCH 00/11] nd/worktree-move update

Johannes Schindelin writes: > Also, the more important reply was Peff's reply that suggested that the > proposed fix was incomplete, as it misses --unpack-unreachable: > https://public-inbox.org/git/20160601160143.ga9...@sigill.intra.peff.net/ While I think that

Re: [PATCH 00/11] nd/worktree-move update

Hi Duy, On Thu, 2 Feb 2017, Johannes Schindelin wrote: > Hi Duy, > > On Thu, 2 Feb 2017, Duy Nguyen wrote: > > > On Thu, Feb 2, 2017 at 5:37 PM, Johannes Schindelin > > wrote: > > > > > > On Thu, 2 Feb 2017, Duy Nguyen wrote: > > > > > >> You meant this one [1]?

Re: [PATCH 00/11] nd/worktree-move update

Hi Duy, On Thu, 2 Feb 2017, Duy Nguyen wrote: > On Thu, Feb 2, 2017 at 5:37 PM, Johannes Schindelin > wrote: > > > > On Thu, 2 Feb 2017, Duy Nguyen wrote: > > > >> On Thu, Feb 2, 2017 at 4:43 PM, Johannes Schindelin > >> wrote: > >> > >

Re: [PATCH 00/11] nd/worktree-move update

On Thu, Feb 2, 2017 at 5:37 PM, Johannes Schindelin wrote: > Hi Duy, > > On Thu, 2 Feb 2017, Duy Nguyen wrote: > >> On Thu, Feb 2, 2017 at 4:43 PM, Johannes Schindelin >> wrote: >> > >> > On Thu, 2 Feb 2017, Duy Nguyen wrote: >> > >> >> On

Re: [PATCH 00/11] nd/worktree-move update

Hi Duy, On Thu, 2 Feb 2017, Duy Nguyen wrote: > On Thu, Feb 2, 2017 at 4:43 PM, Johannes Schindelin > wrote: > > > > On Thu, 2 Feb 2017, Duy Nguyen wrote: > > > >> On Thu, Feb 2, 2017 at 4:16 PM, Johannes Schindelin > >> wrote: > >> > >

Re: [PATCH 00/11] nd/worktree-move update

On Thu, Feb 2, 2017 at 4:43 PM, Johannes Schindelin wrote: > Hi Duy, > > On Thu, 2 Feb 2017, Duy Nguyen wrote: > >> On Thu, Feb 2, 2017 at 4:16 PM, Johannes Schindelin >> wrote: >> > Hi Duy, >> > >> > On Thu, 2 Feb 2017, Nguyễn Thái Ngọc

Re: [PATCH 00/11] nd/worktree-move update

Hi Duy, On Thu, 2 Feb 2017, Duy Nguyen wrote: > On Thu, Feb 2, 2017 at 4:16 PM, Johannes Schindelin > wrote: > > Hi Duy, > > > > On Thu, 2 Feb 2017, Nguyễn Thái Ngọc Duy wrote: > > > >> This squashes two changes from Johannes and Ramsay: [...] > > > > Sorry, I lost

Re: [PATCH 00/11] nd/worktree-move update

On Thu, Feb 2, 2017 at 4:16 PM, Johannes Schindelin wrote: > Hi Duy, > > On Thu, 2 Feb 2017, Nguyễn Thái Ngọc Duy wrote: > >> This squashes two changes from Johannes and Ramsay: [...] > > Sorry, I lost track of the worktree discussions... Could you remind me > which

Re: [PATCH 00/11] nd/worktree-move update

Hi Duy, On Thu, 2 Feb 2017, Nguyễn Thái Ngọc Duy wrote: > This squashes two changes from Johannes and Ramsay: [...] Sorry, I lost track of the worktree discussions... Could you remind me which patch is supposed to fix my continuous reflog corruption? Thanks, Dscho

[PATCH 00/11] nd/worktree-move update

This squashes two changes from Johannes and Ramsay: diff --git a/builtin/worktree.c b/builtin/worktree.c index 339c622e20..a1c91f1542 100644 --- a/builtin/worktree.c +++ b/builtin/worktree.c @@ -528,7 +528,7 @@ static int unlock_worktree(int ac, const char **av, const char *prefix) static

[PATCH] .mailmap: update Gábor Szeder's email address

Signed-off-by: SZEDER Gábor --- .mailmap | 1 + 1 file changed, 1 insertion(+) diff --git a/.mailmap b/.mailmap index 9c87a3840..ab59b2fac 100644 --- a/.mailmap +++ b/.mailmap @@ -225,6 +225,7 @@ Steven Walter Steven Walter

[PATCH v3 03/27] attr.c: update a stale comment on "struct match_attr"

From: Junio C Hamano <gits...@pobox.com> When 82dce998 (attr: more matching optimizations from .gitignore, 2012-10-15) changed a pointer to a string "*pattern" into an embedded "struct pattern" in struct match_attr, it forgot to update the comment that describes

[PATCH v3 3/3] update-ref: add test cases for bare repository

From: Cornelius Weig <cornelius.w...@tngtech.com> The default behavior of update-ref to create reflogs differs in repositories with worktree and bare ones. The existing tests cover only the behavior of repositories with worktree. This commit adds tests that assert the correct behavior i

Re: [PATCH v2 3/3] update-ref: add test cases for bare repository

cornelius.w...@tngtech.com writes: > From: Cornelius Weig <cornelius.w...@tngtech.com> > > The default behavior of update-ref to create reflogs differs in > repositories with worktree and bare ones. The existing tests cover only > the behavior of repositories with worktree.

[PATCH v2 3/3] update-ref: add test cases for bare repository

From: Cornelius Weig <cornelius.w...@tngtech.com> The default behavior of update-ref to create reflogs differs in repositories with worktree and bare ones. The existing tests cover only the behavior of repositories with worktree. This commit adds tests that assert the correct behavior i

[PATCHv3] submodule update: run custom update script for initial populating as well

that was added later (6cb5728c43, submodule update: allow custom command to update submodule working tree, 2013-07-03). I am unsure about the "none" command, as I can see an initial checkout there as a useful thing. On the other hand going strictly by our own documentation, we should do nothing in cas

Re: [PATCHv2] submodule update: run custom update script for initial populating as well

ds however do make sense, such as the custom command > that was added later (6cb5728c43, submodule update: allow custom > command to update submodule working tree, 2013-07-03). > > I am unsure about the "none" command, as I can see an initial > checkout there as a useful thing

[PATCHv2] submodule update: run custom update script for initial populating as well

that was added later (6cb5728c43, submodule update: allow custom command to update submodule working tree, 2013-07-03). I am unsure about the "none" command, as I can see an initial checkout there as a useful thing. On the other hand going strictly by our own documentation, we should do nothing in cas

[PATCH v2 03/27] attr.c: update a stale comment on "struct match_attr"

From: Junio C Hamano <gits...@pobox.com> When 82dce998 (attr: more matching optimizations from .gitignore, 2012-10-15) changed a pointer to a string "*pattern" into an embedded "struct pattern" in struct match_attr, it forgot to update the comment that describes

Re: [PATCH v3 08/21] Documentation/git-update-index: talk about core.splitIndex config var

r. > > That would be my preferred solution as I think it is the simplest in > the end for users. > Also, as Duy wrote above, one can always use something like "git -c > core.splitIndex= ...", which by the way can work for any command, not > just "update-i

Re: [PATCH v3 08/21] Documentation/git-update-index: talk about core.splitIndex config var

being forced >> to choose between the two unsatifactory designs? In any case, I >> mostly am and was pointing out the issues and not saying the other >> one is the most preferred solution in these threads. >> >> I think there should just be one authoritative source of t

Re: [PATCH] submodule update: run custom update script for initial populating as well

"rebase" || >> +test "$update_module" = "none" >> + then >> + update_module=checkout >> + fi > > case "$update_module" in >

Re: [PATCH] submodule update: run custom update script for initial populating as well

+test "$update_module" = "none" > + then > + update_module=checkout > + fi case "$update_module" in merge | rebase | none) update_module=checkout ;; esac Shorter and probably easier to update.

Re: [PATCH] submodule update: run custom update script for initial populating as well

;> a submodule initially, because merging or rebasing makes no sense >> in that situation. >> >> Other commands however do make sense, such as the custom command >> that was added later (6cb5728c43, submodule update: allow custom >> command to update submodule

Re: [PATCH] submodule update: run custom update script for initial populating as well

; Other commands however do make sense, such as the custom command > that was added later (6cb5728c43, submodule update: allow custom > command to update submodule working tree, 2013-07-03). Makes sense. > I am unsure about the "none" command, as I can see an initial > check

[PATCH] submodule update: run custom update script for initial populating as well

that was added later (6cb5728c43, submodule update: allow custom command to update submodule working tree, 2013-07-03). I am unsure about the "none" command, as I can see an initial checkout there as a useful thing. On the other hand going strictly by our own documentation, we should do nothing in cas

[PATCH 03/27] attr.c: update a stale comment on "struct match_attr"

From: Junio C Hamano <gits...@pobox.com> When 82dce998 (attr: more matching optimizations from .gitignore, 2012-10-15) changed a pointer to a string "*pattern" into an embedded "struct pattern" in struct match_attr, it forgot to update the comment that describes

[PATCH v5 03/14] t7610: update branch names to match test number

getool' ' - git checkout -b test1 branch1 && + git checkout -b test$test_count branch1 && git submodule update -N && test_must_fail git merge master >/dev/null 2>&1 && ( yes "" | git mergetool both >/dev/null 2>&

[PATCH v4 03/14] t7610: update branch names to match test number

getool' ' - git checkout -b test1 branch1 && + git checkout -b test$test_count branch1 && git submodule update -N && test_must_fail git merge master >/dev/null 2>&1 && ( yes "" | git mergetool both >/dev/null 2>&

[PATCHv2 5/5] unpack-trees: factor working tree update out of check_updates

struct index_state *index = >result; struct checkout state = CHECKOUT_INIT; @@ -270,15 +271,6 @@ static int check_updates(struct unpack_trees_options *o) state.refresh_cache = 1; state.istate = index; - progress = get_progress(o); - - if (

Re: [PATCH v3 08/21] Documentation/git-update-index: talk about core.splitIndex config var

the issues and not saying the other > one is the most preferred solution in these threads. > > I think there should just be one authoritative source of the truth, Either that, or we make sure all sources of truth are consistent. In this case, 'update --split-index' could update core

[PATCH v3 02/13] t7610: update branch names to match test number

getool' ' - git checkout -b test1 branch1 && + git checkout -b test$test_count branch1 && git submodule update -N && test_must_fail git merge master >/dev/null 2>&1 && ( yes "" | git mergetool both >/dev/null 2>&

Re: [PATCH v3 08/21] Documentation/git-update-index: talk about core.splitIndex config var

Christian Couder writes: > It feels strange that when I do things one way, you suggest another > way, and the next time in a similar situation when I do things the way > you suggested previously, then you suggest the way I did it initially > the first time... Perhaps

Re: [PATCH] submodule update --init: displays correct path from submodule

On Fri, Jan 6, 2017 at 4:55 PM, David Turner wrote: > (for the test) > Signed-off-by: David Turner > > TIL: super-prefix! yeah that was introduced recently for prefixes from "outside the repository" e.g. a superproject, its first user is grep

Re: [PATCH] submodule update --init: displays correct path from submodule

rgc, argv, prefix, , ) < 0) > return 1; > > @@ -1117,31 +1118,31 @@ static int absorb_git_dirs(int argc, const char > **argv, const char *prefix) > > struct cmd_struct { > const char *cmd; > int (*fn)(int, const char **, const char *); > u

[PATCH] submodule update --init: displays correct path from submodule

r *); unsigned option; }; static struct cmd_struct commands[] = { {"list", module_list, 0}, {"name", module_name, 0}, {"clone", module_clone, 0}, {"update-clone", update_clone, 0}, {"relative-path&

minor bug: git submodule update --init from a subdir shows wrong path

le-update.sh @@ -140,6 +140,23 @@ test_expect_success 'submodule update --init --recursive from subdirectory' ' test_i18ncmp expect2 actual2 ' +cat <expect2 +Submodule 'foo/sub' (/home/novalis/twosigma/git/t/trash directory.t7406-submodule-update/withsubs/../rebasing) registered for path 'foo

[PATCH 5/5] unpack-trees: factor working tree update out of check_updates

ec1233..b40c069b1b 100644 --- a/unpack-trees.c +++ b/unpack-trees.c @@ -275,67 +275,79 @@ static struct progress *get_progress(struct unpack_trees_options *o) struct index_state *index = >result; if (!o->update || !o->verbose_update) return NULL; for

[PATCH v2 1/4] t7610: update branch names to match test number

getool' ' - git checkout -b test1 branch1 && + git checkout -b test$test_count branch1 && git submodule update -N && test_must_fail git merge master >/dev/null 2>&1 && ( yes "" | git mergetool both >/dev/null 2>&

[PATCH 1/4] t7610: update branch names to match test number

getool' ' - git checkout -b test1 branch1 && + git checkout -b test$test_count branch1 && git submodule update -N && test_must_fail git merge master >/dev/null 2>&1 && ( yes "" | git mergetool both >/dev/null 2>&

Re: [PATCH v3 21/21] Documentation/git-update-index: explain splitIndex.*

+ already enabled and `--split-index` is given again, all >> + changes in $GIT_DIR/index are pushed back to the shared index >> + file. > > In the world after this series that introduced the percentage-based > auto consolidation, it smells strange, or even illogica

[PATCH v3 17/38] sequencer (rebase -i): update refs after a successful rebase

An interactive rebase operates on a detached HEAD (to keep the reflog of the original branch relatively clean), and updates the branch only at the end. Now that the sequencer learns to perform interactive rebases, it also needs to learn the trick to update the branch before removing the directory

Re: [PATCH v3 08/21] Documentation/git-update-index: talk about core.splitIndex config var

On Tue, Dec 27, 2016 at 8:07 PM, Junio C Hamano <gits...@pobox.com> wrote: > Christian Couder <christian.cou...@gmail.com> writes: > >> Signed-off-by: Christian Couder <chrisc...@tuxfamily.org> >> --- >> Documentation/git-update-index.txt | 6 ++ >

[PATCH 2/3] submodule update documentation: don't repeat ourselves

The documentation for the `git submodule update` command, repeats itself for each update option, "This is done when is given, or no option is given and `submodule..update` is set to . Avoid these repetitive clauses by stating the command line options take precedence over configured op

[PATCH 0/3] Update submodule documentation

describe a particular command but e.g. explains design. Thanks, Stefan Stefan Beller (3): submodule documentation: add options to the subcommand submodule update documentation: don't repeat ourselves submodules: add a background story Documentation/git-submodule.txt | 93

Re: [PATCH v3 21/21] Documentation/git-update-index: explain splitIndex.*

> + file. In the world after this series that introduced the percentage-based auto consolidation, it smells strange, or even illogical, that index is un-split after doing this: $ git update-index --split-index $ git update-index --split-index Before this series, it may have been a quic

Re: [PATCH v3 08/21] Documentation/git-update-index: talk about core.splitIndex config var

Christian Couder <christian.cou...@gmail.com> writes: > Signed-off-by: Christian Couder <chrisc...@tuxfamily.org> > --- > Documentation/git-update-index.txt | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/Documentation/git-update-index.txt > b/D

[PATCH v3 08/21] Documentation/git-update-index: talk about core.splitIndex config var

Signed-off-by: Christian Couder <chrisc...@tuxfamily.org> --- Documentation/git-update-index.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt index 7386c93162..e091b2a409 100644 --- a/Documentation/git-

[PATCH v3 05/21] update-index: warn in case of split-index incoherency

When users are using `git update-index --(no-)split-index`, they may expect the split-index feature to be used or not according to the option they just used, but this might not be the case if the new "core.splitIndex" config variable has been set. In this case let's warn about what w

[PATCH v3 21/21] Documentation/git-update-index: explain splitIndex.*

Signed-off-by: Christian Couder <chrisc...@tuxfamily.org> --- Documentation/config.txt | 6 +++--- Documentation/git-update-index.txt | 37 + 2 files changed, 32 insertions(+), 11 deletions(-) diff --git a/Documentation/config.txt b/Documen

Re: [PATCH v2 14/34] sequencer (rebase -i): update refs after a successful rebase

; > at the end. > > > > Now that the sequencer learns to perform interactive rebases, it also > > needs to learn the trick to update the branch before removing the > > directory containing the state of the interactive rebase. > > > > We introduce a new head_ref va

[PATCH v2 21/21] Documentation/git-update-index: explain splitIndex.*

Signed-off-by: Christian Couder <chrisc...@tuxfamily.org> --- Documentation/config.txt | 6 +++--- Documentation/git-update-index.txt | 37 + 2 files changed, 32 insertions(+), 11 deletions(-) diff --git a/Documentation/config.txt b/Documen

[PATCH v2 05/21] update-index: warn in case of split-index incoherency

When users are using `git update-index --(no-)split-index`, they may expect the split-index feature to be used or not according to the option they just used, but this might not be the case if the new "core.splitIndex" config variable has been set. In this case let's warn about what w

[PATCH v2 08/21] Documentation/git-update-index: talk about core.splitIndex config var

Signed-off-by: Christian Couder <chrisc...@tuxfamily.org> --- Documentation/git-update-index.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt index 7386c93162..e091b2a409 100644 --- a/Documentation/git-

Re: [PATCH v2 14/34] sequencer (rebase -i): update refs after a successful rebase

ases, it also > needs to learn the trick to update the branch before removing the > directory containing the state of the interactive rebase. > > We introduce a new head_ref variable in a wider scope than necessary at > the moment, to allow for a later patch that prints out

Re: [PATCH v2 4/6] update-unicode.sh: automatically download newer definition files

Beat Bolli <dev+...@drbeat.li> writes: > On 14.12.16 00:31, Beat Bolli wrote: > >> [PATCH v2 4/6] update-unicode.sh: automatically download newer definition >> files > > Dang! And again I'm not capable of putting an underline instead of the > dash... &

Re: [PATCH v2 4/6] update-unicode.sh: automatically download newer definition files

On 14.12.16 00:31, Beat Bolli wrote: > [PATCH v2 4/6] update-unicode.sh: automatically download newer definition > files Dang! And again I'm not capable of putting an underline instead of the dash... Junio, would you please reword the subject to Re: [PATCH v2 4/6] update_unic

Re: [PATCH v2 0/6] unicode_width.h: update the width tables to Unicode 9.0

Thanks. Very much appreciated.

[PATCH v2 1/6] update_unicode.sh: move it into contrib/update-unicode

ignore | 1 - contrib/update-unicode/.gitignore| 3 +++ contrib/update-unicode/README| 20 contrib/update-unicode/update_unicode.sh | 38 ++ update_unicode.sh| 40 5

[PATCH v2 4/6] update-unicode.sh: automatically download newer definition files

i <dev+...@drbeat.li> --- contrib/update-unicode/update_unicode.sh | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/contrib/update-unicode/update_unicode.sh b/contrib/update-unicode/update_unicode.sh index 9f1bf31..56871a1 100755 --- a/contrib/update-unicode/update_unic

[PATCH v2 0/6] unicode_width.h: update the width tables to Unicode 9.0

| 1 - contrib/update-unicode/.gitignore| 3 ++ contrib/update-unicode/README| 20 +++ contrib/update-unicode/update_unicode.sh | 33 ++ unicode_width.h | 131

[PATCH v2 6/6] unicode_width.h: update the width tables to Unicode 9.0

Rerunning update-unicode.sh that we fixed in the previous commits produces these new tables. Signed-off-by: Beat Bolli <dev+...@drbeat.li> --- unicode_width.h | 131 +--- 1 file changed, 107 insertions(+), 24 deletions(-) diff

[PATCH v2 14/34] sequencer (rebase -i): update refs after a successful rebase

An interactive rebase operates on a detached HEAD (to keep the reflog of the original branch relatively clean), and updates the branch only at the end. Now that the sequencer learns to perform interactive rebases, it also needs to learn the trick to update the branch before removing the directory

Re: [PATCH 1/3] update_unicode.sh: update the uniset repo if it exists

ng the mouse, or don't check the error message or return codes. > Having a pre-baked shell script, which does use "&&" is in that way > more attractive, > and the README can be as simple as run "update-unicode.sh" and that's it. That's OK as well. > "

Re: [PATCH 1/3] update_unicode.sh: update the uniset repo if it exists

Sure, and I'd rather see the update-unicode.sh script moved somewhere in contrib/ while at it. Those who are interested in keeping up with the unicode standard are tiny minority of the developer population, and most of us would treat the built width table as the source (after all, that is what

Re: [PATCH 1/3] update_unicode.sh: update the uniset repo if it exists

t;> this: >> >> -{ 0x0300, 0x036F }, >> >> +{ 768, 879 }, >> >> IOW, all hex values are printed as decimal values. >> Not a problem for the compiler, but for the human >> to check the unicode tables. >> >> So I think we should "pin

Re: [PATCH 1/3] update_unicode.sh: update the uniset repo if it exists

On 12.12.16 19:12, Torsten Bögershausen wrote: > >>> Minor question, especially to the next commit: >>> Should we make sure to checkout the exact version, which has been tested? >>> In this case cb97792880625e24a9f581412d03659091a0e54f >>> >>> And this is for both a fresh clone and the git pull

Re: [PATCH 1/3] update_unicode.sh: update the uniset repo if it exists

> IOW, all hex values are printed as decimal values. > Not a problem for the compiler, but for the human > to check the unicode tables. > > So I think we should "pin" the version of uniset. Sure, and I'd rather see the update-unicode.sh script moved somewhere in con

Re: [PATCH 1/3] update_unicode.sh: update the uniset repo if it exists

>> Minor question, especially to the next commit: >> Should we make sure to checkout the exact version, which has been tested? >> In this case cb97792880625e24a9f581412d03659091a0e54f >> >> And this is for both a fresh clone and the git pull >> needs to be replaced by >> git fetch && git

Re: [PATCH 1/3] update_unicode.sh: update the uniset repo if it exists

On 2016-12-12 06:53, Torsten Bögershausen wrote: On 2016-12-12 00:34, Beat Bolli wrote: We need to track the new commits in uniset, otherwise their and our code get out of sync. Signed-off-by: Beat Bolli --- Junio, these go on top of my bb/unicode-9.0 branch, please.

Re: [PATCH 1/3] update_unicode.sh: update the uniset repo if it exists

On 2016-12-12 00:34, Beat Bolli wrote: > We need to track the new commits in uniset, otherwise their and our code > get out of sync. > > Signed-off-by: Beat Bolli > --- > > Junio, these go on top of my bb/unicode-9.0 branch, please. > > Thanks! > > update_unicode.sh | 5

[PATCH 1/3] update_unicode.sh: update the uniset repo if it exists

We need to track the new commits in uniset, otherwise their and our code get out of sync. Signed-off-by: Beat Bolli --- Junio, these go on top of my bb/unicode-9.0 branch, please. Thanks! update_unicode.sh | 5 + 1 file changed, 5 insertions(+) diff --git

Re: [BUG] git crash for git remote update tip tip

On Sun, Dec 11, 2016 at 07:51:16AM -0500, Jeff King wrote: > On Sun, Dec 11, 2016 at 01:17:44PM +0100, Jiri Olsa wrote: > > > I accidentaly added 2 remotes and git remote update > > crashed, see the attached output. > > > > [jolsa@krava perf]$ git -

Re: [BUG] git crash for git remote update tip tip

On Sun, Dec 11, 2016 at 01:17:44PM +0100, Jiri Olsa wrote: > I accidentaly added 2 remotes and git remote update > crashed, see the attached output. > > [jolsa@krava perf]$ git --version > git version 2.7.4 This is fixed already by b7410f616 (builtin/fetch.c: don't free remote-&g

[BUG] git crash for git remote update tip tip

hi, I accidentaly added 2 remotes and git remote update crashed, see the attached output. [jolsa@krava perf]$ git --version git version 2.7.4 thanks, jirka [jolsa@krava perf]$ git remote update tip tip Fetching tip Fetching tip *** Error in `git': double free or corruption (fasttop

Re: [PATCH 1/3] wt-status: implement opportunisitc index update correctly

lling it when it does not hold the lock. > Perhaps the repeated use of this conditional is a sign that the > 0 <= fd check could be built into update_index_if_able()? That condition is "do we have the lock? Otherwise we are not even allowed to update it", so in that sense it

Re: [PATCH 1/3] wt-status: implement opportunisitc index update correctly

Hi Junio, On Thu, Dec 8, 2016 at 4:48 AM, Stefan Beller wrote: > On Wed, Dec 7, 2016 at 11:41 AM, Junio C Hamano wrote: >> The require_clean_work_tree() function calls hold_locked_index() >> with die_on_error=0 to signal that it is OK if it fails to obtain

<    5   6   7   8   9   10   11   12   13   14   >