Hi Peff,
On Fri, 1 Jul 2016, Jeff King wrote:
> On Fri, Jul 01, 2016 at 03:39:03PM +0200, Johannes Schindelin wrote:
>
> > > The description was sufficiently long that I didn't want to try
> > > repeating it, and opted for a reference instead. If you're planning to
> > > fix mingw_main(), I'd be
Hi Junio,
On Wed, 29 Jun 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > When trying to match a pattern in the commit subject, simply skip leading
> > blank lines in the commit message. This is consistent with the
> > pretty-printing machinery: it silently ignores leading blank
Do You Need Urgent Loan? Contact Us Now: cfifunding...@hotmail.com
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jun 29, 2016 at 1:36 PM, Johannes Schindelin
wrote:
> @@ -955,9 +955,8 @@ static struct merge_file_info merge_file_1(struct
> merge_options *o,
>
> if (!sha_eq(a->sha1, b->sha1))
> result.clean = 0;
> - } else {
> -
On Sat, Jul 2, 2016 at 1:21 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> I'm not sure if we should bring back "{ -> origin/}foo" format. I can
>> do it if someone still wants it.
>> ...
>> +In compact output mode, specified with configuration variable
>> +fetch.output, if either
The functions `mk_repo_pair` as well as `test_refs` are borrowed from
t5543-atomic-push, with additional hooks installed.
Signed-off-by: Stefan Beller
---
t/t5544-push-options.sh | 101
1 file changed, 101 insertions(+)
create mode 100755 t/t5544
The pre/post receive hook may be interested in more information from the
user. This information can be transmitted when both client and server
support the "push-options" capability, which when used is a phase directly
after update commands ended by a flush pkt.
Similar to the atomic option, the se
The environment variable GIT_PUSH_OPTION_COUNT is set to the number of
push options sent, and GIT_PUSH_OPTION_{0,1,..} is set to the transmitted
option.
The code is not executed as the push options are set to NULL, nor is the
new capability advertised.
There was some discussion back and forth how
This implements everything that is required on the client side to make use
of push options from the porcelain push command.
Signed-off-by: Stefan Beller
---
Documentation/git-push.txt | 8 +++-
builtin/push.c | 16 +---
send-pack.c| 29 +++
Allow a user to pass information along a push to the pre/post-receive hook
on the remote.
Jeff writes on v1:
> Whereas in Dennis's patches, it was about specific information directly
> related to the act of pushing.
This allows to transmit arbitrary information as the backends of $VENDOR
may have
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 any of
the integration branches, but I am still holding onto them.
The first few batches for this cyc
Thanks, will queue.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Nguyễn Thái Ngọc Duy writes:
> I'm not sure if we should bring back "{ -> origin/}foo" format. I can
> do it if someone still wants it.
> ...
> +In compact output mode, specified with configuration variable
> +fetch.output, if either entire `` or `` is found in the
> +other string, it will be su
Junio C Hamano writes:
> On Fri, Jul 1, 2016 at 3:08 PM, Philip Oakley wrote:
~~~
To exclude commits reachable from a commit, a prefix '{caret}'
notation is used. E.g. '{caret}r1 r2' means commits reachable
-from 'r2' but exclude the ones reach
On Fri, Jul 01, 2016 at 03:19:37PM -0700, Junio C Hamano wrote:
> > Here they are:
> >
> > [1/5]: add an extra level of indirection to main()
> > [2/5]: common-main: call git_extract_argv0_path()
> > [3/5]: common-main: call sanitize_stdfds()
> > [4/5]: common-main: call restore_sigpipe_to
On Fri, Jul 01, 2016 at 03:39:03PM +0200, Johannes Schindelin wrote:
> > The description was sufficiently long that I didn't want to try
> > repeating it, and opted for a reference instead. If you're planning to
> > fix mingw_main(), I'd be happy to do that as a preparatory patch, and
> > then jus
From: "Junio C Hamano"
Philip Oakley writes:
Signed-off-by: Philip Oakley
---
Documentation/revisions.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index 131060c..87be9c4 100644
--- a/Documentation/revisions
On Fri, Jul 1, 2016 at 3:08 PM, Philip Oakley wrote:
>>> ~~~
>>> To exclude commits reachable from a commit, a prefix '{caret}'
>>> notation is used. E.g. '{caret}r1 r2' means commits reachable
>>> -from 'r2' but exclude the ones reachable from 'r1'.
>>> +from 'r2'
Jeff King writes:
> On Fri, Jul 01, 2016 at 12:07:15AM -0400, Jeff King wrote:
>
>> Interesting. It's failing on the assert(argv0_path) in system_path().
>>
>> That's part of the RUNTIME_PREFIX code which is built only on Windows,
>> so this is a Windows-specific issue.
>>
>> I can guess the re
Torsten Bögershausen writes:
>> The checkout process hopefully does not blindly turn LF into CRLF,
>> making it "first line \r\r\nsame line\r\rn". Instead the (virtual)
>> working tree file will have "first line\r\nsame line\r\n".
> Yes
>>
>> Then "git add" should turn that CRLF into LF, which
Philip Oakley writes:
> This is the re-roll of the po/range-doc (2016-06-27) 3 commits
>
> The order is slightly re-arranged, and an additional patch clarifying
> that ^r1 excludes r1 itself being added.
>
> The heading have been tweaked.
Thanks.
I think 1-3 are ready for 'next'. 4/4 may need
Philip Oakley writes:
> Signed-off-by: Philip Oakley
> ---
> Documentation/revisions.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
> index 131060c..87be9c4 100644
> --- a/Documentation/revisions.txt
> +++ b
Charles Bailey writes:
> +test_expect_success 'grep can find things only in the work tree' '
> + : >work-tree-only &&
> + git add work-tree-only &&
> + test_when_finished "git rm -f work-tree-only" &&
It is better to have the test_when_finished before "git add", and
possibly before t
Charles Bailey writes:
> So I've got back around to this topic again.
>
> I've applied fixes to the tests as suggested by Eric and Junio.
>
> I came up with a test case that demonstrates a difference between the
> additional fix that Duy suggested and the alternative that Junio
> suggested.
Than
Charles Bailey writes:
> @@ -353,7 +353,7 @@ test_expect_success 'grep -l -C' '
> cat >expected < file:5
> EOF
> -test_expect_success 'grep -l -C' '
> +test_expect_success 'grep -c -C' '
> git grep -c -C1 foo >actual &&
> test_cmp expected actual
> '
Makes sense. The previous on
On Fri, Jul 01, 2016 at 11:25:40AM -0700, Stefan Beller wrote:
> > So a litmus test for me would be something like:
> >
> > Can you get the same effect with:
> >
> > git push $remote my-branch &&
> > curl https://$remote/api/do-the-thing?q=my-branch
> >
> > as you would with:
> >
> >
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Lukas Fleischer writes:
> Oh, and one more detail: I wonder why we still use fwrite(), now that we
> know we can use xwrite() which guarantees atomicity. Is there a reason
> for that?
The code (before squashing anyway) used to use fprintf() directly
bypasing the outbuf for unusual cases, and we
Junio C Hamano writes:
>> Ok, there was a miniscule conflicts but otherwise the squashed
>> material was all coming from a single step in the original, so
>> I did so myself. Let's start merging the result to 'next' ;-)
>>
>> Thanks.
>
> IOW, this on top of the fixup we discussed.
>
> sideband.
Junio C Hamano writes:
> Junio C Hamano writes:
>
>> Duy Nguyen writes:
>>
>>> The rest looks good (after your comment fixup). I see you already have
>>> all the changes in your SQUASH??? commit. Do you want me to resend or
>>> you will just squash this in locally?
>>
>> Squashing in would need
On Fri, Jul 1, 2016 at 12:39 PM, Jeff King wrote:
>
> That was sort of my question. _Is it_ too bad or not? It's hard to say
> without knowing the use cases.
>
...
>
> That's ugly, of course, but not really uglier than the parsing required
> for the COUNT proposal.
ok, I'll try to get the COUNT p
Junio C Hamano writes:
> Duy Nguyen writes:
>
>> The rest looks good (after your comment fixup). I see you already have
>> all the changes in your SQUASH??? commit. Do you want me to resend or
>> you will just squash this in locally?
>
> Squashing in would need to redo this into a few relevant c
On Fri, Jul 01, 2016 at 12:25:39PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Compare to:
> >
> > if test "$GIT_PUSH_VAR_force" = true
> > ...
>
> OK. As this is a new feature, I guess it is not too bad if we tell
> users that they cannot have duplicate keys in their data
>
On Fri, Jul 1, 2016 at 12:25 PM, Junio C Hamano wrote:
> Jeff King writes:
>
>> Compare to:
>>
>> if test "$GIT_PUSH_VAR_force" = true
>> ...
>
> OK. As this is a new feature, I guess it is not too bad if we tell
> users that they cannot have duplicate keys in their data
> they ask Git t
Jeff King writes:
> Compare to:
>
> if test "$GIT_PUSH_VAR_force" = true
> ...
OK. As this is a new feature, I guess it is not too bad if we tell
users that they cannot have duplicate keys in their data
they ask Git to transport. They can do the key1=val1 key2=val2
numbering themselves
Duy Nguyen writes:
> The rest looks good (after your comment fixup). I see you already have
> all the changes in your SQUASH??? commit. Do you want me to resend or
> you will just squash this in locally?
Squashing in would need to redo this into a few relevant commits,
so it won't be "just squas
Duy Nguyen writes:
> On Fri, Jul 1, 2016 at 8:18 PM, Junio C Hamano wrote:
>> Duy Nguyen writes:
>>
>>> Makes sense. But then if opt->ignore_case is false and regflags
>>> happens to have REG_ICASE set, should we clear it as well?
>>
>> I think .ignore_case is set iff '-i' is given, and .regfla
On Fri, Jul 1, 2016 at 8:18 PM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> Makes sense. But then if opt->ignore_case is false and regflags
>> happens to have REG_ICASE set, should we clear it as well?
>
> I think .ignore_case is set iff '-i' is given, and .regflags has
> REG_ICASE only if '-
On Fri, Jul 1, 2016 at 10:59 AM, Jeff King wrote:
> On Fri, Jul 01, 2016 at 10:20:32AM -0700, Stefan Beller wrote:
>
>> >> The rationale for keeping the actual options inside a file instead of
>> >> putting them directly into an environment variable has multiple reasons:
>> >
>> > Thanks for inclu
Hope you are doing well!!!
I would like to discuss a business. I am Shruti, Online Marketing Consultant,
I gone through your website and found its design is not eye-catching. However,
your website needs re-designing or needful modification to look fascinating and
business oriented. So, would yo
On Fri, Jul 1, 2016 at 10:55 AM, Jeff King wrote:
> On Fri, Jul 01, 2016 at 10:07:10AM -0700, Stefan Beller wrote:
>
>> > So you'd probably want some client tool to help the user figure out what
>> > to put in the PR, and of course that already exists, because GitHub has
>> > an HTTP API that it c
Duy Nguyen writes:
> Makes sense. But then if opt->ignore_case is false and regflags
> happens to have REG_ICASE set, should we clear it as well?
I think .ignore_case is set iff '-i' is given, and .regflags has
REG_ICASE only if '-i' is given and the user said she does not want
literal string ma
On Fri, Jul 01, 2016 at 03:51:33PM +0200, Johannes Schindelin wrote:
> > > If the idea is to make it easier to find, I would wager a guess that
> > > 'die("BUG:' would be just as good a search term. Even better, I think,
> > > because 'BUG' would also match comments.
> >
> > I have been tempted t
On Fri, Jul 01, 2016 at 11:03:06AM -0700, Junio C Hamano wrote:
> On Fri, Jul 1, 2016 at 10:59 AM, Jeff King wrote:
> > If you give up on having multiple incarnations of each variable, then I
> > think:
> >
> > GIT_PUSH_VAR_foo=value_for_foo
> > GIT_PUSH_VAR_bar=value_for_bar
> >
> > is quite
On Fri, Jul 01, 2016 at 10:23:05AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > In shell scripts it is sometimes useful to be able to read
> > exactly N bytes from a pipe. Doing this portably turns out
> > to be surprisingly difficult.
>
> I'd rotate the above by three words ;-).
>
>
On Fri, Jul 1, 2016 at 10:59 AM, Jeff King wrote:
> If you give up on having multiple incarnations of each variable, then I
> think:
>
> GIT_PUSH_VAR_foo=value_for_foo
> GIT_PUSH_VAR_bar=value_for_bar
>
> is quite elegant, and easy to use from hooks. It just cannot represent
> multiple such "f
Michael Haggerty writes:
> I put quite of work into tooling to evaluate diff heuristics, and just
> published it on GitHub:
>
> https://github.com/mhagger/diff-slider-tools
>
> The README there is hopefully enough to let people get started using it
> to test their own favorite heuristics.
In
On Fri, Jul 01, 2016 at 10:20:32AM -0700, Stefan Beller wrote:
> >> The rationale for keeping the actual options inside a file instead of
> >> putting them directly into an environment variable has multiple reasons:
> >
> > Thanks for including this rationale; my first thought on seeing the
> > pa
On Fri, Jul 01, 2016 at 10:07:10AM -0700, Stefan Beller wrote:
> > So you'd probably want some client tool to help the user figure out what
> > to put in the PR, and of course that already exists, because GitHub has
> > an HTTP API that it can talk to. Shoe-horning it into Git doesn't buy
> > much
On Fri, Jul 1, 2016 at 10:11 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> +static const char *stream_push_options_to_file()
>> +{
>> + static const char *fname = "push-options-XX";
>> + char *ret = xmallocz(strlen(fname));
>> + int fd;
>> + memcpy(ret, fname, strlen(
Jeff King writes:
> In shell scripts it is sometimes useful to be able to read
> exactly N bytes from a pipe. Doing this portably turns out
> to be surprisingly difficult.
I'd rotate the above by three words ;-).
It is sometimes useful to be able to read
exactly N bytes from a pipe. Doi
On Fri, Jul 1, 2016 at 12:14 AM, Jeff King wrote:
>
> Putting the data into a file does alleviate some issues. But it also
> makes parsing annoying, and opens up new issues (like what happens
> to content that has a newline in it?). Wouldn't multiple files be a bit
> more convenient? Especially fo
Stefan Beller writes:
> +static const char *stream_push_options_to_file()
> +{
> + static const char *fname = "push-options-XX";
> + char *ret = xmallocz(strlen(fname));
> + int fd;
> + memcpy(ret, fname, strlen(fname));
> + fd = mkstemp(ret);
Probably
char *ret;
On 06/30/2016 03:54 PM, Michael Haggerty wrote:
> On 06/23/2016 07:10 PM, Michael Haggerty wrote:
>> On 06/17/2016 06:09 PM, Stefan Beller wrote:
>>> I think before spending more time on discussing and implementing new
>>> (hopefully better) heuristics, I'd want to step back and try to be a bit
>>
On Fri, Jul 1, 2016 at 12:09 AM, Jeff King wrote:
> On Wed, Jun 29, 2016 at 05:59:47PM -0700, Stefan Beller wrote:
>
>> Allow a user to pass information along a push to the pre/post-receive hook
>> on the remote.
>
> Seems like a reasonable thing to want, and related to:
>
> http://thread.gmane.
We do align "remote -> local" output by allocating 10 columns to
"remote". That produces aligned output only for short refs. An extra
pass is performed to find the longest remote ref name (that does not
produce a line longer than terminal width) to produce better aligned
output.
Signed-off-by: Ngu
Jeff King writes:
> So I think it would be more productive to put a check like this in "git
> commit" rather than (or perhaps in addition to) fsck. That prevents
> us creating the broken relationship, but it does still mean the user may
> have to to go back and tell the original committer that th
Johannes Schindelin writes:
>> that has a substring '-S"' in it to ensure that the codepath to
>> parse --gpg-sign= on the command line of "rebase", and to the
>> message we see here are working correctly, without actually checking
>> if GPG is invoked at all, or if it is invoked the key given by
This makes the fetch flag code consistent with push, where '-' means
deleted ref.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-fetch.txt | 4 ++--
builtin/fetch.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-fetch.txt b/Docum
In the "remote -> local" line, if either ref is a substring of the
other, the common part in the other string is replaced with "*". For
example
abc-> origin/abc
refs/pull/123/head -> pull/123
become
abc -> origin/*
refs/*/head -> pull/123
Activated with f
v5 changes the substitute symbol from '$' to '*' in compact mode and
makes sure long lines in compact mode will not make the remote ref
column too big (it's far from perfect but I think it's still good to
do).
I'm not sure if we should bring back "{ -> origin/}foo" format. I can
do it if someone s
This documents the ref update status of fetch. The structure of this
output is defined in [1]. The ouput content is refined a bit in [2]
[3] [4].
This patch is a copy from git-push.txt, modified a bit because the
flag '-' means different things in push (delete) and fetch (tag
update).
PS. For cod
This makes it easier to change the formatting later. And it makes sure
translators cannot mess up format specifiers and break Git.
There are a couple call sites where the length of the second column is
TRANSPORT_SUMMARY_WIDTH instead of calculated by TRANSPORT_SUMMARY(),
which is enforced now. The
Johannes Schindelin writes:
> On Wed, 29 Jun 2016, Junio C Hamano wrote:
>
>> Johannes Schindelin writes:
>>
>> > From: Junio C Hamano
>>
>> Did I write this thing?
>
> Yes, you did. It was db05d6194d3f9ea9e64163944961d5f6e85302be as part of
> pu@{2016-06-15}.
Ah, OK, that is quite old, dati
Johannes Schindelin writes:
>> >saved_b2 = o->branch2;
>> >o->branch1 = "Temporary merge branch 1";
>> >o->branch2 = "Temporary merge branch 2";
>> > - merge_recursive(o, merged_common_ancestors, iter->item,
>> > - NULL, &merge
Johannes Schindelin writes:
>> > A truly libified function does not die() just for fun.
>>
>> The sentence is wasting bits. After all, a helper function in
>> run-once-and-exit program does not die() just for fun, either.
>
> This sentence does not so much target *you* personally as audience, b
Johannes Schindelin writes:
> I agree that the comment is not very good currently. But I disagree that
> we are better off without any comment here.
I meant we are better off without your particular version of comment
which is misleading. I am all for a better comment to help those
who are new
On Fri, Jul 1, 2016 at 4:20 PM, Michael J Gruber
wrote:
> Jeff King venit, vidit, dixit 01.07.2016 08:31:
>> On Thu, Jun 30, 2016 at 06:39:42PM +0200, Nguyễn Thái Ngọc Duy wrote:
>>
>>> Commit 76c61fb (log: decorate HEAD with branch name under
>>> --decorate=full, too - 2015-05-13) adds "HEAD -> b
Johannes Schindelin wrote:
> P.S.: If it is not too much of a problem, may I ask you to simply delete
> remainders of my patches when replying and not commenting on them? I just
> deleted 226 lines after verifying that you really did not respond to any
> part of it in the unhelpful Alpine client (
Jeff King venit, vidit, dixit 01.07.2016 08:31:
> On Thu, Jun 30, 2016 at 06:39:42PM +0200, Nguyễn Thái Ngọc Duy wrote:
>
>> Commit 76c61fb (log: decorate HEAD with branch name under
>> --decorate=full, too - 2015-05-13) adds "HEAD -> branch" decoration to
>> show current branch vs detached HEAD.
Hi Peff,
On Thu, 30 Jun 2016, Jeff King wrote:
> On Wed, Jun 29, 2016 at 09:02:37AM +0200, Johannes Schindelin wrote:
>
> > It is the most convenient way to determine which tests failed after
> > running the entire test suite, in parallel, to look for left-over "trash
> > directory.t*" subdirect
Hi Junio,
On Wed, 29 Jun 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > While developing patch series, it is a good practice to run the test
> > suite from time to time, just to make sure that obvious bugs are caught
> > early. With complex patch series, it is common to run `ma
Hi Peff,
On Thu, 30 Jun 2016, Jeff King wrote:
> On Thu, Jun 30, 2016 at 10:42:37AM +0200, Johannes Schindelin wrote:
>
> > > > The vast majority of error messages in Git's source code which report a
> > > > bug use the convention to prefix the message with "BUG:".
> > >
> > > Good thing to do.
Hi Junio,
On Wed, 29 Jun 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > It is technically allowed, as per C89, for functions' return type to
> > be complete structs (i.e. *not* just pointers to structs), but it is
> > bad practice.
>
> Not necessarily.
Okay, I fixed it.
> >
Hi,
>From a git-p4 point of view, I see no problems with this change.
Thanks and regards,
Vitor
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Yannis,
On Fri, 1 Jul 2016, Ioannis Kappas wrote:
> Johannes Schindelin gmx.de> writes:
>
> > [...]
> >
> > My more immediate concern is MSYS2 (the POSIX-emulating basis of Git
> > for Windows), and I opened a Pull Request there:
> >
> > https://github.com/Alexpux/MSYS2-packages/pull/6
Hi Peff,
On Fri, 1 Jul 2016, Jeff King wrote:
> On Fri, Jul 01, 2016 at 10:04:44AM +0200, Johannes Schindelin wrote:
>
> > On Fri, 1 Jul 2016, Jeff King wrote:
> >
> > > I waffled between the two mechanisms. Opinions welcome.
> >
> > I am happy you took the cmd_main() approach: we do have to p
W dniu 2016-07-01 o 08:42, Jeff King pisze:
> On Thu, Jun 30, 2016 at 05:14:15PM +0200, Duy Nguyen wrote:
>
>>> So we could describe how Git handles pathspecs and pathspec magic
>>> in the new manual page named gitpathspec(7), or gitpaths(7). The
>>> former has the advantage of the name being iden
Hi Junio,
On Wed, 29 Jun 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > - cp.git_cmd = 1;
> > + init_merge_options(&o);
> > +
> > + o.branch1 = "HEAD";
> > + his_tree_name = xstrfmt("%.*s", linelen(state->msg), state->msg);
> > + o.branch2 = his_tree_name;
> >
> > -
Hi Junio,
On Wed, 29 Jun 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > @@ -743,6 +741,8 @@ static int update_file_flags(struct merge_options *o,
> > int update_cache,
> > int update_wd)
> > ...
> > + ret = e
Hi Junio,
On Wed, 29 Jun 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > diff --git a/merge-recursive.c b/merge-recursive.c
> > index 6ab7dfc..bb075e3 100644
> > --- a/merge-recursive.c
> > +++ b/merge-recursive.c
> > @@ -266,8 +266,10 @@ struct tree *write_tree_from_memory(stru
Hmhm.
Bryan Turner wrote:
You now support git too.
But say, is that you with the "stay away from the storage backend
if you don't have a glue!", long ago on the Mercurial list???
Ha!
See how important knowledge of an aggressively garbage-collected
storage backend is. I always knew that!
Ciao.
Hello Jeff!
Jeff King wrote:
|On Thu, Jun 30, 2016 at 09:38:45PM +0200, Steffen Nurpmeso wrote:
|> For some time (currently with 2.9.0) know see that a single commit
|> gives a longer hash than necessary, even though there is no
|> ambiguity:
|I don't know what your "git longca" alias is, b
Hi Junio,
On Wed, 29 Jun 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > It can be puzzling to see that was_tracked() tries to match an index
> > entry by name even if cache_name_pos() returned a negative value. Let's
> > clarify that cache_name_pos() implicitly looks for stage
Hi Junio,
On Wed, 29 Jun 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > A truly libified function does not die() just for fun.
>
> The sentence is wasting bits. After all, a helper function in
> run-once-and-exit program does not die() just for fun, either.
Given that I had
Hi Junio,
On Wed, 29 Jun 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > There are a couple of places where return values indicating errors
> > are ignored. Let's teach them manners.
> >
> > Signed-off-by: Johannes Schindelin
> > ---
> > merge-recursive.c | 10 --
> >
Hi Johannes,
Johannes Schindelin gmx.de> writes:
> [...]
>
> My more immediate concern is MSYS2 (the POSIX-emulating basis of Git
for
> Windows), and I opened a Pull Request there:
>
> https://github.com/Alexpux/MSYS2-packages/pull/647
>
> If this Pull Request is not picked up in time
W dniu 2016-07-01 o 08:54, Jeff King pisze:
> On Thu, Jun 30, 2016 at 12:30:31PM +0200, Jakub Narębski wrote:
>
>>> This is one of the open questions. My older patches turned them off when
>>> replacements and grafts are in effect.
>>
>> Well, if you store the cache of generation numbers in the pa
W dniu 2016-07-01 o 05:17, Jeff King pisze:
> On Thu, Jun 30, 2016 at 11:12:52AM -0700, Linus Torvalds wrote:
>
>> I do think that it's ok to cache generation numbers somewhere if there
>> is an algorithm that can make use of them, but every time this comes
>> up, it's just not been important enou
On Fri, Jul 01, 2016 at 10:04:44AM +0200, Johannes Schindelin wrote:
> Hi Peff,
>
> On Fri, 1 Jul 2016, Jeff King wrote:
>
> > I waffled between the two mechanisms. Opinions welcome.
>
> I am happy you took the cmd_main() approach: we do have to play some
> tricks on Windows, in particular in s
Hi Peff,
On Fri, 1 Jul 2016, Jeff King wrote:
> I waffled between the two mechanisms. Opinions welcome.
I am happy you took the cmd_main() approach: we do have to play some
tricks on Windows, in particular in some upcoming changes that support
building with MS Visual C++ (we want to ensure that
Hi Peff,
On Fri, 1 Jul 2016, Jeff King wrote:
> This has been an accident-waiting-to-happen for a long time,
> but wasn't triggered until recently because it involves one
> of those programs actually calling system_path(). That
> happened with git-credential-store in v2.8.0 with ae5f677
> (lazily
We have an abstracted variable; let's use it consistently.
Signed-off-by: Jeff King
---
On top of the cleanup earlier in the thread.
I actually wonder if we should drop the vcs-svn code entirely. The last
update that wasn't just part of a "I'm grepping the whole code base to
change this interfac
A few test-helpers have Makefile dependencies on specific
object files. But since these files are part of libgit.a
(which all of the helpers link against), the inclusion is
simply redundant.
These were once necessary, but became redundant due to
5c5ba73 (Makefile: Use generic rule to build test pr
Hi Peff,
On Fri, 1 Jul 2016, Jeff King wrote:
> - for external programs run as "git foo", you get _two_ times.
I considered doing this in my work-around, but decided against it because
I deemed it too inelegant to call it twice.
But your patch series has more benefits than just fixing the ass
On Fri, Jul 01, 2016 at 09:38:33AM +0200, Johannes Schindelin wrote:
> it is sad when bug reporters simply delete the part of our bug reporting
> template that says: "I searched for existing bug reports but did not find
> any".
>
> It saves the reporters a few minutes... and spends the time of yo
Hi Peff,
it is sad when bug reporters simply delete the part of our bug reporting
template that says: "I searched for existing bug reports but did not find
any".
It saves the reporters a few minutes... and spends the time of you and me
in the hour range.
In this particular case, the bug report i
On Wed, Jun 29, 2016 at 05:59:47PM -0700, Stefan Beller wrote:
> Allow a user to pass information along a push to the pre/post-receive hook
> on the remote.
Seems like a reasonable thing to want, and related to:
http://thread.gmane.org/gmane.comp.version-control.git/285124
which was specifica
On Wed, Jun 29, 2016 at 05:59:48PM -0700, Stefan Beller wrote:
> The environment variable GIT_PUSH_OPTION_FILE is set to the push options
> separated by new line.
>
> The code is not executed as the push options are set to NULL, nor is the
> new capability advertised.
>
> The rationale for keepi
On Thu, Jun 30, 2016 at 12:30:31PM +0200, Jakub Narębski wrote:
> > This is one of the open questions. My older patches turned them off when
> > replacements and grafts are in effect.
>
> Well, if you store the cache of generation numbers in the packfile, or in
> the index of the packfile, or in
100 matches
Mail list logo
