* Re: [PATCH] t3200: clean side effect of git checkout --orphan
From: Eric Sunshine @ 2020-08-30 5:35 UTC (permalink / raw)
To: Aaron Lipman; +Cc: Git List
In-Reply-To: <20200829225648.11971-1-alipman88@gmail.com>
On Sat, Aug 29, 2020 at 6:57 PM Aaron Lipman <alipman88@gmail.com> wrote:
> The "refuse --edit-description on unborn branch for now" test in t3200
> switches to an orphan branch, causing subsequent git commands
> referencing HEAD to fail. Avoid this side-effect by switching back to
> master after that test finishes.
>
> This has gone undetected, as the next effected test expects failure -
> but it currently fails for the wrong reason.
s/effected/affected
In fact, the three tests following the orphan test all expect failure
(though I didn't check if they also fail for the wrong reason), and
the following test which doesn't expect failure has an explicit "git
checkout master" early on, which explains why it was not impacted by
this problem.
> Verbose output of the next test referencing HEAD,
> "--merged is incompatible with --no-merged":
>
> fatal: malformed object name HEAD
>
> Which this commit corrects to:
>
> error: option `no-merged' is incompatible with --merged
>
> Signed-off-by: Aaron Lipman <alipman88@gmail.com>
Description and actual fix make perfect sense.
^ permalink raw reply
* Re: [PATCH 2/5] worktree: teach "repair" to fix worktree back-links to main worktree
From: Eric Sunshine @ 2020-08-30 7:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List, Henré Botha, Jeff King
In-Reply-To: <xmqqlfi0qaru.fsf@gitster.c.googlers.com>
On Thu, Aug 27, 2020 at 1:06 PM Junio C Hamano <gitster@pobox.com> wrote:
> Eric Sunshine <sunshine@sunshineco.com> writes:
> > The .git file in a linked worktree is a "gitlink" which points back to
>
> Please never call it a "gitlink" (which is a word reserved for a
> cache entry with 160000 mode that typically point at a commit
> object, an implementation detail of the mechanism to bind a
> submodule to its superproject) to avoid confusing future readers of
> our code and documentation. The setup.c code calls it as "gitfile",
> since it was introduced at b44ebb19 (Add platform-independent .git
> "symlink", 2008-02-20), I think, and that is how it has been described
> in the glossary.
Thanks. I don't know why my brain latched onto "gitlink" even though I
noted the difference in the name read_gitfile_gently().
> > the .git/worktrees/<id> entry in the main worktree or bare repository.
> > If a worktree's .git file is deleted or becomes corrupted or outdated,
> > then the linked worktree won't know how to find the repository or any of
> > its own administrative files (such as 'index', 'HEAD', etc.). An easy
> > way for the .git file to become outdated is for the user to move the
> > main worktree or bare repository.
>
> I am not sure if a directory that used to be a secondary worktree
> would still appear to be a Git controlled worktree after its ".git"
> removed, but I guess a ".git" pointing at a wrong place won't,
> either.
The directory itself will be disconnected from its object database,
thus non-working, however, its .git/worktrees/<id> entry will still be
present, so the repository will still consider it a linked worktree.
> I am just curious how much more involved in dealing with the "is
> deleted" situation than "becomes corrupted" situation.
They are handled identically. "git worktree repair" simply visits each
.git/worktrees/<id> entry and checks if the /path/to/worktree/.git
gitfile points back to .git/worktrees/<id>. If it doesn't -- whether
because the gitfile is missing, corrupted, or simply pointing at the
wrong location -- it recreates the gitfile with the correct content.
> sequence, the user does
>
> user goes to a directory D, thinking it is a valid secondary
> worktree and wanting to work in it, and finds that Git does not
> think it is.
>
> user goes to X, which is the location of the primary copy, and
> tells "worktree repair" that the directory D ought to be the top
> of the working tree for a secondary worktree.
>
> "worktree repair" creates/updates D/.git gitfile to point at X.
>
> user comes back to D and starts working.
>
> because "git worktree repair" wants to do the usual setup sequence
> anyway.
Correct. Perhaps not 100% intuitive now that you mention it but that
sort of interface could be built atop the machinery provided by this
patch series, and I don't think this initial implementation needs to
have all the bells and whistles. Even with what is implemented by this
series, support becomes much easier -- simply ask the user to run "git
worktree repair" in the main worktree (or in any functional worktree)
-- than the situation presently which requires precise instructions
about how to patch administrative files by hand.
> > Move a working tree to a new location. Note that the main working tree
> > -or linked working trees containing submodules cannot be moved.
> > +or linked working trees containing submodules cannot be moved with this
> > +command. (The `git worktree repair` command, however, can reestablish
> > +the connection with linked working trees if you move the main working
> > +tree manually.)
>
> ... meaning after moving the main working tree, repair can be used
> to touch-up the submodule directories?
>
> Ah, no. You are saying "git worktree move" still cannot be used to
> move the main working tree (the ones with submodules in it we do not
> even care), but as a workaround, the user can "mv" it manually and
> run "repair" to fix all the secondary worktrees.
Seeing as the meaning wasn't clear upon your first reading, perhaps I
should remove this change? Or rewrite it in some way?
> Hopefully somewhere in the rest of this series it would become
> automatic? After all, instead of letting users "mv" things without
> us knowing what is going on, if we let them say "worktree move" the
> primary working tree, we know both the source and the destination
> directories of such a move, and because we know all the secondary
> worktrees, we can run "worktree repair" on them as part of this
> "worktree move" of the primary working tree.
>
> It is perfectly fine that it is not happening here in this step to
> keep each step digestible, of course.
Duy's original implementation did automatically repair worktree
administrative files but it ended up being buggy (I don't recall the
precise details) and discussion between the two of you resulted in the
functionality being removed with the possibility of resurrecting it
later. (Unfortunately, I can't find references to any of the
discussion right now.)
Automatic repair was definitely on my mind as I wrote this series, but
as something which could possibly be added later atop the machinery
implemented by this series.
> > +test_corrupt_gitlink () {
>
> See gitglossary::gitfile. We'd need to find all references to
> "gitlink" and "git link" in this series and decide which ones need
> to be fixed (there might be genuine references to gitlink---I
> haven't read the series through).
They all need to be fixed. There aren't any genuine gitlink references
in the series.
> > +static void repair_dotgit(struct worktree *wt,
> > + worktree_repair_cb *cb, void *cb_data)
>
> "dotgit" is an OK name in this context, I would think. repair_gitfile
> is also fine, but "dotgit" may be more explicit.
I think I originally called the function repair_gitlink() but changed
it to "dotgit" to be more explicit. But now that I know "gitfile" is
the correct term, repair_gitfile() seems preferable.
> > + /* missing worktree can't be repaired */
> > + if (!file_exists(wt->path))
> > + return;
>
> Shouldn't it be a bit stronger? if wt->path is not a directory, it
> cannot be the top of the working tree of a secondary worktree.
I'm not quite sure what you're asking. This code is saying that if the
path recorded in .git/worktrees/<id>/gitdir doesn't exist, then there
simply isn't anything we can repair.
> > + strbuf_realpath(&repo, git_common_path("worktrees/%s", wt->id), 1);
>
> OK, the need to use git_common_path() is a good justification why it
> is easier to implement if we initialize ourselves using the primary
> copy's repository data (i.e. require the user to start "worktree
> repair" in the primary copy or any working secondary worktrees, and
> let the normal setup.c sequence to prime us in the repository),
> instead of allowing the user to start at the secondary worktree
> whose gitfile got broken.
Yes, and this does highlight that there are conditions under which
"git worktree repair" simply won't operate. I did consider handling a
number of such conditions but ultimately decided that I'd rather keep
this initial implementation as simple and straightforward as
possible. Such improvements can be built atop.
> > + if (repair) {
> > + cb(0, wt->path, repair, cb_data);
> > + write_file(dotgit.buf, "gitdir: %s", repo.buf);
>
> Shouldn't write_file() be monitored for its failure, and the failure
> reported back to the callback function?
Yes and no. write_file() will die() if it can't write the file. That's
not necessarily ideal behavior for a command which wants to repair
_all_ problems, and the decision to use write_file() was not one I
made lightly. The bigger picture is that, although "git worktree
repair" ideally should not abort when attempting repairs, there are a
number of library functions called by "git worktree repair" which
undesirably die(). And writing all that functionality from scratch or
enhancing those functions to have "gentle" modes would have made this
series far longer and far more complex. So, I eventually decided to
keep the implementation simple, with the idea that such enhancements
can be made later as needed and as we gain experience with the
command.
> > +void repair_worktrees(worktree_repair_cb *cb, void *cb_data)
> > +{
> > + struct worktree **worktrees = get_worktrees();
> > + struct worktree **wt = worktrees + 1; /* +1 skips main worktree */
> > +
> > + if (!cb)
> > + cb = repair_noop_cb;
> > + for (; *wt; wt++)
> > + repair_dotgit(*wt, cb, cb_data);
> > + free_worktrees(worktrees);
> > +}
>
> This "repair"s only in one direction. Manual movement of secondary
> worktrees, if we want to support repairing, needs the user to tell
> where the new location of the secondary is, and we need a code to
> update the record of the location of the secondary kept at the main
> worktree, which is not needed in the repair implemented by this
> step.
Correct. Patch [3/5] implements repair in the other direction.
> Looking good.
Thanks for the thoughtful review comments (including the ones to which
I didn't respond directly -- they will be addressed by the re-roll
itself).
^ permalink raw reply
* Re: [PATCH 3/5] worktree: teach "repair" to fix outgoing links to worktrees
From: Eric Sunshine @ 2020-08-30 7:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List, Henré Botha, Jeff King
In-Reply-To: <xmqqh7soqady.fsf@gitster.c.googlers.com>
On Thu, Aug 27, 2020 at 1:14 PM Junio C Hamano <gitster@pobox.com> wrote:
> Eric Sunshine <sunshine@sunshineco.com> writes:
> > Therefore, teach "git worktree repair" how to repair broken or outdated
> > .git/worktrees/<id>/gitdir files automatically. (For this to work, the
> > command must either be invoked from within the worktree whose gitdir
> > file requires repair, or from within the main or any linked worktree by
> > providing the path of the broken worktree as an argument to "git
> > worktree repair".)
>
> Would git "work" in a corrupt worktree whose gitfile is broken, in
> the sense that it notices that the cwd is the top of the working
> tree of a secondary worktree?
No. For this repair to work, the gitfile in the linked worktree must
be intact; it must be pointing back at the .git/worktrees/<id>
directory so that "git worktree repair" can repair the corresponding
.git/worktrees/<id>/gitdir file.
Making it "work" for the case when both the worktree's gitfile is
broken and .git/worktrees/<id>/gitdir is broken would require an
enhancement like what you mentioned in your review of patch [2/5] in
which the user would manually specify the location of the main
worktree (or repository). That is something which can be added, but I
wanted to keep this initial implementation simple.
> Hmph, if the secondary is _moved_, how would "worktree repair $path"
> would know which <id> the $path corresponds to? Would we just cull
> all the <id> that do not point at working secondary worktrees and
> add the $path as if it were a new one by allocating a new <id>, or
> reusing a randomly chosen <id> that points at a non-existing
> location?
Since this can only work if the linked worktree's gitfile is intact,
and since the content of the gitfile is the path .git/worktrees/<id>,
"git worktree repair" knows the exact <id>, thus the precise
.git/worktrees/<id>/gitdir file to repair. It is deterministic; there
is no guessing about <id>, and there is no creating a new <id>
magically (though I did consider additional repair cases but opted
against them for the initial implementation).
^ permalink raw reply
* Re: [PATCH] gitdiff: Introduce --index and deprecate --cached.
From: Danielle Akers @ 2020-08-30 10:21 UTC (permalink / raw)
To: junkio; +Cc: ae, git
^ permalink raw reply
* Re: [PATCH] Avoid infinite loop in malformed packfiles
From: René Scharfe @ 2020-08-30 10:56 UTC (permalink / raw)
To: ori, gitster, peff; +Cc: git
In-Reply-To: <A1CA9D499EDDACBA275BA61E114645F0@eigenstate.org>
Am 30.08.20 um 05:33 schrieb ori@eigenstate.org:
>> Jeff King <peff@peff.net> writes:
>>
>>> It may be hard to test, as I suspect modern versions of Git are not
>>> happy to create such a deep chain. We could test with a lowered value of
>>> the config option, though.
>>
>> Yes, that was what I meant. Start from a 1KB text, create 50
>> revisions of the file by adding a single line at its end at a time,
>> pack with depth limit of 100, and then see "git log -p" die when the
>> allowed max lowered to 10, or something like that.
>
> Sorry about the delay -- most of my time to poke at this is over the weekend.
>
> Will that work? I'd expect that modern pack files end up being
> offset deltas, rather than reference deltas.
True, but going down all the way would work:
diff --git a/t/t5316-pack-delta-depth.sh b/t/t5316-pack-delta-depth.sh
index 0f06c40eb1..7fd21cd3ce 100755
--- a/t/t5316-pack-delta-depth.sh
+++ b/t/t5316-pack-delta-depth.sh
@@ -94,4 +94,15 @@ test_expect_success '--depth limits depth' '
test_i18ncmp expect actual
'
+test_expect_success 'maxAllowedDeltaDepth is respected' '
+ git clone . clone1 &&
+ (
+ cd clone1 &&
+ git repack -a -d &&
+ test_config core.maxAllowedDeltaDepth 0 &&
+ test_must_fail git fsck 2>err &&
+ test_i18ngrep "overlong delta chain" err
+ )
+'
+
test_done
^ permalink raw reply related
* Re: [PATCH] Avoid infinite loop in malformed packfiles
From: Junio C Hamano @ 2020-08-30 16:15 UTC (permalink / raw)
To: René Scharfe; +Cc: ori, peff, git
In-Reply-To: <59efeeab-49de-17e7-8b1c-355d6ef31b5d@web.de>
René Scharfe <l.s.r@web.de> writes:
>> Will that work? I'd expect that modern pack files end up being
>> offset deltas, rather than reference deltas.
>
> True, but going down all the way would work:
Perhaps, but I'd rather use pack-objects to prepare the repository
with no-delta-base-offset to force ref deltas.
> diff --git a/t/t5316-pack-delta-depth.sh b/t/t5316-pack-delta-depth.sh
> index 0f06c40eb1..7fd21cd3ce 100755
> --- a/t/t5316-pack-delta-depth.sh
> +++ b/t/t5316-pack-delta-depth.sh
> @@ -94,4 +94,15 @@ test_expect_success '--depth limits depth' '
> test_i18ncmp expect actual
> '
>
> +test_expect_success 'maxAllowedDeltaDepth is respected' '
> + git clone . clone1 &&
> + (
> + cd clone1 &&
> + git repack -a -d &&
> + test_config core.maxAllowedDeltaDepth 0 &&
> + test_must_fail git fsck 2>err &&
> + test_i18ngrep "overlong delta chain" err
> + )
> +'
> +
> test_done
^ permalink raw reply
* [PATCH] Makefile: add support for generating JSON compilation database
From: Philippe Blain via GitGitGadget @ 2020-08-30 19:28 UTC (permalink / raw)
To: git; +Cc: Philippe Blain, Philippe Blain
From: Philippe Blain <levraiphilippeblain@gmail.com>
Tools based on LibClang [1] can make use of a 'JSON Compilation
Database' [2] that keeps track of the exact options used to compile a set
of source files.
The Clang compiler can generate JSON fragments when compiling [3],
using the `-MJ` flag. These JSON fragments (one per compiled source
file) can then be concatenated to create the compilation database,
commonly called 'compile_commands.json'.
Add support to the Makefile for generating these JSON fragments as well
as the compilation database itself, if the environment variable
'GENERATE_COMPILATION_DATABASE' is set.
If this variable is set, check that $(CC) indeed supports the `-MJ`
flag, following what is done for automatic dependencies.
All JSON fragments are placed in the 'compile_commands/' directory, and
the compilation database 'compile_commands.json' is generated as a
dependency of the 'all' target using a `sed` invocation.
[1] https://clang.llvm.org/docs/Tooling.html
[2] https://clang.llvm.org/docs/JSONCompilationDatabase.html
[3] https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-mj-arg
Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com>
---
Add support for generating JSON compilation database
I don't have a lot of knowledge of Make double-colon rules, or insight
into why they are used for the 'all' target, but I think the approach I
chose makes sense. In particular, I do not list any prerequisite for the
'compile_commands.json' file, but from what I tested it is still rebuilt
anytime the 'all' target is rebuilt, which is what we want.
Note: CMakeLists.txt in contrib/buildsystems does not need to be updated
to also support this feature because CMake supports it out-of-the-box
[1].
[1]
https://cmake.org/cmake/help/latest/variable/CMAKE_EXPORT_COMPILE_COMMANDS.html
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-714%2Fphil-blain%2Fcompiledb-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-714/phil-blain/compiledb-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/714
.gitignore | 2 ++
Makefile | 52 +++++++++++++++++++++++++++++++++++++++++++++++-----
2 files changed, 49 insertions(+), 5 deletions(-)
diff --git a/.gitignore b/.gitignore
index ee509a2ad2..f4c51300e0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -197,6 +197,7 @@
/git.spec
*.exe
*.[aos]
+*.o.json
*.py[co]
.depend/
*.gcda
@@ -218,6 +219,7 @@
/tags
/TAGS
/cscope*
+/compile_commands.json
*.hcc
*.obj
*.lib
diff --git a/Makefile b/Makefile
index 65f8cfb236..954bd2aa47 100644
--- a/Makefile
+++ b/Makefile
@@ -462,6 +462,12 @@ all::
# the global variable _wpgmptr containing the absolute path of the current
# executable (this is the case on Windows).
#
+# Define GENERATE_COMPILATION_DATABASE to generate JSON compilation database
+# entries during compilation if your compiler supports it, using the `-MJ` flag.
+# The JSON entries will be placed in the `compile_commands/` directory,
+# and the JSON compilation database can be created afterwards with
+# `make compile_commands.json`.
+#
# Define DEVELOPER to enable more compiler warnings. Compiler version
# and family are auto detected, but could be overridden by defining
# COMPILER_FEATURES (see config.mak.dev). You can still set
@@ -1258,6 +1264,20 @@ $(error please set COMPUTE_HEADER_DEPENDENCIES to yes, no, or auto \
endif
endif
+ifdef GENERATE_COMPILATION_DATABASE
+compdb_check = $(shell $(CC) $(ALL_CFLAGS) \
+ -c -MJ /dev/null \
+ -x c /dev/null -o /dev/null 2>&1; \
+ echo $$?)
+ifeq ($(compdb_check),0)
+override GENERATE_COMPILATION_DATABASE = yes
+else
+override GENERATE_COMPILATION_DATABASE = no
+$(warning GENERATE_COMPILATION_DATABASE is set, but your compiler does not \
+support generating compilation database entries)
+endif
+endif
+
ifdef SANE_TOOL_PATH
SANE_TOOL_PATH_SQ = $(subst ','\'',$(SANE_TOOL_PATH))
BROKEN_PATH_FIX = 's|^\# @@BROKEN_PATH_FIX@@$$|git_broken_path_fix "$(SANE_TOOL_PATH_SQ)"|'
@@ -2381,16 +2401,30 @@ missing_dep_dirs =
dep_args =
endif
+compdb_dir = compile_commands/
+
+ifeq ($(GENERATE_COMPILATION_DATABASE),yes)
+missing_compdb_dir = $(compdb_dir)
+$(missing_compdb_dir):
+ @mkdir -p $@
+
+compdb_file = $(compdb_dir)$(subst .-,,$(subst /,-,$(dir $@)))$(notdir $@).json
+compdb_args = -MJ $(compdb_file)
+else
+missing_compdb_dir =
+compdb_args =
+endif
+
ASM_SRC := $(wildcard $(OBJECTS:o=S))
ASM_OBJ := $(ASM_SRC:S=o)
C_OBJ := $(filter-out $(ASM_OBJ),$(OBJECTS))
.SUFFIXES:
-$(C_OBJ): %.o: %.c GIT-CFLAGS $(missing_dep_dirs)
- $(QUIET_CC)$(CC) -o $*.o -c $(dep_args) $(ALL_CFLAGS) $(EXTRA_CPPFLAGS) $<
-$(ASM_OBJ): %.o: %.S GIT-CFLAGS $(missing_dep_dirs)
- $(QUIET_CC)$(CC) -o $*.o -c $(dep_args) $(ALL_CFLAGS) $(EXTRA_CPPFLAGS) $<
+$(C_OBJ): %.o: %.c GIT-CFLAGS $(missing_dep_dirs) $(missing_compdb_dir)
+ $(QUIET_CC)$(CC) -o $*.o -c $(dep_args) $(compdb_args) $(ALL_CFLAGS) $(EXTRA_CPPFLAGS) $<
+$(ASM_OBJ): %.o: %.S GIT-CFLAGS $(missing_dep_dirs) $(missing_compdb_dir)
+ $(QUIET_CC)$(CC) -o $*.o -c $(dep_args) $(compdb_args) $(ALL_CFLAGS) $(EXTRA_CPPFLAGS) $<
%.s: %.c GIT-CFLAGS FORCE
$(QUIET_CC)$(CC) -o $@ -S $(ALL_CFLAGS) $(EXTRA_CPPFLAGS) $<
@@ -2413,6 +2447,14 @@ else
$(OBJECTS): $(LIB_H) $(GENERATED_H)
endif
+ifeq ($(GENERATE_COMPILATION_DATABASE),yes)
+all:: compile_commands.json
+compile_commands.json:
+ @$(RM) $@
+ $(QUIET_GEN)sed -e '1s/^/[/' -e '$$s/,$$/]/' $(compdb_dir)*.o.json > $@+
+ @if test -s $@+; then mv $@+ $@; else $(RM) $@+; fi
+endif
+
exec-cmd.sp exec-cmd.s exec-cmd.o: GIT-PREFIX
exec-cmd.sp exec-cmd.s exec-cmd.o: EXTRA_CPPFLAGS = \
'-DGIT_EXEC_PATH="$(gitexecdir_SQ)"' \
@@ -3117,7 +3159,7 @@ clean: profile-clean coverage-clean cocciclean
$(RM) $(TEST_PROGRAMS)
$(RM) $(FUZZ_PROGRAMS)
$(RM) $(HCC)
- $(RM) -r bin-wrappers $(dep_dirs)
+ $(RM) -r bin-wrappers $(dep_dirs) $(compdb_dir) compile_commands.json
$(RM) -r po/build/
$(RM) *.pyc *.pyo */*.pyc */*.pyo $(GENERATED_H) $(ETAGS_TARGET) tags cscope*
$(RM) -r $(GIT_TARNAME) .doc-tmp-dir
base-commit: d9cd4331470f4d9d78677f12dc79063dab832f53
--
gitgitgadget
^ permalink raw reply related
* Re: [GSoC][PATCH] submodule: port submodule subcommand 'add' from shell to C
From: Kaartic Sivaraam @ 2020-08-30 19:58 UTC (permalink / raw)
To: Shourya Shukla
Cc: Junio C Hamano, git, christian.couder, johannes.schindelin,
liu.denton
In-Reply-To: <20200826091502.GA29471@konoha>
On Wed, 2020-08-26 at 14:45 +0530, Shourya Shukla wrote:
> On 24/08 11:35, Junio C Hamano wrote:
> > Shourya Shukla <shouryashukla.oo@gmail.com> writes:
> >
> > The shell version would error out with anything in the index, so I'd
> > expect that a faithful conversion would not call is_directory() nor
> > submodule_from_path() at all---it would just look path up in the_index
> > and complains if anything is found. For example, the quoted part in
> > the original above is what gives the error message when I do
> >
> > $ git submodule add ./Makefile
> > 'Makefile' already exists in the index.
> >
> > I think. And the above code won't trigger the "already exists" at
> > all because 'path' is not a directory.
>
> Alright. That is correct. I tried to use a multitude of functions but
> did not find luck with any of them. The functions I tried:
>
It would've been nice to see the actual code you tried so that it's
easier for others to more easily identify if you're using the wrong
function or using the correct function in the wrong way.
> - index_path() to check if the path is in the index. For some
> reason, it switched to the 'default' case and return the
> 'unsupported file type' error.
>
> - A combination of doing an OR with index_file_exists() and
> index_dir_exists(). Still no luck. t7406.43 fails.
>
> - Using index_name_pos() along with the above two functions. Again a
> failure in the same test.
>
> I feel that index_name_pos() should suffice this task but it fails in
> t7406.43. The SM is in index since 'git ls-files --error-unmatch s1'
> does return 's1' (s1 is the submodule). What am I missing here?
>
You're likely missing the fact that you should call `read_cache` before
using `index_name_pos` or the likes of it.
For instance, the following works without issues for most cases (more
on that below):
if (read_cache() < 0)
die(_("index file corrupt"));
cache_pos = cache_name_pos(path, strlen(path));
if (cache_pos >= 0) {
if (!force) {
die(_("'%s' already exists in the index"),
path);
}
else {
struct cache_entry *ce = the_index.cache[cache_pos];
if (!S_ISGITLINK(ce->ce_mode))
die(_("'%s' already exists in the index and is not a "
"submodule"), path);
}
}
This is more close to what the shell version did but misses one case
which might or might not be covered by the test suite[1]. The case when
path is a directory that has tracked contents. In the shell version we
would get:
$ git submodule add ../git-crypt/ builtin
'builtin' already exists in the index
$ git submodule add --force ../git-crypt/ builtin
'builtin' already exists in the index and is not a submodule
In the C version with the above snippet we get:
$ git submodule add --force ../git-crypt/ builtin
fatal: 'builtin' does not have a commit checked out
$ git submodule add ../git-crypt/ builtin
fatal: 'builtin' does not have a commit checked out
That's not appropriate and should be fixed. I believe we could do
something with `cache_dir_exists` to fix this.
Footnote
===
[1]: If it's not covered already, it might be a good idea to add a test
for the above case.
--
Sivaraam
^ permalink raw reply
* [PATCH 0/3] Clean up and improve git-imap-send.txt
From: Philippe Blain via GitGitGadget @ 2020-08-30 22:01 UTC (permalink / raw)
To: git; +Cc: Philippe Blain
This series cleans up the documentation page for 'git imap-send', removes
the sslVerify config from the Gmail example, and uses more appropriate
Asciidoc syntax.
It is a rework of [1], incorporating Junio's suggestions from [2].
I split the suggestions in 2 commits to make reviewing the patches easier.
The third commit adds a note about localized Gmail folder names, which bit
me when I was configuring 'git imap-send' myself.
[1] https://lore.kernel.org/git/51758EE8.7030800@gmail.com/[2]
https://lore.kernel.org/git/7vr4hzetki.fsf@alter.siamese.dyndns.org/
Philippe Blain (3):
git-imap-send.txt: don't duplicate 'Examples' sections
git-imap-send.txt: do verify SSL certificate for gmail.com
git-imap-send.txt: add note about localized Gmail folders
Documentation/git-imap-send.txt | 34 ++++++++++++++++++---------------
1 file changed, 19 insertions(+), 15 deletions(-)
base-commit: d9cd4331470f4d9d78677f12dc79063dab832f53
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-715%2Fphil-blain%2Fimap-send-ssl-verify-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-715/phil-blain/imap-send-ssl-verify-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/715
--
gitgitgadget
^ permalink raw reply
* [PATCH 3/3] git-imap-send.txt: add note about localized Gmail folders
From: Philippe Blain via GitGitGadget @ 2020-08-30 22:01 UTC (permalink / raw)
To: git; +Cc: Philippe Blain, Philippe Blain
In-Reply-To: <pull.715.git.1598824880.gitgitgadget@gmail.com>
From: Philippe Blain <levraiphilippeblain@gmail.com>
The name of the "Special-Use Mailboxes" in Gmail are localized
using the user's localization settings. Add a note to that effect
in `git imap-send`'s documentation, to make it easier for users to
configure their account.
Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com>
---
Documentation/git-imap-send.txt | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/git-imap-send.txt b/Documentation/git-imap-send.txt
index 5e4d4d43b9..63cf498ce9 100644
--- a/Documentation/git-imap-send.txt
+++ b/Documentation/git-imap-send.txt
@@ -110,6 +110,10 @@ Using Gmail's IMAP interface:
You might need to instead use: `folder = "[Google Mail]/Drafts"` if you get an error
that the "Folder doesn't exist".
+[NOTE]
+If your Gmail account is set to another language than English, the name of the "Drafts"
+folder will be localized.
+
Once the commits are ready to be sent, run the following command:
$ git format-patch --cover-letter -M --stdout origin/master | git imap-send
--
gitgitgadget
^ permalink raw reply related
* [PATCH 2/3] git-imap-send.txt: do verify SSL certificate for gmail.com
From: Philippe Blain via GitGitGadget @ 2020-08-30 22:01 UTC (permalink / raw)
To: git; +Cc: Philippe Blain, Philippe Blain
In-Reply-To: <pull.715.git.1598824880.gitgitgadget@gmail.com>
From: Philippe Blain <levraiphilippeblain@gmail.com>
As a public service, it is unlikely that the Gmail server is configured
to throw a certificate that does not verify at the user.
Remove the `sslVerify=false` config from the Gmail example.
Also, comment it in the `example.com` example, and add a note to the
user explaining that they might want to uncomment it if they are having
trouble connecting. While at it, use an Asciidoc 'Note' section in the
Gmail example also.
Based-on-patch-by: Barbu Paul - Gheorghe <barbu.paul.gheorghe@gmail.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com>
---
Documentation/git-imap-send.txt | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-imap-send.txt b/Documentation/git-imap-send.txt
index 0a00a1236b..5e4d4d43b9 100644
--- a/Documentation/git-imap-send.txt
+++ b/Documentation/git-imap-send.txt
@@ -85,10 +85,17 @@ Using direct mode with SSL:
user = bob
pass = p4ssw0rd
port = 123
- sslverify = false
+ ; sslVerify = false
.........................
+[NOTE]
+You may want to use `sslVerify=false`
+while troubleshooting, if you suspect that the reason you are
+having trouble connecting is because the certificate you use at
+the private server `example.com` you are trying to set up (or
+have set up) may not be verified correctly.
+
Using Gmail's IMAP interface:
---------
@@ -97,9 +104,9 @@ Using Gmail's IMAP interface:
host = imaps://imap.gmail.com
user = user@gmail.com
port = 993
- sslverify = false
---------
+[NOTE]
You might need to instead use: `folder = "[Google Mail]/Drafts"` if you get an error
that the "Folder doesn't exist".
--
gitgitgadget
^ permalink raw reply related
* [PATCH 1/3] git-imap-send.txt: don't duplicate 'Examples' sections
From: Philippe Blain via GitGitGadget @ 2020-08-30 22:01 UTC (permalink / raw)
To: git; +Cc: Philippe Blain, Philippe Blain
In-Reply-To: <pull.715.git.1598824880.gitgitgadget@gmail.com>
From: Philippe Blain <levraiphilippeblain@gmail.com>
Remove the 'Examples' subsection in the 'Configuration' section and move
these examples to the 'Examples' section. Also remove the 'Variables'
title since it is now useless.
Also, use appropriate Asciidoc syntax for configuration values, and
capitalize 'Gmail' properly.
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com>
---
Documentation/git-imap-send.txt | 19 ++++++-------------
1 file changed, 6 insertions(+), 13 deletions(-)
diff --git a/Documentation/git-imap-send.txt b/Documentation/git-imap-send.txt
index 65b53fcc47..0a00a1236b 100644
--- a/Documentation/git-imap-send.txt
+++ b/Documentation/git-imap-send.txt
@@ -51,17 +51,13 @@ OPTIONS
CONFIGURATION
-------------
-To use the tool, imap.folder and either imap.tunnel or imap.host must be set
+To use the tool, `imap.folder` and either `imap.tunnel` or `imap.host` must be set
to appropriate values.
-Variables
-~~~~~~~~~
-
include::config/imap.txt[]
-Examples
-~~~~~~~~
-
+EXAMPLES
+--------
Using tunnel mode:
..........................
@@ -93,10 +89,7 @@ Using direct mode with SSL:
.........................
-EXAMPLES
---------
-To submit patches using GMail's IMAP interface, first, edit your ~/.gitconfig
-to specify your account settings:
+Using Gmail's IMAP interface:
---------
[imap]
@@ -107,14 +100,14 @@ to specify your account settings:
sslverify = false
---------
-You might need to instead use: folder = "[Google Mail]/Drafts" if you get an error
+You might need to instead use: `folder = "[Google Mail]/Drafts"` if you get an error
that the "Folder doesn't exist".
Once the commits are ready to be sent, run the following command:
$ git format-patch --cover-letter -M --stdout origin/master | git imap-send
-Just make sure to disable line wrapping in the email client (GMail's web
+Just make sure to disable line wrapping in the email client (Gmail's web
interface will wrap lines no matter what, so you need to use a real
IMAP client).
--
gitgitgadget
^ permalink raw reply related
* Re: [PATCH] Makefile: add support for generating JSON compilation database
From: brian m. carlson @ 2020-08-30 22:10 UTC (permalink / raw)
To: Philippe Blain via GitGitGadget; +Cc: git, Philippe Blain
In-Reply-To: <pull.714.git.1598815707540.gitgitgadget@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1184 bytes --]
On 2020-08-30 at 19:28:27, Philippe Blain via GitGitGadget wrote:
> From: Philippe Blain <levraiphilippeblain@gmail.com>
>
> Tools based on LibClang [1] can make use of a 'JSON Compilation
> Database' [2] that keeps track of the exact options used to compile a set
> of source files.
For additional context why this is valuable, clangd, which is a C
language server protocol implementation, can use these files to
determine the flags needed to compile a file so it can provide proper
editor integration. As a result, editors supporting the language server
protocol (such as VS Code, or Vim with a suitable plugin) can provide
better searching, integration, and refactoring tools.
So I'm very much in favor of a change like this.
> +ifeq ($(GENERATE_COMPILATION_DATABASE),yes)
> +all:: compile_commands.json
> +compile_commands.json:
> + @$(RM) $@
> + $(QUIET_GEN)sed -e '1s/^/[/' -e '$$s/,$$/]/' $(compdb_dir)*.o.json > $@+
> + @if test -s $@+; then mv $@+ $@; else $(RM) $@+; fi
> +endif
How are those commas at the end of the line added? Are they natively
part of the files? If so, this seems reasonable.
--
brian m. carlson: Houston, Texas, US
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
^ permalink raw reply
* Re: [PATCH] Makefile: add support for generating JSON compilation database
From: Philippe Blain @ 2020-08-30 22:17 UTC (permalink / raw)
To: Philippe Blain via GitGitGadget; +Cc: Git mailing list, brian m. carlson
In-Reply-To: <pull.714.git.1598815707540.gitgitgadget@gmail.com>
> #
> +# Define GENERATE_COMPILATION_DATABASE to generate JSON compilation database
> +# entries during compilation if your compiler supports it, using the `-MJ` flag.
> +# The JSON entries will be placed in the `compile_commands/` directory,
> +# and the JSON compilation database can be created afterwards with
> +# `make compile_commands.json`.
> +#
I'm realizing that the way I'm describing how it works here is wrong: there is no
separate 'make compile_commands.json' step needed (it was needed in my first draft).
I'll fix that for v2.
^ permalink raw reply
* [PATCH v2] t3200: clean side effect of git checkout --orphan
From: Aaron Lipman @ 2020-08-30 22:42 UTC (permalink / raw)
To: git; +Cc: Aaron Lipman, Eric Sunshine
In-Reply-To: <20200829225648.11971-1-alipman88@gmail.com>
The "refuse --edit-description on unborn branch for now" test in t3200
switches to an orphan branch, causing subsequent git commands
referencing HEAD to fail. Avoid this side-effect by switching back to
master after the test finishes.
This has gone undetected, as the next affected test expects failure -
but it currently fails for the wrong reason.
Verbose output of the next test referencing HEAD,
"--merged is incompatible with --no-merged":
fatal: malformed object name HEAD
Which this commit corrects to:
error: option `no-merged' is incompatible with --merged
Signed-off-by: Aaron Lipman <alipman88@gmail.com>
---
Whoops, fixed the effected/affected error.
Thanks for catching that, Eric!
t/t3200-branch.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index 4c0734157b..028c88d1b2 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -1287,6 +1287,7 @@ test_expect_success 'detect typo in branch name when using --edit-description' '
'
test_expect_success 'refuse --edit-description on unborn branch for now' '
+ test_when_finished "git checkout master" &&
write_script editor <<-\EOF &&
echo "New contents" >"$1"
EOF
--
2.24.3 (Apple Git-128)
^ permalink raw reply related
* Re: [PATCH] Makefile: add support for generating JSON compilation database
From: Philippe Blain @ 2020-08-31 2:37 UTC (permalink / raw)
To: brian m. carlson; +Cc: Philippe Blain via GitGitGadget, Git mailing list
In-Reply-To: <20200830221004.GB241078@camp.crustytoothpaste.net>
Hi Brian,
> Le 30 août 2020 à 18:10, brian m. carlson <sandals@crustytoothpaste.net> a écrit :
>
> On 2020-08-30 at 19:28:27, Philippe Blain via GitGitGadget wrote:
>> From: Philippe Blain <levraiphilippeblain@gmail.com>
>>
>> Tools based on LibClang [1] can make use of a 'JSON Compilation
>> Database' [2] that keeps track of the exact options used to compile a set
>> of source files.
>
> For additional context why this is valuable, clangd, which is a C
> language server protocol implementation, can use these files to
> determine the flags needed to compile a file so it can provide proper
> editor integration. As a result, editors supporting the language server
> protocol (such as VS Code, or Vim with a suitable plugin) can provide
> better searching, integration, and refactoring tools.
>
> So I'm very much in favor of a change like this.
Thanks!
>
>> +ifeq ($(GENERATE_COMPILATION_DATABASE),yes)
>> +all:: compile_commands.json
>> +compile_commands.json:
>> + @$(RM) $@
>> + $(QUIET_GEN)sed -e '1s/^/[/' -e '$$s/,$$/]/' $(compdb_dir)*.o.json > $@+
>> + @if test -s $@+; then mv $@+ $@; else $(RM) $@+; fi
>> +endif
>
> How are those commas at the end of the line added? Are they natively
> part of the files? If so, this seems reasonable.
Yes: the '*.o.json' files generated by the compiler contain one JSON object per file,
with a trailing comma.
This 'sed' invocation turns these files into a proper JSON array by:
- adding a '[' at the beginning and a ']' at the end of the list of objects
- removing the comma after the last entry (before the closing ']')
^ permalink raw reply
* [PATCH] doc: mention GIT_SEQUENCE_EDITOR and 'sequence.editor' more
From: Philippe Blain via GitGitGadget @ 2020-08-31 3:40 UTC (permalink / raw)
To: git; +Cc: Peter Oberndorfer, Philippe Blain, Philippe Blain
From: Philippe Blain <levraiphilippeblain@gmail.com>
The environment variable `GIT_SEQUENCE_EDITOR`, and the configuration
variable 'sequence.editor', which were added in 821881d88d ("rebase -i":
support special-purpose editor to edit insn sheet, 2011-10-17), are
mentioned in the `git config` man page but not anywhere else.
Include `config/sequencer.txt` in `git-rebase.txt`, so that both the
environment variable and the configuration setting are mentioned there.
Also, add `GIT_SEQUENCE_EDITOR` to the list of environment variables
in `git(1)`.
Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com>
---
doc: mention GIT_SEQUENCE_EDITOR and 'sequence.editor' more
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-716%2Fphil-blain%2Fdoc-mention-sequence-editor-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-716/phil-blain/doc-mention-sequence-editor-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/716
Documentation/git-rebase.txt | 1 +
Documentation/git.txt | 6 ++++++
2 files changed, 7 insertions(+)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 374d2486f7..9e2f9576c3 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -204,6 +204,7 @@ CONFIGURATION
-------------
include::config/rebase.txt[]
+include::config/sequencer.txt[]
OPTIONS
-------
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 2fc92586b5..0bb1cfb239 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -605,6 +605,12 @@ other
an editor is to be launched. See also linkgit:git-var[1]
and the `core.editor` option in linkgit:git-config[1].
+`GIT_SEQUENCE_EDITOR`::
+ This environment variable overrides the configured Git editor
+ when editing the todo list of an interactive rebase. See also
+ linkit::git-rebase[1] and the `sequence.editor` option in
+ linkit::git-config[1].
+
`GIT_SSH`::
`GIT_SSH_COMMAND`::
If either of these environment variables is set then 'git fetch'
base-commit: d9cd4331470f4d9d78677f12dc79063dab832f53
--
gitgitgadget
^ permalink raw reply related
* Re: [PATCH] Makefile: add support for generating JSON compilation database
From: Junio C Hamano @ 2020-08-31 4:24 UTC (permalink / raw)
To: brian m. carlson; +Cc: Philippe Blain via GitGitGadget, git, Philippe Blain
In-Reply-To: <20200830221004.GB241078@camp.crustytoothpaste.net>
"brian m. carlson" <sandals@crustytoothpaste.net> writes:
> On 2020-08-30 at 19:28:27, Philippe Blain via GitGitGadget wrote:
>> From: Philippe Blain <levraiphilippeblain@gmail.com>
>>
>> Tools based on LibClang [1] can make use of a 'JSON Compilation
>> Database' [2] that keeps track of the exact options used to compile a set
>> of source files.
>
> For additional context why this is valuable, clangd, which is a C
> language server protocol implementation, can use these files to
> determine the flags needed to compile a file so it can provide proper
> editor integration. As a result, editors supporting the language server
> protocol (such as VS Code, or Vim with a suitable plugin) can provide
> better searching, integration, and refactoring tools.
I found that the proposed commit log was very weak to sell the
change; some of what you gave above should definitely help strenthen
it.
Thanks.
^ permalink raw reply
* Re: [PATCH v2] revision: add separate field for "-m" of "diff-index -m"
From: Junio C Hamano @ 2020-08-31 4:49 UTC (permalink / raw)
To: Sergey Organov; +Cc: Jeff King, git
In-Reply-To: <20200829201140.23425-1-sorganov@gmail.com>
Sergey Organov <sorganov@gmail.com> writes:
> Historically, in "diff-index -m", "-m" does not mean "do not ignore merges", but
> "match missing". Despite this, diff-index abuses 'ignore_merges' field being set
> by "-m", that in turn causes more troubles.
"causes more troubles"? When there is no trouble, and no "more"
trouble, concretely mentioned, it is a quite weak justfiication.
There is no reason to say "historically" here, as it has been like
so from beginning of the time, it still is so and it is relied
upon. "diff-{files,index,tree}" are about comparing two things, and
not about history (where a "merge" might influence "now we are
showing this commit. which parent do we compare it with?"), so
giving short-and-sweet "-m" its own meaning that is sensible within
the context of "diff" was and is perfectly sensible thing to do.
What is worth fixing is not "-m" in diff-index means "match missing"
while "-m" in log wants to mean "show merges". It is that, even both
commands use the same option parsing machinery, and the use of these
two options are mutually exclusive so there is no risk of confusion,
the flag internally used to record the presense of the "em" option is
not named neutrally (e.g. "revs->seen_em_option").
The "log" family of commands and "diff" family of commands
share the same command line parsiong machinery. For the
former, "-m" means "show merges" while for the latter it
means "match missing". Tnis is not a problem at the UI
level, as "show/not show merges" is meaningless in the
context of "diff", and similarly "match/not match missing"
is meaningless in the context of "log".
But there are two problems with this arrangement.
1. the field the presense of the option on the command line
is recorded in has to be given a name. It is currently
called "ignore_merges", which gives an incorrect
impression that using it for "diff" family is somehow a
mistake, and renaming it to "match_missing" would not be
a solution, as it will give an incorrect impression that
"log" family is abusing it. However, naming the field to
something neutral, e.g. "em_option", would make the code
harder to understand.
2. because it uses the same command line parser, giving a
default for "diff -m" in a way that is different from the
default for "log -m" is quite cumbersome if they use the
same field to record it.
Introduce a separate "match_missing" field, and flip it and
"ignore_merges" when we see the "-m" option on the command
line. That way, even when ignore_merges's default is
affected by end-user configuration, the default for
"match_missing" would not be affected.
I think the above would be in line with what you wanted to say but
didn't, and I think it supports the split fairly well.
I have a very strong objection against changing the built-in default
of "log -m", but I do agree that this split of the single field into
two is a fairly good idea. So I do not want to be in the position
that must reject this change because "log -m" and "diff-index -m"
will never be on by default. Basing the justification of this
change on end-user configurability would be a good way to sidestep
the issue, and avoids taking this change hostage to the discussion
on what should be the built-in default for "log/diff-index -m".
^ permalink raw reply
* [gitk] moving the cursor position in search boxes
From: Lyndon Brown @ 2020-08-31 4:53 UTC (permalink / raw)
To: git
Hi,
Please can the UX of gitk be improved by allowing left and right keys
to move the cursor position in the search boxes, which is currently
only possible with a mouse click (the left/right keys just do nothing).
I'm a Debian Linux user, running version 1:2.28.0-1. This annoyance has
existed for a long time.
^ permalink raw reply
* [gitk] broken search box text cutting
From: Lyndon Brown @ 2020-08-31 4:56 UTC (permalink / raw)
To: git
Hi,
If I cut some text in the gitk search boxes, a U+0018 character is
placed into it in place of the cut text, and the text is not actually
placed into the clipboard.
I'm a Debian Linux user, running version 1:2.28.0-1.
^ permalink raw reply
* [gitk] searching misses relevant commits
From: Lyndon Brown @ 2020-08-31 5:08 UTC (permalink / raw)
To: git
Hi,
When searching commits (by which I mean the "find" feature), sometimes
relevant entries are missed which should have been selected. I reported
this to Debian as bug #969197 ([1]).
I gave an example in the Debian bug report of searching the VLC
codebase for commits adding/removing "set_capability" (exact; all
fields). While 888451fe5146a49de8d49e830dbe57dd478e358f was one of
those found, the adjacent
commit 46650ad3f7f92d2757c43b42aa170965dc1df25c was skipped, despite it
being entirely relevant.
Changing to IgnCase makes no difference.
I'm a Debian Linux user, running version 1:2.28.0-1.
[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969197
^ permalink raw reply
* [gitk] searching commits includes irrelevant file renaming entries
From: Lyndon Brown @ 2020-08-31 5:11 UTC (permalink / raw)
To: git
Hi,
When searching commits in add/remove string mode, the search results
include commits that simply rename files that contain the string. UX
would be improved IMO if it were to ignore such commits.
I'm a Debian Linux user, running version 1:2.28.0-1.
^ permalink raw reply
* Re: Git in Outreachy?
From: Christian Couder @ 2020-08-31 6:55 UTC (permalink / raw)
To: Jeff King; +Cc: git, Christian Couder, Johannes Schindelin
In-Reply-To: <20200828065609.GA2105118@coredump.intra.peff.net>
On Fri, Aug 28, 2020 at 8:56 AM Jeff King <peff@peff.net> wrote:
>
> Are we interested in participating in the December 2020 round of
> Outreachy? The community application period is now open.
I am interested in participating.
> I can look into lining up funding, but we'd also need:
>
> - volunteers to act as mentors
I am interested in mentoring, but would prefer to co-mentor.
> - updates to our applicant materials (proposed projects, but also
> microproject / patch suggestions)
It looks like many micro-project ideas from GSoC 2020 are still valid,
and I have a few new ones, so I am ok to create a micro-project page.
I would appreciate help to find project ideas though. Are there still
scripts that are worth converting to C (excluding git-bisect.sh and
git-submodule.sh that are still worked on)? Are there worthy
refactorings or improvements that we could propose as projects?
^ permalink raw reply
* [PATCH v2 1/5] worktree: add skeleton "repair" command
From: Eric Sunshine @ 2020-08-31 6:57 UTC (permalink / raw)
To: git
Cc: Henré Botha, Jeff King, Junio C Hamano, Johannes Schindelin,
Ramsay Jones, Eric Sunshine
In-Reply-To: <20200831065800.62502-1-sunshine@sunshineco.com>
Worktree administrative files can become corrupted or outdated due to
external factors. Although, it is often possible to recover from such
situations by hand-tweaking these files, doing so requires intimate
knowledge of worktree internals. While information necessary to make
such repairs manually can be obtained from git-worktree.txt and
gitrepository-layout.txt, we can assist users more directly by teaching
git-worktree how to repair its administrative files itself (at least to
some extent). Therefore, add a "git worktree repair" command which
attempts to correct common problems which may arise due to factors
beyond Git's control.
At this stage, the "repair" command is a mere skeleton; subsequent
commits will flesh out the functionality.
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
---
Documentation/git-worktree.txt | 6 ++++++
builtin/worktree.c | 15 +++++++++++++++
t/t2406-worktree-repair.sh | 11 +++++++++++
3 files changed, 32 insertions(+)
create mode 100755 t/t2406-worktree-repair.sh
diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
index 6ee6ec7982..ae432d39a8 100644
--- a/Documentation/git-worktree.txt
+++ b/Documentation/git-worktree.txt
@@ -15,6 +15,7 @@ SYNOPSIS
'git worktree move' <worktree> <new-path>
'git worktree prune' [-n] [-v] [--expire <expire>]
'git worktree remove' [-f] <worktree>
+'git worktree repair'
'git worktree unlock' <worktree>
DESCRIPTION
@@ -110,6 +111,11 @@ and no modification in tracked files) can be removed. Unclean working
trees or ones with submodules can be removed with `--force`. The main
working tree cannot be removed.
+repair::
+
+Repair working tree administrative files, if possible, if they have
+become corrupted or outdated due to external factors.
+
unlock::
Unlock a working tree, allowing it to be pruned, moved or deleted.
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 378f332b5d..88af412d4f 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -1030,6 +1030,19 @@ static int remove_worktree(int ac, const char **av, const char *prefix)
return ret;
}
+static int repair(int ac, const char **av, const char *prefix)
+{
+ struct option options[] = {
+ OPT_END()
+ };
+ int rc = 0;
+
+ ac = parse_options(ac, av, prefix, options, worktree_usage, 0);
+ if (ac)
+ usage_with_options(worktree_usage, options);
+ return rc;
+}
+
int cmd_worktree(int ac, const char **av, const char *prefix)
{
struct option options[] = {
@@ -1056,5 +1069,7 @@ int cmd_worktree(int ac, const char **av, const char *prefix)
return move_worktree(ac - 1, av + 1, prefix);
if (!strcmp(av[1], "remove"))
return remove_worktree(ac - 1, av + 1, prefix);
+ if (!strcmp(av[1], "repair"))
+ return repair(ac - 1, av + 1, prefix);
usage_with_options(worktree_usage, options);
}
diff --git a/t/t2406-worktree-repair.sh b/t/t2406-worktree-repair.sh
new file mode 100755
index 0000000000..cc679e1a21
--- /dev/null
+++ b/t/t2406-worktree-repair.sh
@@ -0,0 +1,11 @@
+#!/bin/sh
+
+test_description='test git worktree repair'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+ test_commit init
+'
+
+test_done
--
2.28.0.531.g41c3d8a546
^ permalink raw reply related
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