Re: [PATCH v6] log: fix coloring of certain octupus merge shapes

ch case the number of parents will be one greater than the * number of added columns. */ int added_cols = (graph->num_new_columns - graph->num_columns); int parent_in_old_cols = graph->num_parents - added_cols; From a9c90605c062b30273dad35adbf319905028cacc Mon Sep 17 00:00:

Re: [BUG] A part of an edge from an octopus merge gets colored, even with --color=never

> This whole version looks good to me. "git am" is supposed to understand > attachments, but it seems to want to apply our whole conversation as the > commit message. > > You may want to repost one more time with this subject in the email > subject line to fix that and to get the maintainer's

[PATCH v6] log: fix coloring of certain octupus merge shapes

an initial patch suggestion by Jeff King. Signed-off-by: Noam Postavsky Reviewed-by: Jeff King --- graph.c | 56 +--- t/t4214-log-graph-octopus.sh | 102 +++ 2 files changed, 143 insertions(+), 15 deletions(-) create

Re: [BUG] A part of an edge from an octopus merge gets colored, even with --color=never

the problematic graph here? I think if we just omit > "left" we get that, don't we? t4202-log.sh already does test a "normal" octopus merge (starting around line 615, search for "octopus-a"). But that is only a 3-parent merge. And adding another test is easy en

Re: [BUG] A part of an edge from an octopus merge gets colored, even with --color=never

On Mon, 24 Sep 2018 at 20:27, Noam Postavsky wrote: > > On Sat, 8 Sep 2018 at 12:13, Jeff King wrote: > > > Great (and sorry for the delayed response). > > No problem, I know it's not the most urgent bug ever :) Ping. :) > I managed to recast my script into the framew

Re: [BUG] A part of an edge from an octopus merge gets colored, even with --color=never

to t4202-log.sh, but it's not clear to me how I can do this without breaking all the other tests which expect a certain sequence of commits. t4299-octopus.sh Description: Bourne shell script From ade526d32f692cae06000bb413ff29dad3f6109e Mon Sep 17 00:00:00 2001 From: Noam Postavsky Date: Sat, 1 Sep 20

Re: [BUG] A part of an edge from an octopus merge gets colored, even with --color=never

e" in the comment is not accurate in that latter > case, and it should be two). Yes, thanks, it makes a lot more sense this way. I believe the attached handles both parent types correctly. From a841a50b016c0cfc9183384e6c3ca85a23d1e11f Mon Sep 17 00:00:00 2001 From: Noam Postavsky Date:

Re: [BUG] A part of an edge from an octopus merge gets colored, even with --color=never

On 30 June 2018 at 08:47, Noam Postavsky wrote: > I'm still having trouble getting a big picture understanding of how > the graph struct relates the what gets drawn on screen, but through > some poking around with the debugger + trial & error, I've arrived at > a new patch whi

Re: [BUG] A part of an edge from an octopus merge gets colored, even with --color=never

hed an updated test-multiway-merge.sh which allows adding more branches to test different sized merges more easily. From ad40c5986264af1f5934b05082e16a3ce314caab Mon Sep 17 00:00:00 2001 From: Noam Postavsky Date: Sat, 23 Jun 2018 16:56:43 -0400 Subject: [PATCH v2] log: Fix coloring of certain octupus

Re: [BUG] A part of an edge from an octopus merge gets colored, even with --color=never

Archive link to previous discussion: https://marc.info/?l=git=146331754420554=2 On 20 May 2016 at 18:12, Noam Postavsky wrote: > Looking at the coloured output, for some octopus merges where the > first parent edge immediately merges into the next column to the left, > col_n

Re: [GSoC] Move ~/.git-credential-cache to ~/.cache/git

On Fri, Mar 10, 2017 at 7:26 PM, Jonathan Nieder wrote: > I find that magit does rely on the socket path. > > Start credential daemon on magit-credential-hook > > If we let git start the daemon, Emacs will send a SIGHUP when git > finishes and closes the pty,

Re: [BUG] A part of an edge from an octopus merge gets colored, even with --color=never

On Tue, May 17, 2016 at 3:55 PM, Jeff King wrote: >> (It's actually the first one which triggers). I'm not familiar enough >> with the code to know whether the col_num computation is bogus, or >> whether we needed to earlier increase the size of the "new_columns" >> field. > > And

[BUG] A part of an edge from an octopus merge gets colored, even with --color=never

With a certain topology involving an octopus merge, git log --graph --oneline --all --color=never produces output which includes some ANSI escape code coloring. Attached is a script to reproduce the problem (creates a git repository in subdir log-format-test), along with sample graph and valgrind

Re: git-credential-cache--daemon quits on SIGHUP, can we change it to ignore instead?

I think you're right about the automated test not being worth the trouble. On Tue, Nov 10, 2015 at 7:26 AM, Jeff King wrote: > To clarify: just telling me it's OK to add your sign-off is fine here. I > can add it (and fix up the style thing) as I apply. Ok, please do that then,

Re: git-credential-cache--daemon quits on SIGHUP, can we change it to ignore instead?

git_config_get_bool() will > normalize the key we feed it, but I'd rather stay consistent. Oh, I didn't even realize git config names were case insensitive. > I don't think you need to pop the tempfile handler here. You can simply > sigchain_push() the SIG_IGN, and since we won't ever p

Re: git-credential-cache--daemon quits on SIGHUP, can we change it to ignore instead?

On Fri, Oct 30, 2015 at 5:08 PM, Jeff King wrote: > Right. And not only is that hard to get right (I doubt, for example, you > support the arbitrary "!" shell expressions that git does), but it's > impossible to know for sure that will be needed, because you cannot know > all

Re: git-credential-cache--daemon quits on SIGHUP, can we change it to ignore instead?

On Thu, Oct 29, 2015 at 8:10 PM, Jeff King <p...@peff.net> wrote: > On Tue, Oct 27, 2015 at 11:46:20PM -0400, Noam Postavsky wrote: >> Perhaps we could express the auto-spawn more explicitly, something >> like "git config credential.pre-helper start-cache-daemon". A

Re: git-credential-cache--daemon quits on SIGHUP, can we change it to ignore instead?

On Thu, Oct 29, 2015 at 8:50 PM, Jeff King wrote: > workaround (the real inelegance is that you are assuming that "foo" > needs run in the first place). Well, we currently check the output from "git config credential.helpers" to determine what's needed, so the inelegance here is

Re: git-credential-cache--daemon quits on SIGHUP, can we change it to ignore instead?

On Tue, Oct 27, 2015 at 2:47 PM, Jeff King wrote: > On Tue, Oct 27, 2015 at 10:52:52AM -0700, Junio C Hamano wrote: >> Yes. Probably the right way forward is to make it a non-issue by >> teaching users how to control the lifetime of the "daemon" process, >> and wean them off

Re: git-credential-cache--daemon quits on SIGHUP, can we change it to ignore instead?

On Mon, Oct 26, 2015 at 5:50 PM, Jeff King wrote: > But these days, people often have several simultaneous sessions open. > They may have multiple ssh sessions to a single machine, or they may > have a bunch of terminal windows open, each of which has a login shell > and will send HUP to its

Re: git --literal-pathspecs add -u says "fatal: pathspec ':/' did not match any files"

On Sat, Oct 24, 2015 at 3:13 AM, Victor Leschuk wrote: > The problem is that in the absence of explicit argument we set the list of > files to special path ":/" which means repo root: > And after that we treat it as regular file Aha. > Maybe it'll make sense to modify

Re: git-credential-cache--daemon quits on SIGHUP, can we change it to ignore instead?

On Tue, Oct 20, 2015 at 10:35 PM, Noam Postavsky <npost...@users.sourceforge.net> wrote: > On Sun, Oct 18, 2015 at 1:58 PM, Junio C Hamano <gits...@pobox.com> wrote: >> I cannot speak for the person who was primarily responsible for >> designing this behav

git --literal-pathspecs add -u says "fatal: pathspec ':/' did not match any files"

~/tmp/tmprepo$ git init Initialized empty Git repository in /home/npostavs/tmp/tmprepo/.git/ ~/tmp/tmprepo$ git --literal-pathspecs add -u fatal: pathspec ':/' did not match any files ~/tmp/tmprepo$ git --version git version 2.6.1 It was reported[1] that 2.0.2 and several following versions also

Re: git-credential-cache--daemon quits on SIGHUP, can we change it to ignore instead?

On Sun, Oct 18, 2015 at 1:58 PM, Junio C Hamano wrote: > I cannot speak for the person who was primarily responsible for > designing this behaviour, but I happen to agree with the current > behaviour in the situation where it was designed to be used. Upon > the first use in

Re: git-credential-cache--daemon quits on SIGHUP, can we change it to ignore instead?

On Sun, Oct 18, 2015 at 1:58 PM, Junio C Hamano wrote: > I cannot speak for the person who was primarily responsible for > designing this behaviour, but I happen to agree with the current > behaviour in the situation where it was designed to be used. Upon > the first use in

Re: git-credential-cache--daemon quits on SIGHUP, can we change it to ignore instead?

On Sat, Oct 10, 2015 at 12:45 PM, Noam Postavsky <npost...@users.sourceforge.net> wrote: > I noticed that git-credential-cache--daemon quits on SIGHUP. This > seems like surprising behaviour for a daemon. Would it be acceptable > to change it to ignore SIGHUP? ping? -- To u

git-credential-cache--daemon quits on SIGHUP, can we change it to ignore instead?

I noticed that git-credential-cache--daemon quits on SIGHUP. This seems like surprising behaviour for a daemon. Would it be acceptable to change it to ignore SIGHUP? (This came up while investigating a Magit bug[1], we are also considering ways to avoid sending a SIGHUP in the first place) [1]:

[BUG] git diff --(src|dst)-prefix=// causes spurious (new|deleted) file mode

% git init Initialized empty Git repository in /home/npostavs/tmp/scratch/.git/ % echo foo x % git add x % git commit -m x [master (root-commit) 41be1f2] x 1 file changed, 1 insertion(+) create mode 100644 x % echo bar x % git diff | head -3 diff --git i/x w/x index 257cc56..5716ca5 100644