Brandon Williams writes:
> +/*
> + * Read a packetized line into a buffer like the 'packet_read()' function but
> + * returns an 'enum packet_read_status' which indicates the status of the
> read.
> + * The number of bytes read will be assigined to *pktlen if the status of the
> + * read was 'PA
This is v2 of my attempt at stopping shortlog from BUG-ing when it is
used incorrectly outside a repo. Thanks Jonathan and Junio for helpful
comments.
Patches 1 and 2 are identical to pu. The error message in patch 3 is now
more general. The error condition on the other hand is a bit more
specific
This has been missing since we learned to print usage, way back in
4e27fb06f (add commit count options to git-shortlog, 2006-10-06).
While at it, drop the [] around "...". This matches `git log -h`
and Documentation/git-{short}log.txt. It formally makes it look like we
do not allow `git shortlog -
The first usage we give is the original one where, e.g., `git log` is
piped through `git shortlog`. The description that follows reads the
other way round, by first focusing on the general behavior, then ending
with the behavior when reading from stdin.
It is also a tiny bit odd that what is proba
If we are outside a repo and have any arguments left after
option-parsing, `setup_revisions()` will try to do its job and
something like this will happen:
$ git shortlog v2.16.0..
BUG: environment.c:183: git environment hasn't been setup
Aborted (core dumped)
The usage is wrong, but we could obvi
When introducing the stash push feature, and thus allowing users to pass
in a pathspec to limit the files that would get stashed in
df6bba0937 ("stash: teach 'push' (and 'create_stash') to honor
pathspec", 2017-02-28), this developer missed one place where the
pathspec should be passed in.
Namely
Currently 'git stash push -u -- ' prints the following errors
if only matches untracked files:
fatal: pathspec 'untracked' did not match any files
error: unrecognized input
This is because we first clean up the untracked files using 'git clean
', and then use a command chain involving 'g
Signed-off-by: Ramsay Jones
---
Hi Junio,
I happened to be building git on an _old_ laptop earlier this evening
and gcc complained, thus:
CC http.o
http.c:77:20: warning: ‘curl_no_proxy’ defined but not used
[-Wunused-variable]
static const char *curl_no_proxy;
Jonathan Tan writes:
> When doing a partial clone or fetch with transfer.fsckobjects=1, use the
> --fsck-objects instead of the --strict flag when invoking index-pack so
> that links are not checked, only objects. This is because incomplete
> links are expected when doing a partial clone or fetch
Brandon Williams writes:
> Introduce git-serve, the base server for protocol version 2.
> ...
> Documentation/Makefile | 1 +
> Documentation/technical/protocol-v2.txt | 174 +
asciidoc: ERROR: protocol-v2.txt: line 20: only book doctypes can contain level
0 s
Hi,
Ramsay Jones wrote:
> Signed-off-by: Ramsay Jones
> ---
>
> Hi Junio,
>
> I happened to be building git on an _old_ laptop earlier this evening
> and gcc complained, thus:
>
> CC http.o
> http.c:77:20: warning: ‘curl_no_proxy’ defined but not used
> [-Wunused-variable]
>static c
On Wed, Mar 14, 2018 at 09:56:06PM +, Ramsay Jones wrote:
> Signed-off-by: Ramsay Jones
> ---
>
> Hi Junio,
>
> I happened to be building git on an _old_ laptop earlier this evening
> and gcc complained, thus:
>
> CC http.o
> http.c:77:20: warning: ‘curl_no_proxy’ defined but not u
On Wed, Mar 14, 2018 at 05:56:04PM +0100, Lars Schneider wrote:
> I am investigating a Git merge (a86dd40fe) in which an older version of
> a file won over the newer version. I try to understand why this is the
> case. I can reproduce the merge with the following commands:
> $ git checkout -b te
On Wed, 14 Mar 2018 14:55:31 -0700
Junio C Hamano wrote:
> Jonathan Tan writes:
>
> > When doing a partial clone or fetch with transfer.fsckobjects=1, use the
> > --fsck-objects instead of the --strict flag when invoking index-pack so
> > that links are not checked, only objects. This is becaus
Ævar Arnfjörð Bjarmason writes:
> This small series makes USE_LIBPCRE=YesPlease mean
> USE_LIBPCRE2=YesPlease, instead of USE_LIBPCRE1=YesPlease is it does
> now. Along the way I fixed a couple of minor issues in the PCRE
> detection in the autoconf script.
>
> Ævar Arnfjörð Bjarmason (3):
> c
On 14/03/18 22:15, Jeff King wrote:
> On Wed, Mar 14, 2018 at 09:56:06PM +, Ramsay Jones wrote:
>
>> Signed-off-by: Ramsay Jones
>> ---
>>
>> Hi Junio,
>>
>> I happened to be building git on an _old_ laptop earlier this evening
>> and gcc complained, thus:
>>
>> CC http.o
>> http.c:
On 14/03/2018 15:24, Sergey Organov wrote:
>
> > > Second side note: if we can fast-forward, currently we prefer that, and I
> > > think we should keep that behavior with -R, too.
> >
> > I agree.
>
> I'm admittedly somewhat lost in the discussion, but are you talking
> fast-forward on _rebasing_
Hi Sergey,
On 14/03/2018 08:21, Sergey Organov wrote:
>
> There are still 2 issues about the implementation that need to be
> discussed though:
>
> 1. Still inverted order of the second merge compared to RFC.
>
> It'd be simple to "fix" again, except I'm not sure it'd be better, and
> as there
This email just won a sum of €5,000,000. For claims, Send your NAME, AGE &
TELEPHONE NUMBER to: mastercard-awa...@columbus.rr.com
On Wed, Mar 14, 2018 at 11:01:01PM +, Ramsay Jones wrote:
> >> The version of libcurl installed was 0x070f04. So, while it was fresh in my
> >> mind, I applied and tested this patch.
> >
> > Makes sense. This #if would go away under my "do not support antique
> > curl versions" proposal. I ha
On Wed, Mar 14, 2018 at 10:31:37AM -0700, Junio C Hamano wrote:
> "brian m. carlson" writes:
>
> > -+ buf += the_hash_algo->rawsz;
> > -+ size -= the_hash_algo->rawsz;
> > ++ memcpy(it->oid.hash, (const unsigned char*)buf, rawsz);
> > ++
On Wed, Mar 14, 2018 at 09:48:30AM -0700, Junio C Hamano wrote:
> As always, thanks for working on this.
>
> After this series, what jumps at me out of output from
>
> git grep -e '[^0-9A-Za-z_][24]0[^0-9A-Za-z_]' -- '*.[ch]' \
> ':!*sha1*' ':!contrib/' ':!compat/'
>
> are co
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.
You can find the changes described
Do you need a loan
Hi Buga,
Igor Djordjevic writes:
> On 14/03/2018 15:24, Sergey Organov wrote:
[...]
>> Thinking about it I've got an idea that what we actually need is
>> --no-flatten flag that, when used alone, will just tell "git rebase" to
>> stop flattening history, and which will be implicitly imposed by
>
On Thu, Mar 15, 2018 at 2:34 AM, Junio C Hamano wrote:
> * nd/pack-objects-pack-struct (2018-03-05) 9 commits
> - pack-objects: reorder 'hash' to pack struct object_entry
> - pack-objects: refer to delta objects by index instead of pointer
> - pack-objects: move in_pack out of struct object_ent
101 - 126 of 126 matches
Mail list logo
