По вашему запросу высылаем
Услуги отправки писем Реально низкие цены Огромный выбор em@il баз Изготовление рекламного шаблона бесплатно Вы получаете заказы заказчиков в день обращения КИБЕРПАРТИЗАН.РФ -- 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 10/11] ref_transaction_verify(): new function to check a reference's value
On 02/09/2015 07:50 PM, Stefan Beller wrote: On Sun, Feb 8, 2015 at 8:14 AM, Michael Haggerty mhag...@alum.mit.edu wrote: /* - * Add a reference update to transaction. new_sha1 is the value that - * the reference should have after the update, or null_sha1 if it should - * be deleted. If old_sha1 is non-NULL, then it the value - * that the reference should have had before the update, or null_sha1 if - * it must not have existed beforehand. - * Function returns 0 on success and non-zero on failure. A failure to update - * means that the transaction as a whole has failed and will need to be - * rolled back. + * Add a reference update to transaction. new_sha1 is the value that + * the reference should have after the update, or null_sha1 if it + * should be deleted. If new_sha1 is NULL, then the reference is not + * changed at all. old_sha1 is the value that the reference must have + * before the update, or null_sha1 if it must not have existed + * beforehand. The old value is checked after the lock is taken to + * prevent races. If the old value doesn't agree with old_sha1, the + * whole transaction fails. If old_sha1 is NULL, then the previous + * value is not checked. + * + * Return 0 on success and non-zero on failure. Any failure in the + * transaction means that the transaction as a whole has failed and + * will need to be rolled back. Do we need to be explicit about having to rollback everything in each ref_transaction_* function documentation? Thanks for the suggestion. I just added a new commit that moves this (and more) information to the introductory comment above these four functions' declarations, so that it doesn't have to be repeated for each function. It will be in the re-roll. 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
Keep original author with git merge --squash?
I frequently find myself using `git merge --squash` to combine a series of commits by the same author into one. (For example, I fetch my project's GitHub PRs into my repo. Frequently, a PR consists of the original PR (with a good description) followed by a few follow-ups based on feedback from me. While I'd prefer that the submitter amended their original commit instead of making it my job, this is rare. And I don't feel that it's valuable to my project's git history to contain all the intermediate stages of code review --- it's usually just one commit.) So `git merge --squash origin/pr/1234` is a really convenient command here... except for one thing: it sets the author as me. I always have to manually find the author line and make sure to pass it to --author (perhaps with --amend). What would people think of a flag (or a config value) that means if all merged commits are by the same author, use that author for the resulting commit instead of the default author? (I'm not sure if this should be a flag to --squash or to commit. Maybe `git merge --squash`; `git commit --use-squashed-author`? Seems like it should be not too hard to implement; SQUASH_MSG is pretty parseable. Or just a config value.) --dave -- glas...@davidglasser.net | langtonlabs.org | flickr.com/photos/glasser/ -- 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 06/11] commit: add tests of commit races
Michael Haggerty mhag...@alum.mit.edu writes: On the other hand, there's this [1] and this [2] from the FSF, which recommend a copyright blurb at the beginning of every source file. Though actually the recommendation is to include a GPL blurb too, not just a naked copyright line like I used. But I get the feeling that the FSF's recommendation is more for ideological than for legal reasons. It is relatively recent (late 1980s) that US became part of Berne Convention (1886). Before that you had to write Copyright and All Rights Reserved (or Todos Derechos Reserrvados) in Buenos Aires days. It is not surprising to see the more cautious practice from the older days in recommendations by an old organization like FSF. Is there a reason you did not append the tests in 7509 ? Hmph. I don't know what Hmph means in this context. Hmph, it might deserve more thought, but I do not have opinion right now. -- 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] merge-file: correctly open files when in a subdir
Aleksander Boruch-Gruszecki aleksander.boruchgrusze...@gmail.com writes: @@ -72,6 +72,12 @@ test_expect_success 'works in subdirectory' ' ( cd dir git merge-file a.txt o.txt b.txt ) ' +mkdir -p dir/deep +cp new1.txt orig.txt new2.txt dir/deep +test_expect_success 'accounts for subdirectory when writing' ' +(cd dir git merge-file deep/new1.txt deep/orig.txt deep/new2.txt) +' Interesting. Makes us wonder why the one before this new one you added did not catch the issue, doesn't it? The test before the one added by me does work because merge-file tries to open a.txt for writing in repo root directory, which will create a file if it does not exist. Ahh, this existing test ( cd dir git merge-file a.txt o.txt b.txt ) implicitly expects that dir/a.txt is written, but the broken implementation writes to a.txt (i.e. outside dir). But the test only checks the exit code from the command without making sure that dir/a.txt is written, it does not notice the breakage. Thanks, that makes sense and it also makes sense that checking the resulting content in dir/a.txt would make sense. Then we many not need to add a new dir/deep/* test---after all they are checking the same thing. -- 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] merge-file: correctly open files when in a subdir
Junio C Hamano gits...@pobox.com writes:
Thanks, that makes sense and it also makes sense that checking the
resulting content in dir/a.txt would make sense. Then we many not
need to add a new dir/deep/* test---after all they are checking the
same thing.
Here is what I have right now, queued somewhere in 'pu', after
fixing it up a bit.
-- 8 --
From: Aleksander Boruch-Gruszecki aleksander.boruchgrusze...@gmail.com
Date: Sun, 8 Feb 2015 17:53:53 +0100
Subject: [PATCH] merge-file: correctly open files when in a subdir
run_setup_gently() is called before merge-file. This may result in changing
current working directory, which wasn't taken into account when opening a file
for writing.
Fix by prepending the passed prefix. Previous var is left so that error
messages keep referring to the file from the user's working directory
perspective.
Signed-off-by: Aleksander Boruch-Gruszecki
aleksander.boruchgrusze...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/merge-file.c | 3 ++-
t/t6023-merge-file.sh | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/builtin/merge-file.c b/builtin/merge-file.c
index 844f84f..232b768 100644
--- a/builtin/merge-file.c
+++ b/builtin/merge-file.c
@@ -90,7 +90,8 @@ int cmd_merge_file(int argc, const char **argv, const char
*prefix)
if (ret = 0) {
const char *filename = argv[0];
- FILE *f = to_stdout ? stdout : fopen(filename, wb);
+ const char *fpath = prefix_filename(prefix, prefixlen, argv[0]);
+ FILE *f = to_stdout ? stdout : fopen(fpath, wb);
if (!f)
ret = error(Could not open %s for writing, filename);
diff --git a/t/t6023-merge-file.sh b/t/t6023-merge-file.sh
index 432f086..d0df869 100755
--- a/t/t6023-merge-file.sh
+++ b/t/t6023-merge-file.sh
@@ -69,7 +69,8 @@ test_expect_success 'works in subdirectory' '
cp new1.txt dir/a.txt
cp orig.txt dir/o.txt
cp new2.txt dir/b.txt
- ( cd dir git merge-file a.txt o.txt b.txt )
+ ( cd dir git merge-file a.txt o.txt b.txt )
+ test_path_is_missing a.txt
'
cp new1.txt test.txt
--
2.3.0-185-g073f588
--
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 06/11] commit: add tests of commit races
On Wed, Feb 11, 2015 at 10:10 AM, Junio C Hamano gits...@pobox.com wrote: Michael Haggerty mhag...@alum.mit.edu writes: On the other hand, there's this [1] and this [2] from the FSF, which recommend a copyright blurb at the beginning of every source file. Though actually the recommendation is to include a GPL blurb too, not just a naked copyright line like I used. But I get the feeling that the FSF's recommendation is more for ideological than for legal reasons. It is relatively recent (late 1980s) that US became part of Berne Convention (1886). Before that you had to write Copyright and All Rights Reserved (or Todos Derechos Reserrvados) in Buenos Aires days. Quoting from wikipedia[1] (note however that when the United States joined the Convention in 1988, it continued to make statutory damages and attorney's fees only available for registered works). Does that mean if somebody would infringe the GPL on git (e.g. selling a modified git version without giving sources), it would be harder to tell him to stop because of the missing attorney's fees in case we drop out the copyright notices? (I have no deep understanding of legal processes in the US). It is not surprising to see the more cautious practice from the older days in recommendations by an old organization like FSF. Is there a reason you did not append the tests in 7509 ? You convinced me that having to start with an orphan commit justifies a new test file as well as the nature of the test. Hmph. I don't know what Hmph means in this context. Hmph, it might deserve more thought, but I do not have opinion right now. [1] http://en.wikipedia.org/wiki/Berne_Convention -- 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] config: add show_err flag to git_config_parse_key()
Jeff King p...@peff.net writes: On Wed, Feb 11, 2015 at 01:15:05AM +0530, Tanay Abhra wrote: I just saw your mail late in the night (I didn't had net for a week). This patch just squelches the error message, I will take a better look tomorrow morning. Thanks, this is probably a good first step. We can worry about making the config look actually _work_ as the next step (which does not even have to happen right now; it is not like it hasn't been this way since the very beginning of git). I agree this is probably a good first step in the right direction. As to the implementation, there are a few minor things I would change, but they are both minor: - defective may want to be a bit more descriptive to clarify what kind fo defect is undesired. In the context of this patch, I think Tanay meant (syntactically) malformed, perhaps? - int show_err should be unsigned flags with its bit 01 defined to be used as QUIET bit. Another option for this first step would be to actually make git_config_parse_key permissive, rather than just squelching the error. That is, to actually look up pager.under_score rather than silently erroring out with an invalid key whenever we are reading (whereas on the writing side, we _do_ want to make sure we enforce syntactic validity). I doubt it matters, much, though. Sensible. I was tempted to also add something like: test_expect_failure TTY 'command with underscores can override pager' ' test_config pager.under_score sed s/^/paged:// git --exec-path=. under_score actual echo paged:ok expect test_cmp expect actual ' but I am not sure it is worth adding the test, even as a placeholder. Unless we are planning to relax the config syntax, the correct spelling is more like pager.under_score.command. It's probably better to just add the test along with the code when we know what the final form will look like. Concurred. -- 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
https://docs.google.com/file/d/0B9nj3tAxC2ooc3lhQ2...
https://docs.google.com/file/d/0B9nj3tAxC2ooc3lhQ2RDVmp4cFE/edit?usp=docslist_api -- 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 06/11] commit: add tests of commit races
Stefan Beller sbel...@google.com writes: Quoting from wikipedia[1] (note however that when the United States joined the Convention in 1988, it continued to make statutory damages and attorney's fees only available for registered works). Does that mean if somebody would infringe the GPL on git (e.g. selling a modified git version without giving sources), it would be harder to tell him to stop because of the missing attorney's fees in case we drop out the copyright notices? (I have no deep understanding of legal processes in the US). No. registered works in that sentence is about registering copyright with U.S. Copyright Office. In-file Copyright circle-c line does not have much to do with that. -- 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 04/11] ref_transaction_update(): remove have_old parameter
On 02/09/2015 07:20 PM, Stefan Beller wrote: On Sun, Feb 8, 2015 at 8:13 AM, Michael Haggerty mhag...@alum.mit.edu wrote: Instead, if old_sha1 is non-NULL, verify it; otherwise, don't. parsing error on that commit message. I needed to read the code to understand what you want to say here. Thanks for the comment. I will change that sentence to Instead, verify the reference's old value if and only if old_sha1 is non-NULL. (in this commit and its successor). 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: EOL handling (EGit/svn/Windows)
On Tue, Feb 10, 2015 at 6:49 AM, Torsten Bögershausen tbo...@web.de wrote: add that to the repo, do the normalization and push. I did LF normalization over history. Looks like everything worked correctly, just wondering, what does the WARNING mean? $ git filter-branch --tree-filter '~/fix-eol.sh' -d /dev/shm/repo-tmp -- --all Rewrite 4eab51b65af61d2b0e56f9990cc14be1e1372194 (13349/13349) Ref 'refs/heads/master' was rewritten Ref 'refs/remotes/origin/master' was rewritten WARNING: Ref 'refs/remotes/origin/master' is unchanged $ cat ~/fix-eol.sh find . -type f \! -path ./.git/\* -print0 | xargs -0 dos2unix --keepdate 2/dev/null -- Piotr Krukowiecki -- 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 06/11] commit: add tests of commit races
On 02/10/2015 08:12 PM, Junio C Hamano wrote: Stefan Beller sbel...@google.com writes: On Sun, Feb 8, 2015 at 8:14 AM, Michael Haggerty mhag...@alum.mit.edu wrote: +# Copyright (c) 2014 Michael Haggerty mhag...@alum.mit.edu What is the projects stance on copyright lines? I do not think we have a strong one. I've seen files (most of them from the beginning) having some copyright lines, other files (often introduced way later) not having them, because we're git and have history, so we know who did it. I personally agree with that statement. Also, a copyright notice per file is often added when a new file is added, but that ends up giving false sense of ownership to everybody else down the line even after the file has been extensively modified. It's not like Michael solely owns all lines in this file in later versions. And even if people added their name at the top every time they make any change, their names tend to stay even when their contributions are later completely rewritten or removed. In a sense, my agreement with your statement is stronger than Yes, Git can tell us who did what anyway. What we can find in the history is the sole source of truth, and in-file copyright notice is misleading. You do not even have to have one in the Berne signatory nations anyway. I only put a copyright notice there because I thought it was standard practice. I think it is ugly and would rather do without it, even aside from the practical problems that Junio mentioned. On the other hand, there's this [1] and this [2] from the FSF, which recommend a copyright blurb at the beginning of every source file. Though actually the recommendation is to include a GPL blurb too, not just a naked copyright line like I used. But I get the feeling that the FSF's recommendation is more for ideological than for legal reasons. If I don't hear anything else, I'll delete the copyright line in the reroll. The tests themselves look fine. Is there a reason you did not append the tests in 7509 ? Hmph. I don't know what Hmph means in this context. The description for t7509 is git commit --reset-author, which doesn't seem to describe the new tests. There are also t7500 git commit / Tests for selected commit options t7501 git commit t7502 git commit porcelain-ish I suppose the new tests could go in any of these. But since the tests are thematically a bit unusual (dealing with races rather than testing command-line options) and they start with an orphan commit, I thought it would be just as easy to put them in their own file to make it clear that they are independent. I really don't care either way. Michael [1] http://www.gnu.org/licenses/gpl-howto.html [2] http://www.gnu.org/licenses/gpl-faq.html#NoticeInSourceFile -- 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 07/11] commit: avoid race when creating orphan commits
On 02/09/2015 07:35 PM, Stefan Beller wrote: On Sun, Feb 8, 2015 at 8:14 AM, Michael Haggerty mhag...@alum.mit.edu wrote: If, during the initial check, HEAD doesn't point at anything, then we Maybe If HEAD doesn't point at anything during the initial check, then... ? (Being a non native speaker is hard. These commas look so confusing, so the version without commas makes it way easier to read for me.) Will change. Thanks! 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 v2] merge-file: correctly open files when in a subdir
Here is what I have right now, queued somewhere in 'pu', after fixing it up a bit. That's awesome! Thanks for your help :) -- 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
Увеличьте доходы в бизнесе
Вам нужно увеличивать продажи? http://bit.ly/1M9HAVu -- 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 01/24] dir.c: optionally compute sha-1 of a .gitignore file
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
-int add_excludes_from_file_to_list(const char *fname,
-const char *base,
-int baselen,
-struct exclude_list *el,
-int check_index)
+/*
+ * Given a file with name fname, read it (either from disk, or from
+ * the index if check_index is non-zero), parse it and store the
+ * exclude rules in el.
+ *
+ * If ss is not NULL, compute SHA-1 of the exclude file and fill
+ * stat data from disk (only valid if add_excludes returns zero). If
+ * ss_valid is non-zero, ss must contain good value as input.
+ */
+static int add_excludes(const char *fname, const char *base, int baselen,
+ struct exclude_list *el, int check_index,
+ struct sha1_stat *sha1_stat)
...
@@ -571,6 +588,21 @@ int add_excludes_from_file_to_list(const char *fname,
}
buf[size++] = '\n';
close(fd);
+ if (sha1_stat) {
+ int pos;
+ if (sha1_stat-valid
+ !match_stat_data(sha1_stat-stat, st))
+ ; /* no content change, ss-sha1 still good */
+ else if (check_index
+ (pos = cache_name_pos(fname, strlen(fname)))
= 0
+ !ce_stage(active_cache[pos])
+ ce_uptodate(active_cache[pos]))
+ hashcpy(sha1_stat-sha1,
active_cache[pos]-sha1);
+ else
+ hash_sha1_file(buf, size, blob,
sha1_stat-sha1);
I do not think this would work well on DOS.
This helper function originally is meant to work *only* on the
checked out representation of the file and that is what is read by
read_in_full(), and that is the reason why it handles the case where
the contents of buf[] happens to be CRLF terminated in the function.
If you want to detect the content changes across working tree, index
and the tree objects by reusing hash_sha1_file(), however, you must
not feed the checked out (aka smudged) representation to it.
You'd need to turn it into cleaned representation by doing the
equivalent of calling index_path(). Some helpers in the callchain
that originates from index_path() might directly be reusable for
your purpose.
--
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: read() MAX_IO_SIZE bytes, more than SSIZE_MAX?
Eric Sunshine sunsh...@sunshineco.com writes: A bit cleaner: #ifndef(MAX_IO_SIZE) # define MAX_IO_SIZE_DEFAULT (8*1024*1024) # if defined(SSIZE_MAX) (SSIZE_MAX MAX_IO_SIZE_DEFAULT) # define MAX_IO_SIZE SSIZE_MAX # else # define MAX_IO_SIZE MAX_IO_SIZE_DEFAULT # endif #endif OK, then let's do this. -- 8 -- Subject: xread/xwrite: clip MAX_IO_SIZE to SSIZE_MAX Since 0b6806b9 (xread, xwrite: limit size of IO to 8MB, 2013-08-20), we chomp our calls to read(2) and write(2) into chunks of MAX_IO_SIZE bytes (8 MiB), because a large IO results in a bad latency when the program needs to be killed. This also brought our IO below SSIZE_MAX, which is a limit POSIX allows read(2) and write(2) to fail when the IO size exceeds it, for OS X, where a problem was originally reported. However, there are other systems that define SSIZE_MAX smaller than our default X-. Make sure we clip our calls to this as well. Reported-by: Joachim Schmitz j...@schmitz-digital.de Helped-by: Torsten Bögershausen tbo...@web.de Helped-by: Eric Sunshine sunsh...@sunshineco.com Signed-off-by: Junio C Hamano gits...@pobox.com --- wrapper.c | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/wrapper.c b/wrapper.c index 007ec0d..50e6697 100644 --- a/wrapper.c +++ b/wrapper.c @@ -172,8 +172,21 @@ void *xcalloc(size_t nmemb, size_t size) * 64-bit is buggy, returning EINVAL if len = INT_MAX; and even in * the absence of bugs, large chunks can result in bad latencies when * you decide to kill the process. + * + * We pick 8 MiB as our default, but if the platform defines SSIZE_MAX + * that is smaller than that, clip it to SSIZE_MAX, as a call to + * read(2) or write(2) larger than taht is allowed to fail. As the last + * resort, we allow a port to pass via CFLAGS e.g. -DMAX_IO_SIZE=value + * to override this, if the definition of SSIZE_MAX platform is broken. */ -#define MAX_IO_SIZE (8*1024*1024) +#ifndef(MAX_IO_SIZE) +# define MAX_IO_SIZE_DEFAULT (8*1024*1024) +# if defined(SSIZE_MAX) (SSIZE_MAX MAX_IO_SIZE_DEFAULT) +# define MAX_IO_SIZE SSIZE_MAX +# else +# define MAX_IO_SIZE MAX_IO_SIZE_DEFAULT +# endif +#endif /* * xread() is the same a read(), but it automatically restarts read() -- 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: read() MAX_IO_SIZE bytes, more than SSIZE_MAX?
Junio C Hamano gitster at pobox.com writes: snip OK, then let's do this. Yep, that'd do, thanks. bye, Jojo -- 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 8/8] reflog_expire(): lock symbolic refs themselves, not their referent
On Wed, Feb 11, 2015 at 2:49 PM, Junio C Hamano gits...@pobox.com wrote: Stefan Beller sbel...@google.com writes: On Mon, Feb 9, 2015 at 1:12 AM, Michael Haggerty mhag...@alum.mit.edu wrote: When processing the reflog of a symbolic ref, hold the lock on the symbolic reference itself, not on the reference that it points to. I am not sure if that makes sense. So when expiring HEAD, you want to have a .git/HEAD.lock file instead of a .git/refs/heads/master.lock file? What would happen if there is a concurrent modification to the master branch? The HEAD may be pointing at 'master' and the other party that is trying to modify it would fail when it tries to update the reflog for HEAD thanks to HEAD.lock being held by us. The HEAD may be pointing at 'next' and the other part that updates 'master' would not try to modify HEAD reflog and we do not conflict. At least, I think that is the rationale behind this change. That makes sense! Do we have documentation on symrefs? Originally I was wondering if this would make things complicated for symbolic branches which are not HEAD. Then you could update the branch pointed to, because it has no lock as the lock is on the symref. On the other hand this seems to be an improvement, as you cannot move the symref itself, as it has the lock and we don't really have other symrefs? -- 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 3/3] Win32: implement nanosecond-precision file times
We no longer use any of MSVCRT's stat-functions, so there's no need to
stick to a CRT-compatible 'struct stat' either.
Define and use our own POSIX-2013-compatible 'struct stat' with nanosecond-
precision file times.
Signed-off-by: Karsten Blees bl...@dcon.de
---
compat/mingw.c | 12 ++--
compat/mingw.h | 43 +++
config.mak.uname | 4 ++--
3 files changed, 39 insertions(+), 20 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index 6d73a3d..e4d5e3f 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -442,9 +442,9 @@ static int do_lstat(int follow, const char *file_name,
struct stat *buf)
buf-st_size = fdata.nFileSizeLow |
(((off_t)fdata.nFileSizeHigh)32);
buf-st_dev = buf-st_rdev = 0; /* not used by Git */
- buf-st_atime = filetime_to_time_t((fdata.ftLastAccessTime));
- buf-st_mtime = filetime_to_time_t((fdata.ftLastWriteTime));
- buf-st_ctime = filetime_to_time_t((fdata.ftCreationTime));
+ filetime_to_timespec((fdata.ftLastAccessTime),
(buf-st_atim));
+ filetime_to_timespec((fdata.ftLastWriteTime), (buf-st_mtim));
+ filetime_to_timespec((fdata.ftCreationTime), (buf-st_ctim));
if (fdata.dwFileAttributes FILE_ATTRIBUTE_REPARSE_POINT) {
WIN32_FIND_DATAW findbuf;
HANDLE handle = FindFirstFileW(wfilename, findbuf);
@@ -550,9 +550,9 @@ int mingw_fstat(int fd, struct stat *buf)
buf-st_mode = file_attr_to_st_mode(fdata.dwFileAttributes);
buf-st_size = fdata.nFileSizeLow |
(((off_t)fdata.nFileSizeHigh)32);
- buf-st_atime = filetime_to_time_t((fdata.ftLastAccessTime));
- buf-st_mtime = filetime_to_time_t((fdata.ftLastWriteTime));
- buf-st_ctime = filetime_to_time_t((fdata.ftCreationTime));
+ filetime_to_timespec((fdata.ftLastAccessTime),
(buf-st_atim));
+ filetime_to_timespec((fdata.ftLastWriteTime), (buf-st_mtim));
+ filetime_to_timespec((fdata.ftCreationTime), (buf-st_ctim));
return 0;
case FILE_TYPE_CHAR:
diff --git a/compat/mingw.h b/compat/mingw.h
index f2a78b4..8dee9c9 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -293,22 +293,48 @@ static inline long long filetime_to_hnsec(const FILETIME
*ft)
return winTime - 1164447360LL;
}
-static inline time_t filetime_to_time_t(const FILETIME *ft)
+struct timespec {
+ time_t tv_sec;
+ long tv_nsec;
+};
+
+static inline void filetime_to_timespec(const FILETIME *ft, struct timespec
*ts)
{
- return (time_t)(filetime_to_hnsec(ft) / 1000);
+ long long hnsec = filetime_to_hnsec(ft);
+ ts-tv_sec = (time_t)(hnsec / 1000);
+ ts-tv_nsec = (hnsec % 1000) * 100;
}
/*
- * Use mingw specific stat()/lstat()/fstat() implementations on Windows.
+ * Use mingw specific stat()/lstat()/fstat() implementations on Windows,
+ * including our own struct stat with 64 bit st_size and nanosecond-precision
+ * file times.
*/
#define off_t off64_t
#define lseek _lseeki64
-/* use struct stat with 64 bit st_size */
+struct mingw_stat {
+_dev_t st_dev;
+_ino_t st_ino;
+_mode_t st_mode;
+short st_nlink;
+short st_uid;
+short st_gid;
+_dev_t st_rdev;
+off64_t st_size;
+struct timespec st_atim;
+struct timespec st_mtim;
+struct timespec st_ctim;
+};
+
+#define st_atime st_atim.tv_sec
+#define st_mtime st_mtim.tv_sec
+#define st_ctime st_ctim.tv_sec
+
#ifdef stat
#undef stat
#endif
-#define stat _stati64
+#define stat mingw_stat
int mingw_lstat(const char *file_name, struct stat *buf);
int mingw_stat(const char *file_name, struct stat *buf);
int mingw_fstat(int fd, struct stat *buf);
@@ -321,13 +347,6 @@ int mingw_fstat(int fd, struct stat *buf);
#endif
#define lstat mingw_lstat
-#ifndef _stati64
-# define _stati64(x,y) mingw_stat(x,y)
-#elif defined (_USE_32BIT_TIME_T)
-# define _stat32i64(x,y) mingw_stat(x,y)
-#else
-# define _stat64(x,y) mingw_stat(x,y)
-#endif
int mingw_utime(const char *file_name, const struct utimbuf *times);
#define utime mingw_utime
diff --git a/config.mak.uname b/config.mak.uname
index b64b63c..a18a4cc 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -346,7 +346,7 @@ ifeq ($(uname_S),Windows)
NO_SVN_TESTS = YesPlease
RUNTIME_PREFIX = YesPlease
NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease
- NO_NSEC = YesPlease
+ USE_NSEC = YesPlease
USE_WIN32_MMAP = YesPlease
# USE_NED_ALLOCATOR = YesPlease
UNRELIABLE_FSTAT = UnfortunatelyYes
@@ -498,7 +498,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
NO_PERL_MAKEMAKER = YesPlease
RUNTIME_PREFIX = YesPlease
NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease
- NO_NSEC = YesPlease
+ USE_NSEC =
[PATCH 2/3] Win32: replace MSVCRT's fstat() with a Win32-based implementation
fstat() is the only stat-related CRT function for which we don't have a
full replacement yet (and thus the only reason to stick with MSVCRT's
'struct stat' definition).
Fully implement fstat(), in preparation of implementing a POSIX 2013
compatible 'struct stat' with nanosecond-precision file times.
Signed-off-by: Karsten Blees bl...@dcon.de
---
compat/mingw.c | 28 +++-
1 file changed, 19 insertions(+), 9 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index ba3cfb0..6d73a3d 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -532,28 +532,38 @@ int mingw_fstat(int fd, struct stat *buf)
{
HANDLE fh = (HANDLE)_get_osfhandle(fd);
BY_HANDLE_FILE_INFORMATION fdata;
+ DWORD avail;
if (fh == INVALID_HANDLE_VALUE) {
errno = EBADF;
return -1;
}
- /* direct non-file handles to MS's fstat() */
- if (GetFileType(fh) != FILE_TYPE_DISK)
- return _fstati64(fd, buf);
- if (GetFileInformationByHandle(fh, fdata)) {
- buf-st_ino = 0;
- buf-st_gid = 0;
- buf-st_uid = 0;
- buf-st_nlink = 1;
+ /* initialize stat fields */
+ memset(buf, 0, sizeof(*buf));
+ buf-st_nlink = 1;
+
+ switch (GetFileType(fh) ~FILE_TYPE_REMOTE) {
+ case FILE_TYPE_DISK:
+ if (!GetFileInformationByHandle(fh, fdata))
+ break;
buf-st_mode = file_attr_to_st_mode(fdata.dwFileAttributes);
buf-st_size = fdata.nFileSizeLow |
(((off_t)fdata.nFileSizeHigh)32);
- buf-st_dev = buf-st_rdev = 0; /* not used by Git */
buf-st_atime = filetime_to_time_t((fdata.ftLastAccessTime));
buf-st_mtime = filetime_to_time_t((fdata.ftLastWriteTime));
buf-st_ctime = filetime_to_time_t((fdata.ftCreationTime));
return 0;
+
+ case FILE_TYPE_CHAR:
+ buf-st_mode = _S_IFCHR;
+ return 0;
+
+ case FILE_TYPE_PIPE:
+ buf-st_mode = _S_IFIFO;
+ if (PeekNamedPipe(fh, NULL, 0, NULL, avail, NULL))
+ buf-st_size = avail;
+ return 0;
}
errno = EBADF;
return -1;
--
2.3.0.3.ge7778af
--
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: read() MAX_IO_SIZE bytes, more than SSIZE_MAX?
Joachim Schmitz jojo at schmitz-digital.de writes: Junio C Hamano gitster at pobox.com writes: snip OK, then let's do this. Except for the type taht -- 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 8/8] reflog_expire(): lock symbolic refs themselves, not their referent
Stefan Beller sbel...@google.com writes: On Mon, Feb 9, 2015 at 1:12 AM, Michael Haggerty mhag...@alum.mit.edu wrote: When processing the reflog of a symbolic ref, hold the lock on the symbolic reference itself, not on the reference that it points to. I am not sure if that makes sense. So when expiring HEAD, you want to have a .git/HEAD.lock file instead of a .git/refs/heads/master.lock file? What would happen if there is a concurrent modification to the master branch? The HEAD may be pointing at 'master' and the other party that is trying to modify it would fail when it tries to update the reflog for HEAD thanks to HEAD.lock being held by us. The HEAD may be pointing at 'next' and the other part that updates 'master' would not try to modify HEAD reflog and we do not conflict. At least, I think that is the rationale behind this 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
[poll] does anybody depend on RelNotes being a symbolic link?
I am wondering if I can turn the top-level RelNotes symbolic link into a regular file. The benefit for doing that is that I can start the file like so: Git Release Notes == Updates since v2.3 early in the cycle and then later decide if we want to make the next one 3.0 or 2.4. And then just after the release, I move it down to Documentation/RelNotes/3.0.0.txt (or 2.4.0.txt) and start the next cycle. One thing that worries me is that people and their build scripts might depend on being able to figure out the upcoming release name by reading the symbolic link, assuming that the link would point to Documentation/RelNotes/x.y.z.txt, and such a change ends up breaking their setup. I am not sure how likely this would be. Objections? Also any other objections, other possible cause of breakages I may have missed? -- 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: read() MAX_IO_SIZE bytes, more than SSIZE_MAX?
Joachim Schmitz j...@schmitz-digital.de writes: Joachim Schmitz jojo at schmitz-digital.de writes: Junio C Hamano gitster at pobox.com writes: snip OK, then let's do this. Except for the type taht Also #ifndef part X- Here is what I queued for the day. -- 8 -- Subject: xread/xwrite: clip MAX_IO_SIZE to SSIZE_MAX Since 0b6806b9 (xread, xwrite: limit size of IO to 8MB, 2013-08-20), we chomp our calls to read(2) and write(2) into chunks of MAX_IO_SIZE bytes (8 MiB), because a large IO results in a bad latency when the program needs to be killed. This also brought our IO below SSIZE_MAX, which is a limit POSIX allows read(2) and write(2) to fail when the IO size exceeds it, for OS X, where a problem was originally reported. However, there are other systems that define SSIZE_MAX smaller than our default, and feeding 8 MiB to underlying read(2)/write(2) would fail. Make sure we clip our calls to the lower limit as well. Reported-by: Joachim Schmitz j...@schmitz-digital.de Helped-by: Torsten Bögershausen tbo...@web.de Helped-by: Eric Sunshine sunsh...@sunshineco.com Signed-off-by: Junio C Hamano gits...@pobox.com --- wrapper.c | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/wrapper.c b/wrapper.c index f92b147..c77c2eb 100644 --- a/wrapper.c +++ b/wrapper.c @@ -135,8 +135,21 @@ void *xcalloc(size_t nmemb, size_t size) * 64-bit is buggy, returning EINVAL if len = INT_MAX; and even in * the absense of bugs, large chunks can result in bad latencies when * you decide to kill the process. + * + * We pick 8 MiB as our default, but if the platform defines SSIZE_MAX + * that is smaller than that, clip it to SSIZE_MAX, as a call to + * read(2) or write(2) larger than that is allowed to fail. As the last + * resort, we allow a port to pass via CFLAGS e.g. -DMAX_IO_SIZE=value + * to override this, if the definition of SSIZE_MAX platform is broken. */ -#define MAX_IO_SIZE (8*1024*1024) +#ifndef MAX_IO_SIZE +# define MAX_IO_SIZE_DEFAULT (8*1024*1024) +# if defined(SSIZE_MAX) (SSIZE_MAX MAX_IO_SIZE_DEFAULT) +# define MAX_IO_SIZE SSIZE_MAX +# else +# define MAX_IO_SIZE MAX_IO_SIZE_DEFAULT +# endif +#endif /* * xread() is the same a read(), but it automatically restarts read() -- 2.3.0-186-g9f73ee1 -- 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
What's cooking in git.git (Feb 2015, #03; Wed, 11)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. Git 2.3 is out, and the first batch of topics that have been cooking in the 'next' branch are now in the 'master' branch. The 'next' branch will be rewound shortly but not yet. Its tree currently matches that of the 'master' branch. We'd need Is this ready, or are you rerolling? poll for individual topics that have been waiting before moving forward. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [Graduated to master] * ah/usage-strings (2015-01-14) 1 commit (merged to 'next' on 2015-01-22 at bfa5bab) + standardize usage info string format * ak/typofixes (2015-01-21) 2 commits (merged to 'next' on 2015-01-22 at e36f25a) + t/lib-terminal.sh: fix typo + pack-bitmap: fix typo * bc/http-fallback-to-password-after-krb-fails (2015-01-07) 1 commit (merged to 'next' on 2015-01-12 at 4c67038) + remote-curl: fall back to Basic auth if Negotiate fails After attempting and failing a password-less authentication (e.g. kerberos), libcURL refuses to fall back to password based Basic authentication without a bit of help/encouragement. * cj/log-invert-grep (2015-01-13) 1 commit (merged to 'next' on 2015-01-13 at c908e99) + log: teach --invert-grep option * dk/format-patch-ignore-diff-submodule (2015-01-07) 2 commits (merged to 'next' on 2015-01-12 at 6b4605b) + format-patch: ignore diff.submodule setting + t4255: test am submodule with diff.submodule Setting diff.submodule to 'log' made git format-patch produce broken patches. * jc/coding-guidelines (2015-01-15) 1 commit (merged to 'next' on 2015-01-22 at 3c96639) + CodingGuidelines: clarify C #include rules * jc/pretty-format-doc (2015-01-15) 1 commit (merged to 'next' on 2015-01-22 at 2a81ecc) + log --pretty documentation: do not forget tformat: * jc/push-to-checkout (2015-01-08) 2 commits (merged to 'next' on 2015-01-12 at e64df63) + receive-pack: support push-to-checkout hook + receive-pack: refactor updateInstead codepath Extending the js/push-to-deploy topic, the behaviour of git push when updating the working tree and the index with an update to the branch that is checked out can be tweaked by push-to-checkout hook. * jc/unused-symbols (2015-01-15) 8 commits (merged to 'next' on 2015-01-22 at 77fd5f0) + shallow.c: make check_shallow_file_for_update() static + remote.c: make clear_cas_option() static + urlmatch.c: make match_urls() static + revision.c: make save_parents() and free_saved_parents() static + line-log.c: make line_log_data_init() static + pack-bitmap.c: make pack_bitmap_filename() static + prompt.c: remove git_getpass() nobody uses + http.c: make finish_active_slot() and handle_curl_result() static Mark file-local symbols as static, and drop functions that nobody uses. * jk/blame-commit-label (2015-01-13) 5 commits (merged to 'next' on 2015-01-15 at 1b32e21) + blame.c: fix garbled error message + use xstrdup_or_null to replace ternary conditionals + builtin/commit.c: use xstrdup_or_null instead of envdup + builtin/apply.c: use xstrdup_or_null instead of null_strdup + git-compat-util: add xstrdup_or_null helper * jn/rerere-fail-on-auto-update-failure (2015-01-08) 1 commit (merged to 'next' on 2015-01-12 at 313c449) + rerere: error out on autoupdate failure git rerere (invoked internally from many mergy operations) did not correctly signal errors when told to update the working tree files and failed to do so for whatever reason. * km/gettext-n (2015-01-12) 1 commit (merged to 'next' on 2015-01-12 at 0cbbf4a) + gettext.h: add parentheses around N_ expansion if supported * ld/p4-exclude-in-sync (2015-01-28) 1 commit (merged to 'next' on 2015-02-05 at ab410a1) + git-p4: support excluding paths on sync * ld/p4-submit-hint (2015-01-23) 1 commit (merged to 'next' on 2015-01-23 at ed972d3) + git-p4: correct --prepare-p4-only instructions * mh/reflog-expire (2014-12-22) 24 commits (merged to 'next' on 2015-01-12 at 12a7dff) + refs.c: let fprintf handle the formatting + refs.c: don't expose the internal struct ref_lock in the header file + lock_any_ref_for_update(): inline function + refs.c: remove unlock_ref/close_ref/commit_ref from the refs api + reflog_expire(): new function in the reference API + expire_reflog(): treat the policy callback data as opaque + Move newlog and last_kept_sha1 to struct expire_reflog_cb + expire_reflog(): move rewrite to flags argument + expire_reflog(): move verbose to flags argument + expire_reflog(): pass flags through to expire_reflog_ent() + struct expire_reflog_cb: a new callback data type + Rename expire_reflog_cb to expire_reflog_policy_cb + expire_reflog(): move updateref to flags
[PATCH 1/3] Win32: make FILETIME conversion functions public
Signed-off-by: Karsten Blees bl...@dcon.de
---
compat/mingw.c | 16
compat/mingw.h | 16
2 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index 70f3191..ba3cfb0 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -419,22 +419,6 @@ int mingw_chmod(const char *filename, int mode)
return _wchmod(wfilename, mode);
}
-/*
- * The unit of FILETIME is 100-nanoseconds since January 1, 1601, UTC.
- * Returns the 100-nanoseconds (hekto nanoseconds) since the epoch.
- */
-static inline long long filetime_to_hnsec(const FILETIME *ft)
-{
- long long winTime = ((long long)ft-dwHighDateTime 32) +
ft-dwLowDateTime;
- /* Windows to Unix Epoch conversion */
- return winTime - 1164447360LL;
-}
-
-static inline time_t filetime_to_time_t(const FILETIME *ft)
-{
- return (time_t)(filetime_to_hnsec(ft) / 1000);
-}
-
/* We keep the do_lstat code in a separate function to avoid recursion.
* When a path ends with a slash, the stat will fail with ENOENT. In
* this case, we strip the trailing slashes and stat again.
diff --git a/compat/mingw.h b/compat/mingw.h
index 5e499cf..f2a78b4 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -283,6 +283,22 @@ static inline int getrlimit(int resource, struct rlimit
*rlp)
}
/*
+ * The unit of FILETIME is 100-nanoseconds since January 1, 1601, UTC.
+ * Returns the 100-nanoseconds (hekto nanoseconds) since the epoch.
+ */
+static inline long long filetime_to_hnsec(const FILETIME *ft)
+{
+ long long winTime = ((long long)ft-dwHighDateTime 32) +
ft-dwLowDateTime;
+ /* Windows to Unix Epoch conversion */
+ return winTime - 1164447360LL;
+}
+
+static inline time_t filetime_to_time_t(const FILETIME *ft)
+{
+ return (time_t)(filetime_to_hnsec(ft) / 1000);
+}
+
+/*
* Use mingw specific stat()/lstat()/fstat() implementations on Windows.
*/
#define off_t off64_t
--
2.3.0.3.ge7778af
--
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 0/3] Win32: nanosecond-precision file times
This patch series was inspired by the problem that Git does not detect changed file content if st_size, st_mtime and st_ctime are unchanged. This was apparently caused by VSS2Git resetting mtime to a value in the past. [1] I believe (or rather hope) that all involved in the discussion agree that Git cannot reasonably be expected to detect changed file content if file time(s) are reset on purpose. However, some users have expressed concerns that 'same size and mtime' [2] may theoretically happen by chance in daily operation. This patch series adopts POSIX 2013 'struct timespec' file times to make this practically impossible, at least on NTFS with 100ns file time resolution. Cheers, Karsten [1] https://github.com/msysgit/git/issues/312 [2] Note that st_ctime of a file never changes on Windows, as it means 'creation time' rather than 'change status time'. Karsten Blees (3): Win32: make FILETIME conversion functions public Win32: replace MSVCRT's fstat() with a Win32-based implementation Win32: implement nanosecond-precision file times compat/mingw.c | 56 +--- compat/mingw.h | 55 +-- config.mak.uname | 4 ++-- 3 files changed, 72 insertions(+), 43 deletions(-) -- 2.3.0.3.ge7778af -- 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: read() MAX_IO_SIZE bytes, more than SSIZE_MAX?
Sorry to be a pain, but i think this sententence neede mending + * to override this, if the definition of SSIZE_MAX platform is broken. Bye, Jojo
Re: Windows Bluescreen
Hi Erik, On Tue, Feb 10, 2015 at 9:12 AM, e...@aercon.net wrote: I find that preview 1.8 is bluescreening on about 1 of 3 ssh pushes. 1.9 preview 12-17-2014 doesn't even bluescreen, the windows gui locks until reset. Does this mean that pushing over git:// file:// and http:// are unaffected? Can you successfully do other (non-git) things over ssh? Sample command: git push omv master\r config. = [core] repositoryformatversion = 0 filemode = false bare = false logallrefupdates = true symlinks = false ignorecase = true hideDotFiles = dotGitOnly [remote omv] url = gitpush@192.168.0.100:/git-repos/HexEncrypter fetch = +refs/heads/*:refs/remotes/omv/* You might get a more helpful response out of the msysgit folks (I've added them to the Cc list). -- 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
Announcing git-cinnabar 0.1.0 (Was: Announcing a new (prototype) git-remote-hg tool)
Hi, Cinnabar is the common natural form in which mercury can be found on Earth. It contains mercury sulfide and its powder is used to make the vermillion pigment. What does that have to do with git? Hint: mercury. Git-cinnabar is a git remote helper to interact with mercurial repositories. It allows to clone, pull and push from/to mercurial remote repositories, using git. If you've already seen the original thread this message is spawned from, this is the same tool, with a new name, and two months worth of additional work and testing. Where git-cinnabar stands out compared to other similar tools is that it doesn't use a local mercurial clone under the hood (unlike all the existing other such tools), and is close to an order of magnitude faster to clone a repository like http://hg.mozilla.org/mozilla-central than the git-remote-hg tool that used to be shipped in contrib/. I won't claim it is exempt of problems and limitations, which is why it's not a 1.0. I'm however confident enough with its state to make the first official release. Code on https://github.com/glandium/git-cinnabar Cheers, Mike -- 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] merge-file: correctly open files when in a subdir
const char *filename = argv[0]; -FILE *f = to_stdout ? stdout : fopen(filename, wb); +const char *fpath = prefix_filename(prefix, prefixlen, argv[0]); +FILE *f = to_stdout ? stdout : fopen(fpath, wb); if (!f) ret = error(Could not open %s for writing, filename); diff --git a/t/t6023-merge-file.sh b/t/t6023-merge-file.sh index 3758961..fdd104c 100755 --- a/t/t6023-merge-file.sh +++ b/t/t6023-merge-file.sh @@ -72,6 +72,12 @@ test_expect_success 'works in subdirectory' ' ( cd dir git merge-file a.txt o.txt b.txt ) ' +mkdir -p dir/deep +cp new1.txt orig.txt new2.txt dir/deep +test_expect_success 'accounts for subdirectory when writing' ' +(cd dir git merge-file deep/new1.txt deep/orig.txt deep/new2.txt) +' Interesting. Makes us wonder why the one before this new one you added did not catch the issue, doesn't it? The test before the one added by me does work because merge-file tries to open a.txt for writing in repo root directory, which will create a file if it does not exist. If you add a directory before the file, trying to open it will fail. I will additionally check of the file's content to make the test more clear, however it does actually fail with git 2.3.0. The issue with line-wrapping and tab changing to space is my own stupidity, I used an older config with my vim and it mangled the file. It also probably is what caused the patch to not apply properly. -- 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: Gmail Message rejection
Stefan Beller stefanbel...@gmail.com writes: Trying to send from an Android Gmail client. Though the option was called answer inline. ... and still sends multipart text/html message, sorry. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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: EOL handling (EGit/svn/Windows)
On Tue, Feb 10, 2015 at 4:32 PM, Torsten Bögershausen tbo...@web.de wrote: On 2015-02-10 11.52, Piotr Krukowiecki wrote: So far: 1. msysgit can't checkout a one file (saying filename too long, the relative path has 215 bytes) - probably not related to EOL issue. Cygwin git works ok. So I did not check how msysgit works yet. Please have a look here: https://github.com/msysgit/msysgit/releases/Git-1.9.5-preview20141217 I think we have support for long path names (Haven't tested it myself) Thanks, I'll have a look later if I have some free time. Since Cygwin's git is more recent I'd prefer to use it instead of msys, unless there are some other advantages of msys version. 2. maybe due to old cygwin git, I have a problem of not displaying changes, if the changed line has LF eol (and the file was checked out on Windows with CRLF eols). Will try later with newer git. Normally you will not see any changes, and git diff will not show anything either. I meant that there are some actual changes in the file (not only whitespaces), but the line with the changes also has LF eol instead of CRLF, and the actual changes are now shown. That's what the examples below show. 2a. EGit handles such files gracefuly, but OTOH if the file is simple dos2unix'ed, it shows diffs showing all lines changed, and when you commit the files, it will create empty commit. Why this dos2unix ? Is there a special reason ? Just an use case - if for some reason someone/something coverts the file to LF eol. Plus I think it would be better if empty commit was not done (since there are no actual changes besides LF-CRLF). By the way, when people only use Egit, I assume they use Eclipse, and you don't use Notepad.exe or so at all. Then you don't need CRLF in the worktree at all, as Eclipse handle LF well. That's true, but I thought it'd be better to use native EOLs. The reasons: - new files will have initially CRLF (and will be converted to LF on first commit, but I think they will be left with CRLF in workspace even after commit), so workspace might have CRLF files anyway - some files are c# code/projects and are developer in VS, so they should probably have CRLF eols; not checked how VS will work yet. - some external tools might not work with non-native EOLs (not that I know of any specific tool we use - just a precaution) - when in Rome, do as Romans do, generally ;) and in this case you should be able to set git config core.autocrlf input on all repos, just in case someone sneaks in a CRLF somewhere. (And after the normalizing of course) I'm aware of that option, we might change to it - but I still don't see what's the advantage, except lack of CRLF-LF conversion (that's a valid reason, but won't core.safecrlf help here?) $ file master/settings.gradle master/settings.gradle: ASCII text, with CRLF line terminators That is under msysgit ? (Side note: Msysgit is called Git for Windows these days) Nope - both repository and client was cygwin git. $ dos2unix.exe master/settings.gradle Is this under Msysgit ? Cygwin. dos2unix: converting file master/settings.gradle to Unix format ... $ git status # On branch master # # Changes not staged for commit: # (use git add file... to update what will be committed) # (use git checkout -- file... to discard changes in working directory) # # modified: master/settings.gradle # no changes added to commit (use git add and/or git commit -a) $ git diff fatal: LF would be replaced by CRLF in master/settings.gradle That's interesting. What does git config -l | grep core give ? core.autocrlf=true core.safecrlf=true core.eol=native core.repositoryformatversion=0 core.filemode=true core.bare=false core.logallrefupdates=true core.ignorecase=true Plus, *.gradle text in .gitattributes. As I wrote, it might be old Cygwin git - 1.7.9. Will try to update. -- Piotr Krukowiecki -- 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] index-pack: reduce memory footprint a bit
On Tue, Feb 10, 2015 at 12:49 PM, Junio C Hamano gits...@pobox.com wrote: matthew sporleder msporle...@gmail.com writes: I'm having trouble getting this new patch to apply. Apply the first one, replace all object_entry_extra with object_stat, replace all objects_extra with obj_stat and amend the first one. Then apply this one. I got this to work and had a good experience but got this from an arm user: Cloning into 'NetBSD-src-git'... remote: Counting objects: 3484984, done. remote: Compressing objects: 100% (636083/636083), done. error: index-pack died of signal 10 fatal: index-pack failed 125.84 real 0.13 user 0.49 sys Core was generated by `git'. Program terminated with signal SIGBUS, Bus error. #0 0x00045f88 in cmd_index_pack () (gdb) bt #0 0x00045f88 in cmd_index_pack () #1 0x00014058 in handle_builtin () #2 0x00129358 in main () I will wait for the official patch and ask if my friend can compile with -g. -- 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: Windows Bluescreen
Pushing over http and https are unaffected.. My linux nas died, so on rebuild I tried to do the ssh thing, and realized quite soon that things weren't right. As far as other uses of ssh, I don't know, I use putty frequently, but I am not clear if it is using the same libraries or not. I hunted around for the bugreport email on mysgit but couldn't seem to find it. It seems in the foggy recesses I remember reading about an ssh issue with windows, but can't find it now. On Wed, Feb 11, 2015 at 3:56 AM, Chris Packham judge.pack...@gmail.com wrote: Hi Erik, On Tue, Feb 10, 2015 at 9:12 AM, e...@aercon.net wrote: I find that preview 1.8 is bluescreening on about 1 of 3 ssh pushes. 1.9 preview 12-17-2014 doesn't even bluescreen, the windows gui locks until reset. Does this mean that pushing over git:// file:// and http:// are unaffected? Can you successfully do other (non-git) things over ssh? Sample command: git push omv master\r config. = [core] repositoryformatversion = 0 filemode = false bare = false logallrefupdates = true symlinks = false ignorecase = true hideDotFiles = dotGitOnly [remote omv] url = gitpush@192.168.0.100:/git-repos/HexEncrypter fetch = +refs/heads/*:refs/remotes/omv/* You might get a more helpful response out of the msysgit folks (I've added them to the Cc list). -- 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] index-pack: reduce memory footprint a bit
On Wed, Feb 11, 2015 at 8:01 PM, matthew sporleder msporle...@gmail.com wrote: On Tue, Feb 10, 2015 at 12:49 PM, Junio C Hamano gits...@pobox.com wrote: matthew sporleder msporle...@gmail.com writes: I'm having trouble getting this new patch to apply. Apply the first one, replace all object_entry_extra with object_stat, replace all objects_extra with obj_stat and amend the first one. Then apply this one. I got this to work and had a good experience but got this from an arm user: Cloning into 'NetBSD-src-git'... remote: Counting objects: 3484984, done. remote: Compressing objects: 100% (636083/636083), done. error: index-pack died of signal 10 fatal: index-pack failed 125.84 real 0.13 user 0.49 sys Core was generated by `git'. Program terminated with signal SIGBUS, Bus error. It might be the effect of __attribute__((packed)). Maybe you could try again without that in builtin/index-pack.c. Also could you run gdb and do p sizeof(*ofs_deltas) ? No need to actually run it from gdb. -- 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: Relative paths don't work in .gitignore as would be expected.
+git@vger.kernel.org, plain text I would say just use zsh globbing, it has the double star, but it'd likely too late for that. You'd add a single rule: ignore any files that are in a directory higher up than the .gitignore where the rule is found. Then if you have a git repo in your fs at /git/repo with a /git/repo/.gitignore you could put /git/repo/*.js, *.js, or ./*.js to ignore the same thing (the absolute path may or may not bite the person in the ass when he moves the repo, but that's not our problem), so those would be equivalent to the current /*.js (give or take the absolute example). You could do **/*.js the zsh way to start ignoring things everywhere, equivalent to the current *.js. /#!/JoePea On Tue, Feb 10, 2015 at 1:19 AM, /#!/JoePea trus...@gmail.com wrote: I would say just use zsh globbing, it has the double star, but it'd likely too late for that. You'd add a single rule: ignore any files that are in a directory higher up than the .gitignore where the rule is found. Then if you have a git repo in your fs at /git/repo with a /git/repo/.gitignore you could put /git/repo/*.js, *.js, or ./*.js to ignore the same thing (the absolute path may or may not bite the person in the ass when he moves the repo, but that's not our problem), so those would be equivalent to the current /*.js (give or take the absolute example). You could do **/*.js the zsh way to start ignoring things everywhere, equivalent to the current *.js. /#!/JoePea -- 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
