On Thu, May 30, 2019 at 5:20 PM Junio C Hamano wrote:
>
> * nb/branch-show-other-worktrees-head (2019-05-07) 3 commits
> - branch: add worktree info on verbose output
> - branch: update output to include worktree info
> - ref-filter: add worktreepath atom
>
> "git branch --list" learned to sho
mail body is sent?
>
> Ciao,
> Johannes
>
>
> On Sun, 28 Apr 2019, nbelakov...@gmail.com wrote:
>
> > From: Nickolai Belakovski
> >
> > Added test_i18ncmp per instructions from Szeder
> >
> > Is there some other part of the infrastructure that
> Testing with GETTEXT_POISON was broken since 6cdccfce (i18n: make
> GETTEXT_POISON a runtime option, 2018-11-08), and didn't catch any of
> these issues. See:
>
>
> https://public-inbox.org/git/xmqqlg0bvppc.fsf...@gitster-ct.c.googlers.com/T/#u
>
> The fix f88b9cb603 (gettext tests: export th
>
> Patch 1 looks good to me. Given that we're on v8 and most of the other
> comments are for patches 2 and 3, I think we might consider graduating
> it separately if the other two are not ready soon. It's independently
> useful, IMHO.
Patch 2 was my main motivation, so it would be nice to get it
On Thu, Feb 21, 2019 at 4:59 AM Jeff King wrote:
>
> On Tue, Feb 19, 2019 at 05:31:23PM +0900, nbelakov...@gmail.com wrote:
>
> > From: Nickolai Belakovski
> >
> > To display worktree path for refs checked out in a linked worktree
>
> This would be a good pla
On Thu, Feb 21, 2019 at 4:44 AM Jeff King wrote:
>
> On Tue, Feb 19, 2019 at 05:31:22PM +0900, nbelakov...@gmail.com wrote:
>
> > From: Nickolai Belakovski
> >
> > The output of git branch is modified to mark branches checkout out in a
>
> s/checkout
Well, it sounded like we didn't like the ":" extender from another
conversation on this thread. Do you think this patch should move back
in that direction?
On Tue, Feb 5, 2019 at 3:14 AM Junio C Hamano wrote:
>
> Nickolai Belakovski writes:
>
> > There's been
On Fri, Feb 1, 2019 at 2:54 PM Junio C Hamano wrote:
>
>
> As you can see in "git shortlog --no-merges", later two patches
> would look quite out of place by having overlong title and starting
> the description(i.e. after ": ") in a capital letter.
Hadn't looked at it that way. OK, will shorten/u
On Fri, Feb 1, 2019 at 2:54 PM Junio C Hamano wrote:
>
>
> I had to apply and then use --color-words to see what is going on.
> Please avoid unnecessary reflowing of the text that makes the patch
> harder than necessary to read.
I was trying to keep the line length consistent. How else can I acco
On Fri, Feb 1, 2019 at 2:54 PM Junio C Hamano wrote:
>
> If the rule were "a branch that is checked out in one of the
> worktrees connected to the repository is shown with the path to that
> worktree" (i.e. no exception), I would understand it. If the rule
> were "a branch that is ... (the same
; branch: display worktree path in -v -v mode
>
> or something, and use the longer description as the rest of the body
> of the commit message.
OK
>
> > Signed-off-by: Nickolai Belakovski
> > ---
> > diff --git a/Documentation/git-branch.txt b/Documentation
On Fri, Feb 1, 2019 at 2:20 PM Eric Sunshine wrote:
>
> On Fri, Feb 1, 2019 at 5:04 PM wrote:
> > Add an atom providing the path of the linked worktree where this ref is
> > checked out, if it is checked out in any linked worktrees, and empty
> > string otherwise.
> &g
So where does that leave us for this series? We could move hashmap
back into used_atom, but if a user entered
--format="%(worktreepath)%(worktreepath:)" we'd end up freeing
worktrees twice. Not that that should stop us - that scenario is one
where user input isn't sensible and personally I don't th
On Wed, Jan 23, 2019 at 10:57 AM Junio C Hamano wrote:
>
> Missing sign-off?
>
My mistake, forgot -s on format-patch. Will remember to add it next go-around.
> > +static int ref_to_worktree_map_cmpfnc(const void *unused_lookupdata, const
> > void *existing_hashmap_entry_to_test,
> > +
On Fri, Jan 18, 2019 at 2:17 PM Nickolai Belakovski
wrote:
>
>
> I think avoiding this would be check, we can simply check ref->kind ==
> FILTER_REFS_BRANCHES ahead of calling into get_worktree_path and
> provide an empty string otherwise.
>
*would be check -> would be cheap
I will start a separate thread containing these replies for the
potential change to allow deleting branches checked out in worktrees.
Getting back on track for this series, specifically this 2/3 patch,
how do you feel about it? As I pointed out the goal is to communicate
to the user that the branc
On Mon, Jan 7, 2019 at 10:20 AM Junio C Hamano wrote:
> When seeing a tag or note ref, by definition that's not something we
> can have checked out in any worktree. I wonder if it is worth to
> optimize further by omitting this lookup when ref is not a local
> branch?
>
> IOW, with a typical numb
On Thu, Jan 10, 2019 at 1:43 PM Philip Oakley wrote:
>
> On 07/01/2019 19:04, Junio C Hamano wrote:
> > I do not think it is warranted to paint the safety features as
> > "limitations".
>
> Is this not just a case of needing to clarify that this is 'safety'
> related to the _users_ mental model (o
On Tue, Dec 18, 2018 at 9:22 AM Jeff King wrote:
>
> On Sun, Dec 16, 2018 at 01:57:57PM -0800, nbelakov...@gmail.com wrote:
>
> > From: Nickolai Belakovski
> >
> > Add an atom proving the path of the linked worktree where this ref is
> > checked out, if it is ch
OK, I see 3 votes for cyan and 4-5 people participating in the thread,
so I'll make it cyan in the next revision.
On Tue, Nov 13, 2018 at 3:49 PM Jeff King wrote:
>
> On Mon, Nov 12, 2018 at 06:07:18PM +, Rafael Ascensão wrote:
>
> > On Mon, Nov 12, 2018 at 07:14:23AM -0500, Jeff King wrote:
>
I think if we move to making this atom just store worktree path, that
needs to be implemented as a hashmap of refname->wtpath, which would
also solve this string_list issue, correct? Just making sure I'm not
missing something before I submit another patch.
On Tue, Nov 13, 2018 at 2:38 AM Junio C Ha
On Sun, Oct 28, 2018 at 9:01 PM Eric Sunshine wrote:
>
> On Sun, Oct 28, 2018 at 9:11 PM Nickolai Belakovski
> wrote:
> > I would also suggest renaming is_worktree_locked to
> > worktree_lock_reason, the former makes me think the function is
> > returning a boole
On Sun, Oct 28, 2018 at 8:52 PM Junio C Hamano wrote:
>
>
> If the field "reason" should always be populated, there is *no*
> reason why we need the "valid" boolean. They work as a pair to
> realize lazy population of rarely used field. The lazy evaluation
> technique is used as an optimization
On Sun, Oct 28, 2018 at 4:03 PM Eric Sunshine wrote:
>
> On Sun, Oct 28, 2018 at 5:55 PM Nickolai Belakovski
> > wrote: This was meant to be a reply to
> > https://public-inbox.org/git/cac05386f1x7tspr6kgkulwewsmdiq4vktf5rxahvzpkwbmx...@mail.gmail.com/T/#m8898c8f7c68e1ea234aca2
eason_valid. There are currently no consumers of
lock_reason_valid within master, but obviously we should fix this
before they appear :)
Thoughts?
On Wed, Oct 24, 2018 at 11:56 PM Junio C Hamano wrote:
>
> nbelakov...@gmail.com writes:
>
> > From: Nickolai Belakovski
> >
>
The motivation for the change is some work that I'm doing to add a
worktree atom in ref-filter.c. I wanted that atom to be able to access
all fields of the worktree struct and noticed that lock_reason wasn't
getting populated so I figured I'd go and fix that.
I figured that since get_worktrees is
Not to hijack my own thread, but FWIW git branch -r shows remote
branches in red, but old/new status of a remote branch is ambiguous
(could have new stuff, could be out of date). Also, git branch -vv
shows remote tracking branches in blue. One could argue it should be
red since git branch -r is in
a glance
which branch is checked out in the current worktree vs others.
On Thu, Sep 27, 2018 at 11:17 AM Jeff King wrote:
>
> On Thu, Sep 27, 2018 at 08:13:13AM -0700, Nickolai Belakovski wrote:
>
> > In order to more clearly display which branches are active, the output
> > o
r Arnfjörð Bjarmason
wrote:
>
>
> On Thu, Sep 27 2018, Nickolai Belakovski wrote:
>
> > In order to more clearly display which branches are active, the output
> > of git branch is modified to colorize branches checked out in any linked
> > worktrees with the same col
worktree.
The git worktree list command contains the relevant information, however
this is a much less frquently used command than git branch.
Signed-off-by: Nickolai Belakovski
---
Notes:
Travis CI results: https://travis-ci.org/nbelakovski/git/builds/432320949
builtin/branch.c | 35
30 matches
Mail list logo
