Re: [PATCH v3 1/3] ref-filter: add worktreepath atom
From: Nickolai Belakovski <hidden>
Date: 2018-12-20 07:10:29
On Tue, Dec 18, 2018 at 9:22 AM Jeff King [off-list ref] wrote:
On Sun, Dec 16, 2018 at 01:57:57PM -0800, nbelakovski@gmail.com wrote:quoted
From: Nickolai Belakovski <redacted> Add an atom proving 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.I stumbled over the word "proving" here. Maybe "showing" would be more clear?
Oops, providing
quoted
+worktreepath:: + The absolute path to the worktree in which the ref is checked + out, if it is checked out in any linked worktree. ' ' otherwise. +Also, why are we replacing it with a single space? Wouldn't the empty string be more customary (and work with the other "if empty, then do this" formatting options)?
I was just following what was done for HEAD, but overall I agree that empty is preferable to single space, will change.
Minor style nit: we put the "*" in a pointer declaration next to the variable name, without intervening whitespace. Like: static struct worktree **worktrees;
Gotcha, will do, thanks for pointing it out. To sum up the hashmap comments: -I hadn't thought to re-use the head_ref of worktree as the key. That's clever. I like the readability of having separate entries for key and value, but I can see the benefit of not having to do an extra allocation. I can make up for the readability hit with a comment. -Actually, for any valid use case there will only be one instance of the map since the entries of used_atom are cached, but regardless it makes sense to keep per-atom info in used_atom and global context somewhere else, so I'll make that change to make it a static variable outside of used_atom. -Will change the lookup logic to remove the extra allocation. Since I'm letting the hashmap use its internal comparison function on the hash, I don't need to provide a comparison function.
What's this extra strncmp about? If we're _not_ a worktreepath atom, we'd still do the lookup only to put nothing in the string?
Leftover from an earlier iteration where I was going to support getting more info out of the worktree struct. I decided to limit scope to just the info I really needed for the branch change. I left it like this because I thought it would make the code more readable for someone who wanted to come in and add that extra info, but I think you're right that it ends up just reading kind of awkwardly.
quoted
@@ -2013,7 +2076,14 @@ void ref_array_clear(struct ref_array *array) int i; for (i = 0; i < used_atom_cnt; i++) + { + if (!strncmp(used_atom[i].name, "worktreepath", strlen("worktreepath"))) + { + hashmap_free(&(used_atom[i].u.reftoworktreeinfo_map), 1); + free_worktrees(worktrees); + }And if we move the mapping out to a static global, then this only has to be done once, not once per atom. In fact, I think this could double-free "worktrees" with your current patch if you have two "%(worktree)" placeholders, since "worktrees" already is a global.
Only if someone put a colon on one of the %(worktree) atoms, otherwise they're all cached, but as you say moot point anyway if the map is moved outside the used_atom structure.
It's probably worth testing that the path we get is actually sane, too.
I.e., expect something more like:
cat >expect <<-\EOF
master: $PWD
master: $PWD/worktree
side: not checked out
EOF
git for-each-ref \
--format="%(refname:short): %(if)%(worktreepath)%(then)%(worktreepath)%(else)not checked %out%(end)
(I wish there was a way to avoid that really long line, but I don't
think there is).Yea good call, can do. Thanks for all the feedback, will try to turn these around quickly.