On Fri, Jul 06, 2018 at 04:21:47PM -0700, frede...@ofb.net wrote:
> I don't think that it's really important to find a "best" ordering for
> commands or glossary terms; it's more a matter of finding someone who
> is willing to take responsibility for choosing a reasonable ordering.
> Presumably
On Fri, Jul 6, 2018 at 3:57 PM, Junio C Hamano wrote:
> I'll be pushing out the integration branches with some updates, but
> there is no change in 'next' and below. The following topics I gave
> a quick look and gave them topic branches, but I had trouble merging
> them in 'pu' and making them
On Wed, Jul 04, 2018 at 01:12:40AM +0100, Ramsay Jones wrote:
> > True that we don't even bother doing the parsing with your patch. But I
> > think I talked myself out of that part being a significant savings
> > elsewhere.
>
> [Sorry for the late reply - watching football again!]
>
> I'm not
Hi,
Frederick Eaton wrote:
> Unfortunately my contribution will have to be limited for the
> moment to making this suggestion, as I am extraordinarily busy. I hope
> it will not be too burdensome to add this item to your TODO list and
> keep it there until a willing volunteer comes along.
Thank you Jonathan for signaling your willingness to adopt the
documentation philosophy I suggested. That's a quite valuable first
step. Unfortunately my contribution will have to be limited for the
moment to making this suggestion, as I am extraordinarily busy. I hope
it will not be too
Junio C Hamano writes:
> I'll be pushing out the integration branches with some updates, but
> there is no change in 'next' and below. The following topics I gave
> a quick look and gave them topic branches, but I had trouble merging
> them in 'pu' and making them work correctly or pass the
I'll be pushing out the integration branches with some updates, but
there is no change in 'next' and below. The following topics I gave
a quick look and gave them topic branches, but I had trouble merging
them in 'pu' and making them work correctly or pass the tests, so
they are not part of 'pu'
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> Tab completion of `git range-diff` is very convenient, especially
> given that the revision arguments to specify the commit ranges to
> compare are typically more complex than, say, your grandfather's `git
> log`
"Johannes Schindelin via GitGitGadget"
writes:
> 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
>
Hi Junio,
On Fri, 6 Jul 2018, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > Of course, at that point I will have to look through those 7 patches
> > again, if only to verify that yes, they are still the same.
>
> That is something the patch author must help the reviewer with, no?
Jonathan Nieder writes:
> The upsides are that
> ...
> - down the line, it should make operations like "fetch just this one
> tree" a little simpler, since you can use
>
>filter blob:none
>filter tree:none
>want
;-)
I think this example, especially without the first line, would
Kana Natsuno writes:
> A later patch changes the built-in PHP pattern. These test cases
> demonstrate aspects of the pattern that we do not want to change.
>
> Signed-off-by: Kana Natsuno
> ---
> t/t4018/php-class| 4
> t/t4018/php-function | 4
> t/t4018/php-method | 7 +++
Johannes Schindelin writes:
> You recently also suggested this if...else... dance to Pratik, where it
> was not at all about doing the same thing slightly differently, but rather
> two different things: 1) return an error because execvp() returned an
> error, 2) indicate a serious bug (and you
Jeff King writes:
> FWIW, I like the GNU phrasing. I thought the "non-empty" part was not
> all that interesting, but after hearing that BSD behaves differently, it
> is probably worth mentioning.
>
> I think the actual behavior of your patch matches GNU grep, and does not
> need changing.
Johannes Schindelin writes:
>> And I also do not see a reason why somebody wants to make the dist
>> computation to be 1-based (iow, changing the minimum from 0 to 1) or
>> one step not to be 1 (iow, giving 11 to e1 and e8), so while I agree
>> it is not strictly necessary to cast the concrete
Junio C Hamano writes:
> Henning Schild writes:
>
>> The combination of verify_signed_buffer followed by parse_gpg_output is
>> available as check_signature. Use that instead of implementing it again.
>>
>> Signed-off-by: Henning Schild
>> ---
>
> Makes sense.
>
> When d05b9618
On Fri, Jul 06, 2018 at 02:16:00PM -0700, Jonathan Nieder wrote:
> Frederick Eaton wrote:
> > I wonder if someone familiar with Git could list the commands in an
> > order which makes more sense for learning, for example in the order in
> > which they were invented by Git developers,
>
> Alas,
Joshua Nelson writes:
> On 07/06/2018 01:01 PM, Junio C Hamano wrote:
>> Elijah Newren writes:
>>
I'd prefer *not* to have such a DWIM in a command like ls-tree, aka
plumbing commands, where predictability is worth 1000 times more
than ease of typing.
>>>
>>> Fair enough.
Pratik Karki writes:
> +static void add_var(struct strbuf *buf, const char *name, const char *value)
> +{
> + strbuf_addstr(buf, name);
> + strbuf_addstr(buf, "=");
> + sq_quote_buf(buf, value);
> + strbuf_addstr(buf, "; ");
> +}
> +
> +static int run_specific_rebase(struct
Hi,
Junio C Hamano wrote:
>> Jonathan Tan writes:
>>> When cloning a repository with a tagged blob (like the Git repository)
>>> with --filter=blob:none, the following message appears:
>>>
>>> error: missing object referenced by 'refs/tags/junio-gpg-pub'
>>>
>>> and the resulting
On 07/06/2018 01:01 PM, Junio C Hamano wrote:
> Elijah Newren writes:
>
>>> I'd prefer *not* to have such a DWIM in a command like ls-tree, aka
>>> plumbing commands, where predictability is worth 1000 times more
>>> than ease of typing.
>>
>> Fair enough. However, what if no or are
> Hmph, the approach taken by these two patches smells bad.
>
> When a blob is deliberately omitted with --fitler=blob:none, the
> fsck that encounters an entry in a tree object that is about that
> expected-to-be-and-actually-is-missing blob does *not* complain and
> that is by design, right?
Jonathan Nieder wrote:
> Ideas? If you start with a proposal, we're happy to help refine it.
> People in the #git channel on irc.freenode.net (wechat.freenode.net)
> might also be useful for inspiration in coming up with a proposal.
I meant to link to webchat.freenode.net. But
Hi Frederick,
Frederick Eaton wrote:
> I am trying to learn how to use Git but I've been put off by not
> knowing where to start. I would like to start with the 'git' man page,
> but it lists the Git subcommands in alphabetical order, rather than in
> an order which would be useful for learners.
Pratik Karki writes:
> +static int use_builtin_rebase(void)
> +{
> + struct child_process cp = CHILD_PROCESS_INIT;
> + struct strbuf out = STRBUF_INIT;
> + int ret;
> +
> + argv_array_pushl(,
> + "config", "--bool", "rebase.usebuiltin", NULL);
> +
Dear Git Developers,
I am trying to learn how to use Git but I've been put off by not
knowing where to start. I would like to start with the 'git' man page,
but it lists the Git subcommands in alphabetical order, rather than in
an order which would be useful for learners. For example, I'm not
Henning Schild writes:
> -enum gpgformats { PGP_FMT };
> +enum gpgformats { PGP_FMT, X509_FMT };
> struct gpg_format_data gpg_formats[] = {
> { .format = "PGP", .program = "gpg",
> .extra_args_verify = { "--keyid-format=long", },
> .sigs = { PGP_SIGNATURE, PGP_MESSAGE, },
Hi Junio,
On Fri, 6 Jul 2018, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> >> > git rev-list --first-parent --bisect-all F..E >revs &&
> >> > test_line_count = 9 revs &&
> >> > for rev in E e1 e2 e3 e4 e5 e6 e7 e8
> >> > do
> >> > grep "^$(git rev-parse $rev) " revs ||
> >> > {
On Fri, Jul 06, 2018 at 03:15:22PM -0500, Taylor Blau wrote:
> On Fri, Jul 06, 2018 at 11:21:06AM -0700, Junio C Hamano wrote:
> > Taylor Blau writes:
> >
> > > I think that this might be clear enough on its own, especially since
> > > this is the same as BSD grep on my machine. I think that
Henning Schild writes:
> gnupg does print the keyid followed by a space and the signer comes
> next. The same pattern is also used in gpgsm, but there the key length
> would be 40 instead of 16. Instead of hardcoding the expected length,
> find the first space and calculate it.
>
>
Henning Schild writes:
> Valid values are already covered by all tests that use GPG, now also
> test what happens if we go for an invalid one.
>
> Signed-off-by: Henning Schild
> ---
> t/t7510-signed-commit.sh | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git
On Fri, Jul 06, 2018 at 02:01:25AM -0400, Eric Sunshine wrote:
> On Thu, Jul 5, 2018 at 10:24 PM brian m. carlson
> wrote:
> > For most patches, using a transfer encoding of 8bit provides good
> > compatibility with most servers and makes it as easy as possible to view
> > patches. However,
On Fri, Jul 06, 2018 at 08:26:04AM -0400, Drew DeVault wrote:
> On 2018-07-06 2:23 AM, brian m. carlson wrote:
> > diff --git a/git-send-email.perl b/git-send-email.perl
> > index a76953c310..4ea30c4070 100755
> > --- a/git-send-email.perl
> > +++ b/git-send-email.perl
> > @@ -1899,6 +1899,10 @@
On Fri, Jul 06, 2018 at 11:21:06AM -0700, Junio C Hamano wrote:
> Taylor Blau writes:
>
> > I think that this might be clear enough on its own, especially since
> > this is the same as BSD grep on my machine. I think that part_s_ of a
> > line indicates that behavior, but perhaps not. On GNU
Jonathan Tan writes:
>> When cloning a repository with a tagged blob (like the Git repository)
>> with --filter=blob:none, the following message appears:
>>
>> error: missing object referenced by 'refs/tags/junio-gpg-pub'
>>
>> and the resulting repository also fails fsck.
Hmph, the
"brian m. carlson" writes:
> On Tue, Jul 03, 2018 at 02:38:15PM +0200, Henning Schild wrote:
>> Add "gpg.format" where the user can specify which type of signature to
>> use for commits. At the moment only "PGP" is supported and the value is
>> not even used. This commit prepares for a new types
Henning Schild writes:
> The combination of verify_signed_buffer followed by parse_gpg_output is
> available as check_signature. Use that instead of implementing it again.
>
> Signed-off-by: Henning Schild
> ---
Makes sense.
When d05b9618 ("receive-pack: GPG-validate push certificates",
Johannes Schindelin writes:
> Of course, at that point I will have to look through those 7 patches
> again, if only to verify that yes, they are still the same.
That is something the patch author must help the reviewer with, no?
Have uncontroversial stuff early in the series, concentrate on
> When cloning a repository with a tagged blob (like the Git repository)
> with --filter=blob:none, the following message appears:
>
> error: missing object referenced by 'refs/tags/junio-gpg-pub'
>
> and the resulting repository also fails fsck.
>
> Patch 1 fixes the protocol
When cloning a repository with a tagged blob (like the Git repository)
with --filter=blob:none, the following message appears:
error: missing object referenced by 'refs/tags/junio-gpg-pub'
and the resulting repository also fails fsck.
Patch 1 fixes the protocol documentation and the
A filter line in a request to upload-pack filters out objects regardless
of whether they are directly referenced by a "want" line or not. This
means that cloning with "--filter=blob:none" (or another filter that
excludes blobs) from a repository with at least one ref pointing to a
blob (for
The commit that introduced the partial clone feature - 548719fbdc
("clone: partial clone", 2017-12-08) - excluded connectivity checks
for partial clones, but this also meant that it is possible for a clone
to succeed, yet not have all objects either present or promised.
Specifically, if cloning
Jeff King writes:
> On Thu, Jul 05, 2018 at 09:50:53PM +0200, Beat Bolli wrote:
>
>> > Your patch is obviously correct, but I think here there might be an even
>> > simpler solution: just bump option_parse_type() below the declaration,
>> > since it's the only one that needs it. That hunk is
Hi Junio,
On Fri, 6 Jul 2018, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > I would *strongly* encourage you to allow Alban to go back to the small,
> > incremental patch series he sent before, because it will make it
> > *substantially* easier to not only review, but also develop,
Eric Sunshine writes:
> On Thu, Jul 5, 2018 at 10:20 AM Derrick Stolee wrote:
>> On 6/25/2018 3:38 PM, Junio C Hamano wrote:
>> While I don't use substitutions in this patch, I do use them in later
>> patches. Here is the final version of this method:
>>
>> midx_read_expect () {
>>
Jean-Noël Avila writes:
> OK, Will queue this patch for next round of translation
Thanks for an Ack.
Hi Junio,
On Fri, 6 Jul 2018, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> >> I thought we made this into
> >>
> >>if verbose
> >>return run_command
> >>else
> >>return run_command_silently
> >>
> >> to help readers in the previous round already.
>
Tobias Klauser writes:
> And I'm glad to see that this part will be rewritten in C :-)
>
>> However, your patch also covers this:
>>
>> > git-rebase--preserve-merges.sh | 4 ++--
>>
>> I completely missed that in the earlier patch.
>>
>> Junio, this gets an ACK from me, could you apply the
>>
Taylor Blau writes:
> I think that this might be clear enough on its own, especially since
> this is the same as BSD grep on my machine. I think that part_s_ of a
> line indicates that behavior, but perhaps not. On GNU grep, this is:
>
> Print only the matched (non-empty) parts of a matching
Taylor Blau writes:
> On Mon, Jun 25, 2018 at 02:59:07PM -0500, Taylor Blau wrote:
>> Teach 'git grep --only-matching', a new option to only print the
>> matching part(s) of a line.
>>
>> [ ... ]
>>
>> diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt
>> index
Johannes Schindelin writes:
>> > git rev-list --first-parent --bisect-all F..E >revs &&
>> > test_line_count = 9 revs &&
>> > for rev in E e1 e2 e3 e4 e5 e6 e7 e8
>> > do
>> > grep "^$(git rev-parse $rev) " revs ||
>> > {
>> > echo "$rev not shown" >&2 &&
>> > return 1
>> > }
>> >
Thomas Gummerer writes:
> On 06/05, Thomas Gummerer wrote:
>> The previous round was at
>> <20180520211210.1248-1-t.gumme...@gmail.com>.
>>
>> Thanks Junio for the comments on the previous round.
>>
>> Changes since v2:
>> - lowercase the first letter in some error/warning messages before
>>
Johannes Schindelin writes:
> The latest iteration of this is here:
> https://public-inbox.org/git/20180702105717.26386-5-alban.gr...@gmail.com/T/#r8eea71077745d6f2c839acb6200bb8b2bea579d3
Good. I think we have it in tree now.
> I would *strongly* encourage you to allow Alban to go back to
Martin Ågren writes:
>> +enum gpgformats { PGP_FMT };
>> +struct gpg_format_data gpg_formats[] = {
>> + { .format = "PGP", .program = "gpg",
>> + .extra_args_verify = { "--keyid-format=long", },
>> + .sigs = { PGP_SIGNATURE, PGP_MESSAGE, },
>> + },
>> +};
>
> I think
Elijah Newren writes:
>> I'd prefer *not* to have such a DWIM in a command like ls-tree, aka
>> plumbing commands, where predictability is worth 1000 times more
>> than ease of typing.
>
> Fair enough. However, what if no or are specified,
> though -- would you be okay with the HEAD being
Mike Hommey writes:
> On Tue, Jul 03, 2018 at 11:41:42AM -0700, Junio C Hamano wrote:
>> Mike Hommey writes:
>>
>> > When the reference buffer is empty, diff_delta returns NULL without
>> > really attempting anything, yet fast-import counts that as a delta
>> > attempt.
>>
>> But that is an
Duy Nguyen writes:
> On Sat, Jun 30, 2018 at 03:38:21PM +0200, Kim Gybels wrote:
>> Teach gc --auto to release pack files before auto packing the repository
>> to prevent failures when removing them.
>>
>> Also teach the test 'fetching with auto-gc does not lock up' to complain
>> when it is no
Johannes Schindelin writes:
> On Tue, 3 Jul 2018, Junio C Hamano wrote:
>
>> Johannes Schindelin writes:
>>
>> > On Thu, 28 Jun 2018, Junio C Hamano wrote:
>> >
>> >> * as/safecrlf-quiet-fix (2018-06-11) 1 commit
>> >> (merged to 'next' on 2018-06-13 at b163674843)
>> >> + config.c: fix
Johannes Schindelin writes:
>> I thought we made this into
>>
>> if verbose
>> return run_command
>> else
>> return run_command_silently
>>
>> to help readers in the previous round already.
>
> FWIW we had quite a couple of reviews in the recent years which
Apologies for the delayed response - I've been out of town - and It
looks like Paul is already on the right track.
Johannes: I believe the GIT_EXEC_PATH snipped that you listed is not
incorrect. It's defined to "gitexecdir_SQ", and RUNTIME_PREFIX expects
(and enforces, as you snipped) that this
Hi Junio,
On Tue, 3 Jul 2018, Junio C Hamano wrote:
> Alban Gruin writes:
>
> > +static int run_git_checkout(struct replay_opts *opts, const char *commit,
> > + int verbose, const char *action)
> > +{
> > + struct child_process cmd = CHILD_PROCESS_INIT;
> > +
> > +
Hi Pratik,
On Fri, 6 Jul 2018, Pratik Karki wrote:
> The functions present in `git-legacy-rebase.sh` are used by the rebase
> backends as they are implemented as shell script functions in the
> `git-rebase--` files.
>
> To make the `builtin/rebase.c` work, we have to provide support via
> a
Overall this series looks good. Thanks for putting the patches together!
On 2018-07-06 2:23 AM, brian m. carlson wrote:
> diff --git a/git-send-email.perl b/git-send-email.perl
> index a76953c310..4ea30c4070 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -1899,6 +1899,10 @@ sub validate_patch {
> return $hook_error if $hook_error;
>
This patch gives life to the skeleton added in the previous patches:
With this change, we can perform a elementary rebase (without any
options).
It can be tested thusly by:
git -c rebase.usebuiltin=true rebase HEAD~2
The rebase backends (i.e. the shell script functions defined in
In the upcoming builtin rebase, we will have to start by detaching
the HEAD, just like shell script version does. Essentially, we have
to do the same thing as `git checkout -q ^0 --`, in pure C.
The aforementioned functionality was already present in `sequencer.c`
in `do_reset()` function. But
This commit imitates the strategy that was used to convert the
difftool to a builtin. We start by renaming the shell script
`git-rebase.sh` to `git-legacy-rebase.sh` and introduce a
`builtin/rebase.c` that simply executes the shell script version,
unless the config setting `rebase.useBuiltin` is
The functions present in `git-legacy-rebase.sh` are used by the rebase
backends as they are implemented as shell script functions in the
`git-rebase--` files.
To make the `builtin/rebase.c` work, we have to provide support via
a Unix shell script snippet that uses these functions and so, we
want
As a GSoC project, I have been working on the builtin rebase.
The motivation behind the rewrite of rebase i.e. from shell script to C
are for following reasons:
1. Writing shell scripts and getting it to production is much faster
than doing the equivalent in C but lacks in performance and
Hi Paul,
On Thu, 5 Jul 2018, Paul Smith wrote:
> On Wed, 2018-07-04 at 13:22 +0200, Johannes Schindelin wrote:
> > > Basically what happens is that I run configure with
> > > --prefix=/my/install/path --with-gitconfig=etc/gitconfig
> > > --with-gitattributes=etc/gitattributes.
> > >
> > > Then
Am Fri, 6 Jul 2018 01:01:48 +
schrieb "brian m. carlson" :
> On Tue, Jul 03, 2018 at 02:38:15PM +0200, Henning Schild wrote:
> > Add "gpg.format" where the user can specify which type of signature
> > to use for commits. At the moment only "PGP" is supported and the
> > value is not even
Am Fri, 6 Jul 2018 01:14:47 +
schrieb "brian m. carlson" :
> On Tue, Jul 03, 2018 at 02:38:20PM +0200, Henning Schild wrote:
> > Add test cases to cover the new X509/gpgsm support. Most of them
> > resemble existing ones. They just switch the format to X509 and set
> > the signingkey when
Am Fri, 6 Jul 2018 01:18:35 +
schrieb "brian m. carlson" :
> On Tue, Jul 03, 2018 at 02:38:12PM +0200, Henning Schild wrote:
> > This series adds support for signing commits with gpgsm.
> >
> > The first two patches are cleanups of gpg-interface, while the next
> > four prepare for the
Am Fri, 6 Jul 2018 01:10:13 +
schrieb "brian m. carlson" :
> On Tue, Jul 03, 2018 at 02:38:19PM +0200, Henning Schild wrote:
> > This commit allows git to create and check X509 type signatures
> > using gpgsm.
> >
> > Signed-off-by: Henning Schild
> > ---
> > Documentation/config.txt | 5
On Thu, Jul 5, 2018 at 10:24 PM brian m. carlson
wrote:
> With --validate (which is the default), we warn about lines exceeding
> 998 characters due to the limits specified in RFC 5321. However, if
> we're using a suitable transfer encoding (quoted-printable or base64),
> we're guaranteed not to
On Thu, Jul 5, 2018 at 10:24 PM brian m. carlson
wrote:
> For most patches, using a transfer encoding of 8bit provides good
> compatibility with most servers and makes it as easy as possible to view
> patches. However, there are some patches for which 8bit is not a valid
> encoding: RFC 5321
76 matches
Mail list logo
