On February 20, 2019 10:41:51 AM GMT+01:00, Duy Nguyen
wrote:
>Making "git checkout/merge" abort while it's working before breaks
>scripts.
Change is always a trade-off. We should not reject change without considering
the merits. Once we agree on the desired state, we can think about the
mi
On February 20, 2019 2:35:41 AM GMT+01:00, Duy Nguyen wrote:
>On Wed, Feb 20, 2019 at 1:08 AM Junio C Hamano
>wrote:
>>
>> Duy Nguyen writes:
>>
>> > On Sun, Feb 17, 2019 at 2:36 AM Ævar Arnfjörð Bjarmason
>> > wrote:
>> >>
>> >>
>> >> On Sat, Feb 16 2019, Nguyễn Thái Ngọc Duy wrote:
>> >>
>
+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
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 +
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
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.
>
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 no
off-by: Clemens Buchacher
---
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 there.
I a
by Git for
Windows.
Signed-off-by: Clemens Buchacher
---
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..e3ddf27 100644
--- a/cont
: Clemens Buchacher
---
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/completion/git-completion.bash
+++ b
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
---
git-gui/lib/themed.tcl | 15 ++-
1 file changed, 10 insertions(+), 5
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 only
On Thu, Jan 28, 2016 at 01:32:30PM -0800, Junio C Hamano wrote:
> Clemens Buchacher writes:
>
> > If we do this, then git diff should show the diff between
> > convert_to_worktree(index state) and the worktree state.
>
> And that unfortunately is a very good reason wh
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 that path would leave t
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 it
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
is_racy_timest
GIT_ATTRIBUTES_DISABLED, which if
set makes Git ignore any gitattributes.
Signed-off-by: Clemens Buchacher
---
Documentation/git.txt | 4
Documentation/gitattributes.txt | 6 ++
attr.c | 3 +++
t/t0003-attributes.sh | 43
ore SIGPIPE. Do the same 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 b
ements which allow us to enable the test by
default by Jeff King.
Signed-off-by: Clemens Buchacher
---
builtin/commit.c | 3 +++
t/t5571-pre-push-hook.sh | 41 +++--
transport.c | 11 +--
3 files changed, 35 insertions(+), 20 deleti
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)
> +
: Clemens Buchacher
---
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 +32,7 @@
#include "sequen
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 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 like this
exist, read_object returns NULL and read_sha1_file_extended dies
with a fatal error:
fatal: failed to read object : Operation not permitted
Fix this by resetting errno to zero before we call open again.
Cc: Linus Torvalds
Signed-off-by: Clemens Buchacher
---
This is a re-submission
exist, read_object returns NULL and read_sha1_file_extended dies
with a fatal error:
fatal: failed to read object : Operation not permitted
Fix this by resetting errno to zero before we call open again.
Cc: Linus Torvalds
Signed-off-by: Clemens Buchacher
Helped-by: Martin Schröder
On Fri, Jul 03, 2015 at 10:52:32AM -0700, Junio C Hamano wrote:
> >
> > Cc: Andrew Wong
> > Signed-off-by: Clemens Buchacher
> > Reviewed-by: Jorge Nunes
>
> Where was this review made? I may have missed a recent discussion,
> and that is why I am asking
git filter-branch --msg-filter="cat && echo hi" -- --all
I am not sure if we can afford to change behavior like that.
Cc: Thomas Rast
Cc: Johannes Schindelin
Signed-off-by: Clemens Buchacher
---
Re-send with Thomas' email address fixed.
git-filter-b
git filter-branch --msg-filter="cat && echo hi" -- --all
I am not sure if we can afford to change behavior like that.
Cc: Thomas Rast
Cc: Johannes Schindelin
Signed-off-by: Clemens Buchacher
Reviewed-by: Jorge Nunes
---
git-filter-branch.sh | 20 +-
-off-by: Clemens Buchacher
Reviewed-by: Jorge Nunes
---
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--am.sh
+++ b/git-rebase--am.sh
@@ -78,7 +78,7 @@ else
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 D
On Tue, May 28, 2013 at 10:22:17AM -0700, Junio C Hamano wrote:
> Clemens Buchacher 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
ec->raw to keep it consistent
with pathspec->items, but nobody seems to rely on that.
Signed-off-by: Clemens Buchacher
---
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 versi
31 matches
Mail list logo
