* [PATCH v4 2/2] gitweb: use highlight's shebang detection
From: Ian Kelling @ 2016-09-24 22:32 UTC (permalink / raw)
To: git; +Cc: jnareb
In-Reply-To: <20160924223258.9449-1-ian@iankelling.org>
The "highlight" binary can, in some cases, determine the language type
by the means of file contents, for example the shebang in the first line
for some scripting languages. Make use of this autodetection for files
which syntax is not known by gitweb. In that case, pass the blob
contents to "highlight --force"; the parameter is needed to make it
always generate HTML output (which includes HTML-escaping).
Although we now run highlight on files which do not end up highlighted,
performance is virtually unaffected because when we call highlight, it
is used for escaping HTML. In the case that highlight is used, gitweb
calls sanitize() instead of esc_html(), and the latter is significantly
slower (it does more, being roughly a superset of sanitize()). Simple
benchmark comparing performance of 'blob' view of files without syntax
highlighting in gitweb before and after this change indicates ±1%
difference in request time for all file types. Benchmark was performed
on local instance on Debian, using Apache/2.4.23 web server and CGI.
Document the feature and improve syntax highlight documentation, add
test to ensure gitweb doesn't crash when language detection is used.
Signed-off-by: Ian Kelling <ian@iankelling.org>
---
Notes:
The only change from v3 is the commit message as suggested by Jakub
Narębski
Documentation/gitweb.conf.txt | 21 ++++++++++++++-------
gitweb/gitweb.perl | 10 +++++-----
t/t9500-gitweb-standalone-no-errors.sh | 8 ++++++++
3 files changed, 27 insertions(+), 12 deletions(-)
diff --git a/Documentation/gitweb.conf.txt b/Documentation/gitweb.conf.txt
index a79e350..e632089 100644
--- a/Documentation/gitweb.conf.txt
+++ b/Documentation/gitweb.conf.txt
@@ -246,13 +246,20 @@ $highlight_bin::
Note that 'highlight' feature must be set for gitweb to actually
use syntax highlighting.
+
-*NOTE*: if you want to add support for new file type (supported by
-"highlight" but not used by gitweb), you need to modify `%highlight_ext`
-or `%highlight_basename`, depending on whether you detect type of file
-based on extension (for example "sh") or on its basename (for example
-"Makefile"). The keys of these hashes are extension and basename,
-respectively, and value for given key is name of syntax to be passed via
-`--syntax <syntax>` to highlighter.
+*NOTE*: for a file to be highlighted, its syntax type must be detected
+and that syntax must be supported by "highlight". The default syntax
+detection is minimal, and there are many supported syntax types with no
+detection by default. There are three options for adding syntax
+detection. The first and second priority are `%highlight_basename` and
+`%highlight_ext`, which detect based on basename (the full filename, for
+example "Makefile") and extension (for example "sh"). The keys of these
+hashes are the basename and extension, respectively, and the value for a
+given key is the name of the syntax to be passed via `--syntax <syntax>`
+to "highlight". The last priority is the "highlight" configuration of
+`Shebang` regular expressions to detect the language based on the first
+line in the file, (for example, matching the line "#!/bin/bash"). See
+the highlight documentation and the default config at
+/etc/highlight/filetypes.conf for more details.
+
For example if repositories you are hosting use "phtml" extension for
PHP files, and you want to have correct syntax-highlighting for those
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 6cb4280..44094f4 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3931,15 +3931,16 @@ sub guess_file_syntax {
# or return original FD if no highlighting
sub run_highlighter {
my ($fd, $highlight, $syntax) = @_;
- return $fd unless ($highlight && defined $syntax);
+ return $fd unless ($highlight);
close $fd;
+ my $syntax_arg = (defined $syntax) ? "--syntax $syntax" : "--force";
open $fd, quote_command(git_cmd(), "cat-file", "blob", $hash)." | ".
quote_command($^X, '-CO', '-MEncode=decode,FB_DEFAULT', '-pse',
'$_ = decode($fe, $_, FB_DEFAULT) if !utf8::decode($_);',
'--', "-fe=$fallback_encoding")." | ".
quote_command($highlight_bin).
- " --replace-tabs=8 --fragment --syntax $syntax |"
+ " --replace-tabs=8 --fragment $syntax_arg |"
or die_error(500, "Couldn't open file or run syntax highlighter");
return $fd;
}
@@ -7063,8 +7064,7 @@ sub git_blob {
my $highlight = gitweb_check_feature('highlight');
my $syntax = guess_file_syntax($highlight, $file_name);
- $fd = run_highlighter($fd, $highlight, $syntax)
- if $syntax;
+ $fd = run_highlighter($fd, $highlight, $syntax);
git_header_html(undef, $expires);
my $formats_nav = '';
@@ -7117,7 +7117,7 @@ sub git_blob {
$line = untabify($line);
printf qq!<div class="pre"><a id="l%i" href="%s#l%i" class="linenr">%4i</a> %s</div>\n!,
$nr, esc_attr(href(-replay => 1)), $nr, $nr,
- $syntax ? sanitize($line) : esc_html($line, -nbsp=>1);
+ $highlight ? sanitize($line) : esc_html($line, -nbsp=>1);
}
}
close $fd
diff --git a/t/t9500-gitweb-standalone-no-errors.sh b/t/t9500-gitweb-standalone-no-errors.sh
index e94b2f1..6d06ed9 100755
--- a/t/t9500-gitweb-standalone-no-errors.sh
+++ b/t/t9500-gitweb-standalone-no-errors.sh
@@ -709,6 +709,14 @@ test_expect_success HIGHLIGHT \
git commit -m "Add test.sh" &&
gitweb_run "p=.git;a=blob;f=test.sh"'
+test_expect_success HIGHLIGHT \
+ 'syntax highlighting (highlighter language autodetection)' \
+ 'git config gitweb.highlight yes &&
+ echo "#!/usr/bin/perl" > test &&
+ git add test &&
+ git commit -m "Add test" &&
+ gitweb_run "p=.git;a=blob;f=test"'
+
# ----------------------------------------------------------------------
# forks of projects
--
2.9.3
^ permalink raw reply related
* [PATCH v4 1/2] gitweb: remove unused guess_file_syntax() parameter
From: Ian Kelling @ 2016-09-24 22:32 UTC (permalink / raw)
To: git; +Cc: jnareb
In-Reply-To: <20160923090846.3086-2-ian@iankelling.org>
Signed-off-by: Ian Kelling <ian@iankelling.org>
---
Notes:
The only change from v3 is a more descriptive commit message
gitweb/gitweb.perl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 33d701d..6cb4280 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3913,7 +3913,7 @@ sub blob_contenttype {
# guess file syntax for syntax highlighting; return undef if no highlighting
# the name of syntax can (in the future) depend on syntax highlighter used
sub guess_file_syntax {
- my ($highlight, $mimetype, $file_name) = @_;
+ my ($highlight, $file_name) = @_;
return undef unless ($highlight && defined $file_name);
my $basename = basename($file_name, '.in');
return $highlight_basename{$basename}
@@ -7062,7 +7062,7 @@ sub git_blob {
$have_blame &&= ($mimetype =~ m!^text/!);
my $highlight = gitweb_check_feature('highlight');
- my $syntax = guess_file_syntax($highlight, $mimetype, $file_name);
+ my $syntax = guess_file_syntax($highlight, $file_name);
$fd = run_highlighter($fd, $highlight, $syntax)
if $syntax;
--
2.9.3
^ permalink raw reply related
* Re: [PATCH v8 04/11] pkt-line: add packet_write_fmt_gently()
From: Jakub Narębski @ 2016-09-24 22:27 UTC (permalink / raw)
To: larsxschneider, git; +Cc: peff, gitster, sbeller, mlbright, tboegi, ramsay
In-Reply-To: <20160920190247.82189-5-larsxschneider@gmail.com>
W dniu 20.09.2016 o 21:02, larsxschneider@gmail.com pisze:
> From: Lars Schneider <larsxschneider@gmail.com>
>
> packet_write_fmt() would die in case of a write error even though for
> some callers an error would be acceptable. Add packet_write_fmt_gently()
> which writes a formatted pkt-line like packet_write_fmt() but does not
> die in case of an error. The function is used in a subsequent patch.
Looks good.
>
> Signed-off-by: Lars Schneider <larsxschneider@gmail.com>
> ---
> pkt-line.c | 34 ++++++++++++++++++++++++++++++----
> pkt-line.h | 1 +
> 2 files changed, 31 insertions(+), 4 deletions(-)
^ permalink raw reply
* Re: [PATCH v8 03/11] run-command: move check_pipe() from write_or_die to run_command
From: Jakub Narębski @ 2016-09-24 22:12 UTC (permalink / raw)
To: Lars Schneider, git
Cc: Jeff King, Junio C Hamano, Stefan Beller, Martin-Louis Bright,
Torsten Bögershausen, Ramsay Jones
In-Reply-To: <20160920190247.82189-4-larsxschneider@gmail.com>
W dniu 20.09.2016 o 21:02, larsxschneider@gmail.com pisze:
> From: Lars Schneider <larsxschneider@gmail.com>
>
> Move check_pipe() to run_command and make it public. This is necessary
> to call the function from pkt-line in a subsequent patch.
All right.
>
> Signed-off-by: Lars Schneider <larsxschneider@gmail.com>
> ---
> run-command.c | 13 +++++++++++++
> run-command.h | 2 ++
> write_or_die.c | 13 -------------
> 3 files changed, 15 insertions(+), 13 deletions(-)
Diffstat looks correct.
Not to add to your burden, but perhaps somebody could add to his/her
TODO documenting check_pipe() in Documentation/technical/api-run-command.txt
Or is it not worth it?
Best regards,
--
Jakub Narębski
^ permalink raw reply
* Re: [PATCH v8 02/11] pkt-line: extract set_packet_header()
From: Jakub Narębski @ 2016-09-24 21:22 UTC (permalink / raw)
To: Lars Schneider, git
Cc: Jeff King, Junio C Hamano, Stefan Beller, Martin-Louis Bright,
Torsten Bögershausen, Ramsay Jones
In-Reply-To: <20160920190247.82189-3-larsxschneider@gmail.com>
W dniu 20.09.2016 o 21:02, larsxschneider@gmail.com pisze:
> From: Lars Schneider <larsxschneider@gmail.com>
>
> Subject: [PATCH v8 02/11] pkt-line: extract set_packet_header()
>
> set_packet_header() converts an integer to a 4 byte hex string. Make
> this function locally available so that other pkt-line functions can
> use it.
Ah. I have trouble understanding this commit message, as the
set_packet_header() was not available before this patch, but it
is good if one reads it together with commit summary / title.
Writing
Extracted set_packet_header() function converts...
or
New set_packet_header() function converts...
would make it more clear, but it is all right as it is now.
Perhaps also
... could use it.
as currently no other pkt-line function but the one set_packet_header()
was extracted from, namely format_packet(), uses it.
But that is just nitpicking; no need to change on that account.
>
> Signed-off-by: Lars Schneider <larsxschneider@gmail.com>
^ permalink raw reply
* Re: [PATCH v8 01/11] pkt-line: rename packet_write() to packet_write_fmt()
From: Jakub Narębski @ 2016-09-24 21:14 UTC (permalink / raw)
To: Lars Schneider, git
Cc: Jeff King, Junio C Hamano, Stefan Beller, Martin-Louis Bright,
Torsten Bögershausen, Ramsay Jones
In-Reply-To: <20160920190247.82189-2-larsxschneider@gmail.com>
Hello Lars,
W dniu 20.09.2016 o 21:02, larsxschneider@gmail.com pisze:
> From: Lars Schneider <larsxschneider@gmail.com>
>
> packet_write() should be called packet_write_fmt() as the string
> parameter can be formatted.
I would say:
packet_write() should be called packet_write_fmt() because it
is printf-like function where first parameter is format string.
Or something like that. But such minor change might be not worth
yet another reroll of this patch series.
Perhaps it would be a good idea to explain the reasoning behind
this change:
This is important distinction to know from the name if the
function accepts arbitrary binary data and/or arbitrary
strings to be written - packet_write[_fmt()] do not.
>
> Suggested-by: Junio C Hamano <gitster@pobox.com>
Just so nobody wonders later why this patch was needed/suggested.
> Signed-off-by: Lars Schneider <larsxschneider@gmail.com>
> ---
> builtin/archive.c | 4 ++--
> builtin/receive-pack.c | 4 ++--
> builtin/remote-ext.c | 4 ++--
> builtin/upload-archive.c | 4 ++--
> connect.c | 2 +-
> daemon.c | 2 +-
> http-backend.c | 2 +-
> pkt-line.c | 2 +-
The header of the renamed function looks now very nice:
void packet_write_fmt(int fd, const char *fmt, ...)
^^^ ^^^
> pkt-line.h | 2 +-
> shallow.c | 2 +-
> upload-pack.c | 30 +++++++++++++++---------------
> 11 files changed, 29 insertions(+), 29 deletions(-)
Diffstat looks correct. Was the patch generated by doing search
and replace?
Best,
--
Jakub Narębski
^ permalink raw reply
* Re: [PATCH v3] checkout: eliminate unnecessary merge for trivial checkout
From: Philip Oakley @ 2016-09-24 19:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ben Peart, pclouds, git
In-Reply-To: <xmqqd1jtyx01.fsf@gitster.mtv.corp.google.com>
Hi Junio,
From: "Junio C Hamano" <gitster@pobox.com>
> "Philip Oakley" <philipoakley@iee.org> writes:
>
>>> > >"git checkout -b foo" (without -f -m or <start_point>) is defined in
>>> > >the manual as being a shortcut for/equivalent to:
>>> > >
>>> > > (1a) "git branch foo"
>>> > > (1b) "git checkout foo"
>>> > >
>>> > >However, it has been our experience in our observed use cases and all
>>> > >the existing git tests, that it can be treated as equivalent to:
>>> > >
>>> > > (2a) "git branch foo"
>>> > > (2b) "git symbolic-ref HEAD refs/heads/foo"
>>> > >...
>>> > >
>>> > I am still not sure if I like the change of what "checkout -b" is this
>>> > late in the game, though.
>>>
>>> ...
>>> That said, you're much more on the frontline of receiving negative
>>> feedback about doing that than I am. :) How would you like to
>>> proceed?
>>
>> I didn't see an initial confirmation as to what the issue really
>> was. You indicated the symptom ('a long checkout time'), but then we
>> missed out on hard facts and example repos, so that the issue was
>> replicable.
>
> I took it as a given, trivial and obvious optimization opportunity,
> that it is wasteful having to traverse two trees to consolidate and
> reflect their differences into the working tree when we know upfront
> that these two trees are identical, no matter what the overhead for
> doing so is.
I agree, and I believe Ben agrees.
>
>> At the moment there is the simple workaround of an alias that executes
>> that two step command dance to achieve what you needed, and Junio has
>> outlined the issues he needed to be covered from his maintainer
>> perspective (e.g. the detection of sparse checkouts). Confirming the
>> root causes would help in setting a baseline.
>>
>> I hope that is of help - I'd seen that the discussion had gone quiet.
>
> Some of the problems I have are:
>
> (1) "git checkout -b NEW", "git checkout", "git checkout HEAD^0"
> and "git checkout HEAD" (no other parameters to any of them)
> ought to give identical index and working tree. It is too
> confusing to leave subtly different results that will lead to
> hard to diagnose bugs for only one of them.
>
> (2) The proposed log message talks only about "performance
> optimization",
> while the purpose of the change is more
> about
> changing the definition
Here I think is the misunderstanding. His purpose is NOT to change the
definition (IIUC). As I read the message you reference below (and Ben's
other messages), I understood that he was trying to achieve what you said
(i.e. optimise the trivial and obvious opportunity) of selecting for the
common case (underlying conditions) where the two command sequences are
identical. If the selected case / conditions is not identical then it is
defined wrongly...
I suspect that it was Ben's 'soft' explanation that allowed the discussion
to diverge.
> of what "git checkout -b
> NEW" is from
> "git branch NEW && git checkout NEW" to "git branch NEW && git
> symbolic-ref HEAD refs/heads/NEW". The explanation in a Ben's
> later message <007401d21278$445eba80$cd1c2f80$@gmail.com> does
> a much better job contrasting the two.
>
> (3) I identified only one difference as an example sufficient to
> point out why the patch provided is not a pure optimization but
> behaviour change. Fixing that example alone to avoid change in
> the behaviour is trivial (see if the "info/sparse-checkout"
> file is present and refrain from skipping the proper checkout),
This is probably the point Ben needs to take on board to narrow the
conditions down. There may be others.
> but a much larger problem is that I do not know (and Ben does
> not, I suspect) know what other behaviour changes the patch is
> introducing, and worse, the checks are sufficiently dense too
> detailed and intimate to the implementation of unpack_trees()
> that it is impossible for anybody to make sure the exceptions
> defined in this patch and updates to other parts of the system
> will be kept in sync.
I did not believe he was proposing such a change to behaviour, hence his
difficulty in responding (or at least that is my perception). I.e. he was
digging a hole in the wrong place.
It is possible that he had accidentally introduced a behavious change, and
having failed to explictly say "This patch (should) produces no behavious
change", which then continued to re-inforce the misunderstanding.
>
> So my inclination at this point, unless we see somebody invents a
> clever way to solve (3), is that any change that violates (1),
> i.e. as long as the patch does "Are we doing '-b NEW'? Then we do
> something subtly different", is not acceptable, and solving (3) in a
> maintainable way smells like quite a hard thing to do. But it would
> be ideal if (3) is solved cleanly, as we will then not have to worry
> about changing behaviour at all and can apply the optimization for
> all of the four cases equally. As a side effect, that approach
> would solve problem (2) above.
>
> If we were to punt on keeping the sanity (1) and introduce a subtly
> different "create a new branch and point the HEAD at it", an easier
> way out may be be one of
>
> 1. a totally new command, e.g. "git branch-switch NEW" that takes
> only a single argument and no other "checkout" options, or
>
> 2. a new option to "git checkout" that takes _ONLY_ a single
> argument and incompatible with any other option or command line
> argument, or
>
> 3. an alias that does "git branch" followed by "git symbolic-ref".
>
> Neither of the first two sounds palatable, though.
It will need Ben to come back and clarify, if he did, or did not, want any
behaviour change (beyond speed of action;-)
Thanks
Philip
^ permalink raw reply
* Re: [RFC/PATCH 0/6] Add --format to tag verification
From: Jakub Narębski @ 2016-09-24 19:09 UTC (permalink / raw)
To: Stefan Beller, Santiago Torres
Cc: git@vger.kernel.org, Junio C Hamano, Jeff King, Eric Sunshine,
walters
In-Reply-To: <CAGZ79kZ+eETHm2xuorRqP9OPKdETZSOuuY+SWPR_=J6MwJedRg@mail.gmail.com>
W dniu 22.09.2016 o 21:01, Stefan Beller pisze:
> On Thu, Sep 22, 2016 at 11:53 AM, <santiago@nyu.edu> wrote:
>
>>
>> P.S. Gmane seems to be broken for git after it was rebooted. Should we ping
>> them about it?
>
> I think most of the git developers have moved on and reference emails by
> message id. An archive of all messages of the mailing list is found at
>
> public-inbox.org/git/
>
> (You can git-clone it to have a distributed copy of the whole archive)
>
> public-inbox.org/git/<message-id>/
> public-inbox.org/git/<message-id>/raw
>
> is a good point to link to.
>
> However, feel free to ping gmane. :)
Two relevant articles are the following:
[1]: https://lwn.net/Articles/695695/
[2]: https://lwn.net/Articles/699704/
In short: Gmane creator and maintainer wanted to retire from being
maintainer[1] because of DDoS attack against its web interface, so he
stopped supporting wen interface (NNTP continues working). Thus
public-inbox.org was created (or just advertised more). Later
Gmane got new maintainer[2], but without code for web interface
(I don't know why it is).
So there is hope that Gmane web interface would be up some time in
the future; in meantime one can use public-inbox URLs.
HTH,
--
Jakub Narębski
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2016, #07; Fri, 23)
From: Johannes Schindelin @ 2016-09-24 19:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqqlgyiz0lr.fsf@gitster.mtv.corp.google.com>
Hi Junio,
On Fri, 23 Sep 2016, Junio C Hamano wrote:
> A bunch of topics have graduated to 'next', including a few that
> were so far marked as "needs review" or "will hold", as I think
> giving them a greater visibility and guinea pigs would be the most
> efficient way to get feedback from the real world ;-) Some of them
> may be "Meh" topic, which might be why they weren't getting any
> feedback so far, but at least this way we'd know if there are
> breakages in them (in which case we can just revert and discard
> them).
In your previous kitchen status ("What's cooking") you hinted at a
possible v2.10.1 soon. I have a couple of bugfixes lined up for Git for
Windows and would like to avoid unnecessarily frequent release
engineering... Any more concrete ideas on a date for this version?
Also, I found https://tinyurl.com/gitCal very convenient a URL to point
to, do you plan to update that for v2.11.0?
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH v2 4/3] init: combine set_git_dir_init() and init_db() into one
From: Junio C Hamano @ 2016-09-24 18:55 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, git, max.nordlund
In-Reply-To: <xmqqshsqz0s1.fsf@gitster.mtv.corp.google.com>
Junio C Hamano <gitster@pobox.com> writes:
> I think this 4/3 is not quite enough to fix the damage to the code
> caused by 2/3.
> ...
> after 4/3 is applied, we should be able to remove the global
> variable 2/3 introduced, make init_db() receive that information as
> the return value of set_git_dir_init(), and pass that as a parameter
> to create_default_files().
That would look something like this squashed into 4/3, I think. I
am not sure if a commit that squashes 2/3, 3/3, 4/3 and this update
together is harder to understand than keeping 2/3, 3/3 and a fixed
4/3 separate, though. The end result looks much better structured
than before 2/3 is applied to my quick scan-through of the code.
In any case, the log message of 2/3 needs to be updated to retitle
it, I think. "do not ... more often than necessary" makes it sound
as if we were doing things that did not make any difference in the
end result, wasting cycles. But what you actually wanted to achieve
was not to "avoid unnecessary work"--doing so gave a broken
behaviour and that was what you were fixing, "do not record broken
core.worktree", perhaps?
The solution (if we squash 2-4 and the fixup below) is to stop
feeding get_git_dir() to needs_work_tree_config(), because the
parameter to the latter is the path to ".git" that presumably is at
the top of the working tree, and get_git_dir() is not that when
"gitdir" file is involved. So a rewritten log message may say
something like...
init: do not set unnecessary core.worktree
The function needs_work_tree_config() that is called from
create_default_files() is supposed to be fed the path to ".git"
that looks as if it is at the top of the working tree, and
decide if that location matches the actual worktree being used.
This comparison allows "git init" to decide if core.worktree
needs to be recorded in the working tree.
In the current code, however, we feed the return value from
get_git_dir(), which can be totally different from what the
function expects when "gitdir" file is involved. Instead of
giving the path to the ".git" at the top of the working tree, we
end up feeding the actual path that the file points at.
This original location of ".git" however is only known to a
helper function set_git_dir_init() that must be called before
init_db() is called (they both have only two callsites, one in
"git init" and the other in "git clone"), and in the current
code, this original location is not visible to its callers.
By doing the following two things:
* Move call to set_git_dir_init() to init_db(), as the two must
always be called in this order, and adjust its current
callers.
* Make set_git_dir_init() return the original location of ".git"
to the caller, which is init_db(), and have it passed to
create_default_files() as a new parameter.
pass the correct location down to needs_work_tree_config() to fix
this.
This suggests that 2/3, 3/3 and fixed 4/3 could be done in two
logical steps. The first bullet point can be done as a separate
preparatory step, and on top of that, the second bullet point can be
done as a separate "fix".
builtin/init-db.c | 21 +++++++++++----------
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/builtin/init-db.c b/builtin/init-db.c
index ee7942f..527722c 100644
--- a/builtin/init-db.c
+++ b/builtin/init-db.c
@@ -23,7 +23,6 @@ static int init_is_bare_repository = 0;
static int init_shared_repository = -1;
static const char *init_db_template_dir;
static const char *git_link;
-static const char *original_git_dir;
static void copy_templates_1(struct strbuf *path, struct strbuf *template,
DIR *dir)
@@ -172,7 +171,8 @@ static int needs_work_tree_config(const char *git_dir, const char *work_tree)
return 1;
}
-static int create_default_files(const char *template_path)
+static int create_default_files(const char *template_path,
+ const char *original_git_dir)
{
struct stat st1;
struct strbuf buf = STRBUF_INIT;
@@ -312,11 +312,11 @@ static void create_object_directory(void)
strbuf_release(&path);
}
-static int set_git_dir_init(const char *git_dir,
- const char *real_git_dir,
- int exist_ok)
+static char *set_git_dir_init(const char *git_dir,
+ const char *real_git_dir,
+ int exist_ok)
{
- original_git_dir = xstrdup(real_path(git_dir));
+ char *original_git_dir = xstrdup(real_path(git_dir));
if (real_git_dir) {
struct stat st;
@@ -339,7 +339,7 @@ static int set_git_dir_init(const char *git_dir,
git_link = NULL;
}
startup_info->have_repository = 1;
- return 0;
+ return original_git_dir;
}
static void separate_git_dir(const char *git_dir)
@@ -367,9 +367,10 @@ int init_db(const char *git_dir, const char *real_git_dir,
const char *template_dir, unsigned int flags)
{
int reinit;
+ char *original_git_dir;
- set_git_dir_init(git_dir, real_git_dir, flags & INIT_DB_EXIST_OK);
-
+ flags |= INIT_DB_EXIST_OK;
+ original_git_dir = set_git_dir_init(git_dir, real_git_dir, flags);
git_dir = get_git_dir();
if (git_link)
@@ -386,7 +387,7 @@ int init_db(const char *git_dir, const char *real_git_dir,
*/
check_repository_format();
- reinit = create_default_files(template_dir);
+ reinit = create_default_files(template_dir, original_git_dir);
create_object_directory();
^ permalink raw reply related
* Re: [PATCH v3] checkout: eliminate unnecessary merge for trivial checkout
From: Junio C Hamano @ 2016-09-24 18:26 UTC (permalink / raw)
To: Philip Oakley; +Cc: Ben Peart, pclouds, git
In-Reply-To: <99A866BEF8944598A50C6E061A703297@PhilipOakley>
"Philip Oakley" <philipoakley@iee.org> writes:
>> > >"git checkout -b foo" (without -f -m or <start_point>) is defined in
>> > >the manual as being a shortcut for/equivalent to:
>> > >
>> > > (1a) "git branch foo"
>> > > (1b) "git checkout foo"
>> > >
>> > >However, it has been our experience in our observed use cases and all
>> > >the existing git tests, that it can be treated as equivalent to:
>> > >
>> > > (2a) "git branch foo"
>> > > (2b) "git symbolic-ref HEAD refs/heads/foo"
>> > >...
>> > >
>> > I am still not sure if I like the change of what "checkout -b" is this
>> > late in the game, though.
>>
>> ...
>> That said, you're much more on the frontline of receiving negative
>> feedback about doing that than I am. :) How would you like to
>> proceed?
>
> I didn't see an initial confirmation as to what the issue really
> was. You indicated the symptom ('a long checkout time'), but then we
> missed out on hard facts and example repos, so that the issue was
> replicable.
I took it as a given, trivial and obvious optimization opportunity,
that it is wasteful having to traverse two trees to consolidate and
reflect their differences into the working tree when we know upfront
that these two trees are identical, no matter what the overhead for
doing so is.
> At the moment there is the simple workaround of an alias that executes
> that two step command dance to achieve what you needed, and Junio has
> outlined the issues he needed to be covered from his maintainer
> perspective (e.g. the detection of sparse checkouts). Confirming the
> root causes would help in setting a baseline.
>
> I hope that is of help - I'd seen that the discussion had gone quiet.
Some of the problems I have are:
(1) "git checkout -b NEW", "git checkout", "git checkout HEAD^0"
and "git checkout HEAD" (no other parameters to any of them)
ought to give identical index and working tree. It is too
confusing to leave subtly different results that will lead to
hard to diagnose bugs for only one of them.
(2) The proposed log message talks only about "performance
optimization", while the purpose of the change is more about
changing the definition of what "git checkout -b NEW" is from
"git branch NEW && git checkout NEW" to "git branch NEW && git
symbolic-ref HEAD refs/heads/NEW". The explanation in a Ben's
later message <007401d21278$445eba80$cd1c2f80$@gmail.com> does
a much better job contrasting the two.
(3) I identified only one difference as an example sufficient to
point out why the patch provided is not a pure optimization but
behaviour change. Fixing that example alone to avoid change in
the behaviour is trivial (see if the "info/sparse-checkout"
file is present and refrain from skipping the proper checkout),
but a much larger problem is that I do not know (and Ben does
not, I suspect) know what other behaviour changes the patch is
introducing, and worse, the checks are sufficiently dense too
detailed and intimate to the implementation of unpack_trees()
that it is impossible for anybody to make sure the exceptions
defined in this patch and updates to other parts of the system
will be kept in sync.
So my inclination at this point, unless we see somebody invents a
clever way to solve (3), is that any change that violates (1),
i.e. as long as the patch does "Are we doing '-b NEW'? Then we do
something subtly different", is not acceptable, and solving (3) in a
maintainable way smells like quite a hard thing to do. But it would
be ideal if (3) is solved cleanly, as we will then not have to worry
about changing behaviour at all and can apply the optimization for
all of the four cases equally. As a side effect, that approach
would solve problem (2) above.
If we were to punt on keeping the sanity (1) and introduce a subtly
different "create a new branch and point the HEAD at it", an easier
way out may be be one of
1. a totally new command, e.g. "git branch-switch NEW" that takes
only a single argument and no other "checkout" options, or
2. a new option to "git checkout" that takes _ONLY_ a single
argument and incompatible with any other option or command line
argument, or
3. an alias that does "git branch" followed by "git symbolic-ref".
Neither of the first two sounds palatable, though.
^ permalink raw reply
* Re: [PATCH] git-gui: stop using deprecated merge syntax
From: Johannes Sixt @ 2016-09-24 18:22 UTC (permalink / raw)
To: René Scharfe
Cc: Git List, Pat Thoyts, Junio C Hamano, Dennis Kaarsemaker
In-Reply-To: <cbb1815e-0ebc-e103-927e-14d7d038245a@web.de>
Am 24.09.2016 um 13:30 schrieb René Scharfe:
> Starting with v2.5.0 git merge can handle FETCH_HEAD internally and
> warns when it's called like 'git merge <message> HEAD <commit>' because
> that syntax is deprecated. Use this feature in git-gui and get rid of
> that warning.
>
> Signed-off-by: Rene Scharfe <l.s.r@web.de>
> ---
> Tested only _very_ lightly!
>
> git-gui/lib/merge.tcl | 7 +------
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/git-gui/lib/merge.tcl b/git-gui/lib/merge.tcl
> index 460d32f..5ab6f8f 100644
> --- a/git-gui/lib/merge.tcl
> +++ b/git-gui/lib/merge.tcl
> @@ -112,12 +112,7 @@ method _start {} {
> close $fh
> set _last_merged_branch $branch
>
> - set cmd [list git]
> - lappend cmd merge
> - lappend cmd --strategy=recursive
> - lappend cmd [git fmt-merge-msg <[gitdir FETCH_HEAD]]
> - lappend cmd HEAD
> - lappend cmd $name
> + set cmd [list git merge --strategy=recursive FETCH_HEAD]
>
> ui_status [mc "Merging %s and %s..." $current_branch $stitle]
> set cons [console::new [mc "Merge"] "merge $stitle"]
>
Much better than my version. I had left fmt-merge-msg and added --no-log
to treat merge.log config suitably. But this works too, and is much more
obvious.
Tested-by: Johannes Sixt <j6t@kdbg.org>
-- Hannes
^ permalink raw reply
* Re: [PATCH v3 2/2] gitweb: use highlight's shebang detection
From: Junio C Hamano @ 2016-09-24 17:52 UTC (permalink / raw)
To: Jakub Narębski; +Cc: Ian Kelling, git
In-Reply-To: <946807ff-1570-2d81-1026-06529164f8ef@gmail.com>
Jakub Narębski <jnareb@gmail.com> writes:
>> Also, "curling" is not the word I would like to see. I would say:
>>
>> Simple benchmark comparing performance of 'blob' view of files without
>> syntax highlighting in gitweb before and after this change indicates
>> ±1% difference in request time for all file types. Benchmark was
>> performed on local instance on Debian, using Apache/2.4.23 web server
>> and CGI/PSGI/FCGI/mod_perl.
>>
>> ^^^^^^^^^^^^^^^^^^^^^^--- select one
or state that all of them produced similar results ;-)
>> Or something like that; I'm not sure how detailed this should be.
>> But it is nice to have such benchmark in the commit message.
>
> Sidenote: this way of benchmarking of gitweb falls between two ways of
> doing a benchmark.
All good comments. Thanks.
^ permalink raw reply
* Re: [PATCH v3 2/2] gitweb: use highlight's shebang detection
From: Jakub Narębski @ 2016-09-24 16:21 UTC (permalink / raw)
To: Ian Kelling, git
In-Reply-To: <2a4c3efb-2145-b699-c980-3079f165a6e1@gmail.com>
W dniu 24.09.2016 o 00:15, Jakub Narębski pisze:
> W dniu 23.09.2016 o 11:08, Ian Kelling napisał:
>> After curling blob view of unhighlighted large and small text
>> files of perl code and license text 100 times each on a local
>> Apache/2.4.23 (Debian) instance, it's logs indicate +-1% difference in
>> request time for all file types.
>
> Also, "curling" is not the word I would like to see. I would say:
>
> Simple benchmark comparing performance of 'blob' view of files without
> syntax highlighting in gitweb before and after this change indicates
> ±1% difference in request time for all file types. Benchmark was
> performed on local instance on Debian, using Apache/2.4.23 web server
> and CGI/PSGI/FCGI/mod_perl.
>
> ^^^^^^^^^^^^^^^^^^^^^^--- select one
>
> Or something like that; I'm not sure how detailed this should be.
> But it is nice to have such benchmark in the commit message.
Sidenote: this way of benchmarking of gitweb falls between two ways of
doing a benchmark.
The first method is to simply run gitweb as a standalone script, passing
its parameters in CGI environment variables; just like the test suite
does it. You would 'time' / 'times' it a few times, drop outliers, and
take average or a median. With this method you don't even need to set
up a web server.
The second is to use a specialized program to benchmark the server-side
of a web page, for example 'ab' (ApacheBench), httperf, curl-loader
or JMeter. The first one is usually distributed together with Apache
web server, so you probably have it installed already. Those tools
provide timing statistics.
[...]
> Note that the performance loss might be quite higher on MS Windows, with
> its higher cost of fork. But then they probably do not configure
> server-side highligher anyway.
^ permalink raw reply
* Re: [PATCH v3] checkout: eliminate unnecessary merge for trivial checkout
From: Philip Oakley @ 2016-09-24 14:28 UTC (permalink / raw)
To: Ben Peart, Junio C Hamano; +Cc: pclouds, git
In-Reply-To: <BL2PR03MB323ADC371E49EFD1CBBC566F4F60@BL2PR03MB323.namprd03.prod.outlook.com>
Ben,
Using a 'bottom / in-line' posting flow is much preferred, which may require
some manual editing[1], hopefully I have it about right...
Philip
--
[1] this is massaged and mangled Outlook Express, sometimes one has to work
with the tools at hand...
From: "Ben Peart" <Ben.Peart@microsoft.com>
> From: Junio C Hamano [mailto:gitster@pobox.com]
> > Junio C Hamano <gitster@pobox.comwrites:
> >
> > >"git checkout -b foo" (without -f -m or <start_point>) is defined in
> > >the manual as being a shortcut for/equivalent to:
> > >
> > > (1a) "git branch foo"
> > > (1b) "git checkout foo"
> > >
> > >However, it has been our experience in our observed use cases and all
> > >the existing git tests, that it can be treated as equivalent to:
> > >
> > > (2a) "git branch foo"
> > > (2b) "git symbolic-ref HEAD refs/heads/foo"
> > >...
> > >
> > I am still not sure if I like the change of what "checkout -b" is this
> > late in the game, though.
> >
> > Having said all that.
> >
> > I do see the merit of having a shorthand way to invoke your 2 above.
> > It is just that I am not convinced that it is the best way to achieve
> > that goal to redefine what "git checkout -b <new-name>" (no other
> > parameters) does.
> >
> ---
>
> I understand the reluctance to change the existing behavior of the "git
> checkout -b <new-name>" command.
>
> I see this as a tradeoff between taking advantage of the muscle memory for
> the existing command and coming up with a new shortcut command and
> training people to use it instead.
>
> The fact that all the use cases we've observed and all the git test cases
> actually produce the same results but significantly faster with that
> change in behavior made me hope we could redefine the command to take
> advantage of the muscle memory.
>
> That said, you're much more on the frontline of receiving negative
> feedback about doing that than I am. :) How would you like to proceed?
The discussion can often feel harsh [2], especially if there is accidental
'talking past each other', which is usually because of differing
perspectives on the issues.
I didn't see an initial confirmation as to what the issue really was. You
indicated the symptom ('a long checkout time'), but then we missed out on
hard facts and example repos, so that the issue was replicable.
Is there an example public repo that you can show the issue on? (or
anonymise a private one - there is a script for that [3])
Can you give local timings (and indication of the hardware and software
versions used for the test, and if appropriate, network setup)?
I know at my work that sometime our home drives are multiply mapped to H:, a
C:/homedrive directory and a $netshare/me network directory via the
Microsofy roaming profiles, and if there is hard synchronization (or
whatever term is appropriate) there can be sudden slowdowns as local C:
writes drop from 'instant' to 'forever'...
Is there anything special about the repos that have the delays? Is it a
local process issue that causes the repos to develop those symptoms (see
above about not being sure why you have these issues), in which case it
could be local self inflicted issues, or it could be that you have a
regulatory issue for that domain that requires such symptoms, which would
shift the problem from a 'don't do that' response to a 'hmm, how to cover
this'.
At the moment there is the simple workaround of an alias that executes that
two step command dance to achieve what you needed, and Junio has outlined
the issues he needed to be covered from his maintainer perspective (e.g. the
detection of sparse checkouts). Confirming the root causes would help in
setting a baseline.
I hope that is of help - I'd seen that the discussion had gone quiet.
--
Philip
[2] Been there, feel your pain. It's not in any way malicious, just a
reflection that email can be a poor medium for such discussions.
[3] https://public-inbox.org/git/20140827170127.GA6138@peff.net/ suggest
that the `git fast-export --anonymize --all` maybe the approach.
^ permalink raw reply
* [PATCH] git-gui: stop using deprecated merge syntax
From: René Scharfe @ 2016-09-24 11:30 UTC (permalink / raw)
To: Git List, Pat Thoyts; +Cc: Junio C Hamano, Johannes Sixt, Dennis Kaarsemaker
Starting with v2.5.0 git merge can handle FETCH_HEAD internally and
warns when it's called like 'git merge <message> HEAD <commit>' because
that syntax is deprecated. Use this feature in git-gui and get rid of
that warning.
Signed-off-by: Rene Scharfe <l.s.r@web.de>
---
Tested only _very_ lightly!
git-gui/lib/merge.tcl | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/git-gui/lib/merge.tcl b/git-gui/lib/merge.tcl
index 460d32f..5ab6f8f 100644
--- a/git-gui/lib/merge.tcl
+++ b/git-gui/lib/merge.tcl
@@ -112,12 +112,7 @@ method _start {} {
close $fh
set _last_merged_branch $branch
- set cmd [list git]
- lappend cmd merge
- lappend cmd --strategy=recursive
- lappend cmd [git fmt-merge-msg <[gitdir FETCH_HEAD]]
- lappend cmd HEAD
- lappend cmd $name
+ set cmd [list git merge --strategy=recursive FETCH_HEAD]
ui_status [mc "Merging %s and %s..." $current_branch $stitle]
set cons [console::new [mc "Merge"] "merge $stitle"]
--
2.10.0
^ permalink raw reply related
* Re: [PATCH] run-command: async_exit no longer needs to be public
From: Ramsay Jones @ 2016-09-24 1:04 UTC (permalink / raw)
To: Junio C Hamano, Lars Schneider; +Cc: Jeff King, GIT Mailing-list
In-Reply-To: <xmqq60pm1kp3.fsf@gitster.mtv.corp.google.com>
On 23/09/16 20:26, Junio C Hamano wrote:
> Lars Schneider <larsxschneider@gmail.com> writes:
>
>>> I do not offhand know if the topic is otherwise ready as-is, or
>>> needs further work. When you need to reroll, you'd also need to
>>> fetch from the result of the above from me first and then start your
>>> work from it, though, if we go that route.
>>
>> Sounds good to me!
>
> OK, here is what I queued, then.
This looks good to me. Thanks!
ATB,
Ramsay Jones
^ permalink raw reply
* [PATCH 3/3 v3] ls-files: add pathspec matching for submodules
From: Brandon Williams @ 2016-09-24 0:13 UTC (permalink / raw)
To: git; +Cc: Brandon Williams
In-Reply-To: <1474676014-134568-1-git-send-email-bmwill@google.com>
Pathspecs can be a bit tricky when trying to apply them to submodules.
The main challenge is that the pathspecs will be with respect to the
superproject and not with respect to paths in the submodule. The
approach this patch takes is to pass in the identical pathspec from the
superproject to the submodule in addition to the submodule-prefix, which
is the path from the root of the superproject to the submodule, and then
we can compare an entry in the submodule prepended with the
submodule-prefix to the pathspec in order to determine if there is a
match.
This patch also permits the pathspec logic to perform a prefix match against
submodules since a pathspec could refer to a file inside of a submodule.
Due to limitations in the wildmatch logic, a prefix match is only done
literally. If any wildcard character is encountered we'll simply punt
and produce a false positive match. More accurate matching will be done
once inside the submodule. This is due to the superproject not knowing
what files could exist in the submodule.
Signed-off-by: Brandon Williams <bmwill@google.com>
---
builtin/ls-files.c | 134 ++++++++++++++++++++-------------
dir.c | 46 ++++++++++-
dir.h | 4 +
t/t3007-ls-files-recurse-submodules.sh | 126 +++++++++++++++++++++++++++++--
4 files changed, 248 insertions(+), 62 deletions(-)
diff --git a/builtin/ls-files.c b/builtin/ls-files.c
index 54ab765..8ecffd1 100644
--- a/builtin/ls-files.c
+++ b/builtin/ls-files.c
@@ -177,6 +177,7 @@ static void show_gitlink(const struct cache_entry *ce)
{
struct child_process cp = CHILD_PROCESS_INIT;
int status;
+ int i;
argv_array_push(&cp.args, "ls-files");
argv_array_push(&cp.args, "--recurse-submodules");
@@ -184,6 +185,29 @@ static void show_gitlink(const struct cache_entry *ce)
GIT_SUBMODULE_PREFIX_ENVIRONMENT,
submodule_prefix ? submodule_prefix : "",
ce->name);
+ /* add options */
+ if (show_eol)
+ argv_array_push(&cp.args, "--eol");
+ if (show_valid_bit)
+ argv_array_push(&cp.args, "-v");
+ if (show_stage)
+ argv_array_push(&cp.args, "--stage");
+ if (show_cached)
+ argv_array_push(&cp.args, "--cached");
+ if (debug_mode)
+ argv_array_push(&cp.args, "--debug");
+ if (line_terminator == '\0')
+ argv_array_push(&cp.args, "-z");
+
+ /*
+ * Pass in the original pathspec args. The submodule will be
+ * responsible for prepending the 'submodule_prefix' prior to comparing
+ * against the pathspec for matches.
+ */
+ argv_array_push(&cp.args, "--");
+ for (i = 0; i < pathspec.nr; i++)
+ argv_array_push(&cp.args, pathspec.items[i].original);
+
cp.git_cmd = 1;
cp.dir = ce->name;
status = run_command(&cp);
@@ -193,57 +217,62 @@ static void show_gitlink(const struct cache_entry *ce)
static void show_ce_entry(const char *tag, const struct cache_entry *ce)
{
+ struct strbuf name = STRBUF_INIT;
int len = max_prefix_len;
+ if (submodule_prefix)
+ strbuf_addstr(&name, submodule_prefix);
+ strbuf_addstr(&name, ce->name);
if (len >= ce_namelen(ce))
die("git ls-files: internal error - cache entry not superset of prefix");
- if (!match_pathspec(&pathspec, ce->name, ce_namelen(ce),
- len, ps_matched,
- S_ISDIR(ce->ce_mode) || S_ISGITLINK(ce->ce_mode)))
- return;
- if (recurse_submodules && S_ISGITLINK(ce->ce_mode)) {
+ if (recurse_submodules && S_ISGITLINK(ce->ce_mode) &&
+ submodule_path_match(&pathspec, name.buf, ps_matched)) {
show_gitlink(ce);
- return;
- }
+ } else if (match_pathspec(&pathspec, name.buf, name.len,
+ len, ps_matched,
+ S_ISDIR(ce->ce_mode) ||
+ S_ISGITLINK(ce->ce_mode))) {
+ if (tag && *tag && show_valid_bit &&
+ (ce->ce_flags & CE_VALID)) {
+ static char alttag[4];
+ memcpy(alttag, tag, 3);
+ if (isalpha(tag[0]))
+ alttag[0] = tolower(tag[0]);
+ else if (tag[0] == '?')
+ alttag[0] = '!';
+ else {
+ alttag[0] = 'v';
+ alttag[1] = tag[0];
+ alttag[2] = ' ';
+ alttag[3] = 0;
+ }
+ tag = alttag;
+ }
- if (tag && *tag && show_valid_bit &&
- (ce->ce_flags & CE_VALID)) {
- static char alttag[4];
- memcpy(alttag, tag, 3);
- if (isalpha(tag[0]))
- alttag[0] = tolower(tag[0]);
- else if (tag[0] == '?')
- alttag[0] = '!';
- else {
- alttag[0] = 'v';
- alttag[1] = tag[0];
- alttag[2] = ' ';
- alttag[3] = 0;
+ if (!show_stage) {
+ fputs(tag, stdout);
+ } else {
+ printf("%s%06o %s %d\t",
+ tag,
+ ce->ce_mode,
+ find_unique_abbrev(ce->sha1,abbrev),
+ ce_stage(ce));
+ }
+ write_eolinfo(ce, ce->name);
+ write_name(ce->name);
+ if (debug_mode) {
+ const struct stat_data *sd = &ce->ce_stat_data;
+
+ printf(" ctime: %d:%d\n", sd->sd_ctime.sec, sd->sd_ctime.nsec);
+ printf(" mtime: %d:%d\n", sd->sd_mtime.sec, sd->sd_mtime.nsec);
+ printf(" dev: %d\tino: %d\n", sd->sd_dev, sd->sd_ino);
+ printf(" uid: %d\tgid: %d\n", sd->sd_uid, sd->sd_gid);
+ printf(" size: %d\tflags: %x\n", sd->sd_size, ce->ce_flags);
}
- tag = alttag;
}
- if (!show_stage) {
- fputs(tag, stdout);
- } else {
- printf("%s%06o %s %d\t",
- tag,
- ce->ce_mode,
- find_unique_abbrev(ce->sha1,abbrev),
- ce_stage(ce));
- }
- write_eolinfo(ce, ce->name);
- write_name(ce->name);
- if (debug_mode) {
- const struct stat_data *sd = &ce->ce_stat_data;
-
- printf(" ctime: %d:%d\n", sd->sd_ctime.sec, sd->sd_ctime.nsec);
- printf(" mtime: %d:%d\n", sd->sd_mtime.sec, sd->sd_mtime.nsec);
- printf(" dev: %d\tino: %d\n", sd->sd_dev, sd->sd_ino);
- printf(" uid: %d\tgid: %d\n", sd->sd_uid, sd->sd_gid);
- printf(" size: %d\tflags: %x\n", sd->sd_size, ce->ce_flags);
- }
+ strbuf_release(&name);
}
static void show_ru_info(void)
@@ -568,27 +597,28 @@ int cmd_ls_files(int argc, const char **argv, const char *cmd_prefix)
submodule_prefix = getenv(GIT_SUBMODULE_PREFIX_ENVIRONMENT);
if (recurse_submodules &&
- (show_stage || show_deleted || show_others || show_unmerged ||
- show_killed || show_modified || show_resolve_undo ||
- show_valid_bit || show_tag || show_eol))
- die("ls-files --recurse-submodules can only be used in "
- "--cached mode");
+ (show_deleted || show_others || show_unmerged ||
+ show_killed || show_modified || show_resolve_undo))
+ die("ls-files --recurse-submodules unsupported mode");
if (recurse_submodules && error_unmatch)
die("ls-files --recurse-submodules does not support "
"--error-unmatch");
- if (recurse_submodules && argc)
- die("ls-files --recurse-submodules does not support path "
- "arguments");
-
parse_pathspec(&pathspec, 0,
PATHSPEC_PREFER_CWD |
PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP,
prefix, argv);
- /* Find common prefix for all pathspec's */
- max_prefix = common_prefix(&pathspec);
+ /*
+ * Find common prefix for all pathspec's
+ * This is used as a performance optimization which unfortunately cannot
+ * be done when recursing into submodules
+ */
+ if (recurse_submodules)
+ max_prefix = NULL;
+ else
+ max_prefix = common_prefix(&pathspec);
max_prefix_len = max_prefix ? strlen(max_prefix) : 0;
/* Treat unmatching pathspec elements as errors */
diff --git a/dir.c b/dir.c
index 0ea235f..28e9736 100644
--- a/dir.c
+++ b/dir.c
@@ -207,8 +207,9 @@ int within_depth(const char *name, int namelen,
return 1;
}
-#define DO_MATCH_EXCLUDE 1
-#define DO_MATCH_DIRECTORY 2
+#define DO_MATCH_EXCLUDE (1<<0)
+#define DO_MATCH_DIRECTORY (1<<1)
+#define DO_MATCH_SUBMODULE (1<<2)
/*
* Does 'match' match the given name?
@@ -283,6 +284,32 @@ static int match_pathspec_item(const struct pathspec_item *item, int prefix,
item->nowildcard_len - prefix))
return MATCHED_FNMATCH;
+ /* Perform checks to see if "name" is a super set of the pathspec */
+ if (flags & DO_MATCH_SUBMODULE) {
+ /* name is a literal prefix of the pathspec */
+ if ((namelen < matchlen) &&
+ (match[namelen] == '/') &&
+ !ps_strncmp(item, match, name, namelen))
+ return MATCHED_RECURSIVELY;
+
+ /* name" doesn't match up to the first wild character */
+ if (item->nowildcard_len < item->len &&
+ ps_strncmp(item, match, name,
+ item->nowildcard_len - prefix))
+ return 0;
+
+ /*
+ * Here is where we would perform a wildmatch to check if
+ * "name" can be matched as a directory (or a prefix) against
+ * the pathspec. Since wildmatch doesn't have this capability
+ * at the present we have to punt and say that it is a match,
+ * potentially returning a false positive
+ * The submodules themselves will be able to perform more
+ * accurate matching to determine if the pathspec matches.
+ */
+ return MATCHED_RECURSIVELY;
+ }
+
return 0;
}
@@ -386,6 +413,21 @@ int match_pathspec(const struct pathspec *ps,
return negative ? 0 : positive;
}
+/**
+ * Check if a submodule is a superset of the pathspec
+ */
+int submodule_path_match(const struct pathspec *ps,
+ const char *submodule_name,
+ char *seen)
+{
+ int matched = do_match_pathspec(ps, submodule_name,
+ strlen(submodule_name),
+ 0, seen,
+ DO_MATCH_DIRECTORY |
+ DO_MATCH_SUBMODULE);
+ return matched;
+}
+
int report_path_error(const char *ps_matched,
const struct pathspec *pathspec,
const char *prefix)
diff --git a/dir.h b/dir.h
index da1a858..97c83bb 100644
--- a/dir.h
+++ b/dir.h
@@ -304,6 +304,10 @@ extern int git_fnmatch(const struct pathspec_item *item,
const char *pattern, const char *string,
int prefix);
+extern int submodule_path_match(const struct pathspec *ps,
+ const char *submodule_name,
+ char *seen);
+
static inline int ce_path_match(const struct cache_entry *ce,
const struct pathspec *pathspec,
char *seen)
diff --git a/t/t3007-ls-files-recurse-submodules.sh b/t/t3007-ls-files-recurse-submodules.sh
index caf3815..4a51d38 100755
--- a/t/t3007-ls-files-recurse-submodules.sh
+++ b/t/t3007-ls-files-recurse-submodules.sh
@@ -34,6 +34,18 @@ test_expect_success 'ls-files correctly outputs files in submodule' '
test_cmp expect actual
'
+test_expect_success 'ls-files correctly outputs files in submodule with -z' '
+ cat | tr "\n" "\0" >expect <<-\EOF &&
+ .gitmodules
+ a
+ b/b
+ submodule/c
+ EOF
+
+ git ls-files --recurse-submodules -z >actual &&
+ test_cmp expect actual
+'
+
test_expect_success 'ls-files does not output files not added to a repo' '
cat >expect <<-\EOF &&
.gitmodules
@@ -69,9 +81,111 @@ test_expect_success 'ls-files recurses more than 1 level' '
test_cmp expect actual
'
-test_expect_success '--recurse-submodules does not support using path arguments' '
- test_must_fail git ls-files --recurse-submodules b 2>actual &&
- test_i18ngrep "does not support path arguments" actual
+test_expect_success '--recurse-submodules and pathspecs setup' '
+ echo e >submodule/subsub/e.txt &&
+ git -C submodule/subsub add e.txt &&
+ git -C submodule/subsub commit -m "adding e.txt" &&
+ echo f >submodule/f.TXT &&
+ echo g >submodule/g.txt &&
+ git -C submodule add f.TXT g.txt &&
+ git -C submodule commit -m "add f and g" &&
+ echo h >h.txt &&
+ mkdir sib &&
+ echo sib >sib/file &&
+ git add h.txt sib/file &&
+ git commit -m "add h and sib/file" &&
+ git init sub &&
+ echo sub >sub/file &&
+ git -C sub add file &&
+ git -C sub commit -m "add file" &&
+ git submodule add ./sub &&
+ git commit -m "added sub" &&
+
+ cat >expect <<-\EOF &&
+ .gitmodules
+ a
+ b/b
+ h.txt
+ sib/file
+ sub/file
+ submodule/.gitmodules
+ submodule/c
+ submodule/f.TXT
+ submodule/g.txt
+ submodule/subsub/d
+ submodule/subsub/e.txt
+ EOF
+
+ git ls-files --recurse-submodules >actual &&
+ test_cmp expect actual &&
+ cat actual &&
+ git ls-files --recurse-submodules "*" >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success '--recurse-submodules and pathspecs' '
+ cat >expect <<-\EOF &&
+ h.txt
+ submodule/g.txt
+ submodule/subsub/e.txt
+ EOF
+
+ git ls-files --recurse-submodules "*.txt" >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success '--recurse-submodules and pathspecs' '
+ cat >expect <<-\EOF &&
+ h.txt
+ submodule/f.TXT
+ submodule/g.txt
+ submodule/subsub/e.txt
+ EOF
+
+ git ls-files --recurse-submodules ":(icase)*.txt" >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success '--recurse-submodules and pathspecs' '
+ cat >expect <<-\EOF &&
+ h.txt
+ submodule/f.TXT
+ submodule/g.txt
+ EOF
+
+ git ls-files --recurse-submodules ":(icase)*.txt" ":(exclude)submodule/subsub/*" >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success '--recurse-submodules and pathspecs' '
+ cat >expect <<-\EOF &&
+ sub/file
+ EOF
+
+ git ls-files --recurse-submodules "sub" >actual &&
+ test_cmp expect actual &&
+ git ls-files --recurse-submodules "sub/" >actual &&
+ test_cmp expect actual &&
+ git ls-files --recurse-submodules "sub/file" >actual &&
+ test_cmp expect actual &&
+ git ls-files --recurse-submodules "su*/file" >actual &&
+ test_cmp expect actual &&
+ git ls-files --recurse-submodules "su?/file" >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success '--recurse-submodules and pathspecs' '
+ cat >expect <<-\EOF &&
+ sib/file
+ sub/file
+ EOF
+
+ git ls-files --recurse-submodules "s??/file" >actual &&
+ test_cmp expect actual &&
+ git ls-files --recurse-submodules "s???file" >actual &&
+ test_cmp expect actual &&
+ git ls-files --recurse-submodules "s*file" >actual &&
+ test_cmp expect actual
'
test_expect_success '--recurse-submodules does not support --error-unmatch' '
@@ -82,18 +196,14 @@ test_expect_success '--recurse-submodules does not support --error-unmatch' '
test_incompatible_with_recurse_submodules () {
test_expect_success "--recurse-submodules and $1 are incompatible" "
test_must_fail git ls-files --recurse-submodules $1 2>actual &&
- test_i18ngrep 'can only be used in --cached mode' actual
+ test_i18ngrep 'unsupported mode' actual
"
}
-test_incompatible_with_recurse_submodules -v
-test_incompatible_with_recurse_submodules -t
test_incompatible_with_recurse_submodules --deleted
test_incompatible_with_recurse_submodules --modified
test_incompatible_with_recurse_submodules --others
-test_incompatible_with_recurse_submodules --stage
test_incompatible_with_recurse_submodules --killed
test_incompatible_with_recurse_submodules --unmerged
-test_incompatible_with_recurse_submodules --eol
test_done
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH 2/3 v3] ls-files: optionally recurse into submodules
From: Brandon Williams @ 2016-09-24 0:13 UTC (permalink / raw)
To: git; +Cc: Brandon Williams
In-Reply-To: <1474676014-134568-1-git-send-email-bmwill@google.com>
Allow ls-files to recognize submodules in order to retrieve a list of
files from a repository's submodules. This is done by forking off a
process to recursively call ls-files on all submodules. Use environment
variable `GIT_INTERNAL_SUBMODULE_PREFIX` to pass a path to the submodule
which it can use to prepend to output or pathspec matching logic.
Signed-off-by: Brandon Williams <bmwill@google.com>
---
Documentation/git-ls-files.txt | 7 ++-
builtin/ls-files.c | 63 ++++++++++++++++++++++
t/t3007-ls-files-recurse-submodules.sh | 99 ++++++++++++++++++++++++++++++++++
3 files changed, 168 insertions(+), 1 deletion(-)
create mode 100755 t/t3007-ls-files-recurse-submodules.sh
diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
index 0d933ac..446209e 100644
--- a/Documentation/git-ls-files.txt
+++ b/Documentation/git-ls-files.txt
@@ -18,7 +18,8 @@ SYNOPSIS
[--exclude-per-directory=<file>]
[--exclude-standard]
[--error-unmatch] [--with-tree=<tree-ish>]
- [--full-name] [--abbrev] [--] [<file>...]
+ [--full-name] [--recurse-submodules]
+ [--abbrev] [--] [<file>...]
DESCRIPTION
-----------
@@ -137,6 +138,10 @@ a space) at the start of each line:
option forces paths to be output relative to the project
top directory.
+--recurse-submodules::
+ Recursively calls ls-files on each submodule in the repository.
+ Currently there is only support for the --cached mode.
+
--abbrev[=<n>]::
Instead of showing the full 40-byte hexadecimal object
lines, show only a partial prefix.
diff --git a/builtin/ls-files.c b/builtin/ls-files.c
index 00ea91a..54ab765 100644
--- a/builtin/ls-files.c
+++ b/builtin/ls-files.c
@@ -14,6 +14,7 @@
#include "resolve-undo.h"
#include "string-list.h"
#include "pathspec.h"
+#include "run-command.h"
static int abbrev;
static int show_deleted;
@@ -28,6 +29,8 @@ static int show_valid_bit;
static int line_terminator = '\n';
static int debug_mode;
static int show_eol;
+static int recurse_submodules;
+static const char *submodule_prefix;
static const char *prefix;
static int max_prefix_len;
@@ -68,6 +71,21 @@ static void write_eolinfo(const struct cache_entry *ce, const char *path)
static void write_name(const char *name)
{
/*
+ * NEEDSWORK: To make this thread-safe, full_name would have to be owned
+ * by the caller.
+ *
+ * full_name get reused across output lines to minimize the allocation
+ * churn.
+ */
+ static struct strbuf full_name = STRBUF_INIT;
+ if (submodule_prefix && *submodule_prefix) {
+ strbuf_reset(&full_name);
+ strbuf_addstr(&full_name, submodule_prefix);
+ strbuf_addstr(&full_name, name);
+ name = full_name.buf;
+ }
+
+ /*
* With "--full-name", prefix_len=0; this caller needs to pass
* an empty string in that case (a NULL is good for "").
*/
@@ -152,6 +170,27 @@ static void show_killed_files(struct dir_struct *dir)
}
}
+/**
+ * Recursively call ls-files on a submodule
+ */
+static void show_gitlink(const struct cache_entry *ce)
+{
+ struct child_process cp = CHILD_PROCESS_INIT;
+ int status;
+
+ argv_array_push(&cp.args, "ls-files");
+ argv_array_push(&cp.args, "--recurse-submodules");
+ argv_array_pushf(&cp.env_array, "%s=%s%s/",
+ GIT_SUBMODULE_PREFIX_ENVIRONMENT,
+ submodule_prefix ? submodule_prefix : "",
+ ce->name);
+ cp.git_cmd = 1;
+ cp.dir = ce->name;
+ status = run_command(&cp);
+ if (status)
+ exit(status);
+}
+
static void show_ce_entry(const char *tag, const struct cache_entry *ce)
{
int len = max_prefix_len;
@@ -163,6 +202,10 @@ static void show_ce_entry(const char *tag, const struct cache_entry *ce)
len, ps_matched,
S_ISDIR(ce->ce_mode) || S_ISGITLINK(ce->ce_mode)))
return;
+ if (recurse_submodules && S_ISGITLINK(ce->ce_mode)) {
+ show_gitlink(ce);
+ return;
+ }
if (tag && *tag && show_valid_bit &&
(ce->ce_flags & CE_VALID)) {
@@ -468,6 +511,8 @@ int cmd_ls_files(int argc, const char **argv, const char *cmd_prefix)
{ OPTION_SET_INT, 0, "full-name", &prefix_len, NULL,
N_("make the output relative to the project top directory"),
PARSE_OPT_NOARG | PARSE_OPT_NONEG, NULL },
+ OPT_BOOL(0, "recurse-submodules", &recurse_submodules,
+ N_("recurse through submodules")),
OPT_BOOL(0, "error-unmatch", &error_unmatch,
N_("if any <file> is not in the index, treat this as an error")),
OPT_STRING(0, "with-tree", &with_tree, N_("tree-ish"),
@@ -519,6 +564,24 @@ int cmd_ls_files(int argc, const char **argv, const char *cmd_prefix)
if (require_work_tree && !is_inside_work_tree())
setup_work_tree();
+ if (recurse_submodules)
+ submodule_prefix = getenv(GIT_SUBMODULE_PREFIX_ENVIRONMENT);
+
+ if (recurse_submodules &&
+ (show_stage || show_deleted || show_others || show_unmerged ||
+ show_killed || show_modified || show_resolve_undo ||
+ show_valid_bit || show_tag || show_eol))
+ die("ls-files --recurse-submodules can only be used in "
+ "--cached mode");
+
+ if (recurse_submodules && error_unmatch)
+ die("ls-files --recurse-submodules does not support "
+ "--error-unmatch");
+
+ if (recurse_submodules && argc)
+ die("ls-files --recurse-submodules does not support path "
+ "arguments");
+
parse_pathspec(&pathspec, 0,
PATHSPEC_PREFER_CWD |
PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP,
diff --git a/t/t3007-ls-files-recurse-submodules.sh b/t/t3007-ls-files-recurse-submodules.sh
new file mode 100755
index 0000000..caf3815
--- /dev/null
+++ b/t/t3007-ls-files-recurse-submodules.sh
@@ -0,0 +1,99 @@
+#!/bin/sh
+
+test_description='Test ls-files recurse-submodules feature
+
+This test verifies the recurse-submodules feature correctly lists files from
+submodules.
+'
+
+. ./test-lib.sh
+
+test_expect_success 'setup directory structure and submodules' '
+ echo a >a &&
+ mkdir b &&
+ echo b >b/b &&
+ git add a b &&
+ git commit -m "add a and b" &&
+ git init submodule &&
+ echo c >submodule/c &&
+ git -C submodule add c &&
+ git -C submodule commit -m "add c" &&
+ git submodule add ./submodule &&
+ git commit -m "added submodule"
+'
+
+test_expect_success 'ls-files correctly outputs files in submodule' '
+ cat >expect <<-\EOF &&
+ .gitmodules
+ a
+ b/b
+ submodule/c
+ EOF
+
+ git ls-files --recurse-submodules >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success 'ls-files does not output files not added to a repo' '
+ cat >expect <<-\EOF &&
+ .gitmodules
+ a
+ b/b
+ submodule/c
+ EOF
+
+ echo a >not_added &&
+ echo b >b/not_added &&
+ echo c >submodule/not_added &&
+ git ls-files --recurse-submodules >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success 'ls-files recurses more than 1 level' '
+ cat >expect <<-\EOF &&
+ .gitmodules
+ a
+ b/b
+ submodule/.gitmodules
+ submodule/c
+ submodule/subsub/d
+ EOF
+
+ git init submodule/subsub &&
+ echo d >submodule/subsub/d &&
+ git -C submodule/subsub add d &&
+ git -C submodule/subsub commit -m "add d" &&
+ git -C submodule submodule add ./subsub &&
+ git -C submodule commit -m "added subsub" &&
+ git ls-files --recurse-submodules >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success '--recurse-submodules does not support using path arguments' '
+ test_must_fail git ls-files --recurse-submodules b 2>actual &&
+ test_i18ngrep "does not support path arguments" actual
+'
+
+test_expect_success '--recurse-submodules does not support --error-unmatch' '
+ test_must_fail git ls-files --recurse-submodules --error-unmatch 2>actual &&
+ test_i18ngrep "does not support --error-unmatch" actual
+'
+
+test_incompatible_with_recurse_submodules () {
+ test_expect_success "--recurse-submodules and $1 are incompatible" "
+ test_must_fail git ls-files --recurse-submodules $1 2>actual &&
+ test_i18ngrep 'can only be used in --cached mode' actual
+ "
+}
+
+test_incompatible_with_recurse_submodules -v
+test_incompatible_with_recurse_submodules -t
+test_incompatible_with_recurse_submodules --deleted
+test_incompatible_with_recurse_submodules --modified
+test_incompatible_with_recurse_submodules --others
+test_incompatible_with_recurse_submodules --stage
+test_incompatible_with_recurse_submodules --killed
+test_incompatible_with_recurse_submodules --unmerged
+test_incompatible_with_recurse_submodules --eol
+
+test_done
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH 1/3 v3] submodules: make submodule-prefix option an envvar
From: Brandon Williams @ 2016-09-24 0:13 UTC (permalink / raw)
To: git; +Cc: Brandon Williams
In-Reply-To: <1474676014-134568-1-git-send-email-bmwill@google.com>
Add a submodule-prefix enviorment variable
'GIT_INTERNAL_SUBMODULE_PREFIX' which can be used by commands which have
--recurse-submodule options.
Signed-off-by: Brandon Williams <bmwill@google.com>
---
cache.h | 1 +
environment.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/cache.h b/cache.h
index 3556326..ae88a35 100644
--- a/cache.h
+++ b/cache.h
@@ -408,6 +408,7 @@ static inline enum object_type object_type(unsigned int mode)
#define GIT_NAMESPACE_ENVIRONMENT "GIT_NAMESPACE"
#define GIT_WORK_TREE_ENVIRONMENT "GIT_WORK_TREE"
#define GIT_PREFIX_ENVIRONMENT "GIT_PREFIX"
+#define GIT_SUBMODULE_PREFIX_ENVIRONMENT "GIT_INTERNAL_SUBMODULE_PREFIX"
#define DEFAULT_GIT_DIR_ENVIRONMENT ".git"
#define DB_ENVIRONMENT "GIT_OBJECT_DIRECTORY"
#define INDEX_ENVIRONMENT "GIT_INDEX_FILE"
diff --git a/environment.c b/environment.c
index ca72464..7380815 100644
--- a/environment.c
+++ b/environment.c
@@ -120,6 +120,7 @@ const char * const local_repo_env[] = {
NO_REPLACE_OBJECTS_ENVIRONMENT,
GIT_REPLACE_REF_BASE_ENVIRONMENT,
GIT_PREFIX_ENVIRONMENT,
+ GIT_SUBMODULE_PREFIX_ENVIRONMENT,
GIT_SHALLOW_FILE_ENVIRONMENT,
GIT_COMMON_DIR_ENVIRONMENT,
NULL
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH 0/3] recursive support for ls-files
From: Brandon Williams @ 2016-09-24 0:13 UTC (permalink / raw)
To: git; +Cc: Brandon Williams
After looking at the feedback I rerolled a few things, in particular the
--submodule_prefix option that existed to give a submodule context about where
it had been invoked from. People didn't seem to like the idea of exposing this
to the users (yet anyways) so I removed it as an option and instead have it
being passed to a child process via an environment variable
GIT_INTERNAL_SUBMODULE_PREFIX. This way we don't have to support anything to
external users at the moment.
Also fixed a bug (and added a test) for the -z options as pointed out by Jeff
King.
Brandon Williams (3):
submodules: make submodule-prefix option an envvar
ls-files: optionally recurse into submodules
ls-files: add pathspec matching for submodules
Documentation/git-ls-files.txt | 7 +-
builtin/ls-files.c | 173 ++++++++++++++++++++-------
cache.h | 1 +
dir.c | 46 +++++++-
dir.h | 4 +
environment.c | 1 +
t/t3007-ls-files-recurse-submodules.sh | 209 +++++++++++++++++++++++++++++++++
7 files changed, 398 insertions(+), 43 deletions(-)
create mode 100755 t/t3007-ls-files-recurse-submodules.sh
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply
* Re: [PATCH 1/2] ls-files: optionally recurse into submodules
From: Brandon Williams @ 2016-09-23 23:31 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20160922062047.jbxsgfabej26jt5i@sigill.intra.peff.net>
On Wed, Sep 21, 2016 at 11:20 PM, Jeff King <peff@peff.net> wrote:
>> +/**
>> + * Recursively call ls-files on a submodule
>> + */
>> +static void show_gitlink(const struct cache_entry *ce)
>> +{
>> + struct child_process cp = CHILD_PROCESS_INIT;
>> + int status;
>> +
>> + argv_array_push(&cp.args, "ls-files");
>> + argv_array_push(&cp.args, "--recurse-submodules");
>> + argv_array_pushf(&cp.args, "--submodule-prefix=%s%s/",
>> + submodule_prefix ? submodule_prefix : "",
>> + ce->name);
>> + cp.git_cmd = 1;
>> + cp.dir = ce->name;
>> + status = run_command(&cp);
>> + if (status)
>> + exit(status);
>> +}
>
> This doesn't propagate the parent argv at all. So if I run:
>
> git ls-files -z --recurse-submodules
>
> then the paths are all NUL-terminated in the parent, but
> newline-terminated in the submodules. Oops.
Yep definitely missed that. I can fix that. I think the main reason
for not blindly
copying the argv array is that there may be some things we don't want to pass
to the child. While not in the context of ls-files, I was working on
recursive grep
earlier and with that you can pass a rev to grep. You can't blindly
copy that because
the rev is meaningless to the the child and may produce broken
output. Instead we
would need to pass the actual rev of what the parent has checked out
in that particular
rev. I haven't thought it completely through yet but it did
discourage me from blindly
copying the args across.
-Brandon
^ permalink raw reply
* What's cooking in git.git (Sep 2016, #07; Fri, 23)
From: Junio C Hamano @ 2016-09-23 22:56 UTC (permalink / raw)
To: git
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.
A bunch of topics have graduated to 'next', including a few that
were so far marked as "needs review" or "will hold", as I think
giving them a greater visibility and guinea pigs would be the most
efficient way to get feedback from the real world ;-) Some of them
may be "Meh" topic, which might be why they weren't getting any
feedback so far, but at least this way we'd know if there are
breakages in them (in which case we can just revert and discard
them).
You can find the changes described here in the integration branches
of the repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--------------------------------------------------
[New Topics]
* jk/clone-recursive-progress (2016-09-22) 1 commit
(merged to 'next' on 2016-09-22 at 8310c42)
+ clone: pass --progress decision to recursive submodules
"git clone --recurse-submodules" lost the progress eye-candy in
recent update, which has been corrected.
Will merge to 'master'.
* jk/doc-cvs-update (2016-09-22) 3 commits
(merged to 'next' on 2016-09-22 at c0f949f)
+ docs/cvs-migration: mention cvsimport caveats
+ docs/cvs-migration: update link to cvsps homepage
+ docs/cvsimport: prefer cvs-fast-export to parsecvs
Documentation around tools to import from CVS was fairly outdated.
Will merge to 'master'.
* jk/verify-packfile-gently (2016-09-22) 1 commit
- verify_packfile: check pack validity before accessing data
A low-level function verify_packfile() was meant to show errors
detected without dying itself, but under some conditions it didn't
and died instead, which has been fixed.
Will merge to 'next'.
* jt/fetch-pack-in-vain-count-with-stateless (2016-09-23) 1 commit
- fetch-pack: do not reset in_vain on non-novel acks
When "git fetch" tries to find where the history it has diverged
from what the other side has, it has a mechanism to avoid digging
too deep into irrelevant side branches. This however did not work
well over the "smart-http" transport due to a design bug, which has
been fixed.
Will merge to 'next'.
* rs/checkout-init-macro (2016-09-22) 1 commit
(merged to 'next' on 2016-09-22 at 6513755)
+ introduce CHECKOUT_INIT
Code cleanup.
Will merge to 'master'.
* ik/gitweb-force-highlight (2016-09-23) 2 commits
- gitweb: use highlight's shebang detection
- gitweb: remove unused paarmeter from guess_file_syntax()
"gitweb" can spawn "highlight" to show blob contents with
(programming) language-specific syntax highlighting, but only
when the language is known. "highlight" can however be told
to make the guess itself by giving it "--force" option, which
has been enabled.
Waiting for the discussion to conclude.
cf. <2a4c3efb-2145-b699-c980-3079f165a6e1@gmail.com>
* jk/ident-ai-canonname-could-be-null (2016-09-23) 1 commit
- ident: handle NULL ai_canonname
In the codepath that comes up with the hostname to be used in an
e-mail when the user didn't tell us, we looked at ai_canonname
field in struct addrinfo without making sure it is not NULL first.
Will merge to 'next'.
--------------------------------------------------
[Stalled]
* jc/bundle (2016-03-03) 6 commits
- index-pack: --clone-bundle option
- Merge branch 'jc/index-pack' into jc/bundle
- bundle v3: the beginning
- bundle: keep a copy of bundle file name in the in-core bundle header
- bundle: plug resource leak
- bundle doc: 'verify' is not about verifying the bundle
The beginning of "split bundle", which could be one of the
ingredients to allow "git clone" traffic off of the core server
network to CDN.
While I think it would make it easier for people to experiment and
build on if the topic is merged to 'next', I am at the same time a
bit reluctant to merge an unproven new topic that introduces a new
file format, which we may end up having to support til the end of
time. It is likely that to support a "prime clone from CDN", it
would need a lot more than just "these are the heads and the pack
data is over there", so this may not be sufficient.
Will discard.
* jc/attr (2016-05-25) 18 commits
- attr: support quoting pathname patterns in C style
- attr: expose validity check for attribute names
- attr: add counted string version of git_attr()
- attr: add counted string version of git_check_attr()
- attr: retire git_check_attrs() API
- attr: convert git_check_attrs() callers to use the new API
- attr: convert git_all_attrs() to use "struct git_attr_check"
- attr: (re)introduce git_check_attr() and struct git_attr_check
- attr: rename function and struct related to checking attributes
- attr.c: plug small leak in parse_attr_line()
- attr.c: tighten constness around "git_attr" structure
- attr.c: simplify macroexpand_one()
- attr.c: mark where #if DEBUG ends more clearly
- attr.c: complete a sentence in a comment
- attr.c: explain the lack of attr-name syntax check in parse_attr()
- attr.c: update a stale comment on "struct match_attr"
- attr.c: use strchrnul() to scan for one line
- commit.c: use strchrnul() to scan for one line
(this branch is used by jc/attr-more, sb/pathspec-label and sb/submodule-default-paths.)
The attributes API has been updated so that it can later be
optimized using the knowledge of which attributes are queried.
I wanted to polish this topic further to make the attribute
subsystem thread-ready, but because other topics depend on this
topic and they do not (yet) need it to be thread-ready.
As the authors of topics that depend on this seem not in a hurry,
let's discard this and dependent topics and restart them some other
day.
Will discard.
* jc/attr-more (2016-06-09) 8 commits
- attr.c: outline the future plans by heavily commenting
- attr.c: always pass check[] to collect_some_attrs()
- attr.c: introduce empty_attr_check_elems()
- attr.c: correct ugly hack for git_all_attrs()
- attr.c: rename a local variable check
- fixup! d5ad6c13
- attr.c: pass struct git_attr_check down the callchain
- attr.c: add push_stack() helper
(this branch uses jc/attr; is tangled with sb/pathspec-label and sb/submodule-default-paths.)
The beginning of long and tortuous journey to clean-up attribute
subsystem implementation.
Needs to be redone.
Will discard.
* sb/submodule-default-paths (2016-06-20) 5 commits
- completion: clone can recurse into submodules
- clone: add --init-submodule=<pathspec> switch
- submodule update: add `--init-default-path` switch
- Merge branch 'sb/pathspec-label' into sb/submodule-default-paths
- Merge branch 'jc/attr' into sb/submodule-default-paths
(this branch uses jc/attr and sb/pathspec-label; is tangled with jc/attr-more.)
Allow specifying the set of submodules the user is interested in on
the command line of "git clone" that clones the superproject.
Will discard.
* sb/pathspec-label (2016-06-03) 6 commits
- pathspec: disable preload-index when attribute pathspec magic is in use
- pathspec: allow escaped query values
- pathspec: allow querying for attributes
- pathspec: move prefix check out of the inner loop
- pathspec: move long magic parsing out of prefix_pathspec
- Documentation: fix a typo
(this branch is used by sb/submodule-default-paths; uses jc/attr; is tangled with jc/attr-more.)
The pathspec mechanism learned ":(attr:X)$pattern" pathspec magic
to limit paths that match $pattern further by attribute settings.
The preload-index mechanism is disabled when the new pathspec magic
is in use (at least for now), because the attribute subsystem is
not thread-ready.
Will discard.
* mh/connect (2016-06-06) 10 commits
- connect: [host:port] is legacy for ssh
- connect: move ssh command line preparation to a separate function
- connect: actively reject git:// urls with a user part
- connect: change the --diag-url output to separate user and host
- connect: make parse_connect_url() return the user part of the url as a separate value
- connect: group CONNECT_DIAG_URL handling code
- connect: make parse_connect_url() return separated host and port
- connect: re-derive a host:port string from the separate host and port variables
- connect: call get_host_and_port() earlier
- connect: document why we sometimes call get_port after get_host_and_port
Rewrite Git-URL parsing routine (hopefully) without changing any
behaviour.
It has been two months without any support. We may want to discard
this.
* pb/bisect (2016-08-23) 27 commits
. bisect--helper: remove the dequote in bisect_start()
. bisect--helper: retire `--bisect-auto-next` subcommand
. bisect--helper: retire `--bisect-autostart` subcommand
. bisect--helper: retire `--check-and-set-terms` subcommand
. bisect--helper: retire `--bisect-write` subcommand
. bisect--helper: `bisect_replay` shell function in C
. bisect--helper: `bisect_log` shell function in C
. bisect--helper: retire `--write-terms` subcommand
. bisect--helper: retire `--check-expected-revs` subcommand
. bisect--helper: `bisect_state` & `bisect_head` shell function in C
. bisect--helper: `bisect_autostart` shell function in C
. bisect--helper: retire `--next-all` subcommand
. bisect--helper: retire `--bisect-clean-state` subcommand
. bisect--helper: `bisect_next` and `bisect_auto_next` shell function in C
. bisect--helper: `bisect_start` shell function partially in C
. bisect--helper: `get_terms` & `bisect_terms` shell function in C
. bisect--helper: `bisect_next_check` & bisect_voc shell function in C
. bisect--helper: `check_and_set_terms` shell function in C
. bisect--helper: `bisect_write` shell function in C
. bisect--helper: `is_expected_rev` & `check_expected_revs` shell function in C
. bisect--helper: `bisect_reset` shell function in C
. wrapper: move is_empty_file() and rename it as is_empty_or_missing_file()
. t6030: explicitly test for bisection cleanup
. bisect--helper: `bisect_clean_state` shell function in C
. bisect--helper: `write_terms` shell function in C
. bisect: rewrite `check_term_format` shell function in C
. bisect--helper: use OPT_CMDMODE instead of OPT_BOOL
GSoC "bisect" topic.
I'd prefer to see early part solidified so that reviews can focus
on the later part that is still in flux. We are almost there but
not quite yet.
* kn/ref-filter-branch-list (2016-05-17) 17 commits
- branch: implement '--format' option
- branch: use ref-filter printing APIs
- branch, tag: use porcelain output
- ref-filter: allow porcelain to translate messages in the output
- ref-filter: add `:dir` and `:base` options for ref printing atoms
- ref-filter: make remote_ref_atom_parser() use refname_atom_parser_internal()
- ref-filter: introduce symref_atom_parser() and refname_atom_parser()
- ref-filter: introduce refname_atom_parser_internal()
- ref-filter: make "%(symref)" atom work with the ':short' modifier
- ref-filter: add support for %(upstream:track,nobracket)
- ref-filter: make %(upstream:track) prints "[gone]" for invalid upstreams
- ref-filter: introduce format_ref_array_item()
- ref-filter: move get_head_description() from branch.c
- ref-filter: modify "%(objectname:short)" to take length
- ref-filter: implement %(if:equals=<string>) and %(if:notequals=<string>)
- ref-filter: include reference to 'used_atom' within 'atom_value'
- ref-filter: implement %(if), %(then), and %(else) atoms
The code to list branches in "git branch" has been consolidated
with the more generic ref-filter API.
Rerolled.
Needs review.
* sb/bisect (2016-04-15) 22 commits
. SQUASH???
. bisect: get back halfway shortcut
. bisect: compute best bisection in compute_relevant_weights()
. bisect: use a bottom-up traversal to find relevant weights
. bisect: prepare for different algorithms based on find_all
. bisect: rename count_distance() to compute_weight()
. bisect: make total number of commits global
. bisect: introduce distance_direction()
. bisect: extract get_distance() function from code duplication
. bisect: use commit instead of commit list as arguments when appropriate
. bisect: replace clear_distance() by unique markers
. bisect: use struct node_data array instead of int array
. bisect: get rid of recursion in count_distance()
. bisect: make algorithm behavior independent of DEBUG_BISECT
. bisect: make bisect compile if DEBUG_BISECT is set
. bisect: plug the biggest memory leak
. bisect: add test for the bisect algorithm
. t6030: generalize test to not rely on current implementation
. t: use test_cmp_rev() where appropriate
. t/test-lib-functions.sh: generalize test_cmp_rev
. bisect: allow 'bisect run' if no good commit is known
. bisect: write about `bisect next` in documentation
The internal algorithm used in "git bisect" to find the next commit
to check has been optimized greatly.
Was expecting a reroll, but now pb/bisect topic starts removinging
more and more parts from git-bisect.sh, this needs to see a fresh
reroll.
Will discard.
cf. <1460294354-7031-1-git-send-email-s-beyer@gmx.net>
* sg/completion-updates (2016-02-28) 21 commits
. completion: cache the path to the repository
. completion: extract repository discovery from __gitdir()
. completion: don't guard git executions with __gitdir()
. completion: consolidate silencing errors from git commands
. completion: don't use __gitdir() for git commands
. completion: respect 'git -C <path>'
. completion: fix completion after 'git -C <path>'
. completion: don't offer commands when 'git --opt' needs an argument
. rev-parse: add '--absolute-git-dir' option
. completion: list short refs from a remote given as a URL
. completion: don't list 'HEAD' when trying refs completion outside of a repo
. completion: list refs from remote when remote's name matches a directory
. completion: respect 'git --git-dir=<path>' when listing remote refs
. completion: fix most spots not respecting 'git --git-dir=<path>'
. completion: ensure that the repository path given on the command line exists
. completion tests: add tests for the __git_refs() helper function
. completion tests: check __gitdir()'s output in the error cases
. completion tests: consolidate getting path of current working directory
. completion tests: make the $cur variable local to the test helper functions
. completion tests: don't add test cruft to the test repository
. completion: improve __git_refs()'s in-code documentation
Has been waiting for a reroll for too long.
cf. <1456754714-25237-1-git-send-email-szeder@ira.uka.de>
Will discard.
* ec/annotate-deleted (2015-11-20) 1 commit
- annotate: skip checking working tree if a revision is provided
Usability fix for annotate-specific "<file> <rev>" syntax with deleted
files.
Has been waiting for a review for too long without seeing anything.
Will discard.
* dk/gc-more-wo-pack (2016-01-13) 4 commits
- gc: clean garbage .bitmap files from pack dir
- t5304: ensure non-garbage files are not deleted
- t5304: test .bitmap garbage files
- prepare_packed_git(): find more garbage
Follow-on to dk/gc-idx-wo-pack topic, to clean up stale
.bitmap and .keep files.
Has been waiting for a reroll for too long.
cf. <xmqq60ypbeng.fsf@gitster.mtv.corp.google.com>
Will discard.
* jc/diff-b-m (2015-02-23) 5 commits
. WIPWIP
. WIP: diff-b-m
- diffcore-rename: allow easier debugging
- diffcore-rename.c: add locate_rename_src()
- diffcore-break: allow debugging
"git diff -B -M" produced incorrect patch when the postimage of a
completely rewritten file is similar to the preimage of a removed
file; such a resulting file must not be expressed as a rename from
other place.
The fix in this patch is broken, unfortunately.
Will discard.
--------------------------------------------------
[Cooking]
* jc/blame-reverse (2016-06-14) 2 commits
(merged to 'next' on 2016-09-22 at d1a8e9c)
+ blame: dwim "blame --reverse OLD" as "blame --reverse OLD.."
+ blame: improve diagnosis for "--reverse NEW"
It is a common mistake to say "git blame --reverse OLD path",
expecting that the command line is dwimmed as if asking how lines
in path in an old revision OLD have survived up to the current
commit.
Will hold to see if it is broken.
* ep/doc-check-ref-format-example (2016-09-21) 1 commit
(merged to 'next' on 2016-09-22 at 6d0d79e)
+ git-check-ref-format.txt: fixup documentation
A shell script example in check-ref-format documentation has been
fixed.
Will merge to 'master'.
* js/regexec-buf (2016-09-21) 3 commits
(merged to 'next' on 2016-09-22 at 2ee2477)
+ regex: use regexec_buf()
+ regex: add regexec_buf() that can work on a non NUL-terminated string
+ regex: -G<pattern> feeds a non NUL-terminated string to regexec() and fails
Some codepaths in "git diff" used regexec(3) on a buffer that was
mmap(2)ed, which may not have a terminating NUL, leading to a read
beyond the end of the mapped region. This was fixed by introducing
a regexec_buf() helper that takes a <ptr,len> pair with REG_STARTEND
extension.
Will merge to 'master'.
* jt/format-patch-rfc (2016-09-21) 1 commit
(merged to 'next' on 2016-09-22 at 3b39442)
+ format-patch: add "--rfc" for the common case of [RFC PATCH]
In some projects, it is common to use "[RFC PATCH]" as the subject
prefix for a patch meant for discussion rather than application. A
new option "--rfc" was a short-hand for "--subject-prefix=RFC PATCH"
to help the participants of such projects.
Will merge to 'master'.
* ls/travis-homebrew-path-fix (2016-09-22) 1 commit
(merged to 'next' on 2016-09-22 at 310e620)
+ travis-ci: ask homebrew for its path instead of hardcoding it
The procedure to build Git on Mac OS X for Travis CI hardcoded the
internal directory structure we assumed HomeBrew uses, which was a
no-no. The procedure has been updated to ask HomeBrew things we
need to know to fix this.
Will merge to 'master'.
* nd/init-core-worktree-in-multi-worktree-world (2016-09-23) 4 commits
- init: combine set_git_dir_init() and init_db() into one
- init: reuse original_git_dir in set_git_dir_init()
- init: do not set core.worktree more often than necessary
- init: correct re-initialization from a linked worktree
"git init" tried to record core.worktree in the repository's
'config' file when GIT_WORK_TREE environment variable was set and
it was different from where GIT_DIR appears as ".git" at its top,
but the logic was faulty when .git is a "gitdir:" file that points
at the real place, causing trouble in working trees that are
managed by "git worktree". This has been corrected.
The fourth one seems to need a bit more polishing.
cf. <xmqqshsqz0s1.fsf@gitster.mtv.corp.google.com>
* mm/config-color-ui-default-to-auto (2016-09-16) 1 commit
(merged to 'next' on 2016-09-22 at 4eac0cb)
+ Documentation/config: default for color.* is color.ui
Documentation for individual configuration variables to control use
of color (like `color.grep`) said that their default value was
'false', instead of saying their default is taken from `color.ui`.
When we updated the default value for color.ui from 'false' to
'auto' quite a while ago, all of them broke. This has been
corrected.
Will merge to 'master'.
* rs/c-auto-resets-attributes (2016-09-19) 1 commit
(merged to 'next' on 2016-09-22 at 68f2e4a)
+ pretty: let %C(auto) reset all attributes
The pretty-format specifier used by the "log" family of commands
have "%C(auto)" to enable coloring of the output is taught to also
issue a color-reset sequence to the output.
Will merge to 'master'.
* rs/cocci (2016-09-15) 3 commits
(merged to 'next' on 2016-09-22 at aa54fa4)
+ use strbuf_addstr() for adding constant strings to a strbuf, part 2
+ add coccicheck make target
+ contrib/coccinelle: fix semantic patch for oid_to_hex_r()
Code cleanup.
Will merge to 'master'.
* va/i18n-more (2016-09-21) 6 commits
(merged to 'next' on 2016-09-22 at bea26e8)
+ i18n: stash: mark messages for translation
+ i18n: notes-merge: mark die messages for translation
+ i18n: ident: mark hint for translation
+ i18n: i18n: diff: mark die messages for translation
+ i18n: connect: mark die messages for translation
+ i18n: commit: mark message for translation
Even more i18n.
Will merge to 'master'.
* jt/mailinfo-fold-in-body-headers (2016-09-21) 3 commits
- mailinfo: handle in-body header continuations
- mailinfo: make is_scissors_line take plain char *
- mailinfo: separate in-body header processing
When "git format-patch --stdout" output is placed as an in-body
header and it used the RFC2822 header folding, "git am" failed to
notice and put the header line back into a single logical line.
The underlying "git mailinfo" was taught to handle this properly.
Will merge to 'next'.
* kd/mailinfo-quoted-string (2016-09-19) 2 commits
- mailinfo: unescape quoted-pair in header fields
- t5100-mailinfo: replace common path prefix with variable
An e-mail author named that spelled a backslash-quoted double quote
in the human readable part "My \"double quoted\" name" was not
unquoted correctly.
Waiting for the discussion to conclude.
cf. <20160920035710.qw2byl3qeqwih7t5@sigill.intra.peff.net>
* js/libify-require-clean-work-tree (2016-09-12) 5 commits
- wt-status: teach has_{unstaged,uncommitted}_changes() about submodules
- Export also the has_un{staged,committed}_changed() functions
- Make the require_clean_work_tree() function truly reusable
- pull: make code more similar to the shell script again
- pull: drop confusing prefix parameter of die_on_unclean_work_tree()
The require_clean_work_tree() helper was recreated in C when "git
pull" was rewritten from shell; the helper is now made available to
other callers in preparation for upcoming "rebase -i" work.
Waiting for comments.
Modulo a few minor nits, this looked almost ready.
cf. <xmqqtwdl2bhm.fsf@gitster.mtv.corp.google.com>
cf. <xmqqpoo92bdr.fsf@gitster.mtv.corp.google.com>
* tg/add-chmod+x-fix (2016-09-21) 6 commits
(merged to 'next' on 2016-09-22 at 6afdd21)
+ t3700-add: do not check working tree file mode without POSIXPERM
+ t3700-add: create subdirectory gently
+ add: modify already added files when --chmod is given
+ read-cache: introduce chmod_index_entry
+ update-index: add test for chmod flags
+ Merge branch 'ib/t3700-add-chmod-x-updates' into tg/add-chmod+x-fix
"git add --chmod=+x <pathspec>" added recently only toggled the
executable bit for paths that are either new or modified. This has
been corrected to flip the executable bit for all paths that match
the given pathspec.
Will merge to 'master'.
* bw/ls-files-recurse-submodules (2016-09-21) 2 commits
- ls-files: add pathspec matching for submodules
- ls-files: optionally recurse into submodules
"git ls-files" learned "--recurse-submodules" option that can be
used to get a listing of tracked files across submodules (i.e. this
only works with "--cached" option, not for listing untracked or
ignored files). This would be a useful tool to sit on the upstream
side of a pipe that is read with xargs to work on all working tree
files from the top-level superproject.
Waiting for the discussion to conclude.
* ls/filter-process (2016-09-23) 11 commits
- convert: add filter.<driver>.process option
- convert: make apply_filter() adhere to standard Git error handling
- convert: modernize tests
- convert: quote filter names in error messages
- pkt-line: add functions to read/write flush terminated packet streams
- pkt-line: add packet_write_gently()
- pkt-line: add packet_flush_gently()
- pkt-line: add packet_write_fmt_gently()
- run-command: move check_pipe() from write_or_die to run_command
- pkt-line: extract set_packet_header()
- pkt-line: rename packet_write() to packet_write_fmt()
The smudge/clean filter API expect an external process is spawned
to filter the contents for each path that has a filter defined. A
new type of "process" filter API has been added to allow the first
request to run the filter for a path to spawn a single process, and
all filtering need is served by this single process for multiple
paths, reducing the process creation overhead.
Is this one ready to be merged?
* hv/submodule-not-yet-pushed-fix (2016-09-15) 5 commits
. SQUASH??? -Wdecl-after-stmt
. use actual start hashes for submodule push check instead of local refs
. batch check whether submodule needs pushing into one call
- serialize collection of refs that contain submodule changes
- serialize collection of changed submodules
The code in "git push" to compute if any commit being pushed in the
superproject binds a commit in a submodule that hasn't been pushed
out was overly inefficient, making it unusable even for a small
project that does not have any submodule but have a reasonable
number of refs. This has been optimized.
The last two in the original series seem to break a few tests when
queued to 'pu'.
* rt/rebase-i-broken-insn-advise (2016-09-07) 1 commit
(merged to 'next' on 2016-09-23 at 0d12484)
+ rebase -i: improve advice on bad instruction lines
When "git rebase -i" is given a broken instruction, it told the
user to fix it with "--edit-todo", but didn't say what the step
after that was (i.e. "--continue").
Will merge to 'master'.
* nd/checkout-disambiguation (2016-09-21) 3 commits
(merged to 'next' on 2016-09-22 at ebfa365)
+ checkout: fix ambiguity check in subdir
+ checkout.txt: document a common case that ignores ambiguation rules
+ checkout: add some spaces between code and comment
"git checkout <word>" does not follow the usual disambiguation
rules when the <word> can be both a rev and a path, to allow
checking out a branch 'foo' in a project that happens to have a
file 'foo' in the working tree without having to disambiguate.
This was poorly documented and the check was incorrect when the
command was run from a subdirectory.
Will merge to 'master'.
* sg/fix-versioncmp-with-common-suffix (2016-09-08) 5 commits
- versioncmp: cope with common leading parts in versionsort.prereleaseSuffix
- versioncmp: pass full tagnames to swap_prereleases()
- t7004-tag: add version sort tests to show prerelease reordering issues
- t7004-tag: use test_config helper
- t7004-tag: delete unnecessary tags with test_when_finished
The prereleaseSuffix feature of version comparison that is used in
"git tag -l" did not correctly when two or more prereleases for the
same release were present (e.g. when 2.0, 2.0-beta1, and 2.0-beta2
are there and the code needs to compare 2.0-beta1 and 2.0-beta2).
Waiting for a reroll.
cf. <20160908223727.Horde.jVOOJ278ssZ3qkyjkmyqZD-@webmail.informatik.kit.edu>
* cp/completion-negative-refs (2016-08-24) 1 commit
(merged to 'next' on 2016-09-22 at abd1585)
+ completion: support excluding refs
The command-line completion script (in contrib/) learned to
complete "git cmd ^mas<HT>" to complete the negative end of
reference to "git cmd ^master".
Will hold to see if it is broken.
* sb/push-make-submodule-check-the-default (2016-08-24) 1 commit
- push: change submodule default to check
Turn the default of "push.recurseSubmodules" to "check".
Alas, this reveals that the "check" mode is too inefficient to use
in real projects, even in ones as small as git itself.
cf. <xmqqh9aaot49.fsf@gitster.mtv.corp.google.com>
* ak/curl-imap-send-explicit-scheme (2016-08-17) 1 commit
(merged to 'next' on 2016-09-22 at 4449584)
+ imap-send: Tell cURL to use imap:// or imaps://
When we started cURL to talk to imap server when a new enough
version of cURL library is available, we forgot to explicitly add
imap(s):// before the destination. To some folks, that didn't work
and the library tried to make HTTP(s) requests instead.
Will hold to see if it is broken.
* mh/diff-indent-heuristic (2016-09-19) 8 commits
(merged to 'next' on 2016-09-22 at e71d742)
+ blame: honor the diff heuristic options and config
+ parse-options: add parse_opt_unknown_cb()
+ diff: improve positioning of add/delete blocks in diffs
+ xdl_change_compact(): introduce the concept of a change group
+ recs_match(): take two xrecord_t pointers as arguments
+ is_blank_line(): take a single xrecord_t as argument
+ xdl_change_compact(): only use heuristic if group can't be matched
+ xdl_change_compact(): fix compaction heuristic to adjust ixo
Output from "git diff" can be made easier to read by selecting
which lines are common and which lines are added/deleted
intelligently when the lines before and after the changed section
are the same. A command line option is added to help with the
experiment to find a good heuristics.
Will merge to 'master'.
* jk/pack-objects-optim-mru (2016-08-11) 4 commits
(merged to 'next' on 2016-09-21 at 97b919b)
+ pack-objects: use mru list when iterating over packs
+ pack-objects: break delta cycles before delta-search phase
+ sha1_file: make packed_object_info public
+ provide an initializer for "struct object_info"
Originally merged to 'next' on 2016-08-11
"git pack-objects" in a repository with many packfiles used to
spend a lot of time looking for/at objects in them; the accesses to
the packfiles are now optimized by checking the most-recently-used
packfile first.
Will hold to see if people scream.
* dp/autoconf-curl-ssl (2016-06-28) 1 commit
(merged to 'next' on 2016-09-22 at 9c5aeec)
+ ./configure.ac: detect SSL in libcurl using curl-config
The ./configure script generated from configure.ac was taught how
to detect support of SSL by libcurl better.
Will hold to see if it is broken.
* jc/pull-rebase-ff (2016-07-28) 1 commit
- pull: fast-forward "pull --rebase=true"
"git pull --rebase", when there is no new commits on our side since
we forked from the upstream, should be able to fast-forward without
invoking "git rebase", but it didn't.
Needs a real log message and a few tests.
* ex/deprecate-empty-pathspec-as-match-all (2016-06-22) 1 commit
(merged to 'next' on 2016-09-21 at e19148e)
+ pathspec: warn on empty strings as pathspec
Originally merged to 'next' on 2016-07-13
An empty string used as a pathspec element has always meant
'everything matches', but it is too easy to write a script that
finds a path to remove in $path and run 'git rm "$paht"', which
ends up removing everything. Start warning about this use of an
empty string used for 'everything matches' and ask users to use a
more explicit '.' for that instead.
The hope is that existing users will not mind this change, and
eventually the warning can be turned into a hard error, upgrading
the deprecation into removal of this (mis)feature.
Will hold to see if people scream.
* nd/shallow-deepen (2016-06-13) 27 commits
(merged to 'next' on 2016-09-22 at f0cf3e3)
+ fetch, upload-pack: --deepen=N extends shallow boundary by N commits
+ upload-pack: add get_reachable_list()
+ upload-pack: split check_unreachable() in two, prep for get_reachable_list()
+ t5500, t5539: tests for shallow depth excluding a ref
+ clone: define shallow clone boundary with --shallow-exclude
+ fetch: define shallow boundary with --shallow-exclude
+ upload-pack: support define shallow boundary by excluding revisions
+ refs: add expand_ref()
+ t5500, t5539: tests for shallow depth since a specific date
+ clone: define shallow clone boundary based on time with --shallow-since
+ fetch: define shallow boundary with --shallow-since
+ upload-pack: add deepen-since to cut shallow repos based on time
+ shallow.c: implement a generic shallow boundary finder based on rev-list
+ fetch-pack: use a separate flag for fetch in deepening mode
+ fetch-pack.c: mark strings for translating
+ fetch-pack: use a common function for verbose printing
+ fetch-pack: use skip_prefix() instead of starts_with()
+ upload-pack: move rev-list code out of check_non_tip()
+ upload-pack: make check_non_tip() clean things up on error
+ upload-pack: tighten number parsing at "deepen" lines
+ upload-pack: use skip_prefix() instead of starts_with()
+ upload-pack: move "unshallow" sending code out of deepen()
+ upload-pack: remove unused variable "backup"
+ upload-pack: move "shallow" sending code out of deepen()
+ upload-pack: move shallow deepen code out of receive_needs()
+ transport-helper.c: refactor set_helper_option()
+ remote-curl.c: convert fetch_git() to use argv_array
The existing "git fetch --depth=<n>" option was hard to use
correctly when making the history of an existing shallow clone
deeper. A new option, "--deepen=<n>", has been added to make this
easier to use. "git clone" also learned "--shallow-since=<date>"
and "--shallow-exclude=<tag>" options to make it easier to specify
"I am interested only in the recent N months worth of history" and
"Give me only the history since that version".
Will hold to see if it is broken.
* jc/merge-drop-old-syntax (2015-04-29) 1 commit
- merge: drop 'git merge <message> HEAD <commit>' syntax
Stop supporting "git merge <message> HEAD <commit>" syntax that has
been deprecated since October 2007, and issues a deprecation
warning message since v2.5.0.
It has been reported that git-gui still uses the deprecated syntax,
which needs to be fixed before this final step can proceed.
cf. <5671DB28.8020901@kdbg.org>
--------------------------------------------------
[Discarded]
* jn/fix-connect-unexpected-hangup-diag (2016-09-08) 1 commit
. connect: tighten check for unexpected early hang up
Now part of jt/accept-capability-advertisement-when-fetching-from-void
topic.
^ permalink raw reply
* Re: [PATCH v2 4/3] init: combine set_git_dir_init() and init_db() into one
From: Junio C Hamano @ 2016-09-23 22:53 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, git, max.nordlund
In-Reply-To: <20160923111206.8596-1-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> I think a separate commit for this is better than combining back to
> 2/3 so we can explain the problem properly (without making 2/3 commit
> message even longer)
>
> Not sure if you want to s/contains/contain/ in 2/3 by yourself or I
> should resend the whole series. Let me know.
I think this 4/3 is not quite enough to fix the damage to the code
caused by 2/3.
Given that
- set_git_dir_init() is is the only one that sets original_git_dir,
- create_default_files() is the only one that uses
original_git_dir, and
- init_db() is the only one that calls set_git_dir_init() and
create_default_files()
after 4/3 is applied, we should be able to remove the global
variable 2/3 introduced, make init_db() receive that information as
the return value of set_git_dir_init(), and pass that as a parameter
to create_default_files().
^ permalink raw reply
* Re: .gitignore does not ignore Makefile
From: Jakub Narębski @ 2016-09-23 22:29 UTC (permalink / raw)
To: Junio C Hamano, Kevin Daudt; +Cc: Timur Tabi, git
In-Reply-To: <xmqqy42j4wp9.fsf@gitster.mtv.corp.google.com>
W dniu 22.09.2016 o 20:26, Junio C Hamano napisał:
> Kevin Daudt <me@ikke.info> writes:
>
>> Often people advise tricks like `git update-index --assume-unchanges
>> <file>`, but this does not work as expected. It's merely a promise to
>> git that this file does not change (and hence, git will not check if
>> this file has changed when doing git status), but command that try to
>> change this file will abort saying that the file has changed.
>
> It actually is even worse. As the user promised Git that the <file>
> will not be modified and will be kept the same as the version in the
> index, Git reserves the right to _overwrite_ it with the version in
> the index anytime when it is convenient to do so, removing whatever
> local change the user had despite the promise to Git. The "abort
> saying that the file has changed" is merely various codepaths in the
> current implementation trying to be extra nice.
There is a trick that works almost as 'ignore changes' for tracked
files, namely `git update-index --skip-worktree <file>`. From the
documentation:
Skip-worktree bit
~~~~~~~~~~~~~~~~~
Skip-worktree bit can be defined in one (long) sentence: When
reading an entry, if it is marked as skip-worktree, then Git
pretends its working directory version is up to date and read
the index version instead.
[...] Writing is not affected by this bit, content safety is still
first priority. [...]
It works quite well; the only problem is that `git stash` would
not stash away your changes, and you would need to unmark such
file before saving a stash.
With --assume-unchanged used for ignoring changes to tracked files,
you can quite easily lose your work because you are lying to Git.
Note also that in Git classic "ignored" implies unimportant.
--
Jakub Narębski
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox