On Tue, Mar 28, 2017 at 11:49 PM, Jeff King wrote:
> On Tue, Mar 28, 2017 at 11:15:12PM +0200, Christian Couder wrote:
>
>> On Sun, Mar 26, 2017 at 3:43 PM, René Scharfe wrote:
>> > FreeBSD implements getcwd(3) as a syscall, but falls back to a version
>> > based on readdir(3) if it fails for som
On 03/29/2017 02:32 AM, Daniel Ferreira wrote:
> Create inline helpers to dir_iterator_advance(). Make
> dir_iterator_advance()'s code more legible and allow some behavior to
> be reusable.
Thanks for breaking up the patches. That makes them a lot easier to review.
> Signed-off-by: Daniel Ferreir
On Tue, Mar 28, 2017 at 03:33:48PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > It's a lot of patches, but hopefully they're all pretty straightforward
> > to read.
>
> Yes, quite a lot of changes. I didn't see anything questionable in
> there.
>
> As to the "patch-id" thing, I find
On Tue, Mar 28, 2017 at 07:17:16PM -0400, Jeffrey Walton wrote:
> I configured with --enable-pthreads, and LIBS included -lpthread.
>
> $ make V=1
> gcc -I/usr/local/include -g -O2 -I. -DHAVE_ALLOCA_H
> -I/usr/local/include -DUSE_CURL_FOR_IMAP_SEND -I/usr/local/include
> -I/usr/local/include -DH
On Tue, Mar 28, 2017 at 09:03:43PM -0400, Jeffrey Walton wrote:
> This looks like the last issue with Git 2.12.2. This time the machine
> is Fedora 25.
>
> I configured with PERL_PATH=/usr/local/bin/perl. The local Perl was
> built specifically for this error, and it includes
> ExtUtils/MakeMaker
Jacob Keller wrote:
> On Tue, Mar 28, 2017 at 10:53 AM, Pickfire wrote:
> >
> > Yes, I can't reproduce it outside the test suite. I have added the builtin
> > and yet the test fails. test_decode_color gets same output as expect but
> > still it fails, should I send in the patch?
>
> You also ne
Stefan Beller wrote:
> On Tue, Mar 28, 2017 at 3:46 AM, Pickfire wrote:
>
> > EOF
> >
> > echo '* diff="cpp"' > .gitmodules
>
> Did you mean .gitattributes?
Yeah, that's a spelling error.
This looks like the last issue with Git 2.12.2. This time the machine
is Fedora 25.
I configured with PERL_PATH=/usr/local/bin/perl. The local Perl was
built specifically for this error, and it includes
ExtUtils/MakeMaker.pm:
$ find /usr/local -name MakeMaker.pm
/usr/local/lib/perl5/5.24.1/ExtUti
Use dir_iterator to traverse through remove_subtree()'s directory tree,
avoiding the need for recursive calls to readdir(). Simplify
remove_subtree()'s code.
A conversion similar in purpose was previously done at 46d092a
("for_each_reflog(): reimplement using iterators", 2016-05-21).
Signed-off-b
Create an option for the dir_iterator API to iterate over subdirectories
only after having iterated through their contents. This feature was
predicted, although not implemented by 0fe5043 ("dir_iterator: new API
for iterating over a directory tree", 2016-06-18).
Add the "flags" parameter to dir_it
Amend a call to dir_iterator_begin() to pass the flags parameter
introduced in 3efb5c0 ("dir_iterator: iterate over dir after its
contents", 2017-28-03).
Signed-off-by: Daniel Ferreira
---
refs/files-backend.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/refs/files-backend
Create inline helpers to dir_iterator_advance(). Make
dir_iterator_advance()'s code more legible and allow some behavior to
be reusable.
Signed-off-by: Daniel Ferreira
---
dir-iterator.c | 65 +-
1 file changed, 42 insertions(+), 23 deletio
Hi there,
This is the fourth version of the GSoC microproject of refactoring
remove_subtree() from recursively using readdir() to use dir_iterator. Below
are the threads for other versions:
v1:
https://public-inbox.org/git/CAGZ79kZwT-9mHTiOJ5CEjk2wDFkn6+NcogjX0=vjhsah16a...@mail.gmail.com/T/#t
v
Test removing a nested directory when an attempt is made to restore the
index to a state where it does not exist. A similar test could be found
previously in t/t2000-checkout-cache-clash.sh, but it did not check for
nested directories, which could allow a faulty implementation of
remove_subtree() p
On Tue, Mar 28, 2017 at 10:27:41AM -0700, Junio C Hamano wrote:
> "brian m. carlson" writes:
>
> > Convert the callers to pass struct object_id by changing the function
> > declaration and definition and applying the following semantic patch:
> >
> > @@
> > expression E1, E2, E3;
> > @@
> > - sha
On Mon, Mar 20, 2017 at 3:34 PM, Brandon Williams wrote:
> That the gist of how I'm hoping to solve the problem. Hopefully that was
> clear enough to get some feedback on.
Junio wrote in "What's cooking in git.git (Mar 2017, #10; Fri, 24)"
> I saw no particular issues myself. Do others find th
Stefan Beller wrote:
> Suppose I have a superproject 'super', with two submodules 'super/sub'
> and 'super/sub1'. 'super/sub' itself contains a submodule
> 'super/sub/subsub'. Now suppose I run, from within 'super':
>
> echo hi >sub/subsub/stray-file
> echo hi >sub1/stray-file
>
> Currentl
Hi,
Stefan Beller wrote:
[...]
> +++ b/t/t7506-status-submodule.sh
[...]
> @@ -287,4 +311,82 @@ test_expect_success 'diff --submodule with merge
> conflict in .gitmodules' '
> test_cmp diff_submodule_actual diff_submodule_expect
> '
>
> +test_expect_success 'setup superproject with untr
+cc Ben Peart, who sent
"[RFC] Add support for downloading blobs on demand" to the list recently.
This proposal here seems like it has the same goal, so maybe your review
could go a long way here?
Thanks,
Stefan
On Tue, Mar 14, 2017 at 3:57 PM, Jonathan Tan wrote:
> As described in "Background"
I configured with --enable-pthreads, and LIBS included -lpthread.
$ make V=1
gcc -I/usr/local/include -g -O2 -I. -DHAVE_ALLOCA_H
-I/usr/local/include -DUSE_CURL_FOR_IMAP_SEND -I/usr/local/include
-I/usr/local/include -DHAVE_PATHS_H -DHAVE_STRINGS_H -DHAVE_DEV_TTY
-DHAVE_CLOCK_GETTIME -DHAVE_CLOCK
v8:
* This is a resend of the last two patches, i.e. these two patches apply
at 5c896f7c3ec (origin/sb/submodule-short-status^^)
* below is a diff of this patch series against origin/sb/submodule-short-status
* add tests showing the subtle bug fix in case of nesting.
* add a bit of documentation
Suppose I have a superproject 'super', with two submodules 'super/sub'
and 'super/sub1'. 'super/sub' itself contains a submodule
'super/sub/subsub'. Now suppose I run, from within 'super':
echo hi >sub/subsub/stray-file
echo hi >sub1/stray-file
Currently we get would see the following out
If I add an untracked file to a submodule or modify a tracked file,
currently "git status --short" treats the change in the same way as
changes to the current HEAD of the submodule:
$ git clone --quiet --recurse-submodules
https://gerrit.googlesource.com/gerrit
$ echo hello >gerri
Jeff King writes:
> It's a lot of patches, but hopefully they're all pretty straightforward
> to read.
Yes, quite a lot of changes. I didn't see anything questionable in
there.
As to the "patch-id" thing, I find the alternate one slightly easier
to read. Also, exactly because this is not a pe
Bloomberg would like to host a Git hackathon over a weekend in both New
York and London, towards the end of April or the beginning of May.
Crucial to the success of the weekend will be having mentors available
in both locations who can guide people on the project. Mentors should
have some experien
On Tue, Mar 28, 2017 at 11:15:12PM +0200, Christian Couder wrote:
> On Sun, Mar 26, 2017 at 3:43 PM, René Scharfe wrote:
> > FreeBSD implements getcwd(3) as a syscall, but falls back to a version
> > based on readdir(3) if it fails for some reason. The latter requires
> > permissions to read and
On Tue, Mar 28, 2017 at 11:24 PM, Stefan Beller wrote:
> On Tue, Mar 28, 2017 at 2:15 PM, Christian Couder
> wrote:
>> On Sun, Mar 26, 2017 at 3:43 PM, René Scharfe wrote:
>>> FreeBSD implements getcwd(3) as a syscall, but falls back to a version
>>> based on readdir(3) if it fails for some reas
On Tue, Mar 28, 2017 at 2:15 PM, Christian Couder
wrote:
> On Sun, Mar 26, 2017 at 3:43 PM, René Scharfe wrote:
>> FreeBSD implements getcwd(3) as a syscall, but falls back to a version
>> based on readdir(3) if it fails for some reason. The latter requires
>> permissions to read and execute pat
On Mon, Mar 27, 2017 at 2:46 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> When a nested submodule has untracked files, it would be reported as
>> "modified submodule" in the superproject, because submodules are not
>> parsed correctly in is_submodule_modified as they are bucketed into
>
On Sun, Mar 26, 2017 at 3:43 PM, René Scharfe wrote:
> FreeBSD implements getcwd(3) as a syscall, but falls back to a version
> based on readdir(3) if it fails for some reason. The latter requires
> permissions to read and execute path components, while the former does
> not. That means that if
Jeff King writes:
> That also means an option to something like "expand" is tough, because
> "first character" really means "first non-ANSI-code character".
That is true, but once you commit to the mindset that you are
extending "expand", then that becomes a mere part of what must be
done, i.e.
On Tue, Mar 28, 2017 at 01:05:40PM -0700, Jacob Keller wrote:
> On Tue, Mar 28, 2017 at 12:03 PM, Junio C Hamano wrote:
> > Jacob Keller writes:
> >
> >> I'm really not a fan of how the ws code ended up. It seems pretty ugly
> >> and weird to hack in the expand_tabs stuff here. However, I'm real
On Tue, Mar 28, 2017 at 03:50:34PM -0400, Jeff Hostetler wrote:
> It was a convenient way to isolate, average, and compare
> read_index() times, but I suppose we could do something
> like that.
>
> I did confirm that a ls-files does show a slight 0.008
> second difference on the 58K file Linux tr
On Tue, Mar 28, 2017 at 12:03 PM, Junio C Hamano wrote:
> Jacob Keller writes:
>
>> I'm really not a fan of how the ws code ended up. It seems pretty ugly
>> and weird to hack in the expand_tabs stuff here. However, I'm really not
>> sure how else I could handle this. Additionally, I'm not 100% s
On Tue, Mar 28, 2017 at 12:40:29PM -0700, Junio C Hamano wrote:
> > Here's that minor tweak, in case anybody is interested. It's less useful
> > without that follow-on that touches "eol" more, but perhaps it increases
> > readability on its own.
>
> Yup, the only thing that the original (with Bri
On Tue, Mar 28, 2017 at 03:46:18PM -0400, Jeff King wrote:
> As a result, the data we feed to the sha1 computation may be
> truncated, and it's possible that a commit with a very long
> filename could erroneously collide in the patch-id space
> with another commit. For instance, if one commit modi
On 3/28/2017 3:16 PM, Jeff King wrote:
On Tue, Mar 28, 2017 at 07:07:30PM +, g...@jeffhostetler.com wrote:
From: Jeff Hostetler
Version 3 of this patch series simplifies this effort to just turn
on/off the hash verification using a "core.checksumindex" config variable.
I've preserved t
Our struct child_process already has its own argv_array.
Let's use that to avoid having to format options into
separate buffers.
Note that we'll need to declare the child process outside of
the run_service_command() helper to do this. But that opens
up a further simplification, which is that the h
We can use xsnprintf to do our truncation check with less
code. The error message isn't as specific, but the point is
that this isn't supposed to trigger in the first place
(because our buffer is big enough to handle any int).
Signed-off-by: Jeff King
---
transport-helper.c | 5 +
1 file cha
We probe the "17/" loose object directory for auto-gc, and
use a local buffer to format the path. We can just use
git_path() for this. It handles paths of any length
(reducing our error handling). And because we feed the
result straight to a system call, we can just use the static
variant.
Note th
There's no need to use the magic "100" when a strbuf can do
it for us.
Signed-off-by: Jeff King
---
combine-diff.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/combine-diff.c b/combine-diff.c
index 59501db99..d3560573a 100644
--- a/combine-diff.c
+++ b/combine-diff.
We format the tag header into a fixed 1024-byte buffer. But
since the tag-name and tagger ident can be arbitrarily
large, we may unceremoniously die with "tag header too big".
Let's just use a strbuf instead.
Note that it looks at first glance like we can just format
this directly into the "buf" s
We generate a reflog message that contains some fixed text
plus a branch name, and use a buffer of size PATH_MAX + 20.
This mostly works if you assume that refnames are shorter
than PATH_MAX, but:
1. That's not necessarily true. PATH_MAX is not always the
filesystem's limit.
2. The "20"
Like the previous commit, we'd like to avoid the assumption
that refs fit into PATH_MAX-sized buffers. These callsites
have an extra twist, though: they write the refnames using
mksnpath. This does two things beyond a regular snprintf:
1. It quietly writes "/bad-path/" when truncation occurs.
When name-rev needs to format an actual name, we do so into
a fixed-size buffer. That includes the actual ref tip, as
well as any traversal information. Since refs can exceed
1024 bytes, this means you can get a bogus result. E.g.,
doing:
git tag $(perl -e 'print join("/", 1..1024)')
git des
We'd prefer to avoid unchecked snprintf calls because
truncation can lead to unexpected results.
These are all cases where truncation shouldn't ever happen,
because the input to snprintf is fixed in size. That makes
them candidates for xsnprintf(), but it's simpler still to
just use the heap, and
Part of the reflog content comes from the environment, which
can be much larger than our fixed buffer. Let's use a heap
buffer so we avoid truncating it.
Signed-off-by: Jeff King
---
builtin/fetch.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/builtin/fetch.c b/built
Many functions which handle refs use a PATH_MAX-sized buffer
to do so. This is mostly reasonable as we have to write
loose refs into the filesystem, and at least on Linux the 4K
PATH_MAX is big enough that nobody would care. But:
1. The static PATH_MAX is not always the filesystem limit.
2. O
These calls to snprintf should always succeed, because their
input is small and fixed. Let's use xsnprintf to make sure
this is the case (and to make auditing for actual truncation
easier).
These could be candidates for turning into heap buffers, but
they fall into a few broad categories that make
To generate a patch id, we format the diff header into a
fixed-size buffer, and then feed the result to our sha1
computation. The fixed buffer has size '4*PATH_MAX + 20',
which in theory accomodates the four filenames plus some
extra data. Except:
1. The filenames may not be constrained to PATH_
In create_branch() we write the reflog msg into a buffer in
the main function, but then use it only inside a
conditional. If you carefully follow the logic, you can
confirm that we never use the buffer uninitialized nor write
when it would not be used. But we can make this a lot more
obvious by sim
After receive-pack reads the pack header from the client, it
feeds the already-read part to index-pack and unpack-objects
via their --pack-header command-line options. To do so, we
format it into a fixed buffer, then duplicate it into the
child's argv_array.
Our buffer is long enough to handle an
Since git_path_buf() is smart enough to replace "objects/"
with the correct object path, we can use it instead of
manually assembling the path. That's slightly shorter, and
will clean up any non-canonical bits in the path.
Signed-off-by: Jeff King
---
environment.c | 6 ++
1 file changed, 2
The odb_mkstemp() function expects the caller to provide a
fixed buffer to write the resulting tempfile name into. But
it creates the template using snprintf without checking the
return value. This means we could silently truncate the
filename.
In practice, it's unlikely that the truncation would
The odb_mkstemp function does not return an error; it dies
on failure instead. But many of its callers compare the
resulting descriptor against -1 and die themselves.
Mostly this is just pointless, but it does raise a question
when looking at the callers: if they show the results of the
"template"
Our code base calls snprintf() into a fixed-size buffer in a bunch of
places. Sometimes we check the result, and sometimes we accept a silent
truncation. In some cases an overflow is easy given long input. In some
cases it's impossible. And in some cases it depends on how big PATH_MAX
is on your fi
Jeff King writes:
> Here's that minor tweak, in case anybody is interested. It's less useful
> without that follow-on that touches "eol" more, but perhaps it increases
> readability on its own.
Yup, the only thing that the original (with Brian's fix) appears to
be more careful about is it tries
On Tue, Mar 28, 2017 at 11:51:49AM -0700, Jonathan Nieder wrote:
> > * jc/merge-drop-old-syntax (2015-04-29) 1 commit
> >
> > This topic stops "git merge HEAD " syntax that
> > has been deprecated since October 2007 (and we have issued a
> > warning message since around v2.5.0 when the anci
On Tue, Mar 28, 2017 at 07:07:30PM +, g...@jeffhostetler.com wrote:
> From: Jeff Hostetler
>
> Version 3 of this patch series simplifies this effort to just turn
> on/off the hash verification using a "core.checksumindex" config variable.
>
> I've preserved the original checksum validation
From: Jeff Hostetler
Version 3 of this patch series simplifies this effort to just turn
on/off the hash verification using a "core.checksumindex" config variable.
I've preserved the original checksum validation code so that we can
force it on in fsck if desired.
It eliminates the original threa
From: Jeff Hostetler
Created test helper to measure read_index() with and without
core.checksumindex set and report performance.
Signed-off-by: Jeff Hostetler
---
Makefile| 1 +
t/helper/.gitignore | 1 +
t/helper/test-core-checksum-index.c | 77 ++
From: Jeff Hostetler
Teach git to skip verification of the index SHA in verify_hdr()
in read_index().
This is a performance optimization. The index file SHA verification
can be considered an ancient relic from the early days of git and only
useful for detecting disk corruption. For small repos
Jacob Keller writes:
> I'm really not a fan of how the ws code ended up. It seems pretty ugly
> and weird to hack in the expand_tabs stuff here. However, I'm really not
> sure how else I could handle this. Additionally, I'm not 100% sure
> whether this interacts with format-patch or other machine
On Tue, Mar 28, 2017 at 11:35 AM, Junio C Hamano wrote:
> There are two topics that are marked as "Will cook in 'next'" for
> practically forever in the "What's cooking" reports. The world may
> have become ready for one or both of them, in which case we should
> do the merge not too late in the
Hi Junio,
Junio C Hamano wrote:
> There are two topics that are marked as "Will cook in 'next'" for
> practically forever in the "What's cooking" reports. The world may
> have become ready for one or both of them, in which case we should
> do the merge not too late in the cycle.
>
> * jc/merge-d
There are two topics that are marked as "Will cook in 'next'" for
practically forever in the "What's cooking" reports. The world may
have become ready for one or both of them, in which case we should
do the merge not too late in the cycle.
* jc/merge-drop-old-syntax (2015-04-29) 1 commit
This
On Mon, Mar 27, 2017 at 6:39 PM, Robert Stanca wrote:
> Replaces recursive traversing of opendir with dir_iterator.
>
> Signed-off-by: Robert Stanca
> ---
> builtin/repack.c | 15 ++-
> 1 file changed, 6 insertions(+), 9 deletions(-)
>
> diff --git a/builtin/repack.c b/builtin/repack
Andreas Krey wrote:
> On Tue, 21 Mar 2017 13:33:35 +, Jeff King wrote:
>> Probably "format-patch | sed | am -3" is your best bet if you want to
>> modify the patches in transit _and_ have the user just use normal git
>> tools.
>
> Except that 'git am' doesn't have --no-commit like cherry-pick
On Tue, Mar 28, 2017 at 3:46 AM, Pickfire wrote:
> EOF
>
> echo '* diff="cpp"' > .gitmodules
Did you mean .gitattributes?
On Tue, Mar 28, 2017 at 10:53 AM, Pickfire wrote:
>
> Yes, I can't reproduce it outside the test suite. I have added the builtin
> and yet the test fails. test_decode_color gets same output as expect but
> still it fails, should I send in the patch?
You also need to ensure you have the exact same
On Sat, Mar 25, 2017 at 8:15 PM, Daniel Ferreira (theiostream)
wrote:
> SYNOPSIS
> There are many advantages to converting parts of git that are still
> scripts to C builtins, among which execution speed, improved
> compatibility and code deduplication.
agreed.
> git-add--interactive, one of th
Jacob Keller wrote:
> On Tue, Mar 28, 2017 at 3:46 AM, Pickfire wrote:
> > While I was working buildins shell patterns for user diffs. I noticed that
> > the tests t4034 passes but I can reproduce it manually with:
> >
> > mkdir cpp/ && cd cpp/ && git init
> >
> > cat > pre < > Foo()
On Tue, Mar 28, 2017 at 01:35:36PM -0400, Jeff King wrote:
> I thought I'd knock this out quickly before I forgot about it. But it
> actually isn't so simple.
>
> The main caller in read_head_info() does indeed just pass strlen(line)
> as the length in each case. But the cert parser really does n
On Tue, Mar 28, 2017 at 11:13:15AM +, brian m. carlson wrote:
> > I suggested an additional cleanup around "linelen" in one patch. In the
> > name of keeping the number of re-rolls sane, I'm OK if we skip that for
> > now (the only reason I mentioned it at all is that you have to justify
> > t
Jeff King writes:
> On Sun, Mar 26, 2017 at 04:01:22PM +, brian m. carlson wrote:
>
>> This is part 7 in the continuing transition to use struct object_id.
>>
>> This series focuses on two main areas: adding two constants for the
>> maximum hash size we'll be using (which will be suitable fo
"brian m. carlson" writes:
> Convert the callers to pass struct object_id by changing the function
> declaration and definition and applying the following semantic patch:
>
> @@
> expression E1, E2, E3;
> @@
> - sha1_array_append(E1, E2[E3].hash)
> + sha1_array_append(E1, E2 + E3)
>
> @@
> expres
On Sat, Mar 25, 2017 at 11:12 AM, Daniel Ferreira wrote:
> This is the third version of the GSoC microproject
> of refactoring remove_subtree() from recursively using
> readdir() to use dir_iterator. Below are the threads for
> other versions:
>
> v1:
> https://public-inbox.org/git/CAGZ79kZwT-9mH
Jeff King writes:
> The patch itself is obviously an improvement. It may be worth graduating
> separately from the rest of the series.
Yup, I will split it out to bc/push-cert-receive-fix that builds
directly on an ancient jc/push-cert topic that was merged at
v2.2.0-rc0~64.
I'll need to drop t
> * sb/submodule-short-status (2017-03-27) 7 commits
> - submodule.c: correctly handle nested submodules in is_submodule_modified
> - short status: improve reporting for submodule changes
> - submodule.c: stricter checking for submodules in is_submodule_modified
> - submodule.c: port is_submodu
On Tue, Mar 28, 2017 at 07:52:42AM +0200, Christian Couder wrote:
> Hi,
>
> On Tue, Mar 28, 2017 at 12:17 AM, Devin Lehmacher wrote:
> > Hello everyone,
> >
> > I am a student studying Computer Science at Cornell University. I
> > already completed a microproject, Move ~/.git-credential-cache/sock
On Tue, Mar 28, 2017 at 11:27:19AM -0400, Jeff Hostetler wrote:
> > Hrm, there shouldn't be any dependency of the config on the index (and
> > there are a handful of options which impact the index already). Did you
> > try it and run into problems?
>
> Yeah, I tried adding a new "core.verifyindex
On Fri, Mar 24, 2017 at 8:42 PM, Jeff King wrote:
> On Thu, Mar 23, 2017 at 04:29:18PM +0100, SZEDER Gábor wrote:
>> case "$cur_" in
>> refs|refs/*)
>> format="refname"
>> - refs="${cur_%/*}"
>> + refs=("$mat
On 3/27/2017 6:45 PM, Jeff King wrote:
On Mon, Mar 27, 2017 at 09:09:37PM +, g...@jeffhostetler.com wrote:
From: Jeff Hostetler
Version 2 of this patch series simplifies this to just
turn off the hash verification. Independent comments
from Linus and Peff suggested that we could just t
On 3/27/2017 6:44 PM, Jeff King wrote:
On Mon, Mar 27, 2017 at 09:09:38PM +, g...@jeffhostetler.com wrote:
From: Jeff Hostetler
Teach git to skip verification of the index SHA in read_index().
This is a performance optimization. The index file SHA verification
can be considered an anc
---
FWIW here's the current state of this WIP hack which I worked a bit on
yesterday. I converted it to use a hashmap and got rid of the need to
s/const // the options struct.
I've either converted options that read the config to this already, or
left TODO comments on those that are candidates fo
On Tue, Mar 28, 2017 at 3:46 AM, Pickfire wrote:
> While I was working buildins shell patterns for user diffs. I noticed that
> the tests t4034 passes but I can reproduce it manually with:
>
> mkdir cpp/ && cd cpp/ && git init
>
> cat > pre < Foo():x(0&&1){}
> cout<<"Hello World!\n
From: Jacob Keller
When creating a diff for contents, we prepend a single character to
represent the state of that line. This character can offset how the tabs
in the real content are displayed, which may result in weird alignment
issues when viewing the diffs. Teach the diff core a new option to
From: Jacob Keller
In commit 7cc13c717b52 ("pretty: expand tabs in indented logs to make
things line up properly", 2016-03-16) a new function was added to insert
a line into a strbuf while expanding the tabs into spaces. This
functionality was used to help show the log message correctly when it
h
On Tue, 21 Mar 2017 13:33:35 +, Jeff King wrote:
...
> Probably "format-patch | sed | am -3" is your best bet if you want to
> modify the patches in transit _and_ have the user just use normal git
> tools.
Except that 'git am' doesn't have --no-commit like cherry-pick does. :-(
It's always som
On Tue, Mar 28, 2017 at 03:31:59AM -0400, Jeff King wrote:
> I read through the whole series and didn't find anything objectionable.
> The pointer-arithmetic fix should perhaps graduate separately.
Junio's welcome to take that patch separately if he likes.
> I suggested an additional cleanup arou
While I was working buildins shell patterns for user diffs. I noticed that
the tests t4034 passes but I can reproduce it manually with:
mkdir cpp/ && cd cpp/ && git init
cat > pre b
ab a>=b
a==b a!=b
a&b
a
> On 28 Mar 2017, at 00:35, Junio C Hamano wrote:
> ...
>
> * ls/filter-process-delayed (2017-03-06) 1 commit
> - convert: add "status=delayed" to filter process protocol
>
> What's the status of this one???
> cf.
I was about to send out a new round last Sunday but then
I discovered a problem
On Sun, Mar 26, 2017 at 04:01:22PM +, brian m. carlson wrote:
> This is part 7 in the continuing transition to use struct object_id.
>
> This series focuses on two main areas: adding two constants for the
> maximum hash size we'll be using (which will be suitable for allocating
> memory) and
On Sun, Mar 26, 2017 at 04:01:38PM +, brian m. carlson wrote:
> diff --git a/transport.c b/transport.c
> index 8a90b0c29b..e492757726 100644
> --- a/transport.c
> +++ b/transport.c
> @@ -1027,7 +1027,8 @@ int transport_push(struct transport *transport,
>
> for (; ref; r
On Sun, Mar 26, 2017 at 04:01:37PM +, brian m. carlson wrote:
> Make the internal storage for struct sha1_array use an array of struct
> object_id internally. Update the users of this struct which inspect its
> internals.
Yay. I'm happy to see all those gross (*sha1)[20] bits go away.
-Peff
On Sun, Mar 26, 2017 at 04:01:29PM +, brian m. carlson wrote:
> Convert some hardcoded constants into uses of parse_oid_hex.
> Additionally, convert all uses of struct command, and miscellaneous
> other functions necessary for that. This work is necessary to be able
> to convert sha1_array_ap
96 matches
Mail list logo
