Junio C Hamano wrote:
> Jonathan Nieder writes:
>> I find --ignore-removal fairly easy to understand, and I had no idea
>> what --overlay would mean.
>>
>> I realize this is just one user's experience.
>
> Exactly. My impression was the exact opposite from yours.
>
> The phrase "removal" in the
On Thu, Jan 24, 2019 at 08:46:54AM -0800, Elijah Newren wrote:
> The critical part of the patch is the few line change to
> show_raw_diff(), the rest is plumbing to set that up.
>
> This patch was based out of Peff's suggestion[1] to fix diff-tree to
> do what I needed rather than bending fast-exp
On Thu, Jan 24, 2019 at 06:13:31PM +0200, Arti Zirk wrote:
> With this patch it is possible to launch git-instaweb by using
> Python 3 http.server CGI handler via `-d python` option.
>
> git-instaweb generates a small wrapper around the http.server
> (in GIT_DIR/gitweb/) that address a limitation
On Thu, Jan 24, 2019 at 08:11:05AM -0500, Jeff King wrote:
> I've mentioned before that I have a series which compiles cleanly with
> -Wunused-parameters. I split this work roughly into three groups:
>
> 1. Patches that fix bugs (i.e., we should have been using the
> parameter but didn't).
I need a custom merge strategy (not driver) for a tool I’m writing, and I’m
wondering:
1. Is there documentation for the API anywhere?
2. Does git-merge actually do any magic, or could I just run the script that
implements my merge directly? In other words, is there really any difference
betw
Rename the packing_data lock to obd_lock and upgrade it to a recursive
mutex to make it suitable for current read_lock usages. Additionally
remove the superfluous #ifndef NO_PTHREADS guard around mutex
initialization in prepare_packing_data as the mutex functions
themselves are already protected.
ac77d0c37 ("pack-objects: shrink size field in struct object_entry",
2018-04-14) added an extra usage of read_lock/read_unlock in the newly
introduced oe_get_size_slow for thread safety in parallel calls to
try_delta(). Unfortunately oe_get_size_slow is also used in serial
code, some of which is ca
Hi,
I monitor a couple of Git repos by reviewing changes via:
% git pull
% git log -p -w --no-merges ORIG_HEAD..
This works wonderfully for me. However, sometimes I have pending
changes in my repo (because I did not yet committed them to a new
branch). I thought I could simply use
% git pull
On Thu, Jan 24, 2019 at 2:49 PM Junio C Hamano wrote:
>
> Duy Nguyen writes:
>
> > On Thu, Jan 24, 2019 at 8:06 AM Patrick Hogg wrote:
> >> diff --git a/pack-objects.h b/pack-objects.h
> >> index 0a038e3bc..dc869f26c 100644
> >> --- a/pack-objects.h
> >> +++ b/pack-objects.h
> >> @@ -146,7 +146,
"Derrick Stolee via GitGitGadget" writes:
> This series is based on ab/commit-graph-write-progress and bc/sha-256.
Thanks.
It seems that the base (i.e. merge between these two topics) you
used may have used a version of either topic (most likely the
latter) slightly older than what I have, as p
"Derrick Stolee via GitGitGadget" writes:
> The commit-graph file format has some shortcomings that were discussed
> on-list:
> ...
> This series adds a new version (2) to the commit-graph file.
Sigh. It is unfortunate that we have to bump the format version
this early before we can say "it is
Jonathan Nieder writes:
> I find --ignore-removal fairly easy to understand, and I had no idea
> what --overlay would mean.
>
> I realize this is just one user's experience.
Exactly. My impression was the exact opposite from yours.
The phrase "removal" in the context of checkout does not click
[I’m resending this as I clicked on the wrong button…]
Hi,
Le 24/01/2019 à 22:54, Junio C Hamano a écrit :
> Alban Gruin writes:
>
> Before I comment on anything else.
>
> > This is based on nd/the-index (36e7ed69de, "rebase-interactive.c: remove
> > the_repository references").
>
> My attemp
> Updates in V4:
>
> * More 'verb' and 'command' instances replaced with 'subcommand'. I grepped
>the patch to check these should be fixed everywhere.
>
>
> * Update the tests to check .keep files (in last patch).
>
>
> * Modify the tests to show the terminating condition of
On 01/23, Jonathan Nieder wrote:
> Thomas Gummerer wrote:
> > On 01/22, Jonathan Nieder wrote:
>
> > As checkout is a porcelain command, I had hoped it would be okay to
> > also have this as a configuration option, for the time before
> > 'checkout-paths' exists and while I'm getting used to actua
On 01/23, Jonathan Nieder wrote:
> Hi,
>
> Junio C Hamano wrote:
> > Thomas Gummerer writes:
> >> Jonathan Nieder wrote:
>
> >>> Is this analogous to "git add --ignore-removal"? If so, can we just
> >>> call it --ignore-removal?
> >>
> >> Yes, it seems like they are very similar.
> >
> > Hmm, I
Alban Gruin writes:
Before I comment on anything else.
> This is based on nd/the-index (36e7ed69de, "rebase-interactive.c: remove
> the_repository references").
My attempt to apply these in order on top of that commit seems to
stop at step 5/16. Are you sure you based them on it?
Thanks.
From: Derrick Stolee
To repack using a multi-pack-index, first sort all pack-files by
their modified time. Second, walk those pack-files from oldest
to newest, adding the packs to a list if they are smaller than the
given pack-size. Finally, collect the objects from the multi-pack-
index that are
From: Derrick Stolee
The 'git multi-pack-index expire' subcommand may delete packs that
are not needed from the perspective of the multi-pack-index. If
a pack has a .keep file, then we should not delete that pack. Add
a test that ensures we preserve a pack that would otherwise be
expired. First,
From: Derrick Stolee
The 'git multi-pack-index expire' subcommand looks at the existing
mult-pack-index, counts the number of objects referenced in each
pack-file, deletes the pack-fils with no referenced objects, and
rewrites the multi-pack-index to no longer reference those packs.
Refactor the
From: Derrick Stolee
In an environment where the multi-pack-index is useful, it is due
to many pack-files and an inability to repack the object store
into a single pack-file. However, it is likely that many of these
pack-files are rather small, and could be repacked into a slightly
larger pack-fi
From: Derrick Stolee
We will add new subcommands to the multi-pack-index, and that will
make the documentation a bit messier. Clean up the 'verb'
descriptions by renaming the concept to 'subcommand' and removing
the reference to the object directory.
Helped-by: Stefan Beller
Helped-by: Szeder G
From: Derrick Stolee
The multi-pack-index tracks objects in a collection of pack-files.
Only one copy of each object is indexed, using the modified time
of the pack-files to determine tie-breakers. It is possible to
have a pack-file with no referenced objects because all objects
have a duplicate
From: Derrick Stolee
In anticipation of the expire subcommand, refactor the way we sort
the packfiles by name. This will greatly simplify our approach to
dropping expired packs from the list.
First, create 'struct pack_info' to replace 'struct pack_pair'.
This struct contains the necessary infor
From: Derrick Stolee
Before writing the multi-pack-index, we compute the length of the
pack-index names concatenated together. This forms the data in the
pack name chunk, and we precompute it to compute chunk offsets.
The value is also modified to fit alignment needs.
Previously, this computatio
From: Derrick Stolee
During development of the multi-pack-index expire subcommand, a
version went out that improperly computed the pack order if a new
pack was introduced while other packs were being removed. Part of
the subtlety of the bug involved the new pack being placed before
other packs th
From: Derrick Stolee
The repack builtin deletes redundant pack-files and their
associated .idx, .promisor, .bitmap, and .keep files. We will want
to re-use this logic in the future for other types of repack, so
pull the logic into 'unlink_pack_path()' in packfile.c.
The 'ignore_keep' parameter i
The multi-pack-index provides a fast way to find an object among a large
list of pack-files. It stores a single pack-reference for each object id, so
duplicate objects are ignored. Among a list of pack-files storing the same
object, the most-recently modified one is used.
Create new subcommands fo
On Tue, Jan 22, 2019 at 12:23:55PM -0800, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> >> + sha1_abbr_src=$(GIT_DIR="$name/.git" git rev-parse --short
> >> $sha1_src)
> >
> > How about `git -C "$name" rev-parse --short`? That would less likely run
> > over 80 columns/line, e
Signed-off-by: Kyle Meyer
---
Documentation/git-init.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt
index 057076ca38..32880aafb0 100644
--- a/Documentation/git-init.txt
+++ b/Documentation/git-init.txt
@@ -128,7 +128
> Thanks for the suggestion.
>
> It is slightly wrong, in that we don't sort by size. Instead we sort by
> modified time. That makes is a little complicated, but I'll give it
> another shot using your framing:
>
> Create a new pack-file containing objects in small pack-files
>
On Thu, Jan 24, 2019 at 11:30:20AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > What if you have other atoms that need worktrees? E.g., does
> > %(worktreepath:foo) use the same used_atom slot? What if we have another
> > worktree-related atom?
> > ...
> > And that one is a good exampl
On Thu, Jan 24, 2019 at 01:12:15PM -0800, Junio C Hamano wrote:
> Joey Hess writes:
>
> > When a worktree file is larger than the available memory, and a clean
> > filter is in use, this avoids mallocing a buffer the whole size of the
> > file when reading from the clean filter, which caused com
On Thu, Jan 24, 2019 at 12:36:38PM -0800, Stefan Beller wrote:
> > - In an if() block we enter when o->emitted_symbols is set, there
> >is a check to see if o->color_moved is set. This makes sense
> >only if we are trying to be prepared to handle a case where we
> >are not the one th
On Thu, Jan 24, 2019 at 12:18:41PM -0800, Junio C Hamano wrote:
> I did not like the complexity of that "emitted symbols" conversion
> we had to do recently and never trusted the code. There still is
> something funny in diff_flush_patch_all_file_pairs() even after this
> patch, though.
>
> - W
Jeff King writes:
> On Thu, Jan 24, 2019 at 06:34:29PM +, Lucy Phipps wrote:
>
>> honestly i just like optimizing files. the test images still work but
>> one of them is half the size as before. i don't know if it needs to be
>> bigger. it doesn't make any actual difference
>
> I'm not sure i
When have conflict in interactive rebase then git write such message:
Auto-merging hey
CONFLICT (content): Merge conflict in hey
error: could not apply cd79304... 4
Resolve all conflicts manually, mark them as resolved with
"git add/rm ", then run "git rebase --continue".
Yo
Joey Hess writes:
> When a worktree file is larger than the available memory, and a clean
> filter is in use, this avoids mallocing a buffer the whole size of the
> file when reading from the clean filter, which caused commands like git
> status and git commit to OOM.
>
> Often in this situation
Arti Zirk writes:
> With this patch it is possible to launch git-instaweb by using
> Python 3 http.server CGI handler via `-d python` option.
>
> git-instaweb generates a small wrapper around the http.server
> (in GIT_DIR/gitweb/) ...
I know this follows an existing pattern (psgi and webrick als
On Thu, Jan 24, 2019 at 12:18 PM Junio C Hamano wrote:
>
> Jeff King writes:
>
> > When we run "git log --cc --stat -p --color-moved" starting at D, we get
> > this sequence of events:
> >
> > 1. The diff for D is using -p, so diff_flush() calls into
> > diff_flush_patch_all_file_pairs().
When a worktree file is larger than the available memory, and a clean
filter is in use, this avoids mallocing a buffer the whole size of the
file when reading from the clean filter, which caused commands like git
status and git commit to OOM.
Often in this situation the clean filter will produce a
Jeff King writes:
> The patches themselves are pretty much independent from each other. I
> based these on master. They're cleanup which _could_ go to maint, and I
> suspect they'd apply there, too (most of these are pretty old), but
> again, I don't think there's a particular urgency to this.
T
On Thu, Jan 24, 2019 at 4:26 AM Jeff King wrote:
>
> This started as a follow-up to my "something like this" bug-fix from
> last July:
>
> https://public-inbox.org/git/20180710203438.gb6...@sigill.intra.peff.net/
>
> (better late than never). But in the course of that, I discovered
> another real
Jeff King writes:
> When we run "git log --cc --stat -p --color-moved" starting at D, we get
> this sequence of events:
>
> 1. The diff for D is using -p, so diff_flush() calls into
> diff_flush_patch_all_file_pairs(). There we see that o->color_moved
> is in effect, so we point o->em
On Thu, Jan 24, 2019 at 11:14:15AM -0800, Stefan Beller wrote:
> On Thu, Jan 24, 2019 at 4:35 AM Jeff King wrote:
>
> > Note that we have to tweak t4013's setup a bit to test this case, as the
> > existing merges do not have any --summary results against their first
> > parent. But since the mer
Jeff King writes:
> What if you have other atoms that need worktrees? E.g., does
> %(worktreepath:foo) use the same used_atom slot? What if we have another
> worktree-related atom?
> ...
> And that one is a good example where we _do_ need the global, because we
> already have multiple atoms pulli
On Thu, Jan 24, 2019 at 02:18:36PM -0500, Jeff King wrote:
> > I did some benchmarking, using cat as the clean filter:
> > [...]
> > From this, it looks like the file has to be quite large before the
> > preallocation makes a sizable improvement to runtime, and the
> > smudge/clean filters have to
On Thu, Jan 24, 2019 at 11:27:36AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > If anything, I'd suggest going in the opposite direction, and teaching
> > the worktree code a function for looking up a working tree by ref. And
> > then it can handle its own cache to implement that rever
Nguyễn Thái Ngọc Duy writes:
> This was noticed by Ramsay [1] and I almost forgot.
>
> [1]
> http://public-inbox.org/git/419519f9-1b48-93bb-eead-eacf6b383...@ramsayjones.plus.com
Not forgetting is good ;-)
> diff --git a/repository.c b/repository.c
> --- a/repository.c
> +++
On 1/23/2019 5:38 PM, Jonathan Tan wrote:
diff --git a/Documentation/git-multi-pack-index.txt
b/Documentation/git-multi-pack-index.txt
index 6186c4c936..cc63531cc0 100644
--- a/Documentation/git-multi-pack-index.txt
+++ b/Documentation/git-multi-pack-index.txt
@@ -36,6 +36,17 @@ expire::
On 24/01/2019 19:18, Derrick Stolee wrote:
> On 1/24/2019 1:15 PM, Junio C Hamano wrote:
>> Derrick Stolee writes:
>>
>>> Here is today's test coverage report.
>>>
>>> Also, there has been some feedback that it can be hard to manually
>>> match up uncovered lines with names at the bottom of the
Duy Nguyen writes:
> On Thu, Jan 24, 2019 at 8:06 AM Patrick Hogg wrote:
>> diff --git a/pack-objects.h b/pack-objects.h
>> index 0a038e3bc..dc869f26c 100644
>> --- a/pack-objects.h
>> +++ b/pack-objects.h
>> @@ -146,7 +146,6 @@ struct packing_data {
>> struct packed_git **in_pack;
>>
>>
Jeff King writes:
> If anything, I'd suggest going in the opposite direction, and teaching
> the worktree code a function for looking up a working tree by ref. And
> then it can handle its own cache to implement that reverse-mapping
> efficiently.
Yeah, that's a thought. Then "give me a worktre
On 1/24/2019 1:15 PM, Junio C Hamano wrote:
Derrick Stolee writes:
Here is today's test coverage report.
Also, there has been some feedback that it can be hard to manually
match up uncovered lines with names at the bottom of the summary. The
suggestion was to auto-generate an HTML report that
On Thu, Jan 24, 2019 at 02:38:10PM -0400, Joey Hess wrote:
> > Just off the top of my head, something like:
> >
> > /* guess that the filtered output will be the same size as the original */
> > hint = len;
> >
> > /* allocate 10% extra in case the clean size is slightly larger */
> > hi
On 1/24/2019 12:34 PM, Derrick Stolee wrote:
On 1/23/2019 4:00 PM, Jonathan Tan wrote:
Indeed, the sorting of pack_info is moved to after get_sorted_entries().
Also, pack_perm[old number] = new number, as expected.
Thanks for chiming in with all the detail on the use of 'perm'. This
is the mo
On Thu, Jan 24, 2019 at 4:35 AM Jeff King wrote:
> Note that we have to tweak t4013's setup a bit to test this case, as the
> existing merges do not have any --summary results against their first
> parent. But since the merge at the tip of 'master' does add and remove
> files with respect to the
On Thu, Jan 24, 2019 at 10:55:10AM -0800, Stefan Beller wrote:
> > But where does that output go? Normally it goes directly to stdout,
> > but because o->emitted_symbols is set, we queue it. As a result, we
> > don't actually print the diffstat for the merge commit (yet),
>
> Thank
On Thu, Jan 24, 2019 at 06:34:29PM +, Lucy Phipps wrote:
> honestly i just like optimizing files. the test images still work but
> one of them is half the size as before. i don't know if it needs to be
> bigger. it doesn't make any actual difference
I'm not sure if we actually see any benefit
On Thu, Jan 24, 2019 at 4:34 AM Jeff King wrote:
>
> The --stat of a combined diff is defined as the first-parent stat,
> going all the way back to 965f803c32 (combine-diff: show diffstat with
> the first parent., 2006-04-17).
>
> Naturally, we gave --numstat the same treatment in 74e2abe5b7 (diff
Thanks for the fix here.
On Thu, 2019-01-24 at 07:34 -0500, Jeff King wrote:
> The --stat of a combined diff is defined as the first-parent stat,
> going all the way back to 965f803c32 (combine-diff: show diffstat
> with
> the first parent., 2006-04-17).
>
> Naturally, we gave --numstat the same
On Thu, Jan 24, 2019 at 4:32 AM Jeff King wrote:
>
> There's an odd bug when "log --color-moved" is used with the combination
> of "--cc --stat -p": the stat for merge commits is erroneously shown
> with the diff of the _next_ commit.
>
> The included test demonstrates the issue. Our history looks
Jeff King wrote:
> Looking at apply_single_file_filter(), it's not the _original_ file that
> it's trying to store, but rather the data coming back from the filter.
> It's just that we use the original file size as a hint!
Thanks much for working that out!
> In other words, I think this patch fix
honestly i just like optimizing files. the test images still work but
one of them is half the size as before. i don't know if it needs to be
bigger. it doesn't make any actual difference
On Thu, 24 Jan 2019, 18:11 Stefan Beller
> On Thu, Jan 24, 2019 at 10:08 AM Lucy Phipps wrote:
> >
> > Signed
On Thu, Jan 24, 2019 at 10:26:18AM -0800, Junio C Hamano wrote:
> Nickolai Belakovski writes:
>
> > Yes, the parser used the atom argument in an earlier version of this
> > patch, but we since moved the map out of the atom since it only needs
> > to exist once globally. Even though we have a cac
Nickolai Belakovski writes:
> Yes, the parser used the atom argument in an earlier version of this
> patch, but we since moved the map out of the atom since it only needs
> to exist once globally. Even though we have a caching mechanism for
> atoms it still seemed like a logical move to explicitl
On Thu, Jan 24, 2019 at 4:27 AM Jeff King wrote:
> ---
> Not actually relevant to the rest of the series; I just found this while
> looking for existing --shortstat tests.
Not actually relevant to the review, but my long term vision for
--color-moved would work with this patch, too. ;)
But now
Derrick Stolee writes:
> Here is today's test coverage report.
>
> Also, there has been some feedback that it can be hard to manually
> match up uncovered lines with names at the bottom of the summary. The
> suggestion was to auto-generate an HTML report that could be posted to
> a public page an
On Thu, Jan 24, 2019 at 10:08 AM Lucy Phipps wrote:
>
> Signed-off-by: Lucy Phipps
Could you state reasons for this patch?
Do we need to treat the gitweb images differently than the test images?
If so, how?
> ---
> gitweb/static/git-favicon.png | Bin 115 -> 106 bytes
> gitweb/static/git-logo.
Signed-off-by: Lucy Phipps
---
gitweb/static/git-favicon.png | Bin 115 -> 106 bytes
gitweb/static/git-logo.png| Bin 207 -> 204 bytes
t/test-binary-1.png | Bin 5660 -> 2603 bytes
t/test-binary-2.png | Bin 275 -> 217 bytes
4 files changed, 0 insertions(+), 0 deletions(-)
On 1/23/2019 5:13 PM, Jonathan Tan wrote:
Maybe add a fsck at the end for sanity's sake. Also, I think that
preservation of .keep packfiles is an important feature, and maybe worth
a test.
Good points! I forgot to test the .keep stuff directly here because I
have an equivalent test in VFS for Gi
On 1/23/2019 4:00 PM, Jonathan Tan wrote:
Indeed, the sorting of pack_info is moved to after get_sorted_entries().
Also, pack_perm[old number] = new number, as expected.
Thanks for chiming in with all the detail on the use of 'perm'. This is
the most confusing part of this code path.
I thin
Hi,
don't send this to git@vger.kernel.org. Send it to
majord...@vger.kernel.org instead.
Thanks,
Johannes
On Wed, 23 Jan 2019, Cody Kratzer wrote:
> I've sent this same email 3 times. I don't think it works. I'm
> researching this morning how to unsubscribe from this git group.
>
> CODY KRAT
The raw diff format for merges with -c or --cc will only list one
filename, even if rename detection is active and a rename was detected
for the given path. Examples:
::100644 100644 100644 fabadb8 cc95eb0 4866510 MM describe.c
::100755 100755 100755 52b7a2d 6d1ac04 d2ac7d7 RM bar.sh
Jeff King wrote:
> I didn't experiment with the smudge side, but I think it uses the same
> apply_filter() code. Which means that yes, it would try to store the
> 11GB in memory before writing it out. And I agree writing it out to a
> file and moving it directly into place is the sanest option ther
With this patch it is possible to launch git-instaweb by using
Python 3 http.server CGI handler via `-d python` option.
git-instaweb generates a small wrapper around the http.server
(in GIT_DIR/gitweb/) that address a limitation of the CGI handler
where CGI scripts have to be in a cgi-bin subdirec
On Thu, 2019-01-24 at 14:51 +, Naum Derzhi wrote:
> Greetings,
>
> I have this problem: years ago one of our developers committed a
> large (Gigabytes) piece of binary data into our project repository.
> This should not have been done, but it happened. (Honest, it was not
> me). We never neede
Thank you
Naum Derzhi
Chief Scientific Adviser, Physics
3000 N Sam Houston Pkwy E, Technology Center, Office T1241H
Houston, TX 77032
Office: +1 (281) 871 3278
Follow Halliburton: LinkedIn | Facebook | Twitter | YouTube | Blog
Thank you very much. We'll try
Naum Derzhi
Chief Scientific Adviser, Physics
3000 N Sam Houston Pkwy E, Technology Center, Office T1241H
Houston, TX 77032
Office: +1 (281) 871 3278
Follow Halliburton: LinkedIn | Facebook | Twitter | YouTube | Blog
On Thu, Jan 24, 2019 at 02:51:50PM +, Naum Derzhi wrote:
> I have this problem: years ago one of our developers committed a large
> (Gigabytes) piece of binary data into our project repository. This
> should not have been done, but it happened. (Honest, it was not me).
> We never needed this d
Greetings,
I have this problem: years ago one of our developers committed a large
(Gigabytes) piece of binary data into our project repository. This should not
have been done, but it happened. (Honest, it was not me). We never needed this
data in the repository.
Using git rm removes these file
On 1/24/2019 4:40 AM, Ævar Arnfjörð Bjarmason wrote:
On Wed, Jan 23 2019, Derrick Stolee via GitGitGadget wrote:
The new format modifies the header of the commit-graph to solve
these problems. We use the 4-byte hash format id, freeing up a byte
in our 32-bit alignment to introduce a reachabilit
On 1/24/2019 8:11 AM, Jeff King wrote:
2. Patches that drop unused parameters (i.e., code cleanup).
I've read the patches and they do exactly this, along with explanations
of why they don't fit in the first category.
Thanks,
-Stolee
On 1/24/2019 8:12 AM, Jeff King wrote:
The timestamp we receive is in epoch time, so there's no need for a
timezone parameter to interpret it. The matching show_date() uses "tz"
to show dates in author local time, but relative dates show only the
absolute time difference. The author's location is
The caller is responsible for looking up the attributes,
after which point we no longer care about the path at which
the content is found.
Signed-off-by: Jeff King
---
convert.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/convert.c b/convert.c
index dafd6db
There's no need to pass a header struct to create_bundle(); it writes
the header information directly to a descriptor (and does not report
back details to the caller).
Signed-off-by: Jeff King
---
builtin/bundle.c | 3 +--
bundle.c | 4 ++--
bundle.h | 4 ++--
3 files changed, 5
We don't need the contents buffer to drop a section; the parse
information in the config_store_data parameter is enough for our logic.
Signed-off-by: Jeff King
---
config.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/config.c b/config.c
index ff521eb27a..24ad1a9854 1006
We've already extracted the useful information into our text_stat
struct, so the length is no longer needed.
Signed-off-by: Jeff King
---
convert.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/convert.c b/convert.c
index 0d89ae7c23..dafd6db643 100644
--- a/c
The timestamp we receive is in epoch time, so there's no need for a
timezone parameter to interpret it. The matching show_date() uses "tz"
to show dates in author local time, but relative dates show only the
absolute time difference. The author's location is irrelevant, barring
relativistic effects
There are no column options which impact the length computation. In
theory there might be, but this is a file-local function, so it will be
trivial to re-add the parameter should it ever be useful.
Signed-off-by: Jeff King
---
column.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
d
We use the "def" parameter in find_name_common() for some heuristics,
but they are not necessary with the less-ambiguous GNU format. Let's
drop this unused parameter.
Signed-off-by: Jeff King
---
apply.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/apply.c b/apply.c
i
The scores do not take the particular path into account at
all. It's possible they could, but these are all static file-local
functions. It won't be a big deal to re-add the parameter if they ever
need it.
Signed-off-by: Jeff King
---
match-trees.c | 16 +++-
1 file changed, 7 insert
I've mentioned before that I have a series which compiles cleanly with
-Wunused-parameters. I split this work roughly into three groups:
1. Patches that fix bugs (i.e., we should have been using the
parameter but didn't).
2. Patches that drop unused parameters (i.e., code cleanup).
3.
On Thu, Jan 24, 2019 at 7:11 PM Jeff King wrote:
>
> On Tue, Jan 22, 2019 at 06:07:14PM -0400, Joey Hess wrote:
>
> > joey@darkstar:~/tmp/t> ls -l big-file
> > -rw-r--r-- 1 joey joey 11811160064 Jan 22 17:48 big-file
> > joey@darkstar:~/tmp/t> git status
> > fatal: Out of memory, realloc failed
>
Currently "--cc --dirstat" will show nothing for a merge. Like
--shortstat and --summary in the previous two patches, it probably makes
sense to treat it like we do --stat, and show a stat against the
first-parent.
This case is less obviously correct than for --shortstat and --summary,
as those a
There are several conditionals in the combine diff code that check if
we're doing --stat or --numstat output. Since these must all remain in
sync, let's pull them out into a separate bit-mask.
Arguably this could go into diff.h along with the other DIFF_FORMAT
macros, but it's not clear that the d
The --stat of a combined diff is defined as the first-parent stat,
going all the way back to 965f803c32 (combine-diff: show diffstat with
the first parent., 2006-04-17).
Naturally, we gave --numstat the same treatment in 74e2abe5b7 (diff
--numstat, 2006-10-12).
But --shortstat, which is really ju
Currently "--cc --summary" on a merge shows nothing. Since we show "--cc
--stat" as a stat against the first parent, and because --summary is
typically used in combination with --stat, it makes sense to treat them
both the same way.
Note that we have to tweak t4013's setup a bit to test this case,
There's an odd bug when "log --color-moved" is used with the combination
of "--cc --stat -p": the stat for merge commits is erroneously shown
with the diff of the _next_ commit.
The included test demonstrates the issue. Our history looks something
like this:
A-B-M--D
\ /
C
When we run "
This set of tests was added by 4434e6ba6c (tests: check --[short]stat
output after chmod, 2012-05-01), and is primarily about the handling of
binary versus text files.
Later, 74faaa16f0 (Fix "git diff --stat" for interesting - but empty -
file changes, 2012-10-17) changed the stat output so that t
1 - 100 of 120 matches
Mail list logo