Tags: gitgitgadget/git
Tags
git-add : Respect submodule ignore=all and only add changes with --force
The feature of configuring a submodule to "ignore=all" is nicely respected
in commands "status" and "diff". However the "add" command does not respect
the configuration the same way. The behavior is problematic for the logic
between status/diff and add. Secondly it makes it problematic to track
branches in the submodule configuration as developers unintentionally keeps
add submodule updates and get conflicts for no intentional reason. Both adds
unnecessary friction to the usage of submodules.
The patches implement the same logical behavior for ignore=all submodules as
regular ignored files. The status now does not show any diff - nor will the
add command update the reference submodule reference. If you add the
submodule path which is ignore=all then you are presented with a message
that you need to use the --force option. The branch=, ignore=all (and
update=none) now works great with update --remote, but developers does not
have to consider changes in the updates of the submodule sha1. The
implementation removes a friction of working with submodules and can be used
like the repo tool with branches configured. The submodule status report
could be used for build/release documentation for reproduction of a setup.
A few tests used the adding of submodules without --force, hence they have
been updated to use the --force option.
Claus Schneider(Eficode) (5):
read-cache: update add_files_to_cache to take param
ignored_too(--force)
read-cache: let read-cache respect submodule ignore=all and --force
tests: add new t2206-add-submodule-ignored.sh to test ignore=all
scenario
tests: fix existing tests when add an ignore=all submodule
Documentation: update add --force and submodule ignore=all config
Documentation/git-add.adoc | 4 +-
Documentation/gitmodules.adoc | 5 +-
builtin/add.c | 2 +-
builtin/checkout.c | 2 +-
builtin/commit.c | 2 +-
read-cache-ll.h | 2 +-
read-cache.c | 54 ++++++++++++-
t/lib-submodule-update.sh | 6 +-
t/meson.build | 1 +
t/t2206-add-submodule-ignored.sh | 134 +++++++++++++++++++++++++++++++
t/t7508-status.sh | 2 +-
11 files changed, 202 insertions(+), 12 deletions(-)
create mode 100755 t/t2206-add-submodule-ignored.sh
base-commit: c44beea
Submitted-As: https://lore.kernel.org/git/pull.1987.git.1760818039.gitgitgadget@gmail.com
diff: stop output garbled message in dry run mode From: Lidong Yan <yldhome2d2@gmail.com> In dry run mode, diff_flush_patch() should not produce any output. However, in commit b55e6d3 (diff: ensure consistent diff behavior with ignore options, 2025-08-08), only the output during the comparison of two file contents was suppressed. For file deletions or mode changes, diff_flush_patch() still produces output. In run_extern_diff(), set quiet to true if in dry run mode. In emit_diff_symbol_from_struct(), directly return if in dry run mode. Signed-off-by: Lidong Yan <yldhome2d2@gmail.com> Submitted-As: https://lore.kernel.org/git/pull.2071.git.git.1760671049113.gitgitgadget@gmail.com
doc: git-reset: clarify DESCRIPTION section I got feedback from 24 Git users about the current git reset man page, using this tool: https://text-feedback.wizardzines.com/git-reset. My main goals here are to highlight the git reset [--soft | --hard | --mixed...] <commit> use of git reset that many users commenting said they considered the "main" use (which is currently at the end), explain how --soft, --hard and --mixed work more clearly, and to avoid using terminology that users don't understand when that's realistic. Like we discussed with git checkout, there's some tension about using the word "index" since on one hand many users don't know what it means, but on the other hand (especially with commands like git reset --hard) it gets very awkward to talk about what's going on precisely without using that word, since the index is a core concept in Git's data model. I've done my best here to use the word "index" where I think it's appropriate and use the word "staged" otherwise. There were also quite a few comments about the EXAMPLES section which I think could also be made clearer, but I'll defer that to a separate patch series to keep the size of this one under control. Julia Evans (4): doc: git-reset: reorder the forms doc: git-reset: clarify intro doc: git-reset: clarify `git reset [mode]` doc: git-reset: clarify `git reset <pathspec>` Documentation/git-reset.adoc | 102 +++++++++++++++++------------------ 1 file changed, 51 insertions(+), 51 deletions(-) base-commit: a483264 Submitted-As: https://lore.kernel.org/git/pull.1991.git.1760731558.gitgitgadget@gmail.com
commit-graph: add new config for changed-paths & recommend it in scalar From: Emily Yang <emilyyang.git@gmail.com> The changed-path Bloom filters feature has proven stable and reliable over several years of use, delivering significant performance improvement for file history computation in large monorepos. Currently a user can opt-in to writing the changed-path Bloom filters using the "--changed-paths" option to "git commit-graph write". The filters will be persisted until the user drops the filters using the "--no-changed-paths" option. For this functionality, refer to 0087a87 (commit-graph: persist existence of changed-paths, 2020-07-01). Large monorepos using Git's background maintenance to build and update commit-graph files could use an easy switch to enable this feature without a foreground computation. In this commit, we're proposing a new config option "commitGraph.changedPaths": * If "true", "git commit-graph write" will write Bloom filters, equivalent to passing "--changed-paths"; * If "false" or "unset", Bloom filters will be written during "git commit-graph write" only if the filters already exist in the current commit-graph file. This matches the default behaviour of "git commit-graph write" without any "--[no-]changed-paths" option. Note "false" can disable a previous "true" config value but doesn't imply "--no-changed-paths". This config will always respect the precedence of command line option "--[no-]changed-paths". We also set this new config as optional recommended config in scalar to turn on this feature for large repos. Helped-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Emily Yang <emilyyang.git@gmail.com> Submitted-As: https://lore.kernel.org/git/pull.1983.v2.git.1760734739642.gitgitgadget@gmail.com In-Reply-To: https://lore.kernel.org/git/pull.1983.git.1760043710502.gitgitgadget@gmail.com
Upgrade a couple GitHub Actions The Dependabot setup of Git for Windows suggested a couple of version upgrades; I extracted those that apply to Git itself. Note that I took authorship of the commits because Dependabot's email is not exactly meant for follow-up discussions. Johannes Schindelin (4): build(deps): bump actions/download-artifact from 4 to 5 build(deps): bump actions/checkout from 4 to 5 build(deps): bump actions/setup-python from 5 to 6 build(deps): bump actions/github-script from 7 to 8 .github/workflows/check-style.yml | 2 +- .github/workflows/check-whitespace.yml | 2 +- .github/workflows/coverity.yml | 2 +- .github/workflows/main.yml | 34 +++++++++++++------------- 4 files changed, 20 insertions(+), 20 deletions(-) base-commit: 143f58e Submitted-As: https://lore.kernel.org/git/pull.1990.git.1760629692.gitgitgadget@gmail.com
docs: fix minor grammar issue in MyFirstContribution.adoc From: QueenJcloud <qjessa662@gmail.com> This commit corrects a small grammatical error in the MyFirstContribution document to improve clarity and readability for new contributors. Signed-off-by: QueenJcloud <qjessa662@gmail.com> Submitted-As: https://lore.kernel.org/git/pull.1988.git.1760600313093.gitgitgadget@gmail.com
Xdiff cleanup part2
Maintainer note: This patch series builds on top of en/xdiff-cleanup and
am/xdiff-hash-tweak (both of which are now in master).
The primary goal of this patch series is to convert every field's type in
xrecord_t and xdfile_t to be unambiguous, in preparation to make it more
Rust FFI friendly. Additionally the ha field in xrecord_t is split into
line_hash and minimal_perfect hash.
The order of some of the fields has changed as called out by the commit
messages.
Before:
typedef struct s_xrecord {
char const *ptr;
long size;
unsigned long ha;
} xrecord_t;
typedef struct s_xdfile {
xrecord_t *recs;
long nrec;
long dstart, dend;
bool *changed;
long *rindex;
long nreff;
} xdfile_t;
After part 2
typedef struct s_xrecord {
uint8_t const *ptr;
size_t size;
uint64_t line_hash;
size_t minimal_perfect_hash;
} xrecord_t;
typedef struct s_xdfile {
xrecord_t *recs;
size_t nrec;
bool *changed;
size_t *reference_index;
size_t nreff;
ssize_t dstart, dend;
} xdfile_t;
Ezekiel Newren (9):
xdiff: use ssize_t for dstart/dend, make them last in xdfile_t
xdiff: make xrecord_t.ptr a uint8_t instead of char
xdiff: use size_t for xrecord_t.size
xdiff: use unambiguous types in xdl_hash_record()
xdiff: split xrecord_t.ha into line_hash and minimal_perfect_hash
xdiff: make xdfile_t.nrec a size_t instead of long
xdiff: make xdfile_t.nreff a size_t instead of long
xdiff: change rindex from long to size_t in xdfile_t
xdiff: rename rindex -> reference_index
xdiff-interface.c | 2 +-
xdiff/xdiffi.c | 29 +++++++++++------------
xdiff/xemit.c | 28 +++++++++++-----------
xdiff/xhistogram.c | 4 ++--
xdiff/xmerge.c | 30 ++++++++++++------------
xdiff/xpatience.c | 14 +++++------
xdiff/xprepare.c | 58 +++++++++++++++++++++++-----------------------
xdiff/xtypes.h | 15 ++++++------
xdiff/xutils.c | 32 ++++++++++++-------------
xdiff/xutils.h | 6 ++---
10 files changed, 109 insertions(+), 109 deletions(-)
base-commit: 143f58e
Submitted-As: https://lore.kernel.org/git/pull.2070.git.git.1760563101.gitgitgadget@gmail.com
BreakingChanges: say that `git diff X..Y` syntax will be removed in 3.0 From: Martin von Zweigbergk <martinvonz@google.com> The `git diff X..Y` syntax is quite misleading because it looks like it shows the diff of the commits in the X..Y range but it actually shows the diff from X to Y. IMO, if that syntax is supported, it should show a diff from the merge base of X and Y to Y. I hope Git 3.0 is a good time to remove support for the current syntax and semantics. Then we can perhaps add the syntax back later with less surprising semantics. Signed-off-by: Martin von Zweigbergk <martinvonz@google.com> Submitted-As: https://lore.kernel.org/git/pull.1989.git.1760566054455.gitgitgadget@gmail.com
doc: git-pull: clarify DESCRIPTION section I got feedback from 15 Git users on the current git pull man page, using this tool: https://text-feedback.wizardzines.com/git-pull. My goals here are to be clear about the relationship between git pull and fetch/merge/rebase etc, make sure users know the current default for git pull (--ff-only) since some folks still remember the old default, and to help users quickly figure out what command they need to run to merge/rebase/squash/etc. I've taken a pretty aggressive approach because I think it's possible to have a pretty short and focused DESCRIPTION section here while keeping the most important info. Open to hearing that I've removed too much. This references the UPSTREAM BRANCHES section from https://lore.kernel.org/git/0ec629d4037bf5d1ccc248ca1bbd87ccc08119a3.1757703309.git.gitgitgadget@gmail.com/ , so if that isn't merged I'll need to revisit the approach here. changes in v2: * Add "(excluding merge options)" to clarify which options are passed to git fetch (from Chris's review) * Say that git pull will by default merge the upstream branch. (from Chris's review) * Add some links to the UPSTREAM BRANCHES section, and to the <refspec> section in git fetch, to make it easier to navigate in the HTML version of the docs at least. The situation where we repeat the <repository> part in git fetch is weird but I don't have a better idea for how to handle it right now. The UPSTREAM BRANCHES links are currently failing the documentation tests, but should pass once the patch series that adds that is merged. (from Ben's review) changes in v3: Change "fails if the local branch has diverged" to say "remote branch has diverged", from Junio's review. I did not come up with a better idea for a word to use than "integrate" so left that alone. Julia Evans (4): doc: git-pull: move <repository> and <refspec> params doc: git-pull: clarify options for integrating remote branch doc: git-pull: delete the example doc: git-pull: clarify how to exit a conflicted merge Documentation/git-pull.adoc | 93 +++++++++++++---------------- Documentation/pull-fetch-param.adoc | 1 + 2 files changed, 41 insertions(+), 53 deletions(-) base-commit: ca2559c Submitted-As: https://lore.kernel.org/git/pull.1976.v3.git.1760534011.gitgitgadget@gmail.com In-Reply-To: https://lore.kernel.org/git/pull.1976.git.1758656702.gitgitgadget@gmail.com In-Reply-To: https://lore.kernel.org/git/pull.1976.v2.git.1759951536.gitgitgadget@gmail.com
PreviousNext