Re: What's cooking in git.git
Hi Junio, On 2015-08-06 00:55, Junio C Hamano wrote: > * sb/submodule-helper (2015-08-05) 1 commit > - submodule: implement `module_list` as a builtin helper > > The beginning of "git submodule" rewritten in C. I am really looking forward to that, with my Windows performance hat firmly on my head. > * tb/complete-rebase-i-edit-todo (2015-08-05) 1 commit > - completion: offer '--edit-todo' during interactive rebase > > Comments? The problem fixed by this one has bugged me plenty of times. I often need to edit the TODO e.g. when I managed to get the reordering wrong and want to insert a `pick ` later in the `git-rebase-todo` and then call `git rebase --skip`. Read: I am very much in favor of fast-tracking this topic. Thanks, Dscho -- 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] git-am: add am.threeWay config variable
Hi, On 2015-08-04 16:19, Paul Tan wrote: > From: Remi Lespinet > > Add the am.threeWay configuration variable to use the -3 or --3way > option of git am by default. When am.threeway is set and not desired > for a specific git am command, the --no-3way option can be used to > override it. > > Signed-off-by: Remi Lespinet > Signed-off-by: Paul Tan > --- > I tweaked Remi's patch so it is implemented on top of builtin/am.c. Hopefully > there will be no regressions this time ;) The diff looks obviously correct to me (and yes, I also looked at the context... :-)). Ciao, Dscho -- 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 3/3] am: let --signoff override --no-signoff
Hi Paul,
On 2015-08-04 16:08, Paul Tan wrote:
> diff --git a/builtin/am.c b/builtin/am.c
> index 0961304..8c95aec 100644
> --- a/builtin/am.c
> +++ b/builtin/am.c
> @@ -2151,8 +2169,9 @@ int cmd_am(int argc, const char **argv, const
> [...]
> char *prefix)
> OPT_BOOL('3', "3way", &state.threeway,
> N_("allow fall back on 3way merging if needed")),
> OPT__QUIET(&state.quiet, N_("be quiet")),
> - OPT_BOOL('s', "signoff", &state.signoff,
> - N_("add a Signed-off-by line to the commit message")),
> + OPT_SET_INT('s', "signoff", &state.signoff,
> + N_("add a Signed-off-by line to the commit message"),
> + SIGNOFF_EXPLICIT),
> OPT_BOOL('u', "utf8", &state.utf8,
> N_("recode into utf8 (default)")),
> OPT_SET_INT('k', "keep", &state.keep,
> @@ -2265,6 +2284,9 @@ int cmd_am(int argc, const char **argv, const
> char *prefix)
>
> if (resume == RESUME_FALSE)
> resume = RESUME_APPLY;
> +
> + if (state.signoff == SIGNOFF_EXPLICIT)
> + am_append_signoff(&state);
> } else {
This is clever, but I suspect there is now a chance for a double-signoff if we
passed `--signoff` to the initial `git am` call and it went through without
having to resume.
Or am I missing something?
Ciao,
Dscho
--
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 7 - long/short and upper/lower filename
Hi, On 2015-08-03 23:18, JoséQuintas wrote: > I am using Windows 7 64 bits. ... and Git version... ? > I have a filename called ze_xmlfun.prg > Last week gitgui shows 2 changed files: ZE_XML~1.PRG and ze_xmlfun.prg > At momment I can't update this file, because get a error. > Try delete file, update one name each time, but same error. > Seems that a unique file is considered as 2 files, and this causes error. This is no longer allowed in the most recent Git for Windows 1.x versions, for exactly the reason you mentioned: the short name is actually referring to the same file as the long name. Therefore, short names will be refused. Unfortunately, you will have to fix this issue in your repository yourself. It will most likely entail something like `git rm --cached ZE_XML~1.PRG && git commit -s -m "Remove bogus file"` > When do a search in history, upper/lower case must be the same as in git > control. > If upper/lower is changed, is considered a new file. > How to configure git to work allways using lower case on Windows? There is no such configuration. If you have a file with an undesired file name, you have to rename it. You can use `git mv` for that. If the file name differs only in case, you will have to do a little dance like `git mv MYFILE myfile.bak && git mv myfile.bak myfile` > Is there a plugin or a tool to make this, to new files and to update in > git repository? No, not unless you write one. > Note: gitgui is a gui tool for git, ok, but once it uses git, may be > this feature/change need to be made in git. If you have an idea how to incorporate this into Git's source code, it would be a splendid idea to contribute that change to this mailing list. Ciao, Johannes -- 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: wishlist: make it possible to amend commit messages after push to remote
Hi, On 2015-08-07 19:10, Jarkko Hietaniemi wrote: > But to be honest, I wasn't expecting a miracle cure. I guess the core > of my gripe is just that: how the commit message is part of the SHA. The commit message is not "part of the SHA" but it is part of the content that defines the SHA-1. I guess in your case, you would rather have an empty commit message and attach the real message as a commit note. Speaking for myself, I actually like it that the entire metadata is part of the commit object, even the commit message. It makes the whole thing more reliable: one cannot claim that the commit does one thing on one day, and the next day all of a sudden claim that the commit does something completely different. Git's just really consistent the way it is. Ciao, Johannes -- 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.mak.uname: Cygwin: Use renames for creation
Hi Adam, On 2015-08-09 04:01, Adam Dinwoodie wrote: > I do not see any difference between the situation here and the situation > for MinGW, which is fundamentally a Cygwin fork, but which already has > this build option set for it in config.mak.uname. This is incorrect. MinGW is distinctly *not* a Cygwin fork. MinGW means "Minimal GNU on Windows" and that in turn means that it provides an environment to build executables that purely use the Win32 API. Read: no POSIX emulation whatsoever. Most notably, MinGW programs cannot use fork(2); It is simply unavailable. What you *probably* meant is that Git for Windows relies on MSys2 for its shell and Perl scripts, and that MSys2 in turn is a fork of Cygwin. That affects *only* the scripts, though; Git itself (as in `git.exe`) is still a pure MinGW program (and as a consequence, is quite a bit faster than Cygwin Git, at the price of certain quirks that Cygwin Git does not suffer). >> We've gotten a lot of users on the list who ask why their Git >> directories on shared drives aren't working (or are broken in some way). >> Since I don't use Windows, let me ask: does the Cygwin DLL handle >> link(2) properly on shared drives, and if not, would this patch help it >> do so? I can imagine that perhaps SMB doesn't support the necessary >> operations to make a POSIX link(2) work properly. > > I'd need to go back to the Cygwin list to get a definite answer, but as > I understand it, yes, this is is exactly the problem -- quoting Corinna, > one of the Cygwin project leads, "The MS NFS is not very reliable in > keeping up with changes to metadata." > > We have verified that setting `core.createobject rename` resolves the > problem for people who are seeing it, which very strongly implies that > this build option would solve the problem similarly, but would fix it > for all users, not just those who spend enough time investigating the > problem to find that setting. >From my experience, it appears that providing Corinna Vinschen (or better put: >the Cygwin developers in general) with a sound patch gets things fixed pretty >timely. And since `core.createObject = rename` seems to work around the problem, it should be possible to patch the Cygwin runtime accordingly. Sure, it will take a little investigation *what* code should be changed, and how, but the obvious benefit to *all* Cygwin applications should make that effort worth your while. Please note that Cygwin's source code itself is in Git now, too: https://cygwin.com/git.html Ciao, Johannes -- 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 report Windows 10
Hi, On 2015-08-10 14:26, MS-Informatique wrote: > My Windows notebook got updated to Windows 10 and now my Git Bash doesn't > start and when I open an existing repository from Git Gui, I am getting next > error: > "0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 error 487 > AllocationBase 0x0, BaseAddress 0x6857, RegionSize 0x41, State > 0x1 > C:\Program Files (x86)\Git\bin\sh.exe: *** Couldn't reserve space for > cygwin's heap, Win32 error 0" > > I am running GIT version 1.9.5 (latest build for Windows). > > Can someone help me? First of all, the home page of Git for Windows has hints where to report bugs (and where to look for possible resolutions first). Second, this issue is so common that I wrote a wiki page about it: https://github.com/git-for-windows/git/wiki/32-bit-issues Short version: reinstall Git for Windows. Preferably a 64-bit Git for Windows 2.x from https://git-for-windows.github.io/. And you might want to heed the advice given in http://git-for-windows.github.io/#contribute when you want to report bugs ;-) Ciao, Johannes -- 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: File Hash for Windows executable
Hi Ryan, On 2015-08-10 15:54, Kiser, Ryan Lee wrote: > I've downloaded the Windows installer for Git, Which one. > but can't seem to find hashes published anywhere for verification. Since the > downloaded file doesn't seem to be signed, The newest ones from https://git-for-windows.github.io/ are signed. Ciao, Johannes -- 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 2/2] pager_in_use: make sure output is still going to pager
Hi Peff,
On 2015-08-10 07:23, Jeff King wrote:
> diff --git a/compat/pipe-id.c b/compat/pipe-id.c
> new file mode 100644
> index 000..4764c5f
> --- /dev/null
> +++ b/compat/pipe-id.c
> @@ -0,0 +1,25 @@
> +#include "git-compat-util.h"
> +#include "compat/pipe-id.h"
> +#include "strbuf.h"
> +
> +const char *pipe_id_get(int fd)
> +{
> + static struct strbuf id = STRBUF_INIT;
> + struct stat st;
> +
> + if (fstat(fd, &st) < 0 || !S_ISFIFO(st.st_mode))
> + return NULL;
Just a quick note: it seems that this check is not really working on Windows. I
tested this by running this test case manually (because TTY is not set on
Windows):
> +test_expect_success TTY 'no color when paged program writes to pipe' '
> + test_config alias.externallog "!git log | cat >log.out" &&
> + test_config color.ui auto &&
> + test_terminal env TERM=vt100 git -p externallog &&
> + test_line_count = 0 paginated.out &&
> + test -s log.out &&
> + ! colorful log.out
> +'
The output is "colorful" ;-)
I hope to find some time tomorrow to figure out some workaround that makes this
work on Windows.
Ciao,
Dscho
--
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: Question
Hi, On 2015-08-11 10:28, Jet Rey Maza wrote: > I'm wondering why gitbash dont have wget? Please take the time to write coherent questions in the future, giving enough context for others to understand what you are talking about. We are not dogs that you throw some bones, you know? We are highly skilled software developers and you might want to express some respect for that by crafting a pleasant email. As to your question, I have to guess here because you are so parsimonious with context: are you referring to Git for Windows' "Git Bash" entry in the start menu? Assuming that this is what you meant, the explanation is simple: Git does not require wget to work. So we do not ship it with Git for Windows. Side note: Git for Windows *does* ship with curl.exe, for historical reasons. You can probably use curl instead of wget for your use case. Second side note: you obviously seek more than just Git for Windows, so why not use MSys2 (https://msys2.github.io/) which comes with a wget package you can install via pacman? Ciao, Johannes -- 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 bc/connect-plink] t5601-clone: remove broken and pointless check for plink.exe
Hi Johannes, On 2015-08-11 22:51, Johannes Sixt wrote: > Invoking plink requires special treatment, and we have support and even > test cases for the commands 'plink' and 'tortoiseplink'. We also support > .exe variants for these two and there is a test for 'plink.exe'. > > On Windows, however, where support for plink.exe would be relevant, the > test case fails because it is not possible to execute a file with a .exe > extension that is actually not a binary executable---it is a shell > script in our test. We have to disable the test case on Windows. Oh how would I wish you were working on Git for Windows even *just* a bit *with* me. At least I would wish for a more specific description of the development environment, because it sure as hell is not anything anybody can download and install as easily as Git for Windows' SDK. FWIW Git for Windows has this patch (that I wanted to contribute in due time, what with being busy with all those tickets) to solve the problem mentioned in your patch in a different way: https://github.com/git-for-windows/git/commit/2fff4b54a0d4e5c5e2e4638c9b0739d3c1ff1e45 Please read this as my vote not to remove the test cases. Thanks, Johannes -- 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: [msysGit] [PATCH nd/dwim-wildcards-as-pathspecs] t2019: skip test requiring '*' in a file name non Windows
Hi, On 2015-08-11 22:38, Johannes Sixt wrote: > diff --git a/t/t2019-checkout-ambiguous-ref.sh > b/t/t2019-checkout-ambiguous-ref.sh > index 8396320..199b22d 100755 > --- a/t/t2019-checkout-ambiguous-ref.sh > +++ b/t/t2019-checkout-ambiguous-ref.sh > @@ -69,7 +69,7 @@ test_expect_success 'wildcard ambiguation, paths win' ' > ) > ' > > -test_expect_success 'wildcard ambiguation, refs lose' ' > +test_expect_success !MINGW 'wildcard ambiguation, refs lose' ' > git init ambi2 && > ( > cd ambi2 && FWIW I planned to submit a patch including this fix: https://github.com/git-for-windows/git/commit/4694320330e1b4d9178e13e215ce60a1cc8e0b1c (The idea of the `fixup! ` was to make this change part of a larger change during the next merging rebase of Git for Windows.) Ciao, Johannes -- 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: [msysGit] Re: [PATCH bc/connect-plink] t5601-clone: remove broken and pointless check for plink.exe
Hi Johannes, On 2015-08-12 20:31, Johannes Sixt wrote: > Am 12.08.2015 um 13:58 schrieb Erik Faye-Lund: >> On Wed, Aug 12, 2015 at 1:07 PM, Johannes Schindelin >> wrote: >>> FWIW Git for Windows has this patch (that I wanted to contribute >>> in due time, what with being busy with all those tickets) to solve the >>> problem mentioned in your patch in a different way: >>> >>> https://github.com/git-for-windows/git/commit/2fff4b54a0d4e5c5e2e4638c9b0739d3c1ff1e45 >> >> Yuck. On Windows, it's the extension of a file that dictates what kind >> of file it is (and if it's executable or not), not the contents. If we >> get a shell script written with the ".exe"-prefix, it's considered as >> an invalid executable by the system. We should consider it the same >> way, otherwise we're on the path to user-experience schizophrenia. >> >> I'm not sure I consider this commit a step in the right direction. > > I, too, think that it is a wrong decision to pessimize git for the > sake of a single test case. Oh, you make it sound as if you believe that I had indeed weakened Git *just* for a single test case. That is quite a strong assumption, and could not be further from the truth, though, I have to point out. It is important to keep in mind that we (actually, IIRC it was you) taught Git to recognize shell scripts when executing external programs *because Windows does not do that for us*. So yes, we are deviating from the standard Windows way of things, and we do that quite intentionally so. Now, let's look at the test case for a moment and let's try to understand the technique it uses (that breaks the test case currently). It puts a script in place of an `.exe`, with the intention to execute the script instead of the original executable. This technique is an age-old technique on Unix, and it just works. There are a range of valid reasons, from debugging to slightly modifying the function of a particular `.exe` (possibly renaming the original `.exe` and calling it from the script) in the easiest way: by scripting on top of it. If we want to allow such a thing -- allowing users to use scripts to modify the behavior of executables -- then we *have* to allow `.exe` suffixes for scripts, because that happens to be the suffix of executables on Windows. I guess you would have had an easier time to understand my thinking if I had replaced the sentence So the assumption that the `.exe` extension implies that the file is *not* a shell script is now wrong. by So this is a strong indicator that it was wrong to assume that `.exe` extensions imply that the file is *not* a shell script. Further, I even looked at the performance impact, but that is at least well documented in the commit message. I also have to point out that the alternative "solution" presented by your patch -- to disable the test case -- is no solution at all: the very platform that is most likely to have plink users is Windows. And to *exclude* that platform from running that unit test is questionable at best. Ciao, Johannes -- 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: [msysGit] [PATCH jk/prune-mtime] prune: close directory earlier during loose-object directory traversal
Hi, On 2015-08-12 19:43, Johannes Sixt wrote: > 27e1e22d (prune: factor out loose-object directory traversal, 2014-10-16) > introduced a new function for_each_loose_file_in_objdir() with a helper > for_each_file_in_obj_subdir(). The latter calls callbacks for each file > found during a directory traversal and finally also a callback for the > directory itself. > > git-prune uses the function to clean up the object directory. In > particular, in the directory callback it calls rmdir(). On Windows XP, > this rmdir call fails, because the directory is still open while the > callback is called. Close the directory before calling the callback. > > Signed-off-by: Johannes Sixt > --- > My Windows 8.1 machine does not require this fix for some unkonwn > reason. But we still cater for Windows XP users, where this change > is a real improvement. I believe that we have a concrete bug report for that: https://github.com/git-for-windows/git/issues/231 Ciao, Johannes -- 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 nd/dwim-wildcards-as-pathspecs] t2019: skip test requiring '*' in a file name non Windows
Hi Junio, On 2015-08-12 18:28, Junio C Hamano wrote: > Johannes Schindelin writes: > >> On 2015-08-11 22:38, Johannes Sixt wrote: >> >>> diff --git a/t/t2019-checkout-ambiguous-ref.sh >>> b/t/t2019-checkout-ambiguous-ref.sh >>> index 8396320..199b22d 100755 >>> --- a/t/t2019-checkout-ambiguous-ref.sh >>> +++ b/t/t2019-checkout-ambiguous-ref.sh >>> @@ -69,7 +69,7 @@ test_expect_success 'wildcard ambiguation, paths win' ' >>> ) >>> ' >>> >>> -test_expect_success 'wildcard ambiguation, refs lose' ' >>> +test_expect_success !MINGW 'wildcard ambiguation, refs lose' ' >>> git init ambi2 && >>> ( >>> cd ambi2 && >> >> FWIW I planned to submit a patch including this fix: >> >> https://github.com/git-for-windows/git/commit/4694320330e1b4d9178e13e215ce60a1cc8e0b1c >> >> (The idea of the `fixup! ` was to make this change part of a larger >> change during the next merging rebase of Git for Windows.) > > Thanks. Is that an Ack? Yes, this is an Ack. (Although I would have preferred to organize the contribution of Windows-related patches better, really.) Ciao, Dscho -- 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: [msysGit] Re: [PATCH bc/connect-plink] t5601-clone: remove broken and pointless check for plink.exe
Hi kusma, On 2015-08-12 13:58, Erik Faye-Lund wrote: > On Wed, Aug 12, 2015 at 1:07 PM, Johannes Schindelin > wrote: >> >> On 2015-08-11 22:51, Johannes Sixt wrote: >>> Invoking plink requires special treatment, and we have support and even >>> test cases for the commands 'plink' and 'tortoiseplink'. We also support >>> .exe variants for these two and there is a test for 'plink.exe'. >>> >>> On Windows, however, where support for plink.exe would be relevant, the >>> test case fails because it is not possible to execute a file with a .exe >>> extension that is actually not a binary executable---it is a shell >>> script in our test. We have to disable the test case on Windows. >> >> Oh how would I wish you were working on Git for Windows even *just* a bit >> *with* me. At least I would wish for a more specific description of the >> development environment, because it sure as hell is not anything anybody can >> download and install as easily as Git for Windows' SDK. >> >> FWIW Git for Windows has this patch (that I wanted to contribute in due >> time, what with being busy with all those tickets) to solve the problem >> mentioned in your patch in a different way: >> >> https://github.com/git-for-windows/git/commit/2fff4b54a0d4e5c5e2e4638c9b0739d3c1ff1e45 > > Yuck. On Windows, it's the extension of a file that dictates what kind > of file it is (and if it's executable or not), not the contents. Careful. If you continue along those lines, interactive rebase, `git add -p` and all those wonderful scripts Git has will have to stop working. Because those scripts completely disagree with what you just said about Windows if you think about it: *none* of them has an extension. I know that you do not mean this, of course, but that is the argument you were making... ;-) > If we get a shell script written with the ".exe"-prefix, it's considered as > an invalid executable by the system. And if we get a shell script without any `.exe` suffix, it is still considered as an invalid executable by the system. And even if we tack on an `.sh` suffix (which is *not* in line with the way Git works), it is *still* considered as an invalid executable by the system. Ciao, Dscho -- 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: "git am --abort" screwing up index?
Hi Linus, On 2015-08-17 01:33, Linus Torvalds wrote: > On Sun, Aug 16, 2015 at 12:46 PM, Linus Torvalds > wrote: >> >> Maybe it has always done this, and I just haven't noticed (I usually >> _just_ do the "git reset --hard" thing, don't ask me why I wanted to >> be doubly sure this time). But maybe it's an effect of the new >> built-in "am". > > I bisected this. It's definitely used to work, and the regression is > from the new built-in am. This patch is a reproducer: -- snipsnap -- >From 5323f1c309ad40721e2e19fa9c6ce5ad52d98271 Mon Sep 17 00:00:00 2001 From: Johannes Schindelin Date: Mon, 17 Aug 2015 09:37:39 +0200 Subject: [PATCH] t4151: demonstrate that builtin am corrupts index' stat data Reported by Linus Torvalds. Signed-off-by: Johannes Schindelin --- t/t4151-am-abort.sh | 12 1 file changed, 12 insertions(+) diff --git a/t/t4151-am-abort.sh b/t/t4151-am-abort.sh index 05bdc3e..bf2e6f4 100755 --- a/t/t4151-am-abort.sh +++ b/t/t4151-am-abort.sh @@ -168,4 +168,16 @@ test_expect_success 'am --abort on unborn branch will keep local commits intact' test_cmp expect actual ' +test_expect_failure 'am --abort leaves index stat info alone' ' + git checkout -f --orphan stat-info && + git reset && + test_commit should-be-untouched && + test-chmtime =0 should-be-untouched.t && + git update-index --refresh && + git diff-files --exit-code --quiet && + test_must_fail git am 0001-*.patch && + git am --abort && + git diff-files --exit-code --quiet +' + test_done -- 2.3.1.windows.1.9.g8c01ab4 -- 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] am --abort: merge ORIG_HEAD tree into index
Hi Paul, On 2015-08-17 11:48, Paul Tan wrote: > It's true that we need to merge the ORIG_HEAD tree into the index > instead of overwriting it. Patch below. Thanks for your impressive, very responsive work! Dscho -- 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.mak.uname: Cygwin: Use renames for creation
Hi Adam, On 2015-08-09 19:05, Adam Dinwoodie wrote: > On 09/08/2015 10:01, Johannes Schindelin wrote: >> On 2015-08-09 04:01, Adam Dinwoodie wrote: >>> >>>> We've gotten a lot of users on the list who ask why their Git >>>> directories on shared drives aren't working (or are broken in some way). >>>> Since I don't use Windows, let me ask: does the Cygwin DLL handle >>>> link(2) properly on shared drives, and if not, would this patch help it >>>> do so? I can imagine that perhaps SMB doesn't support the necessary >>>> operations to make a POSIX link(2) work properly. >>> >>> I'd need to go back to the Cygwin list to get a definite answer, but as >>> I understand it, yes, this is is exactly the problem -- quoting Corinna, >>> one of the Cygwin project leads, "The MS NFS is not very reliable in >>> keeping up with changes to metadata." >>> >>> We have verified that setting `core.createobject rename` resolves the >>> problem for people who are seeing it, which very strongly implies that >>> this build option would solve the problem similarly, but would fix it >>> for all users, not just those who spend enough time investigating the >>> problem to find that setting. >> >> From my experience, it appears that providing Corinna Vinschen (or better >> put: the Cygwin developers in general) with a sound patch gets things fixed >> pretty timely. >> >> And since `core.createObject = rename` seems to work around the problem, it >> should be possible to patch the Cygwin runtime accordingly. Sure, it will >> take a little investigation *what* code should be changed, and how, but the >> obvious benefit to *all* Cygwin applications should make that effort worth >> your while. > > Hmm. I'm not sure what a Cygwin fix would look like here. As I > understand it, using link(2) will fail if the target exists, while > using rename(2) will just clobber a target file. Thanks to you and Junio for explaining why my idea was bad. Sorry! Ciao, Johannes -- 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
Git for Windows 2.5.0
Dear Git (for Windows) users, it is my great pleasure to announce the first official version of Git for Windows. We finally have caught up with Git 2.x and are ready to leave the -preview suffix behind (more on that below). It is available at https://git-for-windows.github.io/ and also at https://git-scm.com/. So how does that affect you? - The biggest benefit is that we finally have a 64-bit Git for Windows. This not only makes a huge difference with large repositories; It also avoids some bugs (if you are interested in technical details, please have a look at https://github.com/git-for-windows/git/wiki/32-bit-issues). - Another huge benefit is that we benefit from (and contribute to) the very active MSys2 community; MSys2 is a minimal POSIX system (forked from Cygwin) that sports a package manager and many packages that are kept up-to-date. - As a consequence of basing Git for Windows on MSys2's packages, Git for Windows now comes with up-to-date versions of Bash and OpenSSL. Oh, and we finally have support in `git svn` for recent Subversion features! - Since there were not many users of Git Cheetah, the Explorer extension similar to TortoiseSVN, and since there is the actively maintained TortoiseGit, Git for Windows dropped support for Git Cheetah. - Git for Windows will be maintained more actively from now on, following Git development more closely. And of course, contributions are welcome! - GitHub for Windows is slated to integrate this new version soon and will continue to follow Git for Windows' development closely. I probably forgot to mention some really important improvements, so feel free to point them out as replies to this mail. Work on upgrading Git for Windows to use MSys2 and follow Git 2.x has been a lot of work that has been going on since the end of January. It would not have been possible without substantial support of GitHub, in particular Michael Haggerty, Jeff King and Brendan Forster, the help of Karsten Blees, Nalla, Sebastian Schuberth, and other contributors. The maintenance of Git for Windows is supported by Microsoft from now on. I would like to take the opportunity to thank above-mentioned developers and companies: this is your release just as much as it is mine. Ciao, Johannes -- 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: No dialog box appears
Hi Aleksey, On 2015-08-19 09:33, Цапков Алексей wrote: > When installing the Git is not a dialog box appears with a choice ssh. > What could be the reason? I assume that you are referring to the Git for Windows installer (please state such details in the future). And I assume you were wondering why you could not choose putty as your ssh program. If that is the case, I think you might need to add connections to your putty first, otherwise the installer will not even present the choice to you. But maybe you want to move this to the issue tracker at https://github.com/git-for-windows/git/issues? Ciao, Johannes -- 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] Fix `git rev-list --show-notes HEAD` when there are no notes
The `format_display_notes()` function clearly assumes that the data
structure holding the notes has been initialized already, i.e. that the
`display_notes_trees` variable is no longer `NULL`.
However, when there are no notes whatsoever, this variable is still
`NULL`, even after initialization.
So let's be graceful and just return if that data structure is `NULL`.
Reported in https://github.com/msysgit/git/issues/363.
Signed-off-by: Johannes Schindelin
---
notes.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/notes.c b/notes.c
index df08209..24a335a 100644
--- a/notes.c
+++ b/notes.c
@@ -1266,7 +1266,10 @@ void format_display_notes(const unsigned char
*object_sha1,
struct strbuf *sb, const char *output_encoding, int
raw)
{
int i;
- assert(display_notes_trees);
+
+ if (!display_notes_trees)
+ return;
+
for (i = 0; display_notes_trees[i]; i++)
format_note(display_notes_trees[i], object_sha1, sb,
output_encoding, raw);
--
2.3.1.windows.1.9.g8c01ab4
--
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] Fix `git rev-list --show-notes HEAD` when there are no notes
Hi Peff, On 2015-08-23 19:43, Jeff King wrote: > On Sat, Aug 22, 2015 at 05:14:39PM +0200, Johannes Schindelin wrote: > >> The `format_display_notes()` function clearly assumes that the data >> structure holding the notes has been initialized already, i.e. that the >> `display_notes_trees` variable is no longer `NULL`. >> >> However, when there are no notes whatsoever, this variable is still >> `NULL`, even after initialization. >> >> So let's be graceful and just return if that data structure is `NULL`. > > Hrm. This is supposed to be made non-NULL by calling init_display_notes. > The "git-log" code does this properly, and can show notes. The > "rev-list" code does not, and hits this assert. But that also means that > it cannot actually _show_ notes, and your patch is papering over the > problem. Good point... > it looks like [patch] is not enough to convince the pretty-printer to > actually show notes (I suspect we need something like the > pretty_ctx->notes_message setup that is in show_log()). > > I don't know how deeply anybody _cares_ about showing notes via > rev-list. It has clearly never worked. But rather than silently > accepting --show-notes (and not showing any notes!), perhaps we should > tell the user that it does not work. Likewise, the "%N" --format > specifier never expands in rev-list, and should probably be removed from > the rev-list documentation. Hmpf. I really did not want to uncover yet another rabbit hole... >> Reported in https://github.com/msysgit/git/issues/363. > > After reading your subject, I wondered why "git rev-list --show-notes > HEAD" did not crash for me (whether or not I had notes). But the key > element from that issue is the addition of "--grep", which is what > triggers us to actually look at the notes (since rev-list otherwise does > not support displaying them). And that _does_ work with my patch above. > So perhaps that is useful, though again, it has never worked in the > past (and with your patch, it would silently return no results, whether > the grep matched or not). > > Of course it's a terrible interface to make "--show-notes --grep" grep > the notes, but not actually _show_ them. :-/ It is. > So I'm not really in favor of this approach, but if we do go that route, > the comment above the declaration of format_display_notes needs to be > updated. You're right. I think the best approach for now is to error out when `--show-notes` is passed to rev-list. Do you agree? Ciao, Dscho -- 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] Fix `git rev-list --show-notes HEAD` when there are no notes
Hi Peff, On 2015-08-24 16:43, Jeff King wrote: > On Mon, Aug 24, 2015 at 12:23:52PM +0200, Johannes Schindelin wrote: > >> You're right. I think the best approach for now is to error out when >> `--show-notes` is passed to rev-list. Do you agree? > > Yes (I imagine you didn't yet read my follow-up patch when you wrote > this). :) Yep, and I forgot to reply when I saw it. Thanks for continuing on that front! Ciao, Dscho -- 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] compat/inet_ntop.c: Use INET_ADDRSTRLEN and INET6_ADDRSTRLEN macroses
Hi Kirill,
On 2015-08-25 12:34, brillian...@inbox.ru wrote:
> From: Brilliantov Kirill Vladimirovich
>
> Signed-off-by: Brilliantov Kirill Vladimirovich
The commit message makes for an excellent place to fill in the reader on
information that is not obvious from reading the patch. For example...
> diff --git a/compat/inet_ntop.c b/compat/inet_ntop.c
> index 90b7cc4..fcd3b15 100644
> --- a/compat/inet_ntop.c
> +++ b/compat/inet_ntop.c
> @@ -47,7 +47,7 @@ static const char *
> inet_ntop4(const u_char *src, char *dst, size_t size)
> {
> static const char fmt[] = "%u.%u.%u.%u";
> - char tmp[sizeof "255.255.255.255"];
> + char tmp[INET_ADDRSTRLEN];
Given that we are in compat/ space, i.e. in a space meant for platforms lacking
POSIX functions and definitions, is it really safe to assume that
INET_ADDRSTRLEN is available there?
> @@ -78,7 +78,7 @@ inet_ntop6(const u_char *src, char *dst, size_t size)
>* Keep this in mind if you think this function should have been coded
>* to use pointer overlays. All the world's not a VAX.
>*/
> - char tmp[sizeof "::::::255.255.255.255"], *tp;
> + char tmp[INET6_ADDRSTRLEN], *tp;
Are we really, absolutely sure that INET6_ADDRSTRLEN is defined?
Also I wonder: what problem does this patch solve? Is the current way to
determine the size of the `tmp` array incorrect?
Please use the commit message space to answer at least these questions.
Ciao,
Johannes
--
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 1/5] submodule: implement `module_clone` as a builtin helper
Hi Stefan,
thank you so much for doing this. `git submodule` is really, really slow on
Windows...
On 2015-08-27 02:52, Stefan Beller wrote:
> diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
> index 4b32a3c..f11fb9c 100644
> --- a/builtin/submodule--helper.c
> +++ b/builtin/submodule--helper.c
> [...]
> +
> +/*
> + * Clone a submodule
> + *
> + * $1 = submodule path
> + * $2 = submodule name
> + * $3 = URL to clone
> + * $4 = reference repository to reuse (empty for independent)
> + * $5 = depth argument for shallow clones (empty for deep)
I think this description is now safely obsolete and can be deleted: you
introduced explicit options like --depth to avoid the "magic" of positional
parameters.
> +static int module_clone(int argc, const char **argv, const char *prefix)
> +{
> + const char *path = NULL, *name = NULL, *url = NULL, *reference =
> NULL, *depth = NULL;
This line is a little long ;-)
> @@ -135,6 +290,9 @@ int cmd_submodule__helper(int argc, const char
> **argv, const char *prefix)
> if (!strcmp(argv[1], "module_name"))
> return module_name(argc - 2, argv + 2, prefix);
>
> + if (!strcmp(argv[1], "module_clone"))
> + return module_clone(argc - 1, argv + 1, prefix);
> +
> usage:
> - usage("git submodule--helper [module_list module_name]\n");
> + usage("git submodule--helper [module_list module_name module_clone]\n");
Was the convention not to use ( ... | ... | ... )?
Thanks,
Dscho
--
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 2/5] thread-utils: add a threaded task queue
Hi Stefan,
On 2015-08-27 02:52, Stefan Beller wrote:
> diff --git a/run-command.c b/run-command.c
> index 28e1d55..cb15cd9 100644
> --- a/run-command.c
> +++ b/run-command.c
> @@ -668,6 +668,22 @@ int git_atexit(void (*handler)(void))
>
> #endif
>
> +void setup_main_thread(void)
> [...]
>
> diff --git a/thread-utils.c b/thread-utils.c
> index a2135e0..b45ab92 100644
> --- a/thread-utils.c
> +++ b/thread-utils.c
> [...]
> +/* FIXME: deduplicate this code with run-command.c */
> +static void setup_main_thread(void)
Do you remember off-hand why the code could not be moved to thread-utils.c
wholesale? Just curious.
> +#else /* NO_PTHREADS */
> +
> +struct task_queue {
> + int early_return;
> +};
> +
> +struct task_queue *create_task_queue(unsigned max_threads)
> +{
> + struct task_queue *tq = xmalloc(sizeof(*tq));
> +
> + tq->early_return = 0;
> +}
> +
> +void add_task(struct task_queue *tq,
> + int (*fct)(struct task_queue *tq, void *task),
Might make sense to typedef this... Maybe task_t?
> + void *task)
> +{
> + if (tq->early_return)
> + return;
Ah, so "early_return" actually means "interrupted" or "canceled"?
I guess I will have to set aside some time to wrap my head around the way tasks
are handled here, in particular how the two `early_return` variables
(`dispatcher()`'s local variable and the field in the `task_queue`) interact.
Thanks!
Dscho
--
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: verify both ends of the pipe () call
From: jfmc
The code to open and test the second end of the pipe clearly imitates
the code for the first end. A little too closely, though... Let's fix
the obvious copy-edit bug.
Signed-off-by: Jose F. Morales
Signed-off-by: Johannes Schindelin
---
compat/mingw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index 496e6f8..f74da23 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -681,7 +681,7 @@ int pipe(int filedes[2])
return -1;
}
filedes[1] = _open_osfhandle((int)h[1], O_NOINHERIT);
- if (filedes[0] < 0) {
+ if (filedes[1] < 0) {
close(filedes[0]);
CloseHandle(h[1]);
return -1;
--
https://github.com/git/git/pull/168
--
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] Mingw: verify both ends of the pipe () call
Hi all, On 2015-08-27 17:55, Johannes Schindelin wrote: > From: jfmc > > The code to open and test the second end of the pipe clearly imitates > the code for the first end. A little too closely, though... Let's fix > the obvious copy-edit bug. > > Signed-off-by: Jose F. Morales > Signed-off-by: Johannes Schindelin > --- For what it's worth: this is my first submitGit submission! ;-) Ciao, Dscho -- 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: http.c (curl_easy_setopt and CURLAUTH_ANY)
Hi Stephen, On 2015-08-28 08:07, Stephen Kazakoff wrote: > When I'm behind a proxy (with BASIC authentication), I'm unable to > perform a git clone. > > I managed to fix this by editing http.c and recompiling. The change > I'd like to propose is to line 452. > > > From: > > curl_easy_setopt(result, CURLOPT_PROXYAUTH, CURLAUTH_ANY); > > To: > > curl_easy_setopt(result, CURLOPT_PROXYAUTH, CURLAUTH_BASIC | CURLAUTH_NTLM); But `CURLAUTH_ANY` should imply `_BASIC` and `_NTLM`. I remember that the `_ANY` was supposed to avoid hard-coding things. According to https://github.com/bagder/curl/blob/ac7be02e695af95e93b3f5a40b80dcab782f5321/include/curl/curl.h#L651 it should actually imply even more. Maybe that is the problem? Could you debug further by setting the environment variable GIT_CURL_VERBOSE=1? Ciao, Johannes -- 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] Mingw: verify both ends of the pipe () call
Hi Jose, Please do not top-post; I use top-posting as a tell-tale for mails I can safely delete unread when I have too many mails in my inbox. On 2015-08-28 08:37, Jose F. Morales wrote: > Ops... my fault. I was playing with the web editor and forgot that my > profile didn't had my real name (now it has). Great! > Could I still amend the commit? (it seems to be already pushed into master) It was pushed to Git for Windows' master, but here it was submitted to the Git mailing list. Junio, would you terribly mind fixing the name on your end? Alternatively, I could try to update the Pull Request and give submitGit another chance to show just how awesome it is. Ciao, Dscho -- 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] Mingw: verify both ends of the pipe () call
Hi, On 2015-08-28 11:39, Johannes Schindelin wrote: > On 2015-08-28 08:37, Jose F. Morales wrote: > >> Could I still amend the commit? (it seems to be already pushed into master) > > It was pushed to Git for Windows' master, but here it was submitted to > the Git mailing list. > > Junio, would you terribly mind fixing the name on your end? > Alternatively, I could try to update the Pull Request and give > submitGit another chance to show just how awesome it is. Never mind, it was way too easy to let submitGit show how excellent it is. Ciao, Dscho -- 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 v2] Mingw: verify both ends of the pipe () call
From: Jose F. Morales
The code to open and test the second end of the pipe clearly imitates
the code for the first end. A little too closely, though... Let's fix
the obvious copy-edit bug.
Signed-off-by: Jose F. Morales
Signed-off-by: Johannes Schindelin
---
compat/mingw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index 496e6f8..f74da23 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -681,7 +681,7 @@ int pipe(int filedes[2])
return -1;
}
filedes[1] = _open_osfhandle((int)h[1], O_NOINHERIT);
- if (filedes[0] < 0) {
+ if (filedes[1] < 0) {
close(filedes[0]);
CloseHandle(h[1]);
return -1;
--
https://github.com/git/git/pull/168
--
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] Mingw: verify both ends of the pipe () call
Hi Jonathan, On 2015-08-27 23:50, Jonathan Nieder wrote: > Johannes Schindelin wrote: > >> From: jfmc > > This means the name shown by git shortlog would be jfmc instead of > Jose F. Morales. Intended? Fixed in v2 ;-) Ciao, Dscho -- 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 0/9] Progress with git submodule
Hi Stefan, On 2015-08-28 03:14, Stefan Beller wrote: > Stefan Beller (9): > submodule: implement `module_list` as a builtin helper > submodule: implement `module_name` as a builtin helper > submodule: implement `module_clone` as a builtin helper Another thing that just hit me: is there any specific reason why the underscore? I think we prefer dashes for subcommands (think: cherry-pick) and maybe we want to do the same for subsubcommands... Ciao, Dscho -- 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
Git for Windows 2.5.1 is out
Dear Git (for Windows) users, it is my pleasure to announce the release of Git for Windows 2.5.1. Apart from synchronizing with Git 2.5.1, the following bugs were fixed: • Backspace works now with ConHost-based (cmd.exe) terminal. • When there is a ~/.bashrc but no ~/.bash_profile, the latter will be created automatically. • When calling a non-login shell, the prompt now works. • The text in the installer describing the terminal emulator options is no longer cut off. • The connect.exe tool to allow SSH connections via HTTP/HTTPS/SOCKS proxies is included in Git for Windows again, as it was in Git for Windows 1.x. • The LANG variable is no longer left unset (which caused troubles with vim). • `call start-ssh-agent` no longer spits out bogus lines. • It is now possible even behind NTLM-authenticated proxies to install Git for Windows' SDK. • We can handle the situation now when the first $PATH elements point outside of Git for Windows' bin/ directories and contain .dll files that interfere with our own (e.g. PostgreSQL's libintl-8.dll). • The patch tool is now included again as it was in Git for Windows 1.x. Ciao, Johannes -- 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: Git crash on different versions, including current
Hi Christian, On 2015-08-29 10:41, Christian Soltenborn wrote: > today I ran into a git issue on Windows 7/64. My directory structure > looks like this, and I wondered why the content of a dir wouldn't get added. > > C:\Users\chris\git\GoogleTestExtension > -- .git > -- ConsoleApplication1 (new) > - gtest-1.7.0 dir (does not get added) > - stuff that has been successfully added > -- more stuff that's already under git control > > So here's about what I did: > - Looked at it with Git Gui, noticed that gtest-1.7.0 is a submodule > - Deleted gtest-1.7.0/.git > - performed git add --all . within the gtest-1.7.0 dir => crash, output > below If you copy the entire `GoogleTestExtension` folder somewhere else, does the crash happen there, still? Can you share a .zip of this folder? Ciao, Johannes -- 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: git Dockerfile for ppc64le
Hi, On 2015-08-25 06:37, Gawade P wrote: > I have built and tested the latest version on git on multiple > distributions including Ubuntu 15.04 on the ppc64le architecture. I > have run the complete test suite and verified that there are no test > failures. > > I have also written a dockerfile for this for Ubuntu 15.04 and wanted > to understand if there is any way I can contribute it to the git > community? Nice! As far as I understand, you could upload this to https://hub.docker.com/ and then everybody could benefit from a simple installation (something like `docker pull GawadeP/git/ppc64le`). Ciao, Johannes -- 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] mailmap: update my entry with new email address
Hi Ramsay, On 2015-09-01 17:50, Ramsay Jones wrote: > diff --git a/.mailmap b/.mailmap > index ece2951..e5b4126 100644 > --- a/.mailmap > +++ b/.mailmap > @@ -186,7 +186,7 @@ Philip Jägenstedt > > Philipp A. Hartmann > Philippe Bruhat > Ralf Thielow > -Ramsay Allan Jones > +Ramsay Jones > René Scharfe > Robert Fitzsimons > Robert Shearman The idea of the .mailmap file is to fix inconsistent names in the history. For example, if you look e.g. at commit 6ebdee5af47df0c64354e452419015a694c25f5f, you will see that your middle name was recorded, but if you look e.g. at f84df81f654aeb0ac4582e0b3be162cba6ea5232 you will see that it was not always recorded with your changes. Therefore I would recommend leaving the old line in place, and just *adding* another one. Besides, for consistency I would leave the middle name in there. Otherwise, people might be wondering why their shortlog calls bring up some other name. In other words, if you add a new line, you really want to use the same clear name as before. You actually do not even need to add a new line if you plan on submitting patches with your middle name. Remember: the main purpose of .mailmap is to support shortlog, i.e. appropriate grouping of patches by person (such as the two commits I mentioned above). Ciao, Johannes P.S.: That's a major bummer on your three forced-offline weeks. I feel with ya! -- 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 path handling changed between versions
Hi Geofrey, On 2015-09-01 18:55, Geofrey Sanders wrote: > I recently upgraded from Windows Git 1.6.2 to 2.5.0 and found myself > unable to rebase. Turns out paths didn't used to be case-sensitive and > now they are, causing a number of operations to halt. A repo created > by pointing at the directory > c:\core\guidewire\Dev\2.4 > would (I suppose) technically have been invalid the whole time because > Windows reports the current path as > C:\core\guidewire\Dev\2.4 > , but msys Git 1.6.2 evidently made a case-insensitive path comparison > so the discrepancy was suppressed. Are you sure about that? I seem to recall that `pwd` changed behavior between MSys and MSys2, but Git never made case-insensitive comparisons. It might help me to understand what is going on if I could have preciser information. What exactly do you mean by "A repo created by pointing at ..."? Could you type out the Git commands you used? > The proximate cause of errors was > git rev-parse --is-inside-work-tree > which would output 'false' even inside the working tree. Ah, you are apparently talking about a worktree separate from your repository? > "--is-inside-git-dir" also printed 'false' in directories where it > should have said 'true'. Again, I really need preciser information about this: *How* did you end up in that directory? Did you use Git Bash or Git CMD? Did you call `cd` with a relative path, a POSIX path or a POSIX-ified full DOS path? > I actually missed the problem in plain sight > at first, because I created a new repo (in which everything worked as > expected), and then did a directory diff... the worktree paths were > different but I only noticed the names, not the case difference in the > drive letter. More details in this SO question: > http://stackoverflow.com/q/32280644/2835086 Please understand that I have a lot of tickets to juggle about and that it is a bit unfair to send me onto a goose chase. I would have preferred a proper GitHub issue, as the "Contribute" section of https://git-for-windows.github.io/ explicitly asks for, but I am okay with discussing this ticket on the mailing list. But studying a StackOverflow thread in addition is a bit much... next, people would ask me to search their Twitter feed for the little tid bit of information I need to help. So please summarize that StackOverflow question, and while we are at it: StackOverflow suggests coming up with a Minimal, Complete and Verifiable Example. That would be a nice thing to have. Maybe you find it in you to come up with that MCVE. > I was able to repair my existing repos by changing the 'worktree' > value in gitconfig - s/c/C/ did the trick - but the whole thing was a > surprise. > > Is this a bug in the current version? Windows doesn't distinguish on > case, so maybe applications shouldn't either. > Was this a bug in the prior version? Maybe creating a repo with a > worktree path that doesn't match the file system should have been an > error from the very beginning. > Was this user error? Maybe I did something wrong and should have known > better, but got away with it for a while. I think there is a good chance we can fix this, although a 1.x -> 2.x jump always suggests that certain things change in a backwards-incompatible manner. Looking forward to more detailed information and that MCVE, Johannes -- 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: Git book figure bug
Hi Jesper, On 2015-09-02 09:45, Jesper Jørgensen wrote: > I am learning how git works, and is using the excellent book on the > official site. > I believe I have located a mistake in one of the images. > It is about Figure 3.17 on this page : > http://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging > > As far as I understand it, the right most snapshot called C5 should > have been named C6. > The texts describes a new snapshot being made from the merge of the 2 > branches. > Having 2 snapshots both named C5 does not seem like it can be possible. Your hunch is correct, and it should be C6, that's why it was changed: https://github.com/progit/progit2/blob/master/book/03-git-branching/images/basic-merging-2.png I do not know why it is still displayed incorrectly on https://git-scm.com/, but your best bet would be to report this as a bug: https://github.com/git/git-scm.com/issues But make sure first that there is not another ticket opened for the same bug! Ciao, Johannes -- 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
Do you plan to release 2.5.2 any time soon?
Hi Junio, I have a couple of fixes lined up for bugs in Git for Windows 2.5.1. Do you plan to release 2.5.2 any time soon? If yes, I would hold off, otherwise I will just do a Git for Windows 2.5.1 (Rel 2). Thanks, Dscho -- 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: GSoC 2015 is over
Hi, On Wed, 2 Sep 2015, Paul Tan wrote: > On Wed, Sep 2, 2015 at 12:55 AM, Matthieu Moy > wrote: > > I consider this GSoC as a great success and a pleasant experience. > > Congratulation to Paul and Karthik, and a warm "thank you" to everybody > > who contributed: administrators, mentors, reviewers, and obviously > > Junio! (not to mention Google, who made all this possible) > > > > Thanks all! > > Thanks! Well, with so many thankyous going on, who am I to hide behind a rock? Seriously again, Paul, it is so good to have you. I have mentored GSoC students before and it is no secret that I had to take a (partially forced) break. This summer was really excellent for me because I could be lazy ;-) What strikes me as particularly pleasant is that you are really responsive and I personally feel that your project has not only been successful but will benefit many, many Windows users once 2.6.0 comes out (the performance boost will be noticeable, I am sure). So here is a hearfelt: well done! Ciao, Dscho -- 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: [git-for-windows] Re: Git for Windows 2.5.1 is out
On Wed, 2 Sep 2015, Aaron Bird wrote: > I am running windows 8.1. Every time I try and open git Bash I get an > unexpected kernal mode trap error and computer instantly shuts down. For lurkers, Aaron also reported this bug at https://github.com/git-for-windows/git/issues/348 and we are eagerly waiting for his feedback. Ciao, Johannes -- 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
On a personal note
Hey all, yes, it is true: since mid-August I am working for Microsoft. Over a year ago, I got into contact with the Visual Studio Online group at Microsoft, of which I am now a happy member. A large part of my mission is to improve the experience of Git for Windows. This is very exciting to me: I finally can focus pretty much full time on something that I could only address in my spare time previously. Of course, Git for Windows will stay exactly the same project as before. It will not suddenly turn into a Microsoft product. Obviously, it will stay Open Source, its goal remains to bring the awesome Git SCM to Windows, and I will continue to participate actively in the Git community, if anything even more actively. After the release of Git for Windows 2.5.0 and 2.5.1, there are quite a few loose ends to tie up; All the better that I can now dedicate enough time to address them, and that I now also have time to work properly with contributors on improving Git for Windows. I am really excited to join the club of Git developers who get paid to work on Git as part of their day-jobs. In short: for users and contributors of Git for Windows, nothing changes. Except that Pull Requests and issues may be dealt with more swiftly, and that I will actively work on keeping Git for Windows more closely in sync with Git proper. Good times! Johannes -- 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: git bash bug: ipython doesn't work
Hi Sergey, On 2015-09-03 18:56, Sergey Chipiga wrote: > I downloaded git for windows v2.5.1. And in git bash I can't launch ipython. > I suppose it forwards stdout somethere. I replied in the ticket you opened on GitHub: https://github.com/git-for-windows/git/issues/352 Ciao, Johannes -- 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: Do you plan to release 2.5.2 any time soon?
Hi Junio, On 2015-09-03 21:00, Junio C Hamano wrote: > Johannes Schindelin writes: > >> I have a couple of fixes lined up for bugs in Git for Windows 2.5.1. Do >> you plan to release 2.5.2 any time soon? If yes, I would hold off, >> otherwise I will just do a Git for Windows 2.5.1 (Rel 2). > > Among the topics marked for possible later merging to 'maint' in the > draft release notes to 2.6, candidates for future maintenance > snapshots are: > > * mh/get-remote-group-fix # 4 (2 weeks ago) > * cb/open-noatime-clear-errno # 1 (9 days ago) > * jk/long-error-messages # 2 (9 days ago) > * jh/strbuf-read-use-read-in-full # 1 (9 days ago) > * ps/t1509-chroot-test-fixup # 2 (2 weeks ago) > * sg/help-group # 1 (8 days ago) > * nd/dwim-wildcards-as-pathspecs # 1 (9 days ago) > * jk/fix-alias-pager-config-key-warnings # 1 (3 days ago) > * jk/rev-list-has-no-notes # 1 (3 days ago) > * nd/fixup-linked-gitdir # 1 (2 days ago) > * as/docfix-reflog-expire-unreachable # 1 (8 days ago) > * sg/t3020-typofix # 1 (8 days ago) > * po/po-readme # 1 (8 days ago) > * sg/wt-status-header-inclusion # 1 (8 days ago) > * ss/fix-config-fd-leak # 1 (8 days ago) > * jc/calloc-pathspec # 1 (8 days ago) > * rs/archive-zip-many # 3 (2 days ago) > * dt/commit-preserve-base-index-upon-opportunistic-cache-tree-update # > 1 (2 days ago) > * cc/trailers-corner-case-fix # 3 (22 hours ago) > * jk/log-missing-default-HEAD # 1 (22 hours ago) > * ee/clean-test-fixes # 1 (22 hours ago) > > These I deem are safe (not just the changes themselves are trivially > correct but it is unlikely to make things gravely worse if it turns > out there were ramifications no reviewers thought about with them) > and can go in 2.5.2. > > As to other topics that are in 'master' but not in the above list, I > do not have doubt about their value (otherwise they would not be in > 'master' in the first place), but either they are still too young in > 'master' or are with sufficiently big impact on the callchain that > it is not entirely implausible that they have risks of unforeseen > ramifications and fallouts. > > Let's aim to tag 2.5.2 soonish, before mid next-week at the latest. Okay! Thank you, Dscho -- 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: On a personal note
On 2015-09-03 15:06, Levente wrote: > Is the 'git for windows' development is in a separate branch? https://github.com/git-for-windows/git/ (see the "repository" link on the upper right of http://git-for-windows.github.io/). Ciao, Johannes -- 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 report: GIT PRO/Branches chapter
Hi Robert, On 2015-09-09 08:11, Robert Macháček wrote: > Just reading this chapter: > https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell > > I believe that: Figure 3-9. Divergent history > (https://git-scm.com/book/en/v2/book/03-git-branching/images/advance-master.png) > does not show the final "2 branch situation" as described in the > example in this chapter. I guess you want to report it here: https://github.com/progit/progit2/issues (as suggested by the link on the left side of the page you referred to, where it says: "The source of this book is hosted on GitHub. Patches, suggestions and comments are welcome.") You might want to search the tickets first, though, to make sure that it has not been reported before (or even already addressed). Ciao, Johannes -- 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] am --skip/--abort: merge HEAD/ORIG_HEAD tree into index
This is a backport of the corresponding patch to the builtin am in 2.6: 3ecc704 (am --skip/--abort: merge HEAD/ORIG_HEAD tree into index, 2015-08-19). Reportedly, it can make a huge difference on Windows, in one case a `git rebase --skip` took 1m40s without, and 5s with, this patch. Reported-and-suggested-by: Kim Gybels Original report: https://github.com/git-for-windows/git/issues/365 Acked-by: Paul Tan Signed-off-by: Johannes Schindelin --- contrib/examples/git-am.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/examples/git-am.sh b/contrib/examples/git-am.sh index 3b77028..dd539f1 100755 --- a/contrib/examples/git-am.sh +++ b/contrib/examples/git-am.sh @@ -512,7 +512,7 @@ then git read-tree --reset -u $head_tree $head_tree && index_tree=$(git write-tree) && git read-tree -m -u $index_tree $head_tree - git read-tree $head_tree + git read-tree -m $head_tree ;; ,t) if test -f "$dotest/rebasing" -- https://github.com/git/git/pull/173 -- 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] am --skip/--abort: merge HEAD/ORIG_HEAD tree into index
Hi Junio, On 2015-09-09 11:10, Johannes Schindelin wrote: > This is a backport of the corresponding patch to the builtin am in 2.6: > 3ecc704 (am --skip/--abort: merge HEAD/ORIG_HEAD tree into index, > 2015-08-19). > > Reportedly, it can make a huge difference on Windows, in one case a `git > rebase --skip` took 1m40s without, and 5s with, this patch. > > Reported-and-suggested-by: Kim Gybels > Original report: https://github.com/git-for-windows/git/issues/365 > Acked-by: Paul Tan > Signed-off-by: Johannes Schindelin > --- > contrib/examples/git-am.sh | 2 +- Of course this should be `git-am.sh` in the 2.5.x branch... Could you adjust that on your side? Thanks, Dscho -- 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: storing cover letter of a patch series?
Hi Jake, On 2015-09-10 18:28, Jacob Keller wrote: > does anyone know of any tricks for storing a cover letter for a patch > series inside of git somehow? It is not stored as a blob, but I use `git branch --edit-description` to write the cover letter for patch series when I expect a couple of iterations. Ciao, Dscho -- 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 for Windows 2.5.2
Dear Git users, it is my pleasure to announce Git for Windows 2.5.2. The installers and portable versions can be downloaded from our home page at https://git-for-windows.github.io/. We have been quite busy, lots of contributions (mostly bug reports, but also the occasional Pull Request). Thank you all! The changes since Git for Windows 2.5.1 are: New Features • Comes with Git 2.5.2 • Alternates can now point to UNC paths, i.e. network drives. Bug fixes • The MSys2 runtime was taught not to look hard for groups, speeding up Git Bash's startup time. • A work around was added for issues when installing 32-bit Git for Windows on 64-bit Windows 10. • The installer no longer freezes when there are interactive commands in the user's .profile. • git rebase --skip was speeded up again. • The redirector in /bin/bash.exe now adjusts the PATH environment variable correctly (i.e. so that Git's executables are found) before launching the real Bash, even when called without --login. • When installing Git for Windows to a location whose path is longer than usual, Git commands no longer trigger occasional Bad address errors. • Git no longer asks for a DVD to be inserted again when one has been ejected from the D: drive. Ciao, Johannes -- 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: storing cover letter of a patch series?
Hi Jake, On 2015-09-10 23:00, Jacob Keller wrote: > On Thu, Sep 10, 2015 at 11:58 AM, Johannes Schindelin > wrote: >> >> On 2015-09-10 18:28, Jacob Keller wrote: >> >>> does anyone know of any tricks for storing a cover letter for a patch >>> series inside of git somehow? >> >> It is not stored as a blob, but I use `git branch --edit-description` to >> write the cover letter for patch series when I expect a couple of iterations. > > Does this (or can it?) get used by send-email or format-patch's > --cover-letter? This sounds like exactly what I want. Yes, format-patch picks it up if you say `--cover-letter`. Ciao, Johannes P.S.: Please do cut down the quoted text to the part you are actually responding to. Bottom-posting is not much better than top-posting... -- 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: error opening
Hi Adrian, please note that Renato never got your mail (you should always use reply-to-all). I re-Cc:ed him, please do not forget to reply-to-all next time. On 2015-09-11 23:33, Adrian Ang wrote: > Renato Akaboci gmail.com> writes: >> >> I´m in trouble just after installation of my Git for Windows. >> I get a box with error saying: >> >> couldn´t read file "C:\Program >> Files\Git\cmd\mingw64\libexec\git-core\git-gui": no such file or >> directory > > I'm having the exact same problem. Please see the corresponding ticket: https://github.com/git-for-windows/git/issues/376 In short: I will release an updated installer soon, with other fixes. In the meantime, as a work-around you could right-click on the Git GUI shortcut (you can right-click the icon in the Windows menu and open the file location to get there), select Properties... and change the Target: from "C:\Program Files\Git\cmd\git-gui.exe" to "C:\Program Files\Git\cmd\git.exe" gui It will open an ugly, unnecessary console until the next Git for Windows version is available, but at least it will work until then. Out of curiosity: how did you go about finding the best place to report this bug? Ciao, Johannes -- 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: v2.5.2 installation on Windows 10
Hi Long, On 2015-09-11 18:13, Long wrote: > Installation of 64bit could complete, but running Git GUI always prompt the > error below: > > Couldn’t read file “C:\Program > Files\Git\cmd\mingw64\libexec\git-core\git-gui”: no such file or > directory Please see the corresponding ticket: https://github.com/git-for-windows/git/issues/376 In short: I will release an updated installer soon, with other fixes. In the meantime, as a work-around you could right-click on the Git GUI shortcut (you can right-click the icon in the Windows menu and open the file location to get there), select Properties... and change the Target: from "C:\Program Files\Git\cmd\git-gui.exe" to "C:\Program Files\Git\cmd\git.exe" gui It will open an ugly, unnecessary console until the next Git for Windows version is available, but at least it will work until then. Out of curiosity: how did you go about finding the best place to report this bug? Ciao, Johannes -- 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: v2.5.2 installation on Windows 10
Dear Diaoul, it is considered rude on this mailing list to top-post, and likewise to cull the Cc: list. Please do not do that. On 2015-09-12 11:34, Diaoul wrote: > I can confirm this on the same setup (W10 64bit git 2.5.2) Please see the corresponding ticket: https://github.com/git-for-windows/git/issues/376 In short: I will release an updated installer soon, with other fixes. In the meantime, as a work-around you could right-click on the Git GUI shortcut (you can right-click the icon in the Windows menu and open the file location to get there), select Properties... and change the Target: from "C:\Program Files\Git\cmd\git-gui.exe" to "C:\Program Files\Git\cmd\git.exe" gui It will open an ugly, unnecessary console until the next Git for Windows version is available, but at least it will work until then. Out of curiosity: how did you go about finding the best place to report this bug? Ciao, Johannes -- 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: Git Deployment using existing multiple environments
Hi, On 2015-09-12 08:31, Sukhwinder Singh wrote: > We already have 3-4 environments setup on our Windows servers without Git > and each environment already has code which is different from each > other. > > There are three environments > Live > UAT > Test (has the latest code) > > > And then developers have their local copies. > > We write and test the code locally and manually move each point from > one environment to other using merging software and test at each > environment. > Now we want to use git because manually moving the code is a lengthy > process. Also as the developers have local copies, it is very > difficult to manage code. > > Code is written locally by the team and then after testing locally it > is first merged with "Test" environment code, then "UAT" and then, > finally with "Live". > So we have two concerns: > > There is different code already existing on these environments. > Testing the code on each environment using the web server. > > What is the best way to go about it? As I am new to git more details > will be helpful, like commands to use. It seems you are not only looking for commands to use, but for a proper workflow in which Git supports your work best. The key is to define the roles in your flow first, and then identify the optimal commands. In your case, I figure that there are three "merge lords" or "merge ladies", one for "Test", one for "UAT", one for "Live". And each of them needs to be notified when changes are ready to be merged, then merge the changes. If I was walking in your shoes, I would set up four repositories that each are owned by one of the "merge lords/ladies", or the developers, respectively. The code would move from one to the next repository, triggered by a notification, then being pulled into the environment, then tested, and if everything is okay, pushed into the next repository. (Actually, you could do without the repository corresponding to the "Live" version, but it would be a nice record.) However, this is just one possible suggestion. I would highly recommend buying and reading the book "Git for Teams", as it has extensive coverage of different work flows, their strengths and their weaknesses. Ciao, Johannes -- 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: v2.5.2 installation on Windows 10
Hi Long, On 2015-09-12 13:43, Long Yang wrote: > Thanks for the email to confirm the bug. Of course! Thank you for taking the time to report it. > To answer your question first, I found only the Community page at > http://www.git-scm.com/, as I was looking for a forum-kind of page to > see if someone had reported the same problem I had. Then I tried to > send a couple of emails to the mailing list, git@vger.kernel.org, as > instructed on the Community page. But none of my emails was > delivered. At the end, I post my case via gmane. Thank you, I think I will open a Pull Request to that Community page to suggest going the GitHub issues route in case of Windows-specific bugs. > In short, I still don't know how to successfully report a bug for Git. > Should I/users use GitHub? If the bug in question is a Windows-specific bug, or if you do not know whether it is a Windows-specific bug, then yes, please submit it to our GitHub issue tracker, as described in the "Contribute" section of our home page: http://git-for-windows.github.io/#contribute If you already know that the bug in question affects more than just Windows users, please report it to the Git mailing list, as you have done. (You will need to send plain-text messages, as the Git mailing list rejects HTML mails.) Ciao, Johannes -- 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] poll: honor the timeout on Win32
From: Edward Thomson
Ensure that when passing a pipe, the gnulib poll replacement will not
return 0 before the timeout has passed.
Not obeying the timeout (and merely returning 0) causes pathological
behavior when preparing a packfile for a repository and taking a
long time to do so. If poll were to return 0 immediately, this would
cause keep-alives to get sent as quickly as possible until the packfile
was created. Such deviance from the standard would cause megabytes (or
more) of keep-alive packets to be sent.
GetTickCount is used as it is efficient, stable and monotonically
increasing. (Neither GetSystemTime nor QueryPerformanceCounter have
all three of these properties.)
Signed-off-by: Edward Thomson
Signed-off-by: Johannes Schindelin
---
compat/poll/poll.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/compat/poll/poll.c b/compat/poll/poll.c
index a9b41d8..db4e03e 100644
--- a/compat/poll/poll.c
+++ b/compat/poll/poll.c
@@ -446,7 +446,7 @@ poll (struct pollfd *pfd, nfds_t nfd, int timeout)
static HANDLE hEvent;
WSANETWORKEVENTS ev;
HANDLE h, handle_array[FD_SETSIZE + 2];
- DWORD ret, wait_timeout, nhandles;
+ DWORD ret, wait_timeout, nhandles, start = 0, elapsed, orig_timeout = 0;
fd_set rfds, wfds, xfds;
BOOL poll_again;
MSG msg;
@@ -459,6 +459,12 @@ poll (struct pollfd *pfd, nfds_t nfd, int timeout)
return -1;
}
+ if (timeout != INFTIM)
+{
+ orig_timeout = timeout;
+ start = GetTickCount();
+}
+
if (!hEvent)
hEvent = CreateEvent (NULL, FALSE, FALSE, NULL);
@@ -603,7 +609,13 @@ poll (struct pollfd *pfd, nfds_t nfd, int timeout)
rc++;
}
- if (!rc && timeout == INFTIM)
+ if (!rc && orig_timeout && timeout != INFTIM)
+{
+ elapsed = GetTickCount() - start;
+ timeout = elapsed >= orig_timeout ? 0 : orig_timeout - elapsed;
+}
+
+ if (!rc && timeout)
{
SleepEx (1, TRUE);
goto restart;
--
https://github.com/git/git/pull/176
--
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 for Windows 2.5.2 (Release 2)
Dear Git users, you probably noticed that there was a really obvious bug in the "Git GUI" entry in the Start Menu (because it has been reported several times). I just released a new version that squashes this bug and three more. Please find it here: https://github.com/git-for-windows/git/releases/tag/v2.5.2.windows.2 In case you encounter a bug, please follow the guide lines on our wiki: https://github.com/git-for-windows/git/wiki/Issue-reporting-guidelines Ciao, Johannes -- 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: [git-for-windows] Re: Announcing Git for Windows 2.5.2
Hi Marko, On 2015-09-12 20:46, Marko Palola wrote: > I have some problems with 2.5.2 and 2.5.1 and bitdefender scanner. > but I can use v2.5.0 We have had plenty of reports since the start of the Git for Windows project in 2007. None of them have turned out to be true viruses, all of them were caused by flawed virus scanners. Further, I build these executables and installers on a trusted machine that is used exclusively for the development and maintenance of Git for Windows. So I am inclined to dismiss *any* such report, especially when it comes with no concrete evidence that there is indeed a virus present. Ciao, Johannes -- 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: Git Deployment using existing multiple environments
Hi,
please stop top-posting. It is quite irritating by now. Thank you.
On 2015-09-15 08:50, Sukhwinder Singh wrote:
> Now lets say we set up a repository at github which has the latest
> code (all test code)., Now at each of our own servers we already have
> existing code, that is Test, UAT and Live. For example, first he'll
> pull code from github to our Test Server and then move branches to UAT
> and then to Live. Can it work?
Yes, it can work.
The major problem here will be that you have only a single, central repository
that every developer has write access to, but you expect only a single trusted
person to deploy that code via three different stages. That can be tricky, in
particular if your trusted person is a newbie.
> If it can work then can I please get some some example commands or the
> procedure to set it up?
Sorry, this feels a bit too much like "could you please do all my work for me?"
to me. And if I really provide exact commands here, I may even be liable when
it does not work out in the end? I am not going to do that.
Instead, I will strongly suggest to learn enough about Git to answer those
quite simple questions ("How do I pull?", "What is a pull?", "How do I update a
test machine's working directory with the newest branch tip?") yourself. I
usually recommend https://try.github.io/
> Time is a bit of problem right now or I would have read book suggested by
> Johannes. I have searched on the internet but couldn't find any similar case.
If I was in your shoes, I would spend the time *now*, rather than quite
possibly spending 10x as much time later when I have to clean up a mess. In my
experience,
what looks like the cheap route (copying commands without understanding them,
really), invariably turns out to be the most expensive route possible.
In any case, this was as much useful feedback as I had to give to your
questions.
Ciao,
Johannes
--
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/67] fsck: don't fsck alternates for connectivity-only check
Hi Peff, On 2015-09-15 17:24, Jeff King wrote: > Commit 02976bf (fsck: introduce `git fsck --connectivity-only`, > 2015-06-22) recently gave fsck an option to perform only a > subset of the checks, by skipping the fsck_object_dir() > call. However, it does so only for the local object > directory, and we still do expensive checks on any alternate > repos. We should skip them in this case, too. > > Signed-off-by: Jeff King ACK! Sorry for missing this spot. Dscho -- 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 08/67] add reentrant variants of sha1_to_hex and find_unique_abbrev
Hi Junio, Jeff & Ramsay, On 2015-09-16 03:32, Junio C Hamano wrote: > Jeff King writes: > >>> Hmm, I haven't read any other patches yet (including those which use these >>> new '_to' functions), but I can't help feeling they should be named >>> something >>> like 'sha1_to_hex_str()' and 'find_unique_abbrev_str()' instead. i.e. I >>> don't get >>> the '_to' thing - not that I'm any good at naming things ... >> >> I meant it as a contrast with their original. sha1_to_hex() formats into >> an internal buffer and returns it. But sha1_to_hex_to() formats "to" a >> buffer of your choice. > > I think that naming makes perfect sense. I have to admit that I needed the explanation. Maybe we should stick to the established practice of the many, many reentrant POSIX functions following the *_r() naming convention? I.e. the reentrant version of localtime() is called localtime_r(), the reentrant version of random() is called random_r() etc. So I could see myself not needing an explanation if I had read sha1_to_hex_r(...). Ciao, Dscho -- 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: Big path on git add file [windows bug]
Hi Alexey, On 2015-09-16 10:01, Alexey Kasyanchuk wrote: > I tried add one of node.js module to git project. But add operation failed: > > libgit2 returned: Invalid path for filesystem > 'E:/Projects/vsteams/node_modules/gulp-imagemin/node_modules/imagemin/node_modules/imagemin-gifsicle/node_modules/gifsicle/node_modules/bin-build/node_modules/decompress/node_modules/decompress-tar/node_modules/strip-dirs/node_modules/is-natural-number/is-natural-number-cjs.js': > Data area passed to a system call is too small. It is indeed too small for normal operations (MAX_PATH is somewhere around 248). However, as far as I know, libgit2 has internal code to convert the path into a form that the Win32 API can handle. > Is this windows problem or problem with libgit2 realization on windows > (windows 7 by the way)? It looked like problem with big system path > (276 symbols). May be some sulution for this? Yes, there is a sulution for this. But it is unclear whether you have that already or not because you were a little parsimonious with information. For example, I have no idea which libgit2 version you use, in which context, what program you use to call libgit2, etc. So I am left guessing, which is a little bit inefficient. In any case, the work-around for the issue you described is in https://github.com/libgit2/libgit2/commit/cceae9a25d0bed8b00f4981e051d5f380ef54401 which is part of v0.22.1. > Version: Git-2.5.2.2-64-bit No, that is not the correct version. This looks like the current Git for Windows version, but the error you reported is clearly a libgit2 error message. And that Git for Windows version contains no libgit2 at all. Please clarify. You might want to err on the side of verbosity to avoid unnecessary back-and-forth. Ciao, Johannes -- 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: On a personal note
Hi Duy, On 2015-09-17 15:29, Duy Nguyen wrote: > On Thu, Sep 3, 2015 at 5:00 PM, Johannes Schindelin > wrote: >> >> yes, it is true: since mid-August I am working for Microsoft. Over a >> year ago, I got into contact with the Visual Studio Online group at >> Microsoft, of which I am now a happy member. A large part of my mission >> is to improve the experience of Git for Windows. This is very exciting >> to me: I finally can focus pretty much full time on something that I >> could only address in my spare time previously. > > Is upstreaming msysgit-specific patches in the roadmap? It would be > very nice to have everything in one tree (or at least keep the two > trees as close as possible). Please strike that name "msysgit" from your memory. Just remember "Git for Windows". (The name "msysgit" *never* referred to "Git for Windows", but only to the development environment used to generate Git for Windows 1.x). Please. Thank you. And yes, the roadmap is pretty clear from the GitHub tickets, e.g. this one: https://github.com/git-for-windows/git/issues/285 Please note that I held off this week for three reasons: 1) I was submitting patches to the MSys2 and Cygwin upstream first, 2) I was busy fixing e.g. that bug where home directories containing non-ASCII characters were handled incorrectly (and generally trying to keep the tickets in https://github.com/git-for-windows/git under something similar to control), and 3) what with Peff's and Stefan's huge patch series, I did not want to overload Junio. Please note that I already started submitting patches, though: http://thread.gmane.org/gmane.comp.version-control.git/277542 http://article.gmane.org/gmane.comp.version-control.git/277731 Ciao, Dscho -- 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
Windows patches roadmap, was Re: On a personal note
Hi Stefan, [sorry that your mail to the git-for-windows Google Group got rejected; I want to try to keep this list subscribers-only as long as possible so as not to waste precious time on moderating 20+ spam mails per day, as we used to do with msysgit's mailing list.] On 2015-09-17 21:27, Stefan Beller wrote: > On Thu, Sep 17, 2015 at 11:54 AM, Johannes Schindelin > wrote: >> >> And yes, the roadmap is pretty clear from the GitHub tickets, e.g. this one: >> >> https://github.com/git-for-windows/git/issues/285 > > That's pretty awesome. Glad it's on the roadmap! > >> >> Please note that I held off this week for three reasons: >> >> 1) I was submitting patches to the MSys2 and Cygwin upstream first, >> >> 2) I was busy fixing e.g. that bug where home directories containing >> non-ASCII characters were handled incorrectly (and generally trying to keep >> the tickets in https://github.com/git-for-windows/git under something >> similar to control), and >> >> 3) what with Peff's and Stefan's huge patch series, I did not want to >> overload Junio. > > My patch series is not large by any means, but it seems as if it requires > lots of discussion in the fine details. ;) Yes, I actually meant the impact on the bandwidth of the Git mailing list, not the size of the patch series per se, sorry. I think that it is highly valuable what you are doing there, and I wish I had more time to participate in improving it... (but just when I think I have time, another bug report comes in, or some day-job stuff, or Junio releases a new version and I scramble to get a new Git for Windows version out... ;-)) Ciao, Dscho -- 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 for Windows 2.5.3
Dear Git users, it is my pleasure to announce that Git for Windows 2.5.3 can be downloaded from https://git-for-windows.github.io/. I would like to take this opportunity to thank everybody who contributes to this project (and you will see below that there have been quite a few changes since release 2 of version 2.5.3 this past Sunday), in particular Matthias Aßhauer and @nalla for tireless testing and contributing patches. Changes since Git-2.5.2(2) (September 13th 2015) New Features • Comes with Git 2.5.3. • Includes git flow. • By configuring `git config core.editor notepad`, users can now use notepad.exe as their default editor. Configuring `git config format.commitMessageColumns 72` will be picked up by the notepad wrapper and line-wrap the commit message after the user edited it. • The Subversion bindings for use with git svn were upgraded to version 1.9.1. • Some interactive console programs, e.g. psql.exe, now work in mintty thanks to pre-configured aliases. • The mechanism to diff .pdf, .doc and .docx files known from Git for Windows 1.x has been ported to Git for Windows 2.x. • Git can now access IPv6-only hosts via HTTP/HTTPS. Bug fixes • The .vimrc in the home directory is now allowed to have DOS line endings. • The README.portable file of the portable Git mentions the need to run post-install.bat when the archive was extracted manually. • Home directories for user names with non-ASCII characters are handled correctly now. • The documentation no longer shows plain-text linkgit:... "links" but proper hyperlinks instead. • The mtab link is written to /etc/mtab again, as it should. • When run inside the PowerShell, Git no longer gets confused when the current directory's path and what is recorded in the file system differs in case (e.g. "GIT/" vs "Git/"). Ciao, Johannes -- 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: Unable to create temporary file '/var/git/tmv3-target-overlay.git/shallow_Un8ZOR': Permission denied
Hi Duy, On 2015-09-19 04:21, Duy Nguyen wrote: > On Thu, Sep 17, 2015 at 11:54 PM, Joakim Tjernlund > wrote: >> On Thu, 2015-09-17 at 20:18 +0700, Duy Nguyen wrote: >>> On Mon, Sep 14, 2015 at 10:37 PM, Joakim Tjernlund >>> wrote: >>> > On Mon, 2015-08-31 at 16:56 +0700, Duy Nguyen wrote: >>> > > On Fri, Aug 21, 2015 at 6:36 PM, Joakim Tjernlund >>> > > wrote: >>> > > > I cannot push: >>> > > > # > git push origin >>> > > > Login for jo...@git.transmode.se >>> > > > Password: >>> > > > Counting objects: 7, done. >>> > > > Delta compression using up to 4 threads. >>> > > > Compressing objects: 100% (7/7), done. >>> > > > Writing objects: 100% (7/7), 13.73 KiB | 0 bytes/s, done. >>> > > > Total 7 (delta 4), reused 0 (delta 0) >>> > > > fatal: Unable to create temporary file >>> > > > '/var/git/tmv3-target-overlay.git/shallow_Un8ZOR': Permission >>> > > > denied > > I'm about to do it, but now I'm not sure if I should move > shallow_XX out of $GIT_DIR. It will not be the only command that > may write to $GIT_DIR. "git gc --auto" (which can be triggered at the > server side at push time) can write $GIT_DIR/gc.pid (and soon, > gc.log). Even if you disable gc --auto and run it periodically (with > cron or something), it will write gc.pid. > > Is it really necessary to remove write access in $GIT_DIR? Do we (git > devs) have some guidelines about things in $GIT_DIR? IMO it makes little sense to remove write access from users who you want to push. They need to write objects to the directory, after all, and update refs. This problem sounds more like the doing of an overzealous sysadmin to me than a careful one who researched diligently what locations require write access for the intended operations. Personally, I see little sense in bending over to try to support such an intentionally tampered setup. Ciao, Dscho -- 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: Unable to create temporary file '/var/git/tmv3-target-overlay.git/shallow_Un8ZOR': Permission denied
Hi Joakim, On 2015-09-21 19:08, Joakim Tjernlund wrote: > On Mon, 2015-09-21 at 09:48 -0700, Junio C Hamano wrote: >> Duy Nguyen writes: >> >> > Is it really necessary to remove write access in $GIT_DIR? Do we (git >> > devs) have some guidelines about things in $GIT_DIR? >> >> Those who are allowed to "git push" into it should be able to write >> there. It is a different matter that "git" program itself may make >> a policy decision to disallow some operations that the filesystem >> bits alone would have allowed (e.g. you can arrange the "pusher" to >> only come over the wire via "receive-pack" and "receive-pack" may >> deliberately lack support for writing into $GIT_DIR/config). >> > > I view $GIT_DIR similar to "/" and "/tmp". Normally one does not let > normal users write to "/" > as you want to keep this level clean. It is not obvious to everybody > what files are important > under $GIT_DIR when mixed with tmp files etc. > $GIT_DIR/tmp would solve this nicely. By now it is pretty clear that you won't find many people here you share your opinion about locking down the Git directory. The reason should be easy to understand: Git's concept is based on the idea that you have full control over your repository. Other repositories you might only have read access. But this idea you have, to somehow introduce fine-grained levels of control, this idea would imply that all of a sudden Git is no longer free to write to its files as it likes. And as far as Git is concerned, everything inside .git/ *are* its files. So in essence, the core concept of Git -- you clone a repository you cannot write to so that you have a local repository you can do *anything you like* to -- is pretty much incompatible with this idea of a selective lock down of files in .git/ that not only would require you to know very exactly what files Git might want to write, but also to keep yourself up-to-date with Git's development as to which files it might want to write for *every* new version. Making only .git/tmp/ a writable location further fails to acknowledge the fact that the hierarchy of to-be-written files follows the function of those files, not any write permission hierarchy. Since the idea seems so alien to Git's core concept, I called it "overzealous". If that hurt your feelings, I am sorry and would like to apologize. Having said all that, I believe that reiterating this idea without pointing to any benefit will continue to fail to convince people that the idea is sound and that Git's core concept should change. If you need to exert more control in a specific repository, you simply make it accessible only as a non-file-system remote (where only `git`, `git-receive-pack` and `git-upload-pack` are allowed to be executed) and define hooks that can accept or deny on a *much* finer level than file system permissions ever could, after all. Ciao, Johannes -- 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: Unable to create temporary file '/var/git/tmv3-target-overlay.git/shallow_Un8ZOR': Permission denied
Hi Joakim, On 2015-09-22 22:58, Joakim Tjernlund wrote: > On Tue, 2015-09-22 at 22:00 +0200, Johannes Schindelin wrote: >> >> The reason should be easy to understand: Git's concept is based on the idea >> that you have full control over >> your repository. Other repositories you might only have read access. > > Yes and some repos I only have partial write access to(config, hooks > etc. might be readonly) The partial write access idea is definitely not part of the original idea of Git, and your use case is actually the first I heard of. The original idea was really that you either own your repository, or you do not. And that includes the repositories that can be accessed publicly: you own them or you don't. Now, I know that in particular in some corporate setups, there needs to be a permission system in place that disallows certain users from doing certain things (such as editing the config). The Git solution is to set up a server, usually with SSH, and allow users to push and fetch from the repositories, but nothing else (i.e. no shell access), then set up hooks to implement the permission system. This is much less error prone than partially locking down a repository on some network drive because the file system structure simply does not reflect the permission structure. That is where all your troubles come from. >> But this idea you have, to somehow introduce fine-grained levels of control, >> this idea would imply that all >> of a sudden Git is no longer free to write to its files as it likes. And as >> far as Git is concerned, >> everything inside .git/ *are* its files. > > This does not compute for me, files inside git are git's files, I only > think that not all users > to a repo should have the same (write) access. But then it is your duty to tell *Git* what it can and what it cannot do. Typically via those hooks I mentioned. > A .git/tmp/ would make housekeeping easier, you would know that every > file under .git > should be there and if you find something you don't recognize you would react. No, it would actually make it harder. I seem to recall that there was some problem with renaming a file unless it was already in the same directory as the destination. If all files were to be written to .git/tmp/ first... >> If you need to exert more control in a specific repository, you simply make >> it accessible only as a non-file-system remote >> (where only `git`, `git-receive-pack` and `git-upload-pack` are allowed to >> be executed) and define hooks >> that can accept or deny on a *much* finer level than file system permissions >> ever could, after all. > > Even if I did go through this hassle, I would prefer if temporary data > were put somewhere else > than .git/ as I think mixing config/persistent data with temporary > data in the same directory is something > that should be avoided. Sure, I understand what you ask for. It's just that Git worked in a different direction for 10 years now ;-) Ciao, Johannes -- 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: Unable to create temporary file '/var/git/tmv3-target-overlay.git/shallow_Un8ZOR': Permission denied
Hi Joakim, On 2015-09-23 22:41, Joakim Tjernlund wrote: > On Wed, 2015-09-23 at 13:10 +0200, Johannes Schindelin wrote: >> >> On 2015-09-22 22:58, Joakim Tjernlund wrote: >> > On Tue, 2015-09-22 at 22:00 +0200, Johannes Schindelin wrote: >> > > >> > > The reason should be easy to understand: Git's concept is based on the >> > > idea that you have full control >> > > over >> > > your repository. Other repositories you might only have read access. >> > >> > Yes and some repos I only have partial write access to(config, hooks >> > etc. might be readonly) >> >> The partial write access idea is definitely not part of the original idea of >> Git, and your use case is >> actually the first I heard of. > > Ouch, that cannot be so?? Yes, it can be so. In fat, it is so. Please note that I *did* encounter valid scenarios where some operations might not be desirable (and therefore need to be prevented). One such scenario (maybe even the first one) was to prevent non-fast-forward pushes. But you will certainly agree that this cannot be prevented by mere file system permission: they are not fine-grained enough. So we introduced a config option -- because in contrast to file system permissions, Git *does* have the means to enforce that rule. So it all comes back to the point I made earlier, and that I really would like you to understand: Git's concepts do not align well with file system permissions. Not well at all, in fact. So the method of choice is indeed what you called that "big axe" which is not such a big axe after all. You just need to set up an SSH server and define very clearly in the hooks what you consider permissible. Yep, that's a bit of work, but it is less work than would be required of Git to bend it so the same could be done via file system permissions. And stay that way. Now, it might be possible for some operations, to *make* Git align with that permission system. But that sounds more and more like the desired changes would require Git developers to put in a lot of work in favor of others being able to avoid work, just for the sake of keeping with an idea that has been demonstrated to be flawed. If you are looking for fans of that idea, count me out ;-) Of course, if you are willing to put in the work to make it possible to restrict certain Git operations simply by using `chmod`, and to pay attention that it stays that way, go right ahead and submit a patch series to that end... Junio already indicated that he would not be flatly opposed to accept such changes ;-) Ciao, Johannes -- 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 2/4] pack-objects: do not get distracted by stale refs
It is quite possible for, say, a remote HEAD to become stale, e.g. when the default branch was renamed. We should still be able to pack our objects when such a thing happens; simply ignore invalid refs (because they cannot matter for the packing process anyway). Signed-off-by: Johannes Schindelin --- builtin/pack-objects.c | 1 + 1 file changed, 1 insertion(+) diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c index 1c63f8f..ef2f794 100644 --- a/builtin/pack-objects.c +++ b/builtin/pack-objects.c @@ -2499,6 +2499,7 @@ static void get_object_list(int ac, const char **av) int flags = 0; init_revisions(&revs, NULL); + revs.ignore_missing = 1; save_commit_buffer = 0; setup_revisions(ac, av, &revs, NULL); -- 2.5.2.windows.2 -- 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 1/4] gc: demonstrate failure with stale remote HEAD
Signed-off-by: Johannes Schindelin --- t/t6500-gc.sh | 15 +++ 1 file changed, 15 insertions(+) diff --git a/t/t6500-gc.sh b/t/t6500-gc.sh index 63194d8..b736774 100755 --- a/t/t6500-gc.sh +++ b/t/t6500-gc.sh @@ -30,4 +30,19 @@ test_expect_success 'gc -h with invalid configuration' ' test_i18ngrep "[Uu]sage" broken/usage ' +test_expect_failure 'gc removes broken refs/remotes//HEAD' ' + git init remote && + ( + cd remote && + test_commit initial && + git clone . ../client && + git branch -m develop && + cd ../client && + git fetch --prune && + git gc && + git branch --list -r origin/HEAD >actual && + test_line_count = 0 actual + ) +' + test_done -- 2.5.2.windows.2 -- 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/4] Fix gc failure when a remote HEAD goes stale
There has been a report in the Git for Windows project that gc fails sometimes: https://github.com/git-for-windows/git/issues/423 It turns out that there are cases when a remote HEAD can go stale and it is not the user's fault at all. It can happen, for example, if the active branch in the remote repository gets renamed. Git's garbage collector should handle this gracefully. The best this developer could come up with, is to simply ignore and delete the now-broken refs. Johannes Schindelin (4): gc: demonstrate failure with stale remote HEAD pack-objects: do not get distracted by stale refs mark_reachable_objects(): optionally collect broken refs gc: remove broken refs builtin/pack-objects.c | 1 + builtin/prune.c| 12 +++- builtin/reflog.c | 2 +- reachable.c| 26 -- reachable.h| 3 ++- t/t6500-gc.sh | 15 +++ 6 files changed, 50 insertions(+), 9 deletions(-) -- 2.5.2.windows.2 -- 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/4] mark_reachable_objects(): optionally collect broken refs
The behavior of `mark_reachable_objects()` without this patch is that it
dies if it encounters a broken ref. This is sometimes undesirable, e.g.
when garbage collecting in a repository with a stale remote HEAD.
So let's introduce an optional parameter to collect such broken refs. The
behavior of the function is unchanged if that parameter is `NULL`.
Signed-off-by: Johannes Schindelin
---
builtin/prune.c | 2 +-
builtin/reflog.c | 2 +-
reachable.c | 26 --
reachable.h | 3 ++-
4 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/builtin/prune.c b/builtin/prune.c
index 10b03d3..d6f664f 100644
--- a/builtin/prune.c
+++ b/builtin/prune.c
@@ -136,7 +136,7 @@ int cmd_prune(int argc, const char **argv, const char
*prefix)
if (show_progress)
progress = start_progress_delay(_("Checking connectivity"), 0,
0, 2);
- mark_reachable_objects(&revs, 1, expire, progress);
+ mark_reachable_objects(&revs, 1, expire, progress, NULL);
stop_progress(&progress);
for_each_loose_file_in_objdir(get_object_directory(), prune_object,
prune_cruft, prune_subdir, NULL);
diff --git a/builtin/reflog.c b/builtin/reflog.c
index f96ca2a..cb8758a 100644
--- a/builtin/reflog.c
+++ b/builtin/reflog.c
@@ -583,7 +583,7 @@ static int cmd_reflog_expire(int argc, const char **argv,
const char *prefix)
init_revisions(&cb.cmd.revs, prefix);
if (flags & EXPIRE_REFLOGS_VERBOSE)
printf("Marking reachable objects...");
- mark_reachable_objects(&cb.cmd.revs, 0, 0, NULL);
+ mark_reachable_objects(&cb.cmd.revs, 0, 0, NULL, NULL);
if (flags & EXPIRE_REFLOGS_VERBOSE)
putchar('\n');
}
diff --git a/reachable.c b/reachable.c
index 9cff25b..1fc7ada 100644
--- a/reachable.c
+++ b/reachable.c
@@ -15,6 +15,11 @@ struct connectivity_progress {
unsigned long count;
};
+struct add_one_data {
+ struct rev_info *revs;
+ struct string_list *broken_refs;
+};
+
static void update_progress(struct connectivity_progress *cp)
{
cp->count++;
@@ -25,10 +30,14 @@ static void update_progress(struct connectivity_progress
*cp)
static int add_one_ref(const char *path, const struct object_id *oid,
int flag, void *cb_data)
{
- struct object *object = parse_object_or_die(oid->hash, path);
- struct rev_info *revs = (struct rev_info *)cb_data;
+ struct add_one_data *data = (struct add_one_data *)cb_data;
+ struct object *object = data->broken_refs ? parse_object(oid->hash) :
+ parse_object_or_die(oid->hash, path);
- add_pending_object(revs, object, "");
+ if (!object)
+ string_list_append(data->broken_refs, path);
+ else
+ add_pending_object(data->revs, object, "");
return 0;
}
@@ -153,9 +162,11 @@ int add_unseen_recent_objects_to_traversal(struct rev_info
*revs,
void mark_reachable_objects(struct rev_info *revs, int mark_reflog,
unsigned long mark_recent,
- struct progress *progress)
+ struct progress *progress,
+ struct string_list *broken_refs)
{
struct connectivity_progress cp;
+ struct add_one_data data;
/*
* Set up revision parsing, and mark us as being interested
@@ -168,11 +179,14 @@ void mark_reachable_objects(struct rev_info *revs, int
mark_reflog,
/* Add all refs from the index file */
add_index_objects_to_pending(revs, 0);
+ data.revs = revs;
+ data.broken_refs = broken_refs;
+
/* Add all external refs */
- for_each_ref(add_one_ref, revs);
+ for_each_ref(add_one_ref, &data);
/* detached HEAD is not included in the list above */
- head_ref(add_one_ref, revs);
+ head_ref(add_one_ref, &data);
/* Add all reflog info */
if (mark_reflog)
diff --git a/reachable.h b/reachable.h
index d23efc3..39de1c7 100644
--- a/reachable.h
+++ b/reachable.h
@@ -5,6 +5,7 @@ struct progress;
extern int add_unseen_recent_objects_to_traversal(struct rev_info *revs,
unsigned long timestamp);
extern void mark_reachable_objects(struct rev_info *revs, int mark_reflog,
- unsigned long mark_recent, struct progress
*);
+ unsigned long mark_recent, struct progress *,
+ struct string_list *broken_refs);
#endif
--
2.5.2.windows.2
--
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 4/4] gc: remove broken refs
When encountering broken refs, such as a stale remote HEAD (which can
happen if the active branch was renamed in the remote), it is more
helpful to remove those refs than to exit with an error.
This fixes https://github.com/git-for-windows/git/issues/423
Signed-off-by: Johannes Schindelin
---
builtin/prune.c | 12 +++-
t/t6500-gc.sh | 2 +-
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/builtin/prune.c b/builtin/prune.c
index d6f664f..1a30f65 100644
--- a/builtin/prune.c
+++ b/builtin/prune.c
@@ -6,6 +6,7 @@
#include "reachable.h"
#include "parse-options.h"
#include "progress.h"
+#include "refs.h"
static const char * const prune_usage[] = {
N_("git prune [-n] [-v] [--expire ] [--] [...]"),
@@ -100,6 +101,7 @@ static void remove_temporary_files(const char *path)
int cmd_prune(int argc, const char **argv, const char *prefix)
{
struct rev_info revs;
+ struct string_list broken_refs = STRING_LIST_INIT_DUP;
struct progress *progress = NULL;
const struct option options[] = {
OPT__DRY_RUN(&show_only, N_("do not remove, show only")),
@@ -110,6 +112,7 @@ int cmd_prune(int argc, const char **argv, const char
*prefix)
OPT_END()
};
char *s;
+ int i;
expire = ULONG_MAX;
save_commit_buffer = 0;
@@ -136,7 +139,14 @@ int cmd_prune(int argc, const char **argv, const char
*prefix)
if (show_progress)
progress = start_progress_delay(_("Checking connectivity"), 0,
0, 2);
- mark_reachable_objects(&revs, 1, expire, progress, NULL);
+ revs.ignore_missing = 1;
+ mark_reachable_objects(&revs, 1, expire, progress, &broken_refs);
+ for (i = 0; i < broken_refs.nr; i++) {
+ char *path = broken_refs.items[i].string;
+ printf("Removing stale ref %s\n", path);
+ if (!show_only && delete_ref(path, NULL, REF_NODEREF))
+ die("Could not remove stale ref %s", path);
+ }
stop_progress(&progress);
for_each_loose_file_in_objdir(get_object_directory(), prune_object,
prune_cruft, prune_subdir, NULL);
diff --git a/t/t6500-gc.sh b/t/t6500-gc.sh
index b736774..0ae4271 100755
--- a/t/t6500-gc.sh
+++ b/t/t6500-gc.sh
@@ -30,7 +30,7 @@ test_expect_success 'gc -h with invalid configuration' '
test_i18ngrep "[Uu]sage" broken/usage
'
-test_expect_failure 'gc removes broken refs/remotes//HEAD' '
+test_expect_success 'gc removes broken refs/remotes//HEAD' '
git init remote &&
(
cd remote &&
--
2.5.2.windows.2
--
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: What's cooking in git.git (Sep 2015, #06; Wed, 23)
Hi Junio, On 2015-09-24 00:56, Junio C Hamano wrote: > * jc/fsck-dropped-errors (2015-09-23) 1 commit > - fsck: exit with non-zero when problems are found > > There were some classes of errors that "git fsck" diagnosed to its > standard error that did not cause it to exit with non-zero status. Thanks for this! > * sb/submodule-parallel-fetch (2015-09-23) 9 commits > - submodules: allow parallel fetching, add tests and documentation > - fetch_populated_submodules: use new parallel job processing > - SQUASH??? > - run-command: add an asynchronous parallel child processor > - run-command: factor out return value computation > - strbuf: add strbuf_read_once to read without blocking > - xread_nonblock: add functionality to read from fds without blocking > - xread: poll on non blocking fds > - submodule.c: write "Fetching submodule " to stderr > (this branch uses sb/submodule-helper.) > > Add a framework to spawn a group of processes in parallel, and use > it to run "git fetch --recurse-submodules" in parallel. > > It seems that the fundamentals are almost there, modulo polishing > the overall structure to ensure that future enhancement can be made > cleanly. Awesome. As I stated before, I am a big fan of this enhancement, even if I am sad that I have too little time to participate effectively. Ciao, Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v1] Add Travis CI support
Hi, On 2015-09-25 05:14, Dennis Kaarsemaker wrote: > On do, 2015-09-24 at 17:41 -0700, Junio C Hamano wrote: >> larsxschnei...@gmail.com writes: >> >> > My idea is that the owner of "https://github.com/git/git"; enables this >> > account >> > for Travis (it's free!). Then we would automatically get the test state >> > for all >> > official branches. >> >> The last time I heard about this "it's free" thing, I thought I >> heard that it wants write access to the repository. > > It does not need write access to the git data, only to auxiliary GitHub > data: commit status and deployment status (where it can put "this > commit failed tests"), repository hooks (to set up build triggers), > team membership (ro) and email addresses (ro). If that still elicits concerns, a fork could be set up that is automatically kept up-to-date via a web hook, and enable Travis CI there. Junio, if that is something with which you feel more comfortable, I would be willing to set it up. Even if the visibility (read: impact) would be higher if the badges were attached to https://github.com/git/git proper... Ciao, Dscho -- 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: Fwd: diff not finding difference
Hi Jack Adrian, On 2015-09-24 23:09, Jack Adrian Zappa wrote: > This is a weird one: > > [file-1 begin] > > abcd efg hijklmnop > > [file-1 end] > > [file-2 begin] > > blah blah blah > / > abdc boo ya! > > [file-2 end] > > Do a diff between these and it won't find any difference. > > Same with the following two lines, each in a different file: > sabc fed ghi jkl > abc def ghi jkl > > I first noticed this on the command line git and then in VS2013. The > original problem was like my first example. The files were much > longer, but all that git would see is the addition of the line of > ..., but not the removal of the original line. > > I've tried some other simple file changes with similar results. > Something seems to be definitely broken in git diff. :( You might want to show your exact command-line invocation, i.e. the full information. I suspect that you missed the fact that `git diff a b` does not compare the file a to the file b, but instead it compares both a and b to what is recorded in the index. With one quirk: if the files a and b are not even recorded in the index, `git diff` will output nothing. Now, the really confusing part for you was probably that your `file-2` *was* recorded in the index (maybe you made a backup copy with the extra file extension `.bak` or some such, and then called `git diff my-file.bak my-file` where `my-file` *actually is tracked by Git* but `my-file.bak` is not). But `git diff` has so nice features that I wanted to use it myself to compare files or directories. That is why I introduced the `--no-index` option, years ago. And so I suspect that you called git diff file-1 file-2 when you actually wanted to call git diff --no-index file-1 file-2 Here is my shell session to verify that `git diff` works as designed: ``` me@work $ cat >file-1 abcd efg hijklmnop me@work $ cat >file-2 blah blah blah / abdc boo ya! me@work $ git diff --no-index file-1 file-2 diff --git a/file-1 b/file-2 index 80ea2bc..f7fd7eb 100644 --- a/file-1 +++ b/file-2 @@ -1,3 +1,5 @@ -abcd efg hijklmnop +blah blah blah +/ +abdc boo ya! me@work $ ``` Please note that I ended the file contents for both `cat` calls [*1*] with a `Ctrl+D` which you cannot see in the pasted lines. Ciao, Johannes Footnote *1*: Can you believe that I wanted to make that pun for at least ten years 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/RFC] read-cache: fix file time comparisons with different precisions
Hi Karsten,
On 2015-09-28 12:39, Karsten Blees wrote:
> Different git variants record file times in the index with different
> precisions, according to their capabilities. E.g. git compiled with NO_NSEC
> records seconds only, JGit records the mtime in milliseconds, but leaves
> ctime blank (because ctime is unavailable in Java).
>
> This causes performance issues in git compiled with USE_NSEC, because index
> entries with such 'incomplete' timestamps are considered dirty, triggering
> unnecessary content checks.
>
> Add a file time comparison function that auto-detects the precision based
> on the number of trailing 0 digits, and compares with the lower precision
> of both values. This initial version supports the known precisions seconds
> (git + NO_NSEC), milliseconds (JGit) and nanoseconds (git + USE_NSEC), but
> can be easily extended to e.g. microseconds.
>
> Use the new comparison function in both dirty and racy checks. As a side
> effect, this fixes racy detection in USE_NSEC-enabled git with
> core.checkStat=minimal, as the coreStat setting now affects racy checks as
> well.
>
> Finally, do not check ctime if ctime.sec is 0 (as recorded by JGit).
Great analysis, and nice patch. I would like to offer one suggestion in
addition:
> diff --git a/read-cache.c b/read-cache.c
> index 87204a5..3a4e6cd 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -99,23 +99,50 @@ void fill_stat_data(struct stat_data *sd, struct stat *st)
> sd->sd_size = st->st_size;
> }
>
> +/*
> + * Compares two file times. Returns 0 if equal, <0 if t1 < t2, >0 if t1 > t2.
> + * Auto-detects precision based on trailing 0 digits. Compares seconds only
> if
> + * core.checkStat=minimal.
> + */
> +static inline int cmp_filetime(uint32_t t1_sec, uint32_t t1_nsec,
> +uint32_t t2_sec, uint32_t t2_nsec) {
> +#ifdef USE_NSEC
> + /*
> + * Compare seconds and return result if different, or checkStat=mimimal,
> + * or one of the time stamps has second precision only (nsec == 0).
> + */
> + int diff = t1_sec - t2_sec;
> + if (diff || !check_stat || !t1_nsec || !t2_nsec)
> + return diff;
> +
> + /*
> + * Check if one of the time stamps has millisecond precision only (i.e.
> + * the trailing 6 digits are 0). First check the trailing 6 bits so that
> + * we only do (slower) modulo division if necessary.
> + */
> + if ((!(t1_nsec & 0x3f) && !(t1_nsec % 100)) ||
> + (!(t2_nsec & 0x3f) && !(t2_nsec % 100)))
> + /* Compare milliseconds. */
> + return (t1_nsec - t2_nsec) / 100;
> +
> + /* Compare nanoseconds */
> + return t1_nsec - t2_nsec;
> +#else
> + return t1_sec - t2_sec;
> +#endif
> +}
As this affects only setups where the same repository is accessed via clients
with different precision, would it make sense to hide this behind a config
option? I.e. something like
static int cmp_filetime_precise(uint32_t t1_sec, uint32_t t1_nsec,
uint32_t t2_sec, uint32_t t2_nsec)
{
#ifdef USE_NSEC
return t1_sec != t2_sec ? t1_sec - t2_sec : t1_nsec - t2_nsec;
#else
return t1_sec - t2_sec;
#endif
}
static int cmp_filetime_mixed(uint32_t t1_sec, uint32_t t1_nsec,
uint32_t t2_sec, uint32_t t2_nsec)
{
#ifdef USE_NSEC
... detect lower precision and compare with lower precision only...
#else
return t1_sec - t2_sec;
#endif
}
static (int *)cmp_filetime(uint32_t t1_sec, uint32_t t1_nsec,
uint32_t t2_sec, uint32_t t2_nsec)
= cmp_filetime_precise;
... modify cmp_filetime_precise if core.mixedTimeSpec = true...
Otherwise there would be that little loop-hole where (nsec % 1000) == 0 *by
chance* and we assume the timestamps to be identical even if they are not.
Ciao,
Dscho
--
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 v2 2/4] pack-objects: do not get distracted by broken symrefs
It is quite possible for, say, a remote HEAD to become broken, e.g.
when the default branch was renamed.
We should still be able to pack our objects when such a thing happens;
simply ignore broken symrefs (because they cannot matter for the packing
process anyway).
Signed-off-by: Johannes Schindelin
---
reachable.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/reachable.c b/reachable.c
index 9cff25b..64289f3 100644
--- a/reachable.c
+++ b/reachable.c
@@ -25,9 +25,15 @@ static void update_progress(struct connectivity_progress *cp)
static int add_one_ref(const char *path, const struct object_id *oid,
int flag, void *cb_data)
{
- struct object *object = parse_object_or_die(oid->hash, path);
struct rev_info *revs = (struct rev_info *)cb_data;
+ struct object *object;
+ if ((flag & REF_ISSYMREF) && (flag & REF_ISBROKEN)) {
+ warning("ref is broken: %s", path);
+ return 0;
+ }
+
+ object = parse_object_or_die(oid->hash, path);
add_pending_object(revs, object, "");
return 0;
--
2.5.3.windows.1.3.gc322723
--
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 v2 1/4] gc: demonstrate failure with stale remote HEAD
Signed-off-by: Johannes Schindelin --- t/t6500-gc.sh | 15 +++ 1 file changed, 15 insertions(+) diff --git a/t/t6500-gc.sh b/t/t6500-gc.sh index 63194d8..b736774 100755 --- a/t/t6500-gc.sh +++ b/t/t6500-gc.sh @@ -30,4 +30,19 @@ test_expect_success 'gc -h with invalid configuration' ' test_i18ngrep "[Uu]sage" broken/usage ' +test_expect_failure 'gc removes broken refs/remotes//HEAD' ' + git init remote && + ( + cd remote && + test_commit initial && + git clone . ../client && + git branch -m develop && + cd ../client && + git fetch --prune && + git gc && + git branch --list -r origin/HEAD >actual && + test_line_count = 0 actual + ) +' + test_done -- 2.5.3.windows.1.3.gc322723 -- 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 v2 3/4] mark_reachable_objects(): optionally collect broken symrefs
The behavior of `mark_reachable_objects()` without this patch is that
it warns if it encounters a broken symref. Sometimes the caller wants
to act upon broken symrefs, e.g. when garbage collecting in a repository
with a broken remote HEAD.
So let's introduce an optional parameter to collect broken symrefs. The
behavior of the function is unchanged if that parameter is `NULL`.
Signed-off-by: Johannes Schindelin
---
builtin/prune.c | 2 +-
builtin/reflog.c | 2 +-
reachable.c | 25 +++--
reachable.h | 3 ++-
4 files changed, 23 insertions(+), 9 deletions(-)
diff --git a/builtin/prune.c b/builtin/prune.c
index 10b03d3..d6f664f 100644
--- a/builtin/prune.c
+++ b/builtin/prune.c
@@ -136,7 +136,7 @@ int cmd_prune(int argc, const char **argv, const char
*prefix)
if (show_progress)
progress = start_progress_delay(_("Checking connectivity"), 0,
0, 2);
- mark_reachable_objects(&revs, 1, expire, progress);
+ mark_reachable_objects(&revs, 1, expire, progress, NULL);
stop_progress(&progress);
for_each_loose_file_in_objdir(get_object_directory(), prune_object,
prune_cruft, prune_subdir, NULL);
diff --git a/builtin/reflog.c b/builtin/reflog.c
index f96ca2a..cb8758a 100644
--- a/builtin/reflog.c
+++ b/builtin/reflog.c
@@ -583,7 +583,7 @@ static int cmd_reflog_expire(int argc, const char **argv,
const char *prefix)
init_revisions(&cb.cmd.revs, prefix);
if (flags & EXPIRE_REFLOGS_VERBOSE)
printf("Marking reachable objects...");
- mark_reachable_objects(&cb.cmd.revs, 0, 0, NULL);
+ mark_reachable_objects(&cb.cmd.revs, 0, 0, NULL, NULL);
if (flags & EXPIRE_REFLOGS_VERBOSE)
putchar('\n');
}
diff --git a/reachable.c b/reachable.c
index 64289f3..25c4932 100644
--- a/reachable.c
+++ b/reachable.c
@@ -15,6 +15,11 @@ struct connectivity_progress {
unsigned long count;
};
+struct add_one_data {
+ struct rev_info *revs;
+ struct string_list *broken_symrefs;
+};
+
static void update_progress(struct connectivity_progress *cp)
{
cp->count++;
@@ -25,16 +30,19 @@ static void update_progress(struct connectivity_progress
*cp)
static int add_one_ref(const char *path, const struct object_id *oid,
int flag, void *cb_data)
{
- struct rev_info *revs = (struct rev_info *)cb_data;
+ struct add_one_data *data = (struct add_one_data *)cb_data;
struct object *object;
if ((flag & REF_ISSYMREF) && (flag & REF_ISBROKEN)) {
- warning("ref is broken: %s", path);
+ if (data->broken_symrefs)
+ string_list_append(data->broken_symrefs, path);
+ else
+ warning("ref is broken: %s", path);
return 0;
}
object = parse_object_or_die(oid->hash, path);
- add_pending_object(revs, object, "");
+ add_pending_object(data->revs, object, "");
return 0;
}
@@ -159,9 +167,11 @@ int add_unseen_recent_objects_to_traversal(struct rev_info
*revs,
void mark_reachable_objects(struct rev_info *revs, int mark_reflog,
unsigned long mark_recent,
- struct progress *progress)
+ struct progress *progress,
+ struct string_list *broken_symrefs)
{
struct connectivity_progress cp;
+ struct add_one_data data;
/*
* Set up revision parsing, and mark us as being interested
@@ -174,11 +184,14 @@ void mark_reachable_objects(struct rev_info *revs, int
mark_reflog,
/* Add all refs from the index file */
add_index_objects_to_pending(revs, 0);
+ data.revs = revs;
+ data.broken_symrefs = broken_symrefs;
+
/* Add all external refs */
- for_each_ref(add_one_ref, revs);
+ for_each_ref(add_one_ref, &data);
/* detached HEAD is not included in the list above */
- head_ref(add_one_ref, revs);
+ head_ref(add_one_ref, &data);
/* Add all reflog info */
if (mark_reflog)
diff --git a/reachable.h b/reachable.h
index d23efc3..06f1400 100644
--- a/reachable.h
+++ b/reachable.h
@@ -5,6 +5,7 @@ struct progress;
extern int add_unseen_recent_objects_to_traversal(struct rev_info *revs,
unsigned long timestamp);
extern void mark_reachable_objects(struct rev_info *revs, int mark_reflog,
- unsigned long mark_recent, struct progress
*);
+ unsigned long mark_recent, struct progress *,
+ struct string_list *broken_s
[PATCH v2 4/4] gc: remove broken symrefs
When encountering broken symrefs, such as a stale remote HEAD (which can
happen if the active branch was renamed in the remote), it is more
helpful to remove those symrefs than to exit with an error.
This fixes https://github.com/git-for-windows/git/issues/423
Signed-off-by: Johannes Schindelin
---
builtin/prune.c | 12 +++-
t/t6500-gc.sh | 2 +-
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/builtin/prune.c b/builtin/prune.c
index d6f664f..337b12a 100644
--- a/builtin/prune.c
+++ b/builtin/prune.c
@@ -6,6 +6,7 @@
#include "reachable.h"
#include "parse-options.h"
#include "progress.h"
+#include "refs.h"
static const char * const prune_usage[] = {
N_("git prune [-n] [-v] [--expire ] [--] [...]"),
@@ -100,6 +101,7 @@ static void remove_temporary_files(const char *path)
int cmd_prune(int argc, const char **argv, const char *prefix)
{
struct rev_info revs;
+ struct string_list broken_symrefs = STRING_LIST_INIT_DUP;
struct progress *progress = NULL;
const struct option options[] = {
OPT__DRY_RUN(&show_only, N_("do not remove, show only")),
@@ -110,6 +112,7 @@ int cmd_prune(int argc, const char **argv, const char
*prefix)
OPT_END()
};
char *s;
+ int i;
expire = ULONG_MAX;
save_commit_buffer = 0;
@@ -136,7 +139,14 @@ int cmd_prune(int argc, const char **argv, const char
*prefix)
if (show_progress)
progress = start_progress_delay(_("Checking connectivity"), 0,
0, 2);
- mark_reachable_objects(&revs, 1, expire, progress, NULL);
+ revs.ignore_missing = 1;
+ mark_reachable_objects(&revs, 1, expire, progress, &broken_symrefs);
+ for (i = 0; i < broken_symrefs.nr; i++) {
+ char *path = broken_symrefs.items[i].string;
+ printf("Removing stale ref %s\n", path);
+ if (!show_only && delete_ref(path, NULL, REF_NODEREF))
+ die("Could not remove stale ref %s", path);
+ }
stop_progress(&progress);
for_each_loose_file_in_objdir(get_object_directory(), prune_object,
prune_cruft, prune_subdir, NULL);
diff --git a/t/t6500-gc.sh b/t/t6500-gc.sh
index b736774..0ae4271 100755
--- a/t/t6500-gc.sh
+++ b/t/t6500-gc.sh
@@ -30,7 +30,7 @@ test_expect_success 'gc -h with invalid configuration' '
test_i18ngrep "[Uu]sage" broken/usage
'
-test_expect_failure 'gc removes broken refs/remotes//HEAD' '
+test_expect_success 'gc removes broken refs/remotes//HEAD' '
git init remote &&
(
cd remote &&
--
2.5.3.windows.1.3.gc322723
--
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 v2 0/4] Fix gc failure when a remote HEAD goes stale
There has been a report in the Git for Windows project that gc fails
sometimes: https://github.com/git-for-windows/git/issues/423
It turns out that there are cases when a remote HEAD can go stale and
it is not the user's fault at all. It can happen, for example, if the
active branch in the remote repository gets renamed.
Git's garbage collector should handle this gracefully. The best this
developer could come up with, is to simply warn and delete broken
symrefs.
Thanks to Junio and Peff for their really valuable sanity check.
Interdiff vs v1 below diffstat.
Johannes Schindelin (4):
gc: demonstrate failure with stale remote HEAD
pack-objects: do not get distracted by broken symrefs
mark_reachable_objects(): optionally collect broken symrefs
gc: remove broken refs
builtin/prune.c | 12 +++-
builtin/reflog.c | 2 +-
reachable.c | 31 +--
reachable.h | 3 ++-
t/t6500-gc.sh| 15 +++
5 files changed, 54 insertions(+), 9 deletions(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index ef2f794..1c63f8f 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -2499,7 +2499,6 @@ static void get_object_list(int ac, const char **av)
int flags = 0;
init_revisions(&revs, NULL);
- revs.ignore_missing = 1;
save_commit_buffer = 0;
setup_revisions(ac, av, &revs, NULL);
diff --git a/builtin/prune.c b/builtin/prune.c
index 1a30f65..337b12a 100644
--- a/builtin/prune.c
+++ b/builtin/prune.c
@@ -101,7 +101,7 @@ static void remove_temporary_files(const char *path)
int cmd_prune(int argc, const char **argv, const char *prefix)
{
struct rev_info revs;
- struct string_list broken_refs = STRING_LIST_INIT_DUP;
+ struct string_list broken_symrefs = STRING_LIST_INIT_DUP;
struct progress *progress = NULL;
const struct option options[] = {
OPT__DRY_RUN(&show_only, N_("do not remove, show only")),
@@ -140,9 +140,9 @@ int cmd_prune(int argc, const char **argv, const char
*prefix)
progress = start_progress_delay(_("Checking connectivity"), 0,
0, 2);
revs.ignore_missing = 1;
- mark_reachable_objects(&revs, 1, expire, progress, &broken_refs);
- for (i = 0; i < broken_refs.nr; i++) {
- char *path = broken_refs.items[i].string;
+ mark_reachable_objects(&revs, 1, expire, progress, &broken_symrefs);
+ for (i = 0; i < broken_symrefs.nr; i++) {
+ char *path = broken_symrefs.items[i].string;
printf("Removing stale ref %s\n", path);
if (!show_only && delete_ref(path, NULL, REF_NODEREF))
die("Could not remove stale ref %s", path);
diff --git a/reachable.c b/reachable.c
index 1fc7ada..25c4932 100644
--- a/reachable.c
+++ b/reachable.c
@@ -17,7 +17,7 @@ struct connectivity_progress {
struct add_one_data {
struct rev_info *revs;
- struct string_list *broken_refs;
+ struct string_list *broken_symrefs;
};
static void update_progress(struct connectivity_progress *cp)
@@ -31,13 +31,18 @@ static int add_one_ref(const char *path, const struct
object_id *oid,
int flag, void *cb_data)
{
struct add_one_data *data = (struct add_one_data *)cb_data;
- struct object *object = data->broken_refs ? parse_object(oid->hash) :
- parse_object_or_die(oid->hash, path);
+ struct object *object;
- if (!object)
- string_list_append(data->broken_refs, path);
- else
- add_pending_object(data->revs, object, "");
+ if ((flag & REF_ISSYMREF) && (flag & REF_ISBROKEN)) {
+ if (data->broken_symrefs)
+ string_list_append(data->broken_symrefs, path);
+ else
+ warning("ref is broken: %s", path);
+ return 0;
+ }
+
+ object = parse_object_or_die(oid->hash, path);
+ add_pending_object(data->revs, object, "");
return 0;
}
@@ -163,7 +168,7 @@ int add_unseen_recent_objects_to_traversal(struct rev_info
*revs,
void mark_reachable_objects(struct rev_info *revs, int mark_reflog,
unsigned long mark_recent,
struct progress *progress,
- struct string_list *broken_refs)
+ struct string_list *broken_symrefs)
{
struct connectivity_progress cp;
struct add_one_data data;
@@ -180,7 +185,7 @@ void mark_reachable_objects(struct rev_info *revs, int
mark_reflog,
add_index_objects_to_pending(revs, 0);
data.revs = revs;
- data.broken_refs = broken_refs;
+ data.broken_symrefs = broken_symrefs;
/* Add all extern
[PATCH] Fix "inside work tree" detection on case-insensitive filesystems
Git has a config variable to indicate that it is operating on a file
system that is case-insensitive: core.ignoreCase. But the
`dir_inside_of()` function did not respect that. As a result, if Git's
idea of the current working directory disagreed in its upper/lower case
with the `GIT_WORK_TREE` variable (e.g. `C:\test` vs `c:\test`) the
user would be greeted by the error message
fatal: git-am cannot be used without a working tree.
when trying to run a rebase.
This fixes https://github.com/git-for-windows/git/issues/402 (reported by
Daniel Harding).
Signed-off-by: Johannes Schindelin
---
dir.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/dir.c b/dir.c
index b90484a..fba938b 100644
--- a/dir.c
+++ b/dir.c
@@ -2107,6 +2107,15 @@ int file_exists(const char *f)
return lstat(f, &sb) == 0;
}
+static int cmp_icase(char a, char b)
+{
+ if (a == b)
+ return 0;
+ if (ignore_case)
+ return toupper(a) - toupper(b);
+ return a - b;
+}
+
/*
* Given two normalized paths (a trailing slash is ok), if subdir is
* outside dir, return -1. Otherwise return the offset in subdir that
@@ -2118,7 +2127,7 @@ int dir_inside_of(const char *subdir, const char *dir)
assert(dir && subdir && *dir && *subdir);
- while (*dir && *subdir && *dir == *subdir) {
+ while (*dir && *subdir && !cmp_icase(*dir, *subdir)) {
dir++;
subdir++;
offset++;
--
2.5.3.windows.1.3.gc322723
--
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] clone --dissociate: avoid locking pack files
When `git clone` is asked to dissociate the repository from the
reference repository whose objects were used, it is quite possible that
the pack files need to be repacked. In that case, the pack files need to
be deleted that were originally hard-links to the reference repository's
pack files.
On platforms where a file cannot be deleted if another process still
holds a handle on it, we therefore need to take pains to release all
pack files and indexes before dissociating.
This fixes https://github.com/git-for-windows/git/issues/446
Signed-off-by: Johannes Schindelin
---
builtin/clone.c| 9 -
t/t5700-clone-reference.sh | 21 +
2 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/builtin/clone.c b/builtin/clone.c
index 578da85..223adc4 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -1064,8 +1064,15 @@ int cmd_clone(int argc, const char **argv, const char
*prefix)
transport_unlock_pack(transport);
transport_disconnect(transport);
- if (option_dissociate)
+ if (option_dissociate) {
+ struct packed_git *p;
+
+ for (p = packed_git; p; p = p->next) {
+ close_pack_windows(p);
+ close_pack_index(p);
+ }
dissociate_from_references();
+ }
junk_mode = JUNK_LEAVE_REPO;
err = checkout();
diff --git a/t/t5700-clone-reference.sh b/t/t5700-clone-reference.sh
index ef1779f..2250ef4 100755
--- a/t/t5700-clone-reference.sh
+++ b/t/t5700-clone-reference.sh
@@ -188,5 +188,26 @@ test_expect_success 'clone and dissociate from reference' '
test_must_fail git -C R fsck &&
git -C S fsck
'
+test_expect_success 'clone, dissociate from partial reference and repack' '
+ rm -fr P Q R &&
+ git init P &&
+ (
+ cd P &&
+ test_commit one &&
+ git repack &&
+ test_commit two &&
+ git repack
+ ) &&
+ git clone --bare P Q &&
+ (
+ cd P &&
+ git checkout -b second &&
+ test_commit three &&
+ git repack
+ ) &&
+ git clone --bare --dissociate --reference=P Q R &&
+ ls R/objects/pack/*.pack >packs.txt &&
+ test_line_count = 1 packs.txt
+'
test_done
--
2.5.3.windows.1.3.gc322723
--
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 4/4] gc: remove broken symrefs
Hi Junio, On 2015-09-28 20:49, Junio C Hamano wrote: > Junio C Hamano writes: > >> Johannes Schindelin writes: >> >>> When encountering broken symrefs, such as a stale remote HEAD (which can >>> happen if the active branch was renamed in the remote), it is more >>> helpful to remove those symrefs than to exit with an error. >> >> I think this depends on the perspective. One side of me says that a >> remote HEAD that points at refs/remotes/origin/topic that no longer >> exists is still giving me a valuable information and it should take >> a conscious action by the user to remove it, or evne better to >> repoint it to a more useful place. And from that point of view, >> removing is not all that helpful. Keeping them and not allowing >> them to exit with an error would be a real improvement. >> >> On the other hand, I can certainly understand a view that considers >> that such a dangling symbolic ref is merely a cruft like any other >> cruft, and "gc" is all about removing cruft. >> >> It just feels to me that this is a bit more valuable than other >> kinds of cruft, but maybe it is just me. > > Sorry, it is a bad habit of me to send out without concluding > remark, leaving the recipient hanging without knowing what the next > step should be. > > I meant to say that I plan to, and I indeed did, queue these 4 > without changes. I am not opposed to the removal so strongly to > reject [4/4]. > > The above comment was that I just do not know if this is the right > thing to do, or it will be hurting users. Oh, I appreciate your feedback. I am actually not all *that* certain that removing the broken symref is the correct thing. It is this sort of fruitful exchange that allows me to throw out an idea and be relatively certain that something better will come out of v3 or v8 of the patch series than what I had in mind. To be honest, the most important outcome is probably 2/4 -- which should be enough to fix the issue reported by the Git for Windows user. I could adjust the test so that it no longer insists that `origin/HEAD` be deleted, but still requires that `git gc` succeeds. I would have no problem to let this sit for a couple of days until the final verdict. Ciao, Dscho -- 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 4/4] gc: remove broken symrefs
Hi Peff,
On 2015-09-28 21:03, Jeff King wrote:
> On Mon, Sep 28, 2015 at 04:02:08PM +0200, Johannes Schindelin wrote:
>
>> @@ -136,7 +139,14 @@ int cmd_prune(int argc, const char **argv, const char
>> *prefix)
>> if (show_progress)
>> progress = start_progress_delay(_("Checking connectivity"), 0,
>> 0, 2);
>>
>> -mark_reachable_objects(&revs, 1, expire, progress, NULL);
>> +revs.ignore_missing = 1;
>> +mark_reachable_objects(&revs, 1, expire, progress, &broken_symrefs);
>
> You should not need this ignore_missing anymore, right?
>
> It is the dangerous thing I mentioned earlier, but I am puzzled why it
> does not cause t5312 to fail.
Gaah! I edited this out at least twice, yet it creeps back in. Bah!
Junio, would you mind fixing this up locally? If you want me to submit v3, just
let me know, I will take care of it tomorrow.
Ciao,
Dscho
--
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] read-cache: fix file time comparisons with different precisions
Hi Karsten, On 2015-09-29 12:23, Karsten Blees wrote: > Am 28.09.2015 um 14:52 schrieb Johannes Schindelin: >> Otherwise there would be that little loop-hole where (nsec % 1000) == 0 *by >> chance* and we assume the timestamps to be identical even if they are not. > > Yeah, but in this case the file would be racy, as racy-checks use > the same comparison now. True. > IMO change detection is so fundamental that it should Just Work, > without having a plethora of config options that we need to explain > to end users. > > If that means that once in a million cases we need an extra content > check to revalidate such falsely racy entries, that's fine with me. You have a good point there. I retract my objections. Thanks, Dscho -- 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] git-send-email.perl: Fixed sending of many changes/patches
Hi Lars, On 2015-09-29 17:00, Lars Wendler wrote: > From: Stefan Agner > > See http://permalink.gmane.org/gmane.comp.version-control.git/274569 Please summarize the linked discussion in the commit message, as it is the convention here in the Git project to make commit messages self-sufficient, with links thrown in only to provide more context when desired. Ciao, Johannes -- 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 for Windows 2.6.0
Dear Git users,
it is my pleasure to announce that Git for Windows 2.6.0 is available (see
https://git-for-windows.github.io/ for details and download links).
Thank you, contributors!
Changes since Git for Windows 2.5.3 (September 18th 2015)
New Features
• Comes with Git 2.6.0
• The WhoUses.exe tool to determine which process holds a lock on a
given file (which was shipped with Git for Windows 1.x) gets
installed alongside Git for Windows again.
• The values CurrentVersion, InstallPath and LibexecPath are added to
the HKEY_LOCAL_MACHINE\Software\GitForWindows registry key to help
third-party add-ons to find us.
• When fetching or pushing with Git without a console, we now fall
back to Git GUI's askpass helper to ask for pass phrases.
• When run through \cmd\git.exe, Git will find tools in
$HOME/bin now.
Bug Fixes
• The portable version avoids DLL search path problems even when
installed into a FAT filesystem.
• Configuring notepad as editor without configuring a width for
commit messages no longer triggers an error message.
• When using Windows' default console for Git Bash, the .sh file
associations work again.
• Portable Git's README is now clearer about the need to run
post-install.bat when unpacking manually.
• We use the winpty trick now to run ipython interactively, too.
• When the environment variable HOME is not set, we now fall back
correctly to use HOMEDRIVE and HOMEPATH.
• The home directory is now set correctly when running as the SYSTEM
user.
• The environment variable GIT_WORK_TREE may now differ in lower/
upper case with the Git's idea of the current working directory.
• Running git clone --dissociate ... no longer locks the pack files
during the repacking phase.
• Upstream cURL fixes for NTLM proxy issues ("Unknown SSL error")
were backported.
Ciao,
Johannes
--
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] git-send-email.perl: Fixed sending of many/huge changes/patches
Hi Lars, On 2015-09-30 09:26, Lars Wendler wrote: > From: Stefan Agner > > Sometimes sending huge patches/commits fail with > > [Net::SMTP::SSL] Connection closed at /usr/lib/git-core/git-send-email > line 1320. > > Running the command with --smtp-debug=1 yields to > > Net::SMTP::SSL: Net::Cmd::datasend(): unexpected EOF on command channel: > at /usr/lib/git-core/git-send-email line 1320. > [Net::SMTP::SSL] Connection closed at /usr/lib/git-core/git-send-email > line 1320. > > Stefan described it in his mail like this: > > It seems to me that there is a size limit, after cutting down the patch > to ~16K, sending started to work. I cut it twice, once by removing lines > from the head and once from the bottom, in both cases at the size of > around 16K I could send the patch. > > See also original report: > http://permalink.gmane.org/gmane.comp.version-control.git/274569 > > Reported-by: Juston Li > Tested-by: Markos Chandras > Signed-off-by: Lars Wendler > --- Very nice! Thank you, Dscho -- 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] Provide a dirname() function when NO_LIBGEN_H=YesPlease
When there is no `libgen.h` to our disposal, we miss the `dirname()`
function.
So far, we only had one user of that function: credential-cache--daemon
(which was only compiled when Unix sockets are available, anyway). But
now we also have `builtin/am.c` as user, so we need it.
Since `dirname()` is a sibling of `basename()`, we simply put our very
own `gitdirname()` implementation next to `gitbasename()` and use it
if `NO_LIBGEN_H` has been set.
Signed-off-by: Johannes Schindelin
---
I stumbled over the compile warning when upgrading Git for Windows
to 2.6.0. There was a left-over NO_LIBGEN_H=YesPlease (which we
no longer need in Git for Windows 2.x), but it did point to the
fact that we use `dirname()` in builtin/am.c now, so we better
have a fall-back implementation for platforms without libgen.h.
I tested this implementation a bit, but I still would appreciate
a few eye-balls to go over it.
compat/basename.c | 26 ++
git-compat-util.h | 2 ++
2 files changed, 28 insertions(+)
diff --git a/compat/basename.c b/compat/basename.c
index d8f8a3c..10dba38 100644
--- a/compat/basename.c
+++ b/compat/basename.c
@@ -13,3 +13,29 @@ char *gitbasename (char *path)
}
return (char *)base;
}
+
+char *gitdirname(char *path)
+{
+ char *p = path, *slash, c;
+
+ /* Skip over the disk name in MSDOS pathnames. */
+ if (has_dos_drive_prefix(p))
+ p += 2;
+ /* POSIX.1-2001 says dirname("/") should return "/" */
+ slash = is_dir_sep(*p) ? ++p : NULL;
+ while ((c = *(p++)))
+ if (is_dir_sep(c)) {
+ char *tentative = p - 1;
+
+ /* POSIX.1-2001 says to ignore trailing slashes */
+ while (is_dir_sep(*p))
+ p++;
+ if (*p)
+ slash = tentative;
+ }
+
+ if (!slash)
+ return ".";
+ *slash = '\0';
+ return path;
+}
diff --git a/git-compat-util.h b/git-compat-util.h
index f649e81..8b01aa5 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -253,6 +253,8 @@ struct itimerval {
#else
#define basename gitbasename
extern char *gitbasename(char *);
+#define dirname gitdirname
+extern char *gitdirname(char *);
#endif
#ifndef NO_ICONV
--
2.5.3.windows.1.3.gc322723
--
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 1/2] sha1_file: close all pack files after running
Hi Max,
On 2015-10-01 05:29, Max Kirillov wrote:
> When a builtin has done its job, but waits for pager or not waited
> by its caller and still hanging it keeps pack files opened.
> This can cause a number of issues, for example on Windows git gc
> cannot remove the packs.
I did not experience that issue. In any case, closing the packs after the
builtin function has returned might not change anything anyway because we are
about to `exit()` and that's that.
So I would like to skip this:
> diff --git a/git.c b/git.c
> index 5feba41..ad34680 100644
> --- a/git.c
> +++ b/git.c
> @@ -348,6 +349,7 @@ static int run_builtin(struct cmd_struct *p, int
> argc, const char **argv)
> trace_argv_printf(argv, "trace: built-in: git");
>
> status = p->fn(argc, argv, prefix);
> + close_all_packs();
> if (status)
> return status;
>
Also, I would move the new declaration directly before `close_pack_windows()`:
> diff --git a/cache.h b/cache.h
> index 79066e5..153bc46 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -1279,6 +1279,7 @@ extern void unuse_pack(struct pack_window **);
> extern void free_pack_by_name(const char *);
> extern void clear_delta_base_cache(void);
> extern struct packed_git *add_packed_git(const char *, int, int);
> +extern void close_all_packs(void);
>
> /*
> * Return the SHA-1 of the nth object within the specified packfile.
The convention in Git seems to call things _gently rather than _nodie:
> diff --git a/sha1_file.c b/sha1_file.c
> index 08302f5..62f1dad 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -773,20 +773,28 @@ void *xmmap(void *start, size_t length,
> return ret;
> }
>
> -void close_pack_windows(struct packed_git *p)
> +static int close_pack_windows_nodie(struct packed_git *p)
> {
> while (p->windows) {
> struct pack_window *w = p->windows;
>
> if (w->inuse_cnt)
> - die("pack '%s' still has open windows to it",
> - p->pack_name);
> + return 1;
> +
> munmap(w->base, w->len);
> pack_mapped -= w->len;
> pack_open_windows--;
> p->windows = w->next;
> free(w);
> }
> +
> + return 0;
> +}
And while we're at it, why not teach that function a new parameter `int
close_pack_fd`?
There is another problem: when we cannot close the pack window, we cannot
really continue, can we? Because if we do, we *still* have the lock, and we'll
just fail later, most likely with an unhelpful error message because we do not
know where the pack closing failed. I do not think that the warning really
helps...
Ciao,
Dscho
--
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 2/2] sha1_file: set packfile to O_CLOEXEC at open
Hi Max, On 2015-10-01 05:29, Max Kirillov wrote: > Windows does not support setting O_CLOEXEC by fcntl, > but there is an open flag O_NOINHERIT which results in same > behaviour. Use it in git_open_noatime() and also bring > setting O_CLOEXEC there also to make it consistent. Rename > the function to git_open_noatime_cloexec(), to avoid confusion. Which problem does this solve? I am actually suspecting that this will rather cause problems because now `exec()`ing children might cause bogus file descriptors to be still held on. So I would recommend to drop this patch. It is not needed to fix the reported bug. Ciao, Dscho -- 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 1/2] sha1_file: close all pack files after running
Hi Max, On 2015-10-02 12:05, Johannes Schindelin wrote: > On 2015-10-01 05:29, Max Kirillov wrote: >> When a builtin has done its job, but waits for pager or not waited >> by its caller and still hanging it keeps pack files opened. >> This can cause a number of issues, for example on Windows git gc >> cannot remove the packs. Could you do me another favor? It seems that you want to work on this, so I will step back (I have to take off for the weekend very soon anyway, so I am really glad that you take care of it). But I would really love to see the line This fixes https://github.com/git-for-windows/git/issues/446 in the commit message, as this will keep the connection between the fix and the original report. Thanks, Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v1] Add Travis CI support
Hi Junio, On 2015-10-04 03:37, Junio C Hamano wrote: > Junio C Hamano writes: > >> On Sat, Oct 3, 2015 at 3:23 PM, Roberto Tyley >> wrote: >>> >>> Given this, enabling Travis CI for git/git seems pretty low risk, >>> are there any strong objections to it happening? >> >> I still don't see a reason why git/git needs to be the one that is >> used, when somebody >> so interested (and I seem to see very many of them in the thread) can >> sacrifice his or >> her own fork and enable it him or herself. > > To state it a bit differently. > > If somebody says "I've been maintaining a clone of git/git with > Travis webhooks enabled and as the result caught this many glitches > during the past two months without any ill side effect. Heh... given that Travis CI requires that .travis.yml file, nobody can really say that they have been using Travis CI *before* you add that file to `master`. If you make successful testing with Travis a *precondition* before adding that file, it is kinda asking for the impossible. Now, I like Travis, even if I have used Jenkins previously (came as part of my previous day-job). And my experience with Jenkins (in the form of BuildHive) was pretty positive: it *did* catch a couple of breakages. Even with my Git fork. But I agree with basically everybody who chimed in and said that the biggest bang for the buck would be made by enabling it on https://github.com/git/git. The only cost I see is for that `.travis.yml` file to live in Git's source code. Small price to pay, if you ask me. If you do not want to use it yourself, that is fine. But I would like to ask for it to be included so that those of us who do want to benefit from Travis' testing are not precluded from doing so [*1*]. As far as I can tell, the patch is fine as-is. Although I would put the `before_script` commands into some file inside `contrib/`. Thanks, Dscho Footnote *1*: of course it would be possible to manually rebase the patch, or to set up a scripted version of that. That is very cumbersome, though, and the benefit would obviously be substantially diminished. -- 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
