On Thu, Jan 31, 2019 at 12:53:24PM -0800, Nickolai Belakovski wrote:
> 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 -
On Thu, Jan 31, 2019 at 01:42:14PM -0800, Junio C Hamano wrote:
> > So I'd much rather see us parse the format into a real tree of nodes,
> > and figure out (once) which properties of each object are required to
> > fulfill that. Then for each object, we grab those properties, and then
> > walk th
Jeff King writes:
> On Thu, Jan 24, 2019 at 11:30:20AM -0800, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > What if you have other atoms that need worktrees? E.g., does
>> > %(worktreepath:foo) use the same used_atom slot? What if we have another
>> > worktree-related atom?
>> > ...
>> >
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 Thu, Jan 24, 2019 at 11:30:20AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > What if you have other atoms that need worktrees? E.g., does
> > %(worktreepath:foo) use the same used_atom slot? What if we have another
> > worktree-related atom?
> > ...
> > And that one is a good exampl
Jeff King writes:
> What if you have other atoms that need worktrees? E.g., does
> %(worktreepath:foo) use the same used_atom slot? What if we have another
> worktree-related atom?
> ...
> And that one is a good example where we _do_ need the global, because we
> already have multiple atoms pulli
On Thu, Jan 24, 2019 at 11:27:36AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > If anything, I'd suggest going in the opposite direction, and teaching
> > the worktree code a function for looking up a working tree by ref. And
> > then it can handle its own cache to implement that rever
Jeff King writes:
> If anything, I'd suggest going in the opposite direction, and teaching
> the worktree code a function for looking up a working tree by ref. And
> then it can handle its own cache to implement that reverse-mapping
> efficiently.
Yeah, that's a thought. Then "give me a worktre
On Thu, Jan 24, 2019 at 10:26:18AM -0800, Junio C Hamano wrote:
> Nickolai Belakovski writes:
>
> > Yes, the parser used the atom argument in an earlier version of this
> > patch, but we since moved the map out of the atom since it only needs
> > to exist once globally. Even though we have a cac
Nickolai Belakovski writes:
> Yes, the parser used the atom argument in an earlier version of this
> patch, but we since moved the map out of the atom since it only needs
> to exist once globally. Even though we have a caching mechanism for
> atoms it still seemed like a logical move to explicitl
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,
> > +
nbelakov...@gmail.com writes:
> From: Nickolai Belakovski
>
> 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.
> ---
Missing sign-off?
> +static int ref_to_worktree_map_cmpfnc(const
From: Nickolai Belakovski
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.
---
Documentation/git-for-each-ref.txt | 5 +++
ref-filter.c | 74 ++
13 matches
Mail list logo
