Re: [PATCH] diff --no-index: allow pathspec after --
Junio C Hamano gits...@pobox.com writes:
Coming back to the command line syntax for the new feature, if I had
to choose, I would say
git diff --no-index [-options] [--] path path pathspec
perhaps? As we never compare anything other than two things,...
Actually, I am not so sure about this anymore.
It is not entirely fair to say that
git diff --no-index [--options] A B C D
as comparing A and B while using C and D as pathspec and declare a
person who expects otherwise a moron. To a person whose brain is
not rotten by years of use of Git, we never compare anything other
than two things with --no-index is not a given, I am afraid.
It is equally plausible that the same command line may be asking to
compare A with B and C with D, i.e. producing
diff --no-git a/A b/B
...
diff --no-git a/C b/D
...
It also equally plausible (taking a cue from mv A B C Dir/) that
it is comparing A, B and C with D/A, D/B and D/C, respectively,
producing
diff --no-git a/A b/D/A
...
diff --no-git a/B b/D/B
...
diff --no-git a/C b/D/C
...
The only unambiguous syntax I can think of that avoids such
alternative interpretations is something ugly like
git diff --no-index [-options] --src=path --dst=path [--] pathspec
where src and dst are in line with the existing src/dst-prefix
options.
Perhaps we could declare that this is the canonical way to spell
pathspec-filtered no-index comparison of two directories, but we
allow the syntax suggested in the message I am responding to as a
short-hand, but I am not sure if that would fly well.
This --src/--dst thing could lead to even uglier tangent. We could
use these options to specify what is compared with what else
--{src,dst}-path=directory in the working tree
--{src,dst}-index
--{src,dst}-worktree
--{src,dst}-tree=tree object
which allows us to express funky combinations like
git diff --src-index --dst-worktree [--] pathspec
git diff --src-tree=HEAD --dst-index [--] pathspec
git diff --src-tree=maint --dst-tree=master [--] pathspec
The above three would be ugly ways to spell the traditional short
hands, e.g.
git diff [--] pathspec
git diff --cached [--] pathspec
git diff maint master [--] pathspec
respectively. And an obvious fallout of the above is this command
line:
git diff --src-path=A --dst-path=B [--] pathspec
Because this does not involve any index, tree or worktree, it cannot
be a Git operation, so we know that is --no-index mode; the command
line does not need to say --no-index anywhere if we go that route.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] l10n: de.po: change Email to E-Mail
2014-09-20 17:51 GMT+02:00 Phillip Sz phillip.sze...@gmail.com: Changes all Email to E-Mail, as this is the correct form in german. Thanks! Phillip Signed-off-by: Phillip Sz phillip.sze...@gmail.com --- po/de.po | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/po/de.po b/po/de.po index e5d2b25..c6aa69f 100644 --- a/po/de.po +++ b/po/de.po @@ -2691,7 +2691,7 @@ msgstr Unterdrückt den Namen des Autors und den Zeitstempel (Standard: aus) #: builtin/blame.c:2514 msgid Show author email instead of name (Default: off) -msgstr Zeigt anstatt des Namens die Email-Adresse des Autors (Standard: aus) +msgstr Zeigt anstatt des Namens die E-Mail-Adresse des Autors (Standard: aus) #: builtin/blame.c:2515 msgid Ignore whitespace differences @@ -6535,7 +6535,7 @@ msgstr zeigt Patchformat anstatt des Standards (Patch + Zusammenfassung) #: builtin/log.c:1217 msgid Messaging -msgstr Email-Einstellungen +msgstr E-Mail-Einstellungen #: builtin/log.c:1218 msgid header @@ -6543,11 +6543,11 @@ msgstr Header #: builtin/log.c:1219 msgid add email header -msgstr fügt Email-Header hinzu +msgstr fügt E-Mail-Header hinzu #: builtin/log.c:1220 builtin/log.c:1222 msgid email -msgstr Email +msgstr E-Mail #: builtin/log.c:1220 msgid add To: header @@ -6573,7 +6573,7 @@ msgstr message-id #: builtin/log.c:1228 msgid make first mail a reply to message-id -msgstr macht aus erster Email eine Antwort zu message-id +msgstr macht aus erster E-Mail eine Antwort zu message-id #: builtin/log.c:1229 builtin/log.c:1232 msgid boundary @@ -9431,7 +9431,7 @@ msgstr Unterdrückt Commit-Beschreibungen, liefert nur Anzahl der Commits #: builtin/shortlog.c:234 msgid Show the email address of each author -msgstr Zeigt die Email-Adresse von jedem Autor +msgstr Zeigt die E-Mail-Adresse von jedem Autor #: builtin/shortlog.c:235 msgid w[,i1[,i2]] @@ -10284,7 +10284,7 @@ msgstr #: git-am.sh:732 msgid Patch does not have a valid e-mail address. -msgstr Patch enthält keine gültige Email-Adresse. +msgstr Patch enthält keine gültige E-Mail-Adresse. #: git-am.sh:779 msgid cannot be interactive without stdin connected to a terminal. -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] remote: simplify match_name_with_pattern() using strbuf
Make the code simpler and shorter by avoiding repetitive use of
string length variables and leaving memory allocation to strbuf
functions.
Signed-off-by: Rene Scharfe l@web.de
---
remote.c | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/remote.c b/remote.c
index 35e62ee..ce785f8 100644
--- a/remote.c
+++ b/remote.c
@@ -862,21 +862,14 @@ static int match_name_with_pattern(const char *key, const
char *name,
ret = !strncmp(name, key, klen) namelen = klen + ksuffixlen
!memcmp(name + namelen - ksuffixlen, kstar + 1, ksuffixlen);
if (ret value) {
+ struct strbuf sb = STRBUF_INIT;
const char *vstar = strchr(value, '*');
- size_t vlen;
- size_t vsuffixlen;
if (!vstar)
die(Value '%s' of pattern has no '*', value);
- vlen = vstar - value;
- vsuffixlen = strlen(vstar + 1);
- *result = xmalloc(vlen + vsuffixlen +
- strlen(name) -
- klen - ksuffixlen + 1);
- strncpy(*result, value, vlen);
- strncpy(*result + vlen,
- name + klen, namelen - klen - ksuffixlen);
- strcpy(*result + vlen + namelen - klen - ksuffixlen,
- vstar + 1);
+ strbuf_add(sb, value, vstar - value);
+ strbuf_add(sb, name + klen, namelen - klen - ksuffixlen);
+ strbuf_addstr(sb, vstar + 1);
+ *result = strbuf_detach(sb, NULL);
}
return ret;
}
--
2.1.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] notes: Allow adding empty notes with -C
On 2014-09-21 05.00, Johan Herland wrote: [] diff --git a/t/t3301-notes.sh b/t/t3301-notes.sh index cfd67ff..a6c399b 100755 --- a/t/t3301-notes.sh +++ b/t/t3301-notes.sh @@ -1239,4 +1239,23 @@ test_expect_success 'git notes get-ref (--ref)' ' test $(GIT_NOTES_REF=refs/notes/bar git notes --ref=baz get-ref) = refs/notes/baz ' +cat expect EOF Git style for shell scripts: Plase put no space between or or and the file name: cat expect EOF +commit 085b0d1309902c3148feb5a136515bdb9a1cd614 +Author: A U Thor aut...@example.com +Date: Thu Apr 7 15:28:13 2005 -0700 + +16th + +Notes (foo): +EOF + +test_expect_success 'can create empty note with git notes add -C $empty_blob' ' + test_commit 16th + blob=e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 + git notes add -C $blob + git log -1 actual git log -1 actual + test_cmp expect actual + test $(git notes list HEAD) = $blob +' + test_done -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mailinfo: resolve -Wstring-plus-int warning
The just-released Apple Xcode 6.0.1 has -Wstring-plus-int enabled by
default which complains about pointer arithmetic applied to a string
literal:
builtin/mailinfo.c:303:24: warning:
adding 'long' to a string does not append to the string
return !memcmp(SAMPLE + (cp - line), cp, strlen(SAMPLE) ...
~~~^
Resolve this issue.
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
This is atop 2da1f366 (mailinfo: make From in-body header check more
robust; 2014-09-13) in 'next'.
In addition to the above diagnostic, the Apple compiler also helpfully
recommends SAMPLE[cp - line] as a replacement to avoid the warning,
however, the solution in this patch allows us drop a couple strlen()s in
favor of sizeof()s.
builtin/mailinfo.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/builtin/mailinfo.c b/builtin/mailinfo.c
index 2632fb0..b6b1c19 100644
--- a/builtin/mailinfo.c
+++ b/builtin/mailinfo.c
@@ -288,19 +288,20 @@ static inline int cmp_header(const struct strbuf *line,
const char *hdr)
line-buf[len] == ':' isspace(line-buf[len + 1]);
}
-#define SAMPLE From e6807f3efca28b30decfecb1732a56c7db1137ee Mon Sep 17
00:00:00 2001\n
static int is_format_patch_separator(const char *line, int len)
{
+ static const char SAMPLE[] =
+ From e6807f3efca28b30decfecb1732a56c7db1137ee Mon Sep 17
00:00:00 2001\n;
const char *cp;
- if (len != strlen(SAMPLE))
+ if (len != sizeof(SAMPLE) - 1)
return 0;
if (!skip_prefix(line, From , cp))
return 0;
if (strspn(cp, 0123456789abcdef) != 40)
return 0;
cp += 40;
- return !memcmp(SAMPLE + (cp - line), cp, strlen(SAMPLE) - (cp - line));
+ return !memcmp(SAMPLE + (cp - line), cp, sizeof(SAMPLE) - 1 - (cp -
line));
}
static int check_header(const struct strbuf *line,
--
2.1.1.391.g7a54a76.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] diff --no-index: allow pathspec after --
On Sun, Sep 21, 2014 at 1:19 PM, Junio C Hamano gits...@pobox.com wrote:
Junio C Hamano gits...@pobox.com writes:
Coming back to the command line syntax for the new feature, if I had
to choose, I would say
git diff --no-index [-options] [--] path path pathspec
perhaps? As we never compare anything other than two things,...
Actually, I am not so sure about this anymore.
It is not entirely fair to say that
git diff --no-index [--options] A B C D
as comparing A and B while using C and D as pathspec and declare a
person who expects otherwise a moron. To a person whose brain is
not rotten by years of use of Git, we never compare anything other
than two things with --no-index is not a given, I am afraid.
It is equally plausible that the same command line may be asking to
compare A with B and C with D, i.e. producing
diff --no-git a/A b/B
...
diff --no-git a/C b/D
...
Heh.. I wrote something like that [1]. An extension of this is feed
all filename pairs via stdin.
[1] http://thread.gmane.org/gmane.comp.version-control.git/188435
It also equally plausible (taking a cue from mv A B C Dir/) that
it is comparing A, B and C with D/A, D/B and D/C, respectively,
producing
diff --no-git a/A b/D/A
...
diff --no-git a/B b/D/B
...
diff --no-git a/C b/D/C
...
This mode is weird... In real world, A may match to D/some-path/A
not just D/A. Which brings it back to the previous mode.
The only unambiguous syntax I can think of that avoids such
alternative interpretations is something ugly like
git diff --no-index [-options] --src=path --dst=path [--] pathspec
where src and dst are in line with the existing src/dst-prefix
options.
Or let the user define a separator, e.g.
git diff --no-index --pathspec-separator=sep [--] paths... [sep
pathspec]
Another option is pathspec magic (I'm not entirely sure how it looks
like at the implementaiton level yet), --src=path could become
:(source)path, --dst=path - :(dst)path and so on..
Perhaps we could declare that this is the canonical way to spell
pathspec-filtered no-index comparison of two directories, but we
allow the syntax suggested in the message I am responding to as a
short-hand, but I am not sure if that would fly well.
This --src/--dst thing could lead to even uglier tangent. We could
use these options to specify what is compared with what else
--{src,dst}-path=directory in the working tree
--{src,dst}-index
--{src,dst}-worktree
--{src,dst}-tree=tree object
which allows us to express funky combinations like
git diff --src-index --dst-worktree [--] pathspec
git diff --src-tree=HEAD --dst-index [--] pathspec
git diff --src-tree=maint --dst-tree=master [--] pathspec
The above three would be ugly ways to spell the traditional short
hands, e.g.
git diff [--] pathspec
git diff --cached [--] pathspec
git diff maint master [--] pathspec
respectively. And an obvious fallout of the above is this command
line:
git diff --src-path=A --dst-path=B [--] pathspec
Because this does not involve any index, tree or worktree, it cannot
be a Git operation, so we know that is --no-index mode; the command
line does not need to say --no-index anywhere if we go that route.
Sounds a lot like Jeff's git-put, except with -- syntax instead of a
special one, and you only look at the diff, not move any content. Also
people who would go with git diff --no-index A B C D E F... usually
script it, not type it manually. And stdin would fit better than
command line arguments.
--
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] notes: Allow adding empty notes with -C
On Sun, Sep 21, 2014 at 10:53 AM, Torsten Bögershausen tbo...@web.de wrote: On 2014-09-21 05.00, Johan Herland wrote: [...] +cat expect EOF Git style for shell scripts: Plase put no space between or or and the file name: cat expect EOF [...] + git log -1 actual git log -1 actual Ok, will fix (although the rest of the file leans towards the alternative style with space). ...Johan -- Johan Herland, jo...@herland.net www.herland.net -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 22/32] checkout: support checking out into a new working directory
On Sun, Sep 21, 2014 at 10:10 AM, Eric Sunshine sunsh...@sunshineco.com wrote: Would it make sense for this rule of thumb summary to be presented first, and then the explanation of that rule after, rather than the reverse as is currently the case? You mean like this? diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt index c101575..fd77631 100644 --- a/Documentation/git-checkout.txt +++ b/Documentation/git-checkout.txt @@ -420,6 +420,11 @@ $GIT_COMMON_DIR is set to point back to the main working tree's $GIT_DIR (e.g. `/path/main/.git`). These settings are made in a `.git` file located at the top directory of the linked working tree. +See linkgit:gitrepository-layout[5] for more information. The rule of +thumb is do not make any assumption about whether a path belongs to +$GIT_DIR or $GIT_COMMON_DIR when you need to directly access something +inside $GIT_DIR. Use `git rev-parse --git-path` to get the final path. + Path resolution via `git rev-parse --git-path` uses either $GIT_DIR or $GIT_COMMON_DIR depending on the path. For example, in the linked working tree `git rev-parse --git-path HEAD` returns @@ -429,11 +434,6 @@ rev-parse --git-path refs/heads/master` uses $GIT_COMMON_DIR and returns `/path/main/.git/refs/heads/master`, since refs are shared across all working trees. -See linkgit:gitrepository-layout[5] for more information. The rule of -thumb is do not make any assumption about whether a path belongs to -$GIT_DIR or $GIT_COMMON_DIR when you need to directly access something -inside $GIT_DIR. Use `git rev-parse --git-path` to get the final path. - EXAMPLES -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] sha1_file: don't convert off_t to size_t too early to avoid potential die()
xsize_t() checks if an off_t argument can be safely converted to
a size_t return value. If the check is executed too early, it could
fail for large files on 32-bit architectures even if the size_t code
path is not taken. Other paths might be able to handle the large file.
Specifically, index_stream_convert_blob() is able to handle a large file
if a filter is configured that returns a small result.
Signed-off-by: Steffen Prohaska proha...@zib.de
---
This patch should be applied on top of sp/stream-clean-filter.
index_stream() might internally also be able to handle large files to
some extent. But it uses size_t for its third argument, and we must
already die() when calling it. It might be a good idea to convert its
interface to use off_t and push the size checks further down the stack.
In general, it might be good idea to carefully consider whether to use
off_t or size_t when passing file-related sizes around. To me it looks
like a separate issue for a separate patch series (I have no specific
plans to prepare one).
sha1_file.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 5b0e67a..6f18c22 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -3180,17 +3180,22 @@ int index_fd(unsigned char *sha1, int fd, struct stat
*st,
enum object_type type, const char *path, unsigned flags)
{
int ret;
- size_t size = xsize_t(st-st_size);
+ /*
+* Call xsize_t() only when needed to avoid potentially unnecessary
+* die() for large files.
+*/
if (type == OBJ_BLOB path would_convert_to_git_filter_fd(path))
ret = index_stream_convert_blob(sha1, fd, path, flags);
else if (!S_ISREG(st-st_mode))
ret = index_pipe(sha1, fd, type, path, flags);
- else if (size = big_file_threshold || type != OBJ_BLOB ||
+ else if (st-st_size = big_file_threshold || type != OBJ_BLOB ||
(path would_convert_to_git(path)))
- ret = index_core(sha1, fd, size, type, path, flags);
+ ret = index_core(sha1, fd, xsize_t(st-st_size), type, path,
+flags);
else
- ret = index_stream(sha1, fd, size, type, path, flags);
+ ret = index_stream(sha1, fd, xsize_t(st-st_size), type, path,
+ flags);
close(fd);
return ret;
}
--
2.1.0.139.g351b19f
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 23/32] prune: strategies for linked checkouts
Here we go again. Thanks both for the suggestions. -- 8 -- Subject: [PATCH] prune: strategies for linked checkouts (alias R=$GIT_COMMON_DIR/worktrees/id) - linked checkouts are supposed to keep its location in $R/gitdir up to date. The use case is auto fixup after a manual checkout move. - linked checkouts are supposed to update mtime of $R/gitdir. If $R/gitdir's mtime is older than a limit, and it points to nowhere, worktrees/id is to be pruned. - If $R/locked exists, worktrees/id is not supposed to be pruned. If $R/locked exists and $R/gitdir's mtime is older than a really long limit, warn about old unused repo. - git checkout --to is supposed to make a hard link named $R/link pointing to the .git file on supported file systems to help detect the user manually deleting the checkout. If $R/link exists and its link count is greated than 1, the repo is kept. Helped-by: Marc Branchaud marcn...@xiplink.com Helped-by: Eric Sunshine sunsh...@sunshineco.com Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- Documentation/git-checkout.txt | 20 +++ Documentation/git-prune.txt| 3 + Documentation/gitrepository-layout.txt | 19 ++ builtin/checkout.c | 19 +- builtin/prune.c| 95 ++ setup.c| 13 t/t2026-prune-linked-checkouts.sh (new +x) | 84 ++ 7 files changed, 251 insertions(+), 2 deletions(-) create mode 100755 t/t2026-prune-linked-checkouts.sh diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt index c101575..0fd3bab 100644 --- a/Documentation/git-checkout.txt +++ b/Documentation/git-checkout.txt @@ -434,6 +434,26 @@ thumb is do not make any assumption about whether a path belongs to $GIT_DIR or $GIT_COMMON_DIR when you need to directly access something inside $GIT_DIR. Use `git rev-parse --git-path` to get the final path. +When you are done with a linked working tree you can simply delete it. +You can clean up any stale $GIT_DIR/worktrees entries via `git prune +--worktrees` in the main worktree or any linked worktree. + +If you move a linked working directory to another file system, or +within a file system that does not support hard links, you need to run +at least one git command inside the linked working directory +(e.g. `git status`) in order to update its entry in $GIT_DIR/worktrees +so that it does not get automatically removed. + +To prevent `git prune --worktrees` from deleting a $GIT_DIR/worktrees +entry (which can be useful in some situations, such as when the +entry's working tree is stored on a portable device), add a file named +'locked' to the entry's directory. The file contains the reason in +plain text. For example, if a linked working tree's `.git` file points +to `/path/main/.git/worktrees/test-next` then a file named +`/path/main/.git/worktrees/test-next/locked` will prevent the +`test-next` entry from being pruned. See +linkgit:gitrepository-layout[5] for details. + EXAMPLES diff --git a/Documentation/git-prune.txt b/Documentation/git-prune.txt index 7a493c8..a0ea381 100644 --- a/Documentation/git-prune.txt +++ b/Documentation/git-prune.txt @@ -48,6 +48,9 @@ OPTIONS --expire time:: Only expire loose objects older than time. +--worktrees:: + Prune stale worktree information in $GIT_DIR/worktrees. + head...:: In addition to objects reachable from any of our references, keep objects diff --git a/Documentation/gitrepository-layout.txt b/Documentation/gitrepository-layout.txt index 8228450..2b30a92 100644 --- a/Documentation/gitrepository-layout.txt +++ b/Documentation/gitrepository-layout.txt @@ -259,6 +259,25 @@ worktrees:: $GIT_COMMON_DIR is set and $GIT_COMMON_DIR/worktrees will be used instead. +worktrees/id/gitdir:: + A text file containing the absolute path back to the .git file + that points to here. This is used to check if the linked + repository has been manually removed and there is no need to + keep this directory any more. mtime of this file should be + updated every time the linked repository is accessed. + +worktrees/id/locked:: + If this file exists, the linked repository may be on a + portable device and not available. It does not mean that the + linked repository is gone and `worktrees/id` could be + removed. The file's content contains a reason string on why + the repository is locked. + +worktrees/id/link:: + If this file exists, it is a hard link to the linked .git + file. It is used to detect if the linked repository is + manually removed. + SEE ALSO linkgit:git-init[1], diff --git a/builtin/checkout.c b/builtin/checkout.c index ad10f99..ab46af9 100644 --- a/builtin/checkout.c +++ b/builtin/checkout.c @@ -826,7 +826,7 @@ static int
Re: [PATCH v2 28/32] gc: support prune --worktrees
And this is the update as suggested in 23/32 [1]
[1] http://thread.gmane.org/gmane.comp.version-control.git/256210/focus=256849
-- 8 --
Subject: [PATCH] gc: support prune --worktrees
Helped-by: Marc Branchaud marcn...@xiplink.com
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/config.txt | 7 +++
Documentation/git-checkout.txt | 11 +++
builtin/gc.c | 10 ++
3 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 98b8ef0..8351c8a 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1212,6 +1212,13 @@ gc.pruneexpire::
now may be used to disable this grace period and always prune
unreachable objects immediately.
+gc.pruneworktreesexpire::
+ When 'git gc' is run, it will call
+ 'prune --worktrees --expire 3.months.ago'.
+ Override the grace period with this config variable. The value
+ now may be used to disable the grace period and prune
+ $GIT_DIR/worktrees immediately.
+
gc.reflogexpire::
gc.pattern.reflogexpire::
'git reflog expire' removes reflog entries older than
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 0fd3bab..6c14710 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -435,8 +435,11 @@ $GIT_DIR or $GIT_COMMON_DIR when you need to directly
access something
inside $GIT_DIR. Use `git rev-parse --git-path` to get the final path.
When you are done with a linked working tree you can simply delete it.
-You can clean up any stale $GIT_DIR/worktrees entries via `git prune
---worktrees` in the main worktree or any linked worktree.
+The working tree's entry in the repository's $GIT_DIR/worktrees
+directory will eventually be removed automatically (see
+`gc.pruneworktreesexpire` in linkgit::git-config[1]), or you can run
+`git prune --worktrees` in the main worktree or any linked worktree to
+clean up any stale entries in $GIT_DIR/worktrees.
If you move a linked working directory to another file system, or
within a file system that does not support hard links, you need to run
@@ -444,8 +447,8 @@ at least one git command inside the linked working directory
(e.g. `git status`) in order to update its entry in $GIT_DIR/worktrees
so that it does not get automatically removed.
-To prevent `git prune --worktrees` from deleting a $GIT_DIR/worktrees
-entry (which can be useful in some situations, such as when the
+To prevent a $GIT_DIR/worktrees entry from from being pruned (which
+can be useful in some situations, such as when the
entry's working tree is stored on a portable device), add a file named
'locked' to the entry's directory. The file contains the reason in
plain text. For example, if a linked working tree's `.git` file points
diff --git a/builtin/gc.c b/builtin/gc.c
index 849a87c..35542f3 100644
--- a/builtin/gc.c
+++ b/builtin/gc.c
@@ -33,11 +33,13 @@ static int gc_auto_threshold = 6700;
static int gc_auto_pack_limit = 50;
static int detach_auto = 1;
static const char *prune_expire = 2.weeks.ago;
+static const char *prune_worktrees_expire = 3.months.ago;
static struct argv_array pack_refs_cmd = ARGV_ARRAY_INIT;
static struct argv_array reflog = ARGV_ARRAY_INIT;
static struct argv_array repack = ARGV_ARRAY_INIT;
static struct argv_array prune = ARGV_ARRAY_INIT;
+static struct argv_array prune_worktrees = ARGV_ARRAY_INIT;
static struct argv_array rerere = ARGV_ARRAY_INIT;
static char *pidfile;
@@ -83,6 +85,7 @@ static void gc_config(void)
git_config_get_int(gc.autopacklimit, gc_auto_pack_limit);
git_config_get_bool(gc.autodetach, detach_auto);
git_config_date_string(gc.pruneexpire, prune_expire);
+ git_config_date_string(gc.pruneworktreesexpire,
prune_worktrees_expire);
git_config(git_default_config, NULL);
}
@@ -290,6 +293,7 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
argv_array_pushl(reflog, reflog, expire, --all, NULL);
argv_array_pushl(repack, repack, -d, -l, NULL);
argv_array_pushl(prune, prune, --expire, NULL);
+ argv_array_pushl(prune_worktrees, prune, --worktrees, --expire,
NULL);
argv_array_pushl(rerere, rerere, gc, NULL);
gc_config();
@@ -359,6 +363,12 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
return error(FAILED_RUN, prune.argv[0]);
}
+ if (prune_worktrees_expire) {
+ argv_array_push(prune_worktrees, prune_worktrees_expire);
+ if (run_command_v_opt(prune_worktrees.argv, RUN_GIT_CMD))
+ return error(FAILED_RUN, prune_worktrees.argv[0]);
+ }
+
if (run_command_v_opt(rerere.argv, RUN_GIT_CMD))
return error(FAILED_RUN, rerere.argv[0]);
--
2.1.0.rc0.78.gc0d8480
-- 8 --
--
To unsubscribe from this list: send the line unsubscribe git in
[PATCH] t9300-fast-import: fix typo in test description
Signed-off-by: Stefan Beller stefanbel...@gmail.com --- t/t9300-fast-import.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh index 8a05449..8df0445 100755 --- a/t/t9300-fast-import.sh +++ b/t/t9300-fast-import.sh @@ -2866,7 +2866,7 @@ test_expect_success 'S: notemodify with garbage after sha1 dataref must fail' ' # # notemodify, mark in commit-ish # -test_expect_success 'S: notemodify with garbarge after mark commit-ish must fail' ' +test_expect_success 'S: notemodify with garbage after mark commit-ish must fail' ' test_must_fail git fast-import --import-marks=marks -EOF 2err commit refs/heads/Snotes committer $GIT_COMMITTER_NAME $GIT_COMMITTER_EMAIL $GIT_COMMITTER_DATE -- 2.1.0.238.gce1d3a9 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 23/23] rebase -i: enable options --signoff, --reset-author for pick, reword
Hi Michael, On 08/13/2014 02:47 PM, Michael Haggerty wrote: On 08/07/2014 01:59 AM, Fabian Ruch wrote: pick and reword are atomic to-do list commands in the sense that they open a new task which is closed after the respective command is completed. squash and fixup are not atomic. They create a new task which is not completed until the last squash or fixup is processed. I don't understand the distinction that you are attempting to draw between atomic and non-atomic commands. For example, in the following command list: pick 111 squash 222 fixup 333 the pick command doesn't seem very atomic, because the *end* result of the three commands is a single commit that is affected by all three commands. Right, when I wrote the commit message I was thinking in abstract terms so I implicitly thought of your example as a (single) squash/fixup command. Now it has become obvious that I wasn't very thorough with the implementation part. The git-rebase implementation is oblivious to the context when it processes 'pick' lines and your example shows how 'pick' lines can be part of squash/fixup command context. In conclusion, I intended to keep options disabled for squash/fixup commands but failed to do so because I neglected that a 'pick' line can initiate a squash/fixup command. Furthermore, if we change the example to pick 111 squash --reset-author 222 fixup --signoff 333 then isn't it clear that the user's intention was to apply both options, --reset-author and --signoff, to the resulting commit? This seems to suggest an interpretation of todo lists similar to what I was thinking of when writing the commit message, that is one in which pick is not oblivious to the neighbouring commands. It might be a problem that it forbids the (admittedly improbable) use case where --reset-author is used to rewrite the authorship to something recent and fixup to have an even more recent committership. To reconcile this kind of vertical interpretation with the horizontal specification of options one could introduce a todo list command taking the list of commits to be squashed as an argument. However, that seems to make it difficult to obtain the squash behaviour for some commits and the fixup behaviour for others that are part of the same chain. The alternative interpretation of todo lists as simplified batch scripts for git commands would allow the intended behaviour (--reset-author and --signoff applied to the resulting commit), not restrict the user relatively to what she can already do on the command line and give actually different meanings to the syntactically different todo lists pick 111 squash --reset-author 222 fixup --signoff 333 and pick 111 squash --signoff 222 fixup --reset-author 333 , which would be treated identically by an implementation that collects the options. The current meaning of squash/fixup seems to be valid in the batch interpretation. In other words, it seems to me that any options on such a chain of lines should be collected and applied to the final commit as a whole. To summarise, I think line options might be confusing if we interpret pick 111 squash --reset-author 222 fixup --signoff 333 as combine the changes of 111, 222, 333 concatenate the messages of 111 and 222 edit the message reset the authorship to the committership add a Signed-off-by: line and not as pick 111 pick -n 222 commit amend --reset-author -m $squash_msg pick -n 333 commit amend --signoff --edit . Thanks for pointing me at these issues. Atomic and non-atomic are really poorly-chosen terminology and the squash-initiating 'pick' might not be implemented correctly. Fabian -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug] git status -unormal -- 'foo[b]/' won't display content of 'foo[b]/
Hello, I found what look like a bug in git status: `git status -unormal foo[b]/` won't output the content of the directory foo[b] when `git status -unormal foo/` will output the content of the directory foo: $ mkdir 'foo[b]' $ touch 'foo[b]/bar' $ git status -unormal 'foo[b]/' On branch master Untracked files: (use git add file... to include in what will be committed) foo[b]/ nothing added to commit but untracked files present (use git add to track) $ mkdir 'foo' $ touch 'foo/bar' $ git status -unormal 'foo/' On branch master Untracked files: (use git add file... to include in what will be committed) foo/bar nothing added to commit but untracked files present (use git add to track) The documentation of git status contain nothing about treating bracket specially. Quoting the brackets do not solve the problem. see https://github.com/magit/magit/issues/1512 for discussion about it (in the case of git status --porcelain). -- Rémi Vanicat -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug] git status -unormal -- 'foo[b]/' won't display content of 'foo[b]/
On 2014-09-21 20.04, Rémi Vanicat wrote: Hello, I found what look like a bug in git status: `git status -unormal foo[b]/` won't output the content of the directory foo[b] when `git status -unormal foo/` will output the content of the directory foo: $ mkdir 'foo[b]' $ touch 'foo[b]/bar' $ git status -unormal 'foo[b]/' On branch master Untracked files: (use git add file... to include in what will be committed) foo[b]/ nothing added to commit but untracked files present (use git add to track) $ mkdir 'foo' $ touch 'foo/bar' $ git status -unormal 'foo/' On branch master Untracked files: (use git add file... to include in what will be committed) foo/bar nothing added to commit but untracked files present (use git add to track) The documentation of git status contain nothing about treating bracket specially. Quoting the brackets do not solve the problem. see https://github.com/magit/magit/issues/1512 for discussion about it (in the case of git status --porcelain). git status takes a pathspec as a parameter, which is not the same as a filename. A pathspec can contain wildcards like '*' or '?' or things like *[ch]. This is known as shell glob syntax (or so), and used automatically by all shells. Git allows to use git add *.[ch] (where the shell expands the glob) or git add '*.[ch]' where Git does the expansion. You can turn of the glob handling in a pathspec by using this: GIT_LITERAL_PATHSPECS=1 git status -unormal 'foo[b]/' On branch master Initial commit Untracked files: (use git add file... to include in what will be committed) foo[b]/bar --- Side note: If somebody feels that the documentation can be better: we appreciate patches. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] t6031-test-merge-recursive: Forgot to add file to be committed
Signed-off-by: Stefan Beller stefanbel...@gmail.com --- t/t6031-merge-recursive.sh | 1 + 1 file changed, 1 insertion(+) diff --git a/t/t6031-merge-recursive.sh b/t/t6031-merge-recursive.sh index a953f1b..6464a16 100755 --- a/t/t6031-merge-recursive.sh +++ b/t/t6031-merge-recursive.sh @@ -13,6 +13,7 @@ test_expect_success 'mode change in one branch: keep changed version' ' git commit -m a git checkout -b b1 master test_chmod +x file1 + git add file1 git commit -m b1 git checkout a1 git merge-recursive master -- a1 b1 -- 2.1.0.238.gce1d3a9 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] merge-recursive: Fix copy-paste mistake
The following issue was found by scan.coverity.com (ID: 1049510), and claimed to be likely a copy-paste mistake. Introduced in 331a1838b (2010-07-02, Try normalizing files to avoid delete/modify conflicts when merging), which is quite a long time ago, so I'm rather unsure if it's of any impact or just went unnoticed. The line after the changed line has a comparison of 'o.len' to 'a.len', so we should assume the lengths may be different. I'd be happy to have a test for this bug(?) attached to t6031-merge-recursive.sh, but I did not manage to come up with a test in a reasonable amount of time. Signed-off-by: Stefan Beller stefanbel...@gmail.com --- merge-recursive.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/merge-recursive.c b/merge-recursive.c index 22315c3..d63524c 100644 --- a/merge-recursive.c +++ b/merge-recursive.c @@ -1555,7 +1555,7 @@ static int blob_unchanged(const unsigned char *o_sha, * unchanged since their sha1s have already been compared. */ if (renormalize_buffer(path, o.buf, o.len, o) | - renormalize_buffer(path, a.buf, o.len, a)) + renormalize_buffer(path, a.buf, a.len, a)) ret = (o.len == a.len !memcmp(o.buf, a.buf, o.len)); error_return: -- 2.1.0.238.gce1d3a9 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: diff-index does not consider a removed submodule to be staged with --ignore-submodules
Am 20.09.2014 um 18:20 schrieb Daniel Hahler:
After staging the removal of a submodule, diff-index does not consider this when
--ignore-submodules is being used:
# In a repository with submodule sm:
% git rm --cached sm
% git diff-index --cached --quiet --ignore-submodules HEAD
% echo $?
0
% git status
On branch master
Changes to be committed:
(use git reset HEAD file... to unstage)
deleted:sm
git status --ignore-submodules behaves the same.
From the man page of --ignore-submodules it looks like the option is meant to
prevent scanning of submodules itself, but in this case the main repository is affected.
Sorry, but I don't know what man page you are talking about here ...
This command is used by zsh's vcs_info module (in
Functions/VCS_Info/Backends/VCS_INFO_get_data_git):
if (( querystaged )) ; then
if ${vcs_comm[cmd]} rev-parse --quiet --verify HEAD /dev/null ; then
${vcs_comm[cmd]} diff-index --cached --quiet --ignore-submodules HEAD
2 /dev/null
(( $? $? != 128 )) gitstaged=1
Is this a bug/oversight in Git or by design?
Is there a better way to detect if there are any staged changes?
It might be that --ignore-submodules=dirty is what you want. It will
report changes in the committed submodule SHA-1, added and removed
submodules but won't care about any modifications inside the submodule.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug/request: the empty string should be a valid git note
On Sep 20, 2014, at 18:44, Johan Herland wrote: At least, we should fix git notes add -C e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 Whether we should also change git notes add -m '' to create an empty note, or leave it as-is, (i.e. similar in spirit to git commit -m ''), I'll leave up to further discussion. The help for git commit has this: --allow-empty-message Like --allow-empty this command is primarily for use by foreign SCM interface scripts. It allows you to create a commit with an empty commit message without using plumbing commands like git-commit-tree(1). Why not add the same/similar option to git notes add? So this: git notes add --allow-empty-message -m '' creates an empty note. (Perhaps --allow-empty-note should be an alias?) With your patch to allow -C e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 there's already support for it, it just needs the option parsing added. :) --Kyle -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug] git status -unormal -- 'foo[b]/' won't display content of 'foo[b]/
On Mon, Sep 22, 2014 at 2:52 AM, Torsten Bögershausen tbo...@web.de wrote: git status takes a pathspec as a parameter, which is not the same as a filename. A pathspec can contain wildcards like '*' or '?' or things like *[ch]. This is known as shell glob syntax (or so), and used automatically by all shells. Git allows to use git add *.[ch] (where the shell expands the glob) or git add '*.[ch]' where Git does the expansion. From the top of my head, pathspec should match as if it's literal string too. Not sure if it applies to this case. I'll check later.. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello,
Hello, I am pleased to contact you after viewing your profile i am interested in having communication with you and if possible to be your friend, please dear write me back using my e-mail address(devineadam...@yahoo.com) i am waiting to hear from you soon. yours new friend Divine. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
