Jeff King writes:
> This patch series started with patch 12: I just wanted to drop the
> unused "force" parameter from update_info_refs().
>
> But that made me look at its sibling update_info_packs(), and whether it
> ...
> And here we are. I present them here in reverse rabbit-hole order (which
Christian Couder writes:
> Hi Ramsay,
>
> On Thu, Apr 4, 2019 at 8:59 PM Ramsay Jones
> wrote:
>
>> If you need to re-roll your 'cc/multi-promisor' branch, could you
>> please squash this into the relevant patch (commit e52d417b57
>> ("promisor-remote: implement promisor_remote_get_direct()", 2
Todd Zullinger writes:
> Martin mentioned this in reply to the patch thread¹ but it
> looks like it slipped by unnoticed. There's some extraneous
> comments in 28216d13f4 ("ci: stick with Asciidoctor v1.5.8
> for now", 2019-03-29) which would be good to trim before
> this hits next.
Thanks.
Elijah Newren writes:
> I'm slightly in favor of the tag.forbidTaggingAnythingButCommits
> route. Two reasons:
>
> * Even core git commands can't handle these properly after more than
> a decade, making me suspect that tools in the greater git ecosystem
> are going to fail to handle them too.
Julian Andres Klode writes:
>> What Thomas Found out was that the exact same email with
>>
>> Message-Id/From/Date/Subject/To
>>
>> (in that order) does not work, but
>>
>> Date/From/Subject/To/Message-Id
>>
>> does work. Weird and "wonderful". But there might be a lot of other
>> ord
Apply similar treatment as the previous commit for non-tree entries,
too.
Signed-off-by: Taylor Blau
---
list-objects.c | 5 +
t/t6102-rev-list-unexpected-objects.sh | 5 +++--
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/list-objects.c b/list-object
From: Jeff King
Return NULL from 'get_commit_tree()' when a commit's root tree is
corrupt, doesn't exist, or points to an object which is not a tree.
In [1], this situation became a BUG(), but it can certainly occur in
cases which are not a bug in Git, for e.g., if a caller manually crafts
a com
Hi everybody,
Peff pointed out to me a couple of weeks ago that we could reproducibly
crash Git when doing the following:
$ git rev-list --objects
Where is a normal blob, and is a tree which
contains an entry that refers to but gives it a type other than
'blob'. (This is described in deta
Fix one of the cases described in the previous commit where a tree-entry
that is promised to a blob is in fact a non-blob.
When 'lookup_blob()' returns NULL, it is because Git has cached the
requested object as a non-blob. In this case, prevent a SIGSEGV by
'die()'-ing immediately before attemptin
Call an object's type "unexpected" when the actual type of an object
does not match Git's contextual expectation. For example, a tree entry
whose mode differs from the object's actual type, or a commit's parent
which is not another commit, and so on.
This can manifest itself in various unfortunate
The helper 'hex2oct' is used to convert base-16 encoded data into a
base-8 binary form, and is useful for preparing data for commands that
accept input in a binary format, such as 'git hash-object', via
'printf'.
This helper is defined identically in three separate places throughout
't'. Move the
From: Jeff King
When the traversal machinery sees a commit without a root tree, it
assumes that the tree was part of a BOUNDARY commit, and quietly ignores
the tree. But it could also be caused by a commit whose root tree is
broken or missing.
Instead, let's die() when we see a NULL root tree. W
From: Jeff King
Commit 7c0fe330d5 (rev-list: handle missing tree objects properly,
2018-10-05) taught the traversal machinery used by git-rev-list to
ignore missing trees, so that rev-list could handle them itself.
However, it does so only by checking via oid_object_info_extended() that
the obje
On Thu, Apr 4, 2019 at 4:50 PM Junio C Hamano wrote:
>
> Robert Dailey writes:
>
> > It might be fine within the realm of git itself, because git knows how
> > to deal with them by peeling, as you say, but there are 3 reasons I
> > dislike that this is allowed:
>
> That sounds as if you have tool
brian m. carlson wrote:
> On Sat, Mar 30, 2019 at 02:00:14PM -0400, Todd Zullinger wrote:
>> Thanks for the very useful docbook5/xmlto details!
>>
>> The hard-coded use of the non-namespaced stylesheets in
>> xmlto is unfortunate. I hadn't gotten far enough along to
>> run into that limitation of
On Thu, Apr 04, 2019 at 09:41:10PM -0400, Jeff King wrote:
> On Fri, Apr 05, 2019 at 01:44:09AM +0100, Ramsay Jones wrote:
>
> >
> >
> > On 05/04/2019 00:22, Jeff King wrote:
> > > There's no such argument as "--unordered"; it's spelled "--unsorted".
> >
> > Err, isn't this back-to-front? (i.e
On Fri, Apr 05, 2019 at 01:44:09AM +0100, Ramsay Jones wrote:
>
>
> On 05/04/2019 00:22, Jeff King wrote:
> > There's no such argument as "--unordered"; it's spelled "--unsorted".
>
> Err, isn't this back-to-front? (i.e. cat-file has the _option_
> "--unordered" but not "--unsorted").
Oops, ye
Hi,
Martin Ågren wrote:
> On Sat, 30 Mar 2019 at 19:30, Todd Zullinger wrote:
>>
>> Just chipping away at the remaining differences between asciidoc and
>> asciidoctor.
>>
>> Todd Zullinger (2):
>> Documentation/rev-list-options: wrap --date= block with "--"
>> Documentation/git-status: fix t
Hi,
Jeff Hostetler wrote:
> On 3/30/2019 2:30 PM, Todd Zullinger wrote:
>> The '^### ' lines were added in 1cd828ddc8 ("git-status.txt: describe
>> --porcelain=v2 format", 2016-08-11). I'm _presuming_ they were made
>> with markdown syntax in mind, but if not I can drop that bit from the
>> commi
Jeff King wrote:
> On Sat, Mar 30, 2019 at 02:30:01PM -0400, Todd Zullinger wrote:
>
>> Asciidoc uses either one-line or two-line syntax for document/section
>> titles[1]. The two-line form is used in git-status. Fix a few section
>> titles in the porcelain v2 section which were inadvertently us
Hi,
Jeff King wrote:
> On Sat, Mar 30, 2019 at 02:30:00PM -0400, Todd Zullinger wrote:
>
>> Using "+" to continue multiple list items is more tedious and
>> error-prone than wrapping the entire block with "--" block markers.
>>
>> When using asciidoctor, the list items after the --date=iso list
Hi Junio,
Junio C Hamano wrote:
> * sg/asciidoctor-in-ci (2019-04-01) 6 commits
> - ci: fix AsciiDoc/Asciidoctor stderr check in the documentation build job
> - ci: stick with Asciidoctor v1.5.8 for now
> - ci: install Asciidoctor in 'ci/install-dependencies.sh'
> - Documentation/technical/pro
On Mon, Apr 01, 2019 at 06:40:43PM +0200, Christian Couder wrote:
> From: Christian Couder
>
> This shows that it is now possible to fetch objects from more
> than one promisor remote, and that fetching from a new
> promisor remote can configure it as one.
>
> Signed-off-by: Christian Couder
>
Ever since the progress infrastructure was introduced in 96a02f8f6d
(common progress display support, 2007-04-18), display_progress() has
returned an int, telling callers whether it updated the progress bar
or not. However, this is:
- useless, because over the last dozen years there has never b
The following patches in this series want to handle the progress bar's
title and changing parts (i.e. the counter and the optional percentage
and throughput combined) differently, and need to know the length
of the changing parts of the previously displayed progress bar.
To prepare for those chang
This patch series fixes two progress display issues by breaking
progress bars longer than the width of the terminal and by properly
cleaning up the previously shown progress bar.
Changes since v2, following Eric's and Peff's suggestions:
- Remove return statements that just became unnecessary i
When the progress bar includes throughput, its length can shorten as
the unit of display changes from KiB to MiB. To cover up remnants of
the previous progress bar when such a change of units happens we
always print three spaces at the end of the progress bar.
Alas, covering only three characters
Some of the recently added progress indicators have quite long titles,
which might be even longer when translated to some languages, and when
they are shown while operating on bigger repositories, then the
progress bar grows longer than the default 80 column terminal width.
When the progress bar e
On 05/04/2019 00:22, Jeff King wrote:
> There's no such argument as "--unordered"; it's spelled "--unsorted".
Err, isn't this back-to-front? (i.e. cat-file has the _option_
"--unordered" but not "--unsorted").
I suspect that I am not reading that right! :-D
ATB,
Ramsay Jones
On Thu, Apr 4, 2019 at 2:31 AM Junio C Hamano wrote:
>
> Jeff King writes:
>
> > I do still think it is likely to be a mistake. I think Junio's point,
> > though is: who cares if the mistake was made? For the most part you can
> > continue to use the tag as if the mistake had never been made, bec
On 2019.04.04 20:00, Jeff King wrote:
> On Thu, Apr 04, 2019 at 04:47:26PM -0700, Josh Steadmon wrote:
>
> > > Did you (or anybody else) have any thoughts on the case where a given
> > > object is referred to both by a promisor and a non-promisor (and we
> > > don't have it)? That's the "shortcut"
On Thu, Apr 04, 2019 at 04:47:26PM -0700, Josh Steadmon wrote:
> > Did you (or anybody else) have any thoughts on the case where a given
> > object is referred to both by a promisor and a non-promisor (and we
> > don't have it)? That's the "shortcut" I think we're taking here: we
> > would no long
On 2019.04.04 19:08, Jeff King wrote:
> On Thu, Apr 04, 2019 at 03:53:56PM -0700, Josh Steadmon wrote:
>
> > For large repositories, enumerating the list of all promisor objects (in
> > order to exclude them from a rev-list walk) can take a significant
> > amount of time).
> >
> > When --exclude-
When writing objects/info/packs, we use the basename of each pack
(i.e., just the "pack-1234abcd.pack" part). We compute that manually by
adding "objdirlen + 6" to the name.
This _should_ work consistently, as we do not include non-local packs,
meaning everything should be in $objdir/pack/. Before
Once upon a time the force flag meant something when writing info/refs,
but it hasn't done anything since 60d0526aaa (Unoptimize info/refs
creation., 2005-09-14).
Signed-off-by: Jeff King
---
server-info.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/server-info.c b/se
As CodingGuidelines recommends, we do not need an "extern" when
declaring a public function. Let's drop these. Note that we leave the
extern on report_garbage(), as that is actually a function pointer, not
a function itself.
Signed-off-by: Jeff King
---
I hesitated on this one, because it does ha
We keep an array of struct pointers, with each one representing a single
packfile. But for some reason there is a nr_alloc parameter inside each
struct, which has never been used.
This is probably cruft left over from development, where we might have
wanted a nr_alloc to dynamically grow the list.
This old code uses fgets with a fixed-size buffer. Let's use a strbuf
instead, so we don't have to wonder if "1000" is big enough, or what
happens if we see a long line.
This also lets us drop our custom code to trim the newline.
Probably nobody actually cares about the 1000-char limit (after all
When we're writing out a new objects/info/packs file, we read back the
old one to try to keep the ordering the same. When we see a line
starting with "P", we expect "P pack-1234..." and blindly jump to "line
+ 2" to parse the pack name. If we saw a line with _just_ "P" and
nothing else, we'd jump p
We have two exits from the function: either we jump to the out_stale
label or not. But in both exits we repeat our cleanup, and the only
difference is our return value. Let's just use a variable for the return
value to avoid repeating ourselves.
Signed-off-by: Jeff King
---
server-info.c | 7 +++
We can use skip_prefix() and parse_oid_hex() to continuously increment
our pointer, rather than dealing with magic numbers. This also fixes a
few small shortcomings:
- if we see a 'P' line that does not match our expectations, we'll
leave our "i" counter in the middle of the line. So we'll p
When we have a .midx that covers many packfiles, we try to avoid opening
the .idx for those packfiles. However, there are a few problems with the
filename comparison we use:
- we ask midx_contains_pack() about the .pack name, not the .idx name.
But it compares to the latter.
- we compute
When we open a pack .idx, we have to convert the "foo.pack" name stored
in the packed_git struct to "foo.idx". This isn't too complicated, but
we do encode some policy in the form of a BUG(). Let's pull this into
its own function so it can be reused.
Signed-off-by: Jeff King
---
packfile.c | 14
The cat-file --buffer option is the default already when using
--batch-all-objects. It doesn't hurt to specify it, but it's nice for
the test scripts to model good usage.
Signed-off-by: Jeff King
---
t/t5319-multi-pack-index.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --gi
There's no such argument as "--unordered"; it's spelled "--unsorted".
But our test failed to notice that cat-file didn't run at all because:
1. It lost the exit code of git on the left-hand side of a pipe.
2. It was comparing two runs of the broken invocation with and without
a particula
This patch series started with patch 12: I just wanted to drop the
unused "force" parameter from update_info_refs().
But that made me look at its sibling update_info_packs(), and whether it
needs its force parameter. It _does_ in fact do something (though I am
slightly doubtful that anybody actual
On Thu, Apr 04, 2019 at 03:53:56PM -0700, Josh Steadmon wrote:
> For large repositories, enumerating the list of all promisor objects (in
> order to exclude them from a rev-list walk) can take a significant
> amount of time).
>
> When --exclude-promisor-objects is passed to rev-list, don't enumer
For large repositories, enumerating the list of all promisor objects (in
order to exclude them from a rev-list walk) can take a significant
amount of time).
When --exclude-promisor-objects is passed to rev-list, don't enumerate
the promisor objects. Instead, filter them (and any children objects)
On Fri, Apr 05, 2019 at 06:54:06AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > but you have to take pretty specific steps to get a tag of a blob or
> > tree, like:
> >
> > git tag mytag HEAD:path
> >
> > or
> >
> > git tag mytag HEAD^{tree}
>
> And the way to ask for commit and t
Hi Ramsay,
On Thu, Apr 4, 2019 at 8:59 PM Ramsay Jones wrote:
> If you need to re-roll your 'cc/multi-promisor' branch, could you
> please squash this into the relevant patch (commit e52d417b57
> ("promisor-remote: implement promisor_remote_get_direct()", 2019-04-01)).
>
> [I had a deja-vu momen
Jeff King writes:
> but you have to take pretty specific steps to get a tag of a blob or
> tree, like:
>
> git tag mytag HEAD:path
>
> or
>
> git tag mytag HEAD^{tree}
And the way to ask for commit and tag are
git tag mytag master
git tag mytag v1.0.0
I do not see why only the last
Robert Dailey writes:
> It might be fine within the realm of git itself, because git knows how
> to deal with them by peeling, as you say, but there are 3 reasons I
> dislike that this is allowed:
That sounds as if you have tools that forgets to peel when it should
in mind. Isn't that what you
Duy Nguyen writes:
> On Thu, Apr 4, 2019 at 5:29 PM Junio C Hamano wrote:
>> * nd/precious (2019-04-01) 1 commit
>> - Introduce "precious" file concept
>>
>> "git clean" learned to pay attention to the 'precious' attributes
>> and keep untracked paths with the attribute instead of removing.
>
On Mon, Apr 01, 2019 at 01:51:57PM -0700, Denton Liu wrote:
> Signed-off-by: Denton Liu
> ---
> t/t3431-rebase-fork-point.sh | 53
> 1 file changed, 53 insertions(+)
> create mode 100755 t/t3431-rebase-fork-point.sh
>
> diff --git a/t/t3431-rebase-fork-point
Signed-off-by: Ramsay Jones
---
Hi Christian,
If you need to re-roll your 'cc/multi-promisor' branch, could you
please squash this into the relevant patch (commit e52d417b57
("promisor-remote: implement promisor_remote_get_direct()", 2019-04-01)).
[I had a deja-vu moment writing this - it see
Robert Dailey reported confusion on the mailing list about a nested tag
which was most likely created by mistake. Jeff King noted that this
isn't a very common case so, most likely, creating a tag-to-a-tag is a
user-error.
Prevent mistakes by providing advice on nested tags. Add tests to ensure
th
[ Sorry for the spam, I typoed the mailing list address the first time ]
Hi all,
I've been following the discussion and the tl;dr of it seems to be this:
Junio wants to keep the long-standing behaviour of being able to git tag
anything while Robert seems to believe that for most users, it is a
mi
Wrap usage line at ''. Also, wrap strings with '\n' at the end
of string fragments instead of at the beginning of the next string
fragment.
Convert a space-indent into a tab-indent for style.
Signed-off-by: Denton Liu
---
builtin/tag.c | 9 +
1 file changed, 5 insertions(+), 4 deletions
On Fri, Mar 15, 2019 at 09:59:25AM -0700, Linus Torvalds wrote:
> On Thu, Mar 14, 2019 at 9:47 PM Junio C Hamano wrote:
> >
> > Linus Torvalds writes:
> >
> > > While it's true that header ordering isn't specified, there's a common
> > > "canonical" order that the headers are listed in. To quote
On Wed, Apr 03, 2019 at 06:34:26PM +0700, Nguyễn Thái Ngọc Duy wrote:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> builtin/rebase.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/builtin/rebase.c b/builtin/rebase.c
> index 77deebc65c..c064909329 100644
> --- a/bui
On Wed, Apr 03, 2019 at 06:34:35PM +0700, Nguyễn Thái Ngọc Duy wrote:
> Signed-off-by: Nguyễn Thái Ngọc Duy
Oh, look, an empty commit message ;)
> ---
> commit.c| 5 +++--
> commit.h| 3 ++-
> contrib/coccinelle/commit.cocci | 4 ++--
> 3 files ch
On Wed, Apr 03, 2019 at 12:02:07PM -0400, Barret Rhoden wrote:
> diff --git a/blame.c b/blame.c
> index c06cbd906658..50511a300059 100644
> --- a/blame.c
> +++ b/blame.c
> @@ -915,27 +915,109 @@ static int are_lines_adjacent(struct
> blame_line_tracker *first,
> first->s_lno + 1 == se
BOMPARD CORENTIN p1603631 writes:
> Adding the --set-upstream option to git pull/fetch
We usually write commit messages with imperative tone, hence "add", not
"adding".
> + /*
> + * We want to set the current branch config following the
> + * ref_map entry
On Thu, Apr 4, 2019 at 8:56 AM Robert Dailey wrote:
>
> On Thu, Apr 4, 2019 at 7:06 AM Jeff King wrote:
> >
> > On Wed, Apr 03, 2019 at 08:26:06PM -0700, Taylor Blau wrote:
> >
> > > Agreed.
> > >
> > > I think that the implement is a little different than "add a --no-edit"
> > > flag, though. 'g
On Thu, Apr 4, 2019 at 7:06 AM Jeff King wrote:
>
> On Wed, Apr 03, 2019 at 08:26:06PM -0700, Taylor Blau wrote:
>
> > Agreed.
> >
> > I think that the implement is a little different than "add a --no-edit"
> > flag, though. 'git tag' already has a OPT_BOOL for '--edit', which means
> > that '--no
On Thu, Apr 4, 2019 at 4:32 AM Junio C Hamano wrote:
>
> Robert Dailey writes:
>
> >> > more clear in the doc and/or in the proposed log message what
> >> > practical downside there are to the end users if we do not stop this
> >> > "mistake", that is.
> >>
> >> Having said all that, I can sort-o
On Thu, Apr 04, 2019 at 06:31:25PM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > I do still think it is likely to be a mistake. I think Junio's point,
> > though is: who cares if the mistake was made? For the most part you can
> > continue to use the tag as if the mistake had never been
Adding the --set-upstream option to git pull/fetch
which lets the user set the upstream configuration
for the current branch.
For example a typical use-case like
git clone http://example.com/my-public-fork
git remote add main http://example.com/project-main-repo
git pull main master --
On Thu, Apr 04, 2019 at 11:42:23AM +0200, Rasmus Villemoes wrote:
> My ack for Baruch's original patch, which AFAICT is identical with
> Junio's suggestion, still stands. FWIW, I'm against Joe's suggestion of
> stopping at a line matching /^---/, since it's not unlikely somebody
> does something l
ср, 3 апр. 2019 г. в 22:54, Kapil Jain :
>
> Reference:
> https://git.github.io/SoC-2019-Ideas/#unify-ref-filter-formats-with-other---pretty-formats
>
> I have spent some time with both pretty.* and ref-filter.*
>
> First off, we are aiming to reuse ref-filter, so avoiding any sort of
> re-impleme
On Wed, Apr 03, 2019 at 08:26:06PM -0700, Taylor Blau wrote:
> Agreed.
>
> I think that the implement is a little different than "add a --no-edit"
> flag, though. 'git tag' already has a OPT_BOOL for '--edit', which means
> that '--no-edit' exists, too.
>
> But, when we look and see how the edit
On Thu, Apr 04, 2019 at 06:13:16PM +0900, Junio C Hamano wrote:
> >> Similar to git commit, it would be nice to have a --no-edit option for
> >> git tag. Use case is when I force-recreate a tag:
> >>
> >> $ git tag -af 1.0 123abc
> >>
> >> An editor will be prompted with the previous annotated t
On Thu, Apr 4, 2019 at 5:29 PM Junio C Hamano wrote:
> * nd/precious (2019-04-01) 1 commit
> - Introduce "precious" file concept
>
> "git clean" learned to pay attention to the 'precious' attributes
> and keep untracked paths with the attribute instead of removing.
>
> Will merge to 'next'.
T
What's cooking in git.git (Apr 2019, #01; Thu, 4)
--
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in
Baruch Siach writes:
> Since commit ef0cc1df90f6b ("send-email: also pick up cc addresses from
> -by trailers") in git version 2.20, git send-email adds to cc list
> addresses from all *-by lines. As a side effect a line with
> '-Signed-off-by' is now also added to cc. This makes send-email pick
Rasmus Villemoes writes:
> My ack for Baruch's original patch, which AFAICT is identical with
> Junio's suggestion, still stands. FWIW, I'm against Joe's suggestion of
> stopping at a line matching /^---/, since it's not unlikely somebody
> does something like
>
> dmesg output
> bla bla
On 04/04/2019 11.27, Baruch Siach wrote:
> Hi Junio,
>
> On Thu, Apr 04 2019, Junio C. Hamano wrote:
>> Baruch Siach writes:
>>
Independently, I think it makes sense to do something like
/^([a-z][a-z-]*-by|Cc): (.*)/i
to tighten the match to exclude a non-trailer; that
Baruch Siach writes:
> Hi Junio,
>
> On Thu, Apr 04 2019, Junio C. Hamano wrote:
>> Baruch Siach writes:
>>
Independently, I think it makes sense to do something like
/^([a-z][a-z-]*-by|Cc): (.*)/i
to tighten the match to exclude a non-trailer; that would have been
>>
Robert Dailey writes:
>> > more clear in the doc and/or in the proposed log message what
>> > practical downside there are to the end users if we do not stop this
>> > "mistake", that is.
>>
>> Having said all that, I can sort-of see that it may make sense to
>> forbid tagging anything but a comm
Jeff King writes:
> I do still think it is likely to be a mistake. I think Junio's point,
> though is: who cares if the mistake was made? For the most part you can
> continue to use the tag as if the mistake had never been made, because
> Git peels through multiple layers as necessary.
Nicely sa
Hi Junio,
On Thu, Apr 04 2019, Junio C. Hamano wrote:
> Baruch Siach writes:
>
>>> Independently, I think it makes sense to do something like
>>>
>>> /^([a-z][a-z-]*-by|Cc): (.*)/i
>>>
>>> to tighten the match to exclude a non-trailer; that would have been
>>> sufficient for the original case
Baruch Siach writes:
>> Independently, I think it makes sense to do something like
>>
>> /^([a-z][a-z-]*-by|Cc): (.*)/i
>>
>> to tighten the match to exclude a non-trailer; that would have been
>> sufficient for the original case that triggered this thread.
>
> Is there anything I need to do
Jeff King writes:
> On Wed, Apr 03, 2019 at 09:38:02AM -0500, Robert Dailey wrote:
>
>> Similar to git commit, it would be nice to have a --no-edit option for
>> git tag. Use case is when I force-recreate a tag:
>>
>> $ git tag -af 1.0 123abc
>>
>> An editor will be prompted with the previous a
Hi,
On Tue, Apr 2, 2019 at 10:34 PM Khalid Ali wrote:
>
> My name is Khalid Ali and I am looking to convert the git-submodule to
> a builtin C script. The link below contains my first proposal draft
> [1] and my microproject is at [2]. My main concern is that my second
> task is not verbose enoug
On Wed, Apr 3, 2019 at 6:15 PM Mark Kharitonov
wrote:
> C:\Dayforce\56 [release/r-856 ≡]> git --version
> git version 2.18.0.windows.1
> C:\Dayforce\56 [release/r-856 ≡]> git worktree list
> [...]
> C:/Dayforce/56 f9c36d3a2b [release/r-856]
> C:/Dayforce/56 f9c36d3a2b [release/r-856]
>
> I
On Thu, Apr 04, 2019 at 09:56:35AM +0200, Christian Couder wrote:
> Hi,
>
> On Thu, Apr 4, 2019 at 3:15 AM Matheus Tavares Bernardino
> wrote:
> >
> > I've been studying the codebase and looking for older emails in the ML
> > that discussed what I want to propose as my GSoC project. In
> > partic
On Thu, Apr 4, 2019 at 12:08 AM SZEDER Gábor wrote:
>
> On Mon, Apr 01, 2019 at 06:40:36PM +0200, Christian Couder wrote:
> > diff --git a/promisor-remote.c b/promisor-remote.c
> > new file mode 100644
> > index 00..0c768210ee
> > --- /dev/null
> > +++ b/promisor-remote.c
> > @@ -0,0 +1,92
On Thu, Apr 4, 2019 at 9:23 AM Junio C Hamano wrote:
>
> Christian Couder writes:
>
> > This path series is a follow up from the "remote odb" patch series
> > that I sent last year, which were a follow up from previous
> > series. See the links section for more information.
>
> When this topic ge
Hi,
On Thu, Apr 4, 2019 at 3:15 AM Matheus Tavares Bernardino
wrote:
>
> I've been studying the codebase and looking for older emails in the ML
> that discussed what I want to propose as my GSoC project. In
> particular, I found a thread about slow git commands on chromium, so I
> reached them ou
Hi Junio,
On Mon, Mar 18 2019, Junio C. Hamano wrote:
> Joe Perches writes:
>
>> My preference would be for correctness.
>> I presume something like this isn't too onerous.
>
> I am guessing that /^---/ is to stop at the three-dash line *OR*
> after the initial handful of lines of the first diff
Teach difftool and mergetool about the Sublime Merge "smerge" command.
Signed-off-by: David Aguilar
---
git-mergetool--lib.sh | 1 +
mergetools/smerge | 12
2 files changed, 13 insertions(+)
create mode 100644 mergetools/smerge
diff --git a/git-mergetool--lib.sh b/git-mergeto
Signed-off-by: David Aguilar
---
contrib/completion/git-completion.bash | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 976e4a6548..b6d69bcaeb 100644
--- a/contrib/completion/git-completio
Kyle Meyer writes:
> When the path given to 'git submodule add' is an existing repository
> that is not in the index, the repository is passed to 'git add'. If
> this repository doesn't have any commits, we don't get a useful
> result: there is no subproject OID to track, and any untracked files
Christian Couder writes:
> This path series is a follow up from the "remote odb" patch series
> that I sent last year, which were a follow up from previous
> series. See the links section for more information.
When this topic gets merged with the "diff: batch fetching of missing
blobs" topic, th
94 matches
Mail list logo
