On 11/30, Junio C Hamano wrote:
>
> I am unsure about the wisdom of calling it "--index", though.
>
> The "--index" option is "the command can work only on the index, or
> only on the working tree files, or on both the index and the working
> tree files, and this option tells it to work in the
On 11/27, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 25 Nov 2018, Thomas Gummerer wrote:
>
> > On 11/23, Paul-Sebastian Ungureanu wrote:
> > > Implement `strbuf_insertf()` and `strbuf_vinsertf()` to
> > > insert data using a printf format string.
>
On 11/20, Duy Nguyen wrote:
> On Mon, Nov 19, 2018 at 04:19:53PM +0100, Duy Nguyen wrote:
> > I promise to come back with something better (at least it still
> > sounds better in my mind). If that idea does not work out, we can
> > come back and see if we can improve this.
>
> So this is it. The
On 11/25, Torsten Bögershausen wrote:
> After running the "Git 2.20-rc1" testsuite here on a raspi,
> the only TC that failed was t5570.
> When the "grep" was run on daemon.log, the file was empty (?).
> When inspecting it later, it was filled, and grep would have found
> the "extended.attribute"
iff and
the new patch of this last round, and this addresses all the comments
I had on v10 (and some more :)). I consider it
Reviewed-by: Thomas Gummerer
> - improved memory management. Now, the callers of `do_create_stash()`
> are responsible of freeing the parameter they pass in. Moreover
On 11/23, Paul-Sebastian Ungureanu wrote:
> Implement `strbuf_insertf()` and `strbuf_vinsertf()` to
> insert data using a printf format string.
>
> Original-idea-by: Johannes Schindelin
> Signed-off-by: Paul-Sebastian Ungureanu
> ---
> strbuf.c | 36
>
UTING.md
> Thanks
>
> -Original Message-
> From: Thomas Gummerer
> Sent: 03 November 2018 15:35
> To: Quinn, David
> Cc: git@vger.kernel.org
> Subject: Re: Failed stash caused untracked changes to be lost
>
> Exercise Caution: This email is from an external sourc
On 10/23, Quinn, David wrote:
>
> Issue: While running a git stash command including the '-u' flag to include
> untracked files, the command failed due to arguments in the incorrect order.
> After this untracked files the were present had been removed and permanently
> lost.
Thanks for your
On 10/22, René Scharfe wrote:
> Am 22.10.2018 um 23:10 schrieb Thomas Gummerer:
> > compare_commit_by_gen is used to sort a list of pointers to 'struct
> > commit'. The comparison function for qsort is called with pointers to
> > the objects it needs to compare, so when sort
function casts it's arguments to 'struct
commit *' and uses those, leading to out of bounds memory access and
potentially to wrong results. Fix that.
Signed-off-by: Thomas Gummerer
---
I noticed this by running the test suite through valgrind. I'm not
familiar with this code, so I'm not sure
On 10/16, Johannes Schindelin wrote:
> Hi Thomas,
>
> On Mon, 15 Oct 2018, Thomas Gummerer wrote:
>
> > 2: 63f2e0e6f9 ! 2: 2d45985676 strbuf.c: add `strbuf_join_argv()`
> > @@ -14,19 +14,17 @@
> > strbuf_setlen(sb, sb->len + sb2->len);
&g
On 10/15, Paul-Sebastian Ungureanu wrote:
> Hello,
>
> This is a new iteration of `git stash`, based on the last review.
> This iteration fixes some code styling issues, bring some changes
> to `do_push_stash()` and `do_create_stash()` to be closer to API by
> following Thomas Gummerer's review
On 10/15, Paul-Sebastian Ungureanu wrote:
> The `-m` option is no longer supported as it might not make
> sense to have two ways of passing a message. Even if this is
> a change in behaviour, the documentation remains the same
> because the `-m` parameter was omitted before.
[...]
> +
On 10/15, 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
On 10/15, Johannes Schindelin wrote:
> Hi Paul,
>
> On Mon, 15 Oct 2018, Paul-Sebastian Ungureanu wrote:
>
> > +static void assert_stash_like(struct stash_info *info, const char
> > *revision)
> > +{
> > + if (get_oidf(>b_commit, "%s^1", revision) ||
> > + get_oidf(>w_tree, "%s:",
On 10/12, Farhan Khan wrote:
> Hi all,
>
> Does git load the entire index file into memory when it wants to
> edit/view it? I ask because I wonder if this can become a problem with
> the index file becomes arbitrarily large, like for the Linux kernel.
Yes, currently git always loads the entire
On 10/12, Jonathan Nieder wrote:
> Jeff King wrote:
> > On Fri, Oct 12, 2018 at 07:40:37PM +0100, Thomas Gummerer wrote:
>
> >> 801fa63a90 ("config.mak.dev: add -Wformat-security", 2018-09-08) added
> >> the -Wformat-security to the flags set in c
set.
Fix that, and make -Wformat-security actually useful by adding the
-Wformat flag as well. git compiles cleanly with both these flags
applied.
Signed-off-by: Thomas Gummerer
---
Sorry for not catching this before the patch made it to next.
config.mak.dev | 1 +
1 file changed, 1 insertio
On 10/10, Junio C Hamano wrote:
> * ps/stash-in-c (2018-08-31) 20 commits
> - stash: replace all `write-tree` child processes with API calls
> - stash: optimize `get_untracked_files()` and `check_changes()`
> - stash: convert `stash--helper.c` into `stash.c`
> - stash: convert save to builtin
On 09/26, 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
On 09/26, Paul-Sebastian Ungureanu wrote:
> Add stash push to the helper.
>
> Signed-off-by: Paul-Sebastian Ungureanu
> ---
> builtin/stash--helper.c | 244 +++-
> git-stash.sh| 6 +-
> 2 files changed, 244 insertions(+), 6 deletions(-)
>
>
On 09/26, Paul-Sebastian Ungureanu wrote:
> Add stash create to the helper.
>
> Signed-off-by: Paul-Sebastian Ungureanu
> ---
> builtin/stash--helper.c | 450
> git-stash.sh| 2 +-
> 2 files changed, 451 insertions(+), 1 deletion(-)
>
>
> Subject: stash: mention options in `show` synopsis.
Really minor point, but the '.' in the end should be dropped.
Also as this is fixing a pre-existing problem I would have put this
patch near the beginning of the series, rather than in between
conversions of functions, and just incorporated
On 09/26, Paul-Sebastian Ungureanu wrote:
> From: Joel Teichroeb
>
> Add stash branch to the helper and delete the apply_to_branch
> function from the shell script.
>
> Checkout does not currently provide a function for checking out
> a branch as cmd_checkout does a large amount of sanity
On 09/26, Paul-Sebastian Ungureanu wrote:
> From: Joel Teichroeb
>
> Add a builtin helper for performing stash commands. Converting
> all at once proved hard to review, so starting with just apply
> lets conversion get started without the other commands being
> finished.
>
> The helper is being
> Subject: stash: update test cases conform to coding guidelines
s/stash/t3903/
s/conform/to &/
Alternatively the subject could also be "t3903: modernize style",
which would be a bit shorter, and still convey the same information to
a reader of 'git log --oneline'.
On 09/26, Paul-Sebastian
On 09/26, Paul-Sebastian Ungureanu wrote:
> Implement `strbuf_join_argv()` to join arguments
> into a strbuf.
>
> Signed-off-by: Paul-Sebastian Ungureanu
> ---
> strbuf.c | 15 +++
> strbuf.h | 7 +++
> 2 files changed, 22 insertions(+)
>
> diff --git a/strbuf.c b/strbuf.c
>
On 09/27, Ruud van Asseldonk wrote:
> Hi,
>
> I just ran into a segmentation fault during a rebase with rerere
> enabled. Inspecting the core dump with gdb shows:
Thanks for reporting this bug
> (gdb) bt
> #0 0x55d673375ce0 in do_rerere_one_path (update=0x7fff03c37f30,
>
On 09/26, Derrick Stolee wrote:
> This is a bit tricky to do, but I will investigate. For some things, the
> values can conflict with each other (GIT_TEST_SPLIT_INDEX doesn't play
> nicely with other index options, I think).
Just commenting on this point. I think all the index options should
be
rl versions > 7.61.1 and
earlier curl versions.
Reported-by: Todd Zullinger
Helped-by: Jonathan Nieder
Signed-off-by: Thomas Gummerer
---
t/t5551-http-fetch-smart.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t5551-http-fetch-smart.sh b/t/t5551-http-fetch-sm
Thanks Jonathan and Junio for the comments on the first round.
Changes since the first round:
- add a preparatory patch to modernize the test script
- add Reported-by to credit Todd
- just use 'sort' instead of 'cat | sort'
Thomas Gummerer (2):
t5551: move setup code inside test_expect blocks
Move setup code inside test_expect blocks, to catch unexpected
failures in the setup steps, and bring the test scripts in line with
our modern test style.
Suggested-by: Jonathan Nieder
Signed-off-by: Thomas Gummerer
---
t/t5551-http-fetch-smart.sh | 66 ++---
1
On 09/17, Junio C Hamano wrote:
> Thomas Gummerer writes:
>
> > In t5551 we check that we save cookies correctly to a file when
> > http.cookiefile and http.savecookies are set. To do so we create an
> > expect file that expects the cookies in a certain order.
> &g
rl versions > 7.61.1 and
earlier curl versions.
Signed-off-by: Thomas Gummerer
---
t/t5551-http-fetch-smart.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t5551-http-fetch-smart.sh b/t/t5551-http-fetch-smart.sh
index 771f36f9ff..d13b993201 100755
--- a/t/t5551-ht
ear assignment
problems. Computing, 38(4), 325–340.
Reported-by: ryenus
Helped-by: Derrick Stolee
Signed-off-by: Thomas Gummerer
---
linear-assignment.c | 6 ++
t/t3206-range-diff.sh | 5 +
2 files changed, 11 insertions(+)
diff --git a/linear-assignment.c b/linear-assi
On 09/12, Johannes Schindelin wrote:
> Hi Thomas,
>
> [quickly, as I will go back to a proper vacation after this]
Sorry about interrupting your vacation, enjoy wherever you are! :)
> On Wed, 12 Sep 2018, Thomas Gummerer wrote:
>
> > diff --git a/linear-assignment.c
On 09/13, Ben Peart wrote:
>
>
> On 9/12/2018 6:31 PM, Thomas Gummerer wrote:
> > On 09/12, Ben Peart wrote:
> > > Teach get_index_format_default() to support running the test suite
> > > with specific index versions. In particular, this enables the test
On 09/12, Junio C Hamano wrote:
> Thomas Gummerer writes:
> > --- >8 ---
> >
> > Subject: [PATCH] linear-assignment: fix potential out of bounds memory
> > access
> >
> > Currently the 'compute_assignment()' function can may read memory out
>
On 09/12, Ben Peart wrote:
> Teach get_index_format_default() to support running the test suite
> with specific index versions. In particular, this enables the test suite
> to be run using index version 4 which is not the default so gets less testing.
I found this commit message slightly
On 09/11, Thomas Gummerer wrote:
> On 09/11, Thomas Gummerer wrote:
> > I think you're on the right track here. I can not test this on Mac
> > OS, but on Linux, the following fails when running the test under
> > valgrind:
> >
> > diff --git a/t/t3206-rang
On 09/11, Thomas Gummerer wrote:
> I think you're on the right track here. I can not test this on Mac
> OS, but on Linux, the following fails when running the test under
> valgrind:
>
> diff --git a/t/t3206-range-diff.sh b/t/t3206-range-diff.sh
> index 2237c7f4af.
On 09/11, Derrick Stolee wrote:
> On 9/11/2018 12:04 PM, Derrick Stolee wrote:
> > On 9/11/2018 11:38 AM, Derrick Stolee wrote:
> > The patch below includes a test that fails on Mac OSX with a segfault.
> >
> > GitGitGadget PR: https://github.com/gitgitgadget/git/pull/36
> > Failed Build:
> >
Hi,
thanks for your bug report!
On 09/11, ryenus wrote:
> I just updated to 2.19 via Homebrew, git range-diff seems cool, but I
> only got a Segmentation fault: 11
>
> $ git version; git range-diff origin/master HEAD@{2} HEAD
Unfortunately the HEAD@{2} syntax needs your reflog, which is
On 08/29, Junio C Hamano wrote:
> Thomas Gummerer writes:
>
> > Yeah that makes sense. Maybe something like this?
> >
> > (replying to here to keep
> > the patches in one thread)
> >
> > Documentation/technical/rerere.txt | 4
> > 1
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
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
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
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
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
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
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
> >
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
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
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:
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
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
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
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
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
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 +++
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
> 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
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
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
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").
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(-)
>
>
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
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
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
> 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
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
> 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
> 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
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
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
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
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 };
>
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
;<<
2
===
3
>>>>>>>
>>>>>>>
and the conflict ID would be calculated as
sha1(1<<<<<<<
2
===
3
>>>>>>>)
Stripping out vs. leaving the conflict markers in place i
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.
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
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
. 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
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
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
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
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
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
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
'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
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
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
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
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
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
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
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
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
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.
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);
> ++
1 - 100 of 848 matches
Mail list logo
