* [PATCH 0/2] submodule config test cleanup
From: Stefan Beller @ 2016-12-27 19:36 UTC (permalink / raw)
To: gitster; +Cc: git, Stefan Beller
A test cleanup and an additional test for the submodule configuration.
Stefan Beller (2):
t7411: quote URLs
t7411: test lookup of uninitialized submodules
t/t7411-submodule-config.sh | 25 +++++++++++++++++++++++--
1 file changed, 23 insertions(+), 2 deletions(-)
--
2.11.0.rc2.50.g8bda6b2.dirty
^ permalink raw reply
* [PATCH 1/2] t7411: quote URLs
From: Stefan Beller @ 2016-12-27 19:36 UTC (permalink / raw)
To: gitster; +Cc: git, Stefan Beller
In-Reply-To: <20161227193605.12413-1-sbeller@google.com>
The variables may contain white spaces, so we need to quote them.
By not quoting the variables we'd end up passing multiple arguments to
git config, which doesn't fail for two arguments as value.
Signed-off-by: Stefan Beller <sbeller@google.com>
---
t/t7411-submodule-config.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t7411-submodule-config.sh b/t/t7411-submodule-config.sh
index 47562ce465..3646f28b40 100755
--- a/t/t7411-submodule-config.sh
+++ b/t/t7411-submodule-config.sh
@@ -120,8 +120,8 @@ test_expect_success 'reading of local configuration' '
"" submodule \
>actual &&
test_cmp expect_local_path actual &&
- git config submodule.a.url $old_a &&
- git config submodule.submodule.url $old_submodule &&
+ git config submodule.a.url "$old_a" &&
+ git config submodule.submodule.url "$old_submodule" &&
git config --unset submodule.a.path c
)
'
--
2.11.0.rc2.50.g8bda6b2.dirty
^ permalink raw reply related
* [PATCH 2/2] t7411: test lookup of uninitialized submodules
From: Stefan Beller @ 2016-12-27 19:36 UTC (permalink / raw)
To: gitster; +Cc: git, Stefan Beller
In-Reply-To: <20161227193605.12413-1-sbeller@google.com>
Sometimes we need to lookup information of uninitialized submodules. Make
sure that works.
Signed-off-by: Stefan Beller <sbeller@google.com>
---
t/t7411-submodule-config.sh | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/t/t7411-submodule-config.sh b/t/t7411-submodule-config.sh
index 3646f28b40..b40df6a4c1 100755
--- a/t/t7411-submodule-config.sh
+++ b/t/t7411-submodule-config.sh
@@ -126,6 +126,27 @@ test_expect_success 'reading of local configuration' '
)
'
+cat >super/expect_url <<EOF
+Submodule url: '../submodule' for path 'b'
+Submodule url: 'git@somewhere.else.net:submodule.git' for path 'submodule'
+EOF
+
+test_expect_success 'reading of local configuration for uninitialized submodules' '
+ (
+ cd super &&
+ git submodule deinit -f b &&
+ old_submodule=$(git config submodule.submodule.url) &&
+ git config submodule.submodule.url git@somewhere.else.net:submodule.git &&
+ test-submodule-config --url \
+ "" b \
+ "" submodule \
+ >actual &&
+ test_cmp expect_url actual &&
+ git config submodule.submodule.url "$old_submodule" &&
+ git submodule init b
+ )
+'
+
cat >super/expect_fetchrecurse_die.err <<EOF
fatal: bad submodule.submodule.fetchrecursesubmodules argument: blabla
EOF
--
2.11.0.rc2.50.g8bda6b2.dirty
^ permalink raw reply related
* Re: [PATCH v9 01/20] ref-filter: implement %(if), %(then), and %(else) atoms
From: Junio C Hamano @ 2016-12-27 20:58 UTC (permalink / raw)
To: Karthik Nayak; +Cc: git, jacob.keller, ramsay
In-Reply-To: <20161227162357.28212-2-Karthik.188@gmail.com>
Karthik Nayak <karthik.188@gmail.com> writes:
>
> +Some atoms like %(align) and %(if) always require a matching %(end).
> +We call them "opening atoms" and sometimes denote them as %($open).
> +
> +When a scripting language specific quoting is in effect, everything
> +between a top-level opening atom and its matching %(end) is evaluated
> +according to the semantics of the opening atom and its result is
> +quoted.
What is unsaid in the last paragraph is that you assume "is
evaluated according to the semantics of the opening atom" does not
involve quoting and only the result from the top-level is quoted. I
am not sure if that is clear to the first-time readers.
>
> EXAMPLES
> --------
> @@ -273,6 +291,22 @@ eval=`git for-each-ref --shell --format="$fmt" \
> eval "$eval"
> ------------
> ...
> +------------
> +git for-each-ref --format="%(refname)%(if)%(authorname)%(then) %(color:red)Authored by: %(authorname)%(end)"
> +------------
This makes readers wonder how "red"ness is reset, but that is not
something this example is interested in demonstrating. Let's drop
the %(color:red) bit to avoid distracting readers.
^ permalink raw reply
* Re: [PATCH v9 02/20] ref-filter: include reference to 'used_atom' within 'atom_value'
From: Junio C Hamano @ 2016-12-27 20:59 UTC (permalink / raw)
To: Karthik Nayak; +Cc: git, jacob.keller, ramsay
In-Reply-To: <20161227162357.28212-3-Karthik.188@gmail.com>
Karthik Nayak <karthik.188@gmail.com> writes:
> From: Karthik Nayak <karthik.188@gmail.com>
>
> Ensure that each 'atom_value' has a reference to its corresponding
> 'used_atom'. This let's us use values within 'used_atom' in the
s/let's us use/lets us use/;
> 'handler' function.
^ permalink raw reply
* Re: [PATCH v9 03/20] ref-filter: implement %(if:equals=<string>) and %(if:notequals=<string>)
From: Junio C Hamano @ 2016-12-27 21:00 UTC (permalink / raw)
To: Karthik Nayak; +Cc: git, jacob.keller, ramsay
In-Reply-To: <20161227162357.28212-4-Karthik.188@gmail.com>
Karthik Nayak <karthik.188@gmail.com> writes:
> This is done by introducing 'if_atom_parser()' which parses the given
> %(if) atom and then stores the data in used_atom which is later passed
> on to the used_atom of the %(then) atom, so that it can do the required
> comparisons.
>
> Add tests and Documentation for the same.
s/Documentation/documentation/
^ permalink raw reply
* Re: [PATCH v9 19/20] branch: use ref-filter printing APIs
From: Junio C Hamano @ 2016-12-27 21:17 UTC (permalink / raw)
To: Karthik Nayak; +Cc: git, jacob.keller, ramsay
In-Reply-To: <20161227162357.28212-20-Karthik.188@gmail.com>
Karthik Nayak <karthik.188@gmail.com> writes:
> static char branch_colors[][COLOR_MAXLEN] = {
> - GIT_COLOR_RESET,
> - GIT_COLOR_NORMAL, /* PLAIN */
> - GIT_COLOR_RED, /* REMOTE */
> - GIT_COLOR_NORMAL, /* LOCAL */
> - GIT_COLOR_GREEN, /* CURRENT */
> - GIT_COLOR_BLUE, /* UPSTREAM */
> + "%(color:reset)",
> + "%(color:reset)", /* PLAIN */
> + "%(color:red)", /* REMOTE */
> + "%(color:reset)", /* LOCAL */
> + "%(color:green)", /* CURRENT */
> + "%(color:blue)", /* UPSTREAM */
> };
The contents of this table is no longer tied to COLOR_MAXLEN. The
above entries used by default happen to be shorter, but it is
misleading.
static const char *branch_colors[] = {
"%(color:reset)",
...
};
perhaps?
More importantly, does this re-definition of the branch_colors[]
work with custom colors filled in git_branch_config() by calling
e.g. color_parse("red", branch_colors[BRANCH_COLOR_REMOTE]), where
"red" and "remote" come from an existing configuration file?
[color "branch"]
remote = red
It obviously would not work if you changed the type of branch_colors[]
because the color_parse() wants the caller to have allocated space
of COLOR_MAXLEN.
But if filling these ANSI escape sequence into the format works OK,
then doesn't it tell us that we do not need to have this change to
use "%(color:reset)" etc. as the new default values?
^ permalink raw reply
* Re: [PATCH v9 11/20] ref-filter: introduce refname_atom_parser()
From: Junio C Hamano @ 2016-12-27 21:04 UTC (permalink / raw)
To: Karthik Nayak; +Cc: git, jacob.keller, ramsay
In-Reply-To: <20161227162357.28212-12-Karthik.188@gmail.com>
Karthik Nayak <karthik.188@gmail.com> writes:
> +symref::
> + The ref which the given symbolic ref refers to. If not a
> + symbolic ref, nothing is printed. Respects the `:short` and
> + `:strip` options in the same way as `refname` above.
> +
I am slightly unhappy with this name. If we had an atom that lets
you ask "Is this a symref?" and yields "" or "->", it could also be
called symref, and we would name it "is_symref" or something to
disambiguate it. Then it is only fair to give this one that lets
you ask "What does this symref point at?" a bit more specific name,
like "symref_target" or something.
But probably I am worried too much. "is_symref", if necessary, can
be written as "%(if:notequals=)%(symref)%(then)...%(else)...%(end)"
and it is not likely that it would be used often, so let's keep it
as-is.
^ permalink raw reply
* Re: [PATCH v9 15/20] ref-filter: modify the 'lstrip=<N>' option to work with negative '<N>'
From: Junio C Hamano @ 2016-12-27 21:11 UTC (permalink / raw)
To: Karthik Nayak; +Cc: git, jacob.keller, ramsay
In-Reply-To: <20161227162357.28212-16-Karthik.188@gmail.com>
Karthik Nayak <karthik.188@gmail.com> writes:
> Currently the 'lstrip=<N>' option only takes a positive value '<N>'
> and strips '<N>' slash-separated path components from the left. Modify
> the 'lstrip' option to also take a negative number '<N>' which would
> only _leave_ behind 'N' slash-separated path components from the left.
"would only leave behind N components from the left" sounds as if
the result is A/B, when you are given A/B/C/D/E and asked to
lstrip:-2. Given these two tests added by the patch ...
> +test_atom head refname:lstrip=-1 master
> +test_atom head refname:lstrip=-2 heads/master
... I somehow think that is not what you wanted to say. Instead,
you strip from the left as many as necessary and leave -N
components that appear at the right-most end, no?
> --- a/Documentation/git-for-each-ref.txt
> +++ b/Documentation/git-for-each-ref.txt
> @@ -98,7 +98,8 @@ refname::
> abbreviation mode. If `lstrip=<N>` is appended, strips `<N>`
> slash-separated path components from the front of the refname
> (e.g., `%(refname:lstrip=2)` turns `refs/tags/foo` into `foo`.
> - `<N>` must be a positive integer.
> + if `<N>` is a negative number, then only `<N>` path components
> + are left behind.
I think positive <N> is so obvious not to require an example but it
is good that you have one. The negative <N> case needs illustration
more than the positive case. Perhaps something like:
(e.g. %(refname:lstrip=-1) strips components of refs/tags/frotz
from the left to leave only one component, i.e. 'frotz').
Would %(refname:lstrip=-4) attempt to strip components of
refs/tags/frotz from the left to leave only four components, and
because the original does not have that many components, it ends
with refs/tags/frotz?
I am debating myself if we need something like "When the ref does
not have enough components, the result becomes an empty string if
stripping with positive <N>, or it becomes the full refname if
stripping with negative <N>. Neither is an error." is necessary
here. Or is it too obvious?
^ permalink raw reply
* Re: [PATCHv5 4/4] rm: absorb a submodules git dir before deletion
From: Junio C Hamano @ 2016-12-27 21:55 UTC (permalink / raw)
To: Stefan Beller
Cc: git@vger.kernel.org, Brandon Williams, David Turner,
brian m. carlson, Johannes Sixt
In-Reply-To: <CAGZ79kZLk2bNj2Z_PFfo9KzODn8nSihDLdLuKvpSPodR9Eg-4w@mail.gmail.com>
Stefan Beller <sbeller@google.com> writes:
>>>> @@ -358,9 +331,6 @@ int cmd_rm(int argc, const char **argv, const char *prefix)
>>>> oidclr(&oid);
>>>> if (check_local_mod(&oid, index_only))
>>>> exit(1);
>>>> - } else if (!index_only) {
>>>> - if (check_submodules_use_gitfiles())
>>>> - exit(1);
>>>> }
>>>>
>>>
>>> Hmph. It may be a bit strange to see an "index-only" remove to
>>> touch working tree, no? Yet submodules_absorb_gitdir_if_needed() is
>>> unconditionally called above, which feels somewhat unexpected.
>> ...
> Well scratch that.
> is_staging_gitmodules_ok only checks for the .gitmodules file and not
> for the submodule itself (the submodule is not an argument to that function)
>
> The actual answer is found in check_local_mod called via
>
> if (!force) {
> struct object_id oid;
> if (get_oid("HEAD", &oid))
> oidclr(&oid);
> if (check_local_mod(&oid, index_only))
> exit(1);
> }
OK, that happens way before this loop starts finding submodules and
removing them, so we can say that the latter is well protected.
Thanks.
^ permalink raw reply
* Re: [PATCH] worktree: initialize return value for submodule_uses_worktrees
From: Junio C Hamano @ 2016-12-27 22:12 UTC (permalink / raw)
To: Stefan Beller; +Cc: larsxschneider, git
In-Reply-To: <20161227175013.12747-1-sbeller@google.com>
Stefan Beller <sbeller@google.com> writes:
> When the worktrees directory is empty, the `ret` will be returned
> uninitialized. Fix it by initializing the value.
>
> Signed-off-by: Stefan Beller <sbeller@google.com>
> ---
>
> This goes on top of 1a248cf (origin/sb/submodule-embed-gitdir);
> ideally to be squashed, but as it is in next already, as a separate
> patch.
>
> Thanks,
> Stefan
If you initialize it at the definition site, it would be more
consistent if these "return 0" we see earlier parts of the function
also returned "ret" instead of "0". A better alternative would be
to initialize it to 0 before it starts to matter, i.e. immediately
before the
while (readdir()) {
if (is_dot_or_dotdot())
continue;
ret = 1;
break;
}
loop. I also wonder if that loop is easier to read
for (has_paths = 0; !has_paths && (d = readdir(dir)) != NULL; ) {
if (is_dot_or_dotdot())
continue;
has_paths = 1;
}
or even make it a helper function "is_empty_directory(const char *)".
Having said that, I'll queue this as-is and will merge to 'master'
by the end of the day, as I'm planning to disappear until early next
year, so please do not "reroll" this to add yet another integration
cycle to my day.
Thanks.
> worktree.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/worktree.c b/worktree.c
> index d4606aa8cd..828fd7a0ad 100644
> --- a/worktree.c
> +++ b/worktree.c
> @@ -387,7 +387,7 @@ int submodule_uses_worktrees(const char *path)
> struct strbuf sb = STRBUF_INIT;
> DIR *dir;
> struct dirent *d;
> - int ret;
> + int ret = 0;
> struct repository_format format;
>
> submodule_gitdir = git_pathdup_submodule(path, "%s", "");
^ permalink raw reply
* Re: git-apply: warn/fail on *changed* end of line (eol) *only*?
From: Igor Djordjevic BugA @ 2016-12-27 22:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqq8tr1cmf9.fsf@gitster.mtv.corp.google.com>
On 27/12/2016 18:27, Junio C Hamano wrote:
> To see the problem with "check existing lines", it probably is
> easier to extend the above example to start from a file with one
> more line, like this:
>
> 1 <CRLF>
> 3 <CRLF>
> 4 <LF>
> 5 <CRLF>
>
> and extend all the example patches to remove "4 <LF>" line as well,
> where they remove "3 <CRLF>", making the first example patch like
> so:
>
> 1 <CRLF>
> -3 <CRLF>
> -4 <LF>
> +three <CRLF>
> 5 <CRLF>
>
> Now, if you take "three <CRLF>" to be replacing "3 <CRLF>", then you
> may feel that not warning on the CRLF would be the right thing, but
> there is no reason (other than the fact you, a human, understand
> what 'three' means) to choose "3 <CRLF>" over "4 <LF>" as the
> original. If you take "three <CRLF>" to be replacing "4 <LF>", you
> would need to warn.
Hmm, but why do you keep insisting on knowing what the lines are about,
and still making a 'per line' end of line comparison? Besides, your
example falls within the (only?) special case I mentioned as the one Git
probably shouldn`t be acting upon, as both <LF> and <CRLF> are present
among the the old hunk lines already (lines starting with '-').
The logic should be simple, what I tried to describe in the previous
message:
1. Examine all '-' lines line endings.
1.1. If not all line endings are the same (like in your example, no
matter the line content), do nothing.
1.2. If all line endings _are_ the same within the old hunk ('-'
lines), check if any of the '+' lines (new hunk) has a different
line ending (still no matter the line content).
1.2.1. If no different line endings among '+' lines in comparison to
unique line ending found in '-' lines, do nothing.
1.2.2. If _any_ of the '+' lines _has_ a different line ending in
comparison to unique line ending found in '-' lines, then do
warn/fail.
This even might seem as the most sensible approach, no matter the
overall project end of line setting, which is exactly why I find it
interesting - it seems to 'just work', being beginner friendly _and_
also watching your back on unexpected end of line changes.
> A totally uninteresting special case is when the original is all
> <CRLF>, but in that case, as you already said in the original
> message, the project wants <CRLF> and you can configure it as such.
> Then <CR> in the line-end <CRLF> won't be mistaken as if it is a
> whitespace character <CR> at the end of a line terminated with <LF>.
But this is exactly the most confusing case, especially for beginners,
where project configuration is incorrect, and you get warned about
'whitespace errors' where all line endings (old/new) are in fact still
the same (confusing).
Yet worse, you don`t get warned of different line endings being applied,
as these are considered 'correct' due to current (incorrect) setting, no
matter the whole file is actually different, which you don`t get warned
about in the first place, and you may discover the file line ending
breakage only when other contributors start complaining.
Also, would it be sensible to account for a possible file inside the
project having different line endings than project in general...? This
would help there as well, without unintentionally breaking the file.
Regards, BugA
P.S. I guess you don`t need me to tell you that, but please feel free
to drop out of this discussion at your own discretion, even though I
enjoy sharing thoughts (and learning new stuff!), I do kind of feel I`m
wasting your time for something that might not be that important, if at
all, otherwise someone would have probably addressed it so far :/
^ permalink raw reply
* Re: [PATCH] worktree: initialize return value for submodule_uses_worktrees
From: Stefan Beller @ 2016-12-27 22:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Lars Schneider, git@vger.kernel.org
In-Reply-To: <xmqqa8bh6myb.fsf@gitster.mtv.corp.google.com>
On Tue, Dec 27, 2016 at 2:12 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> or even make it a helper function "is_empty_directory(const char *)".
This sounds like the way to go IMHO.
> I'm planning to disappear until early next
> year
Safe travels!
I assume there is no interim maintainer for such a short
period of time (which also is not as busy).
Thanks,
Stefan
^ permalink raw reply
* Re: [PATCH] worktree: initialize return value for submodule_uses_worktrees
From: Junio C Hamano @ 2016-12-27 22:47 UTC (permalink / raw)
To: Stefan Beller; +Cc: Lars Schneider, git@vger.kernel.org
In-Reply-To: <CAGZ79kbbm=g9DTUWY=xVZPUi4ajCMgKT63bGXJSpP2t0RDH0Ew@mail.gmail.com>
Stefan Beller <sbeller@google.com> writes:
> On Tue, Dec 27, 2016 at 2:12 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
>> I'm planning to disappear until early next
>> year
>
> Safe travels!
Thanks.
> I assume there is no interim maintainer for such a short
> period of time (which also is not as busy).
I plan to take my Flip with me (the primary development box for me
these days is Google's datacentre, and I only need a chromebook to
use as a SSH terminal or two) and expect to have a usable network
connection, but given the number of topics labelled as "Waiting for
review to conclude", I expect that people have plenty to chew while
I am away and the public git.git tree does not replace the in-flight
topics for a week or so ;-)
^ permalink raw reply
* What's cooking in git.git (Dec 2016, #08; Tue, 27)
From: Junio C Hamano @ 2016-12-27 23:11 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.
This will be the last issue of the "What's cooking" report for the
year. I will be travelling and expect to be slow to respond for a
week or so. Hence there is no "short-term" summary; the topics
marked as "Will merge to 'master'" may stay in 'next' until the
second week of next month.
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
--------------------------------------------------
[Graduated to "master"]
* bw/transport-protocol-policy (2016-12-15) 6 commits
(merged to 'next' on 2016-12-19 at 166168205c)
+ http: respect protocol.*.allow=user for http-alternates
+ transport: add from_user parameter to is_transport_allowed
+ http: create function to get curl allowed protocols
+ transport: add protocol policy config option
+ http: always warn if libcurl version is too old
+ lib-proto-disable: variable name fix
Finer-grained control of what protocols are allowed for transports
during clone/fetch/push have been enabled via a new configuration
mechanism.
* cp/merge-continue (2016-12-15) 4 commits
(merged to 'next' on 2016-12-19 at 8ba0094f45)
+ merge: mark usage error strings for translation
+ merge: ensure '--abort' option takes no arguments
+ completion: add --continue option for merge
+ merge: add '--continue' option as a synonym for 'git commit'
"git merge --continue" has been added as a synonym to "git commit"
to conclude a merge that has stopped due to conflicts.
* gv/p4-multi-path-commit-fix (2016-12-19) 1 commit
(merged to 'next' on 2016-12-21 at f7ba714387)
+ git-p4: fix multi-path changelist empty commits
"git p4" that tracks multile p4 paths imported a single changelist
that touches files in these multiple paths as one commit, followed
by many empty commits. This has been fixed.
* jc/lock-report-on-error (2016-12-27) 1 commit
(merged to 'next' on 2016-12-27 at ab2ae230f4)
+ lockfile: move REPORT_ON_ERROR bit elsewhere
Hotfix for a topic already merged to 'master'.
* jc/push-default-explicit (2016-10-31) 2 commits
(merged to 'next' on 2016-12-05 at d63f3777af)
+ push: test pushing ambiguously named branches
+ push: do not use potentially ambiguous default refspec
Originally merged to 'next' on 2016-11-01
A lazy "git push" without refspec did not internally use a fully
specified refspec to perform 'current', 'simple', or 'upstream'
push, causing unnecessary "ambiguous ref" errors.
* jk/difftool-in-subdir (2016-12-11) 4 commits
(merged to 'next' on 2016-12-21 at c1056e014b)
+ difftool: rename variables for consistency
+ difftool: chdir as early as possible
+ difftool: sanitize $workdir as early as possible
+ difftool: fix dir-diff index creation when in a subdirectory
Even though an fix was attempted in Git 2.9.3 days, but running
"git difftool --dir-diff" from a subdirectory never worked. This
has been fixed.
* js/mingw-isatty (2016-12-22) 3 commits
(merged to 'next' on 2016-12-22 at 5be6c1a083)
+ mingw: replace isatty() hack
+ mingw: fix colourization on Cygwin pseudo terminals
+ mingw: adjust is_console() to work with stdin
Update the isatty() emulation for Windows by updating the previous
hack that depended on internals of (older) MSVC runtime.
* ld/p4-compare-dir-vs-symlink (2016-12-18) 1 commit
(merged to 'next' on 2016-12-20 at f58fed9ef8)
+ git-p4: avoid crash adding symlinked directory
"git p4" misbehaved when swapping a directory and a symbolic link.
* ls/filter-process (2016-12-18) 2 commits
(merged to 'next' on 2016-12-19 at 5ed29656db)
+ t0021: fix flaky test
(merged to 'next' on 2016-12-12 at 8ed1f9eb02)
+ docs: warn about possible '=' in clean/smudge filter process values
Doc update.
* ls/p4-lfs (2016-12-20) 1 commit
(merged to 'next' on 2016-12-22 at 0759f94c65)
+ git-p4: add diff/merge properties to .gitattributes for GitLFS files
Update GitLFS integration with "git p4".
* lt/shortlog-by-committer (2016-12-20) 3 commits
(merged to 'next' on 2016-12-21 at c72e6e7f76)
+ t4201: make tests work with and without the MINGW prerequiste
(merged to 'next' on 2016-12-19 at 555976fc0a)
+ shortlog: test and document --committer option
+ shortlog: group by committer information
"git shortlog" learned "--committer" option to group commits by
committer, instead of author.
* mk/mingw-winansi-ttyname-termination-fix (2016-12-20) 1 commit
(merged to 'next' on 2016-12-21 at 1e8e994605)
+ mingw: consider that UNICODE_STRING::Length counts bytes
A potential but unlikely buffer overflow in Windows port has been
fixed.
* sb/submodule-config-cleanup (2016-11-22) 3 commits
(merged to 'next' on 2016-12-05 at 658b8764bf)
+ submodule-config: clarify parsing of null_sha1 element
+ submodule-config: rename commit_sha1 to treeish_name
+ submodule config: inline config_from_{name, path}
Originally merged to 'next' on 2016-11-23
Minor code clean-up.
* va/i18n-even-more (2016-12-20) 1 commit
(merged to 'next' on 2016-12-22 at 209eee0530)
+ i18n: fix misconversion in shell scripts
Hotfix for a topic already merged to 'master'.
* va/i18n-perl-scripts (2016-12-14) 16 commits
(merged to 'next' on 2016-12-19 at ec800aba9f)
+ i18n: difftool: mark warnings for translation
+ i18n: send-email: mark composing message for translation
+ i18n: send-email: mark string with interpolation for translation
+ i18n: send-email: mark warnings and errors for translation
+ i18n: send-email: mark strings for translation
+ i18n: add--interactive: mark status words for translation
+ i18n: add--interactive: remove %patch_modes entries
+ i18n: add--interactive: mark edit_hunk_manually message for translation
+ i18n: add--interactive: i18n of help_patch_cmd
+ i18n: add--interactive: mark patch prompt for translation
+ i18n: add--interactive: mark plural strings
+ i18n: clean.c: match string with git-add--interactive.perl
+ i18n: add--interactive: mark strings with interpolation for translation
+ i18n: add--interactive: mark simple here-documents for translation
+ i18n: add--interactive: mark strings for translation
+ Git.pm: add subroutines for commenting lines
Porcelain scripts written in Perl are getting internationalized.
--------------------------------------------------
[New Topics]
* dt/disable-bitmap-in-auto-gc (2016-12-23) 2 commits
- repack: die on incremental + write-bitmap-index
- auto gc: don't write bitmaps for incremental repacks
It is natural that "git gc --auto" may not attempt to pack
everything into a single pack, and there is no point in warning
when the user has configured the system to use the pack bitmap,
leading to disabling further "gc".
Waiting for review to conclude.
cf. <20161224025730.vwz2k4af6z6piinl@sigill.intra.peff.net>
(GNUism must go.)
* js/mingw-test-push-unc-path (2016-12-23) 1 commit
- mingw: add a regression test for pushing to UNC paths
"git push \\server\share\dir" has recently regressed and then
fixed. A test has retroactively been added for this breakage.
Waiting for review to conclude.
cf. <6d69b529-a42c-9f93-f342-7c6c19170285@kdbg.org>
(check the final result.)
* nd/log-graph-configurable-colors (2016-12-25) 1 commit
- log --graph: customize the graph lines with config log.graphColors
Some people feel the default set of colors used by "git log --graph"
rather limiting. A mechanism to customize the set of colors has
been introduced.
Waiting for review to conclude.
cf. <xmqqzijjd34j.fsf@gitster.mtv.corp.google.com>
(Should it be cumulative?)
* sb/submodule-rm-absorb (2016-12-27) 4 commits
- rm: absorb a submodules git dir before deletion
- submodule: rename and add flags to ok_to_remove_submodule
- submodule: modernize ok_to_remove_submodule to use argv_array
- submodule.h: add extern keyword to functions
(this branch uses sb/submodule-embed-gitdir.)
"git rm" used to refuse to remove a submodule when it has its own
git repository embedded in its working tree. It learned to move
the repository away to $GIT_DIR/modules/ of the superproject
instead, and allow the submodule to be deleted (as long as there
will be no loss of local modifications, that is).
* cc/split-index-config (2016-12-26) 21 commits
- Documentation/git-update-index: explain splitIndex.*
- Documentation/config: add splitIndex.sharedIndexExpire
- read-cache: use freshen_shared_index() in read_index_from()
- read-cache: refactor read_index_from()
- t1700: test shared index file expiration
- read-cache: unlink old sharedindex files
- config: add git_config_get_expiry() from gc.c
- read-cache: touch shared index files when used
- sha1_file: make check_and_freshen_file() non static
- Documentation/config: add splitIndex.maxPercentChange
- t1700: add tests for splitIndex.maxPercentChange
- read-cache: regenerate shared index if necessary
- config: add git_config_get_max_percent_split_change()
- Documentation/git-update-index: talk about core.splitIndex config var
- Documentation/config: add information for core.splitIndex
- t1700: add tests for core.splitIndex
- update-index: warn in case of split-index incoherency
- read-cache: add and then use tweak_split_index()
- split-index: add {add,remove}_split_index() functions
- config: add git_config_get_split_index()
- config: mark an error message up for translation
The experimental "split index" feature has gained a few
configuration variables to make it easier to use.
Waiting for review to conclude.
cf. <20161226102222.17150-1-chriscool@tuxfamily.org>
--------------------------------------------------
[Stalled]
* jk/nofollow-attr-ignore (2016-11-02) 5 commits
- exclude: do not respect symlinks for in-tree .gitignore
- attr: do not respect symlinks for in-tree .gitattributes
- exclude: convert "check_index" into a flags field
- attr: convert "macro_ok" into a flags field
- add open_nofollow() helper
As we do not follow symbolic links when reading control files like
.gitignore and .gitattributes from the index, match the behaviour
and not follow symbolic links when reading them from the working
tree. This also tightens security a bit by not leaking contents of
an unrelated file in the error messages when it is pointed at by
one of these files that is a symbolic link.
Perhaps we want to cover .gitmodules too with the same mechanism?
* nd/worktree-move (2016-11-28) 11 commits
. worktree remove: new command
. worktree move: refuse to move worktrees with submodules
. worktree move: accept destination as directory
. worktree move: new command
. worktree.c: add update_worktree_location()
. worktree.c: add validate_worktree()
. copy.c: convert copy_file() to copy_dir_recursively()
. copy.c: style fix
. copy.c: convert bb_(p)error_msg to error(_errno)
. copy.c: delete unused code in copy_file()
. copy.c: import copy_file() from busybox
"git worktree" learned move and remove subcommands.
Reported to break builds on Windows.
* 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.
* 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.
* 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/abbrev-autoscale-config (2016-12-22) 1 commit
(merged to 'next' on 2016-12-27 at 631e4200e2)
+ config.abbrev: document the new default that auto-scales
Recent update to the default abbreviation length that auto-scales
lacked documentation update, which has been corrected.
Will merge to 'master'.
* jc/retire-compaction-heuristics (2016-12-23) 1 commit
(merged to 'next' on 2016-12-27 at c69c2f50cf)
+ diff: retire "compaction" heuristics
"git diff" and its family had two experimental heuristics to shift
the contents of a hunk to make the patch easier to read. One of
them turns out to be better than the other, so leave only the
"--indent-heuristic" option and remove the other one.
Will merge to 'master'.
* bw/push-submodule-only (2016-12-20) 3 commits
- push: add option to push only submodules
- submodules: add RECURSE_SUBMODULES_ONLY value
- transport: reformat flag #defines to be more readable
"git submodule push" learned "--recurse-submodules=only option to
push submodules out without pushing the top-level superproject.
* nd/config-misc-fixes (2016-12-22) 3 commits
(merged to 'next' on 2016-12-27 at 6be64a8671)
+ config.c: handle lock file in error case in git_config_rename_...
+ config.c: rename label unlock_and_out
+ config.c: handle error case for fstat() calls
Leakage of lockfiles in the config subsystem has been fixed.
Will merge to 'master'.
* ls/p4-path-encoding (2016-12-18) 1 commit
- git-p4: fix git-p4.pathEncoding for removed files
When "git p4" imports changelist that removes paths, it failed to
convert pathnames when the p4 used encoding different from the one
used on the Git side. This has been corrected.
Will be rerolled.
cf. <7E1C7387-4F37-423F-803D-3B5690B49D40@gmail.com>
* mh/fast-import-notes-fix-new (2016-12-20) 1 commit
(merged to 'next' on 2016-12-27 at b63805e6f6)
+ fast-import: properly fanout notes when tree is imported
"git fast-import" sometimes mishandled while rebalancing notes
tree, which has been fixed.
Will merge to 'master'.
* bw/pathspec-cleanup (2016-12-14) 16 commits
- pathspec: rename prefix_pathspec to init_pathspec_item
- pathspec: small readability changes
- pathspec: create strip submodule slash helpers
- pathspec: create parse_element_magic helper
- pathspec: create parse_long_magic function
- pathspec: create parse_short_magic function
- pathspec: factor global magic into its own function
- pathspec: simpler logic to prefix original pathspec elements
- pathspec: always show mnemonic and name in unsupported_magic
- pathspec: remove unused variable from unsupported_magic
- pathspec: copy and free owned memory
- pathspec: remove the deprecated get_pathspec function
- ls-tree: convert show_recursive to use the pathspec struct interface
- dir: convert fill_directory to use the pathspec struct interface
- dir: remove struct path_simplify
- mv: remove use of deprecated 'get_pathspec()'
Code clean-up in the pathspec API.
Waiting for the (hopefully) final round of review before 'next'.
* js/prepare-sequencer-more (2016-12-14) 34 commits
- sequencer (rebase -i): write out the final message
- sequencer (rebase -i): write the progress into files
- sequencer (rebase -i): show the progress
- sequencer (rebase -i): suggest --edit-todo upon unknown command
- sequencer (rebase -i): show only failed cherry-picks' output
- sequencer (rebase -i): show only failed `git commit`'s output
- run_command_opt(): optionally hide stderr when the command succeeds
- sequencer (rebase -i): differentiate between comments and 'noop'
- sequencer (rebase -i): implement the 'drop' command
- sequencer (rebase -i): allow rescheduling commands
- sequencer (rebase -i): respect strategy/strategy_opts settings
- sequencer (rebase -i): respect the rebase.autostash setting
- sequencer (rebase -i): run the post-rewrite hook, if needed
- sequencer (rebase -i): record interrupted commits in rewritten, too
- sequencer (rebase -i): copy commit notes at end
- sequencer (rebase -i): set the reflog message consistently
- sequencer (rebase -i): refactor setting the reflog message
- sequencer (rebase -i): allow fast-forwarding for edit/reword
- sequencer (rebase -i): implement the 'reword' command
- sequencer (rebase -i): leave a patch upon error
- sequencer (rebase -i): update refs after a successful rebase
- sequencer (rebase -i): the todo can be empty when continuing
- sequencer (rebase -i): skip some revert/cherry-pick specific code path
- sequencer (rebase -i): remove CHERRY_PICK_HEAD when no longer needed
- sequencer (rebase -i): allow continuing with staged changes
- sequencer (rebase -i): write an author-script file
- sequencer (rebase -i): implement the short commands
- sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
- sequencer (rebase -i): write the 'done' file
- sequencer (rebase -i): learn about the 'verbose' mode
- sequencer (rebase -i): implement the 'exec' command
- sequencer (rebase -i): implement the 'edit' command
- sequencer (rebase -i): implement the 'noop' command
- sequencer: support a new action: 'interactive rebase'
The sequencer has further been extended in preparation to act as a
back-end for "rebase -i".
Waiting for review to conclude.
* bw/realpath-wo-chdir (2016-12-22) 5 commits
(merged to 'next' on 2016-12-22 at fea8fa870f)
+ real_path: canonicalize directory separators in root parts
+ real_path: have callers use real_pathdup and strbuf_realpath
+ real_path: create real_pathdup
+ real_path: convert real_path_internal to strbuf_realpath
+ real_path: resolve symlinks by hand
(this branch is used by bw/grep-recurse-submodules.)
The implementation of "real_path()" was to go there with chdir(2)
and call getcwd(3), but this obviously wouldn't be usable in a
threaded environment. Rewrite it to manually resolve relative
paths including symbolic links in path components.
Will merge to 'master'.
* js/difftool-builtin (2016-11-28) 2 commits
- difftool: implement the functionality in the builtin
- difftool: add a skeleton for the upcoming builtin
Rewrite a scripted porcelain "git difftool" in C.
What's the doneness of this topic?
* sb/push-make-submodule-check-the-default (2016-11-29) 2 commits
(merged to 'next' on 2016-12-12 at 1863e05af5)
+ push: change submodule default to check when submodules exist
+ submodule add: extend force flag to add existing repos
Turn the default of "push.recurseSubmodules" to "check" when
submodules seem to be in use.
Will cook in 'next'.
* sb/submodule-embed-gitdir (2016-12-27) 7 commits
(merged to 'next' on 2016-12-27 at 2b43c15479)
+ worktree: initialize return value for submodule_uses_worktrees
(merged to 'next' on 2016-12-21 at e6cdbcf013)
+ submodule: add absorb-git-dir function
+ move connect_work_tree_and_git_dir to dir.h
+ worktree: check if a submodule uses worktrees
+ test-lib-functions.sh: teach test_commit -C <dir>
+ submodule helper: support super prefix
+ submodule: use absolute path for computing relative path connecting
(this branch is used by sb/submodule-rm-absorb.)
A new submodule helper "git submodule embedgitdirs" to make it
easier to move embedded .git/ directory for submodules in a
superproject to .git/modules/ (and point the latter with the former
that is turned into a "gitdir:" file) has been added.
Will merge to 'master'.
* bw/grep-recurse-submodules (2016-12-22) 7 commits
(merged to 'next' on 2016-12-22 at 1ede815b8d)
+ grep: search history of moved submodules
+ grep: enable recurse-submodules to work on <tree> objects
+ grep: optionally recurse into submodules
+ grep: add submodules as a grep source type
+ submodules: load gitmodules file from commit sha1
+ submodules: add helper to determine if a submodule is initialized
+ submodules: add helper to determine if a submodule is populated
(this branch uses bw/realpath-wo-chdir.)
"git grep" learns to optionally recurse into submodules.
Will merge to 'master'.
* dt/smart-http-detect-server-going-away (2016-11-18) 2 commits
(merged to 'next' on 2016-12-05 at 3ea70d01af)
+ upload-pack: optionally allow fetching any sha1
+ remote-curl: don't hang when a server dies before any output
Originally merged to 'next' on 2016-11-21
When the http server gives an incomplete response to a smart-http
rpc call, it could lead to client waiting for a full response that
will never come. Teach the client side to notice this condition
and abort the transfer.
An improvement counterproposal has failed.
cf. <20161114194049.mktpsvgdhex2f4zv@sigill.intra.peff.net>
Will merge to 'master'.
* mm/push-social-engineering-attack-doc (2016-11-14) 1 commit
(merged to 'next' on 2016-12-05 at 9a2b5bd1a9)
+ doc: mention transfer data leaks in more places
Originally merged to 'next' on 2016-11-16
Doc update on fetching and pushing.
Will merge to 'master'.
* jc/compression-config (2016-11-15) 1 commit
(merged to 'next' on 2016-12-05 at 323769ca07)
+ compression: unify pack.compression configuration parsing
Originally merged to 'next' on 2016-11-23
Compression setting for producing packfiles were spread across
three codepaths, one of which did not honor any configuration.
Unify these so that all of them honor core.compression and
pack.compression variables the same way.
Will merge to 'master'.
* mm/gc-safety-doc (2016-11-16) 1 commit
(merged to 'next' on 2016-12-05 at 031ecc1886)
+ git-gc.txt: expand discussion of races with other processes
Originally merged to 'next' on 2016-11-17
Doc update.
Will merge to 'master'.
* kn/ref-filter-branch-list (2016-12-27) 20 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 an 'rstrip=<N>' option to atoms which deal with refnames
- ref-filter: modify the 'lstrip=<N>' option to work with negative '<N>'
- ref-filter: Do not abruptly die when using the 'lstrip=<N>' option
- ref-filter: rename the 'strip' option to 'lstrip'
- ref-filter: make remote_ref_atom_parser() use refname_atom_parser_internal()
- ref-filter: introduce 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.
Waiting for review to conclude.
* jt/fetch-no-redundant-tag-fetch-map (2016-11-11) 1 commit
(merged to 'next' on 2016-12-05 at 432f9469a7)
+ fetch: do not redundantly calculate tag refmap
Originally merged to 'next' on 2016-11-16
Code cleanup to avoid using redundant refspecs while fetching with
the --tags option.
Will merge to 'master'.
* jc/git-open-cloexec (2016-11-02) 3 commits
(merged to 'next' on 2016-12-27 at 487682eb6e)
+ sha1_file: stop opening files with O_NOATIME
+ git_open_cloexec(): use fcntl(2) w/ FD_CLOEXEC fallback
+ git_open(): untangle possible NOATIME and CLOEXEC interactions
The codeflow of setting NOATIME and CLOEXEC on file descriptors Git
opens has been simplified.
Will merge to 'master'.
We may want to drop the tip one, but we'll see.
* jk/no-looking-at-dotgit-outside-repo-final (2016-10-26) 1 commit
(merged to 'next' on 2016-12-05 at 0c77e39cd5)
+ setup_git_env: avoid blind fall-back to ".git"
Originally merged to 'next' on 2016-10-26
This is the endgame of the topic to avoid blindly falling back to
".git" when the setup sequence said we are _not_ in Git repository.
A corner case that happens to work right now may be broken by a
call to die("BUG").
Will cook in 'next'.
* jc/reset-unmerge (2016-10-24) 1 commit
- reset: --unmerge
After "git add" is run prematurely during a conflict resolution,
"git diff" can no longer be used as a way to sanity check by
looking at the combined diff. "git reset" learned a new
"--unmerge" option to recover from this situation.
Will discard.
This may not be needed, given that update-index has a similar
option.
* jc/merge-base-fp-only (2016-10-19) 8 commits
. merge-base: fp experiment
- merge: allow to use only the fp-only merge bases
- merge-base: limit the output to bases that are on first-parent chain
- merge-base: mark bases that are on first-parent chain
- merge-base: expose get_merge_bases_many_0() a bit more
- merge-base: stop moving commits around in remove_redundant()
- sha1_name: remove ONELINE_SEEN bit
- commit: simplify fastpath of merge-base
An experiment of merge-base that ignores common ancestors that are
not on the first parent chain.
Will discard.
The whole premise feels wrong.
* tb/convert-stream-check (2016-10-27) 2 commits
- convert.c: stream and fast search for binary
- read-cache: factor out get_sha1_from_index() helper
End-of-line conversion sometimes needs to see if the current blob
in the index has NULs and CRs to base its decision. We used to
always get a full statistics over the blob, but in many cases we
can return early when we have seen "enough" (e.g. if we see a
single NUL, the blob will be handled as binary). The codepaths
have been optimized by using streaming interface.
Will discard.
Retracted.
cf. <20161102071646.GA5094@tb-raspi>
* pb/bisect (2016-10-18) 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 `--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
- t6030: no cleanup with bad merge base
- 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
Move more parts of "git bisect" to C.
Waiting for review to conclude.
* st/verify-tag (2016-10-10) 7 commits
- t/t7004-tag: Add --format specifier tests
- t/t7030-verify-tag: Add --format specifier tests
- builtin/tag: add --format argument for tag -v
- builtin/verify-tag: add --format to verify-tag
- tag: add format specifier to gpg_verify_tag
- ref-filter: add function to print single ref_array_item
- gpg-interface, tag: add GPG_VERIFY_QUIET flag
"git tag" and "git verify-tag" learned to put GPG verification
status in their "--format=<placeholders>" output format.
Waiting for a reroll.
cf. <20161007210721.20437-1-santiago@nyu.edu>
* sb/attr (2016-11-11) 35 commits
. completion: clone can initialize specific submodules
. clone: add --init-submodule=<pathspec> switch
. submodule update: add `--init-default-path` switch
. 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
- attr: keep attr stack for each check
- attr: convert to new threadsafe API
- attr: make git_check_attr_counted static
- 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
- attr.c: pass struct git_attr_check down the callchain
- attr.c: add push_stack() helper
- attr: support quoting pathname patterns in C style
- attr: expose validity check for attribute names
- 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
The attributes API has been updated so that it can later be
optimized using the knowledge of which attributes are queried.
Building on top of the updated API, the pathspec machinery learned
to select only paths with given attributes set.
The parts near the tip about pathspec would need to work better
with bw/pathspec-cleanup topic and has been dropped for now.
* jc/latin-1 (2016-09-26) 2 commits
(merged to 'next' on 2016-12-05 at fb549caa12)
+ utf8: accept "latin-1" as ISO-8859-1
+ utf8: refactor code to decide fallback encoding
Originally merged to 'next' on 2016-09-28
Some platforms no longer understand "latin-1" that is still seen in
the wild in e-mail headers; replace them with "iso-8859-1" that is
more widely known when conversion fails from/to it.
Will merge to 'master'.
* sg/fix-versioncmp-with-common-suffix (2016-12-08) 8 commits
- versioncmp: generalize version sort suffix reordering
- squash! versioncmp: use earliest-longest contained suffix to determine sorting order
- versioncmp: use earliest-longest contained suffix to determine sorting order
- versioncmp: cope with common part overlapping with prerelease suffix
- 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 review to conclude.
cf. <20161208142401.1329-1-szeder.dev@gmail.com>
* jc/merge-drop-old-syntax (2015-04-29) 1 commit
(merged to 'next' on 2016-12-05 at 041946dae0)
+ merge: drop 'git merge <message> HEAD <commit>' syntax
Originally merged to 'next' on 2016-10-11
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.
Will cook in 'next'.
^ permalink raw reply
* [PATCH 0/3] Update submodule documentation
From: Stefan Beller @ 2016-12-27 23:43 UTC (permalink / raw)
To: git; +Cc: Stefan Beller
I think I sent out the first 2 patches once upon a time, but the review
or me resending them stalled. They improve the man page for the git-submodule
command.
The third patch is RFC-ish and adds a background story to submodules
Similar to gitattributes, gitnamespaces, gittutorial it doesn't describe
a particular command but e.g. explains design.
Thanks,
Stefan
Stefan Beller (3):
submodule documentation: add options to the subcommand
submodule update documentation: don't repeat ourselves
submodules: add a background story
Documentation/git-submodule.txt | 93 +++++++--------------
Documentation/gitsubmodules.txt | 176 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 206 insertions(+), 63 deletions(-)
create mode 100644 Documentation/gitsubmodules.txt
--
2.11.0.196.gee862f456e.dirty
^ permalink raw reply
* [PATCH 1/3] submodule documentation: add options to the subcommand
From: Stefan Beller @ 2016-12-27 23:43 UTC (permalink / raw)
To: git; +Cc: Stefan Beller
In-Reply-To: <20161227234310.13264-1-sbeller@google.com>
When reading up on a subcommand of `git submodule <subcommand>`,
it is convenient to have its options nearby and not just at the
top of the man page. Add the options to each subcommand.
While at it, also document the `--checkout` option for `update`.
Signed-off-by: Stefan Beller <sbeller@google.com>
---
Documentation/git-submodule.txt | 27 +++++++++++----------------
1 file changed, 11 insertions(+), 16 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index d841573475..f9da0d9e91 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -9,17 +9,12 @@ git-submodule - Initialize, update or inspect submodules
SYNOPSIS
--------
[verse]
-'git submodule' [--quiet] add [-b <branch>] [-f|--force] [--name <name>]
- [--reference <repository>] [--depth <depth>] [--] <repository> [<path>]
+'git submodule' [--quiet] add [<options>] [--] <repository> [<path>]
'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...]
'git submodule' [--quiet] init [--] [<path>...]
'git submodule' [--quiet] deinit [-f|--force] (--all|[--] <path>...)
-'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch]
- [--[no-]recommend-shallow] [-f|--force] [--rebase|--merge]
- [--reference <repository>] [--depth <depth>] [--recursive]
- [--jobs <n>] [--] [<path>...]
-'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) <n>]
- [commit] [--] [<path>...]
+'git submodule' [--quiet] update [<options>] [--] [<path>...]
+'git submodule' [--quiet] summary [<options>] [--] [<path>...]
'git submodule' [--quiet] foreach [--recursive] <command>
'git submodule' [--quiet] sync [--recursive] [--] [<path>...]
@@ -62,7 +57,7 @@ if you choose to go that route.
COMMANDS
--------
-add::
+add [-b <branch>] [-f|--force] [--name <name>] [--reference <repository>] [--depth <depth>] [--] <repository> [<path>]::
Add the given repository as a submodule at the given path
to the changeset to be committed next to the current
project: the current project is termed the "superproject".
@@ -103,7 +98,7 @@ together in the same relative location, and only the
superproject's URL needs to be provided: git-submodule will correctly
locate the submodule using the relative URL in .gitmodules.
-status::
+status [--cached] [--recursive] [--] [<path>...]::
Show the status of the submodules. This will print the SHA-1 of the
currently checked out commit for each submodule, along with the
submodule path and the output of 'git describe' for the
@@ -120,7 +115,7 @@ submodules with respect to the commit recorded in the index or the HEAD,
linkgit:git-status[1] and linkgit:git-diff[1] will provide that information
too (and can also report changes to a submodule's work tree).
-init::
+init [--] [<path>...]::
Initialize the submodules recorded in the index (which were
added and committed elsewhere) by copying submodule
names and urls from .gitmodules to .git/config.
@@ -135,7 +130,7 @@ init::
the explicit 'init' step if you do not intend to customize
any submodule locations.
-deinit::
+deinit [-f|--force] (--all|[--] <path>...)::
Unregister the given submodules, i.e. remove the whole
`submodule.$name` section from .git/config together with their work
tree. Further calls to `git submodule update`, `git submodule foreach`
@@ -151,7 +146,7 @@ instead of deinit-ing everything, to prevent mistakes.
If `--force` is specified, the submodule's working tree will
be removed even if it contains local modifications.
-update::
+update [--init] [--remote] [-N|--no-fetch] [--[no-]recommend-shallow] [-f|--force] [--checkout|--rebase|--merge] [--reference <repository>] [--depth <depth>] [--recursive] [--jobs <n>] [--] [<path>...]::
+
--
Update the registered submodules to match what the superproject
@@ -197,7 +192,7 @@ submodule with the `--init` option.
If `--recursive` is specified, this command will recurse into the
registered submodules, and update any nested submodules within.
--
-summary::
+summary [--cached|--files] [(-n|--summary-limit) <n>] [commit] [--] [<path>...]::
Show commit summary between the given commit (defaults to HEAD) and
working tree/index. For a submodule in question, a series of commits
in the submodule between the given super project commit and the
@@ -210,7 +205,7 @@ summary::
Using the `--submodule=log` option with linkgit:git-diff[1] will provide that
information too.
-foreach::
+foreach [--recursive] <command>::
Evaluates an arbitrary shell command in each checked out submodule.
The command has access to the variables $name, $path, $sha1 and
$toplevel:
@@ -231,7 +226,7 @@ As an example, +git submodule foreach \'echo $path {backtick}git
rev-parse HEAD{backtick}'+ will show the path and currently checked out
commit for each submodule.
-sync::
+sync [--recursive] [--] [<path>...]::
Synchronizes submodules' remote URL configuration setting
to the value specified in .gitmodules. It will only affect those
submodules which already have a URL entry in .git/config (that is the
--
2.11.0.196.gee862f456e.dirty
^ permalink raw reply related
* [PATCH 2/3] submodule update documentation: don't repeat ourselves
From: Stefan Beller @ 2016-12-27 23:43 UTC (permalink / raw)
To: git; +Cc: Stefan Beller
In-Reply-To: <20161227234310.13264-1-sbeller@google.com>
The documentation for the `git submodule update` command, repeats itself
for each update option, "This is done when <option> is given, or no
option is given and `submodule.<name>.update` is set to <string>.
Avoid these repetitive clauses by stating the command line options take
precedence over configured options.
Also add 'none' to the list of options instead of mentioning it in the
following running text and split the list into two parts, one that is
accessible via the command line and one that is only reachable via the
configuration variables.
Signed-off-by: Stefan Beller <sbeller@google.com>
---
Documentation/git-submodule.txt | 30 ++++++++++++++----------------
1 file changed, 14 insertions(+), 16 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index f9da0d9e91..7e03ccc444 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -153,13 +153,13 @@ Update the registered submodules to match what the superproject
expects by cloning missing submodules and updating the working tree of
the submodules. The "updating" can be done in several ways depending
on command line options and the value of `submodule.<name>.update`
-configuration variable. Supported update procedures are:
+configuration variable. The command line option takes precedence over
+the configuration variable. if neither is given, a checkout is performed.
+update procedures supported both from the command line as well as setting
+`submodule.<name>.update`:
checkout;; the commit recorded in the superproject will be
- checked out in the submodule on a detached HEAD. This is
- done when `--checkout` option is given, or no option is
- given, and `submodule.<name>.update` is unset, or if it is
- set to 'checkout'.
+ checked out in the submodule on a detached HEAD.
+
If `--force` is specified, the submodule will be checked out (using
`git checkout --force` if appropriate), even if the commit specified
@@ -167,23 +167,21 @@ in the index of the containing repository already matches the commit
checked out in the submodule.
rebase;; the current branch of the submodule will be rebased
- onto the commit recorded in the superproject. This is done
- when `--rebase` option is given, or no option is given, and
- `submodule.<name>.update` is set to 'rebase'.
+ onto the commit recorded in the superproject.
merge;; the commit recorded in the superproject will be merged
- into the current branch in the submodule. This is done
- when `--merge` option is given, or no option is given, and
- `submodule.<name>.update` is set to 'merge'.
+ into the current branch in the submodule.
+
+The following procedures are only available via the `submodule.<name>.update`
+configuration variable:
custom command;; arbitrary shell command that takes a single
argument (the sha1 of the commit recorded in the
- superproject) is executed. This is done when no option is
- given, and `submodule.<name>.update` has the form of
- '!command'.
+ superproject) is executed. When `submodule.<name>.update`
+ is set to '!command', the remainder after the exclamation mark
+ is the custom command.
-When no option is given and `submodule.<name>.update` is set to 'none',
-the submodule is not updated.
+ none;; the submodule is not updated.
If the submodule is not yet initialized, and you just want to use the
setting as stored in .gitmodules, you can automatically initialize the
--
2.11.0.196.gee862f456e.dirty
^ permalink raw reply related
* [PATCH 3/3] submodules: add a background story
From: Stefan Beller @ 2016-12-27 23:43 UTC (permalink / raw)
To: git; +Cc: Stefan Beller
In-Reply-To: <20161227234310.13264-1-sbeller@google.com>
Just like gitattributes, gitcredentials, gitnamespaces, gittutorial,
gitmodules, we'd like to provide some background on submodules,
which is not specific to the `submodule` command, but elaborates
on the background and its intended usage.
Signed-off-by: Stefan Beller <sbeller@google.com>
---
Documentation/git-submodule.txt | 36 ++------
Documentation/gitsubmodules.txt | 176 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 181 insertions(+), 31 deletions(-)
create mode 100644 Documentation/gitsubmodules.txt
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 7e03ccc444..c99920aceb 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -23,37 +23,7 @@ DESCRIPTION
-----------
Inspects, updates and manages submodules.
-A submodule allows you to keep another Git repository in a subdirectory
-of your repository. The other repository has its own history, which does not
-interfere with the history of the current repository. This can be used to
-have external dependencies such as third party libraries for example.
-
-When cloning or pulling a repository containing submodules however,
-these will not be checked out by default; the 'init' and 'update'
-subcommands will maintain submodules checked out and at
-appropriate revision in your working tree.
-
-Submodules are composed from a so-called `gitlink` tree entry
-in the main repository that refers to a particular commit object
-within the inner repository that is completely separate.
-A record in the `.gitmodules` (see linkgit:gitmodules[5]) file at the
-root of the source tree assigns a logical name to the submodule and
-describes the default URL the submodule shall be cloned from.
-The logical name can be used for overriding this URL within your
-local repository configuration (see 'submodule init').
-
-Submodules are not to be confused with remotes, which are other
-repositories of the same project; submodules are meant for
-different projects you would like to make part of your source tree,
-while the history of the two projects still stays completely
-independent and you cannot modify the contents of the submodule
-from within the main project.
-If you want to merge the project histories and want to treat the
-aggregated whole as a single project from then on, you may want to
-add a remote for the other project and use the 'subtree' merge strategy,
-instead of treating the other project as a submodule. Directories
-that come from both projects can be cloned and checked out as a whole
-if you choose to go that route.
+For more information about submodules, see linkgit:gitsubmodules[5]
COMMANDS
--------
@@ -405,6 +375,10 @@ This file should be formatted in the same way as `$GIT_DIR/config`. The key
to each submodule url is "submodule.$name.url". See linkgit:gitmodules[5]
for details.
+SEE ALSO
+--------
+linkgit:gitsubmodules[1], linkgit:gitmodules[1].
+
GIT
---
Part of the linkgit:git[1] suite
diff --git a/Documentation/gitsubmodules.txt b/Documentation/gitsubmodules.txt
new file mode 100644
index 0000000000..aa5fa25608
--- /dev/null
+++ b/Documentation/gitsubmodules.txt
@@ -0,0 +1,176 @@
+gitsubmodules(5)
+================
+
+NAME
+----
+gitsubmodules - information about submodules
+
+SYNOPSIS
+--------
+$GIT_DIR/config, .gitmodules
+
+------------------
+git submodule
+------------------
+
+DESCRIPTION
+-----------
+
+A submodule allows you to keep another Git repository in a subdirectory
+of your repository. The other repository has its own history, which does not
+interfere with the history of the current repository. This can be used to
+have external dependencies such as third party libraries for example.
+
+Submodules are composed from a so-called `gitlink` tree entry
+in the main repository that refers to a particular commit object
+within the inner repository that is completely separate.
+A record in the `.gitmodules` (see linkgit:gitmodules[5]) file at the
+root of the source tree assigns a logical name to the submodule and
+describes the default URL the submodule shall be cloned from.
+The logical name can be used for overriding this URL within your
+local repository configuration (see 'submodule init').
+
+Submodules are not to be confused with remotes, which are other
+repositories of the same project; submodules are meant for
+different projects you would like to make part of your source tree,
+while the history of the two projects still stays completely
+independent and you cannot modify the contents of the submodule
+from within the main project.
+If you want to merge the project histories and want to treat the
+aggregated whole as a single project from then on, you may want to
+add a remote for the other project and use the 'subtree' merge strategy,
+instead of treating the other project as a submodule. Directories
+that come from both projects can be cloned and checked out as a whole
+if you choose to go that route.
+
+When cloning or pulling a repository containing submodules however,
+the submodules will not be checked out by default; You need to instruct
+'clone' to recurse into submodules. The 'init' and 'update' subcommands
+of 'git submodule' will maintain submodules checked out and at an
+appropriate revision in your working tree.
+
+WHEN TO USE
+-----------
+
+Submodules, repositories in other repositories, can be used for different
+use cases:
+
+* To have finer grained access control.
+ The design principles of Git do not allow for partial repositories to be
+ checked out or transferred. A repository is the smallest unit that a user
+ can be given access to. Submodules are separate repositories, such that
+ you can restrict access to parts of your project via the use of submodules.
+
+* To decouple Git histories.
+ Decoupling histories has different benefits.
+
+ When you want to use a (third party) library tied to a specific version.
+ Using submodules for a library allows you to have a clean history for
+ your own project and only updating the library in the submodule when needed.
+
+ In its current form Git scales up poorly for very large repositories that
+ change a lot, as the history grows very large. For that you may want to look
+ at shallow clone, sparse checkout or git-lfs.
+ However you can also use submodules to e.g. hold large binary assets
+ and these repositories are then shallowly cloned such that you do not
+ have a large history locally.
+
+STATES
+------
+
+Submodules can be in different states, the following indicators are used:
+
+* the existence of the setting of 'submodule.<name>.url' in the
+ superprojects configuration
+* the existence of the submodules working tree within the
+ working tree of the superproject
+* the existence of the submodules git directory within the superprojects
+ git directory at $GIT_DIR/modules/<name> or within the submodules working
+ tree
+
+ State URL config working tree git dir
+ -----------------------------------------------------
+ uninitialized no no no
+ initialized yes no no
+ populated yes yes yes
+ depopulated yes no yes
+ deinitialized no no yes
+ uninteresting no yes yes
+
+ invalid no yes no
+ invalid yes yes no
+ -----------------------------------------------------
+
+The first six states can be reached by normal git usage, the latter two are
+only shown for completeness. The states in detail:
+
+* uninitialized
+ The uninitialized state is the default state if no
+ '--recurse-submodules' / '--recursive'. An empty directory will be put in
+ the working tree as a place holder, such that you are reminded of the
+ existence of the submodule.
+
+ To transition into the initialized state
+ you can use 'git submodule init', which copies the presets from the
+ .gitmodules file into the config.
+
+* initialized
+ Users transitioned from the uninitialized state to this state via
+ 'git submodule init', which preset the URL configuration. As these URLs
+ may not be desired in certain scenarios, this state allows to change the
+ URLs. For example in a corporate environment you may want to run
+
+ sed -i s/github.com/$internal-mirror/ .git/config
+
+ before proceeding to populate the submodules.
+
+* populated
+ In the populated state you have the submodule fully available.
+
+* depopulated
+ In this state you still have the git directory around, but the working tree
+ is gone. For example when the superproject checks out a revision that doesn't
+ have the submodule, the state changes to depopulated.
+
+* deinitialized
+ The git directory is still there, but the user is no longer interested in the
+ submodule as inidicated by the missing URL configuration.
+
+
+INNER WORKINGS
+--------------
+
+On the location of the git directory
+------------------------------------
+
+Since v1.7.7 of Git, the git directory of submodules is stored inside the
+superprojects git directory at $GIT_DIR/modules/<submodule-name>
+This location allows for the working tree to be non existent while keeping
+the history around. So we can use git-rm on a submodule without loosing
+information that may only be local.
+
+In the future we may see git-checkout that can checkout submodules and
+revisions that do not contain the submodule can still be checked out without
+having to drop the submodules git directory.
+
+It is also possbile to imagine a future in which a bare repository still
+contains its submodules inside the modules sub directory, such that you can
+get a full clone including submodules from that bare repository, the URLs
+as configured or given in the .gitmodules would only be used as a backup.
+
+SAMPLE WORKFLOWS (RFC/TODO)
+----------------
+Do we need
+* an opinionated way to check for a specific state of a submodule
+* (submodule helper to be plumbing?)
+* expose the design mistake of having the (name->path) mapping inside the
+ working tree, i.e. never remove a name from the submodule config even when
+ the submodule doesn't exist any more.
+
+SEE ALSO
+--------
+linkgit:git-submodule[1], linkgit:gitmodules[1].
+
+GIT
+---
+Part of the linkgit:git[1] suite
--
2.11.0.196.gee862f456e.dirty
^ permalink raw reply related
* [PATCH] pathspec: give better message for submodule related pathspec error
From: Stefan Beller @ 2016-12-28 0:05 UTC (permalink / raw)
To: bmwill; +Cc: git, Stefan Beller
Every once in a while someone complains to the mailing list to have
run into this weird assertion[1].
The usual response from the mailing list is link to old discussions[2],
and acknowledging the problem stating it is known.
For now just improve the user visible error message.
[1] https://www.google.com/search?q=item-%3Enowildcard_len
[2] http://git.661346.n2.nabble.com/assert-failed-in-submodule-edge-case-td7628687.html
https://www.spinics.net/lists/git/msg249473.html
Signed-off-by: Stefan Beller <sbeller@google.com>
---
If you were following the mailing list closely today, you may sense
that I am cleaning up stalled branches. :)
I think such a hot fix is warranted given how often we had reports
on the mailing list.
Thanks,
Stefan
pathspec.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/pathspec.c b/pathspec.c
index 22ca74a126..d522f43331 100644
--- a/pathspec.c
+++ b/pathspec.c
@@ -313,8 +313,11 @@ static unsigned prefix_pathspec(struct pathspec_item *item,
}
/* sanity checks, pathspec matchers assume these are sane */
- assert(item->nowildcard_len <= item->len &&
- item->prefix <= item->len);
+ if (item->nowildcard_len <= item->len &&
+ item->prefix <= item->len)
+ die (_("Path leads inside submodule '%s', but the submodule "
+ "was not recognized, i.e. not initialized or deleted"),
+ ce->name);
return magic;
}
--
2.11.0.196.gee862f456e.dirty
^ permalink raw reply related
* HowTo distribute a hook with the reposity.
From: John P. Hartmann @ 2016-12-28 1:34 UTC (permalink / raw)
To: git
I would like a hook in .got/hooks to be made available to all who clone
or pull a particular project. I'd also like the hook to be under git
control (changes committed &c). I added a hook, but git status does not
show it. Presumably git excludes its files in .git/ from version
control lest there be a chiken-and-egg situation.
Is there a way to achieve this? Or a better way to do it?
Thanks, j.
^ permalink raw reply
* Re: [PATCH v9 15/20] ref-filter: modify the 'lstrip=<N>' option to work with negative '<N>'
From: Jacob Keller @ 2016-12-28 3:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Karthik Nayak, Git mailing list, Ramsay Jones
In-Reply-To: <xmqqo9zx6phw.fsf@gitster.mtv.corp.google.com>
On Tue, Dec 27, 2016 at 1:11 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Karthik Nayak <karthik.188@gmail.com> writes:
>
>> Currently the 'lstrip=<N>' option only takes a positive value '<N>'
>> and strips '<N>' slash-separated path components from the left. Modify
>> the 'lstrip' option to also take a negative number '<N>' which would
>> only _leave_ behind 'N' slash-separated path components from the left.
>
> "would only leave behind N components from the left" sounds as if
> the result is A/B, when you are given A/B/C/D/E and asked to
> lstrip:-2. Given these two tests added by the patch ...
>
>> +test_atom head refname:lstrip=-1 master
>> +test_atom head refname:lstrip=-2 heads/master
>
> ... I somehow think that is not what you wanted to say. Instead,
> you strip from the left as many as necessary and leave -N
> components that appear at the right-most end, no?
>
>> --- a/Documentation/git-for-each-ref.txt
>> +++ b/Documentation/git-for-each-ref.txt
>> @@ -98,7 +98,8 @@ refname::
>> abbreviation mode. If `lstrip=<N>` is appended, strips `<N>`
>> slash-separated path components from the front of the refname
>> (e.g., `%(refname:lstrip=2)` turns `refs/tags/foo` into `foo`.
>> - `<N>` must be a positive integer.
>> + if `<N>` is a negative number, then only `<N>` path components
>> + are left behind.
>
> I think positive <N> is so obvious not to require an example but it
> is good that you have one. The negative <N> case needs illustration
> more than the positive case. Perhaps something like:
>
> (e.g. %(refname:lstrip=-1) strips components of refs/tags/frotz
> from the left to leave only one component, i.e. 'frotz').
>
> Would %(refname:lstrip=-4) attempt to strip components of
> refs/tags/frotz from the left to leave only four components, and
> because the original does not have that many components, it ends
> with refs/tags/frotz?
>
> I am debating myself if we need something like "When the ref does
> not have enough components, the result becomes an empty string if
> stripping with positive <N>, or it becomes the full refname if
> stripping with negative <N>. Neither is an error." is necessary
> here. Or is it too obvious?
I do not think it hurts to have, and makes this obvious.
Thanks,
Jake
^ permalink raw reply
* Re: HowTo distribute a hook with the reposity.
From: Jacob Keller @ 2016-12-28 5:32 UTC (permalink / raw)
To: John P. Hartmann; +Cc: Git mailing list
In-Reply-To: <6e228b75-0208-63e8-b4e8-70905e3f9ea3@gmail.com>
On Tue, Dec 27, 2016 at 5:34 PM, John P. Hartmann <jphartmann@gmail.com> wrote:
> I would like a hook in .got/hooks to be made available to all who clone or
> pull a particular project. I'd also like the hook to be under git control
> (changes committed &c). I added a hook, but git status does not show it.
> Presumably git excludes its files in .git/ from version control lest there
> be a chiken-and-egg situation.
>
> Is there a way to achieve this? Or a better way to do it?
>
> Thanks, j.
Best way I found, was add a script with an "installme" shell script or
similar that you tell all users of the repository that they are
expected to run this to install the scripts. You can' make it happen
automatically.
Thanks,
Jake
^ permalink raw reply
* Re: [PATCH] pathspec: give better message for submodule related pathspec error
From: Jeff King @ 2016-12-28 5:58 UTC (permalink / raw)
To: Stefan Beller; +Cc: bmwill, git
In-Reply-To: <20161228000559.17842-1-sbeller@google.com>
On Tue, Dec 27, 2016 at 04:05:59PM -0800, Stefan Beller wrote:
> Every once in a while someone complains to the mailing list to have
> run into this weird assertion[1].
If people are running into it, it definitely should not be an assert,
nor a die("BUG"). It should be a regular die(), which your patch does.
So this is definitely a good step, even if the ultimate goal may be to
handle the case more gracefully (I say that without having even read the
background, or knowing what the right handling would be).
But...
> diff --git a/pathspec.c b/pathspec.c
> index 22ca74a126..d522f43331 100644
> --- a/pathspec.c
> +++ b/pathspec.c
> @@ -313,8 +313,11 @@ static unsigned prefix_pathspec(struct pathspec_item *item,
> }
>
> /* sanity checks, pathspec matchers assume these are sane */
> - assert(item->nowildcard_len <= item->len &&
> - item->prefix <= item->len);
> + if (item->nowildcard_len <= item->len &&
> + item->prefix <= item->len)
> + die (_("Path leads inside submodule '%s', but the submodule "
> + "was not recognized, i.e. not initialized or deleted"),
> + ce->name);
Don't you need to flip the logic here? An assert() triggers when the
condition is not true, but an "if" does the opposite. So "assert(X)"
should always become "if (!X) die(...)".
-Peff
^ permalink raw reply
* Re: HowTo distribute a hook with the reposity.
From: Jeff King @ 2016-12-28 6:08 UTC (permalink / raw)
To: Jacob Keller; +Cc: John P. Hartmann, Git mailing list
In-Reply-To: <CA+P7+xqHTgRvMRwgL2TJ7SRb_SR0sbtA039J_5N0xSjf3TNrgg@mail.gmail.com>
On Tue, Dec 27, 2016 at 09:32:22PM -0800, Jacob Keller wrote:
> On Tue, Dec 27, 2016 at 5:34 PM, John P. Hartmann <jphartmann@gmail.com> wrote:
> > I would like a hook in .got/hooks to be made available to all who clone or
> > pull a particular project. I'd also like the hook to be under git control
> > (changes committed &c). I added a hook, but git status does not show it.
> > Presumably git excludes its files in .git/ from version control lest there
> > be a chiken-and-egg situation.
> >
> > Is there a way to achieve this? Or a better way to do it?
> >
> > Thanks, j.
>
> Best way I found, was add a script with an "installme" shell script or
> similar that you tell all users of the repository that they are
> expected to run this to install the scripts. You can' make it happen
> automatically.
I agree that is the best way to do it.
I didn't dig up previous discussions, but the gist is usually:
1. Cloning a repository should not run arbitrary code from the remote
without the user on the cloning side taking some further affirmative
action.
This is for security reasons. Obviously the next step is quite often
to run "make" which does run arbitrary code, but that counts as an
action.
2. We could write a feature in git that manages hooks (or config, etc).
But ultimately you would still be running "git clone
--trust-remote-hooks" or something to satisfy point (1).
3. There's not much point in doing point (2), because you can just
spell it as "git clone && cd clone && ./install-hooks" and then git
does not have to care at all about your scripts.
4. A hook (or config) management system could do fancy things like
merging your custom local config, picking up changes from the
remote, etc. But all of that can happen outside of Git totally (and
quite often you want to manage things in contributors setups
_besides_ Git data anyway).
An example system is:
https://github.com/Autodesk/enterprise-config-for-git
(with the disclaimer that I've never used it myself, so I have no
idea how good it is).
I think you probably know all that, Jake, but I am laying it out for the
benefit of the OP and the list. :)
-Peff
^ 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