> For those who want to know, this question was motivated by a big delta
> tree occurring in [1].
Forgot to mention: this is not an issue of the server not repacking with
a chain length limit. The tree in question is indeed not tall, but it is
very wide.
Does anyone have ideas or plans for this? I know that (at least) "grep"
and "index-pack" have their own implementations, and it would be great
to just have one that all code can use.
For those who want to know, this question was motivated by a big delta
tree occurring in [1]. index-pack does paral
On Wed, Sep 25, 2019 at 02:28:15PM -0700, Elijah Newren wrote:
[...]
> > Sorry for the information dump, I haven't had the time to properly look
> > into the issue but I just wanted to make sure that you're aware.
>
> Thanks for testing and sending the heads up. Unfortunately, I cannot
> reprod
Previously, when promisor_remote_move_to_tail() is called for a
promisor_remote which is currently the *only* element in promisors, a
cycle is created in the promisors linked list. This cycle leads to a
double free later on in promisor_remote_clear(): promisors is set to
promisors->next (a no-op, a
Hi Denton,
On Wed, Sep 25, 2019 at 1:39 PM Denton Liu wrote:
>
> Hi Elijah,
>
> I ran into a segfault on MacOS. I managed to bisect it down to
> 404ebceda0 (dir: also check directories for matching pathspecs,
> 2019-09-17), which should be the patch in the parent thread. The test
> case below wor
Hi Elijah,
I ran into a segfault on MacOS. I managed to bisect it down to
404ebceda0 (dir: also check directories for matching pathspecs,
2019-09-17), which should be the patch in the parent thread. The test
case below works fine without this patch applied but segfaults once it
is applied.
This adds highlight support for the diff3 conflict style.
The common pre-image will be reversed to --, because it has been removed
and either replaced with ours or theirs side.
Signed-off-by: Bert Wesarg
---
git-gui.sh | 3 +++
lib/diff.tcl | 22 ++
2 files changed, 25 in
Replace the hand-coded call to git check-attr with the already provided one.
Signed-off-by: Bert Wesarg
---
lib/diff.tcl | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/lib/diff.tcl b/lib/diff.tcl
index 958a0fa..0fd4600 100644
--- a/lib/diff.tcl
+++ b/lib/diff
[Sorry, I made a mistake and this message was not transmitted :/]
This can be seen as a continuation of ag/reduce-rewriting-todo.
Currently, complete_action() releases its todo list before calling
sequencer_continue(), which reloads the todo list from the disk. This
series removes this useless r
Currently, complete_action() calls sequencer_continue() to do the
rebase. Even though the former already has the todo list, the latter
loads it from the disk and parses it. Calling directly pick_commits()
from complete_action() avoids this unnecessary round trip.
Signed-off-by: Alban Gruin
---
`total_nr' is the total amount of items, done and toto, that are in a
todo list. But unlike `nr', it was not updated when an item was
appended to the list.
This variable is mostly used by command prompts (ie. git-prompt.sh and
the like).
Signed-off-by: Alban Gruin
---
sequencer.c | 1 +
1 file
get_replay_opts() did not fill `squash_onto' if possible, meaning that
this field should be read from the disk by the sequencer through
read_populate_opts(). Without this, calling `pick_commits()' directly
will result in incorrect results with `rebase --root'.
Let’s change that.
Signed-off-by: A
The total amount of commands can be used to show the progression of the
rebasing in a shell. It is written to the disk by read_populate_todo()
when the todo list is loaded from sequencer_continue() or
pick_commits(), but not by complete_action().
This moves the part writing total_nr to a new func
In a todo list, `done_nr' is the amount of commands that were executed
or skipped, but skip_unnecessary_picks() did not update it.
This variable is mostly used by command prompts (ie. git-prompt.sh and
the like).
Signed-off-by: Alban Gruin
---
sequencer.c | 1 +
1 file changed, 1 insertion(+)
On Wed, Sep 25, 2019 at 03:26:57AM -0700, Denton Liu wrote:
> I tried my hand at fixing the bug but in the hour I spent going at it, I
> couldn't fix the logic up. The buggy logic is in graph.c:
> graph_draw_octopus_merge() in case anyone is interested.
I guess for the record, this was the final p
Hi,
On Mon, 23 Sep 2019, Kunal Tyagi via GitGitGadget wrote:
> From: Kunal Tyagi
>
> Signed-off-by: Kunal Tyagi
Could you move most (if not all) of the explanation from the cover
letter (read: the PR description) into the commit message?
The patch looks good, I just have one suggestion:
> --
Hi,
On Mon, 23 Sep 2019, Kunal Tyagi via GitGitGadget wrote:
> Hi git contributors!
>
> I'm Kunal Tyagi. While I was choosing the relevant patches for a commit
> using the git add -p command, I found that there was no feedback regarding
> how many hunks from the current file had been processed an
On 25/09/2019 15:32, Thomas Gummerer wrote:
On 09/25, Philip Oakley wrote:
Hi,
At the Virtual Git Contributors Summit we discussed (#13) the bi-weekly
standup meetings (mentioned in the Git Rev News edition 55 under
'News/Various').
The Git Events calendar [1] that's linked from the Rev News d
Hi Alexandr,
On Mon, 23 Sep 2019, Alexandr Miloslavskiy via GitGitGadget wrote:
> From: Alexandr Miloslavskiy
>
> Even though Debug configuration builds, the resulting build is incorrect
> in a subtle way: it mixes up Debug and Release binaries, which in turn
> causes hard-to-predict bugs.
>
> I
On 09/25, Philip Oakley wrote:
> Hi,
>
> At the Virtual Git Contributors Summit we discussed (#13) the bi-weekly
> standup meetings (mentioned in the Git Rev News edition 55 under
> 'News/Various').
>
> The Git Events calendar [1] that's linked from the Rev News doesn't actually
> say what time z
Hi Pierre,
On 25/09/2019 14:36, Pierre Tardy wrote:
As a community, our number one goal is for Git to continue to be the best
distributed version control system. At minimum, it should continue to be
the most widely-used DVCS.
I'd rather we stated our goal in terms of what problems we are trying
On 9/25/2019 9:36 AM, Pierre Tardy wrote:
>>> As a community, our number one goal is for Git to continue to be the best
>>> distributed version control system. At minimum, it should continue to be
>>> the most widely-used DVCS.
>>
>> I'd rather we stated our goal in terms of what problems we are tr
> > As a community, our number one goal is for Git to continue to be the best
> > distributed version control system. At minimum, it should continue to be
> > the most widely-used DVCS.
>
> I'd rather we stated our goal in terms of what problems we are trying
> to address rather than accolades we w
On 25/09/19 08:33AM, Bert Wesarg wrote:
> Pratyush,
>
> once again, I had done this years ago. I may post an updated patch in
> the evening:
>
> https://github.com/bertwesarg/git-gui/commit/90ee4a8c260132a6b730040095929fd267cedd7b
Nice! I was about to dive into this bug, but it is great that you
Hi,
At the Virtual Git Contributors Summit we discussed (#13) the bi-weekly
standup meetings (mentioned in the Git Rev News edition 55 under
'News/Various').
The Git Events calendar [1] that's linked from the Rev News doesn't
actually say what time zone to use for the stand-up start time, so
On 9/23/2019 9:03 PM, Eric Wong wrote:
> Patches 1-11 are largely unchanged from the original series with the
> exception of 2, which is new and posted at:
>
> https://public-inbox.org/git/20190908074953.kux7zz4y7iolqko4@whir/
>
> 12-17 take further steps to get us away from hashmap_entry b
On 9/23/2019 9:03 PM, Eric Wong wrote:
> Using `container_of' can be verbose and choosing names for
> intermediate "struct hashmap_entry" pointers is a hard problem.
> So introduce "*_entry" APIs inspired by similar linked-list
> APIs in the Linux kernel.
>
> Unfortunately, `__typeof__' is not por
On 9/23/2019 9:03 PM, Eric Wong wrote:
> This macro is popular within the Linux kernel for supporting
> intrusive data structures such as linked lists, red-black trees,
> and chained hash tables while allowing the compiler to do
> type checking.
>
> I intend to use this to remove the limitation of
On 9/23/2019 9:03 PM, Eric Wong wrote:
> This is a step towards removing the requirement for
> hashmap_entry being the first field of a struct.
>
> Signed-off-by: Eric Wong
> ---
> diff.c | 19 ---
> diffcore-rename.c | 11 +++
> hashmap.c
On 9/23/2019 9:03 PM, Eric Wong wrote:
> This is less error-prone than "const void *" as the compiler
> now detects invalid types being passed.
[snip]
> diff --git a/hashmap.c b/hashmap.c
> index 092236c09a..bdf33e0381 100644
> --- a/hashmap.c
> +++ b/hashmap.c
> @@ -218,7 +218,8 @@ void hashmap_ad
On 9/23/2019 9:03 PM, Eric Wong wrote:
> This is less error-prone than "const void *" as the compiler
> now detects invalid types being passed.
[snip]
> diff --git a/hashmap.h b/hashmap.h
> index 40bcc64289..2a4b4a3954 100644
> --- a/hashmap.h
> +++ b/hashmap.h
> @@ -74,7 +74,8 @@
> *
On 9/23/2019 9:03 PM, Eric Wong wrote:
> C compilers do type checking to make life easier for us. So
> rely on that and update all hashmap_entry_init callers to take
> "struct hashmap_entry *" to avoid future bugs while improving
> safety and readability.
[snip]
> @@ -244,9 +244,9 @@ void hashmap_
From: Johannes Schindelin
When Git wants to spawn a child Git process inside a worktree's
subdirectory, we need to take care of specifying the work tree's
top-level directory explicitly because it cannot be discovered: the
current directory is _not_ the top-level directory of the work tree, and
n
I saw this issue a couple times in my setup, and always wondered why nobody
else seemed to be hit by this. When I finally found/made some time to
investigate, I found out that it really requires a specific setup: I have
many worktrees connected to my main git.git clone, often run inside t/ and I
do
On 9/23/2019 9:03 PM, Eric Wong wrote:
> Assigning hashmap_entry.hash manually leaves hashmap_entry.next
> uninitialized, which can be dangerous once the hashmap_entry is
> inserted into a hashmap. Detect those assignments and use
> hashmap_entry_init, instead.
I appreciate this future-proofing!
On 9/23/2019 9:03 PM, Eric Wong wrote:
> Since these macros already take a `keyvar' pointer of a known type,
> we can rely on OFFSETOF_VAR to get the correct offset without
> relying on non-portable `__typeof__' and `offsetof'.
>
> Argument order is also rearranged, so `keyvar' and `member' are
>
Hi everyone,
The 55th edition of Git Rev News is now published:
https://git.github.io/rev_news/2019/09/25/edition-55/
Thanks a lot to Emily Shaffer, James Ramsay, Pratik Karki and Thomas
Ferris who contributed this month!
Enjoy,
Christian, Jakub, Markus and Gabriel.
PS: An issue for the next
Hi,
On Tue, 24 Sep 2019, Jeff King wrote:
> On Tue, Sep 24, 2019 at 10:14:55PM +0200, René Scharfe wrote:
>
> > > +* Trolling, insulting/derogatory comments, and personal or
> > > political attacks
> >
> > Hmm. Trolling can be helpful, if done right. I consider this to be
> > a good example: ht
Before, the expect files of the test case were being generated in the
setup method. However, it would make more sense to generate these files
within the test cases that actually use them so that it's obvious to
future readers where the expected values are coming from.
Move the generation of the ex
In the previous commit, we extended test_merge() so that it could
perform octopus merges. Now that the restriction is lifted, use
test_merge() to perform the octopus merge instead of manually
duplicating test_merge() functionality.
Signed-off-by: Denton Liu
---
t/t4214-log-graph-octopus.sh | 3 +
This patchset cleans up t4214 and then, in the last patch, demonstrates
a bug in the way some octopus merges are colored.
While I was playing around with Pratyush's octopus merge in git-gui, I
noticed that there was a bug in `git log --graph`. The horizontal lines
in the octopus merge seemed to ha
In a future test case, we will be extending the commit graph. As a
result, explicitly list the tags that will generate the graph so that
when future additions are made, the current graph illustrations won't be
affected.
Signed-off-by: Denton Liu
---
t/t4214-log-graph-octopus.sh | 8
1 f
The graph coloring logic for octopus merges currently has a bug. This
can be seen git.git with 74c7cfa875 (Merge of
http://members.cox.net/junkio/git-jc.git, 2005-05-05), whose second
child is 211232bae6 (Octopus merge of the following five patches.,
2005-05-05).
If one runs
git log --gra
Currently test_merge() only allows developers to merge in one branch.
However, this restriction is artificial and there is no reason why it
needs to be this way.
Extend test_merge() to allow the specification of multiple branches so
that octopus merges can be performed.
Signed-off-by: Denton Liu
On 25/09/2019 07:33, Bert Wesarg wrote:
Pratyush,
once again, I had done this years ago. I may post an updated patch in
the evening:
https://github.com/bertwesarg/git-gui/commit/90ee4a8c260132a6b730040095929fd267cedd7b
Bert
Thanks, I'll see if I can look at it (I'd also need to re-prepare my
From: Johannes Schindelin
The `qsort()` function is not guaranteed to be stable, i.e. it does not
promise to maintain the order of items it is told to consider equal. In
contrast, the `git_sort()` function we carry in `compat/qsort.c` _is_
stable, by virtue of implementing a merge sort algorithm.
From: Johannes Schindelin
During Git's rename detection, the file names are sorted. At the moment,
this job is performed by `qsort()`. As that function is not guaranteed
to implement a stable sort algorithm, this can lead to inconsistent
and/or surprising behavior: a rename might be detected diff
With the en/merge-recursive-cleanup patches already having advanced to next,
the problem I discovered when rebasing Git for Windows' branch thicket
becomes quite relevant now: t3030.35 fails consistently in the MSVC build &
test (this part of the Azure Pipeline will be upstreamed later).
The solut
Currently, when testing headers using `make hdr-check`, headers are
directly compiled. Although this seems to test the headers, this is too
strict since we treat the headers as C sources. As a result, this will
cause warnings to appear that would otherwise not, such as a static
variable definition
When we ran `make hdr-check`, we got the following warning message:
promisor-remote.h:21:46: warning: declaration of 'struct repository'
will not be visible outside of this function [-Wvisibility]
extern int promisor_remote_get_direct(struct repository *repo,
When running `make hdr-check`, we got the following error messages:
apply.h:146:22: error: use of undeclared identifier 'GIT_MAX_HEXSZ'
char old_oid_prefix[GIT_MAX_HEXSZ + 1];
^
apply.h:147:22: error: use of undeclared identifier
When we ran `make hdr-check` with the following patch
diff --git a/Makefile b/Makefile
index f879697ea3..d8df4e316b 100644
--- a/Makefile
+++ b/Makefile
@@ -2773,7 +2773,7 @@ CHK_HDRS = $(filter-out $(EXCEPT_HDRS),$(patsubst
./%,%,$(LIB_H)))
HCO = $
The first two patches fix errors causing `make hdr-check` to fail. The third is
legacy from v1 but provides code cleanup so we leave it. Finally, the last
patch is a patch which improves the portability and correctness of `hdr-check`.
Changes since v1:
* Reordered patches to put fixes first
* To
53 matches
Mail list logo
