* Re: Storing private config files in .git directory?
From: Jeff King @ 2024-01-12 6:56 UTC (permalink / raw)
To: Stefan Haller; +Cc: Junio C Hamano, git
In-Reply-To: <c8ad96bc-0180-42f4-b559-20b475098eca@haller-berlin.de>
On Thu, Jan 11, 2024 at 02:28:51PM +0100, Stefan Haller wrote:
> On 10.01.24 12:08, Jeff King wrote:
> > On Mon, Jan 08, 2024 at 10:20:00AM -0800, Junio C Hamano wrote:
> >
> >> An obvious alternative is to have .lazygit directory next to .git directory
> >> which would give you a bigger separation, which can cut both ways.
> >
> > Just to spell out one of those ways: unlike ".git", we will happily
> > check out ".lazygit" from an untrusted remote repository. That may be a
> > feature if you want to be able to share project-specific config, or it
> > might be a terrible security vulnerability if lazygit config files can
> > trigger arbitrary code execution.
>
> Unless you don't version it and add it to .gitignore instead, which (I
> suppose) is what most people do with their .vscode/settings.json, for
> example.
A .gitignore will help with people accidentally adding their .lazygit
directory. What I meant, though, was somebody _intentionally_ creating a
malicious repository that would then execute arbitrary code when the
victim cloned it. We prevent that from happening with .git/config
because there's special handling that refuses to check out the name
".git" (or other filesystem-equivalent names). But ".lazygit" would not
have that same protection.
-Peff
^ permalink raw reply
* Re: [PATCH 1/1] attr: add builtin objectmode values support
From: Joanna Wang @ 2024-01-12 6:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, sunshine, tboegi
In-Reply-To: <xmqq5y0ssknj.fsf@gitster.g>
(I was out all month.) Thank you for the additional fixes.
On Thu, Dec 21, 2023 at 4:07 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> Junio C Hamano <gitster@pobox.com> writes:
>
> > The attached is one possible way to plug the leak; I am not sure if
> > it is the best one, though. One thing I like about the solution is
> > that the approach makes sure that the mode attributes we would ever
> > return are very tightly controlled and does not allow a buggy code
> > to come up with "mode" to be passed to this new helper function to
> > pass random and unsupported mode bits without triggering the BUG().
> >
> > attr.c | 30 +++++++++++++++++++++++++++---
> > 1 file changed, 27 insertions(+), 3 deletions(-)
>
> Anybody who want to propose a better leakfix (we cannot afford to do
> with UNLEAK() as the number of leaked mode string will be unbounded)?
>
> Otherwise, I'll squash it in to Jonanna's patch and merge it down to
> 'next'.
>
> Thanks.
>
> > diff --git c/attr.c w/attr.c
> > index b03c20f768..679e42258c 100644
> > --- c/attr.c
> > +++ w/attr.c
> > @@ -1250,10 +1250,34 @@ static struct object_id *default_attr_source(void)
> > return &attr_source;
> > }
> >
> > +static const char *interned_mode_string(unsigned int mode)
> > +{
> > + static struct {
> > + unsigned int val;
> > + char str[7];
> > + } mode_string[] = {
> > + { .val = 0040000 },
> > + { .val = 0100644 },
> > + { .val = 0100755 },
> > + { .val = 0120000 },
> > + { .val = 0160000 },
> > + };
> > + int i;
> > +
> > + for (i = 0; i < ARRAY_SIZE(mode_string); i++) {
> > + if (mode_string[i].val != mode)
> > + continue;
> > + if (!*mode_string[i].str)
> > + snprintf(mode_string[i].str, sizeof(mode_string[i].str),
> > + "%06o", mode);
> > + return mode_string[i].str;
> > + }
> > + BUG("Unsupported mode 0%o", mode);
> > +}
> > +
> > static const char *builtin_object_mode_attr(struct index_state *istate, const char *path)
> > {
> > unsigned int mode;
> > - struct strbuf sb = STRBUF_INIT;
> >
> > if (direction == GIT_ATTR_CHECKIN) {
> > struct object_id oid;
> > @@ -1287,8 +1311,8 @@ static const char *builtin_object_mode_attr(struct index_state *istate, const ch
> > else
> > return ATTR__UNSET;
> > }
> > - strbuf_addf(&sb, "%06o", mode);
> > - return strbuf_detach(&sb, NULL);
> > +
> > + return interned_mode_string(mode);
> > }
> >
> >
^ permalink raw reply
* Hello can you join me on slack
From: ross nicholas Oneil thomas @ 2024-01-12 5:25 UTC (permalink / raw)
To: git@vger.kernel.org
Ross Nicholas Oneil Thomas
ownership of:
www.github.com
www.coinbase.com
www.jsnull.com
(559-816-2950)
^ permalink raw reply
* Re: [PATCH] push: improve consistency of output when "up to date"
From: Eric Sunshine @ 2024-01-12 3:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Benji Kay via GitGitGadget, git, Benji Kay
In-Reply-To: <xmqqjzofec0e.fsf@gitster.g>
On Thu, Jan 11, 2024 at 5:33 PM Junio C Hamano <gitster@pobox.com> wrote:
> Eric Sunshine <sunshine@sunshineco.com> writes:
> > Thanks. This particular change is proposed periodically...
> > ... but has not been considered desirable.
> >
> > See, for instance, this email thread explaining the rationale for
> > avoiding such a change:
> > https://lore.kernel.org/git/pull.1298.git.1658908927714.gitgitgadget@gmail.com/T/
>
> Let's do the second best thing, leave a short comment near them, to
> make it possible for those who are motivated enough to find out why
> we decided to tell them "do not modify".
> ---
> diff --git a/builtin/send-pack.c b/builtin/send-pack.c
> @@ -333,6 +333,7 @@ int cmd_send_pack(int argc, const char **argv, const char *prefix)
> if (!ret && !transport_refs_pushed(remote_refs))
> + /* do not modify this string */
> fprintf(stderr, "Everything up-to-date\n");
Yes, that helps, though, we can probably be a bit more friendly to
future developers. Rather than insisting that they dig through
history, we could use a slightly less terse comment, such as:
/* stable plumbing output; do not modify or localize */
^ permalink raw reply
* Help: Trying to setup triangular workflow
From: Matthew B. Gray @ 2024-01-12 2:23 UTC (permalink / raw)
To: git
Hello
I am trying to set up a triangular workflow against a fork. The example I'm
using is documented here: https://git-scm.com/docs/gitrevisions
Here's the example:
$ git config push.default current
$ git config remote.pushdefault myfork
$ git switch -c mybranch origin/master
$ git rev-parse --symbolic-full-name @{upstream}
refs/remotes/origin/master
$ git rev-parse --symbolic-full-name @{push}
refs/remotes/myfork/mybranch
My setup looks like this:
λ git -v
git version 2.43.0
λ git remote -vv
myfork git@github.com:heymatthew/dactyl-configurator-fork (fetch)
myfork git@github.com:heymatthew/dactyl-configurator-fork (push)
origin https://github.com/rianadon/dactyl-configurator (fetch)
origin https://github.com/rianadon/dactyl-configurator (push)
Here's what I get from running the documented example:
λ git config push.default current
λ git config remote.pushdefault myfork
λ git switch -c mybranch origin/main
λ git push
* [new branch] mybranch -> mybranch
branch 'mybranch' set up to track 'myfork/mybranch'.
λ git rev-parse --symbolic-full-name @{upstream}
refs/remotes/myfork/mybranch
λ git rev-parse --symbolic-full-name @{push}
refs/remotes/myfork/mybranch
I was expecting @{upstream} to be origin/main, but it appears that @{u} and
@{p} are the same.
Am I doing something wrong?
Are there better examples someone can point me at to do this?
Thanks in advance :)
Ngā mihi,
Matthew
^ permalink raw reply
* What's cooking in git.git (Jan 2024, #04; Thu, 11)
From: Junio C Hamano @ 2024-01-12 2:00 UTC (permalink / raw)
To: git
Here are the topics that have been cooking in my tree. Commits
prefixed with '+' are in 'next' (being in 'next' is a sign that a
topic is stable enough to be used and are candidate to be in a
future release). Commits prefixed with '-' are only in 'seen', and
aren't considered "accepted" at all and may be annotated with an URL
to a message that raises issues but they are no means exhaustive. A
topic without enough support may be discarded after a long period of
no activity (of course they can be resubmit when new interests
arise).
Copies of the source code to Git live in many repositories, and the
following is a list of the ones I push into or their mirrors. Some
repositories have only a subset of branches.
With maint, master, next, seen, todo:
git://git.kernel.org/pub/scm/git/git.git/
git://repo.or.cz/alt-git.git/
https://kernel.googlesource.com/pub/scm/git/git/
https://github.com/git/git/
https://gitlab.com/git-vcs/git/
With all the integration branches and topics broken out:
https://github.com/gitster/git/
Even though the preformatted documentation in HTML and man format
are not sources, they are published in these repositories for
convenience (replace "htmldocs" with "manpages" for the manual
pages):
git://git.kernel.org/pub/scm/git/git-htmldocs.git/
https://github.com/gitster/git-htmldocs.git/
Release tarballs are available at:
https://www.kernel.org/pub/software/scm/git/
--------------------------------------------------
[New Topics]
* cp/t4129-pipefix (2024-01-10) 1 commit
- t4129: prevent loss of exit code due to the use of pipes
Test update.
Will merge to 'next'.
source: <pull.1636.git.1704891257544.gitgitgadget@gmail.com>
* rj/advice-delete-branch-not-fully-merged (2024-01-11) 3 commits
- branch: make the advice to force-deleting a conditional one
- advice: fix an unexpected leading space
- advice: sort the advice related lists
The error message given when "git branch -d branch" fails due to
commits unique to the branch has been split into an error and a new
conditional advice message.
Will merge to 'next'?
source: <4aedc15c-4b3f-4f5e-abea-581b501600f8@gmail.com>
* en/diffcore-delta-final-line-fix (2024-01-11) 1 commit
- diffcore-delta: avoid ignoring final 'line' of file
Rename detection logic ignored the final line of a file if it is an
incomplete line.
Expecting a reroll.
cf. <xmqqedenearc.fsf@gitster.g>
source: <pull.1637.git.1705006074626.gitgitgadget@gmail.com>
* mj/gitweb-unreadable-config-error (2024-01-10) 1 commit
- gitweb: die when a configuration file cannot be read
When given an existing but unreadable file as a configuration file,
gitweb behaved as if the file did not exist at all, but now it
errors out. This is a change that may break backward compatibility.
Will merge to 'next'?
source: <20240110225709.30168-1-marcelo.jimenez@gmail.com>
* ps/completion-with-reftable-fix (2024-01-11) 2 commits
- completion: silence pseudoref existence check
- t9902: verify that completion does not print anything
Completion update to prepare for reftable
Will merge to 'next'.
source: <cover.1704969119.git.ps@pks.im>
* ps/p4-use-ref-api (2024-01-11) 1 commit
- git-p4: stop reaching into the refdb
"git p4" update to prepare for reftable
Will merge to 'next'.
source: <33d6a062ec56be33ed50a42a420be0b023f6f4cf.1704980814.git.ps@pks.im>
--------------------------------------------------
[Cooking]
* ps/gitlab-ci-static-analysis (2024-01-08) 1 commit
(merged to 'next' on 2024-01-10 at 71af34de07)
+ ci: add job performing static analysis on GitLab CI
GitLab CI update.
Will merge to 'master'.
source: <1536a5ef07ad24dafb5d685b40099882f89e6cc5.1703761005.git.ps@pks.im>
* ps/prompt-parse-HEAD-futureproof (2024-01-08) 2 commits
(merged to 'next' on 2024-01-10 at f9515b9d89)
+ git-prompt: stop manually parsing HEAD with unknown ref formats
+ Merge branch 'ps/refstorage-extension' into ps/prompt-parse-HEAD-futureproof
(this branch uses ps/refstorage-extension.)
Futureproof command line prompt support (in contrib/).
Will merge to 'master'.
source: <ef4e36a5a40c369da138242a8fdc9e12a846613b.1704356313.git.ps@pks.im>
* ps/reftable-optimize-io (2024-01-11) 5 commits
- reftable/blocksource: use mmap to read tables
- reftable/blocksource: refactor code to match our coding style
- reftable/stack: use stat info to avoid re-reading stack list
- reftable/stack: refactor reloading to use file descriptor
- reftable/stack: refactor stack reloading to have common exit path
Low-level I/O optimization for reftable.
Will merge to 'next'.
source: <cover.1704966670.git.ps@pks.im>
* rj/clarify-branch-doc-m (2024-01-08) 1 commit
(merged to 'next' on 2024-01-10 at 432eaa2c6b)
+ branch: clarify <oldbranch> term
Doc update.
Will merge to 'master'.
source: <d38e5a18-4d85-48f3-bc8b-8ca02ea683a4@gmail.com>
* tb/fetch-all-configuration (2024-01-08) 1 commit
- fetch: add new config option fetch.all
"git fetch" learned to pay attention to "fetch.all" configuration
variable, which pretends as if "--all" was passed from the command
line when no remote parameter was given.
Will merge to 'next'.
source: <20240108211832.47362-1-dev@tb6.eu>
* rj/advice-disable-how-to-disable (2024-01-09) 3 commits
- advice: allow disabling the automatic hint in advise_if_enabled()
- t/test-tool: handle -c <name>=<value> arguments
- t/test-tool: usage description
All conditional "advice" messages show how to turn them off, which
becomes repetitive. Add a configuration variable to omit the
instruction.
Expecting a reroll.
cf. <ZZ2QafUf/JxXYZU/@nand.local>
source: <7c68392c-af2f-4999-ae64-63221bf7833a@gmail.com>
* vd/fsck-submodule-url-test (2024-01-09) 3 commits
- submodule-config.c: strengthen URL fsck check
- t7450: test submodule urls
- submodule-config.h: move check_submodule_url
Tighten URL checks fsck makes in a URL recorded for submodules.
Expecting a reroll (and review response).
cf. <20240110103812.GB16674@coredump.intra.peff.net>
cf. <ZZ46MrjSocJl-kpU@tanuki>
source: <pull.1635.git.1704822817.gitgitgadget@gmail.com>
* ms/rebase-insnformat-doc-fix (2024-01-03) 1 commit
(merged to 'next' on 2024-01-04 at d68f2be39b)
+ Documentation: fix statement about rebase.instructionFormat
Docfix.
Will merge to 'master'.
source: <pull.1629.git.git.1704305663254.gitgitgadget@gmail.com>
* cp/git-flush-is-an-env-bool (2024-01-04) 1 commit
(merged to 'next' on 2024-01-04 at b435a96ce8)
+ write-or-die: make GIT_FLUSH a Boolean environment variable
Unlike other environment variables that took the usual
true/false/yes/no as well as 0/1, GIT_FLUSH only understood 0/1,
which has been corrected.
Will merge to 'master'.
source: <pull.1628.v3.git.1704363617842.gitgitgadget@gmail.com>
* sd/negotiate-trace-fix (2024-01-03) 1 commit
- push: region_leave trace for negotiate_using_fetch
Tracing fix.
Waiting for a review response.
cf. <xmqqbka27zu9.fsf@gitster.g>
source: <20240103224054.1940209-1-delmerico@google.com>
* sk/mingw-owner-check-error-message-improvement (2024-01-10) 1 commit
- mingw: give more details about unsafe directory's ownership
In addition to (rather cryptic) Security Identifiers, show username
and domain in the error message when we barf on mismatch between
the Git directory and the current user.
Will merge to 'next'.
source: <20240108173837.20480-2-soekkle@freenet.de>
* ib/rebase-reschedule-doc (2024-01-05) 1 commit
(merged to 'next' on 2024-01-08 at d451d1f760)
+ rebase: clarify --reschedule-failed-exec default
Doc update.
Will merge to 'master'.
source: <20240105011424.1443732-2-illia.bobyr@gmail.com>
* jk/commit-graph-slab-clear-fix (2024-01-05) 1 commit
(merged to 'next' on 2024-01-08 at f78c4fc296)
+ commit-graph: retain commit slab when closing NULL commit_graph
Clearing in-core repository (happens during e.g., "git fetch
--recurse-submodules" with commit graph enabled) made in-core
commit object in an inconsistent state by discarding the necessary
data from commit-graph too early, which has been corrected.
Will merge to 'master'.
source: <20240105054142.GA2035092@coredump.intra.peff.net>
* jk/index-pack-lsan-false-positive-fix (2024-01-05) 1 commit
(merged to 'next' on 2024-01-08 at 589ed65251)
+ index-pack: spawn threads atomically
Fix false positive reported by leak sanitizer.
Will merge to 'master'.
source: <20240105085034.GA3078476@coredump.intra.peff.net>
* cp/sideband-array-index-comment-fix (2023-12-28) 1 commit
(merged to 'next' on 2024-01-08 at f906bc86f1)
+ sideband.c: remove redundant 'NEEDSWORK' tag
In-code comment fix.
Will merge to 'master'.
source: <pull.1625.v4.git.1703750460527.gitgitgadget@gmail.com>
* ps/worktree-refdb-initialization (2024-01-08) 7 commits
- builtin/worktree: create refdb via ref backend
- worktree: expose interface to look up worktree by name
- builtin/worktree: move setup of commondir file earlier
- refs/files: skip creation of "refs/{heads,tags}" for worktrees
- setup: move creation of "refs/" into the files backend
- refs: prepare `refs_init_db()` for initializing worktree refs
- Merge branch 'ps/refstorage-extension' into ps/worktree-refdb-initialization
(this branch uses ps/refstorage-extension.)
Instead of manually creating refs/ hierarchy on disk upon a
creation of a secondary worktree, which is only usable via the
files backend, use the refs API to populate it.
Needs review.
source: <cover.1704705733.git.ps@pks.im>
* cp/apply-core-filemode (2023-12-26) 3 commits
- apply: code simplification
- apply: correctly reverse patch's pre- and post-image mode bits
- apply: ignore working tree filemode when !core.filemode
"git apply" on a filesystem without filemode support have learned
to take a hint from what is in the index for the path, even when
not working with the "--index" or "--cached" option, when checking
the executable bit match what is required by the preimage in the
patch.
Needs review.
source: <20231226233218.472054-1-gitster@pobox.com>
* jk/t1006-cat-file-objectsize-disk (2024-01-03) 2 commits
(merged to 'next' on 2024-01-03 at a492c6355c)
+ t1006: prefer shell loop to awk for packed object sizes
(merged to 'next' on 2023-12-28 at d82812e636)
+ t1006: add tests for %(objectsize:disk)
Test update.
Will merge to 'master'.
source: <20231221094722.GA570888@coredump.intra.peff.net>
source: <20240103090152.GB1866508@coredump.intra.peff.net>
* js/contributor-docs-updates (2023-12-27) 9 commits
(merged to 'next' on 2024-01-02 at 0e072117cd)
+ SubmittingPatches: hyphenate non-ASCII
+ SubmittingPatches: clarify GitHub artifact format
+ SubmittingPatches: clarify GitHub visual
+ SubmittingPatches: provide tag naming advice
+ SubmittingPatches: update extra tags list
+ SubmittingPatches: discourage new trailers
+ SubmittingPatches: drop ref to "What's in git.git"
+ CodingGuidelines: write punctuation marks
+ CodingGuidelines: move period inside parentheses
Doc update.
Will merge to 'master'.
source: <pull.1623.v3.git.1703739324.gitgitgadget@gmail.com>
* al/unit-test-ctype (2024-01-05) 1 commit
- unit-tests: rewrite t/helper/test-ctype.c as a unit test
Move test-ctype helper to the unit-test framework.
Expecting a (hopefully small and final) reroll.
cf. <a087f57c-ce72-45c7-8182-f38d0aca9030@web.de>
cf. <33c81610-0958-49da-b702-ba8d96ecf1d3@gmail.com>
source: <20240105161413.10422-1-ach.lumap@gmail.com>
* bk/bisect-doc-fix (2024-01-10) 2 commits
- doc: refer to pathspec instead of path
- doc: use singular form of repeatable path arg
Synopsis fix.
Will merge to 'next'.
source: <20240103040207.661413-1-britton.kerin@gmail.com>
* ja/doc-placeholders-fix (2023-12-26) 2 commits
- doc: enforce placeholders in documentation
- doc: enforce dashes in placeholders
Docfix.
Needs review.
source: <pull.1626.git.1703539287.gitgitgadget@gmail.com>
* ps/refstorage-extension (2024-01-02) 13 commits
(merged to 'next' on 2024-01-08 at f9a034803b)
+ t9500: write "extensions.refstorage" into config
+ builtin/clone: introduce `--ref-format=` value flag
+ builtin/init: introduce `--ref-format=` value flag
+ builtin/rev-parse: introduce `--show-ref-format` flag
+ t: introduce GIT_TEST_DEFAULT_REF_FORMAT envvar
+ setup: introduce GIT_DEFAULT_REF_FORMAT envvar
+ setup: introduce "extensions.refStorage" extension
+ setup: set repository's formats on init
+ setup: start tracking ref storage format
+ refs: refactor logic to look up storage backends
+ worktree: skip reading HEAD when repairing worktrees
+ t: introduce DEFAULT_REPO_FORMAT prereq
+ Merge branch 'ps/clone-into-reftable-repository' into ps/refstorage-extension
(this branch is used by ps/prompt-parse-HEAD-futureproof and ps/worktree-refdb-initialization.)
Introduce a new extension "refstorage" so that we can mark a
repository that uses a non-default ref backend, like reftable.
Will merge to 'master'.
source: <cover.1703833818.git.ps@pks.im>
* ps/reftable-fixes-and-optims (2024-01-03) 9 commits
(merged to 'next' on 2024-01-08 at 167d7685f8)
+ reftable/merged: transfer ownership of records when iterating
+ reftable/merged: really reuse buffers to compute record keys
+ reftable/record: store "val2" hashes as static arrays
+ reftable/record: store "val1" hashes as static arrays
+ reftable/record: constify some parts of the interface
+ reftable/writer: fix index corruption when writing multiple indices
+ reftable/stack: do not auto-compact twice in `reftable_stack_add()`
+ reftable/stack: do not overwrite errors when compacting
+ Merge branch 'ps/reftable-fixes' into ps/reftable-fixes-and-optims
More fixes and optimizations to the reftable backend.
Will merge to 'master'.
source: <cover.1704262787.git.ps@pks.im>
* tb/multi-pack-verbatim-reuse (2023-12-14) 26 commits
(merged to 'next' on 2024-01-04 at 891ac0fa2c)
+ t/perf: add performance tests for multi-pack reuse
+ pack-bitmap: enable reuse from all bitmapped packs
+ pack-objects: allow setting `pack.allowPackReuse` to "single"
+ t/test-lib-functions.sh: implement `test_trace2_data` helper
+ pack-objects: add tracing for various packfile metrics
+ pack-bitmap: prepare to mark objects from multiple packs for reuse
+ pack-revindex: implement `midx_pair_to_pack_pos()`
+ pack-revindex: factor out `midx_key_to_pack_pos()` helper
+ midx: implement `midx_preferred_pack()`
+ git-compat-util.h: implement checked size_t to uint32_t conversion
+ pack-objects: include number of packs reused in output
+ pack-objects: prepare `write_reused_pack_verbatim()` for multi-pack reuse
+ pack-objects: prepare `write_reused_pack()` for multi-pack reuse
+ pack-objects: pass `bitmapped_pack`'s to pack-reuse functions
+ pack-objects: keep track of `pack_start` for each reuse pack
+ pack-objects: parameterize pack-reuse routines over a single pack
+ pack-bitmap: return multiple packs via `reuse_partial_packfile_from_bitmap()`
+ pack-bitmap: simplify `reuse_partial_packfile_from_bitmap()` signature
+ ewah: implement `bitmap_is_empty()`
+ pack-bitmap: pass `bitmapped_pack` struct to pack-reuse functions
+ midx: implement `midx_locate_pack()`
+ midx: implement `BTMP` chunk
+ midx: factor out `fill_pack_info()`
+ pack-bitmap: plug leak in find_objects()
+ pack-bitmap-write: deep-clear the `bb_commit` slab
+ pack-objects: free packing_data in more places
Streaming spans of packfile data used to be done only from a
single, primary, pack in a repository with multiple packfiles. It
has been extended to allow reuse from other packfiles, too.
Will merge to 'master'.
cf. <ZXurD1NTZ4TAs7WZ@nand.local>
source: <cover.1702592603.git.me@ttaylorr.com>
* jc/bisect-doc (2023-12-09) 1 commit
- bisect: document "terms" subcommand more fully
Doc update.
Needs review.
source: <xmqqzfyjmk02.fsf@gitster.g>
* jw/builtin-objectmode-attr (2023-12-28) 1 commit
(merged to 'next' on 2024-01-02 at 4c3784b3a1)
+ attr: add builtin objectmode values support
The builtin_objectmode attribute is populated for each path
without adding anything in .gitattributes files, which would be
useful in magic pathspec, e.g., ":(attr:builtin_objectmode=100755)"
to limit to executables.
Will merge to 'master'.
cf. <xmqq5y0ssknj.fsf@gitster.g>
source: <20231116054437.2343549-1-jojwang@google.com>
* tb/pair-chunk-expect (2023-11-10) 8 commits
- midx: read `OOFF` chunk with `pair_chunk_expect()`
- midx: read `OIDL` chunk with `pair_chunk_expect()`
- commit-graph: read `BIDX` chunk with `pair_chunk_expect()`
- commit-graph: read `GDAT` chunk with `pair_chunk_expect()`
- commit-graph: read `CDAT` chunk with `pair_chunk_expect()`
- commit-graph: read `OIDL` chunk with `pair_chunk_expect()`
- chunk-format: introduce `pair_chunk_expect()` helper
- Merge branch 'jk/chunk-bounds-more' into HEAD
Further code clean-up.
Needs review.
source: <cover.1699569246.git.me@ttaylorr.com>
* tb/path-filter-fix (2023-10-18) 17 commits
- bloom: introduce `deinit_bloom_filters()`
- commit-graph: reuse existing Bloom filters where possible
- object.h: fix mis-aligned flag bits table
- commit-graph: drop unnecessary `graph_read_bloom_data_context`
- commit-graph.c: unconditionally load Bloom filters
- bloom: prepare to discard incompatible Bloom filters
- bloom: annotate filters with hash version
- commit-graph: new filter ver. that fixes murmur3
- repo-settings: introduce commitgraph.changedPathsVersion
- t4216: test changed path filters with high bit paths
- t/helper/test-read-graph: implement `bloom-filters` mode
- bloom.h: make `load_bloom_filter_from_graph()` public
- t/helper/test-read-graph.c: extract `dump_graph_info()`
- gitformat-commit-graph: describe version 2 of BDAT
- commit-graph: ensure Bloom filters are read with consistent settings
- revision.c: consult Bloom filters for root commits
- t/t4216-log-bloom.sh: harden `test_bloom_filters_not_used()`
The Bloom filter used for path limited history traversal was broken
on systems whose "char" is unsigned; update the implementation and
bump the format version to 2.
Expecting a reroll?
cf. <20231023202212.GA5470@szeder.dev>
source: <cover.1697653929.git.me@ttaylorr.com>
* ak/color-decorate-symbols (2023-10-23) 7 commits
- log: add color.decorate.pseudoref config variable
- refs: exempt pseudorefs from pattern prefixing
- refs: add pseudorefs array and iteration functions
- log: add color.decorate.ref config variable
- log: add color.decorate.symbol config variable
- log: use designated inits for decoration_colors
- config: restructure color.decorate documentation
A new config for coloring.
Needs review.
source: <20231023221143.72489-1-andy.koppe@gmail.com>
* eb/hash-transition (2023-10-02) 30 commits
- t1016-compatObjectFormat: add tests to verify the conversion between objects
- t1006: test oid compatibility with cat-file
- t1006: rename sha1 to oid
- test-lib: compute the compatibility hash so tests may use it
- builtin/ls-tree: let the oid determine the output algorithm
- object-file: handle compat objects in check_object_signature
- tree-walk: init_tree_desc take an oid to get the hash algorithm
- builtin/cat-file: let the oid determine the output algorithm
- rev-parse: add an --output-object-format parameter
- repository: implement extensions.compatObjectFormat
- object-file: update object_info_extended to reencode objects
- object-file-convert: convert commits that embed signed tags
- object-file-convert: convert commit objects when writing
- object-file-convert: don't leak when converting tag objects
- object-file-convert: convert tag objects when writing
- object-file-convert: add a function to convert trees between algorithms
- object: factor out parse_mode out of fast-import and tree-walk into in object.h
- cache: add a function to read an OID of a specific algorithm
- tag: sign both hashes
- commit: export add_header_signature to support handling signatures on tags
- commit: convert mergetag before computing the signature of a commit
- commit: write commits for both hashes
- object-file: add a compat_oid_in parameter to write_object_file_flags
- object-file: update the loose object map when writing loose objects
- loose: compatibilty short name support
- loose: add a mapping between SHA-1 and SHA-256 for loose objects
- repository: add a compatibility hash algorithm
- object-names: support input of oids in any supported hash
- oid-array: teach oid-array to handle multiple kinds of oids
- object-file-convert: stubs for converting from one object format to another
Teach a repository to work with both SHA-1 and SHA-256 hash algorithms.
Needs review.
source: <878r8l929e.fsf@gmail.froward.int.ebiederm.org>
* jx/remote-archive-over-smart-http (2023-12-14) 4 commits
- archive: support remote archive from stateless transport
- transport-helper: call do_take_over() in connect_helper
- transport-helper: call do_take_over() in process_connect
- transport-helper: no connection restriction in connect_helper
"git archive --remote=<remote>" learned to talk over the smart
http (aka stateless) transport.
Needs review.
source: <cover.1702562879.git.zhiyou.jx@alibaba-inc.com>
* jx/sideband-chomp-newline-fix (2023-12-18) 3 commits
(merged to 'next' on 2024-01-04 at 1237898a22)
+ pkt-line: do not chomp newlines for sideband messages
+ pkt-line: memorize sideband fragment in reader
+ test-pkt-line: add option parser for unpack-sideband
Sideband demultiplexer fixes.
Will merge to 'master'.
source: <cover.1702823801.git.zhiyou.jx@alibaba-inc.com>
* jc/rerere-cleanup (2023-08-25) 4 commits
- rerere: modernize use of empty strbuf
- rerere: try_merge() should use LL_MERGE_ERROR when it means an error
- rerere: fix comment on handle_file() helper
- rerere: simplify check_one_conflict() helper function
Code clean-up.
Not ready to be reviewed yet.
source: <20230824205456.1231371-1-gitster@pobox.com>
^ permalink raw reply
* Re: [PATCH v2 2/3] advice: fix an unexpected leading space
From: Junio C Hamano @ 2024-01-12 1:21 UTC (permalink / raw)
To: Rubén Justo; +Cc: Git List
In-Reply-To: <d5fbdb05-d16a-4390-946e-22a5a7a1b56a@gmail.com>
Rubén Justo <rjusto@gmail.com> writes:
> [ ... ]
> diff --git a/advice.h b/advice.h
> index 0f584163f5..2affbe1426 100644
> --- a/advice.h
> +++ b/advice.h
> @@ -49,6 +49,7 @@ struct string_list;
> ADVICE_UPDATE_SPARSE_PATH,
> ADVICE_WAITING_FOR_EDITOR,
> ADVICE_SKIPPED_CHERRY_PICKS,
> + ADVICE_WORKTREE_ADD_ORPHAN,
> };
>
> Note the hunk header, instead of a much more expected:
>
> @@ -49,6 +49,7 @@ enum advice_type
Next time, don't include "diff" output in the proposed log message
without indenting. It makes it hard to read and parse.
The attached is what I queued in my tree.
Thanks.
------- >8 ------------- >8 ------------- >8 ------------- >8 -------
From: Rubén Justo <rjusto@gmail.com>
Subject: [PATCH] advice: fix an unexpected leading space
This space was introduced, presumably unintentionally, in b3b18d1621
(advice: revamp advise API, 2020-03-02)
I notice this space due to confuse diff outputs while doing some
changes to enum advice_type.
As a reference, a recent change we have to that enum is:
$ git show 35f0383
...
diff --git a/advice.h b/advice.h
index 0f584163f5..2affbe1426 100644
--- a/advice.h
+++ b/advice.h
@@ -49,6 +49,7 @@ struct string_list;
ADVICE_UPDATE_SPARSE_PATH,
ADVICE_WAITING_FOR_EDITOR,
ADVICE_SKIPPED_CHERRY_PICKS,
+ ADVICE_WORKTREE_ADD_ORPHAN,
};
Note the hunk header, instead of a much more expected:
@@ -49,6 +49,7 @@ enum advice_type
Signed-off-by: Rubén Justo <rjusto@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
advice.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/advice.h b/advice.h
index 9396bcdcf1..74d44d1156 100644
--- a/advice.h
+++ b/advice.h
@@ -10,7 +10,7 @@ struct string_list;
* Add the new config variable to Documentation/config/advice.txt.
* Call advise_if_enabled to print your advice.
*/
- enum advice_type {
+enum advice_type {
ADVICE_ADD_EMBEDDED_REPO,
ADVICE_ADD_EMPTY_PATHSPEC,
ADVICE_ADD_IGNORED_FILE,
--
2.43.0-283-ga54a84b333
^ permalink raw reply related
* Re: [PATCH] push: improve consistency of output when "up to date"
From: Benji Kay @ 2024-01-12 0:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric Sunshine, Benji Kay via GitGitGadget, git
In-Reply-To: <CADavbxcFXpP5EQZ=UEMZt+6KKVtCsTMbgQDHEo0uinm0YfRbZA@mail.gmail.com>
If it's important these messages are not changed (under the presumption
some programs may make decisions based on the output), perhaps a test
should be written to ensure the output is as expected.
^ permalink raw reply
* Re: [PATCH v3] builtin/revert.c: refactor using an enum for cmd-action
From: Junio C Hamano @ 2024-01-12 0:40 UTC (permalink / raw)
To: Michael Lohmann; +Cc: git, phillip.wood123, phillip.wood, wanja.hentze
In-Reply-To: <20240111200627.64199-1-mi.al.lohmann@gmail.com>
Michael Lohmann <mi.al.lohmann@gmail.com> writes:
> - if (cmd == 'c')
> + case ACTION_CONTINUE:
> return sequencer_continue(the_repository, opts);
> - if (cmd == 'a')
> + case ACTION_ABORT:
> return sequencer_rollback(the_repository, opts);
> - if (cmd == 's')
> + case ACTION_SKIP:
> return sequencer_skip(the_repository, opts);
> - return sequencer_pick_revisions(the_repository, opts);
> + case ACTION_START:
> + return sequencer_pick_revisions(the_repository, opts);
> + }
> }
This change broke the build when merged to 'seen' like so ...
builtin/revert.c: In function 'run_sequencer':
builtin/revert.c:242:1: error: control reaches end of non-void function [-Werror=return-typ ]
242 | }
| ^
... so I'm discarding
it out of my tree and redoing today's integration cycle.
Different compilers are smart in different ways, and we shouldn't
overly rely on the fact that some compilers may be happy by seeing a
switch that has all the enum values and notice that one of the return
will be triggered in its case arms.
^ permalink raw reply
* Re: [RFC PATCH] `log --merge` also for rebase/cherry pick/revert
From: Junio C Hamano @ 2024-01-12 0:15 UTC (permalink / raw)
To: Michael Lohmann; +Cc: git, phillip.wood123, Elijah Newren
In-Reply-To: <20240111233311.64734-1-mi.al.lohmann@gmail.com>
Michael Lohmann <mi.al.lohmann@gmail.com> writes:
> This extends the functionality of `git log --merge` to also work with
> conflicts for rebase, cherry pick and revert.
>
> Signed-off-by: Michael Lohmann <mi.al.lohmann@gmail.com>
> ---
> ... It is basically the counterpart to
> `git show ${ACTION}_HEAD` for understanding the source of the conflict.
I do not know about the validity of that approach to use *_HEAD, but
we may want to tighten the original's use of repo_get_oid() here ...
> - if (repo_get_oid(the_repository, "MERGE_HEAD", &oid))
> - die("--merge without MERGE_HEAD?");
> - other = lookup_commit_or_die(&oid, "MERGE_HEAD");
... so that we won't be confused in a repository that has a tag
whose name happens to be MERGE_HEAD. We probably should be using
refs.c:refs_resolve_ref_unsafe() instead to
(1) ensure MERGE_HEAD is a ref,
(2) obtain the oid without any prefixing by refs.c:repo_dwim_ref(),
and optionally
(3) error out when MERGE_HEAD is a symref.
As your patch makes the problem even worse, if we were to do such a
tightening (and I do not see a reason not to), it may want to be
done before, not after, this patch.
I won't comment on the coding style violations in the patch below in
this message.
Thanks.
> diff --git a/revision.c b/revision.c
> index 2424c9bd67..2e5c00dabd 100644
> --- a/revision.c
> +++ b/revision.c
> @@ -1961,23 +1961,37 @@ static void add_pending_commit_list(struct rev_info *revs,
> }
> }
>
> +static char* get_action_head_name(struct object_id* oid)
> +{
> + if (!repo_get_oid(the_repository, "MERGE_HEAD", oid)) {
> + return "MERGE_HEAD";
> + } else if (!repo_get_oid(the_repository, "REBASE_HEAD", oid)) {
> + return "REBASE_HEAD";
> + } else if (!repo_get_oid(the_repository, "CHERRY_PICK_HEAD", oid)) {
> + return "CHERRY_PICK_HEAD";
> + } else if (!repo_get_oid(the_repository, "REVERT_HEAD", oid)) {
> + return "REVERT_HEAD";
> + } else
> + die("--merge without MERGE_HEAD, REBASE_HEAD, CHERRY_PICK_HEAD or REVERT_HEAD?");
> +}
> +
> static void prepare_show_merge(struct rev_info *revs)
> {
> struct commit_list *bases;
> struct commit *head, *other;
> struct object_id oid;
> const char **prune = NULL;
> + const char *action_head_name;
> int i, prune_num = 1; /* counting terminating NULL */
> struct index_state *istate = revs->repo->index;
>
> if (repo_get_oid(the_repository, "HEAD", &oid))
> die("--merge without HEAD?");
> head = lookup_commit_or_die(&oid, "HEAD");
> - if (repo_get_oid(the_repository, "MERGE_HEAD", &oid))
> - die("--merge without MERGE_HEAD?");
> - other = lookup_commit_or_die(&oid, "MERGE_HEAD");
> + action_head_name = get_action_head_name(&oid);
> + other = lookup_commit_or_die(&oid, action_head_name);
> add_pending_object(revs, &head->object, "HEAD");
> - add_pending_object(revs, &other->object, "MERGE_HEAD");
> + add_pending_object(revs, &other->object, action_head_name);
> bases = repo_get_merge_bases(the_repository, head, other);
> add_rev_cmdline_list(revs, bases, REV_CMD_MERGE_BASE, UNINTERESTING | BOTTOM);
> add_pending_commit_list(revs, bases, UNINTERESTING | BOTTOM);
^ permalink raw reply
* Re: [DISCUSS] Introducing Rust into the Git project
From: Trevor Gross @ 2024-01-11 23:53 UTC (permalink / raw)
To: Taylor Blau; +Cc: git
In-Reply-To: <ZZ77NQkSuiRxRDwt@nand.local>
On Wed, Jan 10, 2024 at 3:19 PM Taylor Blau <me@ttaylorr.com> wrote:
>
> Over the holiday break at the end of last year I spent some time
> thinking on what it would take to introduce Rust into the Git project.
>
> There is significant work underway to introduce Rust into the Linux
> kernel (see [1], [2]). Among their stated goals, I think there are a few
> which could be potentially relevant to the Git project:
>
> - Lower risk of memory safety bugs, data races, memory leaks, etc.
> thanks to the language's safety guarantees.
>
> - Easier to gain confidence when refactoring or introducing new code
> in Rust (assuming little to no use of the language's `unsafe`
> feature).
>
> - Contributing to Git becomes easier and accessible to a broader group
> of programmers by relying on a more modern language.
>
> Given the allure of these benefits, I think it's at least worth
> considering and discussing how Rust might make its way into Junio's
> tree.
>
> I imagine that the transition state would involve some parts of the
> project being built in C and calling into Rust code via FFI (and perhaps
> vice-versa, with Rust code calling back into the existing C codebase).
> Luckily for us, Rust's FFI provides a zero-cost abstraction [3], meaning
> there is no performance impact when calling code from one language in
> the other.
>
> Some open questions from me, at least to get the discussion going are:
>
> 1. Platform support. The Rust compiler (rustc) does not enjoy the same
> widespread availability that C compilers do. For instance, I
> suspect that NonStop, AIX, Solaris, among others may not be
> supported.
>
> One possible alternative is to have those platforms use a Rust
> front-end for a compiler that they do support. The gccrs [4]
> project would allow us to compile Rust anywhere where GCC is
> available. The rustc_codegen_gcc [5] project uses GCC's libgccjit
> API to target GCC from rustc itself.
>
> 2. Migration. What parts of Git are easiest to convert to Rust? My
> hunch is that the answer is any stand-alone libraries, like
> strbuf.h. I'm not sure how we should identify these, though, and in
> what order we would want to move them over.
>
> 3. Interaction with the lib-ification effort. There is lots of work
> going on in an effort to lib-ify much of the Git codebase done by
> Google. I'm not sure how this would interact with that effort, but
> we should make sure that one isn't a blocker for the other.
>
> I'm curious to hear what others think about this. I think that this
> would be an exciting and worthwhile direction for the project. Let's
> see!
>
> Thanks,
> Taylor
>
> [1]: https://rust-for-linux.com/
> [2]: https://lore.kernel.org/rust-for-linux/20210414184604.23473-1-ojeda@kernel.org/
> [3]: https://blog.rust-lang.org/2015/04/24/Rust-Once-Run-Everywhere.html#c-talking-to-rust
> [4]: https://github.com/Rust-GCC/gccrs
> [5]: https://github.com/rust-lang/rustc_codegen_gcc
>
Two good reference codebases out there:
Abstractions over libgit2
Repo: https://github.com/rust-lang/git2-rs
Docs: https://docs.rs/git2/latest/git2/
gix, a WIP reimplementation of git. This is far from complete but does
a lot of threading / async to apparently get quite fast.
Repo: https://github.com/Byron/gitoxide
Docs: https://docs.rs/gix/latest/gix/
If the git project does decide to go forward with this, there is
probably a lot of completed work that can be pulled from either of
those sources.
^ permalink raw reply
* Re: [DISCUSS] Introducing Rust into the Git project
From: brian m. carlson @ 2024-01-11 23:48 UTC (permalink / raw)
To: Sam James; +Cc: me, git
In-Reply-To: <87v880m6r3.fsf@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]
On 2024-01-11 at 11:45:07, Sam James wrote:
> Something I'm a bit concerned about is that right now, neither
> rustc_codegen_gcc nor gccrs are ready for use here.
>
> We've had trouble getting things wired up for rustc_codegen_gcc
> - which is not to speak against their wonderful efforts - because
> the Rust community hasn't yet figured out how to handle things which
> pure rustc supports yet. See
> e.g. https://github.com/rust-lang/libc/pull/3032.
Is this simply library support in the libc crate? That's very easy to add.
> I think care should be taken in citing rustc_codegen_gcc and gccrs
> as options for alternative platforms for now. They will hopefully
> be great options in the future, but they aren't today, and they probably
> won't be in the next 6 months at the least.
What specifically is missing for rust_codegen_gcc? I know gccrs is not
ready at the moment, but I was under the impression that
rust_codegen_gcc was at least usable. I'm aware it requires some
patches to GCC, but distros should be able to carry those.
If rust_codegen_gcc isn't viable, then I agree we should avoid making
Rust mandatory, but I'd like to learn more.
--
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* [RFC PATCH] `log --merge` also for rebase/cherry pick/revert
From: Michael Lohmann @ 2024-01-11 23:33 UTC (permalink / raw)
To: git; +Cc: Michael Lohmann, phillip.wood123
This extends the functionality of `git log --merge` to also work with
conflicts for rebase, cherry pick and revert.
Signed-off-by: Michael Lohmann <mi.al.lohmann@gmail.com>
---
Hi everybody!
When Phillip Wood gave me some nice hints on his workflow concerning
conflicts [1] (we discussed if `--show-current-patch` would make sense
for cherry pick/revert). When I learned about `git log --merge` I was a
bit sad to discover that those do not exist for rebase/revert/cherry
pick since they look really valuable for getting an understanding on
what was changed. It is basically the counterpart to
`git show ${ACTION}_HEAD` for understanding the source of the conflict.
I am curious if also other people would be interested in having an easy
way to get a log of only the relevant commits touching conflicting files
for said actions.
With this patch I think the functionality is there, just hijacking the
`--merge` code - maybe an alias like `git log --conflict` or similar
might be more descriptive now?
What do you think about this idea? (Or am I maybe missing an easy way to
achieve it with the existing code as well?)
Michael
[1] https://lore.kernel.org/git/cfba7098-3c23-4a81-933c-b7fefdedec8a@gmail.com/
revision.c | 22 ++++++++++++++++++----
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/revision.c b/revision.c
index 2424c9bd67..2e5c00dabd 100644
--- a/revision.c
+++ b/revision.c
@@ -1961,23 +1961,37 @@ static void add_pending_commit_list(struct rev_info *revs,
}
}
+static char* get_action_head_name(struct object_id* oid)
+{
+ if (!repo_get_oid(the_repository, "MERGE_HEAD", oid)) {
+ return "MERGE_HEAD";
+ } else if (!repo_get_oid(the_repository, "REBASE_HEAD", oid)) {
+ return "REBASE_HEAD";
+ } else if (!repo_get_oid(the_repository, "CHERRY_PICK_HEAD", oid)) {
+ return "CHERRY_PICK_HEAD";
+ } else if (!repo_get_oid(the_repository, "REVERT_HEAD", oid)) {
+ return "REVERT_HEAD";
+ } else
+ die("--merge without MERGE_HEAD, REBASE_HEAD, CHERRY_PICK_HEAD or REVERT_HEAD?");
+}
+
static void prepare_show_merge(struct rev_info *revs)
{
struct commit_list *bases;
struct commit *head, *other;
struct object_id oid;
const char **prune = NULL;
+ const char *action_head_name;
int i, prune_num = 1; /* counting terminating NULL */
struct index_state *istate = revs->repo->index;
if (repo_get_oid(the_repository, "HEAD", &oid))
die("--merge without HEAD?");
head = lookup_commit_or_die(&oid, "HEAD");
- if (repo_get_oid(the_repository, "MERGE_HEAD", &oid))
- die("--merge without MERGE_HEAD?");
- other = lookup_commit_or_die(&oid, "MERGE_HEAD");
+ action_head_name = get_action_head_name(&oid);
+ other = lookup_commit_or_die(&oid, action_head_name);
add_pending_object(revs, &head->object, "HEAD");
- add_pending_object(revs, &other->object, "MERGE_HEAD");
+ add_pending_object(revs, &other->object, action_head_name);
bases = repo_get_merge_bases(the_repository, head, other);
add_rev_cmdline_list(revs, bases, REV_CMD_MERGE_BASE, UNINTERESTING | BOTTOM);
add_pending_commit_list(revs, bases, UNINTERESTING | BOTTOM);
--
2.39.3 (Apple Git-145)
^ permalink raw reply related
* Re: [DISCUSS] Introducing Rust into the Git project
From: Trevor Gross @ 2024-01-11 23:23 UTC (permalink / raw)
To: rsbecker; +Cc: brian m. carlson, Taylor Blau, Junio C Hamano, Dragan Simic, git
In-Reply-To: <01c101da44d5$175f1100$461d3300$@nexbridge.com>
On Thu, Jan 11, 2024 at 4:28 PM <rsbecker@nexbridge.com> wrote:
>
> The usable compilers and interpreters on NonStop are c89, c99 (what we use for git), c11, perl, and python3 (for the x86 only). The perl and python do not have sufficient modules to do what would be needed by git. The compilers are invoked using a CLI and are not callable using a library. gcc is, for all intents and purposes, not possible - so anything requiring gcc (for example, Rust), cannot be built. There is no back-end pluggable component for any of the compilers.
>
Ah, no pluggable backend is unfortunate. Rust only uses GCC to build
the LLVM backend, it isn't actually needed for the language. It does
link libgcc_s for unwinding and I believe some math symbols, but
unwinding can be disabled and other symbols can come from anywhere.
If you can build mrustc (C++ program) [1] then you can use it to
transpile Rust to C. This is how rustc is bootstrapped, and would be
how you bring it up with a different backend on a new platform.
Still, this probably wouldn't be a solution for git.
[1]: https://github.com/thepowersgang/mrustc
^ permalink raw reply
* Re: [PATCH] diffcore-delta: avoid ignoring final 'line' of file
From: Junio C Hamano @ 2024-01-11 23:00 UTC (permalink / raw)
To: Elijah Newren via GitGitGadget; +Cc: git, Elijah Newren
In-Reply-To: <pull.1637.git.1705006074626.gitgitgadget@gmail.com>
"Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com> writes:
> diff --git a/diffcore-delta.c b/diffcore-delta.c
> index c30b56e983b..7136c3dd203 100644
> --- a/diffcore-delta.c
> +++ b/diffcore-delta.c
> @@ -159,6 +159,10 @@ static struct spanhash_top *hash_chars(struct repository *r,
> n = 0;
> accum1 = accum2 = 0;
> }
> + if (n > 0) {
> + hashval = (accum1 + accum2 * 0x61) % HASHBASE;
> + hash = add_spanhash(hash, hashval, n);
> + }
OK, so we were ignoring the final short bit that is not terminated
with LF due to the "continue". Nicely found.
> diff --git a/t/t4001-diff-rename.sh b/t/t4001-diff-rename.sh
> index 85be1367de6..29299acbce7 100755
> --- a/t/t4001-diff-rename.sh
> +++ b/t/t4001-diff-rename.sh
> @@ -286,4 +286,23 @@ test_expect_success 'basename similarity vs best similarity' '
> test_cmp expected actual
> '
>
> +test_expect_success 'last line matters too' '
> + test_write_lines a 0 1 2 3 4 5 6 7 8 9 >nonewline &&
> + printf "git ignores final up to 63 characters if not newline terminated" >>nonewline &&
> + git add nonewline &&
> + git commit -m "original version of file with no final newline" &&
I found it misleading that the file whose name is nonewline has
bunch of LF including on its last line ;-).
> + # Change ONLY the first character of the whole file
> + test_write_lines b 0 1 2 3 4 5 6 7 8 9 >nonewline &&
Same here, but it is too much to bother rewriting it ...
{
test_write_lines ...
printf ...
} >incomplete
... like so ("incomplete" stands for "file ending with an incomplete line"),
so I'll let it pass.
> + printf "git ignores final up to 63 characters if not newline terminated" >>nonewline &&
> + git add nonewline &&
> + git mv nonewline still-no-newline &&
> + git commit -a -m "rename nonewline -> still-no-newline" &&
> + git diff-tree -r -M01 --name-status HEAD^ HEAD >actual &&
> + cat >expected <<-\EOF &&
> + R097 nonewline still-no-newline
I am not very happy with the hardcoded 97. You are already using
the non-standard 10% threshold. If the delta detection that
forgets about the last line is so broken as your proposed log
message noted, shouldn't you be able to construct a sample pair of
preimage and postimage for which the broken version gives so low
similarity to be judged not worth treating as a rename, while the
fixed version gives reasonable similarity to be made into a rename,
by the default threshold? That way, the test only needs to see if
we got a rename (with any similarity) or a delete and an add.
^ permalink raw reply
* Re: [PATCH] push: improve consistency of output when "up to date"
From: Junio C Hamano @ 2024-01-11 22:33 UTC (permalink / raw)
To: Eric Sunshine; +Cc: Benji Kay via GitGitGadget, git, Benji Kay
In-Reply-To: <CAPig+cRr0V2ecnmxk1H_yF24dwSFA6niPxYXGH0MZ+wGP9m9UA@mail.gmail.com>
Eric Sunshine <sunshine@sunshineco.com> writes:
> Thanks. This particular change is proposed periodically...
>
>> diff --git a/transport.c b/transport.c
>> @@ -1467,7 +1467,7 @@ int transport_push(struct repository *r,
>> else if (!quiet && !ret && !transport_refs_pushed(remote_refs))
>> - fprintf(stderr, "Everything up-to-date\n");
>> + fprintf(stderr, "Everything up to date.\n");
>
> ... but has not been considered desirable.
>
> See, for instance, this email thread explaining the rationale for
> avoiding such a change:
> https://lore.kernel.org/git/pull.1298.git.1658908927714.gitgitgadget@gmail.com/T/
Looking at the "grep" hits:
$ git grep -e 'up-to-date.*"' \*.c
builtin/rm.c: OPT__FORCE(&force, N_("override the up-to-date check"), PARSE_OPT_NOCOMPLETE),
builtin/send-pack.c: fprintf(stderr, "Everything up-to-date\n");
http-push.c: fprintf(stderr, "'%s': up-to-date\n", ref->name);
http-push.c: "Maybe you are not up-to-date and "
transport.c: fprintf(stderr, "Everything up-to-date\n");
it is true that these are not marked for translation, which should
be a clue enough that we want them to be exactly the way they are
spelled. However, they are going to the standard error stream. Is
it reasonable to expect third-party tools scraping it to find the
string "up-to-date"?
In any case, a safe first step is to add a short comment to each of
these that should not be translated. Perhaps something along this
line.
------- >8 ------------- >8 ------------- >8 -------
Subject: [PATCH] messages: mark some strings with "up-to-date" not to touch
The treewide clean-up of "up-to-date" strings done in 7560f547
(treewide: correct several "up-to-date" to "up to date", 2017-08-23)
deliberately left some out, but unlike the lines that were changed
by the commit, the lines that were deliberately left untouched by
the commit is impossible to ask "git blame" to link back to the
commit that did not touch them.
Let's do the second best thing, leave a short comment near them, to
make it possible for those who are motivated enough to find out why
we decided to tell them "do not modify".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin/send-pack.c | 1 +
http-push.c | 2 ++
transport.c | 1 +
3 files changed, 4 insertions(+)
diff --git a/builtin/send-pack.c b/builtin/send-pack.c
index b7183be970..ac7ec1e643 100644
--- a/builtin/send-pack.c
+++ b/builtin/send-pack.c
@@ -333,6 +333,7 @@ int cmd_send_pack(int argc, const char **argv, const char *prefix)
}
if (!ret && !transport_refs_pushed(remote_refs))
+ /* do not modify this string */
fprintf(stderr, "Everything up-to-date\n");
return ret;
diff --git a/http-push.c b/http-push.c
index b4d0b2a6aa..e4c6645cc2 100644
--- a/http-push.c
+++ b/http-push.c
@@ -1851,6 +1851,7 @@ int cmd_main(int argc, const char **argv)
if (oideq(&ref->old_oid, &ref->peer_ref->new_oid)) {
if (push_verbosely)
+ /* do not modify this string */
fprintf(stderr, "'%s': up-to-date\n", ref->name);
if (helper_status)
printf("ok %s up to date\n", ref->name);
@@ -1871,6 +1872,7 @@ int cmd_main(int argc, const char **argv)
* commits at the remote end and likely
* we were not up to date to begin with.
*/
+ /* do not modify this string */
error("remote '%s' is not an ancestor of\n"
"local '%s'.\n"
"Maybe you are not up-to-date and "
diff --git a/transport.c b/transport.c
index bd7899e9bf..c9f39d45f1 100644
--- a/transport.c
+++ b/transport.c
@@ -1467,6 +1467,7 @@ int transport_push(struct repository *r,
if (porcelain && !push_ret)
puts("Done");
else if (!quiet && !ret && !transport_refs_pushed(remote_refs))
+ /* do not modify this string */
fprintf(stderr, "Everything up-to-date\n");
done:
--
2.43.0-283-ga54a84b333
^ permalink raw reply related
* Re: [PATCH v3] builtin/revert.c: refactor using an enum for cmd-action
From: Junio C Hamano @ 2024-01-11 21:47 UTC (permalink / raw)
To: Michael Lohmann; +Cc: git, phillip.wood123, phillip.wood, wanja.hentze
In-Reply-To: <20240111200627.64199-1-mi.al.lohmann@gmail.com>
Michael Lohmann <mi.al.lohmann@gmail.com> writes:
> This is done to avoid having to keep the char values in sync in
> different places and also to get compiler warnings on non-exhaustive
> switches.
>
> In the rebase `action` enum there is the enumeration constant
> `ACTION_NONE` which is not particularly descriptive, since it seems to
> imply that no action should be taken. Instead it signals a start of a
> revert/cherry-pick process, so here `ACTION_START` was chosen.
>
> Co-authored-by: Wanja Henze <wanja.hentze@bevuta.com>
> Signed-off-by: Michael Lohmann <mi.al.lohmann@gmail.com>
> ---
>
> On 11. Jan 2024, at 20:37, Junio C Hamano <gitster@pobox.com> wrote:
>> Phillip Wood <phillip.wood123@gmail.com> writes:
>> > I think ACTION_NONE was intended to covey that the user did not pass
>> > one of the OPT_CMDMODE() options like "--continue" as there isn't a
>> > "--start" option. I don't have a strong opinion between "_NONE" and
>> > "_START".
>>
>> I agree with you why NONE is called as such. If "revert" does not
>> take "--start" (I do not remember offhand), I would think it would
>> be better to follow suit.
> My point was that yes, it might be in sync with what the user passes in
> as arguments, but when I followed the code and saw lots of references to
> ACTION_NONE I was puzzled, since my intuition of that name was that
> _no action_ should be taken (which did not make sense to me).
I know you wrote that ;-). But _NONE is "no action was specified",
and has been so for a long time in the context of "rebase". I do not
see any confusion expressed there. I do not expect to see any
confusion here, either, if we were to introduce these new enum.
^ permalink raw reply
* Re: Add support for `git rebase -no-edit`
From: Chaitanya Tata @ 2024-01-11 21:46 UTC (permalink / raw)
To: Taylor Blau; +Cc: Junio C Hamano, git
In-Reply-To: <ZaBgqlR5F1dv9ttg@nand.local>
On Fri, Jan 12, 2024 at 3:12 AM Taylor Blau <me@ttaylorr.com> wrote:
>
> On Thu, Jan 11, 2024 at 01:30:55PM -0800, Junio C Hamano wrote:
> > Chaitanya Tata <chaitanya.tk17@gmail.com> writes:
> >
> > > Hi,
> > >
> > > I have a feature request to add `--no-edit` option to `git rebase`
> > > like we do for `git commit`.
> > > The workflow I typically follow is:
> > >
> > > * `git commit -a --fixup=XXX`
> > > * `git rebase -i HEAD~15 --autosquash`
> > >
> > > But it requires closing the editor without any changes. I can
> > > workaround this using the `GIT_EDITOR` option, see [1]. But it would
> > > be good to have this built-in.
> > >
> > > Thoughts?
> >
> > With what is in the 'master' branch, you do not have to say
> > interactive when you do not want to go interactive. I.e.
> >
> > $ git rebase --autosquash HEAD~15
> >
> > should work fine. Building Git from the source should not be too
> > hard.
Amazing, exactly what I need. And or arg order, I just typed in the command,
I typically use aliases that are in the proper order, but thanks.
>
> Oh, duh. Indeed, 297be59456 (rebase: support --autosquash without -i,
> 2023-11-14) will do what Chaitanya is looking for. I'll give myself pass
> on remembering that patch since it is from last year ;-).
:).
Thanks both for prompt support, I will compile and test this.
^ permalink raw reply
* Re: [PATCH] push: improve consistency of output when "up to date"
From: Eric Sunshine @ 2024-01-11 21:45 UTC (permalink / raw)
To: Taylor Blau; +Cc: Benji Kay via GitGitGadget, git, Benji Kay
In-Reply-To: <ZaBhHSCT7EOgTo/N@nand.local>
On Thu, Jan 11, 2024 at 4:44 PM Taylor Blau <me@ttaylorr.com> wrote:
> On Thu, Jan 11, 2024 at 09:27:29PM +0000, Benji Kay via GitGitGadget wrote:
> > - fprintf(stderr, "Everything up-to-date\n");
> > + fprintf(stderr, "Everything up to date.\n");
>
> Between the two, I have a vague preference towards "up-to-date", which
> would suggest changing the pull command's output to read "Already
> up-to-date". Personally I think that neither of them should include a
> period in their output, but whichever we decide should be done so
> consistently between the two.
>
> Also, should this string be marked for translation?
See: https://lore.kernel.org/git/7n9r5q74-9qr1-29sr-p2n5-943n01s0p78r@tzk.qr/
^ permalink raw reply
* Re: [PATCH] diffcore-delta: avoid ignoring final 'line' of file
From: Taylor Blau @ 2024-01-11 21:45 UTC (permalink / raw)
To: Elijah Newren via GitGitGadget; +Cc: git, Elijah Newren
In-Reply-To: <pull.1637.git.1705006074626.gitgitgadget@gmail.com>
On Thu, Jan 11, 2024 at 08:47:54PM +0000, Elijah Newren via GitGitGadget wrote:
> ---
> diffcore-delta.c | 4 ++++
> t/t4001-diff-rename.sh | 19 +++++++++++++++++++
> 2 files changed, 23 insertions(+)
Nice find and fix. This patch LGTM.
Thanks,
Taylor
^ permalink raw reply
* Re: [PATCH] push: improve consistency of output when "up to date"
From: Taylor Blau @ 2024-01-11 21:43 UTC (permalink / raw)
To: Benji Kay via GitGitGadget; +Cc: git, Benji Kay
In-Reply-To: <pull.1638.git.1705008449995.gitgitgadget@gmail.com>
On Thu, Jan 11, 2024 at 09:27:29PM +0000, Benji Kay via GitGitGadget wrote:
> From: okaybenji <okaybenji@gmail.com>
>
> When one issues the pull command, one may see "Already up to date."
> When issuing the push command, one may have seen "Everything up-to-date".
> To improve consistency, "Everything up to date." is printed instead.
> (The hyphens have been removed, and a period has been added.)
>
> Signed-off-by: okaybenji <okaybenji@gmail.com>
> ---
> push: improve consistency of output when "up to date"
>
> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1638%2Fokaybenji%2Fup-to-date-v1
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1638/okaybenji/up-to-date-v1
> Pull-Request: https://github.com/gitgitgadget/git/pull/1638
>
> transport.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/transport.c b/transport.c
> index bd7899e9bf5..c42cb4e58b4 100644
> --- a/transport.c
> +++ b/transport.c
> @@ -1467,7 +1467,7 @@ int transport_push(struct repository *r,
> if (porcelain && !push_ret)
> puts("Done");
> else if (!quiet && !ret && !transport_refs_pushed(remote_refs))
> - fprintf(stderr, "Everything up-to-date\n");
> + fprintf(stderr, "Everything up to date.\n");
Between the two, I have a vague preference towards "up-to-date", which
would suggest changing the pull command's output to read "Already
up-to-date". Personally I think that neither of them should include a
period in their output, but whichever we decide should be done so
consistently between the two.
Also, should this string be marked for translation?
Thanks,
Taylor
^ permalink raw reply
* Re: [PATCH] push: improve consistency of output when "up to date"
From: Eric Sunshine @ 2024-01-11 21:43 UTC (permalink / raw)
To: Benji Kay via GitGitGadget; +Cc: git, Benji Kay
In-Reply-To: <pull.1638.git.1705008449995.gitgitgadget@gmail.com>
On Thu, Jan 11, 2024 at 4:27 PM Benji Kay via GitGitGadget
<gitgitgadget@gmail.com> wrote:
> When one issues the pull command, one may see "Already up to date."
> When issuing the push command, one may have seen "Everything up-to-date".
> To improve consistency, "Everything up to date." is printed instead.
> (The hyphens have been removed, and a period has been added.)
>
> Signed-off-by: okaybenji <okaybenji@gmail.com>
Thanks. This particular change is proposed periodically...
> diff --git a/transport.c b/transport.c
> @@ -1467,7 +1467,7 @@ int transport_push(struct repository *r,
> else if (!quiet && !ret && !transport_refs_pushed(remote_refs))
> - fprintf(stderr, "Everything up-to-date\n");
> + fprintf(stderr, "Everything up to date.\n");
... but has not been considered desirable.
See, for instance, this email thread explaining the rationale for
avoiding such a change:
https://lore.kernel.org/git/pull.1298.git.1658908927714.gitgitgadget@gmail.com/T/
^ permalink raw reply
* would these doc and completion patches like this welcome?
From: Britton Kerin @ 2024-01-11 21:42 UTC (permalink / raw)
To: git
Someone mentioned that there were other places where <path> should be
<pathspec> and I looked through the docs a bit to see, and also noted
simple completion fixes.
There were a number of small issues I saw that I'll fix if there's
interest but I want to ask before spending time (I have a few patches
submitted at the moment and can't tell if they are unwelcome or what).
To give an idea what I have in mind the rough notes I made on a first
pass through are below. Note that I haven't got as far as verifying
for sure e.g. what actually takes a pathspec so there may be mistakes
in here.
The question now is is there enough interest that I should proceed or not?
Here's the list:
git-am:
doc: --exclude and --include probably take <pathspec>, but currently refer
to <path>. Note: Underlying git-apply currently says <path-pattern> in
detailed description, <path> in synopsis
doc: --directory=<dir> in synopsis and detailed description but should
probably be <root> since the detailed description in git-am just says
that "These flags are passed to the git apply"
comp: --directory= takes and should complete a dir
git-archive:
doc: is <path> argument really a <path> or should it be <pathspec>?
git-bisect:
doc: mentions of path in main text should be <pathspec> (assuming
guy on mailing list who said it actually takes a <pathspec> was right,
check)
git-clone:
doc: <directory> or <dir>? who cares I think but elsewhere some use <dir>
<dir>
comp: <directory> should be completed
comp: <git-dir> should be completed
git-describe:
doc: synopsis mentions <blob> but later text just mentions blob, I think this
is not how other tools mention such things
git-diff:
doc: are all the mentions of <path> really <path> or should they be
<pathspec>?
doc: is optional arg to --relative really a <path>, or is it a <pathspec>?
comp: there are lots of options that aren't completed that should be
comp: NOTE: <path> should not get completed as dir even if they aren't
<pathspec> since they might be files
comp: NOTE: the optional arg to --relative should not be completed as an
actual dir
git-format-patch:
doc: is optional arg to --relative really a <path>, or is it a <pathspec>?
doc: what is <boundary>?
doc: --from in main text but not synopsis
comp: --to --cc --from don't have optarg completion help for format-patch
as they do for send-email. I notice that according to it's
--git-completion-helper output format-patch doesn't implement --bcc
hmnm is that really true so weird
comp: NOTE: the optional arg to --relative should not be completed as an
actual dir
git-init:
doc: has both [--template=<template-directory>] and
[--separate-git-dir <git-dir>], I see no reason one of these should get
an = and the other not, seems like both should get = and that's how this
command does it though other git commands seem to doc differently
doc: <directory> is mentioned in synopsis but only underlined directory in
body. elsewhere in same file words like this do get their <> and are
underlined also. what is the
actual git way for this? Just underline? Underline and <> (seems
right to me?) Underline seems to be the common utility way (for ls, cp,
ln at least which I checked, but those don't use <> everywhere. I
guess I sort of think it should be one or the other not both and git
uses <> everywhere for args and optargs. FIXME: sheesh I can't quit
tell when bold is even getting used in my terminal font it's similar
enough but actuall bold and <> seems pretty common as well
comp: arg to --template should be completed as a dir
comp: arg to --separate-git-dir should be completed as a dir
comp: the optional [<directory>] arg appears to be the only possible
non-option argument and so should be easy to complete as a dir
git-log:
doc: synopsis says <path>... probably it means <pathspec>... check
doc: full text also mentions <paths> in a number of places, it should
probably by <pathspec>... but at least <path>... (or sometimes just
<pathspec> or <path>)
doc: is optional arg to --relative really a <path>, or is it a <pathspec>?
comp: NOTE: the optional arg to --relative should not be completed as an
actual dir
git-pull:
doc: one option description reads '--squash, --no-squash' while another reads
'--[no-]verify'. I think I like the first way better for easy search
but I think the second might be more common. Find out the preferred
way and make consistent.
git-range-diff:
doc: refers to <path> where it likely means pathspec. highlights <path>
but doesn't underline
git-reset:
doc: says 'can copy the contents of a path out of a commit' I believe it
really means 'contents of a pathspec' but that's so clunky to read
and understand and so much less likely to be what someone is attempting
if they're doing the already somewhat exatic thing described that it's
probably better to just keep on being wrong here.
git-shortlog:
doc: refers to <path> but should probably be <pathspec>
doc: is optional arg to --relative really a <path>, or is it a <pathspec>?
comp: NOTE: the optional arg to --relative should not be completed as an
actual dir
doc: mentions <paths> in one place ('as the <paths>' should be 'as a <path>')
refers to <path> but should probably be <pathspec>
git-submodule:
doc: <path> all over the place but then the text mentions <pathspec> in one
place that looks representative so probably they should all be
<pathspec>
doc: describes <path> (an optional argument) under options
git-worktree:
doc: NOTE: I don't think these should be doced as <pathspec> regardless of
what the actual code takes. Out of curiosity what does actual code
take?
comp: repair subcommand: <path> should be completed to a real dir in this
case
gitk:
doc: says <path> probably means <pathspec>
git-config:
doc: <file-option> appears in synopsis but isn't mentioned in text
git-reflog:
doc: takes <log-options>, argubly should be <log-option>...
git-repack:
comp: --expire-to=<dir> should complete dirs
comp: --filter-to=<dir> should complete dirs
git-bugreport:
doc: in general (not just for this command) should opts that need a path
that's a dir always call it <dir> rather than <path>?
comp: completion needs implemented
comp: -o/--ouput-directory should complete dirs
git-diagnose:
comp: completion needs implemented
comp: -o/--ouput-directory should complete dirs
git-difftool:
comp: there are lots of options that need completion added for underlying
git-diff. For some reason git difftool --git-completion-help doesn't
pull in the git-diff options (unlike send-email does format-patch
options) perhaps this could be fixed?. Or the git-diff options could
be factored into a function so they can be used for both _git_diff
and _git_difftool
git-merge-tree:
doc: --stdin appears pretty significant, but doesn't have an entry of it's
own in the OPTIONS section
comp: not implemented at all yet
git-archimport:
comp: not implemented, probably not worth it
git-cvsexportcommit:
comp: not implemented, probably not worth it
git-cvsserver:
comp: not implemented, probably not worth it
git-quiltimport:
doc: --patches=<dir> might be better than --patches <dir>, how to handle this
in general?
comp: not implemented yet
comp: --patches should complete dirs
git-send-email:
doc: send-email docs --to --from --cc with different docs than the
corresponding format-patch options. Are they not just passed through in
the case where format-patch is being done implicitly? Do they override
for an already-prepared patch series? Hmm
comp: all long opts of send-email and format-patch are accepted via
the --git-completion-helper mechanism. Unfortunately this means all
git-format-patch opts are accepted even when --no-format-patch has been
given. Both commands support --git-completion-helper so in theory
the wrong option set could be filtered back out. It's not possible
to do this from the arg since it probably isn't there yet and might
be ambiguous anyway
* there are at least some opts for which optargs aren't completed:
comp: should --reply-to be completed like --to=*|--cc=*|--bcc=*|--from=* are?
comp: should --envelope-sender be completed like
--to=*|--cc=*|--bcc=*|--from=* are?
comp: optarg to --smtp-encryption could be completed
comp: optarg to --transfer-encoding could be be completed
comp: optarg to --smtp-debug could be be completed
^ permalink raw reply
* Re: Add support for `git rebase -no-edit`
From: Taylor Blau @ 2024-01-11 21:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Chaitanya Tata, git
In-Reply-To: <xmqq4jfjftgw.fsf@gitster.g>
On Thu, Jan 11, 2024 at 01:30:55PM -0800, Junio C Hamano wrote:
> Chaitanya Tata <chaitanya.tk17@gmail.com> writes:
>
> > Hi,
> >
> > I have a feature request to add `--no-edit` option to `git rebase`
> > like we do for `git commit`.
> > The workflow I typically follow is:
> >
> > * `git commit -a --fixup=XXX`
> > * `git rebase -i HEAD~15 --autosquash`
> >
> > But it requires closing the editor without any changes. I can
> > workaround this using the `GIT_EDITOR` option, see [1]. But it would
> > be good to have this built-in.
> >
> > Thoughts?
>
> With what is in the 'master' branch, you do not have to say
> interactive when you do not want to go interactive. I.e.
>
> $ git rebase --autosquash HEAD~15
>
> should work fine. Building Git from the source should not be too
> hard.
Oh, duh. Indeed, 297be59456 (rebase: support --autosquash without -i,
2023-11-14) will do what Chaitanya is looking for. I'll give myself pass
on remembering that patch since it is from last year ;-).
Thanks,
Taylor
^ permalink raw reply
* Re: Add support for `git rebase -no-edit`
From: Junio C Hamano @ 2024-01-11 21:30 UTC (permalink / raw)
To: Chaitanya Tata; +Cc: git
In-Reply-To: <CADA7-FOE_81ze8hdaRGLPbipihnvFcEYfp9uwnPxPVxDepG4nA@mail.gmail.com>
Chaitanya Tata <chaitanya.tk17@gmail.com> writes:
> Hi,
>
> I have a feature request to add `--no-edit` option to `git rebase`
> like we do for `git commit`.
> The workflow I typically follow is:
>
> * `git commit -a --fixup=XXX`
> * `git rebase -i HEAD~15 --autosquash`
>
> But it requires closing the editor without any changes. I can
> workaround this using the `GIT_EDITOR` option, see [1]. But it would
> be good to have this built-in.
>
> Thoughts?
With what is in the 'master' branch, you do not have to say
interactive when you do not want to go interactive. I.e.
$ git rebase --autosquash HEAD~15
should work fine. Building Git from the source should not be too
hard.
By the way, make it a habit to pass non-option argument after dashed
options. It is easier for your readers to understand your command
line that way.
Thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox