From: Edmundo Carmona Antoranz <eantoranz@gmail.com>
To: git@vger.kernel.org
Cc: Edmundo Carmona Antoranz <eantoranz@gmail.com>
Subject: [RFC PATCH] status: avoid reporting worktrees as "Untracked files"
Date: Sat, 4 Nov 2023 01:02:08 +0100 [thread overview]
Message-ID: <20231104000209.916189-1-eantoranz@gmail.com> (raw)
Given that worktrees are tracked in their own special fashion separately,
it makes sense to _not_ report them as "untracked". Also, when seeing the
directory of a worktree listed as Untracked, it might be tempting to try
to do operations (like 'git add') on them from the parent worktree which,
at the moment, will silently do nothing.
With this patch, we check items against the list of worktrees to add
them into the untracked items list effectively hiding them.
END OF PATCH
Here are a few questions more inline with the "RFC" part of the patch.
About UI
- Would it make more sense to separate them from Untracked files instead
of hiding them (perhaps add a --worktrees option to display them)?
- Follow-up if the previous answer is 'yes': List a worktree only if it
is not clean?
About code:
- If keeping the idea/patch, Would it make more sense (performance-wise) to
fist check an item in the list of worktrees before checking it in the
index? In other words, reverse the conditions to add an item to the
untracked list?
---
wt-status.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/wt-status.c b/wt-status.c
index 9f45bf6949..5fd1e6007a 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -775,6 +775,7 @@ static void wt_status_collect_untracked(struct wt_status *s)
struct dir_struct dir = DIR_INIT;
uint64_t t_begin = getnanotime();
struct index_state *istate = s->repo->index;
+ struct worktree **worktrees;
if (!s->show_untracked_files)
return;
@@ -795,9 +796,12 @@ static void wt_status_collect_untracked(struct wt_status *s)
fill_directory(&dir, istate, &s->pathspec);
+ worktrees = get_worktrees();
+
for (i = 0; i < dir.nr; i++) {
struct dir_entry *ent = dir.entries[i];
- if (index_name_is_other(istate, ent->name, ent->len))
+ if (index_name_is_other(istate, ent->name, ent->len) &&
+ !find_worktree_by_path(worktrees, ent->name))
string_list_insert(&s->untracked, ent->name);
}
@@ -809,6 +813,9 @@ static void wt_status_collect_untracked(struct wt_status *s)
dir_clear(&dir);
+ if (worktrees)
+ free_worktrees(worktrees);
+
if (advice_enabled(ADVICE_STATUS_U_OPTION))
s->untracked_in_ms = (getnanotime() - t_begin) / 1000000;
}
--
2.42.0
next reply other threads:[~2023-11-04 0:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-04 0:02 Edmundo Carmona Antoranz [this message]
2023-11-04 6:15 ` [RFC PATCH] status: avoid reporting worktrees as "Untracked files" Eric Sunshine
2023-11-04 6:58 ` Junio C Hamano
2023-11-11 9:22 ` Edmundo Carmona Antoranz
2023-11-12 17:13 ` Eric Sunshine
2023-11-12 23:52 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231104000209.916189-1-eantoranz@gmail.com \
--to=eantoranz@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.