* Re: 'git submodules update' ignores credential.helper config of the parent repository
From: Jeff King @ 2017-02-28 20:08 UTC (permalink / raw)
To: Stefan Beller; +Cc: Dmitry Neverov, Duy Nguyen, Junio C Hamano, Git List
In-Reply-To: <CAGZ79kb8F9_9fd9uhfPpHVPQj-zm99qt5Tr=3TUhpe=K6JknEg@mail.gmail.com>
On Tue, Feb 28, 2017 at 10:05:24AM -0800, Stefan Beller wrote:
> > I have a feeling that something like this would create unwelcome corner
> > cases in the config-writer, which is otherwise does not have to care
> > about which existing section of a file it adds a key to.
>
> Yeah the writer would become a lot more involved, if we're not going
> the stupid way (add these sections for nearly all keys. that would be
> a mess but easy to implement)
>
> So I guess then we rather settle with multiple config files or a white/blacklist
> of config options to propagate from the superproject to its submodules.
I'm still open to the idea that we simply improve the documentation to
make it clear that per-repo config really is per-repo, and is not shared
between super-projects and submodules. And then something like Duy's
proposed conditional config lets you set global config that flexibly
covers a set of repos.
-Peff
^ permalink raw reply
* Re: [PATCH 0/6] Use time_t
From: Jeff King @ 2017-02-28 20:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <xmqqvarukz0g.fsf@gitster.mtv.corp.google.com>
On Tue, Feb 28, 2017 at 09:26:23AM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > I do not just agree, but I think the move to a signed timestamp is a big
> > improvement. Git's object format is happy to represent times before
> > 1970, but the code is not. I know this has been a pain for people who
> > import ancient histories into Git.
> >
> > It looks from the discussion like the sanest path forward is our own
> > signed-64bit timestamp_t. That's unfortunate compared to using the
> > standard time_t, but hopefully it would reduce the number of knobs (like
> > TIME_T_IS_INT64) in the long run.
>
> Keeping it unsigned is safer in the short-term. There are some
> places that uses 0 as "impossible time" (e.g. somebody tried to
> parse a string as time and returns a failure) and these places need
> to be found and be replaced with probably the most negative value
> that timestamp_t cn represent. Another possible special value we
> may use is for "expiring everything" but I think we tend to just use
> the timestamp of the present time for that purpose and not UONG_MAX,
> so we should be OK there.
Yeah. I think I was the one who invented the "0 is impossible"
convention. We can certainly stick with it for now (it's awkward if you
really do have an entry on Jan 1 1970, but other than that it's an OK
marker). I agree that the most negatively value is probably a saner
choice, but we can switch to it after the dust settles.
> But we need to cross the bridge to signed timestamp sometime, and I
> do not see any reason why that somtime should not be now.
Yep.
-Peff
^ permalink raw reply
* Re: [PATCH 0/6] Use time_t
From: Jeff King @ 2017-02-28 20:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: René Scharfe, Johannes Schindelin, git
In-Reply-To: <xmqqa896kuve.fsf@gitster.mtv.corp.google.com>
On Tue, Feb 28, 2017 at 10:55:49AM -0800, Junio C Hamano wrote:
> > Glibc will get a way to enable 64-bit time_t on 32-bit platforms
> > eventually
> > (https://sourceware.org/glibc/wiki/Y2038ProofnessDesign). Can
> > platforms that won't provide a 64-bit time_t by 2038 be actually used
> > at that point? How would we get time information on them? How would
> > a custom timestamp_t help us?
>
> That's a sensible "wait, let's step back a bit". I take it that you
> are saying "time_t is just fine", and I am inclined to agree.
>
> Right now, they may be able to have future timestamps ranging to
> year 2100 and switching to time_t would limit their ability to
> express future time to 2038 but they would be able to express
> timestamp in the past to cover most of 20th century. Given that
> these 32-bit time_t software platforms will die off before year 2038
> (either by underlying hardware getting obsolete, or software updated
> to handle 64-bit time_t), the (temporary) loss of 2038-2100 range
> would not be too big a deal to warrant additional complexity.
For what it's worth, I'm on board with just using time_t if it reduces
the overall complexity. I agree that the "loss" of far-future timestamp
handling is unlikely to matter between now and 2038, and those systems
will have to figure out their time_t problems by then. By actually using
time_t we get to piggy-back on their solution.
-Peff
^ permalink raw reply
* Re: 'git submodules update' ignores credential.helper config of the parent repository
From: Stefan Beller @ 2017-02-28 20:21 UTC (permalink / raw)
To: Jeff King; +Cc: Dmitry Neverov, Duy Nguyen, Junio C Hamano, Git List
In-Reply-To: <20170228200821.iojdzntjslwgrzcb@sigill.intra.peff.net>
On Tue, Feb 28, 2017 at 12:08 PM, Jeff King <peff@peff.net> wrote:
> On Tue, Feb 28, 2017 at 10:05:24AM -0800, Stefan Beller wrote:
>
>> > I have a feeling that something like this would create unwelcome corner
>> > cases in the config-writer, which is otherwise does not have to care
>> > about which existing section of a file it adds a key to.
>>
>> Yeah the writer would become a lot more involved, if we're not going
>> the stupid way (add these sections for nearly all keys. that would be
>> a mess but easy to implement)
>>
>> So I guess then we rather settle with multiple config files or a white/blacklist
>> of config options to propagate from the superproject to its submodules.
>
> I'm still open to the idea that we simply improve the documentation to
> make it clear that per-repo config really is per-repo, and is not shared
> between super-projects and submodules. And then something like Duy's
> proposed conditional config lets you set global config that flexibly
> covers a set of repos.
How would the workflow for that look like?
My naive thought on that is:
(1) $EDIT .git/config_to_be_included
(2) $ git config add-config-inclusion .git/config_to_be_included
(3) $ git submodule foreach git config add-inclusion-config
.git/config_to_be_included
which sounds a bit cumbersome to me.
So I guess we'd want some parts of that as part of another command, e.g.
(3) could be part of (2).
--
I am also open and willing to document this better; but were would
we want to put documentation? Obviously we would not want to put it
alongside each potentially useful config option to be inherited to
submodules. (that would imply repeating ourselves quite a lot in
the config man page).
I guess putting it into "man gitmodules" that I was writing tentatively
would make sense.
C.f
https://public-inbox.org/git/20161227234310.13264-4-sbeller@google.com/
(or search for "background story" in your emails)
Thanks,
Stefan
^ permalink raw reply
* Re: Typesafer git hash patch
From: Jeff King @ 2017-02-28 20:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: brian m. carlson, Junio C Hamano, Git Mailing List
In-Reply-To: <CA+55aFxYs1zp2c-UPe8EfshNNOxRVxZ2H+ipsnG489NBsE+DLQ@mail.gmail.com>
On Mon, Feb 27, 2017 at 10:59:15PM -0800, Linus Torvalds wrote:
> I saw that somebody is actually looking at doing this "well" - by
> doing it in many smaller steps. I tried. I gave up. The "unsigned char
> *sha1" model is so ingrained that doing it incrementally just seemed
> like a lot of pain. But it might be the right approach.
That somebody is brian carlson, cc'd.
> which is pretty nasty. The good news is that my patch passes all the
> tests, and while it's big it's mostly very very mindless, and a lot of
> it looks like cleanups, and the lines are generally shorter, eg
>
> - const unsigned char *mb = result->item->object.oid.hash;
> - if (!hashcmp(mb, current_bad_oid->hash)) {
>
> turns into
>
> + const hash_t *mb = &result->item->object.oid;
> + if (!hashcmp(mb, current_bad_oid)) {
>
> but I ended up also renaming a lot of common "sha1" as "hash", which
> adds to the noise in that patch.
I think the preimage there is worse than it ought to be because it's
mid-transition. "struct object" has an object_id, but the rest of the
function hasn't been converted yet. So ultimately it should be:
const struct object_id *mb = &result->item->object.oid;
if (!oidcmp(mb, current_bad_oid))
It looks like you stuck your "hash_t" inside "struct object_id", which I
think is redundant. They're both trying to solve the same problem.
> NOTE! It doesn't actually _fix_ the SHA1-centricity in any way, but it
> makes it a bit more obvious where the bigger problems are. Not that
> anybody would be surprised by what they are, but as part of writing
> the patch it did kind of pinpoint most of them, and about 30 of those
> new lines are added
>
> /* FIXME! Hardcoded hash sizes */
> /* FIXME! Lots of fixed-size hashes */
> /* FIXME! Fixed 20-byte hash usage */
Yeah, a lot of brian's patches have been focused around the fixing the
related size assumptions. We've got GIT_SHA1_HEXSZ which doesn't solve
the problem, but at least makes it easy to find. And a big improvement
in the most recent series is a parse_oid() function that lets you parse
object-ids left-to-right without knowing the size up front. So things
like:
if (len > 82 &&
!get_sha1_hex(buf, sha1_a) &&
get_sha1_hex(buf + 41, sha1_b))
becomes more like:
if (parse_oid(p, oid_a, &p) && *p++ == ' ' &&
parse_oid(p, oid_b, &p) && *p++ == '\n')
Still, if you've done more conversion, it's probably worth showing it
publicly. It might not end up used, but it may serve as a reference
later.
> And as part of the type safety, I do think I may have found a bug:
>
> show_one_mergetag():
>
> strbuf_addf(&verify_message, "tag %s names a non-parent %s\n",
> tag->tag, tag->tagged->oid.hash);
>
> note how it prints out the "non-parent %s", but that's a SHA1 hash
> that hasn't been converted to hex. Hmm?
Yeah, that's definitely a bug. I'm surprised that -Wformat doesn't
complain, but I guess we'd need -Wformat-signedness (which triggers
quite a lot of warnings related to "int"). It's especially bad for "%x",
which is implicitly unsigned.
-Peff
^ permalink raw reply
* [PATCH v8 3/6] stash: refactor stash_create
From: Thomas Gummerer @ 2017-02-28 20:33 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, Johannes Schindelin, sunny,
Jakub Narębski, Matthieu Moy, Thomas Gummerer
In-Reply-To: <20170228203340.18723-1-t.gummerer@gmail.com>
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.
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---
git-stash.sh | 22 ++++++++++++++++++----
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/git-stash.sh b/git-stash.sh
index 8365ebba2a..ef5d1b45be 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -58,8 +58,22 @@ clear_stash () {
}
create_stash () {
- stash_msg="$1"
- untracked="$2"
+ stash_msg=
+ untracked=
+ while test $# != 0
+ do
+ case "$1" in
+ -m|--message)
+ shift
+ stash_msg=${1?"BUG: create_stash () -m requires an argument"}
+ ;;
+ -u|--include-untracked)
+ shift
+ untracked=${1?"BUG: create_stash () -u requires an argument"}
+ ;;
+ esac
+ shift
+ done
git update-index -q --refresh
if no_changes
@@ -268,7 +282,7 @@ push_stash () {
git reflog exists $ref_stash ||
clear_stash || die "$(gettext "Cannot initialize stash")"
- create_stash "$stash_msg" $untracked
+ create_stash -m "$stash_msg" -u "$untracked"
store_stash -m "$stash_msg" -q $w_commit ||
die "$(gettext "Cannot save the current status")"
say "$(eval_gettext "Saved working directory and index state \$stash_msg")"
@@ -667,7 +681,7 @@ clear)
;;
create)
shift
- create_stash "$*" && echo "$w_commit"
+ create_stash -m "$*" && echo "$w_commit"
;;
store)
shift
--
2.12.0.428.g67fe103aa
^ permalink raw reply related
* Re: Typesafer git hash patch
From: brian m. carlson @ 2017-02-28 20:33 UTC (permalink / raw)
To: Jeff King; +Cc: Linus Torvalds, Junio C Hamano, Git Mailing List
In-Reply-To: <20170228202633.3pxbrnrhot7syiae@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 1165 bytes --]
On Tue, Feb 28, 2017 at 03:26:34PM -0500, Jeff King wrote:
> Yeah, a lot of brian's patches have been focused around the fixing the
> related size assumptions. We've got GIT_SHA1_HEXSZ which doesn't solve
> the problem, but at least makes it easy to find. And a big improvement
> in the most recent series is a parse_oid() function that lets you parse
> object-ids left-to-right without knowing the size up front. So things
> like:
>
> if (len > 82 &&
> !get_sha1_hex(buf, sha1_a) &&
> get_sha1_hex(buf + 41, sha1_b))
>
> becomes more like:
>
> if (parse_oid(p, oid_a, &p) && *p++ == ' ' &&
> parse_oid(p, oid_b, &p) && *p++ == '\n')
What I could do instead of using GIT_SHA1_HEXSZ is use GIT_MAX_HEXSZ for
things that are about allocating enough memory and create a global (or
function) for things that only care about what the current hash size is.
That might be a desirable approach. If other people agree, I can make a
patch to do that.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 868 bytes --]
^ permalink raw reply
* [PATCH v8 6/6] stash: allow pathspecs in the no verb form
From: Thomas Gummerer @ 2017-02-28 20:33 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, Johannes Schindelin, sunny,
Jakub Narębski, Matthieu Moy, Thomas Gummerer
In-Reply-To: <20170228203340.18723-1-t.gummerer@gmail.com>
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.
Also make git stash -p an alias for git stash push -p. This allows
users to use git stash -p <pathspec>.
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---
Documentation/git-stash.txt | 11 +++++++----
git-stash.sh | 3 +++
t/t3903-stash.sh | 15 +++++++++++++++
3 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 4d8d30f179..70191d06b6 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -54,10 +54,13 @@ push [-p|--patch] [-k|--[no-]keep-index] [-u|--include-untracked] [-a|--all] [-q
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
- 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
- subcommand from making an unwanted stash.
+ the description along with the stashed state.
++
+For quickly making a snapshot, you can omit "push". In this mode,
+non-option arguments are not allowed to prevent a misspelled
+subcommand from making an unwanted stash. The two exceptions to this
+are `stash -p` which acts as alias for `stash push -p` and pathspecs,
+which are allowed after a double hyphen `--` for disambiguation.
+
When pathspec is given to 'git stash push', the new stash records the
modified states only for the files that match the pathspec. The index
diff --git a/git-stash.sh b/git-stash.sh
index f3c2f86804..207c8126f4 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -657,12 +657,15 @@ apply_to_branch () {
}
}
+test "$1" = "-p" && set "push" "$@"
+
PARSE_CACHE='--not-parsed'
# The default command is "push" if nothing but options are given
seen_non_option=
for opt
do
case "$opt" in
+ --) break ;;
-*) ;;
*) seen_non_option=t; break ;;
esac
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index e875fe8259..89877e4b52 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -892,4 +892,19 @@ test_expect_success 'untracked files are left in place when -u is not given' '
test_path_is_file untracked
'
+test_expect_success 'stash without verb with pathspec' '
+ >"foo bar" &&
+ >foo &&
+ >bar &&
+ git add foo* &&
+ git stash -- "foo b*" &&
+ test_path_is_missing "foo bar" &&
+ test_path_is_file foo &&
+ test_path_is_file bar &&
+ git stash pop &&
+ test_path_is_file "foo bar" &&
+ test_path_is_file foo &&
+ test_path_is_file bar
+'
+
test_done
--
2.12.0.428.g67fe103aa
^ permalink raw reply related
* [PATCH v8 1/6] stash: introduce push verb
From: Thomas Gummerer @ 2017-02-28 20:33 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, Johannes Schindelin, sunny,
Jakub Narębski, Matthieu Moy, Thomas Gummerer
In-Reply-To: <20170228203340.18723-1-t.gummerer@gmail.com>
Introduce a new git stash push verb in addition to git stash save. The
push verb is used to transition from the current command line arguments
to a more conventional way, in which the message is given as an argument
to the -m option.
This allows us to have pathspecs at the end of the command line
arguments like other Git commands do, so that the user can say which
subset of paths to stash (and leave others behind).
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---
Documentation/git-stash.txt | 3 +++
git-stash.sh | 46 ++++++++++++++++++++++++++++++++++++++++++---
t/t3903-stash.sh | 9 +++++++++
3 files changed, 55 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 2e9e344cd7..d240df4af7 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -15,6 +15,8 @@ SYNOPSIS
'git stash' branch <branchname> [<stash>]
'git stash' [save [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet]
[-u|--include-untracked] [-a|--all] [<message>]]
+'git stash' push [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet]
+ [-u|--include-untracked] [-a|--all] [-m|--message <message>]]
'git stash' clear
'git stash' create [<message>]
'git stash' store [-m|--message <message>] [-q|--quiet] <commit>
@@ -46,6 +48,7 @@ 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>]::
Save your local modifications to a new 'stash' and roll them
back to HEAD (in the working tree and in the index).
diff --git a/git-stash.sh b/git-stash.sh
index 10c284d1aa..8365ebba2a 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -9,6 +9,8 @@ USAGE="list [<options>]
or: $dashless branch <branchname> [<stash>]
or: $dashless [save [--patch] [-k|--[no-]keep-index] [-q|--quiet]
[-u|--include-untracked] [-a|--all] [<message>]]
+ or: $dashless push [--patch] [-k|--[no-]keep-index] [-q|--quiet]
+ [-u|--include-untracked] [-a|--all] [-m <message>]
or: $dashless clear"
SUBDIRECTORY_OK=Yes
@@ -189,10 +191,11 @@ store_stash () {
return $ret
}
-save_stash () {
+push_stash () {
keep_index=
patch_mode=
untracked=
+ stash_msg=
while test $# != 0
do
case "$1" in
@@ -216,6 +219,11 @@ save_stash () {
-a|--all)
untracked=all
;;
+ -m|--message)
+ shift
+ test -z ${1+x} && usage
+ stash_msg=$1
+ ;;
--help)
show_help
;;
@@ -251,8 +259,6 @@ save_stash () {
die "$(gettext "Can't use --patch and --include-untracked or --all at the same time")"
fi
- stash_msg="$*"
-
git update-index -q --refresh
if no_changes
then
@@ -291,6 +297,36 @@ save_stash () {
fi
}
+save_stash () {
+ push_options=
+ while test $# != 0
+ do
+ case "$1" in
+ --)
+ shift
+ break
+ ;;
+ -*)
+ # pass all options through to push_stash
+ push_options="$push_options $1"
+ ;;
+ *)
+ break
+ ;;
+ esac
+ shift
+ done
+
+ stash_msg="$*"
+
+ if test -z "$stash_msg"
+ then
+ push_stash $push_options
+ else
+ push_stash $push_options -m "$stash_msg"
+ fi
+}
+
have_stash () {
git rev-parse --verify --quiet $ref_stash >/dev/null
}
@@ -617,6 +653,10 @@ save)
shift
save_stash "$@"
;;
+push)
+ shift
+ push_stash "$@"
+ ;;
apply)
shift
apply_stash "$@"
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index 2de3e18ce6..3577115807 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -775,4 +775,13 @@ test_expect_success 'stash is not confused by partial renames' '
test_path_is_missing file
'
+test_expect_success 'push -m shows right message' '
+ >foo &&
+ git add foo &&
+ git stash push -m "test message" &&
+ echo "stash@{0}: On master: test message" >expect &&
+ git stash list -1 >actual &&
+ test_cmp expect actual
+'
+
test_done
--
2.12.0.428.g67fe103aa
^ permalink raw reply related
* [PATCH v8 4/6] stash: teach 'push' (and 'create_stash') to honor pathspec
From: Thomas Gummerer @ 2017-02-28 20:33 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, Johannes Schindelin, sunny,
Jakub Narębski, Matthieu Moy, Thomas Gummerer
In-Reply-To: <20170228203340.18723-1-t.gummerer@gmail.com>
While working on a repository, it's often helpful to stash the changes
of a single or multiple files, and leave others alone. Unfortunately
git currently offers no such option. git stash -p can be used to work
around this, but it's often impractical when there are a lot of changes
over multiple files.
Allow 'git stash push' to take pathspec to specify which paths to stash.
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---
Documentation/git-stash.txt | 9 +++-
git-stash.sh | 39 +++++++++++-----
t/t3903-stash.sh | 92 ++++++++++++++++++++++++++++++++++++++
t/t3905-stash-include-untracked.sh | 26 +++++++++++
4 files changed, 154 insertions(+), 12 deletions(-)
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index d240df4af7..88369ed8b6 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -17,6 +17,7 @@ SYNOPSIS
[-u|--include-untracked] [-a|--all] [<message>]]
'git stash' push [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet]
[-u|--include-untracked] [-a|--all] [-m|--message <message>]]
+ [--] [<pathspec>...]
'git stash' clear
'git stash' create [<message>]
'git stash' store [-m|--message <message>] [-q|--quiet] <commit>
@@ -48,7 +49,7 @@ 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>]::
+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).
@@ -58,6 +59,12 @@ push [-p|--patch] [-k|--[no-]keep-index] [-u|--include-untracked] [-a|--all] [-q
only <message> does not trigger this action to prevent a misspelled
subcommand from making an unwanted stash.
+
+When pathspec is given to 'git stash push', the new stash records the
+modified states only for the files that match the pathspec. The index
+entries and working tree files are then rolled back to the state in
+HEAD only for these files, too, leaving files that do not match the
+pathspec intact.
++
If the `--keep-index` option is used, all changes already added to the
index are left intact.
+
diff --git a/git-stash.sh b/git-stash.sh
index ef5d1b45be..5892abafa3 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -11,6 +11,7 @@ USAGE="list [<options>]
[-u|--include-untracked] [-a|--all] [<message>]]
or: $dashless push [--patch] [-k|--[no-]keep-index] [-q|--quiet]
[-u|--include-untracked] [-a|--all] [-m <message>]
+ [-- <pathspec>...]
or: $dashless clear"
SUBDIRECTORY_OK=Yes
@@ -35,15 +36,15 @@ else
fi
no_changes () {
- git diff-index --quiet --cached HEAD --ignore-submodules -- &&
- git diff-files --quiet --ignore-submodules &&
+ git diff-index --quiet --cached HEAD --ignore-submodules -- "$@" &&
+ git diff-files --quiet --ignore-submodules -- "$@" &&
(test -z "$untracked" || test -z "$(untracked_files)")
}
untracked_files () {
excl_opt=--exclude-standard
test "$untracked" = "all" && excl_opt=
- git ls-files -o -z $excl_opt
+ git ls-files -o -z $excl_opt -- "$@"
}
clear_stash () {
@@ -71,12 +72,16 @@ create_stash () {
shift
untracked=${1?"BUG: create_stash () -u requires an argument"}
;;
+ --)
+ shift
+ break
+ ;;
esac
shift
done
git update-index -q --refresh
- if no_changes
+ if no_changes "$@"
then
exit 0
fi
@@ -108,7 +113,7 @@ create_stash () {
# Untracked files are stored by themselves in a parentless commit, for
# ease of unpacking later.
u_commit=$(
- untracked_files | (
+ untracked_files "$@" | (
GIT_INDEX_FILE="$TMPindex" &&
export GIT_INDEX_FILE &&
rm -f "$TMPindex" &&
@@ -131,7 +136,7 @@ create_stash () {
git read-tree --index-output="$TMPindex" -m $i_tree &&
GIT_INDEX_FILE="$TMPindex" &&
export GIT_INDEX_FILE &&
- git diff-index --name-only -z HEAD -- >"$TMP-stagenames" &&
+ git diff-index --name-only -z HEAD -- "$@" >"$TMP-stagenames" &&
git update-index -z --add --remove --stdin <"$TMP-stagenames" &&
git write-tree &&
rm -f "$TMPindex"
@@ -145,7 +150,7 @@ create_stash () {
# find out what the user wants
GIT_INDEX_FILE="$TMP-index" \
- git add--interactive --patch=stash -- &&
+ git add--interactive --patch=stash -- "$@" &&
# state of the working tree
w_tree=$(GIT_INDEX_FILE="$TMP-index" git write-tree) ||
@@ -273,27 +278,39 @@ push_stash () {
die "$(gettext "Can't use --patch and --include-untracked or --all at the same time")"
fi
+ test -n "$untracked" || git ls-files --error-unmatch -- "$@" >/dev/null || exit 1
+
git update-index -q --refresh
- if no_changes
+ if no_changes "$@"
then
say "$(gettext "No local changes to save")"
exit 0
fi
+
git reflog exists $ref_stash ||
clear_stash || die "$(gettext "Cannot initialize stash")"
- create_stash -m "$stash_msg" -u "$untracked"
+ create_stash -m "$stash_msg" -u "$untracked" -- "$@"
store_stash -m "$stash_msg" -q $w_commit ||
die "$(gettext "Cannot save the current status")"
say "$(eval_gettext "Saved working directory and index state \$stash_msg")"
if test -z "$patch_mode"
then
- git reset --hard ${GIT_QUIET:+-q}
+ if test $# != 0
+ then
+ git reset ${GIT_QUIET:+-q} -- "$@"
+ git ls-files -z --modified -- "$@" |
+ git checkout-index -z --force --stdin
+ git checkout ${GIT_QUIET:+-q} HEAD -- $(git ls-files -z --modified "$@")
+ git clean --force ${GIT_QUIET:+-q} -d -- "$@"
+ else
+ git reset --hard ${GIT_QUIET:+-q}
+ fi
test "$untracked" = "all" && CLEAN_X_OPTION=-x || CLEAN_X_OPTION=
if test -n "$untracked"
then
- git clean --force --quiet -d $CLEAN_X_OPTION
+ git clean --force --quiet -d $CLEAN_X_OPTION -- "$@"
fi
if test "$keep_index" = "t" && test -n "$i_tree"
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index ffe3549ea5..f934993263 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -802,4 +802,96 @@ test_expect_success 'create with multiple arguments for the message' '
test_cmp expect actual
'
+test_expect_success 'stash -- <pathspec> stashes and restores the file' '
+ >foo &&
+ >bar &&
+ git add foo bar &&
+ git stash push -- foo &&
+ test_path_is_file bar &&
+ test_path_is_missing foo &&
+ git stash pop &&
+ test_path_is_file foo &&
+ test_path_is_file bar
+'
+
+test_expect_success 'stash with multiple pathspec arguments' '
+ >foo &&
+ >bar &&
+ >extra &&
+ git add foo bar extra &&
+ git stash push -- foo bar &&
+ test_path_is_missing bar &&
+ test_path_is_missing foo &&
+ test_path_is_file extra &&
+ git stash pop &&
+ test_path_is_file foo &&
+ test_path_is_file bar &&
+ test_path_is_file extra
+'
+
+test_expect_success 'stash with file including $IFS character' '
+ >"foo bar" &&
+ >foo &&
+ >bar &&
+ git add foo* &&
+ git stash push -- "foo b*" &&
+ test_path_is_missing "foo bar" &&
+ test_path_is_file foo &&
+ test_path_is_file bar &&
+ git stash pop &&
+ test_path_is_file "foo bar" &&
+ test_path_is_file foo &&
+ test_path_is_file bar
+'
+
+test_expect_success 'stash with pathspec matching multiple paths' '
+ echo original >file &&
+ echo original >other-file &&
+ git commit -m "two" file other-file &&
+ echo modified >file &&
+ echo modified >other-file &&
+ git stash push -- "*file" &&
+ echo original >expect &&
+ test_cmp expect file &&
+ test_cmp expect other-file &&
+ git stash pop &&
+ echo modified >expect &&
+ test_cmp expect file &&
+ test_cmp expect other-file
+'
+
+test_expect_success 'stash push -p with pathspec shows no changes only once' '
+ >foo &&
+ git add foo &&
+ git commit -m "tmp" &&
+ git stash push -p foo >actual &&
+ echo "No local changes to save" >expect &&
+ git reset --hard HEAD~ &&
+ test_cmp expect actual
+'
+
+test_expect_success 'stash push with pathspec shows no changes when there are none' '
+ >foo &&
+ git add foo &&
+ git commit -m "tmp" &&
+ git stash push foo >actual &&
+ echo "No local changes to save" >expect &&
+ git reset --hard HEAD~ &&
+ test_cmp expect actual
+'
+
+test_expect_success 'stash push with pathspec not in the repository errors out' '
+ >untracked &&
+ test_must_fail git stash push untracked &&
+ test_path_is_file untracked
+'
+
+test_expect_success 'untracked files are left in place when -u is not given' '
+ >file &&
+ git add file &&
+ >untracked &&
+ git stash push file &&
+ test_path_is_file untracked
+'
+
test_done
diff --git a/t/t3905-stash-include-untracked.sh b/t/t3905-stash-include-untracked.sh
index f372fc8ca8..193adc7b68 100755
--- a/t/t3905-stash-include-untracked.sh
+++ b/t/t3905-stash-include-untracked.sh
@@ -185,4 +185,30 @@ test_expect_success 'stash save --all is stash poppable' '
test -s .gitignore
'
+test_expect_success 'stash push --include-untracked with pathspec' '
+ >foo &&
+ >bar &&
+ git stash push --include-untracked -- foo &&
+ test_path_is_file bar &&
+ test_path_is_missing foo &&
+ git stash pop &&
+ test_path_is_file bar &&
+ test_path_is_file foo
+'
+
+test_expect_success 'stash push with $IFS character' '
+ >"foo bar" &&
+ >foo &&
+ >bar &&
+ git add foo* &&
+ git stash push --include-untracked -- "foo b*" &&
+ test_path_is_missing "foo bar" &&
+ test_path_is_file foo &&
+ test_path_is_file bar &&
+ git stash pop &&
+ test_path_is_file "foo bar" &&
+ test_path_is_file foo &&
+ test_path_is_file bar
+'
+
test_done
--
2.12.0.428.g67fe103aa
^ permalink raw reply related
* Re: Typesafer git hash patch
From: Linus Torvalds @ 2017-02-28 20:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: brian m. carlson, Git Mailing List
In-Reply-To: <xmqqvarujdmv.fsf@gitster.mtv.corp.google.com>
On Tue, Feb 28, 2017 at 11:53 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>>
>> Having the hashes be more encapsulated does seem to make things better
>> in many ways. What I did was to also just unify the notion of "hash_t"
>> and "struct object_id", so the two are entirely interchangeable.
>
> Sorry, but at this point in your description, you completely lost
> me. I thought "struct object_id" was what you call "hash_t" in the
> above.
So what happened was that I started out just encapsulating
unsigned char sha1[20];
as a
hash_t hash;
and that made sense in a lot of situations. I always thought that code that used
struct object_id oid;
is just too ugly to live, so I'm not actually all that big of a fan of
the oid approach.
But the two approaches really are pretty much equivalent logically,
even if they don't look the same.
So I wanted to unify things: "One type to bring them all and in the
darkness bind them".
So I just basically made this:
typedef struct object_id {
unsigned char hash[GIT_HASH_SIZE];
} hash_t;
to create one single data structure that doesn't make my eyes bleed.
That "struct object_id" still exists, but I don't generally have to
look at it when doing the conversion, and any current users "just
work".
>> turns into
>>
>> + const hash_t *mb = &result->item->object.oid;
>> + if (!hashcmp(mb, current_bad_oid)) {
>
> Hmph. I somehow thought the longer term directio for the above code
> would be to turn it into
>
> if (!oidcmp(&result->item->object.oid, ¤t_bad_oid))
Well, you can actually do it with my patch, since I left "oidcmp()"
alone and it's just an alias for "hashcmp()" in my tree.
Except I think "oid" is an odious name, and really confusing and not
at all descriptive.
Using a three-letter acronym when we have a four-letter actual word to
say it feels stupid and wrong to me.
So what my conversion does is basically say that the name is *hash*.
So instead of using "oidcmp", you use "hashcmp":
if (!hashcmp(&result->item->object.oid, ¤t_bad_oid))
and functions take a "hash_t *" argument rather than a "struct
object_id *" argument, and when there was any kind of confusion and
mixing of use, I converted to "hash_t".
Both oid and "unsigned char *" users got converted.
In other words, what I was aiming for was getting rid - entirely - of
the "two different types", and I disliked both "oid" and "unsigned
char []", so neither replaces the other.
> Having said all that, I do not offhand see a huge benefit of the
> current layout that has one layer between the hash (i.e. oid.hash)
> and the object name (i.e. oid) over "there is no need for oid.hash;
> oid is just a hash", which you seem to be doing.
Yes exactly.
>> And as part of the type safety, I do think I may have found a bug:
>>
>> show_one_mergetag():
>>
>> strbuf_addf(&verify_message, "tag %s names a non-parent %s\n",
>> tag->tag, tag->tagged->oid.hash);
>>
>> note how it prints out the "non-parent %s", but that's a SHA1 hash
>> that hasn't been converted to hex. Hmm?
>
> Yup. That needs fixing, obviously.
I suspect nobody has ever hit that case - I tried to google for "names
a non-parent" and "tag" and "git" and the only thing that I found was
hits to git source.
So I was actually fairly impressed that the only thing I found was one
totally insignificant bug in a printout.
I did find a lot of cases where we really do mix a buffer of memory
("unsigned char *") with the hash. Not unsurprisingly, most of them
were in pack-file handling and in the tree parsing.
And some thing do the reverse, and really walk a hash name byte by
byte. Things like "find_pack_entry_one()" really does walk the bytes
of the hash.
With the conversion in place, those painful things are a bit more
obvious. So there's a couple of places where I just did a hard
conversion from a "unsigned char *" to a hash_t, but they are now
obvious casts and there's only 17 of them:
[torvalds@i7 git]$ git grep '(hash_t \*)'
builtin/index-pack.c: hashcpy(ref_hash, (hash_t *) fill(20));
builtin/pack-redundant.c: hash_t *h1 = (hash_t
*)(p1_base + p1_off);
builtin/pack-redundant.c: hash_t *h2 = (hash_t
*)(p2_base + p2_off);
builtin/pack-redundant.c: hash_t *h1 = (hash_t
*)(p1_base + p1_off);
builtin/pack-redundant.c: hash_t *h2 = (hash_t
*)(p2_base + p2_off);
builtin/pack-redundant.c: hash_t *h = (hash_t *)(base + off);
dir.c: hashcpy(&ud->exclude_sha1, (hash_t *)rd->data);
fast-import.c: hashcpy(&e->versions[0].hash, (hash_t *)c);
fast-import.c: hashcpy(&e->versions[1].hash, (hash_t *)c);
match-trees.c: hashcpy((hash_t *)rewrite_here, rewrite_with);
sha1-lookup.c: lo, mi, hi, sha1_to_hex((hash_t *)key));
sha1_file.c: return (hash_t *)(base + idx * GIT_SHA1_RAWSZ);
sha1_file.c: return (hash_t *)base;
sha1_file.c: return (hash_t *) (index + 24 * n + 4);
sha1_file.c: return (hash_t *) (index + 20 * n);
sha1_file.c: int cmp = hashcmp((hash_t *)(index + mi *
stride), (hash_t *)sha1);
split-index.c: hashcpy(&si->base_sha1, (hash_t *)data);
and there are basically an equal number of cases where I do the
reverse (by doing hash->hash to get the byte array data of the hash).
So the patch doesn't *fix* anything, but it does, I think, make it
easier to see the problems.
And the *bulk* of the code doesn't look inside the hashes at all.
Linus
^ permalink raw reply
* [PATCH v8 0/6] stash: support pathspec argument
From: Thomas Gummerer @ 2017-02-28 20:33 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, Johannes Schindelin, sunny,
Jakub Narębski, Matthieu Moy, Thomas Gummerer
In-Reply-To: <20170225213306.2410-1-t.gummerer@gmail.com>
Thanks Junio for the review and the squashable diff with the fix for
my errors.
I changed it a tiny bit, to use git stash push instead of git stash,
so the complete diff could go into 4/6, where I think I think the test
fits best.
Interdiff below:
diff --git a/git-stash.sh b/git-stash.sh
index 28d0624c75..207c8126f4 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -300,6 +300,8 @@ push_stash () {
if test $# != 0
then
git reset ${GIT_QUIET:+-q} -- "$@"
+ git ls-files -z --modified -- "$@" |
+ git checkout-index -z --force --stdin
git checkout ${GIT_QUIET:+-q} HEAD -- $(git ls-files -z --modified "$@")
git clean --force ${GIT_QUIET:+-q} -d -- "$@"
else
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index f7733b4dd4..89877e4b52 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -842,6 +842,22 @@ test_expect_success 'stash with file including $IFS character' '
test_path_is_file bar
'
+test_expect_success 'stash with pathspec matching multiple paths' '
+ echo original >file &&
+ echo original >other-file &&
+ git commit -m "two" file other-file &&
+ echo modified >file &&
+ echo modified >other-file &&
+ git stash push -- "*file" &&
+ echo original >expect &&
+ test_cmp expect file &&
+ test_cmp expect other-file &&
+ git stash pop &&
+ echo modified >expect &&
+ test_cmp expect file &&
+ test_cmp expect other-file
+'
+
test_expect_success 'stash push -p with pathspec shows no changes only once' '
>foo &&
git add foo &&
Thomas Gummerer (6):
stash: introduce push verb
stash: add test for the create command line arguments
stash: refactor stash_create
stash: teach 'push' (and 'create_stash') to honor pathspec
stash: use stash_push for no verb form
stash: allow pathspecs in the no verb form
Documentation/git-stash.txt | 25 +++++--
git-stash.sh | 116 +++++++++++++++++++++++++------
t/t3903-stash.sh | 138 ++++++++++++++++++++++++++++++++++++-
t/t3905-stash-include-untracked.sh | 26 +++++++
4 files changed, 275 insertions(+), 30 deletions(-)
--
2.12.0.428.g67fe103aa
^ permalink raw reply related
* [PATCH v8 2/6] stash: add test for the create command line arguments
From: Thomas Gummerer @ 2017-02-28 20:33 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, Johannes Schindelin, sunny,
Jakub Narębski, Matthieu Moy, Thomas Gummerer
In-Reply-To: <20170228203340.18723-1-t.gummerer@gmail.com>
Currently there is no test showing the expected behaviour of git stash
create's command line arguments. Add a test for that to show the
current expected behaviour and to make sure future refactorings don't
break those expectations.
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---
t/t3903-stash.sh | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index 3577115807..ffe3549ea5 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -784,4 +784,22 @@ test_expect_success 'push -m shows right message' '
test_cmp expect actual
'
+test_expect_success 'create stores correct message' '
+ >foo &&
+ git add foo &&
+ STASH_ID=$(git stash create "create test message") &&
+ echo "On master: create test message" >expect &&
+ git show --pretty=%s -s ${STASH_ID} >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success 'create with multiple arguments for the message' '
+ >foo &&
+ git add foo &&
+ STASH_ID=$(git stash create test untracked) &&
+ echo "On master: test untracked" >expect &&
+ git show --pretty=%s -s ${STASH_ID} >actual &&
+ test_cmp expect actual
+'
+
test_done
--
2.12.0.428.g67fe103aa
^ permalink raw reply related
* [PATCH v8 5/6] stash: use stash_push for no verb form
From: Thomas Gummerer @ 2017-02-28 20:33 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, Johannes Schindelin, sunny,
Jakub Narębski, Matthieu Moy, Thomas Gummerer
In-Reply-To: <20170228203340.18723-1-t.gummerer@gmail.com>
Now that we have stash_push, which accepts pathspec arguments, use
it instead of stash_save in git stash without any additional verbs.
Previously we allowed git stash -- -message, which is no longer allowed
after this patch. Messages starting with a hyphen was allowed since
3c2eb80f, ("stash: simplify defaulting to "save" and reject unknown
options"). However it was never the intent to allow that, but rather it
was allowed accidentally.
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
---
Documentation/git-stash.txt | 8 ++++----
git-stash.sh | 16 ++++++++--------
t/t3903-stash.sh | 4 +---
3 files changed, 13 insertions(+), 15 deletions(-)
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 88369ed8b6..4d8d30f179 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -13,11 +13,11 @@ SYNOPSIS
'git stash' drop [-q|--quiet] [<stash>]
'git stash' ( pop | apply ) [--index] [-q|--quiet] [<stash>]
'git stash' branch <branchname> [<stash>]
-'git stash' [save [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet]
- [-u|--include-untracked] [-a|--all] [<message>]]
-'git stash' push [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet]
+'git stash' save [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet]
+ [-u|--include-untracked] [-a|--all] [<message>]
+'git stash' [push [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet]
[-u|--include-untracked] [-a|--all] [-m|--message <message>]]
- [--] [<pathspec>...]
+ [--] [<pathspec>...]]
'git stash' clear
'git stash' create [<message>]
'git stash' store [-m|--message <message>] [-q|--quiet] <commit>
diff --git a/git-stash.sh b/git-stash.sh
index 5892abafa3..f3c2f86804 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -7,11 +7,11 @@ USAGE="list [<options>]
or: $dashless drop [-q|--quiet] [<stash>]
or: $dashless ( pop | apply ) [--index] [-q|--quiet] [<stash>]
or: $dashless branch <branchname> [<stash>]
- or: $dashless [save [--patch] [-k|--[no-]keep-index] [-q|--quiet]
- [-u|--include-untracked] [-a|--all] [<message>]]
- or: $dashless push [--patch] [-k|--[no-]keep-index] [-q|--quiet]
- [-u|--include-untracked] [-a|--all] [-m <message>]
- [-- <pathspec>...]
+ or: $dashless save [--patch] [-k|--[no-]keep-index] [-q|--quiet]
+ [-u|--include-untracked] [-a|--all] [<message>]
+ or: $dashless [push [--patch] [-k|--[no-]keep-index] [-q|--quiet]
+ [-u|--include-untracked] [-a|--all] [-m <message>]
+ [-- <pathspec>...]]
or: $dashless clear"
SUBDIRECTORY_OK=Yes
@@ -658,7 +658,7 @@ apply_to_branch () {
}
PARSE_CACHE='--not-parsed'
-# The default command is "save" if nothing but options are given
+# The default command is "push" if nothing but options are given
seen_non_option=
for opt
do
@@ -668,7 +668,7 @@ do
esac
done
-test -n "$seen_non_option" || set "save" "$@"
+test -n "$seen_non_option" || set "push" "$@"
# Main command set
case "$1" in
@@ -719,7 +719,7 @@ branch)
*)
case $# in
0)
- save_stash &&
+ push_stash &&
say "$(gettext "(To restore them type \"git stash apply\")")"
;;
*)
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index f934993263..e875fe8259 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -274,9 +274,7 @@ test_expect_success 'stash --invalid-option' '
git add file2 &&
test_must_fail git stash --invalid-option &&
test_must_fail git stash save --invalid-option &&
- test bar5,bar6 = $(cat file),$(cat file2) &&
- git stash -- -message-starting-with-dash &&
- test bar,bar2 = $(cat file),$(cat file2)
+ test bar5,bar6 = $(cat file),$(cat file2)
'
test_expect_success 'stash an added file' '
--
2.12.0.428.g67fe103aa
^ permalink raw reply related
* Re: [PATCH] Travis: also test on 32-bit Linux
From: Johannes Schindelin @ 2017-02-28 20:34 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Lars Schneider
In-Reply-To: <c76a133a57514a332828099d342c9763fd946bfa.1488309430.git.johannes.schindelin@gmx.de>
Hi,
On Tue, 28 Feb 2017, Johannes Schindelin wrote:
> When Git v2.9.1 was released, it had a bug that showed only on Windows
> and on 32-bit systems: our assumption that `unsigned long` can hold
> 64-bit values turned out to be wrong.
>
> This could have been caught earlier if we had a Continuous Testing set
> up that includes a build and test run on 32-bit Linux.
>
> Let's do this (and take care of the Windows build later). This patch
> asks Travis CI to install a Docker image with 32-bit libraries and then
> goes on to build and test Git using this 32-bit setup.
For the record, I first tested this with the LONG_IS_32BIT flag forced to
`true` so that the date tests must fail. They did fail as expected (search
for "not ok" in this output):
https://travis-ci.org/git/git/jobs/206199002
(I actually cannot see the log right now, Travis seems to be under heavy
load...)
A much cleaned up version that does not force that LONG_IS_32BIT produced
this log:
https://travis-ci.org/git/git/jobs/206228708
(Same here, my browser fails to load the log, probably because Travis
experiences quite high a load...)
Please note that this approach is not without problems. It would appear
that Travis currently has serious problems to even *reach* the Docker Hub,
and therefore cannot download the Docker image:
https://travis-ci.org/git/git/jobs/206292947#L6
Ciao,
Johannes
^ permalink raw reply
* Re: [PATCH v5 00/24] Remove submodule from files-backend.c
From: Junio C Hamano @ 2017-02-28 20:52 UTC (permalink / raw)
To: Michael Haggerty
Cc: Nguyễn Thái Ngọc Duy, git, Johannes Schindelin,
Ramsay Jones, Stefan Beller, novalis
In-Reply-To: <c525b1cf-3bb0-452c-8a8d-b07c58f00c84@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> On 02/22/2017 03:04 PM, Nguyễn Thái Ngọc Duy wrote:
>> v5 goes a bit longer than v4, basically:
>
> I've read through patch 14/24 so far, and they all look good except for
> the mostly superficial comments that I have sent so far. I like the way
> this is heading!
>
> I'll try to continue tomorrow.
>
> Michael
Thanks.
^ permalink raw reply
* Re: [PATCH v2 2/2] Documentation: Link descriptions of -z to core.quotePath
From: Junio C Hamano @ 2017-02-28 20:51 UTC (permalink / raw)
To: Andreas Heiduk; +Cc: git
In-Reply-To: <1487968676-6126-3-git-send-email-asheiduk@gmail.com>
Andreas Heiduk <asheiduk@gmail.com> writes:
> diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
> index e6215c3..7c28e73 100644
> --- a/Documentation/diff-options.txt
> +++ b/Documentation/diff-options.txt
> @@ -192,10 +192,9 @@ ifndef::git-log[]
> given, do not munge pathnames and use NULs as output field terminators.
> endif::git-log[]
> +
> -Without this option, each pathname output will have TAB, LF, double quotes,
> -and backslash characters replaced with `\t`, `\n`, `\"`, and `\\`,
> -respectively, and the pathname will be enclosed in double quotes if
> -any of those replacements occurred.
> +Without this option, pathnames with "unusual" characters are munged as
> +explained for the configuration variable `core.quotePath` (see
> +linkgit:git-config[1]).
Seeing that many other instances call this "quoted", we may want to
be consistent. I can see "munge" in the pre-context, but that one
can stay as is. Under -z, no modification/munging happens. With -z,
a specific kind of modification (called "quote" described in the
documentation for core.quotepath variable) happens. The same
comment applies to the change to Documentation/git-apply.txt
Otherwise the patch looks good.
Thanks.
^ permalink raw reply
* Re: Typesafer git hash patch
From: brian m. carlson @ 2017-02-28 20:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <CA+55aFzUhWinWqK30GBc1BKy-v6QtDdO2BLUODkiqg9XoKLrwA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2268 bytes --]
On Tue, Feb 28, 2017 at 12:25:20PM -0800, Linus Torvalds wrote:
> On Tue, Feb 28, 2017 at 11:53 AM, Junio C Hamano <gitster@pobox.com> wrote:
> > Sorry, but at this point in your description, you completely lost
> > me. I thought "struct object_id" was what you call "hash_t" in the
> > above.
>
> So what happened was that I started out just encapsulating
>
> unsigned char sha1[20];
>
> as a
>
> hash_t hash;
>
> and that made sense in a lot of situations. I always thought that code that used
>
> struct object_id oid;
>
> is just too ugly to live, so I'm not actually all that big of a fan of
> the oid approach.
There was some discussion on the list about the best name to use, and
object_id seemed like the most popular decision. I don't care if we add
a typedef for it and prefer that typedef, but the existing code avoided
typedefs in favor of explicit struct definitions.
I'm certainly not opposed to having less to type, because “object_id” is
awkward to type, but I've generally tried to defer to existing uses in
the codebase and what list regulars are comfortable with.
The only problem with using hash_t is that it's then not obvious as we
transition (assuming we don't take an omnibus patch) what is converted
and what isn't.
> But the two approaches really are pretty much equivalent logically,
> even if they don't look the same.
Yeah, I think they are.
> So I wanted to unify things: "One type to bring them all and in the
> darkness bind them".
>
> So I just basically made this:
>
> typedef struct object_id {
> unsigned char hash[GIT_HASH_SIZE];
> } hash_t;
>
> to create one single data structure that doesn't make my eyes bleed.
> That "struct object_id" still exists, but I don't generally have to
> look at it when doing the conversion, and any current users "just
> work".
There is nothing that prevents us from doing a nice global
search-and-replace in the future if we think the status quo is bad.
That's something that could be automated with Coccinelle.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 868 bytes --]
^ permalink raw reply
* Re: [PATCH] http: attempt updating base URL only if no error
From: Jeff King @ 2017-02-28 19:58 UTC (permalink / raw)
To: Jonathan Tan; +Cc: git
In-Reply-To: <6127c0a7-800d-fcf3-c6e2-17533347f07e@google.com>
On Tue, Feb 28, 2017 at 10:48:52AM -0800, Jonathan Tan wrote:
> > Running your included test, we get:
> >
> > fatal: unable to access 'http://127.0.0.1:5550/redir-to/502/': The
> > requested URL returned error: 502
> >
> > but the error really happened in the intermediate step. I wonder if we
> > should show the effective_url in that case, as it's more likely to
> > pinpoint the problem. OTOH, we do not mention the intermediate redirect
> > at all, so they might be confused about where that URL came from. If you
> > really want to debug HTTP confusion, you should use GIT_TRACE_CURL.
>
> Yeah, if we mention the effective_url, I think that there would need to be a
> lot more explaining to be done (e.g. why does my URL have
> "info/refs?service=git-upload-pack" tacked on at the end). It might be
> better to just recommend GIT_TRACE_CURL.
Indeed. Your comment made me realize that my suggestion was the exact
opposite of the earlier d5ccbe4df (remote-curl: consistently report repo
url for http errors, 2013-04-05). :)
Given that we don't see a lot of questions on the list about this,
either it doesn't come up much, or they are capable of finding
GIT_TRACE_CURL or GIT_CURL_VERBOSE on their own. So I think we can leave
the message as-is.
-Peff
^ permalink raw reply
* Re: [ANNOUNCE] Git for Windows 2.12.0
From: Johannes Schindelin @ 2017-02-28 20:59 UTC (permalink / raw)
To: wth1; +Cc: git-for-windows, git
In-Reply-To: <74720ad6-1bc6-4dbd-9098-33cb069f41de@googlegroups.com>
[-- Attachment #1: Type: text/plain, Size: 561 bytes --]
Hi,
On Tue, 28 Feb 2017, wth1@cornell.edu wrote:
> I have attempted to download the new version but on 2/28/2016 starting
> at 12:00PM EST I have been unable to download GIT 2.12. The error
> message that is returned is:
>
> Make sure you’ve got the right web address:
> https://github-cloud.s3.amazonaws.com
It looks as if AWS has serious problems right now. Try downloading from
here:
https://instant.io/#152a79b2aad5137413e1ca2edd43fc08f736d896
And please leave the browser open for a while after it downloaded.
Thanks,
Johannes
^ permalink raw reply
* Re: [PATCH 5/5] ls-files: fix bug when recuring with relative pathspec
From: Junio C Hamano @ 2017-02-28 21:07 UTC (permalink / raw)
To: Brandon Williams; +Cc: git, sbeller, pclouds
In-Reply-To: <20170224235100.52627-6-bmwill@google.com>
Brandon Williams <bmwill@google.com> writes:
> Fix a bug which causes a child process for a submodule to error out when a
> relative pathspec with a ".." is provided in the superproject.
>
> While at it, correctly construct the super-prefix to be used in a submodule
> when not at the root of the repository.
>
> Signed-off-by: Brandon Williams <bmwill@google.com>
> ---
> builtin/ls-files.c | 8 ++++++--
> t/t3007-ls-files-recurse-submodules.sh | 2 +-
> 2 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/builtin/ls-files.c b/builtin/ls-files.c
> index 159229081..89533ab8e 100644
> --- a/builtin/ls-files.c
> +++ b/builtin/ls-files.c
> @@ -194,12 +194,15 @@ static void compile_submodule_options(const struct dir_struct *dir, int show_tag
> static void show_gitlink(const struct cache_entry *ce)
> {
> struct child_process cp = CHILD_PROCESS_INIT;
> + struct strbuf name = STRBUF_INIT;
> int status;
> int i;
>
> + quote_path_relative(ce->name, prefix, &name);
> argv_array_pushf(&cp.args, "--super-prefix=%s%s/",
Same comment as 3/5. quote_path is to produce c-quote and is not
even meant for shell script quoting. run_command() interface would
do its own shell quoting when needed, so I think you just want the
exact string you want to pass here.
^ permalink raw reply
* Re: [PATCH v2 2/2] Documentation: Link descriptions of -z to core.quotePath
From: Andreas Heiduk @ 2017-02-28 21:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqqmvd6jayn.fsf@gitster.mtv.corp.google.com>
Am 28.02.2017 um 21:51 schrieb Junio C Hamano:
> Andreas Heiduk <asheiduk@gmail.com> writes:
>
>> diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
>> index e6215c3..7c28e73 100644
>> --- a/Documentation/diff-options.txt
>> +++ b/Documentation/diff-options.txt
>> @@ -192,10 +192,9 @@ ifndef::git-log[]
>> given, do not munge pathnames and use NULs as output field terminators.
>> endif::git-log[]
>> +
>> -Without this option, each pathname output will have TAB, LF, double quotes,
>> -and backslash characters replaced with `\t`, `\n`, `\"`, and `\\`,
>> -respectively, and the pathname will be enclosed in double quotes if
>> -any of those replacements occurred.
>> +Without this option, pathnames with "unusual" characters are munged as
>> +explained for the configuration variable `core.quotePath` (see
>> +linkgit:git-config[1]).
>
> Seeing that many other instances call this "quoted", we may want to
> be consistent. I can see "munge" in the pre-context, but that one
> can stay as is. Under -z, no modification/munging happens. With -z,
> a specific kind of modification (called "quote" described in the
> documentation for core.quotepath variable) happens. The same
> comment applies to the change to Documentation/git-apply.txt
>
> Otherwise the patch looks good.
>
> Thanks.
>
I'll fix the "munged" and, unless there are objections, I will also
replace the remaining ones in the vicinity. These are the last
occurrences of "munged".
You are OK with the references to another man page? My idea was to
establish a well-known term.
^ permalink raw reply
* Re: [PATCH v2 2/2] Documentation: Link descriptions of -z to core.quotePath
From: Junio C Hamano @ 2017-02-28 21:25 UTC (permalink / raw)
To: Andreas Heiduk; +Cc: git
In-Reply-To: <d59bda7b-2eb5-a6cc-8240-0ff4f50de540@gmail.com>
Andreas Heiduk <asheiduk@gmail.com> writes:
> I'll fix the "munged" and, unless there are objections, I will also
> replace the remaining ones in the vicinity. These are the last
> occurrences of "munged".
I'd rather see the "we do not munge" to stay the same. "we do not
quote" still allows us to do modifications that are different from
quoting.
> You are OK with the references to another man page? My idea was to
> establish a well-known term.
The "well-known term" cannot just be "quote", because it is too
generic. "git rev-parse --sq-quote" does a different kind of
quoting from the quoting done here for paths with unusual
characters, for example.
We certainly *could* (1) add to glossary-content.txt the definition
of "c-quote" and describe it there, (2) change the "see the quoting
explained for core.quotePath" to "unless -z is given, paths are
c-quoted", and (3) change the core.quotePath description to refer to
"c-quote" in the glossary.
But I am not sure it that makes the resulting document easier to use
by the end users. I personally find the result of applying the
patch you posted easier.
^ permalink raw reply
* Re: [PATCH 0/6] Use time_t
From: Johannes Schindelin @ 2017-02-28 20:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: René Scharfe, Jeff King, git
In-Reply-To: <xmqqa896kuve.fsf@gitster.mtv.corp.google.com>
[-- Attachment #1: Type: text/plain, Size: 1715 bytes --]
Hi Junio,
On Tue, 28 Feb 2017, Junio C Hamano wrote:
> René Scharfe <l.s.r@web.de> writes:
>
> > Am 28.02.2017 um 15:28 schrieb Jeff King:
> >
> >> It looks from the discussion like the sanest path forward is our own
> >> signed-64bit timestamp_t. That's unfortunate compared to using the
> >> standard time_t, but hopefully it would reduce the number of knobs
> >> (like TIME_T_IS_INT64) in the long run.
> >
> > Glibc will get a way to enable 64-bit time_t on 32-bit platforms
> > eventually (https://sourceware.org/glibc/wiki/Y2038ProofnessDesign).
> > Can platforms that won't provide a 64-bit time_t by 2038 be actually
> > used at that point? How would we get time information on them? How
> > would a custom timestamp_t help us?
>
> That's a sensible "wait, let's step back a bit". I take it that you are
> saying "time_t is just fine", and I am inclined to agree.
>
> Right now, they may be able to have future timestamps ranging to
> year 2100 and switching to time_t would limit their ability to
> express future time to 2038 but they would be able to express
> timestamp in the past to cover most of 20th century. Given that
> these 32-bit time_t software platforms will die off before year 2038
> (either by underlying hardware getting obsolete, or software updated
> to handle 64-bit time_t), the (temporary) loss of 2038-2100 range
> would not be too big a deal to warrant additional complexity.
You seem to assume that time_t is required to be signed. But from my
understanding that is only guaranteed by POSIX, not by ISO C.
We may very well buy ourselves a ton of trouble if we decide to switch to
`time_t` rather than to `int64_t`.
Ciao,
Johannes
^ permalink raw reply
* Re: [PATCH v2 2/2] Documentation: Link descriptions of -z to core.quotePath
From: Andreas Heiduk @ 2017-02-28 21:30 UTC (permalink / raw)
To: Jakub Narębski, Junio C Hamano; +Cc: git
In-Reply-To: <f534b9c7-c8a8-1a05-5fcb-020122dccaac@gmail.com>
Am 24.02.2017 um 22:54 schrieb Jakub Narębski:
> W dniu 24.02.2017 o 21:37, Andreas Heiduk pisze:
>> Linking the description for pathname quoting to the configuration
>> variable "core.quotePath" removes inconstistent and incomplete
>> sections while also giving two hints how to deal with it: Either with
>> "-c core.quotePath=false" or with "-z".
>
> This patch I am not sure about. On one hand it improves consistency
> (and makes information more complete), on the other hand it removes
> information at hand and instead refers to other manpage.
Indeed this is a trade-off. My intention was to establish some kind of
well-known term by citing "core.quotePath" everywhere. So after a while
"quoting" and "core.quotePath" should be known by everyone interested.
> Perhaps a better solution would be to craft a short description that
> is both sufficiently complete, and refers to "core.quotePath" for
> more details, and then transclude it with "include::quotepath.txt[]".
On the other hand this makes every section quite long. Personally, I
find long and repetitive documentation harder to comprehend.
>>
>> Signed-off-by: Andreas Heiduk <asheiduk@gmail.com>
>> ---
>> Documentation/diff-format.txt | 7 ++++---
>> Documentation/diff-generate-patch.txt | 7 +++----
>> Documentation/diff-options.txt | 7 +++----
>> Documentation/git-apply.txt | 7 +++----
>> Documentation/git-commit.txt | 9 ++++++---
>> Documentation/git-ls-files.txt | 10 ++++++----
>> Documentation/git-ls-tree.txt | 10 +++++++---
>> Documentation/git-status.txt | 7 +++----
>> 8 files changed, 35 insertions(+), 29 deletions(-)
>>
>> diff --git a/Documentation/diff-format.txt b/Documentation/diff-format.txt
>> index cf52626..706916c 100644
>> --- a/Documentation/diff-format.txt
>> +++ b/Documentation/diff-format.txt
>> @@ -78,9 +78,10 @@ Example:
>> :100644 100644 5be4a4...... 000000...... M file.c
>> ------------------------------------------------
>>
>> -When `-z` option is not used, TAB, LF, and backslash characters
>> -in pathnames are represented as `\t`, `\n`, and `\\`,
>> -respectively.
>> +Without the `-z` option, pathnames with "unusual" characters are
>> +quoted as explained for the configuration variable `core.quotePath`
>> +(see linkgit:git-config[1]). Using `-z` the filename is output
>> +verbatim and the line is terminated by a NUL byte.
>>
>> diff format for merges
>> ----------------------
>> diff --git a/Documentation/diff-generate-patch.txt b/Documentation/diff-generate-patch.txt
>> index d2a7ff5..231105c 100644
>> --- a/Documentation/diff-generate-patch.txt
>> +++ b/Documentation/diff-generate-patch.txt
>> @@ -53,10 +53,9 @@ The index line includes the SHA-1 checksum before and after the change.
>> The <mode> is included if the file mode does not change; otherwise,
>> separate lines indicate the old and the new mode.
>>
>> -3. TAB, LF, double quote and backslash characters in pathnames
>> - are represented as `\t`, `\n`, `\"` and `\\`, respectively.
>> - If there is need for such substitution then the whole
>> - pathname is put in double quotes.
>> +3. Pathnames with "unusual" characters are quoted as explained for
>> + the configuration variable `core.quotePath` (see
>> + linkgit:git-config[1]).
>>
>> 4. All the `file1` files in the output refer to files before the
>> commit, and all the `file2` files refer to files after the commit.
>> diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
>> index e6215c3..7c28e73 100644
>> --- a/Documentation/diff-options.txt
>> +++ b/Documentation/diff-options.txt
>> @@ -192,10 +192,9 @@ ifndef::git-log[]
>> given, do not munge pathnames and use NULs as output field terminators.
>> endif::git-log[]
>> +
>> -Without this option, each pathname output will have TAB, LF, double quotes,
>> -and backslash characters replaced with `\t`, `\n`, `\"`, and `\\`,
>> -respectively, and the pathname will be enclosed in double quotes if
>> -any of those replacements occurred.
>> +Without this option, pathnames with "unusual" characters are munged as
>> +explained for the configuration variable `core.quotePath` (see
>> +linkgit:git-config[1]).
>>
>> --name-only::
>> Show only names of changed files.
>> diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt
>> index 8ddb207..a7a001b 100644
>> --- a/Documentation/git-apply.txt
>> +++ b/Documentation/git-apply.txt
>> @@ -108,10 +108,9 @@ the information is read from the current index instead.
>> When `--numstat` has been given, do not munge pathnames,
>> but use a NUL-terminated machine-readable format.
>> +
>> -Without this option, each pathname output will have TAB, LF, double quotes,
>> -and backslash characters replaced with `\t`, `\n`, `\"`, and `\\`,
>> -respectively, and the pathname will be enclosed in double quotes if
>> -any of those replacements occurred.
>> +Without this option, pathnames with "unusual" characters are munged as
>> +explained for the configuration variable `core.quotePath` (see
>> +linkgit:git-config[1]).
>>
>> -p<n>::
>> Remove <n> leading slashes from traditional diff paths. The
>> diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
>> index 4f8f20a..25dcdcc 100644
>> --- a/Documentation/git-commit.txt
>> +++ b/Documentation/git-commit.txt
>> @@ -117,9 +117,12 @@ OPTIONS
>>
>> -z::
>> --null::
>> - When showing `short` or `porcelain` status output, terminate
>> - entries in the status output with NUL, instead of LF. If no
>> - format is given, implies the `--porcelain` output format.
>> + When showing `short` or `porcelain` status output, print the
>> + filename verbatim and terminate the entries with NUL, instead of LF.
>> + If no format is given, implies the `--porcelain` output format.
>> + Without the `-z` option, filenames with "unusual" characters are
>> + quoted as explained for the configuration variable `core.quotePath`
>> + (see linkgit:git-config[1]).
>>
>> -F <file>::
>> --file=<file>::
>> diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
>> index 446209e..1cab703 100644
>> --- a/Documentation/git-ls-files.txt
>> +++ b/Documentation/git-ls-files.txt
>> @@ -77,7 +77,8 @@ OPTIONS
>> succeed.
>>
>> -z::
>> - \0 line termination on output.
>> + \0 line termination on output and do not quote filenames.
>> + See OUTPUT below for more information.
>>
>> -x <pattern>::
>> --exclude=<pattern>::
>> @@ -196,9 +197,10 @@ the index records up to three such pairs; one from tree O in stage
>> the user (or the porcelain) to see what should eventually be recorded at the
>> path. (see linkgit:git-read-tree[1] for more information on state)
>>
>> -When `-z` option is not used, TAB, LF, and backslash characters
>> -in pathnames are represented as `\t`, `\n`, and `\\`,
>> -respectively.
>> +Without the `-z` option, pathnames with "unusual" characters are
>> +quoted as explained for the configuration variable `core.quotePath`
>> +(see linkgit:git-config[1]). Using `-z` the filename is output
>> +verbatim and the line is terminated by a NUL byte.
>>
>>
>> Exclude Patterns
>> diff --git a/Documentation/git-ls-tree.txt b/Documentation/git-ls-tree.txt
>> index dbc91f9..9dee7be 100644
>> --- a/Documentation/git-ls-tree.txt
>> +++ b/Documentation/git-ls-tree.txt
>> @@ -53,7 +53,8 @@ OPTIONS
>> Show object size of blob (file) entries.
>>
>> -z::
>> - \0 line termination on output.
>> + \0 line termination on output and do not quote filenames.
>> + See OUTPUT FORMAT below for more information.
>>
>> --name-only::
>> --name-status::
>> @@ -82,8 +83,6 @@ Output Format
>> -------------
>> <mode> SP <type> SP <object> TAB <file>
>>
>> -Unless the `-z` option is used, TAB, LF, and backslash characters
>> -in pathnames are represented as `\t`, `\n`, and `\\`, respectively.
>> This output format is compatible with what `--index-info --stdin` of
>> 'git update-index' expects.
>>
>> @@ -95,6 +94,11 @@ Object size identified by <object> is given in bytes, and right-justified
>> with minimum width of 7 characters. Object size is given only for blobs
>> (file) entries; for other entries `-` character is used in place of size.
>>
>> +Without the `-z` option, pathnames with "unusual" characters are
>> +quoted as explained for the configuration variable `core.quotePath`
>> +(see linkgit:git-config[1]). Using `-z` the filename is output
>> +verbatim and the line is terminated by a NUL byte.
>> +
>> GIT
>> ---
>> Part of the linkgit:git[1] suite
>> diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
>> index 725065e..ba87365 100644
>> --- a/Documentation/git-status.txt
>> +++ b/Documentation/git-status.txt
>> @@ -322,10 +322,9 @@ When the `-z` option is given, pathnames are printed as is and
>> without any quoting and lines are terminated with a NUL (ASCII 0x00)
>> byte.
>>
>> -Otherwise, all pathnames will be "C-quoted" if they contain any tab,
>> -linefeed, double quote, or backslash characters. In C-quoting, these
>> -characters will be replaced with the corresponding C-style escape
>> -sequences and the resulting pathname will be double quoted.
>> +Without the `-z` option, pathnames with "unusual" characters are
>> +quoted as explained for the configuration variable `core.quotePath`
>> +(see linkgit:git-config[1]).
>>
>>
>> CONFIGURATION
>>
>
^ 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