* Re: [PATCH v5 3/6] stash: refactor stash_create
From: Jeff King @ 2017-02-17 23:48 UTC (permalink / raw)
To: Thomas Gummerer
Cc: git, Junio C Hamano, Johannes Schindelin, Øyvind A . Holm,
Jakub Narębski, Matthieu Moy
In-Reply-To: <20170217224141.19183-4-t.gummerer@gmail.com>
On Fri, Feb 17, 2017 at 10:41:38PM +0000, Thomas Gummerer wrote:
> Refactor the internal stash_create function to use a -m flag for
> specifying the message and -u flag to indicate whether untracked files
> should be added to the stash.
>
> This makes it easier to pass a pathspec argument to stash_create in the
> next patch.
>
> The user interface for git stash create stays the same.
Sounds good, but...
> diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
> index 2e9cef06e6..d93c47446a 100644
> --- a/Documentation/git-stash.txt
> +++ b/Documentation/git-stash.txt
> @@ -17,6 +17,7 @@ SYNOPSIS
> [-u|--include-untracked] [-a|--all] [<message>]]
> 'git stash' clear
> 'git stash' create [<message>]
> +'git stash' create [-m <message>] [-u|--include-untracked <untracked|all>]
> 'git stash' store [-m|--message <message>] [-q|--quiet] <commit>
Should this hunk be dropped from the manpage, then?
I think there is a similar one in the next patch that adds the
"pathspec" argument, and should be dropped, too.
-Peff
^ permalink raw reply
* Re: [PATCH v5 6/6] stash: allow pathspecs in the no verb form
From: Jeff King @ 2017-02-17 23:46 UTC (permalink / raw)
To: Thomas Gummerer
Cc: git, Junio C Hamano, Johannes Schindelin, Øyvind A . Holm,
Jakub Narębski, Matthieu Moy
In-Reply-To: <20170217224141.19183-7-t.gummerer@gmail.com>
On Fri, Feb 17, 2017 at 10:41:41PM +0000, Thomas Gummerer wrote:
> Now that stash_push is used in the no verb form of stash, allow
> specifying the command line for this form as well. Always use -- to
> disambiguate pathspecs from other non-option arguments.
I think that makes sense.
> Also make git stash -p an alias for git stash push -p. This allows
> users to use git stash -p <pathspec>.
And I think of all the options we discussed for handling "-p", I think
this one makes the most sense.
It may be worth calling out in the documentation that this is how it
works though, so people do not think that:
git stash -k -p <path>
would work ("git stash -k -p" _does_ happen to work due to the old
options-only rule, but I think we should advertise the general form as
"-p is an alias for "push -p").
-Peff
^ permalink raw reply
* Re: [PATCH 3/3] rename_ref: replace empty deletion message in HEAD's log
From: Kyle Meyer @ 2017-02-17 23:42 UTC (permalink / raw)
To: Jeff King, Junio C Hamano; +Cc: git
In-Reply-To: <20170217195549.z6uyy7hbbhj5avh7@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Feb 17, 2017 at 02:43:50PM -0500, Jeff King wrote:
>
>> Yes. I think the options are basically (in order of decreasing
>> preference in my opinion):
>>
>> 1. Log a rename entry (same sha1, but note the rename in the free-form
>> text).
>>
>> 2. Log a delete (sha1 goes to null) followed by a creation (from null
>> back to the original sha1).
>>
>> 3. Log nothing at all for HEAD.
>>
>> This does half of (2). If we do the second half, then I'd prefer it to
>> (3). But if we can do (1), that is better still (IMHO).
[...]
>> I'm actually confused about which bit of code is updating HEAD. I do not
>> see it either in files_rename_ref() or in the caller. Yet it clearly
>> happens. But that is the code that would know enough to do (1) or the
>> second half of (2) above.
>
> Ah, I found it. It's in replace_each_worktree_head_symref() these days,
> which does not bother to pass a log message.
>
> So I think the second half of (2) is probably something like the patch
> below.
>
> Thinking on it more, we probably _do_ want two entries. Because the
> operations are not atomic, it's possible that we may end up in a
> half-way state after the first entry is written. And when debugging such
> a case, I'd much rather see the first half of the operation logged than
> nothing at all.
OK, I'll have a go at replacing patch 3 with this approach.
--
Kyle
^ permalink raw reply
* Re: [PATCH 3/3] rename_ref: replace empty deletion message in HEAD's log
From: Kyle Meyer @ 2017-02-17 23:41 UTC (permalink / raw)
To: Junio C Hamano, Jeff King; +Cc: git
In-Reply-To: <xmqqk28ou2o1.fsf@gitster.mtv.corp.google.com>
Junio C Hamano <gitster@pobox.com> writes:
[...]
> Do we even want these "internal" delete_ref() invocations to be
> logged in HEAD's reflog? I understand that this is inside the
> implementation of renaming an old ref to a new ref, and reflog
> message given to delete_ref() would matter only if the HEAD happens
> to be pointing at old ref---but then HEAD will be repointed to the
> new ref by somebody else [*1*] that called this function to rename
> old to new and it _will_ log it.
I know the discussion has developed further, but just a note that I
think the last statement is inaccurate: currently, a rename will not be
recorded in HEAD's log. "git branch -m" will show a renaming event in
the new branch's log, but the only trace of the event in HEAD's log is
the deletion entry with an empty message.
--
Kyle
^ permalink raw reply
* Re: [PATCH 2/3] update-ref: pass reflog message argument to delete_refs
From: Jeff King @ 2017-02-17 23:41 UTC (permalink / raw)
To: Kyle Meyer; +Cc: Junio C Hamano, git
In-Reply-To: <8737fcqtcj.fsf@kyleam.com>
On Fri, Feb 17, 2017 at 06:40:28PM -0500, Kyle Meyer wrote:
> > For reference, the two things I notice are:
> >
> > - we prefer test_path_is_missing to "! test -f" these days.
> >
> > - we don't redirect the output of grep (it's handled already in
> > non-verbose mode, and in verbose mode we try to be...verbose).
>
> Would moving cleanup like "rm -f .git/$m" within the test's body using
> test_when_finished also be preferred?
Yeah, that too. I forgot to mention it.
-Peff
^ permalink raw reply
* Re: [PATCH 2/3] update-ref: pass reflog message argument to delete_refs
From: Kyle Meyer @ 2017-02-17 23:40 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20170217082253.kxjezkxfqkfxjhzr@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
[...]
>> diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
>> index b0ffc0b57..65918d984 100755
>> --- a/t/t1400-update-ref.sh
>> +++ b/t/t1400-update-ref.sh
>> @@ -85,6 +85,15 @@ test_expect_success "delete $m (by HEAD)" '
>> '
>> rm -f .git/$m
>>
>> +test_expect_success "deleting current branch adds message to HEAD's log" '
>> + git update-ref $m $A &&
>> + git symbolic-ref HEAD $m &&
>> + git update-ref -mdelmsg -d $m &&
>> + ! test -f .git/$m &&
>> + grep "delmsg$" .git/logs/HEAD >/dev/null
>> +'
>> +rm -f .git/$m
>
> I think covering this with a test is good.
>
> I don't know if it's also worth testing that deleting via HEAD also
> writes the reflog. I.e.,:
>
> git update-ref -m delete-by-head -d HEAD
Seems reasonable to cover this case as well.
> Some of the style here is a bit out-dated, but I think you are just
> matching the surrounding tests. So that's OK by me (though a patch to
> modernize the whole thing would be welcome, too).
Right. I'd be happy to follow up with a patch updating the style in
t1400-update-ref.sh.
> For reference, the two things I notice are:
>
> - we prefer test_path_is_missing to "! test -f" these days.
>
> - we don't redirect the output of grep (it's handled already in
> non-verbose mode, and in verbose mode we try to be...verbose).
Would moving cleanup like "rm -f .git/$m" within the test's body using
test_when_finished also be preferred?
--
Kyle
^ permalink raw reply
* Re: [PATCH] tempfile: avoid "ferror | fclose" trick
From: Jeff King @ 2017-02-17 23:39 UTC (permalink / raw)
To: Junio C Hamano
Cc: Michael Haggerty, Andreas Schwab, Jáchym Barvínek, git
In-Reply-To: <xmqqzihkphkc.fsf@gitster.mtv.corp.google.com>
On Fri, Feb 17, 2017 at 02:40:19PM -0800, Junio C Hamano wrote:
> > Right. EIO is almost certainly _not_ the error we saw. But I would
> > rather consistently say "I/O error" and have the user scratch their
> > head, look up this thread, and say "ah, it was probably a deferred
> > error", as opposed to the alternative: the user sees something
> > nonsensical like ENOMEM or EBADF. Those are more misleading, and worse,
> > may change from run to run based on what other code runs or fails in
> > between.
>
> My point was actually not what errno we feed to strerror(). In that
> example, what is more misleading is the fixed part of the error
> message the caller of close_tempfile() used after seeing the funcion
> fail, i.e. "failed to close". strerror() part is used to explain
> why we "failed to close", and of course any nonsensical errno that
> we did not get from the failed stdio call would not explain it, but
> a more misleading part is that we did not even "failed to close" it.
>
> We just noticed an earlier error while attempting to close it.
> strerror() in the message does not even have to be related to the
> closing of the file handle.
Ah, I see. I think the errno thing is a strict improvement over what is
there now. Actually having a separate error message is even better, but
it does end up rather verbose in the callers.
I'm also not sure that it's all that useful to distinguish errors from
fwrite() versus fclose(). In practice, errors will come from write() in
either case, and the caller does not have much control over when the
flushing happens. So any error saying "error closing file" is probably
assuming too much anyway. It should be "error writing file".
And I think in practice the messages end up quite generic anyway, as
they are really calling commit_lock_file(), which may also fail due to a
rename. So you get something like "unable to write 'foo': ", with errno
appended. That's _also_ potentially confusing when rename() fails.
Solving that would probably require passing down an "err" strbuf (or
other data structure) for the low-level code to fill in.
> > The only reason I do not think we should do so for close_tempfile() is
> > that the fclose is typically far away from the code that actually calls
> > error(). We'd have to pass the tristate (success, fail, fail-with-errno)
> > state up through the stack (most of the calls indirectly come from
> > commit_lock_file(), I would think).
>
> We _could_ clear errno to allow caller to tell them apart, though,
> if we wanted to ;-)
Hmm. So basically "errno = 0" instead of EIO? That at least has the
advantage that you can tell it apart from a real EIO, and a caller
_could_ if they chose do:
if (commit_lock_file(&lock)) {
if (!errno)
error("error writing to file");
else
error_errno("error closing file");
}
But I am not sure I would want to annotate all such callers that way. It
would probably be less bad to just pass down a "quiet" flag or a strbuf
and have the low-level code fill it in. And that solves this problem
_and_ the rename() thing above.
But TBH, I am not sure if it is worth it. Nobody is complaining. This is
just a thing we noticed. I think setting errno to EIO or to "0" is a
strict improvement over what is there (where the errno is essentially
random) and the complexity doesn't escape the function.
So I think that "easy" thing falls far short of a solution, but it's at
least easy. I could take it or leave it at this point.
-Peff
^ permalink raw reply
* Re: dotfiles in git template dir are not copied
From: Grégoire PARIS @ 2017-02-17 23:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <xmqqvas8phdl.fsf@gitster.mtv.corp.google.com>
>There was no 'bug' either. It's just the way it is ;-)
Sure !
^ permalink raw reply
* Re: [PATCH 1/3] delete_refs(): accept a reflog message argument
From: Kyle Meyer @ 2017-02-17 23:35 UTC (permalink / raw)
To: Junio C Hamano, Jeff King; +Cc: git
In-Reply-To: <xmqqshncu4r4.fsf@gitster.mtv.corp.google.com>
Junio C Hamano <gitster@pobox.com> writes:
> Jeff King <peff@peff.net> writes:
>
>>> diff --git a/refs.h b/refs.h
>>> index 9fbff90e7..81627a63d 100644
>>> --- a/refs.h
>>> +++ b/refs.h
>>> @@ -277,7 +277,7 @@ int reflog_exists(const char *refname);
>>> * be NULL_SHA1. flags is passed through to ref_transaction_delete().
>>> */
>>> int delete_ref(const char *refname, const unsigned char *old_sha1,
>>> - unsigned int flags);
>>> + unsigned int flags, const char *msg);
>>
>> Should the "msg" argument go at the beginning, to match update_ref()?
>
> Probably. rename/create have the message at the end but their
> parameters are very different from update/delete. The parameters
> update and delete take are not identical, but we can view them as a
> lot more similar than the other two. So I think it makes sense for
> delete to try matching update, even though trying to make all four
> the same may proabably be pointless.
I put "msg" after "flags" because that's where it occurs in
ref_transaction_delete(), but matching update_ref() makes sense.
--
Kyle
^ permalink raw reply
* [PATCH] Document dotfiles exclusion on template copy
From: Grégoire Paris @ 2017-02-17 23:37 UTC (permalink / raw)
To: git; +Cc: Grégoire Paris
Since there is no dotfile in the default template directory, there was
no point in making the check for . or .. more accurate when copying. Now
that you can customize the template directory, it would make sense, but
it's actually a good thing to at this because you would not want to have
your git directory copied in every git directory that is created should
you decide to put your template directory under version control. Plus, it
might be used as a feature by people who would want to exclude some
files.
Signed-off-by: Grégoire Paris <postmaster@greg0ire.fr>
---
Here is a better version.
Documentation/git-init.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt
index 9d27197..3c5a67f 100644
--- a/Documentation/git-init.txt
+++ b/Documentation/git-init.txt
@@ -116,8 +116,8 @@ does not exist, it will be created.
TEMPLATE DIRECTORY
------------------
-The template directory contains files and directories that will be copied to
-the `$GIT_DIR` after it is created.
+Files and directories in the template directory whose name do not start with a
+dot will be copied to the `$GIT_DIR` after it is created.
The template directory will be one of the following (in order):
--
2.9.3
^ permalink raw reply related
* Re: [PATCH] Document dotfiles exclusion on template copy
From: Grégoire PARIS @ 2017-02-17 23:32 UTC (permalink / raw)
To: Grégoire Paris, git
In-Reply-To: <20170217232748.13164-1-postmaster@greg0ire.fr>
>
> -The template directory contains files and directories that will be copied to
> -the `$GIT_DIR` after it is created.
> +The template directory contains files and directories whose name do not start
> +with a dot will be copied to the `$GIT_DIR` after it is created.
>
> The template directory will be one of the following (in order):
>
This sentence does not make any sense, I realize that now.
^ permalink raw reply
* Re: dotfiles in git template dir are not copied
From: Grégoire PARIS @ 2017-02-17 23:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <32094790-1c2b-bc2a-bfde-a101b18945d7@greg0ire.fr>
> Thanks for your guidance. I believe I just sent the patch to the
mailing list.
I just retried with the Gmail SMTP, and now I am sure it worked. Sorry
for the noobery.
^ permalink raw reply
* [PATCH] Document dotfiles exclusion on template copy
From: Grégoire Paris @ 2017-02-17 23:27 UTC (permalink / raw)
To: git; +Cc: Grégoire Paris
Since there is no dotfile in the default template directory, there was
no point in making the check for . or .. more accurate when copying. Now
that you can customize the template directory, it would make sense, but
it's actually a good thing to at this because you would not want to have
your git directory copied in every git directory that is created should
you decide to put your template directory under version control. Plus, it
might be used as a feature by people who would want to exclude some
files.
Signed-off-by: Grégoire Paris <postmaster@greg0ire.fr>
---
I hope I'm getting it right, this is my first time using format-patch and
send-email…
Documentation/git-init.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt
index 9d27197..7605742 100644
--- a/Documentation/git-init.txt
+++ b/Documentation/git-init.txt
@@ -116,8 +116,8 @@ does not exist, it will be created.
TEMPLATE DIRECTORY
------------------
-The template directory contains files and directories that will be copied to
-the `$GIT_DIR` after it is created.
+The template directory contains files and directories whose name do not start
+with a dot will be copied to the `$GIT_DIR` after it is created.
The template directory will be one of the following (in order):
--
2.9.3
^ permalink raw reply related
* Re: dotfiles in git template dir are not copied
From: Grégoire PARIS @ 2017-02-17 23:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <xmqqk28opgsy.fsf@gitster.mtv.corp.google.com>
Thanks for your guidance. I believe I just sent the patch to the mailing
list.
^ permalink raw reply
* Re: Git bisect does not find commit introducing the bug
From: Stephan Beyer @ 2017-02-17 23:21 UTC (permalink / raw)
To: Alex Hoffman, git
In-Reply-To: <CAMX8fZWe2HO78ySonHX0adtPUxVPbj5_vo-NUGrjwpb7gPdGrQ@mail.gmail.com>
Hi,
On 02/17/2017 11:29 PM, Alex Hoffman wrote:
> According to the documentation "git bisect" is designed "to find the
> commit that introduced a bug" .
> I have found a situation in which it does not returns the commit I expected.
> In order to reproduce the problem:
For the others who are too lazy to clone your repo and run the scripts,
the history is like that (read from bottom to top) and I marked the
commit found by git bisect and the on you expected:
* 7a9e952 (bisect bad) <BAD>
|\
| * 671cec2 <BAD> <--- expected
| |\
| * | 04c6f4b <BAD> <--- found
* | | 3915157 <GOOD>
|\ \ \
| | |/
| |/|
| * | f4154e9 (bisect good) <GOOD>
| * | 85855bf <BAD>
| |/
* | f1a36f5 <BAD>
|/
* 1b7fb88 <BAD>
The <BAD> and <GOOD> markers are set by your definition of what good and
what bad commits are.
> First of all this is confusing, as this commit cannot be reached
> starting from "v.good".
Hm, IMHO it shows that your example is pretty artificial (although you
might have come across it in a real-world scenario): you introduced a
new feature in f4154e9 (and it worked) and you broke that feature by
making the merge 671cec2. However, the feature (that broke in 671cec2)
did not even exist in 04c6f4b; so a test on the feature would not fail
(leading to "bisect bad" as in the example), it would not exist (leading
to "bisect skip").
And if we are not talking about passing or failing tests but about
crashing, bisect finds the right thing: f4154e9 was not crashing, but
04c6f4b is crashing. Yes, it's not the commit that introduced the crash
(which would be the first commit in the repo) but it's the first
crashing commit after the one marked as good.
So I'd consider this a feature or rather correct behavior, not a bug.
In other words: bisect assumes that your repo is usually in a good state
and you have a commit that changes it to a bad state. In your case you
have a repo that is in a bad state and you have a commit that switches
it to a good state and later you merge a bad-state branch and you have a
bad state again. It is not made for that use-case, I think.
Cheers
Stephan
^ permalink raw reply
* Re: [PATCH v5 0/6] stash: support pathspec argument
From: Junio C Hamano @ 2017-02-17 23:14 UTC (permalink / raw)
To: Thomas Gummerer
Cc: git, Jeff King, Johannes Schindelin, Øyvind A . Holm,
Jakub Narębski, Matthieu Moy
In-Reply-To: <20170217231246.GI652@hank>
Thomas Gummerer <t.gummerer@gmail.com> writes:
> On 02/17, Junio C Hamano wrote:
>> Thomas Gummerer <t.gummerer@gmail.com> writes:
>>
>> [some people may see this message twice, as I forgot to check if the
>> copy I received had "Some A . Body" not enclosed in dq; blindly
>> doing "Reply-All" ended up listing an invalid address on my Cc: line
>> and dropped by vger. apologies]
>>
>> > diff --git a/git-stash.sh b/git-stash.sh
>> > index a184b1e274..1446fbe2e8 100755
>> > --- a/git-stash.sh
>> > +++ b/git-stash.sh
>> > @@ -67,51 +67,20 @@ create_stash () {
>> > case "$1" in
>> > -m|--message)
>> > shift
>> > - test -z ${1+x} && usage
>> > - stash_msg="$1"
>> > - new_style=t
>> > + stash_msg=${1-"BUG: create_stash () -m requires an argument"}
>> > ;;
>>
>> Did you mean ${1?"BUG: ..."} here and also "-u" below?
>
> Yeah, shell scripts are still confusing me sometimes. Thanks for
> catching. Would you mind fixing this up while queuing or do you want
> me to resend?
I'll fix it up myself (please remind me if you notice that I forgot ;-).
^ permalink raw reply
* [ANNOUNCE] Git v2.12.0-rc2
From: Junio C Hamano @ 2017-02-17 23:12 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
A release candidate Git v2.12.0-rc2 is now available for testing
at the usual places. It is comprised of 487 non-merge commits
since v2.11.0, contributed by 67 people, 21 of which are new faces.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/testing/
The following public repositories all have a copy of the
'v2.12.0-rc2' tag and the 'master' branch that the tag points at:
url = https://kernel.googlesource.com/pub/scm/git/git
url = git://repo.or.cz/alt-git.git
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
New contributors whose contributions weren't in v2.11.0 are as follows.
Welcome to the Git development community!
Alan Davies, Andreas Krey, Cornelius Weig, David Pursehouse,
Denton Liu, George Vanburgh, Igor Kushnir, Jack Bates,
Kristoffer Haugsbakk, Kyle Meyer, Luis Ressel, Lukas Puehringer,
Markus Hitter, Peter Law, Rasmus Villemoes, Rogier Goossens,
Stefan Dotterweich, Steven Penny, Vinicius Kursancew, Vladimir
Panteleev, and Wolfram Sang.
Returning contributors who helped this release are as follows.
Thanks for your continued support.
마누엘, Alex Henrie, Beat Bolli, Brandon Williams, brian
m. carlson, Chris Packham, Christian Couder, David Aguilar, David
Turner, Dennis Kaarsemaker, Dimitriy Ryazantcev, Elia Pinto,
Eric Wong, Heiko Voigt, Jacob Keller, Jeff Hostetler, Jeff King,
Johannes Schindelin, Johannes Sixt, Jonathan Tan, Junio C Hamano,
Kyle J. McKay, Lars Schneider, Linus Torvalds, Luke Diamand, Matt
McCutchen, Max Kirillov, Mike Hommey, Nguyễn Thái Ngọc Duy,
Patrick Steinhardt, Paul Mackerras, Philip Oakley, Pranit Bauva,
Ramsay Jones, René Scharfe, Richard Hansen, Santiago Torres,
Satoshi Yasushima, Stefan Beller, Stephan Beyer, SZEDER Gábor,
Thomas Gummerer, Torsten Bögershausen, Vasco Almeida, Vegard
Nossum, and Vitaly "_Vi" Shukela.
----------------------------------------------------------------
Git 2.12 Release Notes (draft)
==============================
Backward compatibility notes.
* Use of an empty string that is used for 'everything matches' is
still warned and Git asks 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. That
is not scheduled to happen in the upcoming release (yet).
* The historical argument order "git merge <msg> HEAD <commit>..."
has been deprecated for quite some time, and will be removed in a
future release.
* An ancient script "git relink" has been removed.
Updates since v2.11
-------------------
UI, Workflows & Features
* Various updates to "git p4".
* "git p4" didn't interact with the internal of .git directory
correctly in the modern "git-worktree"-enabled world.
* "git branch --list" and friends learned "--ignore-case" option to
optionally sort branches and tags case insensitively.
* In addition to %(subject), %(body), "log --pretty=format:..."
learned a new placeholder %(trailers).
* "git rebase" learned "--quit" option, which allows a user to
remove the metadata left by an earlier "git rebase" that was
manually aborted without using "git rebase --abort".
* "git clone --reference $there --recurse-submodules $super" has been
taught to guess repositories usable as references for submodules of
$super that are embedded in $there while making a clone of the
superproject borrow objects from $there; extend the mechanism to
also allow submodules of these submodules to borrow repositories
embedded in these clones of the submodules embedded in the clone of
the superproject.
* Porcelain scripts written in Perl are getting internationalized.
* "git merge --continue" has been added as a synonym to "git commit"
to conclude a merge that has stopped due to conflicts.
* Finer-grained control of what protocols are allowed for transports
during clone/fetch/push have been enabled via a new configuration
mechanism.
* "git shortlog" learned "--committer" option to group commits by
committer, instead of author.
* GitLFS integration with "git p4" has been updated.
* The isatty() emulation for Windows has been updated to eradicate
the previous hack that depended on internals of (older) MSVC
runtime.
* 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.
* "git grep" has been taught to optionally recurse into submodules.
* "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).
* A recent updates to "git p4" was not usable for older p4 but it
could be made to work with minimum changes. Do so.
* "git diff" learned diff.interHunkContext configuration variable
that gives the default value for its --inter-hunk-context option.
* 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).
* "git submodule push" learned "--recurse-submodules=only option to
push submodules out without pushing the top-level superproject.
* "git tag" and "git verify-tag" learned to put GPG verification
status in their "--format=<placeholders>" output format.
* An ancient repository conversion tool left in contrib/ has been
removed.
* "git show-ref HEAD" used with "--verify" because the user is not
interested in seeing refs/remotes/origin/HEAD, and used with
"--head" because the user does not want HEAD to be filtered out,
i.e. "git show-ref --head --verify HEAD", did not work as expected.
* "git submodule add" used to be confused and refused to add a
locally created repository; users can now use "--force" option
to add them.
(merge 619acfc78c sb/submodule-add-force later to maint).
* 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.
* "git read-tree" and its underlying unpack_trees() machinery learned
to report problematic paths prefixed with the --super-prefix option.
* When a submodule "A", which has another submodule "B" nested within
it, is "absorbed" into the top-level superproject, the inner
submodule "B" used to be left in a strange state. The logic to
adjust the .git pointers in these submodules has been corrected.
* The user can specify a custom update method that is run when
"submodule update" updates an already checked out submodule. This
was ignored when checking the submodule out for the first time and
we instead always just checked out the commit that is bound to the
path in the superproject's index.
* The command line completion (in contrib/) learned that
"git diff --submodule=" can take "diff" as a recently added option.
* The "core.logAllRefUpdates" that used to be boolean has been
enhanced to take 'always' as well, to record ref updates to refs
other than the ones that are expected to be updated (i.e. branches,
remote-tracking branches and notes).
* Comes with more command line completion (in contrib/) for recently
introduced options.
Performance, Internal Implementation, Development Support etc.
* Commands that operate on a log message and add lines to the trailer
blocks, such as "format-patch -s", "cherry-pick (-x|-s)", and
"commit -s", have been taught to use the logic of and share the
code with "git interpret-trailer".
* The default Travis-CI configuration specifies newer P4 and GitLFS.
* The "fast hash" that had disastrous performance issues in some
corner cases has been retired from the internal diff.
* The character width table has been updated to match Unicode 9.0
* Update the procedure to generate "tags" for developer support.
* The codeflow of setting NOATIME and CLOEXEC on file descriptors Git
opens has been simplified.
* "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.
* 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.
* "git push \\server\share\dir" has recently regressed and then
fixed. A test has retroactively been added for this breakage.
* Build updates for Cygwin.
* 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.
* Adjust documentation to help AsciiDoctor render better while not
breaking the rendering done by AsciiDoc.
* The sequencer machinery has been further enhanced so that a later
set of patches can start using it to reimplement "rebase -i".
* Update the definition of the MacOSX test environment used by
TravisCI.
* Rewrite a scripted porcelain "git difftool" in C.
* "make -C t failed" will now run only the tests that failed in the
previous run. This is usable only when prove is not use, and gives
a useless error message when run after "make clean", but otherwise
is serviceable.
* "uchar [40]" to "struct object_id" conversion continues.
Also contains various documentation updates and code clean-ups.
Fixes since v2.10
-----------------
Unless otherwise noted, all the fixes since v2.9 in the maintenance
track are contained in this release (see the maintenance releases'
notes for details).
* We often decide if a session is interactive by checking if the
standard I/O streams are connected to a TTY, but isatty() that
comes with Windows incorrectly returned true if it is used on NUL
(i.e. an equivalent to /dev/null). This has been fixed.
* "git svn" did not work well with path components that are "0", and
some configuration variable it uses were not documented.
* "git rev-parse --symbolic" failed with a more recent notation like
"HEAD^-1" and "HEAD^!".
* An empty directory in a working tree that can simply be nuked used
to interfere while merging or cherry-picking a change to create a
submodule directory there, which has been fixed..
* 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.
* "git push --dry-run --recurse-submodule=on-demand" wasn't
"--dry-run" in the submodules.
* The output from "git worktree list" was made in readdir() order,
and was unstable.
* mergetool.<tool>.trustExitCode configuration variable did not apply
to built-in tools, but now it does.
* "git p4" LFS support was broken when LFS stores an empty blob.
* A corner case in merge-recursive regression that crept in
during 2.10 development cycle has been fixed.
* Transport with dumb http can be fooled into following foreign URLs
that the end user does not intend to, especially with the server
side redirects and http-alternates mechanism, which can lead to
security issues. Tighten the redirection and make it more obvious
to the end user when it happens.
* Update the error messages from the dumb-http client when it fails
to obtain loose objects; we used to give sensible error message
only upon 404 but we now forbid unexpected redirects that needs to
be reported with something sensible.
* When diff.renames configuration is on (and with Git 2.9 and later,
it is enabled by default, which made it worse), "git stash"
misbehaved if a file is removed and another file with a very
similar content is added.
* "git diff --no-index" did not take "--no-abbrev" option.
* "git difftool --dir-diff" had a minor regression when started from
a subdirectory, which has been fixed.
* "git commit --allow-empty --only" (no pathspec) with dirty index
ought to be an acceptable way to create a new commit that does not
change any paths, but it was forbidden, perhaps because nobody
needed it so far.
* Git 2.11 had a minor regression in "merge --ff-only" that competed
with another process that simultanously attempted to update the
index. We used to explain what went wrong with an error message,
but the new code silently failed. The error message has been
resurrected.
* A pathname that begins with "//" or "\\" on Windows is special but
path normalization logic was unaware of it.
* "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.
* The way to specify hotkeys to "xxdiff" that is used by "git
mergetool" has been modernized to match recent versions of xxdiff.
* Unlike "git am --abort", "git cherry-pick --abort" moved HEAD back
to where cherry-pick started while picking multiple changes, when
the cherry-pick stopped to ask for help from the user, and the user
did "git reset --hard" to a different commit in order to re-attempt
the operation.
* Code cleanup in shallow boundary computation.
* A recent update to receive-pack to make it easier to drop garbage
objects made it clear that GIT_ALTERNATE_OBJECT_DIRECTORIES cannot
have a pathname with a colon in it (no surprise!), and this in turn
made it impossible to push into a repository at such a path. This
has been fixed by introducing a quoting mechanism used when
appending such a path to the colon-separated list.
* The function usage_msg_opt() has been updated to say "fatal:"
before the custom message programs give, when they want to die
with a message about wrong command line options followed by the
standard usage string.
* "git index-pack --stdin" needs an access to an existing repository,
but "git index-pack file.pack" to generate an .idx file that
corresponds to a packfile does not.
* Fix for NDEBUG builds.
* 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.
* "git p4" misbehaved when swapping a directory and a symbolic link.
* 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.
* "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.
* A potential but unlikely buffer overflow in Windows port has been
fixed.
* 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.
* 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.
* "git fast-import" sometimes mishandled while rebalancing notes
tree, which has been fixed.
* Recent update to the default abbreviation length that auto-scales
lacked documentation update, which has been corrected.
* Leakage of lockfiles in the config subsystem has been fixed.
* 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".
* "git archive" did not read the standard configuration files, and
failed to notice a file that is marked as binary via the userdiff
driver configuration.
* "git blame --porcelain" misidentified the "previous" <commit, path>
pair (aka "source") when contents came from two or more files.
* "git rebase -i" with a recent update started showing an incorrect
count when squashing more than 10 commits.
* "git <cmd> @{push}" on a detached HEAD used to segfault; it has
been corrected to error out with a message.
* Running "git add a/b" when "a" is a submodule correctly errored
out, but without a meaningful error message.
(merge 2d81c48fa7 sb/pathspec-errors later to maint).
* Typing ^C to pager, which usually does not kill it, killed Git and
took the pager down as a collateral damage in certain process-tree
structure. This has been fixed.
* "git mergetool" without any pathspec on the command line that is
run from a subdirectory became no-op in Git v2.11 by mistake, which
has been fixed.
* Retire long unused/unmaintained gitview from the contrib/ area.
(merge 3120925c25 sb/remove-gitview later to maint).
* Tighten a test to avoid mistaking an extended ERE regexp engine as
a PRE regexp engine.
* An error message with an ASCII control character like '\r' in it
can alter the message to hide its early part, which is problematic
when a remote side gives such an error message that the local side
will relay with a "remote: " prefix.
(merge f290089879 jk/vreport-sanitize later to maint).
* "git fsck" inspects loose objects more carefully now.
(merge cce044df7f jk/loose-object-fsck later to maint).
* A crashing bug introduced in v2.11 timeframe has been found (it is
triggerable only in fast-import) and fixed.
(merge abd5a00268 jk/clear-delta-base-cache-fix later to maint).
* With an anticipatory tweak for remotes defined in ~/.gitconfig
(e.g. "remote.origin.prune" set to true, even though there may or
may not actually be "origin" remote defined in a particular Git
repository), "git remote rename" and other commands misinterpreted
and behaved as if such a non-existing remote actually existed.
(merge e459b073fb js/remote-rename-with-half-configured-remote later to maint).
* A few codepaths had to rely on a global variable when sorting
elements of an array because sort(3) API does not allow extra data
to be passed to the comparison function. Use qsort_s() when
natively available, and a fallback implementation of it when not,
to eliminate the need, which is a prerequisite for making the
codepath reentrant.
* "git fsck --connectivity-check" was not working at all.
(merge a2b22854bd jk/fsck-connectivity-check-fix later to maint).
* After starting "git rebase -i", which first opens the user's editor
to edit the series of patches to apply, but before saving the
contents of that file, "git status" failed to show the current
state (i.e. you are in an interactive rebase session, but you have
applied no steps yet) correctly.
(merge df9ded4984 js/status-pre-rebase-i later to maint).
* Test tweak for FreeBSD where /usr/bin/unzip is unsuitable to run
our tests but /usr/local/bin/unzip is usable.
(merge d98b2c5fce js/unzip-in-usr-bin-workaround later to maint).
* "git p4" did not work well with multiple git-p4.mapUser entries on
Windows.
(merge c3c2b05776 gv/mingw-p4-mapuser later to maint).
* "git help" enumerates executable files in $PATH; the implementation
of "is this file executable?" on Windows has been optimized.
(merge c755015f79 hv/mingw-help-is-executable later to maint).
* Test tweaks for those who have default ACL in their git source tree
that interfere with the umask test.
(merge d549d21307 mm/reset-facl-before-umask-test later to maint).
* Names of the various hook scripts must be spelled exactly, but on
Windows, an .exe binary must be named with .exe suffix; notice
$GIT_DIR/hooks/<hookname>.exe as a valid <hookname> hook.
(merge 235be51fbe js/mingw-hooks-with-exe-suffix later to maint).
* Asciidoctor, an alternative reimplementation of AsciiDoc, still
needs some changes to work with documents meant to be formatted
with AsciiDoc. "make USE_ASCIIDOCTOR=YesPlease" to use it out of
the box to document our pages is getting closer to reality.
* Correct command line completion (in contrib/) on "git svn"
(merge 2cbad17642 ew/complete-svn-authorship-options later to maint).
* Incorrect usage help message for "git worktree prune" has been fixed.
(merge 2488dcab22 ps/worktree-prune-help-fix later to maint).
* Adjust a perf test to new world order where commands that do
require a repository are really strict about having a repository.
(merge c86000c1a7 rs/p5302-create-repositories-before-tests later to maint).
* "git log --graph" did not work well with "--name-only", even though
other forms of "diff" output were handled correctly.
(merge f5022b5fed jk/log-graph-name-only later to maint).
* The push-options given via the "--push-options" option were not
passed through to external remote helpers such as "smart HTTP" that
are invoked via the transport helper.
* The documentation explained what "git stash" does to the working
tree (after stashing away the local changes) in terms of "reset
--hard", which was exposing an unnecessary implementation detail.
(merge 20a7e06172 tg/stash-doc-cleanup later to maint).
* 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.
(merge a8b05162e8 ls/p4-path-encoding later to maint).
* A new coccinelle rule that catches a check of !pointer before the
pointer is free(3)d, which most likely is a bug.
(merge ec6cd14c7a rs/cocci-check-free-only-null later to maint).
* "ls-files" run with pathspec has been micro-optimized to avoid
having to memmove(3) unnecessary bytes.
(merge 96f6d3f61a rs/ls-files-partial-optim later to maint).
* A hotfix for a topic already in 'master'.
(merge a4d92d579f js/mingw-isatty later to maint).
* Other minor doc, test and build updates and code cleanups.
(merge f2627d9b19 sb/submodule-config-cleanup later to maint).
(merge 384f1a167b sb/unpack-trees-cleanup later to maint).
(merge 874444b704 rh/diff-orderfile-doc later to maint).
(merge eafd5d9483 cw/doc-sign-off later to maint).
(merge 0aaad415bc rs/absolute-pathdup later to maint).
(merge 4432dd6b5b rs/receive-pack-cleanup later to maint).
(merge 540a398e9c sg/mailmap-self later to maint).
(merge 209df269a6 nd/rev-list-all-includes-HEAD-doc later to maint).
(merge 941b9c5270 sb/doc-unify-bottom later to maint).
(merge 2aaf37b62c jk/doc-remote-helpers-markup-fix later to maint).
(merge e91461b332 jk/doc-submodule-markup-fix later to maint).
(merge 8ab9740d9f dp/submodule-doc-markup-fix later to maint).
(merge 0838cbc22f jk/tempfile-ferror-fclose-confusion later to maint).
^ permalink raw reply
* Re: [PATCH v5 0/6] stash: support pathspec argument
From: Thomas Gummerer @ 2017-02-17 23:12 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Johannes Schindelin, Øyvind A . Holm,
Jakub Narębski, Matthieu Moy
In-Reply-To: <xmqqfujcpgky.fsf@gitster.mtv.corp.google.com>
On 02/17, Junio C Hamano wrote:
> Thomas Gummerer <t.gummerer@gmail.com> writes:
>
> [some people may see this message twice, as I forgot to check if the
> copy I received had "Some A . Body" not enclosed in dq; blindly
> doing "Reply-All" ended up listing an invalid address on my Cc: line
> and dropped by vger. apologies]
>
> > diff --git a/git-stash.sh b/git-stash.sh
> > index a184b1e274..1446fbe2e8 100755
> > --- a/git-stash.sh
> > +++ b/git-stash.sh
> > @@ -67,51 +67,20 @@ create_stash () {
> > case "$1" in
> > -m|--message)
> > shift
> > - test -z ${1+x} && usage
> > - stash_msg="$1"
> > - new_style=t
> > + stash_msg=${1-"BUG: create_stash () -m requires an argument"}
> > ;;
>
> Did you mean ${1?"BUG: ..."} here and also "-u" below?
Yeah, shell scripts are still confusing me sometimes. Thanks for
catching. Would you mind fixing this up while queuing or do you want
me to resend?
> > -u|--include-untracked)
> > shift
> > - test -z ${1+x} && usage
> > - untracked="$1"
> > - new_style=t
> > + untracked=${1-"BUG: create_stash () -u requires an argument"}
> > ;;
>
> Other than that the whole series looked sensible to me.
>
> Thanks, will replace but that may not happen today.
Thanks!
^ permalink raw reply
* Re: body-CC-comment regression
From: Junio C Hamano @ 2017-02-17 23:04 UTC (permalink / raw)
To: Johan Hovold; +Cc: Matthieu Moy, git, Jeff King, Kevin Daudt, Larry Finger
In-Reply-To: <xmqqbmu0qwyg.fsf@gitster.mtv.corp.google.com>
Junio C Hamano <gitster@pobox.com> writes:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> That approach may still constrain what those in the former camp can
>>> write in the "cruft" part, like they cannot write comma or semicolon
>>> as part of the "cruft", no?
>>
>> Right. Indeed, this may be a problem since the use of "#" for stable
>> seem to include commit message, and they may contain commas.
>>
>> So, maybe Johan's patch is better indeed.
>
> OK, so I'll queue that one with your Ack for now so that we won't
> forget. I guess we still want a few tests?
It seems that there is an expectation in one of the tests that needs
to be adjusted.
^ permalink raw reply
* Re: [PATCH v5 0/6] stash: support pathspec argument
From: Junio C Hamano @ 2017-02-17 23:01 UTC (permalink / raw)
To: Thomas Gummerer
Cc: git, Jeff King, Johannes Schindelin, Øyvind A . Holm,
Jakub Narębski, Matthieu Moy
In-Reply-To: <20170217224141.19183-1-t.gummerer@gmail.com>
Thomas Gummerer <t.gummerer@gmail.com> writes:
[some people may see this message twice, as I forgot to check if the
copy I received had "Some A . Body" not enclosed in dq; blindly
doing "Reply-All" ended up listing an invalid address on my Cc: line
and dropped by vger. apologies]
> diff --git a/git-stash.sh b/git-stash.sh
> index a184b1e274..1446fbe2e8 100755
> --- a/git-stash.sh
> +++ b/git-stash.sh
> @@ -67,51 +67,20 @@ create_stash () {
> case "$1" in
> -m|--message)
> shift
> - test -z ${1+x} && usage
> - stash_msg="$1"
> - new_style=t
> + stash_msg=${1-"BUG: create_stash () -m requires an argument"}
> ;;
Did you mean ${1?"BUG: ..."} here and also "-u" below?
> -u|--include-untracked)
> shift
> - test -z ${1+x} && usage
> - untracked="$1"
> - new_style=t
> + untracked=${1-"BUG: create_stash () -u requires an argument"}
> ;;
Other than that the whole series looked sensible to me.
Thanks, will replace but that may not happen today.
^ permalink raw reply
* Re: [PATCH] submodule.c: Add missing quotation marks
From: Brandon Williams @ 2017-02-17 23:07 UTC (permalink / raw)
To: Phillip Sz; +Cc: git, sbeller
In-Reply-To: <20170217230433.23336-1-phillip.szelat@gmail.com>
On 02/18, Phillip Sz wrote:
> Hi,
>
> just found this while translating, sorry if this is intended.
>
> Best regards,
>
> Phillip
Definitely not intended. Thanks for catching that.
> ---
> submodule.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/submodule.c b/submodule.c
> index 3b98766a6..b064ed080 100644
> --- a/submodule.c
> +++ b/submodule.c
> @@ -1181,7 +1181,7 @@ int bad_to_remove_submodule(const char *path, unsigned flags)
> cp.dir = path;
> if (start_command(&cp)) {
> if (flags & SUBMODULE_REMOVAL_DIE_ON_ERROR)
> - die(_("could not start 'git status in submodule '%s'"),
> + die(_("could not start 'git status' in submodule '%s'"),
> path);
> ret = -1;
> goto out;
> @@ -1194,7 +1194,7 @@ int bad_to_remove_submodule(const char *path, unsigned flags)
>
> if (finish_command(&cp)) {
> if (flags & SUBMODULE_REMOVAL_DIE_ON_ERROR)
> - die(_("could not run 'git status in submodule '%s'"),
> + die(_("could not run 'git status' in submodule '%s'"),
> path);
> ret = -1;
> }
> --
> 2.11.1
>
--
Brandon Williams
^ permalink raw reply
* [PATCH] submodule.c: Add missing quotation marks
From: Phillip Sz @ 2017-02-17 23:04 UTC (permalink / raw)
To: git; +Cc: sbeller, Phillip Sz
Hi,
just found this while translating, sorry if this is intended.
Best regards,
Phillip
---
submodule.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/submodule.c b/submodule.c
index 3b98766a6..b064ed080 100644
--- a/submodule.c
+++ b/submodule.c
@@ -1181,7 +1181,7 @@ int bad_to_remove_submodule(const char *path, unsigned flags)
cp.dir = path;
if (start_command(&cp)) {
if (flags & SUBMODULE_REMOVAL_DIE_ON_ERROR)
- die(_("could not start 'git status in submodule '%s'"),
+ die(_("could not start 'git status' in submodule '%s'"),
path);
ret = -1;
goto out;
@@ -1194,7 +1194,7 @@ int bad_to_remove_submodule(const char *path, unsigned flags)
if (finish_command(&cp)) {
if (flags & SUBMODULE_REMOVAL_DIE_ON_ERROR)
- die(_("could not run 'git status in submodule '%s'"),
+ die(_("could not run 'git status' in submodule '%s'"),
path);
ret = -1;
}
--
2.11.1
^ permalink raw reply related
* Re: [PATCH v5 0/6] stash: support pathspec argument
From: Thomas Gummerer @ 2017-02-17 23:06 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Johannes Schindelin, Øyvind A . Holm,
Jakub Narębski, Matthieu Moy
In-Reply-To: <xmqqr32wph97.fsf@gitster.mtv.corp.google.com>
On 02/17, Junio C Hamano wrote:
> Thomas Gummerer <t.gummerer@gmail.com> writes:
>
> > Thanks Matthieu, Peff and Junio for the discussion on v3 and v4.
> >
> > Changes since v4:
> > Dropped patch 1 from the series, as it's already in master
> >
> > Instead of changing the external interface to git stash create, only
> > refactor the internal create_stash() function to take -m and -u
> > arguments. This also simplifies the internal option parsing.
>
> Yay.
>
> > Make git stash -p an alias for git stash push -p, so git stash -p
> > <pathspec> is allowed.
>
> Nice.
>
> >
> > Interdiff below:
> >
> > diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
> > index b0825f4aca..97194576ef 100644
> > --- a/Documentation/git-stash.txt
> > +++ b/Documentation/git-stash.txt
> > @@ -53,9 +53,8 @@ OPTIONS
> > save [-p|--patch] [-k|--[no-]keep-index] [-u|--include-untracked] [-a|--all] [-q|--quiet] [<message>]::
> > push [-p|--patch] [-k|--[no-]keep-index] [-u|--include-untracked] [-a|--all] [-q|--quiet] [-m|--message <message>] [--] [<pathspec>...]::
> >
> > - Save your local modifications to a new 'stash' and roll them
> > - back to HEAD (in the working tree and in the index).
> > - The <message> part is optional and gives
> > + Save your local modifications to a new 'stash', and run `git reset
> > + --hard` to revert them. The <message> part is optional and gives
> > the description along with the stashed state. For quickly making
> > a snapshot, you can omit _both_ "save" and <message>, but giving
> > only <message> does not trigger this action to prevent a misspelled
> > diff --git a/git-stash.sh b/git-stash.sh
> > index a184b1e274..1446fbe2e8 100755
> > --- a/git-stash.sh
> > +++ b/git-stash.sh
> > @@ -67,51 +67,20 @@ create_stash () {
> > case "$1" in
> > -m|--message)
> > shift
> > - test -z ${1+x} && usage
> > - stash_msg="$1"
> > - new_style=t
> > + stash_msg=${1-"BUG: create_stash () -m requires an argument"}
>
> Hmph, did you mean ${1?"BUG: ..."}? The same for the one in "-u".
Ah yes sorry, you're right course. Thanks.
^ permalink raw reply
* Re: dotfiles in git template dir are not copied
From: Junio C Hamano @ 2017-02-17 22:56 UTC (permalink / raw)
To: Grégoire PARIS; +Cc: Jeff King, git
In-Reply-To: <2bae8d8a-f0bf-fa8b-8ce4-6880d3490b43@greg0ire.fr>
Grégoire PARIS <postmaster@greg0ire.fr> writes:
>> You could, for example, have your template directory itself be a git
> repository.
>
> I can and I do and indeed, that might be the reason behind this.
> I made a PR to document this : https://github.com/git/git/pull/325
Let's take a look.
> From: Grégoire PARIS <postmaster@greg0ire.fr>
> Date: Fri, 17 Feb 2017 22:33:40 +0100
> Subject: [PATCH] Document dotfiles exclusion on template copy
>
> Since there is no dotfile in the default template directory, there was
> no point in making the check for . or .. more accurate when copying. Now
> that you can customize the template directory, it would make sense, but
> it's actually a good thing to at this because you would not want to have
> your git directory copied in every git directory that is created should
> you decide to put your template directory under version control. Plus it
> might be used as a feature by people who would want to exclude some
> files.
OK.
> See https://public-inbox.org/git/20170217204411.2yixhuazgczxmmxa@sigill.intra.peff.net/T/#t
I do not think what was discussed there adds much. Drop this line.
Instead, add your sign-off (Documentation/SubmittingPatches) here
Signed-off-by: Grégoire PARIS <postmaster@greg0ire.fr>
> ---
> Documentation/git-init.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt
> index 9d27197de8..e3b185cf86 100644
> --- a/Documentation/git-init.txt
> +++ b/Documentation/git-init.txt
> @@ -117,7 +117,7 @@ TEMPLATE DIRECTORY
> ------------------
>
> The template directory contains files and directories that will be copied to
> -the `$GIT_DIR` after it is created.
> +the `$GIT_DIR` after it is created, unless their name starts with a dot.
"... that will be copied ..., unless they are dot" is not incorrect
per-se, but perhaps rewriting the whole sentence, e.g. "Files and
directories in the template directory whose name do not start with a
dot will be copied to ...", may make it easier to read, I suspect.
^ permalink raw reply
* Re: dotfiles in git template dir are not copied
From: Junio C Hamano @ 2017-02-17 22:44 UTC (permalink / raw)
To: Grégoire PARIS; +Cc: Jeff King, git
In-Reply-To: <9894f34a-d362-7741-b5b8-3743fe8f4e0b@greg0ire.fr>
Grégoire PARIS <postmaster@greg0ire.fr> writes:
>> I do not think we should change the behaviour
>> to copy files whose names begin with a dot.
>
> So bug turned feature it is :)
There was no 'bug' either. It's just the way it is ;-)
^ 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