On Tue, Oct 22, 2019 at 07:28:47PM -0400, Prarit Bhargava wrote:
> In many projects the number of contributors is low enough that users know
> each other and the full email address doesn't need to be displayed.
> Displaying only the author's username saves a lot of columns on the screen.
> For exa
On Tue, Oct 22, 2019 at 08:48:20PM -0400, Jeff King wrote:
> I admit I am puzzled, though, _why_ the presence of the submodule
> matters. That is, from your explanation, I thought the issue was simply
> that `fetch` walked (and marked) some commits, and the flags overlapped
> with wha
On Tue, Oct 22, 2019 at 08:35:57PM -0400, Derrick Stolee wrote:
> > In the cover letter Derrick mentioned that he used
> > https://github.com/derrickstolee/numbers for testing, and that repo
> > has a submodule as well.
>
> I completely forgot that I put a submodule in that repo. It makes sense
>
On Tue, Oct 22, 2019 at 04:33:16PM -0400, Jeff King wrote:
> > I have failed to produce a test using the file:// protocol that
> > demonstrates this bug.
>
> Hmm, from the description, it sounds like it should be easy. I might
> poke at it a bit.
Hmph. I can reproduce it
On Tue, Oct 22, 2019 at 05:28:55PM +, Derrick Stolee via GitGitGadget wrote:
> However, the UNINTERESTING flag is used in lots of places in the
> codebase. This flag usually means some barrier to stop a commit walk,
> such as in revision-walking to compare histories. It is not often
> cleared
[resending, looks like we lost Konstantin from the cc]
On Tue, Oct 22, 2019 at 03:44:28PM -0400, Derrick Stolee wrote:
> I'm biased, but I think the commit-graph is generally really good to have
> in almost all cases. I actually do not know of a good reason to _not_ have
> it.
A lot depends on h
On Tue, Oct 22, 2019 at 03:44:28PM -0400, Derrick Stolee wrote:
> I'm biased, but I think the commit-graph is generally really good to have
> in almost all cases. I actually do not know of a good reason to _not_ have
> it.
A lot depends on how much you do on the server. If you're serving a web
in
On Mon, Oct 21, 2019 at 04:04:22PM -0700, Elijah Newren wrote:
> > 4211.3: git log --follow [...]8.56(8.41+0.15) -0.2% 3.67(3.53+0.13)
> > -57.2%
>
> Many nice speedups here, not just commit-graph (the rev-list cases)
> but also log -L (from sg/line-log-tree-diff-optim, I believe), and log
On Tue, Oct 22, 2019 at 04:49:19AM +0900, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> >> ... I do not particularly see this change (there may be similar
> >> ones) desirable. I'd find it it be much more natural to sort
> >> "commit-anything" after "commit", and that is true with or
On Mon, Oct 21, 2019 at 05:51:52PM +0900, Junio C Hamano wrote:
> > - void *value;
> > + union {
> > + int *intp;
> > + const char *strp;
> > + } value;
> [...]
> The side that actually use .vale would need to change for obvious
> reasons, which may be painful, but I agre
On Mon, Oct 21, 2019 at 09:52:11AM +0900, Junio C Hamano wrote:
> I can sympathize, but I do not think it is worth inventing OPT_U64()
> or adding "int total_i" whose value is assigned to "u64 total" after
> parsing a command line arg with OPT_INTEGER() into the former.
>
> Catching a pointer who
On Mon, Oct 21, 2019 at 11:48:40AM +0900, Junio C Hamano wrote:
> > +`git clone` can use any bundle created without negative refspecs
> > +(e.g., `new`, but not `old..new`).
>
> To be consistent with the phrasing of this particular document we
> saw earlier, you would have said "without basis", b
On Fri, Oct 18, 2019 at 09:30:52PM +0100, Philip Oakley wrote:
> +`git clone` can use any bundle created without negative refspecs
> +(e.g., `new`, but not `old..new`).
> +If you want to match `git clone --mirror`, which would clone other
> +refs such as `refs/remotes/*`, use `--all`.
> +If you wa
On Sat, Oct 19, 2019 at 09:20:11PM +0200, Christian Couder wrote:
> > > +static void write_reused_pack_one(size_t pos, struct hashfile *out,
> > > + struct pack_window **w_curs)
> > > +{
> > > + off_t offset, next, cur;
> > > + enum object_type type;
> > > +
On Sat, Oct 19, 2019 at 04:25:19PM +0100, Philip Oakley wrote:
> > +int bitmap_walk_contains(struct bitmap_index *bitmap_git,
> > +struct bitmap *bitmap, const struct object_id *oid)
> > +{
> > + int idx;
> Excuse my ignorance here...
>
> For the case on Windows (int/long 32
On Thu, Oct 17, 2019 at 10:20:38PM +, brian m. carlson wrote:
> > > Documentation/git-commit-tree.txt | 6 ++
> > > 1 file changed, 6 insertions(+)
> >
> > ...I was surprised to see it here, where I think most users wouldn't
> > find it. Would it make sense in git-commit(1), or in the de
d continue looking at the
struct).
This also covers the case where the tag contains a nonsensical "type"
field (there we produced a user-visible error but still returned success
to the caller; now we'll produce a slightly better message and return an
error).
Signed-off-by: Jeff King
op the check in the caller added by that
commit yet, as there's some subtlety with repeated parsings (which will
be addressed in a future commit).
Signed-off-by: Jeff King
---
commit.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/commit.c b/commit.c
index 6467c
ust testing the
"lone" case again. Changing that reveals the breakage (and shows that
this fixes it).
Signed-off-by: Jeff King
---
commit.c | 11 ---
t/t6102-rev-list-unexpected-objects.sh | 2 +-
2 files changed, 9 insertions(+), 4 deletions(-)
diff
The thread starting at:
https://public-inbox.org/git/xmqqo8zxnz0m@gitster-ct.c.googlers.com/
discusses some issues with our handling of corrupt objects, as well as
some weirdness in fsck. This series is my attempt to clean it up. The
number of patches is a little daunting, but the early one
m the struct.
Signed-off-by: Jeff King
---
fsck.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/fsck.c b/fsck.c
index f8c5bbe891..ac4ba4c8e8 100644
--- a/fsck.c
+++ b/fsck.c
@@ -566,7 +566,7 @@ static int verify_ordered(unsigned mode1, const
from the struct.
Signed-off-by: Jeff King
---
fsck.c | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/fsck.c b/fsck.c
index 42e7d1f71f..38be501278 100644
--- a/fsck.c
+++ b/fsck.c
@@ -820,7 +820,7 @@ static int fsck_commit(struct commit *commit,
arsed bits from the struct.
Signed-off-by: Jeff King
---
fsck.c | 29 ++---
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git a/fsck.c b/fsck.c
index 38be501278..f8c5bbe891 100644
--- a/fsck.c
+++ b/fsck.c
@@ -764,8 +764,9 @@ static int fsck_ident(const char **
In fsck_commit() and fsck_tag(), we have local "oid" variables used for
parsing parent and tagged-object oids. Let's give these more specific
names in preparation for the functions taking an "oid" parameter for the
object we're checking.
Signed-off-by: Jeff King
--
We only need the oid and type to pass on to report(). Let's accept the
broken-out parameters to give our callers more flexibility.
Signed-off-by: Jeff King
---
fsck.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/fsck.c b/fsck.c
index e1d06fb210..50c93
We don't actually need any information from the object struct except its
oid (and the type, of course, but that's implicitly OBJ_BLOB). This
gives our callers more flexibility to drop the object structs, too.
Signed-off-by: Jeff King
---
fsck.c | 26 +-
1 fi
al goal is to shrink these down as we continue refactoring
(e.g., "&item->object" becomes "&item->object.oid, item->object.type",
but will eventually shrink down to "oid, type").
Signed-off-by: Jeff King
---
fsck.c | 128 +++
ntents and
type from disk).
Signed-off-by: Jeff King
---
fsck.c | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/fsck.c b/fsck.c
index 6e9640a1a6..4ff0ceb4ac 100644
--- a/fsck.c
+++ b/fsck.c
@@ -1013,7 +1013,6 @@ int fsck_finish(struct fsck_options *options)
The only thing we do with the struct is pass its oid and type to
report(). We can just take those explicitly, which gives our callers
more flexibility.
Signed-off-by: Jeff King
---
fsck.c | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/fsck.c
The skiplist is inherently an oidset, so we don't need a full object
struct. Let's take just the oid to give our callers more flexibility.
Signed-off-by: Jeff King
---
fsck.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/fsck.c b/fsck.c
index
y takes a "type" field for the fsck message
type. We'll rename that to "msg_type" (and use "object_type" for the
object type) to make the distinction explicit.
Signed-off-by: Jeff King
---
builtin/fsck.c | 17 ++---
fsck.c | 11 +++
Our printable_type() and describe_object() functions take whole object
structs, but they really only care about the oid and type. Let's take
those individually in order to give our callers more flexibility.
Signed-off-by: Jeff King
---
builtin/fsck.c
d" check. It's not helping anything, and
getting rid of it makes the function conceptually cleaner, as it really
is just checking the buffer we feed it. In fact, we can get rid of our
one-line wrapper and just unify fsck_tag() and fsck_tag_buffer().
Signed-off-by: Jeff King
---
fsck.c
s). We can solve this by switching to
a kh_oid_map (we could also use the hashmap oidmap, but it's more
awkward for the simple case of just storing a void pointer).
Signed-off-by: Jeff King
---
builtin/fsck.c | 12 +-
fsck.c | 61 ---
This isolates the implementation detail of using the decoration code to
our put/get functions.
Signed-off-by: Jeff King
---
Arguably this could be squashed into the previous commit. By not doing
so, it made describe_object() more of a pure code movement.
fsck.c | 5 +
1 file changed, 1
name we find.
And indeed, the test in t1450 expects this ugly HEAD@{} name. After
this patch, we've switched to using fsck_put_object_name()'s
first-one-wins semantics, and we output the more human-friendly
"refs/tags/julius" (and the test is upda
ch occurs
only if we happen to have seen the object with another type already in
the same process. In most cases, we'd actually run into the problem
during the connectivity walk, not here.
Signed-off-by: Jeff King
---
fsck.c | 23 +--
1 file changed, 1 insertion(+), 22 d
he to use
parsing functions, 2005-04-18), but we later added an explicit walk in
355885d531 (add generic, type aware object chain walker, 2008-02-25).
Signed-off-by: Jeff King
---
fsck.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/fsck.c b/fsck.c
index cdb7d8db03..6dfc533fb0 1
ing
to these. Note that we do drop a few fsck identifiers for missing tags,
but that was all dead code (because nobody passed a NULL tag buffer).
Signed-off-by: Jeff King
---
fsck.c | 51 +--
fsck.h | 6 +-
2 files changed, 14 insertions(+), 4
't know offhand of any
cases where the problem can be triggered (it implies somebody ignoring a
parse error earlier in the process), but consistently returning an error
should cause the least surprise.
Signed-off-by: Jeff King
---
commit-graph.c | 3 ---
commit.c| 14
On Thu, Oct 17, 2019 at 04:03:00PM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> >> Hmm, I am kind of surprised that the decoding side allowed such a
> >> padding.
> >
> > IIRC, the "padding" is just a sequence of 0-length-plus-continuatio
On Fri, Oct 11, 2019 at 09:33:11AM -0400, Derrick Stolee wrote:
> Here is today's test coverage report. The usual report format is
> available online [1], [2]. The report listed below is a new format
> that groups lines by the commit that introduced them [3]. Thanks
> Peff for the feedback on that
On Wed, Oct 09, 2019 at 04:44:22PM -0700, Jonathan Tan wrote:
> Signed-off-by: Jonathan Tan
> ---
> builtin/index-pack.c | 267 ---
> 1 file changed, 127 insertions(+), 140 deletions(-)
I think this is a good direction to go in. I confess I didn't careful
On Wed, Oct 09, 2019 at 04:44:21PM -0700, Jonathan Tan wrote:
> A subsequent commit will make the quantum of work smaller, necessitating
> more locking. This commit allows resolve_delta() to be called outside
> the lock.
OK, that makes sense, I think.
-Peff
On Wed, Oct 09, 2019 at 04:44:20PM -0700, Jonathan Tan wrote:
> Whenever we make a struct base_data, immediately calculate its delta
> children. This eliminates confusion as to when the
> {ref,ofs}_{first,last} fields are initialized.
That _seems_ like a good idea, but I'm a little worried just b
On Wed, Oct 09, 2019 at 04:44:19PM -0700, Jonathan Tan wrote:
> -static void prune_base_data(struct base_data *retain)
> +static void prune_base_data(struct base_data *youngest_child)
> {
> struct base_data *b;
> struct thread_local *data = get_thread_data();
> - for (b = data->ba
On Thu, Oct 10, 2019 at 12:02:29PM -0700, Jonathan Tan wrote:
> > On 10/9/2019 7:44 PM, Jonathan Tan wrote:
> > > Instead, recompute ancestry if we ever need to reclaim memory.
> >
> > I find this message lacking in important details:
> >
> > 1. Where do we recompute ancestry?
> > 2. What are th
On Wed, Oct 09, 2019 at 04:44:18PM -0700, Jonathan Tan wrote:
> Signed-off-by: Jonathan Tan
> ---
> builtin/index-pack.c | 26 --
> 1 file changed, 12 insertions(+), 14 deletions(-)
Yeah, this seems like a good cleanup. Probably worth explaining in the
commit message tha
On Wed, Oct 09, 2019 at 04:44:17PM -0700, Jonathan Tan wrote:
> Signed-off-by: Jonathan Tan
> ---
> builtin/index-pack.c | 10 +-
> 1 file changed, 1 insertion(+), 9 deletions(-)
>
> diff --git a/builtin/index-pack.c b/builtin/index-pack.c
> index a23454da6e..1a2600d4b3 100644
> --- a/b
On Fri, Oct 11, 2019 at 03:08:22PM -0700, Jonathan Tan wrote:
> > As a general rule (and why I'm raising this issue in reply to Jonathan's
> > patch), I think most or all sites that want OBJECT_INFO_QUICK will want
> > SKIP_FETCH_OBJECT as well, and vice versa. The reasoning is generally
> > the s
On Thu, Oct 17, 2019 at 03:00:58AM +, Ralph Ewig wrote:
> Thanks for the reply. I was hoping the Git GUI
> might be able to handle the OpenID authentication
> flow, but it makes sense that it would be
> inconsistent with other git clients.
I don't think we'd ever do the full flow, but it m
On Thu, Oct 17, 2019 at 12:53:30AM +, brian m. carlson wrote:
> Users in a wide variety of situations find themselves with HTTP push
> problems. Oftentimes these issues are due to antivirus software,
> filtering proxies, or other man-in-the-middle situations; other times,
> they are due to si
On Thu, Oct 17, 2019 at 12:53:29AM +, brian m. carlson wrote:
> There is no sensible behavior in this case, because sometimes the data
> is precious, such as certain configuration files, and sometimes it is
> irrelevant data that the user would be happy to discard.
>
> Since this is not a sup
On Thu, Oct 17, 2019 at 12:53:28AM +, brian m. carlson wrote:
> It's a frequent misconception that the user.name variable controls
> authentication in some way, and as a result, beginning users frequently
> attempt to change it when they're having authentication troubles.
> Document that the c
On Wed, Oct 16, 2019 at 10:57:37AM +0100, Philip Oakley wrote:
> From: Philip Oakley
>
> Git URLs can accept bundle files for fetch, pull and clone, include
> in that section. Include git clone in the bundle usage description.
> Correct the quoting of .
> Detail the options for cloning a comple
On Tue, Oct 15, 2019 at 01:07:59AM +, brian m. carlson wrote:
> Fix this by passing the option from the transport code through to remote
> helpers, and from the HTTP remote helper down to send-pack. With this
> change, we can detect if the server side rejects the push and report
> back approp
On Tue, Oct 15, 2019 at 03:31:26AM +, Norman Rasmussen via GitGitGadget
wrote:
> From: Norman Rasmussen
>
> This changes the indent from
> ""
> to
> ""
> so that the statement lines up with the rest of the block.
Yep, that makes sense. Looks like I introduced the problem (most of my
pe
On Sat, Oct 12, 2019 at 09:04:58AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > The current code does so by creating a new entry in the reused_chunks
> > array. In the worst case that can grow to have the same number of
> > entries as we have objects. So thi
On Thu, Oct 10, 2019 at 11:16:24AM -0700, Denton Liu wrote:
> > test_expect_success 'log --graph with normal octopus merge, no color' '
>
> So, I decided to merge 'dl/octopus-graph-bug' with your branch and I
> couldn't be happier! I had to make a couple of minor tweaks to the
> existing test ca
On Thu, Oct 10, 2019 at 09:13:42AM -0700, James Coglan via GitGitGadget wrote:
> A final addition to that set of changes fixes the coloring of dashes that
> are drawn next to octopus merges, in a manner compatible with all these
> changes. The early commits in this set are refactorings that make t
On Fri, Oct 11, 2019 at 06:04:21PM +0100, James Coglan wrote:
> > I should have noticed in your earlier commits, but why don't you keep
> > the output inside the test suite? You can start with "cat >expect <<-EOF"
> > to have it ignore leading whitespace. Sorry if there's something else about
> >
On Sat, Oct 12, 2019 at 06:31:02PM -0400, Teddy Reed wrote:
> Hello, I am trying to debug an issue where a shallow clone (--depth=1)
> fails when the reference is the tip of a tag on a GitHub repository.
>
> The git client works on versions below 2.22.0-rc0 up until commit
> 34066f06, "fetch: do
On Fri, Oct 11, 2019 at 03:10:33PM -0500, Brent Casavant wrote:
> I noticed what appears to be a bug in rev-parse with an admittedly
> somewhat unusual combination of arguments.
>
> Compare the output of the following:
>
> % git rev-parse HEAD --not --remotes=origin
> 3de09080eb219149a8596dc2191
On Fri, Oct 11, 2019 at 09:49:53AM +0200, Christian Couder wrote:
> > I think this should be squashed with patch 3, adding to that commit
> > message "since word_alloc might be 0, we need to change the growth
> > function". (Or just make the minimum word_alloc be 1 or 32 or something
> > positive,
On Thu, Oct 10, 2019 at 04:59:52PM -0700, Jonathan Tan wrote:
> > +/*
> > + * Record the offsets needed in our reused packfile chunks due to
> > + * "gaps" where we omitted some objects.
> > + */
> > +static struct reused_chunk {
> > + off_t start;
> > + off_t offset;
> > +} *reused_chunks;
>
On Fri, Oct 11, 2019 at 08:31:30AM -0400, Derrick Stolee wrote:
> >> Ensure that these lazy fetches do not occur.
> >
> > That makes sense. For similar reasons, should we be using
> > OBJECT_INFO_QUICK here? If the other side has a bunch of ref tips that
> > we don't have, we'll end up re-scannin
On Fri, Oct 11, 2019 at 05:02:33PM +0100, Philip Oakley wrote:
> Another case, of a different style, is that of `git bundle --all` which does
> need mentioning that particular rev-list option as a major usage (I couldn't
> manage to understand the three layers of man page that needed reading).
>
On Sat, Oct 12, 2019 at 02:42:49AM +1100, Daniel Axtens wrote:
> >> where a possible solution was to get senders to use in-body From
> >> headers even when sending their own patches.
> [...]
> I'm not sure this solution is correct.
>
> If I take a patch from Andrew, backport it, and send to the l
On Wed, Oct 09, 2019 at 07:25:51PM +0200, SZEDER Gábor wrote:
> > Probably they'd be easy enough to fix (and they're out of tree anyway),
> > so I'm not really arguing against the escape hatch exactly. Mostly I'm
> > just surprised that if I introduced 3 cases (out of probably a dozen
> > scripts)
On Wed, Oct 09, 2019 at 11:28:51AM -0400, Joey Hess wrote:
> > I suspect it's not entirely sufficient for clean input, though. You're
> > not feeding filenames but rather full "object names". I wouldn't be
> > surprised if we mis-parse "$rev:$path" when $path has "@{}" or similar
> > in it.
>
> N
On Tue, Oct 08, 2019 at 11:37:39AM -0700, Jonathan Tan wrote:
> When building the packfile to be sent, send_pack() is given a list of
> remote refs to be used as exclusions. For each ref, it first checks if
> the ref exists locally, and if it does, passes it with a "^" prefix to
> pack-objects. Ho
On Fri, Oct 04, 2019 at 05:13:08PM -0700, Denton Liu wrote:
> The synopsis section in git-rev-list.txt has grown to be a huge list
> that probably needs its own synopsis. Since the list is huge, users may
> be given the false impression that the list is complete, however it is
> not. It is missing
On Fri, Oct 11, 2019 at 01:39:28PM +0900, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > ... but I'd still wait for a few
> > days for people who expressed their Acks but your scan missed, or
> > those who wanted to give their Acks but forgot to do so, to raise
> > their hands on this thre
On Thu, Oct 10, 2019 at 12:18:53AM +, Eric Wong wrote:
> > The project leadership team can be contacted by email as a whole at
> > g...@sfconservancy.org, or individually:
> >
> > - Ævar Arnfjörð Bjarmason
> > - Christian Couder
> > - Jeff King
&g
On Fri, Oct 11, 2019 at 10:01:23AM +1100, Andrew Donnellan wrote:
> > This might provide an alternate solution (or vice versa). I kind of like
> > this one better in that it doesn't require the sender to do anything
> > differently (but it may be less robust, as it assumes the receiver
> > reliabl
On Thu, Oct 10, 2019 at 12:41:32PM -0700, Jonathan Nieder wrote:
> > Add support for using the X-Original-Sender or Reply-To headers, as used by
> > Google Groups and Mailman respectively, to unmangle the From header when
> > necessary.
> [...]
> Interesting! I'm cc-ing the Git mailing list in ca
On Thu, Oct 10, 2019 at 10:49:23AM +0200, Toon Claes wrote:
> > Yeah, I'd agree that we should start first with a generic trailer line.
>
> IIUC you are suggesting something like this?
>
> git commit --trailer="Co-authored-by: "
>
> I really want to consider this, but I do not understand how t
On Tue, Oct 08, 2019 at 11:27:52AM -0700, Johannes Schindelin via GitGitGadget
wrote:
> From: Johannes Schindelin
>
> Inspired by the thoroughly stale https://github.com/git/git/pull/159,
> this patch fixes a couple of typos, rewraps and clarifies some comments.
>
> Signed-off-by: Johannes Sch
On Wed, Oct 09, 2019 at 11:19:47AM +0900, Junio C Hamano wrote:
> > I wonder how we are supposed to use this trailer in the Git project,
> > in particular in combination with Signed-off-by. Should all
> > (co)authors sign off as well? Or will Co-authored-by imply
> > Signed-off-by?
>
> I think
On Tue, Oct 08, 2019 at 03:22:57PM -0400, Joey Hess wrote:
> I'm surprised to find that git cat-file --batch, on a Linux system,
> strips the \r from an input like "HEAD:foo\r\n"
>
> It's obvious, of course, that it will remove the newline, and so this
> interface cannot be used to query about a
On Sun, Sep 22, 2019 at 02:36:37AM +0400, Alicenab wrote:
> Hi there!
> I have a translated ProGit2 book to Azerbaijan language.
> As code of country name name for our country(az) have already taken, I have
> created "aze" version of it.
> I hope it will be no problem for you.
> Partial translatio
On Thu, Sep 05, 2019 at 11:39:26AM -0700, Jonathan Tan wrote:
> > I'm not really opposed to what you're doing here, but I did recently
> > think of another possible use for .promisor files. So it seems like a
> > good time to bring it up, since presumably we'd have to choose one or
> > the other.
On Fri, Sep 13, 2019 at 08:06:01PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Fri, Sep 13, 2019 at 03:29:00PM -0700, Junio C Hamano wrote:
> >
> >> This comment has nothing to do with the change, but the way the
> >> patch is presented
On Mon, Sep 16, 2019 at 10:54:10PM +0200, SZEDER Gábor wrote:
> > Yes on that final bit. We could always fall back to (4) if the terminal
> > information is not available, but given that the benefit is mostly in
> > simplifying the code, I don't know if it's worth carrying around _two_
> > solutio
custom flags can be used.
>
> Helped-by: Jeff King
> Signed-off-by: Denton Liu
> ---
>
> Peff, thanks for the suggestion! I modified it a little bit so that we
> wouldn't have to keep regenerating the *.hcc files unnecessarily.
What you have here looks good. I doubt it
we probably can't just change this value, since callers will
be feeding us a certain number of X's, but it hopefully makes the
function itself easier to follow.
While we're here, let's do the same with the "letters" array (which we
_could_ modify if we wanted to include mo
On Wed, Oct 02, 2019 at 03:10:12PM +0200, Martin Nicolay wrote:
> I don't know if this is a lack of understanding or a software or
> documentation bug.
>
> man git-fetch says about tags:
>By default, any tag that points into the histories being fetched is
>also fetched; the effect
On Tue, Oct 01, 2019 at 01:33:10AM +0200, Ali Utku Selen wrote:
> Fix possible segfault when cloning a submodule shallow.
Thanks. Just looking at the context, this is clearly the right thing to
be doing.
> It is possible to have unallocated slabs in shallow.c's commit_depth
> for a shallow submo
On Mon, Sep 30, 2019 at 11:58:49PM -0700, Elijah Newren wrote:
> In commit 743474cbfa8b ("merge-recursive: provide a better label for
> diff3 common ancestor", 2019-08-17), the label for the common ancestor
> was changed from always being
>
> "merged common ancestors"
>
> to instead be
cases of promisor_remote_move_to_tail() where r is not already
> at the tail of the list, it works as before.
>
> Helped-by: Jeff King
> Signed-off-by: Emily Shaffer
> ---
> Fixed up some nits from Peff in v2. Thanks especially for the catch on
> capturing the output o
On Mon, Sep 30, 2019 at 05:14:37PM -0400, Jeff King wrote:
> > This chosen label was perfectly reasonable when recursiveness kicks in,
> > i.e. when there are multiple merge bases. (I can't think of a better
> > label in such cases.) But it is actually somewhat mislead
On Sat, Aug 17, 2019 at 11:41:24AM -0700, Elijah Newren wrote:
> In commit 7ca56aa07619 ("merge-recursive: add a label for ancestor",
> 2010-03-20), a label was added for the '||' line to make it have
> the more informative heading '|| merged common ancestors', with
> the statement:
>
>
On Thu, Sep 26, 2019 at 11:44:48PM +0200, SZEDER Gábor wrote:
> All that was over a year and a half ago, and these limitations weren't
> a maintenance burden at all so far, and nobody needed that escape
> hatch.
>
> Well, nobody except me, that is :) When I saw back then that t1510
> saves the s
On Wed, Sep 25, 2019 at 05:33:00PM -0700, Jonathan Tan wrote:
> 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.
> [..]
> Searching reveals [2], but I don't thi
On Thu, Sep 26, 2019 at 03:12:15PM +0200, Christian Couder wrote:
> On https://www.outreachy.org/apply/project-selection/#git it looks
> like we will only have 1 intern as the title of our section is "Git -
> 1 intern". I wonder if it's because only funding for 1 intern has been
> secured or if th
On Thu, Sep 26, 2019 at 10:14:17PM +0200, Johannes Schindelin wrote:
> I mean, if there is _any_ performance-critical code path hitting this
> unrolled loop, we may want to keep it unrolled.
The loop in question is maybe a few dozen instructions, and then it
immediately makes an open() syscall, w
value, since callers will
be feeding us a certain number of X's, but it hopefully makes the
function itself easier to follow.
While we're here, let's do the same with the "letters" array (which we
_could_ modify if we wanted to include more characters).
Signed-off-by:
based on Peff's reproduction steps (thanks!) and
> confirmed it failed before the patch, exiting gracelessly with a
> SIGABRT, and now fails gracefully (and passes test_must_fail condition).
Thanks, this is looking good, though I have a few nits.
> Signed-off-by: Emily Shaffer
On Thu, Sep 26, 2019 at 04:20:05PM +0200, Alejandro Sanchez wrote:
> Are there any updates to this problem?
The fix for the original bug went into Git v2.22.1.
-Peff
On Wed, Sep 25, 2019 at 10:09:02AM -0700, Denton Liu wrote:
> 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 cas
1 - 100 of 15671 matches
Mail list logo
