Re: [PATCH v2 2/2] branch: Mark and colorize a branch differently if it is checked out in a linked worktree

But I can see where personal preference starts to play a role here, as the logical solution isn't good enough. Which makes the case for being able to configure a bit stronger. Cheers, Rafael Ascensão

[PATCH 2/2] refs: fix some exclude patterns being ignored

is tied to, so refs.c:filter_refs() can decide if it should ignore the prefix when trying to match. Signed-off-by: Rafael Ascensão --- refs.c | 4 t/t6018-rev-list-glob.sh | 24 2 files changed, 16 insertions(+), 12 deletions(-) diff --git a/refs.c

[PATCH 1/2] refs: show --exclude failure with --branches/tags/remotes=glob

`, `--tags`, `--remotes` use the optional inclusive glob. Demonstrate this failure. Signed-off-by: Rafael Ascensão --- t/t6018-rev-list-glob.sh | 60 ++-- 1 file changed, 57 insertions(+), 3 deletions(-) diff --git a/t/t6018-rev-list-glob.sh b/t/t6018-rev-list

[PATCH 0/2] fix some exclude patterns being ignored

While trying to set up some aliases for my own use, I found out that --exclude with --branches behave differently depending if the latter uses globs. I tried to fix it making my 2nd contribution. :) Cheers, Rafael Ascensão (2): refs: show --exclude failure with --branches/tags/remotes=glob

Re: [PATCH] branch: make --show-current use already resolved HEAD

elper and do everything > inside cmd_branch(), so perhaps this can be made function local, no? > I was not sure if these 3 lines were global intentionally or if it was just an artifact from the past. Since it looks like the latter, I'll make them local. -- Rafael Ascensão

[PATCH] branch: make --show-current use already resolved HEAD

to the more reliable check for the detached head. Signed-off-by: Rafael Ascensão --- This patch is meant to be either applied or squashed on top of the current series. I am basing the claims of it being more reliable of what Junio suggested on a previous iteration of this series: https://public

Re: Lost changes after merge

ced, is that you're using %p with --graph. And --graph enables parent rewriting. Which may surprise you if you don't know what it does. But apart from that, and assuming you only did `git merge f087081868` everything looks normal between those two pastes. Cheers, Rafael Ascensão

Re: the opposite of .gitignore, whitelist

nes that were forcibly added. If needed, git ls-files can be used to list either category. Cheers, Rafael Ascensão

Re: [PATCH v4] branch: introduce --show-current display option

die(_("HEAD not found below refs/heads!")); What's being proposed can be achieved with + } else if (show_current) { + if (!filter.detached) + puts(head); + return 0; without failing tests. -- Cheers, Rafael Ascensão

Re: [PATCH v2 1/1] branch: introduce --show-current display option

as long as --list-head conforms with the default formatting for --list. -- Cheers Rafael Ascensão

Re: [PATCH v2 1/1] branch: introduce --show-current display option

detached at message.) Is there a strong reason to *not* "resolve" HEAD when it is attached? Would it be that bad to have some DWIM behaviour here? After all, as HEAD is an invalid name for a branch, nothing would ever match it anyways. Thanks for the input. :) -- Cheers Rafael Ascensão

Re: [PATCH v2 1/1] branch: introduce --show-current display option

Otherwise people will eventually start parsing it instead of using the recommended plumbing. -- Cheers Rafael Ascensão -- >8 -- diff --git a/builtin/branch.c b/builtin/branch.c index b67593288c..78a3de526c 100644 --- a/builtin/branch.c +++ b/builtin/branch.c @@ -684,6 +684,17 @@ int cmd_bra

Re: [PATCH 0/2] branch: introduce --current display option

l motivation behind this patch is to be able to determine the current branch without using the concept of 'HEAD', my suggestion falls short. Cheers, Rafael Ascensão

Re: [PATCH] branch: colorize branches checked out in a linked working tree the same way as the current branch is colorized

On Thu, Sep 27, 2018 at 03:35:59PM -0400, Jeff King wrote: > On Thu, Sep 27, 2018 at 08:28:04PM +0100, Rafael Ascensão wrote: > > But if we're open to change how branches are displayed maybe a config > > option like branch.format (probably not the best name choice) that

Re: [PATCH] branch: colorize branches checked out in a linked working tree the same way as the current branch is colorized

end using green and dim green for this case. Because all these worktrees are in a sense active. They're checked out in some place. It's just the case that the particular one that we are in is probably more relevant than the others. -- Cheers Rafael Ascensão

Re: [PATCH] branch: colorize branches checked out in a linked working tree the same way as the current branch is colorized

ld be a nice addition, but I am leaning towards giving the user the ultimate choice on how they want to format their output. (Maybe with dimmed plus symbol as default). -- Cheers, Rafael Ascensão

Re: Adding nested repository with slash adds files instead of gitlink

On Tue, Jun 19, 2018 at 11:28 AM Heiko Voigt wrote: > > Interesting and nobody complained to the mailinglist? > On Wed, Jun 20, 2018 at 3:57 PM Duy Nguyen wrote: > > Abusing a long standing bug does not make it a feature. > To make things clear, I wasn't defending if this should be considered

Re: Adding nested repository with slash adds files instead of gitlink

On Wed, Jun 20, 2018 at 5:39 AM Kevin Daudt wrote: > > What this is about that when doing `git add path/` (with trailing /), > This is what I was referring to. If you search for 'Fake Submodules', you'll see that some people were/are intentionally using this instead of subtrees or submodules.

Re: Adding nested repository with slash adds files instead of gitlink

On Tue, Jun 19, 2018 at 11:28 AM Heiko Voigt wrote: > > Interesting and nobody complained to the mailinglist? > For reference this was sometimes called "Fake Submodules" online.

Re: [RFC PATCH 1/2] docs: reflect supported fetch options of git pull

specifying them again and again. If the path is adding just couple of OPT_PASSTRHU, I could do it. But I'll wait and see if someone picks your parse-options suggestion. Thanks for the review. -- Rafael Ascensão

[RFC PATCH 1/2] docs: reflect supported fetch options of git pull

consistent with present behaviour by hiding unavailable options only. Reported-by: Marius Giurgi Signed-off-by: Rafael Ascensão --- Marius asked on freenode.#git if pull supported `--prune`, upon inspection seems like the man page was missing some of the supported options and listing others

[RFC PATCH 2/2] pull: allow -e as a synonym for --edit

`git pull`'s documentation mentions that `--edit` can be used with short option `-e`. But `git pull` doesn't understand `-e`. To make things consistent, teach `git pull` `-e` for `--edit` Signed-off-by: Rafael Ascensão --- builtin/pull.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion

Re: git update-ref fails to create reference. (bug)

00 && test $A = $(cat .git/PSEUDOREF) ' fails/succeeds appropriately in my limited testing. I am busy this weekend, but can try to write some if no one writes it until after the weekend. Cumprimentos, Rafael Ascensão

git update-ref fails to create reference. (bug)

values from read_ref(), 2015-07-15) Thanks, Rafael Ascensão

[PATCH v2] log: add option to choose which refs to decorate

nt commands. Helped-by: Kevin Daudt <m...@ikke.info> Helped-by: Junio C Hamano <gits...@pobox.com> Signed-off-by: Rafael Ascensão <rafa.al...@gmail.com> --- Notable changes since v1: * Do not change refs.c:for_each_glob_ref. Those changes were meant to address inconsist

Re: [PATCH v1 2/2] log: add option to choose which refs to decorate

On 07/11/17 00:18, Junio C Hamano wrote: > Jacob Keller writes: > > I would have to say that the describe's one is wrong if it does not > match what for_each_glob_ref() does for the log family of commands' > "--branches=" etc. describe.c::get_name() uses positive > and

Re: [PATCH v1 2/2] log: add option to choose which refs to decorate

Would checking the output of ref_exists() make sense here? By that I mean, only add a trailing '/*' if the ref doesn't exist. Unless I am missing something obvious this would allow us to keep both shortcuts and exact patterns.

Re: [PATCH v1 1/2] refs: extract function to normalize partial refs

On 06/11/17 01:23, Junio C Hamano wrote: > Michael Haggerty writes: > >> [1] I say "almost entirely" because putting them in one function means >> that only `pattern` needs to be scanned for glob characters. But that is >> an unimportant detail. > > That could actually be

Re: [PATCH v1 2/2] log: add option to choose which refs to decorate

On 04/11/17 03:49, Junio C Hamano wrote: Rafael Ascensão <rafa.al...@gmail.com> writes: Using `--exclude=` can help mitigate that verboseness by removing unnecessary 'branches' from the output. However, if the tip of an excluded ref points to an ancestor of a non-excluded re

Re: [PATCH v1 1/2] refs: extract function to normalize partial refs

On 04/11/17 02:27, Junio C Hamano wrote: Rafael Ascensão <rafa.al...@gmail.com> writes: Signed-off-by: Kevin Daudt <m...@ikke.info> Signed-off-by: Rafael Ascensão <rafa.al...@gmail.com> Could you explain Kevin's sign-off we see above? It is a bit unusual (I am not yet sayi

[PATCH v1 2/2] log: add option to choose which refs to decorate

-by: Kevin Daudt <m...@ikke.info> Signed-off-by: Rafael Ascensão <rafa.al...@gmail.com> --- Documentation/git-log.txt | 12 ++ builtin/log.c | 10 - log-tree.c| 37 ++--- log-tree.h| 6 ++- pretty.c

[PATCH v1 1/2] refs: extract function to normalize partial refs

where the same behaviour is needed, and add an ENSURE_GLOB flag to toggle if a trailing '/*' is to be appended to the result. Signed-off-by: Kevin Daudt <m...@ikke.info> Signed-off-by: Rafael Ascensão <rafa.al...@gmail.com> --- refs.c | 34 --

[PATCH v1 0/2] Add option to git log to choose which refs receive decoration

that those two are enough. --- Rafael Ascensão Rafael Ascensão (2): refs: extract function to normalize partial refs log: add option to choose which refs to decorate Documentation/git-log.txt | 12 ++ builtin/log.c | 10 - log-tree.c| 37