[PATCH v3 0/3] fixes for split index mode

o test. If this makes the life harder for anyone reviewing this let me know and I can base it on the same commit previous iterations were based on. Thomas Gummerer (3): read-cache: fix reading the shared index for other repos split-index: don't write cache tree with null sha1 entri

[PATCH v3 3/3] travis: run tests with GIT_TEST_SPLIT_INDEX

pobox.com> Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- ci/run-tests.sh | 4 1 file changed, 4 insertions(+) diff --git a/ci/run-tests.sh b/ci/run-tests.sh index f0c743de94..c7aee5b9ff 100755 --- a/ci/run-tests.sh +++ b/ci/run-tests.sh @@ -8,3 +8,7 @@ mkdir -p $HOME/travis-

[PATCH v3 2/3] split-index: don't write cache tree with null oid entries

Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- cache.h| 3 ++- read-cache.c | 2 +- split-index.c | 2 ++ t/t1700-split-index.sh | 19 +++ 4 files changed, 24 insertions(+), 2 deletions(-) diff --git a/cache.h b/cache.h

[PATCH] oidset: don't return value from oidset_init

As the return type is void, and even the return type of the expression we're trying to return (oidmap_init) is void just remove the return statement to fix the compiler error. Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- oidset.h | 2 +- 1 file changed, 1 insertion(+),

Re: [PATCH v3 1/3] read-cache: fix reading the shared index for other repos

On 01/08, Duy Nguyen wrote: > On Mon, Jan 8, 2018 at 5:30 AM, Thomas Gummerer <t.gumme...@gmail.com> wrote: > > @@ -1896,16 +1895,17 @@ int read_index_from(struct index_state *istate, > > const char *path) > > split_index->base = xcallo

Re: [PATCH v3 0/3] fixes for split index mode

. On 01/07, Thomas Gummerer wrote: > Thanks Brandon and Lars for comments on the previous round. > > Previous rounds were at <20171210212202.28231-1-t.gumme...@gmail.com> > and <20171217225122.28941-1-t.gumme...@gmail.com>. > > Changes since the previous roun

Re: [PATCH] Removed unnecessary void* from hashmap.h that caused compile warnings

Thanks for your patch! A few nitpicks below: > Subject: [PATCH] Removed unnecessary void* from hashmap.h that caused compile > warnings >From Documentation/SubmittingPatches: Describe your changes in imperative mood, e.g. "make xyzzy do frotz" instead of "[This patch] makes xyzzy do

Re: [PATCH] Removed unnecessary void* from hashmap.h that caused compile warnings

On 01/15, Randall S. Becker wrote: > On January 15, 2018 3:43 PM, Thomas Gummerer wrote: > > Thanks for your patch! A few nitpicks below: > > > > > Subject: [PATCH] Removed unnecessary void* from hashmap.h that caused > > > compile warnings > > &

Re: [PATCH v3 4/3] read-cache: don't try to write index if we can't write shared index

On 01/14, Duy Nguyen wrote: > On Sun, Jan 14, 2018 at 5:37 AM, Thomas Gummerer <t.gumme...@gmail.com> wrote: > > In a0a967568e ("update-index --split-index: do not split if $GIT_DIR is > > read only", 2014-06-13), we tried to make sure we can still write an > >

Re: [PATCH v3 0/3] fixes for split index mode

On 01/19, Junio C Hamano wrote: > Thomas Gummerer <t.gumme...@gmail.com> writes: > > > Friendly ping on this series now that 2.16 is out :) Is there anything > > in this series (up to 3/3, 4/3 can be dropped now that Duy fixed it in > > a nicer way) that still needs

[PATCH] worktree: teach "add" to check out existing branches

compatibility worries here. We will still 'die()' if the branch is checked out in another worktree, unless the --force flag is passed. Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- This is a follow-up to https://public-inbox.org/git/20171118181345.GC32324@hank/, where this was first sug

Re: [PATCH] worktree: teach "add" to check out existing branches

On 01/22, Duy Nguyen wrote: > On Sun, Jan 21, 2018 at 7:02 PM, Thomas Gummerer <t.gumme...@gmail.com> wrote: > > [...] > > + > > If `` is omitted and neither `-b` nor `-B` nor `--detach` used, > > -then, as a convenience, a new branch based at HEAD is created

Re: [PATCH v3 1/3] read-cache: fix reading the shared index for other repos

On 01/08, Thomas Gummerer wrote: > On 01/08, Duy Nguyen wrote: > > On Mon, Jan 8, 2018 at 5:30 AM, Thomas Gummerer <t.gumme...@gmail.com> > > wrote: > > > @@ -1896,16 +1895,17 @@ int read_index_from(struct index_state *istate, > > > const char *path)

[PATCH v3 4/3] read-cache: don't try to write index if we can't write shared index

have users fix their repositories instead of trying (but failing) to paper over the error. Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- read-cache.c | 11 --- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/read-cache.c b/read-cache.c index d13ce83794..a

Re: [PATCH v3 1/3] read-cache: fix reading the shared index for other repos

On 01/21, Junio C Hamano wrote: > Thomas Gummerer <t.gumme...@gmail.com> writes: > > > On 01/19, Junio C Hamano wrote: > >> Thomas Gummerer <t.gumme...@gmail.com> writes: > >> > >> > read_cache_from() defaults to using the gitdir of the_r

Re: [PATCH] trace: measure where the time is spent in the index-heavy operations

On 01/27, Nguyễn Thái Ngọc Duy wrote: > All the known heavy code blocks are measured (except object database > access). This should help identify if an optimization is effective or > not. An unoptimized git-status would give something like below (92% of > time is accounted). > > Signed-off-by:

[RFC/PATCH] reset --hard: make use of the pretty machinery

ce function such as 'pp_commit_easy' that would do this already. Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- Sending this as RFC/PATCH, as I'm not 100% sure this change in behaviour is acceptable, and that I'm not missing some other edge case, but I noticed this while trying to fi

[PATCH v2 3/3] worktree: teach "add" to check out existing branches

compatibility worries here. We will still 'die()' if the branch is checked out in another worktree, unless the --force flag is passed. Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- Documentation/git-worktree.txt | 9 +++-- builtin/worktree.c

[PATCH v2 1/3] worktree: improve message when creating a new worktree

: Preparing foo (identifier foo) even though the HEAD is set to a commit, which is just not checked out. Fix these inconsistencies by making the 'git reset --hard' call quiet, and printing the message ourselves instead. Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- We might want

[PATCH v2 2/3] worktree: be clearer when "add" dwim-ery kicks in

re it's nice to tell the user which kind of dwim-ery kicked in. Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> --- builtin/worktree.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/builtin/worktree.c b/builtin/worktree.c index d1549e441d..74a853c2a3 100644 --- a/builti

[PATCH v2 0/3] worktree: teach "add" to check out existing branches

de any new magic to guess the branchname, as was suggested, as that would be a bigger change in the behaviour of git worktree, and is not a particular itch I have right now, so I'd prefer to keep it separate. Thomas Gummerer (3): worktree: improve message when creating a new worktree worktree: be c

Re: [PATCH v2 1/3] worktree: improve message when creating a new worktree

On 02/05, Duy Nguyen wrote: > On Sun, Feb 04, 2018 at 10:13:03PM +0000, Thomas Gummerer wrote: > > diff --git a/builtin/worktree.c b/builtin/worktree.c > > index 7cef5b120b..d1549e441d 100644 > > --- a/builtin/worktree.c > > +++ b/builtin/worktree.c > > @@ -303,7

Re: [PATCH v2 3/3] worktree: teach "add" to check out existing branches

On 02/06, Duy Nguyen wrote: > On Tue, Feb 6, 2018 at 3:23 AM, Thomas Gummerer <t.gumme...@gmail.com> wrote: > > On 02/05, Duy Nguyen wrote: > >> On Sun, Feb 04, 2018 at 10:13:05PM +, Thomas Gummerer wrote: > >> > - if (opts->new_branch) > &

Re: [PATCH v2 1/3] worktree: improve message when creating a new worktree

On 02/07, Eric Sunshine wrote: > On Sun, Feb 4, 2018 at 9:12 PM, Duy Nguyen wrote: > > As a former translator, I'm not thrilled to see a sentence broken into > > two pieces like this. I'm not a Japanese translator, but I think this > > sentence is translated differently when

Re: [PATCH v2 3/3] worktree: teach "add" to check out existing branches

On 02/05, Duy Nguyen wrote: > On Sun, Feb 04, 2018 at 10:13:05PM +0000, Thomas Gummerer wrote: > > - if (opts->new_branch) > > + if (opts->checkout_existing_branch) > > + fprintf(stderr, _(", checking out existing branch '%s'"), > > +

Re: [PATCH v2 2/3] prune: fix pruning with multiple worktrees and split index

[sorry for the late reply. I was on Christmas holidays until today and am still catching up on the mailing list. It will probably take me untill the weekend to send a re-roll] On 12/18, Brandon Williams wrote: > On 12/17, Thomas Gummerer wrote: > > be489d02d2 ("revision.c: --index

Re: [PATCH v4 01/21] linear-assignment: a function to solve least-cost assignment problems

On 07/21, Johannes Schindelin via GitGitGadget wrote: > From: Johannes Schindelin > > The problem solved by the code introduced in this commit goes like this: > given two sets of items, and a cost matrix which says how much it > "costs" to assign any given item of the first set to any given item

Re: [PATCH v3 00/11] rerere: handle nested conflicts

On 07/30, Junio C Hamano wrote: > Thomas Gummerer writes: > > > Thomas Gummerer (11): > > rerere: unify error messages when read_cache fails > > rerere: lowercase error messages > > rerere: wrap paths in output in sq > > rerere: mark strin

Re: [PATCH v3 10/11] rerere: teach rerere to handle nested conflicts

On 07/30, Junio C Hamano wrote: > Thomas Gummerer writes: > > > Currently rerere can't handle nested conflicts and will error out when > > it encounters such conflicts. Do that by recursively calling the > > 'handle_conflict' function to normalize the conflict.

Re: [PATCH v3 05/11] rerere: add documentation for conflict normalization

On 07/30, Junio C Hamano wrote: > Thomas Gummerer writes: > > > +Different conflict styles and branch names are normalized by stripping > > +the labels from the conflict markers, and removing extraneous > > +information from the `diff3` conflict style. Branches that are

Re: [PATCH v3 07/11] rerere: only return whether a path has conflicts or not

On 07/30, Junio C Hamano wrote: > Thomas Gummerer writes: > > > We currently return the exact number of conflict hunks a certain path > > has from the 'handle_paths' function. However all of its callers only > > care whether there are conflicts or not or if there is a

Re: [PATCH v4 03/21] range-diff: first rudimentary implementation

On 07/30, Johannes Schindelin wrote: > Hi Thomas, > > On Sun, 29 Jul 2018, Thomas Gummerer wrote: > > > On 07/21, Johannes Schindelin via GitGitGadget wrote: > > > > > > [...] > > > > > > +static void find_exact_match

Re: [PATCH v3 06/11] rerere: fix crash when conflict goes unresolved

On 07/30, Junio C Hamano wrote: > Thomas Gummerer writes: > > > Currently when a user doesn't resolve a conflict in a file, but > > commits the file with the conflict markers, and later the file ends up > > in a state in which rerere can't handle it, subseque

Re: [PATCH v4 03/21] range-diff: first rudimentary implementation

On 07/21, Johannes Schindelin via GitGitGadget wrote: > From: Johannes Schindelin > > At this stage, `git range-diff` can determine corresponding commits > of two related commit ranges. This makes use of the recently introduced > implementation of the linear assignment algorithm. > > The core

Re: [PATCH v4 05/21] range-diff: also show the diff between patches

On 07/21, Johannes Schindelin via GitGitGadget wrote: > From: Johannes Schindelin > > Just like tbdiff, we now show the diff between matching patches. This is > a "diff of two diffs", so it can be a bit daunting to read for the > beginner. > > An alternative would be to display an interdiff,

Re: [PATCH v4 10/21] range-diff: do not show "function names" in hunk headers

On 07/21, Johannes Schindelin via GitGitGadget wrote: > From: Johannes Schindelin > > We are comparing complete, formatted commit messages with patches. There > are no function names here, so stop looking for them. While there are no function names here, trying out range-diff without this patch

Re: [PATCH v4 09/21] range-diff: adjust the output of the commit pairs

On 07/21, Johannes Schindelin via GitGitGadget wrote: > From: Johannes Schindelin > > This change brings `git range-diff` yet another step closer to > feature parity with tbdiff: it now shows the oneline, too, and indicates > with `=` when the commits have identical diffs. > > Signed-off-by:

Re: [PATCH v4 05/21] range-diff: also show the diff between patches

On 07/30, Johannes Schindelin wrote: > Hi Thomas & Eric, > > On Sun, 29 Jul 2018, Thomas Gummerer wrote: > > > On 07/29, Eric Sunshine wrote: > > > On Sun, Jul 29, 2018 at 3:04 PM Thomas Gummerer > > > wrote: > > > > On 07/21, Johannes Sc

Re: [PATCH v4 17/21] range-diff: populate the man page

On 07/21, Johannes Schindelin via GitGitGadget wrote: > From: Johannes Schindelin > > The bulk of this patch consists of a heavily butchered version of > tbdiff's README written by Thomas Rast and Thomas Gummerer, lifted from Thanks for the mention here, but this was really mostly T

Re: [PATCH v4 09/21] range-diff: adjust the output of the commit pairs

On 07/21, Johannes Schindelin via GitGitGadget wrote: > From: Johannes Schindelin > > This change brings `git range-diff` yet another step closer to > feature parity with tbdiff: it now shows the oneline, too, and indicates > with `=` when the commits have identical diffs. > > Signed-off-by:

Re: [PATCH v4 00/21] Add `range-diff`, a `tbdiff` lookalike

while (j < b->nr && b_util->matching < 0) { > -- output_pair_header(, NULL, b_util); > -+ output_pair_header(diffopt, , NULL, b_util); > +- output_pair_header(, , NULL, b_util); > ++

Re: [PATCH v4 20/21] range-diff: make --dual-color the default mode

On 07/21, Johannes Schindelin via GitGitGadget wrote: > From: Johannes Schindelin > > After using this command extensively for the last two months, this > developer came to the conclusion that even if the dual color mode still > leaves a lot of room for confusion about what was actually changed,

Re: [PATCH v4 05/21] range-diff: also show the diff between patches

On 07/29, Eric Sunshine wrote: > On Sun, Jul 29, 2018 at 3:04 PM Thomas Gummerer wrote: > > On 07/21, Johannes Schindelin via GitGitGadget wrote: > > > Just like tbdiff, we now show the diff between matching patches. This is > > > a "diff of two diffs"

Re: git worktree add verbosity

On 08/05, Karen Arutyunov wrote: > Hello, > > We are using git for automation in our build2 project. > > What's quite inconvenient is that the 'git worktree add' command prints some > output by default and there is no way to suppress it, as it normally can be > achieved with the --quiet option

Re: git worktree add prints to stdout

On 08/05, Karen Arutyunov wrote: > Hello, > > The 'git worktree add' command prints to both standard streams. So in the > following example the first line is printed to stderr and the second to > stdout. git 2.18.0 should print both of those lines to stdout. This was done to match where 'git

[PATCH v4 06/11] rerere: fix crash with files rerere can't handle

ote that other variants that have the same conflict ID will not be touched. Signed-off-by: Thomas Gummerer --- rerere.c | 12 +++- t/t4200-rerere.sh | 21 + 2 files changed, 28 insertions(+), 5 deletions(-) diff --git a/rerere.c b/rerere.c index da1ab54

[PATCH v4 05/11] rerere: add documentation for conflict normalization

Add some documentation for the logic behind the conflict normalization in rerere. Helped-by: Junio C Hamano Signed-off-by: Thomas Gummerer --- Documentation/technical/rerere.txt | 140 + rerere.c | 4 - 2 files changed, 140 insertions

[PATCH v4 04/11] rerere: mark strings for translation

'git rerere' is considered a porcelain command and as such its output should be translated. Its functionality is also only enabled through a config setting, so scripts really shouldn't rely on the output either way. Signed-off-by: Thomas Gummerer --- builtin/rerere.c | 4 +-- rerere.c

[PATCH v4 01/11] rerere: unify error messages when read_cache fails

se that here as well. Signed-off-by: Thomas Gummerer --- rerere.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/rerere.c b/rerere.c index e0862e2778..473d32a5cd 100644 --- a/rerere.c +++ b/rerere.c @@ -568,7 +568,7 @@ static int find_conflict(struct string_list *confli

[PATCH v4 00/11] rerere: handle nested conflicts

nsidered using git "wrong". I also realized that while I wrote "no functional changes intended" in 7/11, and functional changes were in fact not intended, there still is a slight functional change. As I think that's a good change, I documented it in the commit message. Thoma

[PATCH v4 07/11] rerere: only return whether a path has conflicts or not

. This will simplify the code in the subsequent steps. Signed-off-by: Thomas Gummerer --- rerere.c | 23 --- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/rerere.c b/rerere.c index 895ad80c0c..bf803043e2 100644 --- a/rerere.c +++ b/rerere.c @@ -393,12 +393,13 @@ static

[PATCH v4 03/11] rerere: wrap paths in output in sq

for translators, when the strings are marked for translation in a subsequent commit. Signed-off-by: Thomas Gummerer --- builtin/rerere.c | 2 +- rerere.c | 26 +- 2 files changed, 14 insertions(+), 14 deletions(-) diff --git a/builtin/rerere.c b/builtin/rerere.c

[PATCH v4 02/11] rerere: lowercase error messages

Documentation/CodingGuidelines mentions that error messages should be lowercase. Prior to marking them for translation follow that pattern in rerere as well, so translators won't have to translate messages that don't conform to our guidelines. Signed-off-by: Thomas Gummerer --- rerere.c | 24

[PATCH v4 10/11] rerere: teach rerere to handle nested conflicts

;<< 2 === 3 >>>>>>> >>>>>>> and the conflict ID would be calculated as sha1(1<<<<<<< 2 === 3 >>>>>>>) Stripping out vs. leaving the conflict markers in place i

[PATCH v4 08/11] rerere: factor out handle_conflict function

conflict marker is found as invalid, we now only consider files invalid when the "ours" conflict marker ("<<<<<<< ") is unmatched, not when other conflict markers (e.g. "===") is unmatched.

[PATCH v4 09/11] rerere: return strbuf from handle path

line function. Signed-off-by: Thomas Gummerer --- rerere.c | 58 ++-- 1 file changed, 18 insertions(+), 40 deletions(-) diff --git a/rerere.c b/rerere.c index 2d62251943..a35b88916c 100644 --- a/rerere.c +++ b/rerere.c @@ -302,38 +302,6

[PATCH v4 11/11] rerere: recalculate conflict ID when unresolved conflict is committed

normalize the conflict before this patch series. Signed-off-by: Thomas Gummerer --- rerere.c | 7 +++ t/t4200-rerere.sh | 7 +++ 2 files changed, 10 insertions(+), 4 deletions(-) diff --git a/rerere.c b/rerere.c index f78bef80b1..dd81d09e19 100644 --- a/rerere.c +++ b/rerere.c

exit code in git diff-index [was: Re: concurrent access to multiple local git repos is error prone]

On 08/05, Alexander Mills wrote: > Also, as an aside, this seems to be a bug, but probably a known bug: > > $ git diff-index HEAD; echo $? > > :100755 100755 60e5d683c1eb3e61381b1a8ec2db822b94b9faec > M cli/npp_check_merge.sh > :100644 100644

Re: [PATCH v6 11/21] range-diff: add tests

On 08/13, Thomas Rast via GitGitGadget wrote: > From: Thomas Rast > > These are essentially lifted from https://github.com/trast/tbdiff, with > light touch-ups to account for the command now being named `git > range-diff`. > > Apart from renaming `tbdiff` to `range-diff`, only one test case

Re: [PATCH v6 00/21] Add range-diff, a tbdiff lookalike

On 08/13, Johannes Schindelin wrote: > Hi, > > On Mon, 13 Aug 2018, Johannes Schindelin via GitGitGadget wrote: > > > The incredibly useful git-tbdiff [https://github.com/trast/tbdiff] tool to > > compare patch series (say, to see what changed between two iterations sent > > to the Git mailing

Re: [PATCH v5 05/21] range-diff: also show the diff between patches

On 08/13, Johannes Schindelin wrote: > Hi Thomas, > > On Sun, 12 Aug 2018, Thomas Gummerer wrote: > > > On 08/10, Johannes Schindelin via GitGitGadget wrote: > > > From: Johannes Schindelin > > > > [...] > > > > I don't think this handles

Re: [GSoC][PATCH v7 13/26] stash: update `git stash show` documentation

On 08/08, Paul-Sebastian Ungureanu wrote: > Add in documentation about the change of behavior regarding > the `--quiet` option, which was introduced in the last commit. > (the `--quiet` option does not exit anymore with erorr if it s/erorr/error/ > is given an empty stash as argument) If we

Re: [GSoC][PATCH v7 14/26] stash: convert store to builtin

On 08/08, Paul-Sebastian Ungureanu wrote: > Add stash store to the helper and delete the store_stash function > from the shell script. > > Add the usage string which was forgotten in the shell script. I think similarly to 'git stash create', which also doesn't appear in the usage, this was

Re: [GSoC][PATCH v7 00/26] Convert "git stash" to C builtin

On 08/08, Paul-Sebastian Ungureanu wrote: > Hello, > > Here is the whole `git stash` C version. Some of the previous > patches were already reviewed (up to and including "stash: convert > store to builtin"), but there are some which were not > (starting with "stash: convert create to builtin").

Re: [GSoC][PATCH v7 10/26] stash: convert show to builtin

On 08/08, Paul-Sebastian Ungureanu wrote: > Add stash show to the helper and delete the show_stash, have_stash, > assert_stash_like, is_stash_like and parse_flags_and_rev functions > from the shell script now that they are no longer needed. > > Before this commit, `git stash show` would ignore

Re: [GSoC][PATCH v7 11/26] stash: change `git stash show` usage text and documentation

> Subject: stash: change `git stash show` usage text and documentation Another nitpick about commit messages. "change ... usage text and documentation" doesn't say much about what the actual change is. How about something like "stash: mention options in "show" synopsis" instead? The change

Re: [GSoC][PATCH v7 15/26] stash: convert create to builtin

On 08/08, Paul-Sebastian Ungureanu wrote: > Add stash create to the helper. > > Signed-off-by: Paul-Sebastian Ungureanu > --- > builtin/stash--helper.c | 406 > git-stash.sh| 2 +- > 2 files changed, 407 insertions(+), 1 deletion(-) > >

Re: [GSoC][PATCH v7 12/26] stash: refactor `show_stash()` to use the diff API

On 08/08, Paul-Sebastian Ungureanu wrote: > Currently, `show_stash()` uses `cmd_diff()` to generate > the output. After this commit, the output will be generated > using the internal API. > > Before this commit, `git stash show --quiet` would act like > `git diff` and error out if the stash is

Re: [PATCH v2] worktree: add --quiet option

On 08/15, Elia Pinto wrote: > Add the '--quiet' option to git worktree, > as for the other git commands. 'add' is the > only command affected by it since all other > commands, except 'list', are currently > silent by default. > > Helped-by: Martin Ågren > Helped-by: Duy Nguyen > Helped-by: Eric

Re: [GSoC][PATCH v7 04/26] stash: renamed test cases to be more descriptive

> Subject: Re: [GSoC][PATCH v7 04/26] stash: renamed test cases to be more > descriptive Please use the imperative mood in the title and the commit messages themselves. From Documentation/SubmittingPatches: Describe your changes in imperative mood, e.g. "make xyzzy do frotz" instead of

Re: [GSoC][PATCH v7 09/26] stash: implement the "list" command in the builtin

> Subject: stash: implement the "list" command in the builtin Nit: The previous commit messages all have the format "stash: convert to builtin", maybe follow the same pattern here? The rest of the patch looks good to me. On 08/08, Paul-Sebastian Ungureanu wrote: > Add stash list to the helper

Re: [PATCH v5 05/21] range-diff: also show the diff between patches

Hi Dscho, On 08/10, Johannes Schindelin via GitGitGadget wrote: > From: Johannes Schindelin > > [..] > > @@ -13,15 +14,38 @@ NULL > int cmd_range_diff(int argc, const char **argv, const char *prefix) > { > int creation_factor = 60; > + struct diff_options diffopt = { NULL }; >

Re: [GSoC][PATCH v7 16/26] stash: replace spawning a "read-tree" process

On 08/08, Paul-Sebastian Ungureanu wrote: > Instead of spawning a child process, make use of `reset_tree()` > function already implemented in `stash-helper.c`. > --- > builtin/stash--helper.c | 9 +++-- > 1 file changed, 3 insertions(+), 6 deletions(-) > > diff --git

Re: [GSoC][PATCH v7 26/26] stash: replace all "git apply" child processes with API calls

On 08/08, Paul-Sebastian Ungureanu wrote: > `apply_all_patches()` does not provide a method to apply patches > from strbuf. Because of this, this commit introduces a new > function `apply_patch_from_buf()` which applies a patch from buf. > It works by saving the strbuf as a file. This way we can

Re: [GSoC][PATCH v7 21/26] stash: replace spawning `git ls-files` child process

On 08/08, Paul-Sebastian Ungureanu wrote: > This commit replaces spawning `git ls-files` child process with > API calls to get the untracked files. > --- > builtin/stash--helper.c | 49 +++-- > 1 file changed, 32 insertions(+), 17 deletions(-) > > diff --git

Re: [GSoC][PATCH v7 15/26] stash: convert create to builtin

On 08/18, Paul Sebastian Ungureanu wrote: > On Thu, Aug 16, 2018 at 1:13 AM, Thomas Gummerer wrote: > > On 08/08, Paul-Sebastian Ungureanu wrote: > >> > >> [...] > >> > >> + r

Re: [GSoC][PATCH v7 24/26] stash: optimize `get_untracked_files()` and `check_changes()`

On 08/08, Paul-Sebastian Ungureanu wrote: > This commits introduces a optimization by avoiding calling the > same functions again. For example, `git stash push -u` > would call at some points the following functions: > > * `check_changes()` > * `do_create_stash()`, which calls:

Re: [GSoC][PATCH v7 25/26] stash: replace all `write-tree` child processes with API calls

On 08/08, Paul-Sebastian Ungureanu wrote: > This commit replaces spawning `git write-tree` with API calls. > --- > builtin/stash.c | 40 > 1 file changed, 12 insertions(+), 28 deletions(-) Nice reduction in lines here! > > diff --git a/builtin/stash.c

Re: [GSoC][PATCH v7 17/26] stash: avoid spawning a "diff-index" process

On 08/08, Paul-Sebastian Ungureanu wrote: > This commits replaces spawning `diff-index` child process by using > the already existing `diff` API I think this should be squashed into the previous commit. It's easier to review a commit that replaces all the 'run_command'/'pipe_command' calls in

Re: [PATCH v4 10/11] rerere: teach rerere to handle nested conflicts

On 08/22, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > > > But why not add this to the git-rerere manpage? These technical docs > > get way less exposure, and in this case we're not describing some > > interna implementation detail, which the technical docs are for, but > >

Re: [PATCH v4 10/11] rerere: teach rerere to handle nested conflicts

On 08/22, Junio C Hamano wrote: > Thomas Gummerer writes: > > > Hmm, it does describe what happens in the code, which is what this > > patch implements. Maybe we should rephrase the title here? > > > > Or are you suggesting dropping this patch (and the next one) &g

[PATCH 1/2] rerere: remove documentation for "nested conflicts"

tion might be misleading to users, in case we change the heuristic in the future. Remove this documentation to avoid being potentially misleading in the documentation. Suggested-by: Junio C Hamano Signed-off-by: Thomas Gummerer --- The original series already made it into 'next', so these patches

[PATCH 2/2] rerere: add not about files with existing conflict markers

When a file contains lines that look like conflict markers, 'git rerere' may fail not be able to record a conflict resolution. Emphasize that in the man page. Helped-by: Junio C Hamano Signed-off-by: Thomas Gummerer --- Not sure if there may be a better place in the man page

[PATCH v2 2/2] rerere: add note about files with existing conflict markers

When a file contains lines that look like conflict markers, 'git rerere' may fail not be able to record a conflict resolution. Emphasize that in the man page, and mention a possible workaround for the issue. Suggested-by: Junio C Hamano Signed-off-by: Thomas Gummerer --- Compared to v1

[PATCH v2 1/2] rerere: mention caveat about unmatched conflict markers

unmatched conflict markers. Make that clearer in the documentation. Suggested-by: Junio C Hamano Signed-off-by: Thomas Gummerer --- > That's fine. I'd rather keep it but perhaps add a reminder to tell > readers that it works only when the merging of contents that already > records w

Re: [PATCH v4 10/11] rerere: teach rerere to handle nested conflicts

On 08/27, Junio C Hamano wrote: > Thomas Gummerer writes: > > > Agreed. I think it may be solvable if we'd actually get the > > information about what belongs to which side from the merge algorithm > > directly. > > The merge machinery may (eh, rather, "does

Re: [GSoC][PATCH v7 18/26] stash: convert push to builtin

On 08/08, Paul-Sebastian Ungureanu wrote: > Add stash push to the helper. > --- This (and the previous two and I think most subsequent patches) are missing your sign-off. > builtin/stash--helper.c | 209 > git-stash.sh| 6 +- > 2 files

Re: [GSoC][PATCH v7 19/26] stash: make push to be quiet

> Subject: stash: make push to be quiet Nit: maybe "stash: make push -q quiet"? I think the subject should at least mention the -q option. On 08/08, Paul-Sebastian Ungureanu wrote: > There is a change in behaviour with this commit. When there was > no initial commit, the shell version of stash

Re: [GSoC][PATCH v7 20/26] stash: add tests for `git stash push -q`

On 08/08, Paul-Sebastian Ungureanu wrote: > This commit introduces more tests for the quiet option of > `git stash push`. I think this commit should be squashed into the previous one, so we have implementation and tests in one commit. That way it's easier to see during review that there are

Re: [GSoC][PATCH v7 22/26] stash: convert save to builtin

On 08/08, Paul-Sebastian Ungureanu wrote: > Add stash save to the helper and delete functions which are no > longer needed (`show_help()`, `save_stash()`, `push_stash()`, > `create_stash()`, `clear_stash()`, `untracked_files()` and > `no_changes()`). > --- > builtin/stash--helper.c | 48 +++

Re: [GSoC][PATCH v7 23/26] stash: convert `stash--helper.c` into `stash.c`

On 08/08, Paul-Sebastian Ungureanu wrote: > The old shell script `git-stash.sh` was removed and replaced > entirely by `builtin/stash.c`. In order to do that, `create` and > `push` were adapted to work without `stash.sh`. For example, before > this commit, `git stash create` called `git

[PATCH v3 01/11] rerere: unify error messages when read_cache fails

se that here as well. Signed-off-by: Thomas Gummerer --- rerere.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/rerere.c b/rerere.c index e0862e2778..473d32a5cd 100644 --- a/rerere.c +++ b/rerere.c @@ -568,7 +568,7 @@ static int find_conflict(struct string_list *confli

[PATCH v3 06/11] rerere: fix crash when conflict goes unresolved

is the 'preimage', which by itself will be regenerated by git if necessary, so the user won't loose any work. Note that other variants that have the same conflict ID will not be touched. Signed-off-by: Thomas Gummerer --- rerere.c | 12 +++- t/t4200-rerere.sh | 22

[PATCH v3 08/11] rerere: factor out handle_conflict function

Factor out the handle_conflict function, which handles a single conflict in a path. This is in preparation for a subsequent commit, where this function will be re-used. No functional changes intended. Signed-off-by: Thomas Gummerer --- rerere.c | 87

[PATCH v3 05/11] rerere: add documentation for conflict normalization

Add some documentation for the logic behind the conflict normalization in rerere. Helped-by: Junio C Hamano Signed-off-by: Thomas Gummerer --- Documentation/technical/rerere.txt | 140 + rerere.c | 4 - 2 files changed, 140 insertions

[PATCH v3 00/11] rerere: handle nested conflicts

Signed-off-by: Thomas Gummerer @@ -87,3 +88,12 @@ /* Nuke the recorded resolution for the conflict */ id = new_rerere_id(sha1); +@@ + handle_cache(path, sha1, rerere_path(id, "thisimage")); + if (read_mmfile(, rere

[PATCH v3 10/11] rerere: teach rerere to handle nested conflicts

t;<<<<< 2 === 3 >>>>>>>) Stripping out vs. leaving the conflict markers in place in the inner conflict should have no practical impact, but it simplifies the implementation. Signed-off-by: Thomas Gummerer --- Documentation/technical/rerere.txt | 42

[PATCH v3 09/11] rerere: return strbuf from handle path

line function. Signed-off-by: Thomas Gummerer --- rerere.c | 58 ++-- 1 file changed, 18 insertions(+), 40 deletions(-) diff --git a/rerere.c b/rerere.c index 2d62251943..a35b88916c 100644 --- a/rerere.c +++ b/rerere.c @@ -302,38 +302,6

[PATCH v3 11/11] rerere: recalculate conflict ID when unresolved conflict is committed

normalize the conflict before this patch series. Signed-off-by: Thomas Gummerer --- rerere.c | 7 +++ t/t4200-rerere.sh | 7 +++ 2 files changed, 10 insertions(+), 4 deletions(-) diff --git a/rerere.c b/rerere.c index f78bef80b1..dd81d09e19 100644 --- a/rerere.c +++ b/rerere.c

[PATCH v3 02/11] rerere: lowercase error messages

Documentation/CodingGuidelines mentions that error messages should be lowercase. Prior to marking them for translation follow that pattern in rerere as well, so translators won't have to translate messages that don't conform to our guidelines. Signed-off-by: Thomas Gummerer --- rerere.c | 24

<    2   3   4   5   6   7   8   9   >