Re: [PATCH] checkout files in-place

+Cc: Orgad Shaneh On Mon, Jun 11, 2018 at 08:35:41PM +, Edward Thomson wrote: > On Sun, Jun 10, 2018 at 09:44:45PM +0200, Clemens Buchacher wrote: > > > > It is safe to do this on Linux file systems, even if open file handles > > still exist, because unlink only

[PATCH v2] checkout files in-place

is irrelevant. Signed-off-by: Clemens Buchacher Reviewed-by: Orgad Shaneh Reviewed-by: "brian m. carlson" Reviewed-by: Duy Nguyen Reviewed-by: Ævar Arnfjörð Bjarmason --- Tested on Windows with Git-for-Windows and with Windows Subsystem for Linux. Documentation/config.txt| 11 +

Re: [PATCH] checkout files in-place

On Mon, Jun 11, 2018 at 11:02:42AM -0700, Junio C Hamano wrote: > > Aside from us not having to worry about emulating the umask, another > reason why we prefer "create, complete the write, and then finally > rename" over "overwrite and let it fail in the middle" is that the > former makes sure we

Re: [PATCH] checkout files in-place

On Mon, Jun 11, 2018 at 02:04:11AM +, brian m. carlson wrote: > On Sun, Jun 10, 2018 at 09:44:45PM +0200, Clemens Buchacher wrote: > > + file prevent creating new files at the same path. Note that Git will not > > + update read/write permissions according to umask. >

[PATCH] checkout files in-place

is irrelevant. Signed-off-by: Clemens Buchacher --- I wonder if Git should be responsible for updating ownership and file permissions when modifying existing files during checkout. We could otherwise remove the unlink completely. Maybe this could even improve performance in some cases. It made

[PATCH] completion: improve ls-files filter performance

off-by: Clemens Buchacher <dri...@gmx.net> --- On Sun, Mar 18, 2018 at 02:26:18AM +0100, SZEDER Gábor wrote: > > You didn't run the test suite, did you? ;) My bad. I put the sort back in. Test t9902 is now pass. I did not run the other tests. I think the completion script is not used

[PATCH 1/2] completion: improve ls-files filter performance

sed by Git for Windows. Signed-off-by: Clemens Buchacher <dri...@gmx.net> --- contrib/completion/git-completion.bash | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index 6da95b8..e3ddf

[PATCH 2/2] completion: simplify ls-files filter

-by: Clemens Buchacher <dri...@gmx.net> --- contrib/completion/git-completion.bash | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index e3ddf27..394c3df 100644 --- a/contrib/completi

[PATCH] git-gui: workaround ttk:style theme use

Tk 8.5.7, which is the latest version on Centos 6, does not support getting the current theme with [ttk::style theme use]. Use the existing workaround for this in all places. Signed-off-by: Clemens Buchacher <dri...@gmx.net> --- git-gui/lib/themed.tcl | 15 ++- 1 file chang

Re: [PATCH] travis-ci: run previously failed tests first, then slowest to fastest

On Mon, Feb 01, 2016 at 10:17:24AM -0800, Junio C Hamano wrote: > > Your proposal is to redefine "is the working tree dirty?"; it would > check if "git checkout -f" would change what is in the working tree. I like this definition. Sounds obviously right. > > Regarding performance impact: We

Re: [PATCH] travis-ci: run previously failed tests first, then slowest to fastest

On Thu, Jan 28, 2016 at 01:32:30PM -0800, Junio C Hamano wrote: > Clemens Buchacher <dri...@aon.at> writes: > > > If we do this, then git diff should show the diff between > > convert_to_worktree(index state) and the worktree state. > > And that unfortuna

Re: [PATCH] optionally disable gitattributes

On Wed, Jan 27, 2016 at 04:04:39PM +0100, Torsten Bögershausen wrote: > > It feels like a workaround for something that could be fixable, or is already > ongoing. > Before going into more details, > could you tell us which attributes you are typically using (when having this > problems) ? > Is

Re: [PATCH] travis-ci: run previously failed tests first, then slowest to fastest

On Wed, Jan 27, 2016 at 12:49:31PM -0800, Junio C Hamano wrote: > Junio C Hamano writes: > > > I wonder what would break if we ask this question instead: > > > > We do not know if the working tree file and the indexed data > > match. Let's see if "git checkout" of

[PATCH] optionally disable gitattributes

GIT_ATTRIBUTES_DISABLED, which if set makes Git ignore any gitattributes. Signed-off-by: Clemens Buchacher <dri...@aon.at> --- Documentation/git.txt | 4 Documentation/gitattributes.txt | 6 ++ attr.c | 3 +++ t/t0003-attributes.sh

Re: [PATCH] travis-ci: run previously failed tests first, then slowest to fastest

I think Junio pointed me to this thread from "[PATCH] optionally disable gitattributes". Since I am not sure I am following everything correctly in this thread, allow me to recapitulate what I understood so far. Firstly, I think the racy'ness of t0025 is understood. It is due to the

Re: [PATCH] allow hooks to ignore their standard input stream

for the remaining hooks pre-push and post-rewrite, which read from standard input. The same arguments for ignoring SIGPIPE apply. Include test by Jeff King which checks that SIGPIPE does not cause pre-push hook failure. With the use of git update-ref --stdin it is fast enough to be enabled by defau

Re: [PATCH] allow hooks to ignore their standard input stream

ements which allow us to enable the test by default by Jeff King. Signed-off-by: Clemens Buchacher <clemens.buchac...@intel.com> --- builtin/commit.c | 3 +++ t/t5571-pre-push-hook.sh | 41 +++-- transport.c | 11 +-- 3 files chan

Re: [PATCH] allow hooks to ignore their standard input stream

On Wed, Nov 11, 2015 at 03:39:20PM +0100, Clemens Buchacher wrote: > + if (write_in_full(proc.in, buf.buf, buf.len) < 0) { > + /* We do not mind if a hook does not read all refs. */ > + if (errno != EPIPE) > +

[PATCH] allow hooks to ignore their standard input stream

-by: Clemens Buchacher <clemens.buchac...@intel.com> --- builtin/commit.c | 3 +++ transport.c | 11 +-- 2 files changed, 12 insertions(+), 2 deletions(-) diff --git a/builtin/commit.c b/builtin/commit.c index dca09e2..f2a8b78 100644 --- a/builtin/commit.c +++ b/builtin/commit.c @@ -32,6

Re: [PATCH] git_open_noatime: return with errno=0 on success

On Wed, Aug 05, 2015 at 10:59:09AM +0200, Linus Torvalds wrote: On Tue, Aug 4, 2015 at 11:03 PM, Junio C Hamano gits...@pobox.com wrote: I would agree it is a good idea to clear it after seeing the first open fail due to lack of O_NOATIME before trying open for the second time, iow, more

[PATCH] git_open_noatime: return with errno=0 on success

not exist, read_object returns NULL and read_sha1_file_extended dies with a fatal error: fatal: failed to read object sha1: Operation not permitted Fix this by resetting errno to zero before we call open again. Cc: Linus Torvalds torva...@linux-foundation.org Signed-off-by: Clemens Buchacher

[PATCH] git_open_noatime: return with errno=0 on success

not exist, read_object returns NULL and read_sha1_file_extended dies with a fatal error: fatal: failed to read object sha1: Operation not permitted Fix this by resetting errno to zero before we call open again. Cc: Linus Torvalds torva...@linux-foundation.org Signed-off-by: Clemens Buchacher

Re: [PATCH] rebase: return non-zero error code if format-patch fails

On Fri, Jul 03, 2015 at 10:52:32AM -0700, Junio C Hamano wrote: Cc: Andrew Wong andrew.k...@gmail.com Signed-off-by: Clemens Buchacher clemens.buchac...@intel.com Reviewed-by: Jorge Nunes jorge.nu...@intel.com Where was this review made? I may have missed a recent discussion

[PATCH] rebase: return non-zero error code if format-patch fails

...@gmail.com Signed-off-by: Clemens Buchacher clemens.buchac...@intel.com Reviewed-by: Jorge Nunes jorge.nu...@intel.com --- git-rebase--am.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git-rebase--am.sh b/git-rebase--am.sh index f923732..9ae898b 100644 --- a/git-rebase

[PATCH] filter-branch: handle deletion of annotated tags

echo hi -- --all I am not sure if we can afford to change behavior like that. Cc: Thomas Rast tr...@student.ethz.ch Cc: Johannes Schindelin johannes.schinde...@gmx.de Signed-off-by: Clemens Buchacher clemens.buchac...@intel.com Reviewed-by: Jorge Nunes jorge.nu...@intel.com --- git-filter

Re: [PATCH] filter-branch: handle deletion of annotated tags

echo hi -- --all I am not sure if we can afford to change behavior like that. Cc: Thomas Rast t...@thomasrast.ch Cc: Johannes Schindelin johannes.schinde...@gmx.de Signed-off-by: Clemens Buchacher clemens.buchac...@intel.com --- Re-send with Thomas' email address fixed. git-filter-branch.sh

Re: Missing capabilities in Documentation/technical/protocol-capbilities.txt

On Mon, Jul 15, 2013 at 07:25:19PM +0700, Duy Nguyen wrote: I noticed that quiet and agent capabilities were missing in protocol-capabilitities.txt. I have a rough idea what they do, but I think it's best to be documented by the authors. Maybe you have some time to make a patch? Hi Duy, I

Re: [PATCH] fix segfault with git log -c --follow

On Tue, May 28, 2013 at 10:22:17AM -0700, Junio C Hamano wrote: Clemens Buchacher dri...@aon.at writes: In diff_tree_combined we make a copy of diffopts. In try_to_follow_renames, called via diff_tree_sha1, we free and re-initialize diffopts-pathspec-items. Since we did not make a deep

[PATCH] fix segfault with git log -c --follow

with pathspec-items, but nobody seems to rely on that. Signed-off-by: Clemens Buchacher dri...@aon.at --- I wonder why I get a segfault from this so reliably, since it's not actually a null-pointer dereference. Maybe this is gcc 4.8 doing something different from previous versions? Also, I have