On Sat, Aug 4, 2018 at 10:15 AM Junio C Hamano wrote:
>
> Stefan Beller writes:
>
> > Try it out via
> > ./git-format-patch --mark-moved 15ef69314d^..15ef69314d
> > to see if you like it.
> >
> > This separates the coloring decision from the detection of moved lines.
> > When giving --mark-mo
On Sat, Aug 4, 2018 at 9:57 AM Junio C Hamano wrote:
>
> Stefan Beller writes:
>
> > This builds on top of sb/range-diff-colors, which builds on js/range-diff.
>
> As another round of js/range-diff is expected, according to
>
>
Oh right. I forgot to mention that in this cover letter, but Johann
On Fri, Aug 3, 2018 at 11:25 PM Nguyễn Thái Ngọc Duy wrote:
>
> The color group in config.txt is actually sorted but changes in
> sb/blame-color broke this. Reorder color.blame.* and move
> blame.coloring back to the rest of blame.* (and reorder that group too
> while we're there)
>
> Signed-off-b
Hi,
Jeff King wrote:
> On Thu, Aug 02, 2018 at 11:21:44PM -0700, Jonathan Nieder wrote:
>> Jeff King wrote:
>>> I guess you could even replace "COCCI_COMBINED" with "COCCI_PATCH" in
>>> most of the targets, and that would let people do individual:
>>>
>>> make COCCI_PATCH=contrib/coccinelle/foo
Hi,
Thomas Gummerer wrote:
> git 2.18.0 should print both of those lines to stdout. This was done
> to match where 'git reset --hard' prints the 'HEAD is now at...'
> message. See also the thread at [1] where we did make that decision.
>
> [1]:
> https://public-inbox.org/git/capig+cq8vzdycumo-q
On Sun, Aug 05, 2018 at 01:23:05AM -0400, Eric Sunshine wrote:
> A simpler approach, without the portability concerns of -A, would be
> to remove the "." and ".." lines from the top of the listing:
>
> ls -f1 "$1" | sed '1,2d'
>
> If we're worried about -f not being sufficiently portable, th
On Fri, Aug 03, 2018 at 04:52:05PM -0400, Jeff King wrote:
> I wrote this up for my own use after our discussion in [1]. I'm not sure
> if it's too ugly for inclusion, or if it might be helpful to others.
> I've only just written it, but my plan is to try to run it on anything I
> submit to check t
On 08/05, Alexander Mills wrote:
> Also, as an aside, this seems to be a bug, but probably a known bug:
>
> $ git diff-index HEAD; echo $?
>
> :100755 100755 60e5d683c1eb3e61381b1a8ec2db822b94b9faec
> M cli/npp_check_merge.sh
> :100644 100644 35a4535
I am on Ubuntu, I will run the checks that you mentioned. I assume
it's operator error for now though. Like I said, it was just `git
status` that was sometimes failing to send any stdout, presumably when
access to a certain git repo was concurrent, but possibly due to
concurrent access across multi
On Sun, Jul 22, 2018 at 10:50 AM, Duy Nguyen wrote:
> On Sun, Jul 22, 2018 at 7:51 AM Christian Couder
> wrote:
>> diff --git a/pack-objects.h b/pack-objects.h
>> index edf74dabdd..8eecd67991 100644
>> --- a/pack-objects.h
>> +++ b/pack-objects.h
>> @@ -100,6 +100,10 @@ struct object_entry {
>>
On Sun, Aug 5, 2018 at 11:01 AM Thomas Gummerer wrote:
> On 08/05, Karen Arutyunov wrote:
> > What's quite inconvenient is that the 'git worktree add' command prints some
> > output by default and there is no way to suppress it, as it normally can be
> > achieved with the --quiet option for the mo
Sent from my iPhone
Git rm — cached jeff
Git rm - jeff
Git ls jeff ingnored
On Tue, Jul 24, 2018 at 7:11 PM, Junio C Hamano wrote:
>
> Another thing I noticed from 2/5 is that you can have up to 7 such
> capture groups. I do not have any opinion if 7 is too few or too
> many, but we would want the number to be documented, and end-user
> input diagnosed when it requires m
On Sun, Jul 22, 2018 at 10:55 AM, Duy Nguyen wrote:
> On Sun, Jul 22, 2018 at 7:52 AM Christian Couder
> wrote:
>>
>> - /*
>> -* And then all remaining commits and tags.
>> -*/
>> - for (i = last_untagged; i < to_pack.nr_objects; i++) {
>> - if (oe_type(&
This reduces the size of 'struct object_entry' and therefore
makes packing objects more efficient.
This also renames cmp_tree_depth() into tree_depth_compare(),
as it is more modern to have the name of the compare functions
end with "compare".
Signed-off-by: Christian Couder
---
builtin/pack-ob
From: Jeff King
Signed-off-by: Jeff King
Signed-off-by: Christian Couder
---
t/t5319-delta-islands.sh | 143 +++
1 file changed, 143 insertions(+)
create mode 100755 t/t5319-delta-islands.sh
diff --git a/t/t5319-delta-islands.sh b/t/t5319-delta-islands.sh
This patch series is upstreaming work made by GitHub and available in:
https://github.com/peff/git/commits/jk/delta-islands
The above work has been already described in the following article:
https://githubengineering.com/counting-objects/
The above branch contains only one patch. In this patch
From: Jeff King
Implement simple support for --delta-islands option and
repack.useDeltaIslands config variable in git repack.
This allows users to setup delta islands in their config and
get the benefit of less disk usage while cloning and fetching
is still quite fast and not much more CPU inten
From: Jeff King
Implement support for delta islands in git pack-objects
and document how delta islands work in
"Documentation/git-pack-objects.txt" and Documentation/config.txt.
This allows users to setup delta islands in their config and
get the benefit of less disk usage while cloning and fetc
From: Jeff King
Hosting providers that allow users to "fork" existing
repos want those forks to share as much disk space as
possible.
Alternates are an existing solution to keep all the
objects from all the forks into a unique central repo,
but this can have some drawbacks. Especially when
packi
From: Jeff King
As get_delta_base() will be used outside 'packfile.c' in
a following commit, let's make it non static and let's
declare it in 'packfile.h'.
Signed-off-by: Jeff King
Signed-off-by: Christian Couder
---
packfile.c | 10 +-
packfile.h | 7 +++
2 files changed, 12 ins
Currently rerere can't handle nested conflicts and will error out when
it encounters such conflicts. Do that by recursively calling the
'handle_conflict' function to normalize the conflict.
Note that a conflict like this would only be produced if a user
commits a file with conflict markers, and g
Factor out the handle_conflict function, which handles a single
conflict in a path. This is in preparation for a subsequent commit,
where this function will be re-used.
Note that this does change the behaviour of 'git rerere' slightly.
Where previously we'd consider all files where an unmatched c
Currently we write the conflict to disk directly in the handle_path
function. To make it re-usable for nested conflicts, instead of
writing the conflict out directly, store it in a strbuf and let the
caller write it out.
This does mean some slight increase in memory usage, however that
increase i
Currently when a user doesn't resolve a conflict, commits the results,
and does an operation which creates another conflict, rerere will use
the ID of the previously unresolved conflict for the new conflict.
This is because the conflict is kept in the MERGE_RR file, which
'rerere' reads every time
We currently return the exact number of conflict hunks a certain path
has from the 'handle_paths' function. However all of its callers only
care whether there are conflicts or not or if there is an error.
Return only that information, and document that only that information
is returned. This will
We have multiple different variants of the error message we show to
the user if 'read_cache' fails. The "Could not read index" variant we
are using in 'rerere.c' is currently not used anywhere in translated
form.
As a subsequent commit will mark all output that comes from 'rerere.c'
for translati
The previous rounds were at
<20180520211210.1248-1-t.gumme...@gmail.com>,
<20180605215219.28783-1-t.gumme...@gmail.com> and
<20180714214443.7184-1-t.gumme...@gmail.com>.
Thanks Junio for the review and Simon for pointing out an error in my
commit message.
The changes in this round are mainly impr
It looks like most paths in the output in the git codebase are wrapped
in single quotes. Standardize on that in rerere as well.
Apart from being more consistent, this also makes some of the strings
match strings that are already translated in other parts of the
codebase, thus reducing the work fo
Documentation/CodingGuidelines mentions that error messages should be
lowercase. Prior to marking them for translation follow that pattern
in rerere as well, so translators won't have to translate messages
that don't conform to our guidelines.
Signed-off-by: Thomas Gummerer
---
rerere.c | 24 ++
Currently when a user does a conflict resolution and ends it (in any
way that calls 'git rerere' again) with a file 'rerere' can't handle,
subsequent rerere operations that are interested in that path, such as
'rerere clear' or 'rerere forget ' will fail, or even worse in
the case of 'rerere clear'
Add some documentation for the logic behind the conflict normalization
in rerere.
Helped-by: Junio C Hamano
Signed-off-by: Thomas Gummerer
---
Documentation/technical/rerere.txt | 140 +
rerere.c | 4 -
2 files changed, 140 insertions(+),
'git rerere' is considered a porcelain command and as such its output
should be translated. Its functionality is also only enabled through
a config setting, so scripts really shouldn't rely on the output
either way.
Signed-off-by: Thomas Gummerer
---
builtin/rerere.c | 4 +--
rerere.c
On 08/05, Karen Arutyunov wrote:
> Hello,
>
> We are using git for automation in our build2 project.
>
> What's quite inconvenient is that the 'git worktree add' command prints some
> output by default and there is no way to suppress it, as it normally can be
> achieved with the --quiet option fo
On 08/05, Karen Arutyunov wrote:
> Hello,
>
> The 'git worktree add' command prints to both standard streams. So in the
> following example the first line is printed to stderr and the second to
> stdout.
git 2.18.0 should print both of those lines to stdout. This was done
to match where 'git res
On 8/3/2018 2:53 PM, Jeff King wrote:
On Fri, Aug 03, 2018 at 02:23:17PM -0400, Jeff Hostetler wrote:
Maybe. It might not work as ino_t. Or it might be expensive to get. Or
maybe it's simply impossible. I don't know much about Windows. Some
searching implies that NTFS does have a "file inde
Hello,
We are using git for automation in our build2 project.
What's quite inconvenient is that the 'git worktree add' command prints
some output by default and there is no way to suppress it, as it
normally can be achieved with the --quiet option for the most of git
commands.
Could you add
Hello,
The 'git worktree add' command prints to both standard streams. So in
the following example the first line is printed to stderr and the second
to stdout.
$ git worktree add ../pub build2-control
Preparing ../pub (identifier pub)
HEAD is now at b03ea86 Update
This looks like a bug, as,
On Sun, Aug 5, 2018 at 6:14 AM Eric Sunshine wrote:
> Having said that, a much easier fix is to use
> range_set_append_unsafe() here, and then at the bottom of the loop,
> invoke 'sort_and_merge_range_set(out)' to restore range-set invariants
By "bottom", I meant "outside" or "after":
...and
On Sat, Aug 4, 2018 at 6:18 PM Johannes Schindelin via GitGitGadget
wrote:
> The assertion in question really indicates a bug, when triggered, so we
> might just as well use the sanctioned method to report it.
>
> Signed-off-by: Johannes Schindelin
> ---
> diff --git a/line-log.c b/line-log.c
> @
On Sat, Aug 4, 2018 at 6:18 PM Johannes Schindelin via GitGitGadget
wrote:
> Now, I am fairly certain that the changes are correct, but given my track
> record with off-by-one bugs (and once even an off-by-two bug), I would
> really appreciate some thorough review of this code, in particular the
>
> On 2018-08-05 00:18, Johannes Schindelin via GitGitGadget wrote:
> > Technically, it is okay to have line ranges that touch (i.e. the end of
> > the first range ends just before the next range begins). However, it is
> > inefficient, and when the user provides such touching ranges via
> > multipl
On Sat, Aug 4, 2018 at 6:18 PM Johannes Schindelin via GitGitGadget
wrote:
> When traversing commits and adjusting the ranges, things can get really
> tricky. For example, when the line range of interest encloses several
> hunks of a commit, the line range can actually shrink.
>
> Currently, range
On Thu, Aug 02, 2018 at 02:02:00PM -0400, Ben Peart wrote:
> > And if all go according to plan, there will be no changes made in the
> > index (by either 2-way merge or sparse checkout stuff) we should be
> > able to just skip writing down the index, if we haven't done that
> > already.
> >
>
> T
On 2018-08-05 00:18, Johannes Schindelin via GitGitGadget wrote:
>
> Now, I am fairly certain that the changes are correct, but given my track
> record with off-by-one bugs (and once even an off-by-two bug), I would
> really appreciate some thorough review of this code, in particular the
> second
Am 05.08.2018 um 06:20 schrieb William Chargin:
While the `test_dir_is_empty` function appears correct in most normal
use cases, it can fail when filenames contain newlines. This patch
changes the implementation to use `ls -A`, which is specified by POSIX.
The output should be empty exactly if th
Alexander Mills wrote:
> Yeah in this case what appeared to be happening is that if `git status` was
> called concurrently, frequently I wouldnt get any stdout..
Thanks for reporting. A few questions:
What platform are you on? What version of Git are you running? What
is the output of "git ve
Hi,
Eric Sunshine wrote:
> On Sat, Aug 4, 2018 at 11:17 PM Jonathan Nieder wrote:
>>> utf8.c:486:28: warning: passing 'iconv_ibp *' (aka 'const char **') to
>>> parameter
>>> of type 'char **' discards qualifiers in nested pointer types
>>> [-Wincompatible-pointer-types-discards-qua
48 matches
Mail list logo
