Re: [Bug] git status -unormal -- 'foo[b]/' won't display content of 'foo[b]/
On Mon, Sep 22, 2014 at 8:24 AM, Duy Nguyen pclo...@gmail.com wrote: 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.. FWIW the problem is in dir.c, function common_prefix_len(). We use this one to determine a shared parent directory, e.g. foo/bar and foo/baarr share foo/, so that we could start looking for untracked files from foo instead of .. The shared directory search only cares about non-wildcard letters. So in the case of foo/ it finds the shared dir foo, but in foo[b]/ it stops at '[' and decides the shared dir is .. But this difference should not lead to any differences in output because that's more about traversal optimization. But somehow we treat the first directory different than subdirs. If a subdir is entirely untracked/ignored, we show subdir/ (with -unormal) but if it's the first examined directory then we show everything inside. This is something we should fix if you guys really depend on a consistent behavior. But if it's fixed, then foo/ case above would show foo/ not foo/bar. Or just call it a quirk of -unormal and magit should use -uall instead. -- 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: [PATCH RFC] git-am: support any number of signatures
On Wed, Jun 18, 2014 at 10:51:04AM -0700, Junio C Hamano wrote: Junio C Hamano gits...@pobox.com writes: On Tue, Jun 17, 2014 at 8:09 PM, Michael S. Tsirkin m...@redhat.com wrote: OK, after looking into this for a while, I realize this is a special property of the Signed-off-by footer. For now I think it's reasonable to just avoid de-duplicating other footers if any. Agree? Not really. I'd rather see git am hardcode as little such policy as possible. We do need to support S-o-b footer and the policy we defined for it long time ago, if only for backward compatiblity, but for any other footers, policy decision such as dedup by default isn't something am should know about. By the way, append without looking for dups is a policy decision that is as bad to have as append with dedup. I'd rather not to see am.signoff, or any name that implies what the -s option to the command is about for that matter, to be used in futzing with the trailers other than S-o-b in any way. As I understand it, our longer term goal is to defer that task, including the user-programmable policy decisions, to something like the 'trailer' Christian started. I suspect that it may add unnecessary work later if we overloaded signoff with a similar feature with the change under discussion. I would feel safer to see it outlined how we envision to transition to a more generic 'trailer' solution later if we were to enhance am with am.signoff now. Thanks. Hi Junio, Christian, it's been a while. I see that the work on trailers is going on. I tried going over the documentation but I could not figure out how would one implement multiple signatures using the trailers mechanism. As a reminder, this old patchset (that I replied to) enhanced git am -s with an option to add different signatures depending on the option passed to the -s flag. E.g. I have [am a] signoff = Acked-by: Michael S. Tsirkin m...@redhat.com [am r] signoff = Reviewed-by: Michael S. Tsirkin m...@redhat.com [am t] signoff = Tested-by: Michael S. Tsirkin m...@redhat.com and now: git am -s art adds all 3 signatures when applying the patch. Any help will be appreciated. -- MST -- 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 v5 02/35] api-lockfile: expand the documentation
On 09/16/2014 10:25 PM, Jonathan Nieder wrote: Michael Haggerty wrote: Document a couple more functions and the flags argument as used by hold_lock_file_for_update() and hold_lock_file_for_append(). Thanks. [...] --- a/Documentation/technical/api-lockfile.txt +++ b/Documentation/technical/api-lockfile.txt @@ -28,9 +28,39 @@ hold_lock_file_for_update:: the final destination (e.g. `$GIT_DIR/index`) and a flag `die_on_error`. Attempt to create a lockfile for the destination and return the file descriptor for writing -to the file. If `die_on_error` flag is true, it dies if -a lock is already taken for the file; otherwise it -returns a negative integer to the caller on failure. +to the file. The flags parameter is a combination of ++ +-- Context: this document has structure lockfile API Explanation of purpose (nice!). The functions - Quick descriptions of each of the four functions `hold_lock_file_for_update`, `commit_lock_file`, `rollback_lock_file`, `close_lock_file`. Reminder about lifetime of the lock_file structure. Description of cleanup convention (thou shalt either commit or roll back; if you forget to, the atexit handler will roll back for you). Long warning about the harder use cases. The above thou shalt was a lie --- you can also close_lock_file if you know what you're doing [jn: why is that function part of the public API?]. What's nice about the existing structure is that you can get a sense of how to use the API at a glance. Would there be a way to add this extra information while preserving that property? E.g.: lockfile API Nice brief explanation of purpose (is this the API I want to use?), as before. Calling sequence The caller: * Allocates a variable `struct lock_file lock` in the bss section or heap. Because the `lock_file` structure is used in an `atexit(3)` handler, its storage has to stay throughout the life of the program. It cannot be an auto variable allocated on the stack. * Attempts to create a lockfile by passing that variable and the filename of the final destination (e.g. `$GIT_DIR/index`) to `hold_lock_file_for_update` or `hold_lock_file_for_append`. + If the `die_on_error` flag is true, git dies if a lock is already taken for the file. * Writes new content for the destination file by writing to `lock-fd`. When finished writing, the caller can: * Close the file descriptor and rename the lockfile to its final destination by calling `commit_lock_file`. * Close the file descriptor and remove the lockfile by calling `rollback_lock_file`. * Close the file descriptor without removing or renaming the lockfile by calling `close_lock_file`. If you do not call one of `commit_lock_file`, `rollback_lock_file`, and `close_lock_file` and instead simply `exit(3)` from the program, an `atexit(3)` handler will close and remove the lockfile. You should never call `close(2)` on `lock-fd` yourself~ Otherwise the ... Error handling -- Functions return 0 on success, -1 on failure. errno is? isn't? meaningful on error. ... description of unable_to_lock_error and unable_to_lock_die here ... Flags - LOCK_NODEREF:: Usually symbolic links in the destination path are resolved and the lockfile is created by adding .lock to the resolved path. If `LOCK_NODEREF` is set, then the lockfile is created by adding .lock to the path argument itself. What is the user-visible effect of that flag? When would I want to pass that flag, and when wouldn't I? LOCK_DIE_ON_ERROR:: If a lock is already taken for the file, `die()` with an error message. If this option is not specified, trying to hold a lock file that is already taken will return -1 to the caller. Sensible? Jonathan OK, in the next reroll I will revise the documentation pretty thoroughly. Please let me know what you think. Michael -- Michael Haggerty mhag...@alum.mit.edu -- 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 v5 10/35] cache.h: define constants LOCK_SUFFIX and LOCK_SUFFIX_LEN
On 09/16/2014 11:05 PM, Jonathan Nieder wrote: Michael Haggerty wrote: There are a few places that use these values, so define constants for them. Seems like a symptom of the API leaving out a useful helper (e.g., something that strips off the lock suffix and returns a memdupz'd filename). I will add a function get_locked_file_path(). [...] --- a/cache.h +++ b/cache.h @@ -570,6 +570,10 @@ extern void fill_stat_cache_info(struct cache_entry *ce, struct stat *st); #define REFRESH_IN_PORCELAIN0x0020 /* user friendly output, not needs update */ extern int refresh_index(struct index_state *, unsigned int flags, const struct pathspec *pathspec, char *seen, const char *header_msg); +/* String appended to a filename to derive the lockfile name: */ +#define LOCK_SUFFIX .lock +#define LOCK_SUFFIX_LEN 5 My suspicion is that error handling would be better if fewer callers outside of lockfile.c did the '- LOCK_SUFFIX_LEN' dance, so this seems like a step in the wrong direction. Adding constants in lockfile.c would make sense, though. I agree that other call sites shouldn't be grubbing around in the lock_file data structure. But with the addition of get_locked_file_path(), the only remaining user of these constants is in refs.c, in check_refname_component(): if (cp - refname = LOCK_SUFFIX_LEN !memcmp(cp - LOCK_SUFFIX_LEN, LOCK_SUFFIX, LOCK_SUFFIX_LEN)) return -1; /* Refname ends with .lock. */ I think it is forgivable there. Michael -- Michael Haggerty mhag...@alum.mit.edu -- 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 v5 09/35] lockfile.c: document the various states of lock_file objects
On 09/16/2014 11:03 PM, Jonathan Nieder wrote:
Michael Haggerty wrote:
--- a/lockfile.c
+++ b/lockfile.c
@@ -4,6 +4,63 @@
#include cache.h
#include sigchain.h
+/*
+ * File write-locks as used by Git.
+ *
+ * When a file at $FILENAME needs to be written, it is done as
+ * follows:
This overlaps a lot with the API doc, which makes me worry a little
about it going out of date. Would improving the API doc help, or if
aspects are especially relevant here, is there a way to summarize them
more quickly to avoid some of the redundancy?
[...]
+ * A lock_file object can be in several states:
Would it make sense for this information to go near the definition of
'struct lock_file'? That's where I'd start if I were looking for
information on what states a lock_file can be in.
I agree with your point about overlap. I will split the documentation
into two parts with less redundancy:
* Documentation/technical/api-lockfile.txt: How to use the API.
* lockfile.{c,h}: Internal implementation details.
I think the implementation details would get lost among the thousand
things in cache.h. So instead, I will add a commit on top of the patch
series that splits out a lockfile.h header file (which I think is a good
idea anyway), and moves the internal documentation there. Sound good?
Michael
--
Michael Haggerty
mhag...@alum.mit.edu
--
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: Branching workflow
Hello!, I have been using this workflow you suggested, and I happen to find it really good fitting in many projects I am. I would like to seek for a little more advice. I keep rebasing all my work each time master branch is updated, and I would like to know if this is usually done or not. The workflow is not using emails, but each developer has his clone where he works, and occasionally sends work to the gerrit tool we use, upgrading the patch with each master update. I know this is a crazy workflow, and I would like to know when you usually consider to update the sent patch with a rebase. Cheers, -- Javier Domingo Cansino -- 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] unblock and unignore SIGPIPE
Johannes Sixt j...@kdbg.org writes:
+static void restore_sigpipe_to_default(void)
+{
+sigset_t unblock;
+
+sigemptyset(unblock);
+sigaddset(unblock, SIGPIPE);
+sigprocmask(SIG_UNBLOCK, unblock, NULL);
+signal(SIGPIPE, SIG_DFL);
+}
This does not build on MinGW due to missing sigaddset() and
sigprocmask(). I've a patch that adds dummies for them (but I ran out of
time to complete it for submission). But then the test cases ...
+test_expect_success 'a constipated git dies with SIGPIPE' '
+OUT=$( ((large_git; echo $? 13) | :) 31 )
+test $OUT -eq 141
+'
+
+test_expect_success 'a constipated git dies with SIGPIPE even if parent
ignores it' '
+OUT=$( ((trap PIPE; large_git; echo $? 13) | :) 31 )
+test $OUT -eq 141
+'
... fail always because we neither get SIGPIPE (we don't have it on
Windows) nor do we see a write error (e.g. EPIPE) when writing to the
pipe. Should I protect these tests with !MINGW or would it be an option
to drop these tests alltogether?
Let's do !MINGW for now, unless somebody can think of a reason why
this change and tests are a bad idea (e.g. we are not in the
business of preventing users from shooting themselves; have the
users bug those who wrote the software that spawns us with SIGPIPE
ignored, to which I am sympathetic to some degree but not very much
because I am also a practical person).
Thanks.
--
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] notes: accept any ref for merge
Johan Herland jo...@herland.net writes: Assuming that this is we all agree to go in that direction, let's make a list of things to be done to codify it, and do them. For a starter, I think these are needed, perhaps? ... Sounds good to me. At least that would ... ... In addition to that we might want to consider ... Yes, I specifically meant my list as a starter, not wanting to make an exhaustive list myself. -- 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
Kyle J. McKay mack...@gmail.com writes: 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? Sounds like a good direction to go. -- 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] mailinfo: resolve -Wstring-plus-int warning
Eric Sunshine sunsh...@sunshineco.com writes:
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) ...
~~~^
And why is that a warning-worthy violation? Can we have them fix
their compiler instead?
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,
--
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] sha1_file: don't convert off_t to size_t too early to avoid potential die()
Steffen Prohaska proha...@zib.de writes: 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. Yes, if we want to futz in this area, I think that would be the right approach. -- 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 RFC] git-am: support any number of signatures
Michael S. Tsirkin m...@redhat.com writes: Hi Junio, Christian, it's been a while. I see that the work on trailers is going on. I tried going over the documentation but I could not figure out how would one implement multiple signatures using the trailers mechanism. Good. Christian has been rerolling the series numerous times but he has been working without getting much input from people who would envision using the mechanism themselves (and my comments on the series do not count because I am not as one of them). Please bombard us with questions and usability improvement suggestions ;-) -- 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] Query string not being phrased correctly when question marks present in config URL.
Cause: [remote repo] url = http://example.com/git/example.com?foo=bar There is a question mark in the URL of the repo URL. Effect (Taken from Apache logs): [22/Sep/2014:14:12:07 -0400] GET /git/example.com?foo=bar/info/refsservice=git-receive-pack HTTP/1.1 403 207 - git/1.9.4.msysgit.1 Git attempts to correct the issue by making the query string continue using ampersands where it would have started the original query string. Expected outcome: The git client should move the ?foo=bar onto the beginning (or end) of the query string that it is creating. For example: [22/Sep/2014:14:12:07 -0400] GET /git/example.com/info/refs?foo=barservice=git-receive-pack HTTP/1.1 403 207 - git/1.9.4.msysgit.1 This is caused on the git client, double checked with Wireshark. I have not tested this on HTTPS, but imagine the output is the same. -- 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] mingw.h: add dummy functions for sigset_t operations
Windows does not have POSIX-like signals, and so we ignore all
operations on the non-existent signal mask machinery.
Do not turn sigemptyset into a function, but leave it a macro that
erases the code in the argument because it is used to set sa_mask
of a struct sigaction, but our dummy in mingw.h does not have that
member.
Signed-off-by: Johannes Sixt j...@kdbg.org
---
compat/mingw.h | 7 ++-
t/t0005-signals.sh | 4 ++--
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/compat/mingw.h b/compat/mingw.h
index 0b5f2fe..0e42653 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -69,7 +69,6 @@ struct sigaction {
sig_handler_t sa_handler;
unsigned sa_flags;
};
-#define sigemptyset(x) (void)0
#define SA_RESTART 0
struct itimerval {
@@ -116,6 +115,12 @@ static inline int fcntl(int fd, int cmd, ...)
}
/* bash cannot reliably detect negative return codes as failure */
#define exit(code) exit((code) 0xff)
+#define sigemptyset(x) (void)0
+static inline int sigaddset(sigset_t *set, int signum)
+{ return 0; }
+#define SIG_UNBLOCK 0
+static inline int sigprocmask(int how, const sigset_t *set, sigset_t *oldset)
+{ return 0; }
/*
* simple adaptors
diff --git a/t/t0005-signals.sh b/t/t0005-signals.sh
index 638a355..aeea50c 100755
--- a/t/t0005-signals.sh
+++ b/t/t0005-signals.sh
@@ -39,12 +39,12 @@ test_expect_success 'create blob' '
git add file
'
-test_expect_success 'a constipated git dies with SIGPIPE' '
+test_expect_success !MINGW 'a constipated git dies with SIGPIPE' '
OUT=$( ((large_git; echo $? 13) | :) 31 )
test $OUT -eq 141
'
-test_expect_success 'a constipated git dies with SIGPIPE even if parent
ignores it' '
+test_expect_success !MINGW 'a constipated git dies with SIGPIPE even if parent
ignores it' '
OUT=$( ((trap PIPE; large_git; echo $? 13) | :) 31 )
test $OUT -eq 141
'
--
2.0.0.12.gbcf935e
--
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
How to compile Git with NDK?
I run the following on Ubuntu: fe@BLD01:~/code/git$ autoconf fe@BLD01:~/code/git$ ./configure --prefix=/home/fe/git-arm --build=x86_64-linux-gnu --host=arm-linux-androideabi configure: Setting lib to 'lib' (the default) configure: Will try -pthread then -lpthread to enable POSIX Threads. configure: CHECKS for site configuration checking for arm-linux-androideabi-gcc... arm-linux-androideabi-gcc checking whether the C compiler works... no configure: error: in `/home/fe/code/git': configure: error: C compiler cannot create executables See `config.log' for more details I have my NDK's prebuilt GCC 4.8 toolchain on PATH (the bin folder). Can someone help me cross compile Git using Android NDK toolchain? Thanks. -- 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] archive: support filtering paths with glob
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
+static void queue_directory(const unsigned char *sha1,
+ const char *base, int baselen, const char *filename,
+ unsigned mode, int stage, struct archiver_context *c)
+{
+ struct directory *d;
+ d = xmallocz(sizeof(*d) + baselen + 1 + strlen(filename));
+ d-up = c-bottom;
+ d-baselen = baselen;
+ d-mode= mode;
+ d-stage = stage;
+ c-bottom = d;
+ d-len = sprintf(d-path, %.*s%s/, baselen, base, filename);
+ hashcpy(d-sha1, sha1);
+}
+
+static int write_directory(struct archiver_context *c)
+{
+ struct directory *d = c-bottom;
+ int ret;
+
+ if (!d)
+ return 0;
+ c-bottom = d-up;
+ d-path[d-len - 1] = '\0'; /* no trailing slash */
+ ret =
+ write_directory(c) ||
By recursing into itself using c-bottom set to one level higher, we
first flush all the leading directories.
+ write_archive_entry(d-sha1, d-path, d-baselen,
+ d-path + d-baselen, d-mode,
+ d-stage, c) != READ_TREE_RECURSIVE;
And after the entries for the leading directories, we write an entry
for this directory.
Which makes sense; presumably the caller will then write an entry
that hangs this directory after calling this.
When we have a/b/c and a/d/e to be written, the first round would
write a/ and then a/b/ with the above, and presumably elsewhere
somebody will write a/b/c; next time around we do need to write a/d/
but we wouldn't want to write a/ itself. How is this code
preventing the recursion going all the way up every time to avoid
repeating a/?
Puzzled...
+ free(d);
+ return ret ? -1 : 0;
+}
+
+static int queue_or_write_archive_entry(const unsigned char *sha1,
+ const char *base, int baselen, const char *filename,
+ unsigned mode, int stage, void *context)
+{
+ struct archiver_context *c = context;
+
+ while (c-bottom
+!(baselen = c-bottom-len
+ !strncmp(base, c-bottom-path, c-bottom-len))) {
Is this comparison, which does not see if the substring matches from
the beginning but without making sure that the tail of the shorter
substring coincides with the directory boundary in the longer
string, correctly done? Or does it consider abcd/ef is inside abc/?
Ah, we should be OK as I think base, baselen is passed with a
trailing slash appended in read_tree_1() when it recurses, so this
comparison is correct.
--
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] Documentation/git-rebase.txt: discuss --fork-point assumption of vanilla git rebase in DESCRIPTION.
Sergey Organov sorga...@gmail.com writes:
Vanilla git rebase defaults to --fork-point that in some cases
makes behavior very different from git rebase upstream,
where --no-fork-point is assumed. This fact was not mentioned in
the DESCRIPTION section of the manual page, even though the case of
omitted upstream was otherwise discussed. That in turn made actual
behavior of vanilla git rebase hardly discoverable.
While we are at it, clarify the --fork-point description itself as well.
Signed-off-by: Sergey Organov sorga...@gmail.com
---
Documentation/git-rebase.txt | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 4138554..73e1e1c 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -21,15 +21,16 @@ If branch is specified, 'git rebase' will perform an
automatic
it remains on the current branch.
If upstream is not specified, the upstream configured in
-branch.name.remote and branch.name.merge options will be used; see
-linkgit:git-config[1] for details. If you are currently not on any
-branch or if the current branch does not have a configured upstream,
-the rebase will abort.
+branch.name.remote and branch.name.merge options will be used (see
+linkgit:git-config[1] for details) and the `--fork-point` option is
+assumed. If you are currently not on any branch or if the current
+branch does not have a configured upstream, the rebase will abort.
OK. When you do not tell rebase with respect to what exact _commit_
the operation is to be done, then we will enable --fork-point, which
makes perfect sense because it is clear that the user is rebasing
with respect to a _branch_, for which we may find a place better
than its current tip to rebase onto if we look at its reflog.
It is debatable if we should do the same when the user tells us to
rebase with respect to a specific _branch_ by giving the 'upstream'
argument, but that is an entirely separate issue. We might want to
do a similar command line heuristics to tell between the branch
switching git checkout master (which is an operation about a
branch) and head detaching git checkout refs/heads/master^0 (which
is an operation about a commit) if we want to help the users by
auto-enabling fork-point mode.
All changes made by commits in the current branch but that are not
in upstream are saved to a temporary area. This is the same set
-of commits that would be shown by `git log upstream..HEAD` (or
-`git log HEAD`, if --root is specified).
+of commits that would be shown by `git log upstream..HEAD`; or by
+`git log fork_point..HEAD`, if --fork-point is either specified or
+assumed; or by `git log HEAD`, if --root is specified.
OK. fork_point is a new term this patch introduces to this
document. Do we define what it is anywhere in this document, or
would it help the readers to add something like ... where fork_point
is computed in such and such way (see ... for details)?
@@ -331,9 +332,8 @@
link:howto/revert-a-faulty-merge.html[revert-a-faulty-merge How-To] for
details)
between `upstream` and `branch` when calculating which commits have
have been introduced by `branch` (see linkgit:git-merge-base[1]).
+
-If no non-option arguments are given on the command line, then the default is
-`--fork-point @{u}` otherwise the `upstream` argument is interpreted
literally
-unless the `--fork-point` option is specified.
+If either upstream or --root is given on the command line, then the
+default is `--no-fork-point`, otherwise the default is `--fork-point`.
Good. The original, especially the mention of @{u}, does not make
any sense and updated text reads more clearly.
Thanks.
--
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] sha1_file: don't convert off_t to size_t too early to avoid potential die()
Steffen Prohaska proha...@zib.de writes:
This patch should be applied on top of sp/stream-clean-filter.
... or it can be squashed in as a fix, as the topic is not yet in
'next'.
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;
}
--
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] mailinfo: resolve -Wstring-plus-int warning
Eric Sunshine sunsh...@sunshineco.com writes: however, the solution in this patch allows us drop a couple strlen()s in favor of sizeof()s. It is actually not a very good justification when you know you care about the length of the string. A decent compiler ought to know the length of a constant string can be computed at the compilation time. Let's at least not do that part of the change. -- 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 14-09-21 05:50 AM, Duy Nguyen wrote: 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? *shrug* To me it seems better to leave it at the end here. If we really want people to follow this advice, it should appear where GIT_DIR is officially documented. I think this is the Environment Variables section of the Documentation/git.txt file. Probably GIT_COMMON_DIR should also be documented there. (Sorry, I don't have time to whip up a patch right now.) M. 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 -- 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
On 14-09-21 06:29 AM, Duy Nguyen wrote: Here we go again. Thanks both for the suggestions. The documentation looks good to me. FWIW: Signed-off-by: Marc Branchaud marcn...@xiplink.com M. -- 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. +
Re: [PATCH v2 28/32] gc: support prune --worktrees
On 14-09-21 06:43 AM, Duy Nguyen wrote:
And this is the update as suggested in 23/32 [1]
[1] http://thread.gmane.org/gmane.comp.version-control.git/256210/focus=256849
Looks good!
FWIW:
Signed-off-by: Marc Branchaud marcn...@xiplink.com
M.
-- 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
Re: [PATCH] mailinfo: resolve -Wstring-plus-int warning
On Mon, Sep 22, 2014 at 1:41 PM, Junio C Hamano gits...@pobox.com wrote: Eric Sunshine sunsh...@sunshineco.com writes: 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) ... ~~~^ And why is that a warning-worthy violation? Not being privy to Apple's decision making process, I can only guess that it is in response to their new Swift programming language which they are pushing heavily on iOS (and soon Mac OS X), in which '+' is the string concatenation operator. For projects written in Swift and incorporating legacy or portable components in C, C++, or Objective-C, the warning may help programmer's avoid the pitfall of thinking that '+' is also concatenation in the C-based languages. Can we have them fix their compiler instead? If the above supposition is correct, then it's likely that Apple considers this a feature, not a bug which needs to be fixed. Resolve this issue. Signed-off-by: Eric Sunshine sunsh...@sunshineco.com -- 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: How to compile Git with NDK?
On 22.09.2014 21:04, Robert Dailey wrote: I run the following on Ubuntu: fe@BLD01:~/code/git$ autoconf fe@BLD01:~/code/git$ ./configure --prefix=/home/fe/git-arm --build=x86_64-linux-gnu --host=arm-linux-androideabi configure: Setting lib to 'lib' (the default) configure: Will try -pthread then -lpthread to enable POSIX Threads. configure: CHECKS for site configuration checking for arm-linux-androideabi-gcc... arm-linux-androideabi-gcc checking whether the C compiler works... no configure: error: in `/home/fe/code/git': configure: error: C compiler cannot create executables See `config.log' for more details I have my NDK's prebuilt GCC 4.8 toolchain on PATH (the bin folder). Can someone help me cross compile Git using Android NDK toolchain? Thanks. You don't need autoconf, just type 'make' and you'll be fine. Please read the file INSTALL for installation instructions. Stefan -- 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 v15 11/11] Documentation: add documentation for 'git interpret-trailers'
This has quite a few trailing whitespace errors in the patch in the documentation part. It would mean that people who try to follow along the examples would have difficult time deciphering where trailing whitespaces are necessary. For example +* Configure a commit template with some trailers with empty values, + then configure a commit-msg hook that uses 'git interpret-trailers' + to remove trailers with empty values and to add a 'git-version' + trailer: ++ + +$ cat commit_template.txt EOF + ***subject*** + + ***message*** + + Fixes: + Cc: ... This presents the example in the least useful way. The leading are coming from $PS2 so people cannot cut paste to follow along on their interactive shell session, but cutting and pasting from a machine-readable copy of the document would be the only way to preserve the trailing SP on lines that begin with Fixes:, Cc: and friends. On the other hand, those who type each line while eyeballing the documentation (because it is not cut-and-paste ready due to $PS2) may not spot the trailing SP on these lines. Can we think of a way to make the necessary trailing SP stand out? -- 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] mailinfo: resolve -Wstring-plus-int warning
On Mon, Sep 22, 2014 at 4:50 PM, Junio C Hamano gits...@pobox.com wrote: Eric Sunshine sunsh...@sunshineco.com writes: however, the solution in this patch allows us drop a couple strlen()s in favor of sizeof()s. It is actually not a very good justification when you know you care about the length of the string. A decent compiler ought to know the length of a constant string can be computed at the compilation time. Indeed, which is why I mentioned this only in the commentary rather than the commit message; but I was also thinking of some of the less-than-decent compilers with which git is sometimes built. Let's at least not do that part of the change. I don't have strong feelings about it. -- 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
On Sun, Sep 21, 2014 at 6:29 AM, Duy Nguyen pclo...@gmail.com wrote: 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 work tree. Nit: In the rest of the documentation, you have consistently spelled out working tree, so the (poor) example you copied from my email, which says worktree, is an anomaly. My bad. Plus, you have a mix of worktree and work tree. You probably want: ... in the main or any linked working tree. +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
Re: [PATCH v5 09/35] lockfile.c: document the various states of lock_file objects
Michael Haggerty wrote:
I agree with your point about overlap. I will split the documentation
into two parts with less redundancy:
* Documentation/technical/api-lockfile.txt: How to use the API.
* lockfile.{c,h}: Internal implementation details.
I think the implementation details would get lost among the thousand
things in cache.h. So instead, I will add a commit on top of the patch
series that splits out a lockfile.h header file (which I think is a good
idea anyway), and moves the internal documentation there. Sound good?
Yep, a separate lockfile.h header file sounds sensible to me.
Thanks,
Jonathan
--
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 Mon, Sep 22, 2014 at 5:00 PM, Marc Branchaud marcn...@xiplink.com wrote: On 14-09-21 05:50 AM, Duy Nguyen wrote: 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? Not quite. It was a genuine question rather than an outright suggestion for change. It is typical to present a high-level overview and then the low-level details. This case reverses that and presents the details first and then the overview (in the form of --git-path). The reader wades through several paragraphs of detailed explanation of the low-level structure of the .git directory, only to be told at the end to use --git-path and not worry about those details. Thus, the organization struck me as a bit odd. *shrug* To me it seems better to leave it at the end here. The text does work as-is, and presents the necessary information; and I don't want to turn this into a bike-shedding session, so feel free to ignore my question. -- 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] archive: support filtering paths with glob
On Tue, Sep 23, 2014 at 2:15 AM, Junio C Hamano gits...@pobox.com wrote: When we have a/b/c and a/d/e to be written, the first round would write a/ and then a/b/ with the above, and presumably elsewhere somebody will write a/b/c; next time around we do need to write a/d/ but we wouldn't want to write a/ itself. How is this code preventing the recursion going all the way up every time to avoid repeating a/? Puzzled... We never traverse 'a' (or any directory) twice and we only push a directory to the stack when we examine it. After a/b and a are written down and we examine 'd', 'a/d' is pushed to the stack. When we hit 'a/d/e', we only have 'a/d' in the stack, not 'a'. -- 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 for-maint] apply: gitdiff_verify_name(): accept /dev/null\r
The edk2 (EFI Development Kit II) project at
https://github.com/tianocore/edk2/ uses CRLF line endings.
The following small reproducer demonstrates how gitdiff_verify_name()
breaks when it meets the usual git patches workflow in combination with
CRLF line endings:
1. Prepare the test repo:
mkdir testdir
cd testdir
git init
git config core.whitespace cr-at-eol
git config am.keepcr true
touch f1
git add f1
git commit -m 'initial import'
2. In the contributor role, write a patch that creates a new file
(adhering to the CRLF convention), submit it, then clean up:
git checkout -b branch1 master
echo 'hello world' | unix2dos f2
git add f2
git commit -m 'add f2'
git format-patch master..branch1
git send-email 0001-add-f2.patch
# send it to yourself -- make sure it goes through your MTA
git clean -fdx
3. In the reviewer / tester / maintainer role, save the patch from your
email client to a local file. Assume that your email client does not
corrupt the patch when saving it. (Thunderbird doesn't corrupt it, for
example.) Once saved, try to apply the patch email to a new branch.
git checkout -b branch2 master
git am /path/to/the/saved/file
- Applying: add f2
- fatal: git apply: bad git-diff - expected /dev/null on line 9
This happens because am.keepcr==true keeps the CRLFs intact (as it should
in fact), but then /dev/null\r in the diff header trips up
gitdiff_verify_name().
Fix it by reusing the is_dev_null() helper function, which in effect
changes the condition from
memcmp(/dev/null, line, 9) || line[9] != '\n'
to
memcmp(/dev/null, line, 9) || !isspace(line[9])
Signed-off-by: Laszlo Ersek ler...@redhat.com
---
Notes:
I'm not subscribed to the list; please keep me CC'd. Thanks.
builtin/apply.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/apply.c b/builtin/apply.c
index 6b7c764..a9c6a08 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -955,7 +955,7 @@ static char *gitdiff_verify_name(const char *line, int
isnull, char *orig_name,
}
else {
/* expect /dev/null */
- if (memcmp(/dev/null, line, 9) || line[9] != '\n')
+ if (!is_dev_null(line))
die(_(git apply: bad git-diff - expected /dev/null on
line %d), linenr);
return NULL;
}
--
1.8.3.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
