git/wt-status.h

189 lines
4.9 KiB
C
Raw Normal View History

#ifndef STATUS_H
#define STATUS_H
#include "string-list.h"
#include "color.h"
#include "pathspec.h"
#include "remote.h"
struct repository;
struct worktree;
enum color_wt_status {
WT_STATUS_HEADER = 0,
WT_STATUS_UPDATED,
WT_STATUS_CHANGED,
WT_STATUS_UNTRACKED,
WT_STATUS_NOBRANCH,
WT_STATUS_UNMERGED,
WT_STATUS_LOCAL_BRANCH,
WT_STATUS_REMOTE_BRANCH,
WT_STATUS_ONBRANCH,
WT_STATUS_MAXSLOT
};
enum untracked_status_type {
SHOW_UNTRACKED_FILES_ERROR = -1,
SHOW_NO_UNTRACKED_FILES = 0,
SHOW_NORMAL_UNTRACKED_FILES,
SHOW_ALL_UNTRACKED_FILES
};
status: add option to show ignored files differently Teach the status command more flexibility in how ignored files are reported. Currently, the reporting of ignored files and untracked files are linked. You cannot control how ignored files are reported independently of how untracked files are reported (i.e. `all` vs `normal`). This makes it impossible to show untracked files with the `all` option, but show ignored files with the `normal` option. This work 1) adds the ability to control the reporting of ignored files independently of untracked files and 2) introduces the concept of status reporting ignored paths that explicitly match an ignored pattern. There are 2 benefits to these changes: 1) if a consumer needs all untracked files but not all ignored files, there is a performance benefit to not scanning all contents of an ignored directory and 2) returning ignored files that explicitly match a path allow a consumer to make more informed decisions about when a status result might be stale. This commit implements --ignored=matching with --untracked-files=all. The following commit will implement --ignored=matching with --untracked=files=normal. As an example of where this flexibility could be useful is that our application (Visual Studio) runs the status command and presents the output. It shows all untracked files individually (e.g. using the '--untracked-files==all' option), and would like to know about which paths are ignored. It uses information about ignored paths to make decisions about when the status result might have changed. Additionally, many projects place build output into directories inside a repository's working directory (e.g. in "bin/" and "obj/" directories). Normal usage is to explicitly ignore these 2 directory names in the .gitignore file (rather than or in addition to the *.obj pattern).If an application could know that these directories are explicitly ignored, it could infer that all contents are ignored as well and make better informed decisions about files in these directories. It could infer that any changes under these paths would not affect the output of status. Additionally, there can be a significant performance benefit by avoiding scanning through ignored directories. When status is set to report matching ignored files, it has the following behavior. Ignored files and directories that explicitly match an exclude pattern are reported. If an ignored directory matches an exclude pattern, then the path of the directory is returned. If a directory does not match an exclude pattern, but all of its contents are ignored, then the contained files are reported instead of the directory. Signed-off-by: Jameson Miller <jamill@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-31 01:21:37 +08:00
enum show_ignored_type {
SHOW_NO_IGNORED,
SHOW_TRADITIONAL_IGNORED,
SHOW_MATCHING_IGNORED,
};
/* from where does this commit originate */
enum commit_whence {
FROM_COMMIT, /* normal */
FROM_MERGE, /* commit came from merge */
FROM_CHERRY_PICK_SINGLE, /* commit came from cherry-pick */
FROM_CHERRY_PICK_MULTI, /* commit came from a sequence of cherry-picks */
FROM_REBASE_PICK /* commit came from a pick/reword/edit */
};
static inline int is_from_cherry_pick(enum commit_whence whence)
{
return whence == FROM_CHERRY_PICK_SINGLE ||
whence == FROM_CHERRY_PICK_MULTI;
}
static inline int is_from_rebase(enum commit_whence whence)
{
return whence == FROM_REBASE_PICK;
}
struct wt_status_change_data {
int worktree_status;
int index_status;
int stagemask;
int mode_head, mode_index, mode_worktree;
struct object_id oid_head, oid_index;
int rename_status;
int rename_score;
char *rename_source;
unsigned dirty_submodule : 2;
unsigned new_submodule_commits : 1;
};
enum wt_status_format {
STATUS_FORMAT_NONE = 0,
STATUS_FORMAT_LONG,
STATUS_FORMAT_SHORT,
STATUS_FORMAT_PORCELAIN,
STATUS_FORMAT_PORCELAIN_V2,
STATUS_FORMAT_UNSPECIFIED
};
#define SPARSE_CHECKOUT_DISABLED -1
#define SPARSE_CHECKOUT_SPARSE_INDEX -2
struct wt_status_state {
int merge_in_progress;
int am_in_progress;
int am_empty_patch;
int rebase_in_progress;
int rebase_interactive_in_progress;
int cherry_pick_in_progress;
int bisect_in_progress;
int revert_in_progress;
int detached_at;
int sparse_checkout_percentage; /* SPARSE_CHECKOUT_DISABLED if not sparse */
char *branch;
char *onto;
char *detached_from;
status: fix branch shown when not only bisecting In 83c750acde (wt-status.*: better advice for git status added, 2012-06-05), git-status received new informative messages to describe the ongoing work in a worktree. These messages were enhanced in 0722c805d6 (status: show the branch name if possible in in-progress info, 2013-02-03), to show, if possible, the branch where the operation was initiated. Since then, we show incorrect information when several operations are in progress and one of them is bisect: $ git checkout -b foo $ GIT_SEQUENCE_EDITOR='echo break >' git rebase -i HEAD~ $ git checkout -b bar $ git bisect start $ git status ... You are currently editing a commit while rebasing branch 'bar' on '...'. You are currently bisecting, started from branch 'bar'. ... Note that we erroneously say "while rebasing branch 'bar'" when we should be referring to "foo". This must have gone unnoticed for so long because it must be unusual to start a bisection while another operation is in progress. And even less usual to involve different branches. It caught my attention reviewing a leak introduced in 8b87cfd000 (wt-status: move strbuf into read_and_strip_branch(), 2013-03-16). A simple change to deal with this situation can be to record in struct wt_status_state, the branch where the bisect starts separately from the branch related to other operations. Let's do it and so we'll be able to display correct information and we'll avoid the leak as well. Signed-off-by: Rubén Justo <rjusto@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-10 04:12:47 +08:00
char *bisecting_from;
struct object_id detached_oid;
struct object_id revert_head_oid;
struct object_id cherry_pick_head_oid;
};
struct wt_status {
struct repository *repo;
int is_initial;
char *branch;
const char *reference;
struct pathspec pathspec;
int verbose;
int amend;
enum commit_whence whence;
int nowarn;
int use_color;
int no_gettext;
int display_comment_prefix;
int relative_paths;
int submodule_summary;
status: add option to show ignored files differently Teach the status command more flexibility in how ignored files are reported. Currently, the reporting of ignored files and untracked files are linked. You cannot control how ignored files are reported independently of how untracked files are reported (i.e. `all` vs `normal`). This makes it impossible to show untracked files with the `all` option, but show ignored files with the `normal` option. This work 1) adds the ability to control the reporting of ignored files independently of untracked files and 2) introduces the concept of status reporting ignored paths that explicitly match an ignored pattern. There are 2 benefits to these changes: 1) if a consumer needs all untracked files but not all ignored files, there is a performance benefit to not scanning all contents of an ignored directory and 2) returning ignored files that explicitly match a path allow a consumer to make more informed decisions about when a status result might be stale. This commit implements --ignored=matching with --untracked-files=all. The following commit will implement --ignored=matching with --untracked=files=normal. As an example of where this flexibility could be useful is that our application (Visual Studio) runs the status command and presents the output. It shows all untracked files individually (e.g. using the '--untracked-files==all' option), and would like to know about which paths are ignored. It uses information about ignored paths to make decisions about when the status result might have changed. Additionally, many projects place build output into directories inside a repository's working directory (e.g. in "bin/" and "obj/" directories). Normal usage is to explicitly ignore these 2 directory names in the .gitignore file (rather than or in addition to the *.obj pattern).If an application could know that these directories are explicitly ignored, it could infer that all contents are ignored as well and make better informed decisions about files in these directories. It could infer that any changes under these paths would not affect the output of status. Additionally, there can be a significant performance benefit by avoiding scanning through ignored directories. When status is set to report matching ignored files, it has the following behavior. Ignored files and directories that explicitly match an exclude pattern are reported. If an ignored directory matches an exclude pattern, then the path of the directory is returned. If a directory does not match an exclude pattern, but all of its contents are ignored, then the contained files are reported instead of the directory. Signed-off-by: Jameson Miller <jamill@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-31 01:21:37 +08:00
enum show_ignored_type show_ignored_mode;
enum untracked_status_type show_untracked_files;
Add the option "--ignore-submodules" to "git status" In some use cases it is not desirable that "git status" considers submodules that only contain untracked content as dirty. This may happen e.g. when the submodule is not under the developers control and not all build generated files have been added to .gitignore by the upstream developers. Using the "untracked" parameter for the "--ignore-submodules" option disables checking for untracked content and lets git diff report them as changed only when they have new commits or modified content. Sometimes it is not wanted to have submodules show up as changed when they just contain changes to their work tree (this was the behavior before 1.7.0). An example for that are scripts which just want to check for submodule commits while ignoring any changes to the work tree. Also users having large submodules known not to change might want to use this option, as the - sometimes substantial - time it takes to scan the submodule work tree(s) is saved when using the "dirty" parameter. And if you want to ignore any changes to submodules, you can now do that by using this option without parameters or with "all" (when the config option status.submodulesummary is set, using "all" will also suppress the output of the submodule summary). A new function handle_ignore_submodules_arg() is introduced to parse this option new to "git status" in a single location, as "git diff" already knew it. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-25 22:56:47 +08:00
const char *ignore_submodule_arg;
char color_palette[WT_STATUS_MAXSLOT][COLOR_MAXLEN];
unsigned colopts;
int null_termination;
int commit_template;
int show_branch;
int show_stash;
int hints;
enum ahead_behind_flags ahead_behind_flags;
int detect_rename;
int rename_score;
int rename_limit;
enum wt_status_format status_format;
unsigned char added_cut_line; /* boolean */
struct wt_status_state state;
struct object_id oid_commit; /* when not Initial */
/* These are computed during processing of the individual sections */
int committable;
int workdir_dirty;
const char *index_file;
FILE *fp;
const char *prefix;
struct string_list change;
struct string_list untracked;
struct string_list ignored;
uint32_t untracked_in_ms;
};
interpret-trailers: honor the cut line If a commit message is edited with the "verbose" option, the buffer will have a cut line and diff after the log message, like so: my subject # ------------------------ >8 ------------------------ # Do not touch the line above. # Everything below will be removed. diff --git a/foo.txt b/foo.txt index 5716ca5..7601807 100644 --- a/foo.txt +++ b/foo.txt @@ -1 +1 @@ -bar +baz "git interpret-trailers" is unaware of the cut line, and assumes the trailer block would be at the end of the whole thing. This can easily be seen with: $ GIT_EDITOR='git interpret-trailers --in-place --trailer Acked-by:me' \ git commit --amend -v Teach "git interpret-trailers" to notice the cut-line and ignore the remainder of the input when looking for a place to add new trailer block. This makes it consistent with how "git commit -v -s" inserts a new Signed-off-by: line. This can be done by the same logic as the existing helper function, wt_status_truncate_message_at_cut_line(), uses, but it wants the caller to pass a strbuf to it. Because the function ignore_non_trailer() used by the command takes a <pointer, length> pair, not a strbuf, steal the logic from wt_status_truncate_message_at_cut_line() to create a new wt_status_locate_end() helper function that takes <pointer, length> pair, and make ignore_non_trailer() call it to help "interpret-trailers". Since there is only one caller of wt_status_truncate_message_at_cut_line() in cmd_commit(), rewrite it to call wt_status_locate_end() helper instead and remove the old helper that no longer has any caller. Signed-off-by: Brian Malehorn <bmalehorn@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-16 14:06:49 +08:00
size_t wt_status_locate_end(const char *s, size_t len);
void wt_status_append_cut_line(struct strbuf *buf);
void wt_status_add_cut_line(struct wt_status *s);
void wt_status_prepare(struct repository *r, struct wt_status *s);
void wt_status_print(struct wt_status *s);
void wt_status_collect(struct wt_status *s);
/*
* Frees the buffers allocated by wt_status_collect.
*/
void wt_status_collect_free_buffers(struct wt_status *s);
/*
* Frees the buffers of the wt_status_state.
*/
void wt_status_state_free_buffers(struct wt_status_state *s);
void wt_status_get_state(struct repository *repo,
struct wt_status_state *state,
int get_detached_from);
int wt_status_check_rebase(const struct worktree *wt,
struct wt_status_state *state);
int wt_status_check_bisect(const struct worktree *wt,
struct wt_status_state *state);
__attribute__((format (printf, 3, 4)))
void status_printf_ln(struct wt_status *s, const char *color, const char *fmt, ...);
__attribute__((format (printf, 3, 4)))
void status_printf(struct wt_status *s, const char *color, const char *fmt, ...);
/* The following functions expect that the caller took care of reading the index. */
int has_unstaged_changes(struct repository *repo,
int ignore_submodules);
int has_uncommitted_changes(struct repository *repo,
int ignore_submodules);
int require_clean_work_tree(struct repository *repo,
const char *action,
const char *hint,
int ignore_submodules,
int gently);
#endif /* STATUS_H */