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)
>
>
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
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]:
>
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,
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
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
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
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
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
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
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
---
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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":
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
> >
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,
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.
> >
>
>
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
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
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
>>>
William Chargin wrote:
> Jonathan Nieder wrote:
>> This subject line will appear out of context in "git shortlog" output,
>> so it's useful to pack in enough information to briefly summarize what
>> the change does.
>
> I'm happy to do so. I think that "simplify" is misleading, because this
> is
Hi,
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> but $'' is too recent of a shell feature to count on (e.g., dash doesn't
>> support it). See t/t3600-rm.sh for an example of a portable way to do
>
> Is that "too recent"? I thought it was bashism, not even in POSIX,
> but I may be
Stefan Beller writes:
>> You are the second one who were negatively affected by Stefan's
>> "summary" that reads a lot more in what I said than what actually
>> was said by me. Stop paying attention to that message, but do go to
>> the original if you want to hear what I actually said.
>
>
Hi,
Alexander Mills wrote:
> Yeah as long as git shouldnt fumble wrt concurrent access across repos, it
> was most likely the same repo being accessed concurrently and that's what
> was causing the issue.
>
> that being said, it would be really nice if git itself could handle
> concurrent
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> 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
>
Johannes Schindelin writes:
> Hi Junio,
>
> On Thu, 2 Aug 2018, Junio C Hamano wrote:
>
>> * pk/rebase-in-c (2018-07-30) 3 commits
>> - builtin/rebase: support running "git rebase "
>> - rebase: refactor common shell functions into their own file
>> - rebase: start implementing it as a
Jonathan Nieder writes:
> but $'' is too recent of a shell feature to count on (e.g., dash doesn't
> support it). See t/t3600-rm.sh for an example of a portable way to do
Is that "too recent"? I thought it was bashism, not even in POSIX,
but I may be mistaken.
Quite honestly, our tests are
53 matches
Mail list logo
