On 9 August 2018 at 21:58, Jeff King wrote:
> If you are asking as a more general case: why do we not complain about
> .gitignore for files the index already knows about, then I think that is
> useful. It lets you override the .gitignore _once_ when adding the file
> initially, and then you don't
On Thu, Aug 09, 2018 at 01:49:52PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Are you sure that it's not well-defined? We open the path with O_APPEND,
> > which means every write() will be atomically positioned at the end of
> > file. So we would never lose or overwrite data.
> >
> >
Hellom
On 10.08.2018 00:00, Junio C Hamano wrote:
Paul-Sebastian Ungureanu writes:
Good to see that the right way to forward a patch from another
person is used, but is this a GSoC project?
Yes, it is. I forgot to add the [GSoC] tag in the last series of patches.
The reason I asked was be
There are lots of suggestions on optimizing this stuff, but since this
problem does not affect me to begin with, I'm reluctant to make more
changes and going to stay simple, stupid and slow. I could continue to
do small updates if needed. But for bigger changes, consider this
patch dropped by me.
Paths that only differ in case work fine in a case-sensitive
filesystems, but if those repos are cloned in a case-insensitive one,
you'll get problems. The first thing to notice is "git status" will
never be clean with no indication what exactly is "dirty".
This patch helps the situation a bit by
On Wed, Aug 8, 2018 at 10:53 PM Ben Peart wrote:
>
>
>
> On 8/1/2018 12:38 PM, Duy Nguyen wrote:
> > On Tue, Jul 31, 2018 at 01:31:31PM -0400, Ben Peart wrote:
> >>
> >>
> >> On 7/31/2018 12:50 PM, Ben Peart wrote:
> >>>
> >>>
> >>> On 7/31/2018 11:31 AM, Duy Nguyen wrote:
> >>
>
> > In t
Jeff King writes:
> Here it is as a patch on top of jt/fetch-negotiator-skipping, which lets
> us pursue any fix for interleaved trace output on Windows without the
> pressure of an impending flaky test.
>
> My gut says that looking into making O_APPEND work there is going to be
> the nicest solu
Jeff King writes:
> Here it is as a patch on top of jt/fetch-negotiator-skipping, which lets
> us pursue any fix for interleaved trace output on Windows without the
> pressure of an impending flaky test.
>
> My gut says that looking into making O_APPEND work there is going to be
> the nicest solu
On Thu, Aug 9, 2018 at 10:16 AM Ben Peart wrote:
> In fact, in the other [1] patch series, we're detecting the number of
> cache entries that are the same as the cache tree and using that to
> traverse_by_cache_tree(). At that point, couldn't we copy the
> corresponding cache tree entries over to
Nguyễn Thái Ngọc Duy writes:
> There are lots of suggestions on optimizing this stuff, but since this
> problem does not affect me to begin with, I'm reluctant to make more
> changes and going to stay simple, stupid and slow. I could continue to
> do small updates if needed. But for bigger chan
Am 09.08.2018 um 19:35 schrieb Johannes Schindelin via GitGitGadget:
I reported a couple of times that t5552 is not passing reliably. It has now
reached next, and will no doubt infect master soon.
Turns out that it is not a Windows-specific issue, even if it occurs a lot
more often on Windows th
On Wed, Aug 8, 2018 at 8:23 PM Elijah Newren wrote:
> > diff --git a/unpack-trees.c b/unpack-trees.c
> > index a32ddee159..ba3d2e947e 100644
> > --- a/unpack-trees.c
> > +++ b/unpack-trees.c
> > @@ -644,6 +644,102 @@ static inline int are_same_oid(struct name_entry
> > *name_j, struct name_entry
On Wed, Aug 8, 2018 at 8:46 PM Elijah Newren wrote:
> > @@ -701,6 +702,24 @@ static int traverse_by_cache_tree(int pos, int
> > nr_entries, int nr_names,
> > if (!o->merge)
> > BUG("We need cache-tree to do this optimization");
> >
> > + /*
> > +* Try to keep
Nguyễn Thái Ngọc Duy writes:
> +static void mark_duplicate_entries(const struct checkout *state,
> +struct cache_entry *ce, struct stat *st)
> +{
> + int i;
> + int *count = state->nr_duplicates;
> +
> + if (!count)
> + BUG("state->nr_dupli
Hi,
On Fri, 10 Aug 2018, Jeff King wrote:
> On Thu, Aug 09, 2018 at 01:49:52PM -0700, Junio C Hamano wrote:
>
> > Jeff King writes:
> >
> > > Are you sure that it's not well-defined? We open the path with O_APPEND,
> > > which means every write() will be atomically positioned at the end of
> >
On 8/10/2018 12:15 PM, Johannes Sixt wrote:
Am 09.08.2018 um 19:35 schrieb Johannes Schindelin via GitGitGadget:
I reported a couple of times that t5552 is not passing reliably. It
has now
reached next, and will no doubt infect master soon.
Turns out that it is not a Windows-specific issue,
Instead of skip_unnecessary_picks() printing its result to stdout, it
returns it into a struct object_id, as the rewrite of complete_action()
(to come in the next commit) will need it.
rebase--helper then is modified to fit this change.
Signed-off-by: Alban Gruin
---
No changes since v5.
built
This rewrites append_todo_help() from shell to C. It also incorporates
some parts of initiate_action() and complete_action() that also write
help texts to the todo file.
This also introduces the source file rebase-interactive.c. This file
will contain functions necessary for interactive rebase tha
This adds a new function, run_command_silent_on_success(), to
redirect the stdout and stderr of a command to a strbuf, and then to run
that command. This strbuf is printed only if the command fails. It is
functionnaly similar to output() from git-rebase.sh.
run_git_commit() is then refactored to u
This rewrites (the misnamed) setup_reflog_action() from shell to C. The
new version is called prepare_branch_to_be_rebased().
A new command is added to rebase--helper.c, “checkout-base”, as well as
a new flag, “verbose”, to avoid silencing the output of the checkout
operation called by checkout_ba
If the todo list generated by `--make-script` is empty,
complete_action() writes a noop, but if it has only commented-out
commands, it will abort with the message "Nothing to do", and does not
launch the editor. This adds a new test to ensure that
complete_action() behaves this way.
Signed-off-by
This refactors append_todo_help() to write its message to a buffer
instead of the todo-list. This is needed for the rewrite of
complete_action(), which will come after the next commit.
As rebase--helper still needs the file manipulation part of
append_todo_help(), it is extracted to a temporary f
As part of the rewrite of interactive rebase, the sequencer will need to
open the sequence editor to allow the user to edit the todo list.
Instead of duplicating the existing launch_editor() function, this
refactors it to a new function, launch_specified_editor(), which takes
the editor as a parame
This rewrites checkout_onto() from shell to C.
A new command (“checkout-onto”) is added to rebase--helper.c. The shell
version is then stripped.
Signed-off-by: Alban Gruin
---
No changes since v5.
builtin/rebase--helper.c | 7 ++-
git-rebase--interactive.sh | 25
This rewrites complete_action() from shell to C.
A new mode is added to rebase--helper (`--complete-action`), as well as
a new flag (`--autosquash`).
Finally, complete_action() is stripped from git-rebase--interactive.sh.
The original complete_action() would return the code 2 when the todo
list
This patch series rewrite the interactive rebase from shell to C.
It is based on ffc6fa0e39 ("Fourth batch for 2.19 cycle", 2018-07-24).
This apply cleanly to 1d89318c48 ("Fifth batch for 2.19 cycle"), and
does not break tests.
Changes since v5:
- [01/20] Make write_message() public.
- [04/20
This rewrites the edit-todo functionality from shell to C.
To achieve that, a new command mode, `edit-todo`, is added, and the
`write-edit-todo` flag is removed, as the shell script does not need to
write the edit todo help message to the todo list anymore.
The shell version is then stripped in f
This makes rebase_path_todo(), get_missing_commit_check_level(),
write_message() and the enum check_level accessible outside sequencer.c,
renames check_level to missing_commit_check_level, and prefixes its
value names by MISSING_COMMIT_ to avoid namespace pollution.
This function and this enum wil
This rewrites the part of init_revisions_and_shortrevisions() needed by
`--complete-action` (which initialize $shortrevisions) from shell to C.
When `upstream` is empty, it means that the user launched a `rebase
--root`, and `onto` contains the ID of an empty commit. As a range
between an empty c
This moves the rebase--helper modes still used by
git-rebase--preserve-merges.sh (`--shorten-ids`, `--expand-ids`,
`--check-todo-list`, `--rearrange-squash` and `--add-exec-commands`) to
rebase--interactive.c.
git-rebase--preserve-merges.sh is modified accordingly, and
rebase--helper.c is removed
This removes git-rebase--interactive.sh, as its functionnality has been
replaced by git-rebase--interactive2.
git-rebase--interactive2.c is then renamed to git-rebase--interactive.c.
Signed-off-by: Alban Gruin
---
No changes since v5.
.gitignore| 1 -
Makef
This rewrites init_basic_state() from shell to C. The call to
write_basic_state() in cmd_rebase__helper() is replaced by a call to the
new function.
The shell version is then stripped from git-rebase--interactive.sh.
Signed-off-by: Alban Gruin
---
No changes since v5.
builtin/rebase--helper.c
This rewrites the part of interactive rebase which initializes the
basic state, make the script and complete the action, as a buitin, named
git-rebase--interactive2 for now. Others modes (`--continue`,
`--edit-todo`, etc.) will be rewritten in the next commit.
git-rebase--interactive.sh is modifi
This rewrites the part of init_revisions_and_shortrevisions() needed by
`--make-script` from shell to C. The new version is called
get_revision_ranges(), and is a static function inside of
rebase--helper.c. As this does not initialize $shortrevision, the
original shell version is not yet stripped
This removes the modes `--skip-unnecessary-picks`, `--append-todo-help`,
and `--checkout-onto` from rebase--helper.c, the functions of
git-rebase--interactive.sh that were rendered useless by the rewrite of
complete_action(), and append_todo_help_to_file() from
rebase-interactive.c.
skip_unnecessa
This rewrites the submodes of interactive rebase (`--continue`,
`--skip`, `--edit-todo`, and `--show-current-patch`) in C.
git-rebase.sh is then modified to call directly git-rebase--interactive2
instead of git-rebase--interactive.sh.
Signed-off-by: Alban Gruin
---
No changes since v5.
builtin
This rewrites write_basic_state() from git-rebase.sh in C. This is the
first step in the conversion of init_basic_state(), hence the mode in
rebase--helper.c is called INIT_BASIC_STATE. init_basic_state() will be
converted in the next commit.
The part of read_strategy_opts() that parses the stat
On Wed, Aug 8, 2018 at 8:39 PM Junio C Hamano wrote:
> One more, and hopefully the final, note.
>
> ..
Much appreciated. I don't think I could figure all this out no matter
how long I stare at those commits and current code.
--
Duy
On 8/10/2018 12:51 PM, Jeff Hostetler wrote:
On 8/10/2018 12:15 PM, Johannes Sixt wrote:
Am 09.08.2018 um 19:35 schrieb Johannes Schindelin via GitGitGadget:
I reported a couple of times that t5552 is not passing reliably. It
has now
reached next, and will no doubt infect master soon.
Tu
Thanks Jonathan.
The confirmation that the super-project config does not apply to the
submodules is what I was really looking for. We'll go from here.
This is a bit complicated, because this config is all generated
dynamically by the GitLab CI Runner when it is setting up a build job.
(See the li
Am 10.08.2018 um 18:51 schrieb Jeff Hostetler:
On 8/10/2018 12:15 PM, Johannes Sixt wrote:
Am 09.08.2018 um 19:35 schrieb Johannes Schindelin via GitGitGadget:
I reported a couple of times that t5552 is not passing reliably. It
has now
reached next, and will no doubt infect master soon.
Tur
On Fri, Aug 10, 2018 at 06:43:07PM +0200, Johannes Schindelin wrote:
> > > Correct. But I am more worried about the "mixed/overwriting"
> > > breakage, if there is one; it means we may need to be prepared for
> > > systems that lack O_APPEND that works correctly. I initially just
> > > assumed t
Hi,
I've tried to skim through the archive, but I couldn't find anything
that describes what I'm seeing. Apologies if that's because I missed
something/used the wrong search terms, or this is an intentional
change in behaviour.
Using 2.18.0.547.g1d89318c48, git fetch behaves differently to 2.18.0
On Fri, Aug 10, 2018 at 07:04:08PM +0100, Paul Jolly wrote:
> I've tried to skim through the archive, but I couldn't find anything
> that describes what I'm seeing. Apologies if that's because I missed
> something/used the wrong search terms, or this is an intentional
> change in behaviour.
>
> U
> I think this is the bug from:
>
> https://public-inbox.org/git/20180729121900.ga16...@sigill.intra.peff.net/
>
> The fix is in e2842b39f4 (fetch-pack: unify ref in and out param,
> 2018-08-01), and is currently in the 'next' branch, and marked for
> merging to master in the next integration cyc
On Thu, Aug 09, 2018 at 08:17:36PM -0700, Philip White wrote:
> I’d like to report what I suspect is a bug in Git, tested in 2.18 and
> 2.14. (I’d be delighted to be corrected if it is my own
> misunderstanding.) I’m reporting it here based on guidance from
> https://git-scm.com/community.
>
> I
Hi Junio,
On Thu, 9 Aug 2018, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > From: Johannes Schindelin
> >
> > This function will be used to make write accesses in trace_write() a bit
> > safer.
> > ...
> > To set a precedent for a better approach, let's introdu
Johannes Sixt writes:
> As this buglet looks like a recurring theme, and a proper fix is
> preferable over repeated work-arounds. To me it looks like we need
> some sort of locking on Windows. Unless your friends at Microsoft have
> an ace in their sleeves that lets us have atomic O_APPEND the PO
Jeff King writes:
> I have tried to help with the actual problem, by identifying the root
> cause (that the trace code's strategy is not fundamentally broken, but
> that it relies on O_APPEND whose guarantees are obviously not portable
> to Windows) and exploring possible solutions there (FILE_AP
On Fri, Aug 10, 2018 at 9:39 AM Duy Nguyen wrote:
>
> On Wed, Aug 8, 2018 at 8:46 PM Elijah Newren wrote:
> > > @@ -701,6 +702,24 @@ static int traverse_by_cache_tree(int pos, int
> > > nr_entries, int nr_names,
> > If we're going to go this route, I think we should first check that
> > o->fn i
> Abandon the previous approach of mutating all new objects implicitly in
> add_pending_object by inverting the meaning of the bit (it is now
> NOT_USER_GIVEN) and only setting the flag when we need to.
>
> This more accurately tracks if a tree was provided directly by the user.
> Without this pat
On Fri, Aug 10, 2018 at 9:29 AM Duy Nguyen wrote:
> On Wed, Aug 8, 2018 at 8:23 PM Elijah Newren wrote:
> > > +* cache-tree would be invalidated and we would never get here
> > > +* in the first place.
> > > +*/
> > > + for (i = 0; i < nr_entries; i++) {
> > > +
On Fri, Aug 10, 2018 at 11:34:59AM -0700, Junio C Hamano wrote:
> Johannes Sixt writes:
>
> > As this buglet looks like a recurring theme, and a proper fix is
> > preferable over repeated work-arounds. To me it looks like we need
> > some sort of locking on Windows. Unless your friends at Micros
> Matthew DeVore (5):
> revision: invert meaning of the USER_GIVEN flag
> list-objects-filter: implement filter only:commits
> list-objects: store common func args in struct
> list-objects: refactor to process_tree_contents
> rev-list: handle missing tree objects properly
Firstly, run ev
Hi Philip
Thanks for CC'ing me Peff.
On 10/08/18 19:27, Jeff King wrote:
On Thu, Aug 09, 2018 at 08:17:36PM -0700, Philip White wrote:
I’d like to report what I suspect is a bug in Git, tested in 2.18 and
2.14. (I’d be delighted to be corrected if it is my own
misunderstanding.) I’m reporting
Alban Gruin writes:
> This rewrites complete_action() from shell to C.
>
> A new mode is added to rebase--helper (`--complete-action`), as well as
> a new flag (`--autosquash`).
>
> Finally, complete_action() is stripped from git-rebase--interactive.sh.
>
> The original complete_action() would re
On Fri, Aug 10, 2018 at 8:39 PM Elijah Newren wrote:
>
> On Fri, Aug 10, 2018 at 9:39 AM Duy Nguyen wrote:
> >
> > On Wed, Aug 8, 2018 at 8:46 PM Elijah Newren wrote:
> > > > @@ -701,6 +702,24 @@ static int traverse_by_cache_tree(int pos, int
> > > > nr_entries, int nr_names,
>
> > > If we're g
Hi Peff,
On Fri, 10 Aug 2018, Jeff King wrote:
> On Fri, Aug 10, 2018 at 06:43:07PM +0200, Johannes Schindelin wrote:
>
> > So unless you are willing to ignore, to willfully keep this breakage,
> > I would suggest not to introduce the ugliness of an overridden
> > upload-pack for the sole purpos
Hi Junio,
Le 10/08/2018 à 21:25, Junio C Hamano a écrit :
> Alban Gruin writes:
>
>> This rewrites complete_action() from shell to C.
>>
>> A new mode is added to rebase--helper (`--complete-action`), as well as
>> a new flag (`--autosquash`).
>>
>> Finally, complete_action() is stripped from gi
On Fri, Aug 10, 2018 at 12:30 PM Duy Nguyen wrote:
> On Fri, Aug 10, 2018 at 8:39 PM Elijah Newren wrote:
...
> > Why do we still need to go through add_index_entry()? I thought that
> > the whole point was that you already checked that at the current path,
> > the trees being unpacked were all
From: Johannes Schindelin
This function will be used to make write accesses in trace_write() a bit
safer.
Note: this patch takes a very different approach for cross-platform
support than Git is historically taking: the original approach is to
first implement everything on Linux, using the functi
I reported a couple of times that t5552 is not passing reliably. It has now
reached next, and will no doubt infect master soon.
Turns out that it is not a Windows-specific issue, even if it occurs a lot
more often on Windows than elsewhere. (And even if it is apparently
impossible to trigger on L
From: Johannes Schindelin
Recently, t5552 introduced a pattern where two processes try to write to
the same GIT_TRACE file in parallel. This is not safe, as the two
processes fighting over who gets to append to the file can cause garbled
lines and may even result in data loss on Windows (where bu
From: Johannes Schindelin
For some reason, t/t5552-skipping-fetch-negotiator.sh fails particularly
often on Windows due to racy tracing where the `git upload-pack` and the
`git fetch` processes compete for the same file.
We just introduced a remedy that uses fcntl(), but Windows does not have
fc
From: Johannes Schindelin
When multiple processes try to write to the same file, it is not
guaranteed that everything works as expected: those writes can overlap,
and in the worst case even lose messages.
This happens in t/t5552-skipping-fetch-negotiator.sh, where we abuse the
`GIT_TRACE` facili
On Fri, Aug 10, 2018 at 9:40 PM Elijah Newren wrote:
>
> On Fri, Aug 10, 2018 at 12:30 PM Duy Nguyen wrote:
> > On Fri, Aug 10, 2018 at 8:39 PM Elijah Newren wrote:
> ...
> > > Why do we still need to go through add_index_entry()? I thought that
> > > the whole point was that you already checke
"Johannes Schindelin via GitGitGadget"
writes:
> +
> +#ifndef GIT_WINDOWS_NATIVE
> +int lock_or_unlock_fd_for_appending(int fd, int lock_it)
> +{
> + struct flock flock;
> +
> + flock.l_type = lock_it ? F_WRLCK : F_UNLCK;
> +
> + /* (un-)lock the whole file */
> + flock.l_whence =
Hi Eric,
On Sun, 22 Jul 2018, Eric Sunshine wrote:
> On Sat, Jul 21, 2018 at 6:05 PM Johannes Schindelin via GitGitGadget
> wrote:
> > Tab completion of `git range-diff` is very convenient, especially
> > given that the revision arguments to specify the commit ranges to
> > compare are typicall
Alban Gruin writes:
>> Hmph. It is easy enough to do the clean-up ourselves in this code,
>> instead of asking the caller to do so. On the other hand, stashing
>> of local changes is done by the caller, so it feels a bit strange
>> way to divide the labor between the two parts.
>>
>> Other tha
Hi Thomas,
On Mon, 30 Jul 2018, Thomas Gummerer wrote:
> On 07/30, Johannes Schindelin wrote:
> >
> > 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 Schind
Hi Thomas,
On Mon, 30 Jul 2018, Thomas Gummerer wrote:
> On 07/30, Johannes Schindelin wrote:
> >
> > On Sun, 29 Jul 2018, Thomas Gummerer wrote:
> >
> > > On 07/21, Johannes Schindelin via GitGitGadget wrote:
> > > >
> > > > [...]
> > > >
> > > > +static void find_exact_matches(struct string
Hi Thomas,
On Sun, 29 Jul 2018, Thomas Gummerer wrote:
> 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
> > wi
Hi Thomas,
On Sun, 29 Jul 2018, Thomas Gummerer wrote:
> 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 ther
Hi Stefan,
On Mon, 23 Jul 2018, Stefan Beller wrote:
> On Sat, Jul 21, 2018 at 3:05 PM Johannes Schindelin via GitGitGadget
> wrote:
> >
> > From: Johannes Schindelin
> >
> > When displaying a diff of diffs, it is possible that there is an outer
> > `+` before a context line. That happens when
Hi Thomas,
On Sun, 29 Jul 2018, Thomas Gummerer wrote:
> On 07/21, Johannes Schindelin via GitGitGadget wrote:
> > From: Johannes Schindelin
> >
> > Documentation/git-range-diff.txt | 229 +++
> > 1 file changed, 229 insertions(+)
> >
> > [...]
> >
> > +CONFIGURATI
Hi Thomas,
On Sun, 29 Jul 2018, Thomas Gummerer wrote:
> 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
> >
Hi Eric,
On Mon, 30 Jul 2018, Eric Sunshine wrote:
> On Mon, Jul 30, 2018 at 5:26 PM Thomas Gummerer wrote:
> > On 07/30, Johannes Schindelin wrote:
> > > On Sun, 29 Jul 2018, Thomas Gummerer wrote:
> > > > There's one more thing that I noticed here:
> > > >
> > > > git range-diff --no-patch
Le 10/08/2018 à 22:27, Junio C Hamano a écrit :
> If we are planning to make all the backend responsible for stashing
> away before they run and applying the stash after they are done,
> then it might make sense to have the application side on the backend
> as the first step. But if what you need
Hi Stefan,
On Wed, 8 Aug 2018, Stefan Beller wrote:
> On Wed, Aug 8, 2018 at 6:05 AM Johannes Schindelin
> wrote:
>
> > > [...]
> > > > diff --git a/Makefile b/Makefile
> > > > --- a/Makefile
> > > > +++ b/Makefile
> > >
> > > The line starting with --- is red (default removed
Brandon Williams writes:
> Introduce a helper function "submodule_name_to_gitdir()" (and the
> submodule--helper subcommand "gitdir") which constructs a path to a
> submodule's gitdir, located in the provided repository's "modules"
> directory.
>
> This consolidates the logic needed to build up a
Hi Junio,
On Fri, 10 Aug 2018, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > +
> > +#ifndef GIT_WINDOWS_NATIVE
> > +int lock_or_unlock_fd_for_appending(int fd, int lock_it)
> > +{
> > + struct flock flock;
> > +
> > + flock.l_type = lock_it ? F_WRLCK : F_UNL
On Fri, Aug 10, 2018 at 5:12 PM Johannes Schindelin
wrote:
> On Mon, 30 Jul 2018, Eric Sunshine wrote:
> > I think you can attain the desired behavior by making a final
> > parse_options() call with empty 'options' list after the call to
> > diff_setup_done(). It's pretty much a one-line fix, but
Johannes Schindelin writes:
> I'll just try to get that option parsing change in that Eric suggested,
> force-push, then wait for macOS and Linux builds to pass (trusting that
> Windows will follow suite) and hit /submit.
OK. Obviously receiving, applying and inspecting that result will
not be
On 08/10, Junio C Hamano wrote:
> Brandon Williams writes:
>
> > Introduce a helper function "submodule_name_to_gitdir()" (and the
> > submodule--helper subcommand "gitdir") which constructs a path to a
> > submodule's gitdir, located in the provided repository's "modules"
> > directory.
> >
> >
On 08/03, Stefan Beller wrote:
> e98317508c0 (submodule: ensure core.worktree is set after update,
> 2018-06-18) was overly aggressive in calling connect_work_tree_and_git_dir
> as that ensures both the 'core.worktree' configuration is set as well as
> setting up correct gitlink file pointing at th
> > + cfg_file = xstrfmt("%s/config", subrepo.gitdir);
>
> As I mentioned here:
> https://public-inbox.org/git/20180807230637.247200-1-bmw...@google.com/T/#t
>
> This lines should probably be more like:
>
> cfg_file = repo_git_path(&subrepo, "config");
>
Why? You did not mention the
On Thu, Aug 09, 2018 at 01:04:43PM +0200, Bartosz Konikiewicz wrote:
> Steps to reproduce:
>
> 1. Create a new file.
> 2. Stage the file.
> 3. Add the file to .gitignore.
> 4. Stage the .gitignore.
> 5. Commit changes.
>
> I imagined that the file would now be removed from the stage (because
> it
Hi Junio,
On Fri, 10 Aug 2018, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > I'll just try to get that option parsing change in that Eric suggested,
> > force-push, then wait for macOS and Linux builds to pass (trusting that
> > Windows will follow suite) and hit /submit.
>
> OK.
Hi Eric,
On Fri, 10 Aug 2018, Eric Sunshine wrote:
> On Fri, Aug 10, 2018 at 5:12 PM Johannes Schindelin
> wrote:
> > On Mon, 30 Jul 2018, Eric Sunshine wrote:
> > > I think you can attain the desired behavior by making a final
> > > parse_options() call with empty 'options' list after the call
On 08/10, Stefan Beller wrote:
> > > + cfg_file = xstrfmt("%s/config", subrepo.gitdir);
> >
> > As I mentioned here:
> > https://public-inbox.org/git/20180807230637.247200-1-bmw...@google.com/T/#t
> >
> > This lines should probably be more like:
> >
> > cfg_file = repo_git_path(&subre
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 of
the second, assign all items (except when the sets have diffe
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 list) is slightly less useful for this developer due to
the fact that it requires the hungarian and numpy Python packages which ar
From: Johannes Schindelin
We are comparing complete, formatted commit messages with patches. There
are no function names here, so stop looking for them.
Signed-off-by: Johannes Schindelin
---
range-diff.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/range-diff.c b/range-diff.c
ind
From: Johannes Schindelin
The main information in the `range-diff` view comes from the list of
matching and non-matching commits, the diffs are additional information.
Indenting them helps with the reading flow.
Signed-off-by: Johannes Schindelin
---
builtin/range-diff.c | 10 ++
1 fil
From: Johannes Schindelin
This not only uses "dashed stand-ins" for "pairs" where one side is
missing (i.e. unmatched commits that are present only in one of the two
commit ranges), but also adds onelines for the reader's pleasure.
This change brings `git range-diff` yet another step closer to
f
From: Johannes Schindelin
When showing the diff between corresponding patches of the two branch
versions, we have to make up a fake filename to run the diff machinery.
That filename does not carry any meaningful information, hence tbdiff
suppresses it. So we should, too.
Signed-off-by: Johannes
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 needed
to be adjusted: 11 - 'changed message'.
The underlying r
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, i.e. the hypothetical
diff which is the result of first reverting the o
From: Johannes Schindelin
This command does not do a whole lot so far, apart from showing a usage
that is oddly similar to that of `git tbdiff`. And for a good reason:
the next commits will turn `range-branch` into a full-blown replacement
for `tbdiff`.
At this point, we ignore tbdiff's color op
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, the
non-dual color mode is substantially worse in that regard.
1 - 100 of 158 matches
Mail list logo
