* Re: Bug: "Received" misspelled in remote message
From: Junio C Hamano @ 2023-11-16 3:42 UTC (permalink / raw)
To: git; +Cc: Alan Dove
In-Reply-To: <xmqqmsvetmu3.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> writes:
>> "remote: Recieved update on checked-out branch, queueing deployment."
>>
>> "Received" is misspelled.
>
> I think it is coming from the "push-to-checkout" hook that is
> installed on your "private server", and not from what we ship as
> part of our software offering.
Googling for the misspelled message seems to indicate that it is
coming from cpanel (whatever it is). A randomly picked example is
https://essgeelabs.com/posts/cpanel-git-1/ which is a recipe that
does not involve typing the typoed message by the end-user, so
somebody (most likely cPanel) must be shipping with a hook with
typo.
Another user of cPanel reports this
https://forums.cpanel.net/threads/git-automatic-deployment-not-working-but-manual-deployment-is.679837/
where they observe post-receive hook with the typo.
Anybody with contact there at cpanel.net may want to report the bug.
Thanks.
^ permalink raw reply
* Re: Bug: "Received" misspelled in remote message
From: Junio C Hamano @ 2023-11-16 3:10 UTC (permalink / raw)
To: Alan Dove; +Cc: git
In-Reply-To: <4e76dda1009a8365a1d66d9594865a4af31ab418.camel@gmail.com>
Alan Dove <alan.dove@gmail.com> writes:
> Hello:
>
> Using Git 2.40.1 on a private server, I see this message whenever I
> push a commit:
>
> "remote: Recieved update on checked-out branch, queueing deployment."
>
> "Received" is misspelled.
I think it is coming from the "push-to-checkout" hook that is
installed on your "private server", and not from what we ship as
part of our software offering.
We are not going to include spelling correction software to massage
the output from end-user installed hooks, so it is unlikely the
typo will be fixed by us.
> I realize this is a very minor issue, but it should also be very easy
> to correct. As someone who suffers from Proofreader's Eye, this error
> deals psychic damage to me on a daily basis.
Sounds like something a world-class science writer may say ;-).
Thanks for reporting.
^ permalink raw reply
* Re: [PATCH 1/1] attr: add builtin objectmode values support
From: Junio C Hamano @ 2023-11-16 2:53 UTC (permalink / raw)
To: Eric Sunshine; +Cc: Joanna Wang, git, tboegi
In-Reply-To: <CAPig+cSyrD71NMnfVCTHEf+K8vop9QHLet7uyOerrq=v9SVbFw@mail.gmail.com>
Eric Sunshine <sunshine@sunshineco.com> writes:
> A bit more idiomatic in this codebase would be:
>
> git update-index --index-info <<-EOF
> 100755 $empty_blob 0 exec
> 120000 $empty_blob 0 symlink
> EOF
>
> No need for `cat`.
Aye, of course. We should not cat a single-source datastream into a
pipe. Thanks for correcting me.
^ permalink raw reply
* Re: [PATCH 1/1] attr: add builtin objectmode values support
From: Eric Sunshine @ 2023-11-16 1:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Joanna Wang, git, tboegi
In-Reply-To: <xmqqy1eytrns.fsf@gitster.g>
On Wed, Nov 15, 2023 at 8:26 PM Junio C Hamano <gitster@pobox.com> wrote:
> Joanna Wang <jojwang@google.com> writes:
> > +test_expect_success 'native object mode attributes work with --cached' '
> > + >normal && attr_check_object_mode normal unspecified --cached &&
> > + git add normal && attr_check_object_mode normal 100644 --cached
> > +'
>
> For "--cached test", on the other hand, we should be able to set the
> executable bit or record a symbolic link regardless of the
> filesystem using "update-index", e.g.,
>
> empty_blob=$(git rev-parse :normal)
> cat <<-EOF | git update-index --index-info
> 100755 $empty_blob 0 exec
> 120000 $empty_blob 0 symlink
> EOF
>
> or something.
A bit more idiomatic in this codebase would be:
git update-index --index-info <<-EOF
100755 $empty_blob 0 exec
120000 $empty_blob 0 symlink
EOF
No need for `cat`.
^ permalink raw reply
* Re: [PATCH 1/1] attr: add builtin objectmode values support
From: Junio C Hamano @ 2023-11-16 1:26 UTC (permalink / raw)
To: Joanna Wang; +Cc: git, tboegi
In-Reply-To: <20231114214934.3484892-1-jojwang@google.com>
Joanna Wang <jojwang@google.com> writes:
>> static struct git_attr mode_attr;
>>
>> if (!mode_attr)
>> mode_attr = git_attr("mode");
> Is there an idiomatic way to check if this git_attr (struct or pointer)
> has been initialized?
Sorry (I think the above is a typo from the "to illustrate the idea"
code snippet in my message), the static one should be a pointer to a
struct, as git_attr() is meant to "intern" the given name and return
a singleton instance.
The idiom is to see if it is still NULL and then call git_attr().
Of course, you could repeatedly call git_attr() with the same name
and get the same singleton instance, so without the "have we
initialized?" check, your code will still be correct, but it would
incur a locked hashmap lookup (to ensure that we do not create the
second instance of the same name), so...
> +RESERVED BUILTIN_* ATTRIBUTES
> +-----------------------------
> +
> +builtin_* is a reserved namespace for builtin attribute values. Any
> +user defined attributes under this namespace will result in a warning.
warning and then? I think we would want to do "warn and ignore",
not "warn and disable all the builtin_ computation", i.e.,
... will be ignored and a warning message is given.
> +/*
> + * Atribute name cannot begin with "builtin_" which
> + * is a reserved namespace for built in attributes values.
> + */
> +static int attr_name_reserved(const char *name)
> +{
> + return !strncmp(name, "builtin_", strlen("builtin_"));
> +}
> +
You'd want to use starts_with() probably.
> @@ -1240,6 +1250,57 @@ static struct object_id *default_attr_source(void)
> return &attr_source;
> }
>
> +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;
> + struct stat st;
> + if (lstat(path, &st))
> + die_errno(_("unable to stat '%s'"), path);
> + mode = canon_mode(st.st_mode);
> + if (S_ISDIR(mode)) {
> + /* `path` is either a directory or it is a submodule,
> + * in which case it is already indexed as submodule
> + * or it does not exist in the index yet and we need to
> + * check if we can resolve to a ref.
> + */
/*
* Our multi-line comment begins and ends with
* slash-asterisk and asterisk-slash on their
* own lines without anything else.
*/
> + int pos = index_name_pos(istate, path, strlen(path));
> + if (pos >= 0) {
> + if (S_ISGITLINK(istate->cache[pos]->ce_mode))
> + mode = istate->cache[pos]->ce_mode;
> + } else if (resolve_gitlink_ref(path, "HEAD", &oid) == 0)
> + mode = S_IFGITLINK;
> + }
Give {braces} around the else if block as the other side has it
(Documentation/CodingGuidelines):
- When there are multiple arms to a conditional and some of them
require braces, enclose even a single line block in braces for
consistency.
> + } else {
> + /*
> + * For GIT_ATTR_CHECKOUT and GIT_ATTR_INDEX we only check
> + * for mode in the index.
> + */
> + int pos = index_name_pos(istate, path, strlen(path));
> + if (pos >= 0)
> + mode = istate->cache[pos]->ce_mode;
> + else
> + return ATTR__UNSET;
> + }
> + strbuf_addf(&sb, "%06o", mode);
> + return sb.buf;
> +
The struct itself will be reclaimed as it is on stack, and sb.buf is
given back to the caller, so there technically is no leak, but I think
a more kosher way to do this involves the use of strbuf_detach().
Let's lose the blank line at the end of the function that is not
serving much useful purpose.
> void git_check_attr(struct index_state *istate,
> const char *path,
> struct attr_check *check)
> @@ -1253,7 +1314,7 @@ void git_check_attr(struct index_state *istate,
> unsigned int n = check->items[i].attr->attr_nr;
> const char *value = check->all_attrs[n].value;
> if (value == ATTR__UNKNOWN)
> - value = ATTR__UNSET;
> + value = compute_builtin_attr(istate, path, check->all_attrs[n].attr);
> check->items[i].value = value;
> }
> }
Nicely done.
> diff --git a/t/t0003-attributes.sh b/t/t0003-attributes.sh
> index aee2298f01..25aa3fbd05 100755
> --- a/t/t0003-attributes.sh
> +++ b/t/t0003-attributes.sh
> @@ -19,6 +19,16 @@ attr_check () {
> test_must_be_empty err
> }
>
> +attr_check_object_mode () {
> + path="$1" &&
> + expect="$2" &&
> + check_opts="$3" &&
> + git check-attr $check_opts builtin_objectmode -- "$path" >actual 2>err &&
> + echo "$path: builtin_objectmode: $expect" >expect &&
> + test_cmp expect actual
> + test_must_be_empty err
> +}
> +
> attr_check_quote () {
> path="$1" quoted_path="$2" expect="$3" &&
>
> @@ -558,4 +568,38 @@ test_expect_success EXPENSIVE 'large attributes file ignored in index' '
> test_cmp expect err
> '
>
> +test_expect_success 'native object mode attributes work' '
> + >exec && chmod +x exec && attr_check_object_mode exec 100755 &&
> + >normal && attr_check_object_mode normal 100644 &&
> + mkdir dir && attr_check_object_mode dir 040000 &&
Just a style thing, but we tend to write one statement on each line.
> + >to_sym ln -s to_sym sym && attr_check_object_mode sym 120000
> +'
You do not need to_sym file, do you? Symbolic links can be left
dangling.
In any case, the above test would not work on a filesystem without
native executable bit support. Also, you cannot do "ln -s" on
certain filesystems. It is a good idea to split the above into
three tests, one that is run unconditionally (for "normal" and
"dir"), another that is run under the POSIXPERM prerequisite, and
the third that is run under the SYNLINKS prerequisite.
> +test_expect_success 'native object mode attributes work with --cached' '
> + >normal && attr_check_object_mode normal unspecified --cached &&
> + git add normal && attr_check_object_mode normal 100644 --cached
> +'
For "--cached test", on the other hand, we should be able to set the
executable bit or record a symbolic link regardless of the
filesystem using "update-index", e.g.,
>normal && git add normal &&
empty_blob=$(git rev-parse :normal)
cat <<-EOF | git update-index --index-info
100755 $empty_blob 0 exec
120000 $empty_blob 0 symlink
EOF
attr_check_object_mode normal 100644 --cached &&
attr_check_object_mode exec 100755 --cached &&
attr_check_object_mode symlink 120000 --cached
or something.
> +test_expect_success 'check object mode attributes work for submodules' '
> + mkdir sub &&
> + (
> + cd sub &&
> + git init &&
> + mv .git .real &&
> + echo "gitdir: .real" >.git &&
> + test_commit first
> + ) &&
> + attr_check_object_mode sub 160000 &&
> + attr_check_object_mode sub unspecified --cached &&
> + git add sub &&
> + attr_check_object_mode sub 160000 --cached
> +'
Sounds good.
> +test_expect_success 'we do not allow user defined builtin_* attributes' '
> + echo "foo* builtin_foo" >.gitattributes &&
> + git add .gitattributes 2>actual &&
> + echo "builtin_foo is not a valid attribute name: .gitattributes:1" >expect &&
> + test_cmp expect actual
> +'
Another thing that is worth checking is what happens when there is an
conflicting entry:
echo "foo builtin_objectmode=200" >.gitattributes &&
>foo &&
attr_check_object_mode foo 100644
> test_done
> diff --git a/t/t6135-pathspec-with-attrs.sh b/t/t6135-pathspec-with-attrs.sh
> index a9c1e4e0ec..b08a32ea68 100755
> --- a/t/t6135-pathspec-with-attrs.sh
> +++ b/t/t6135-pathspec-with-attrs.sh
> @@ -295,4 +295,29 @@ test_expect_success 'reading from .gitattributes in a subdirectory (3)' '
> test_cmp expect actual
> '
>
> +test_expect_success 'pathspec with builtin_objectmode attr can be used' '
> + >mode_exec_file_1 &&
> +
> + git status -s ":(attr:builtin_objectmode=100644)mode_exec_*" >actual &&
> + echo ?? mode_exec_file_1 >expect &&
> + test_cmp expect actual &&
> +
> + git add mode_exec_file_1 && chmod +x mode_exec_file_1 &&
> + git status -s ":(attr:builtin_objectmode=100755)mode_exec_*" >actual &&
> + echo AM mode_exec_file_1 >expect &&
> + test_cmp expect actual
> +'
> +
> +test_expect_success 'builtin_objectmode attr can be excluded' '
> + >mode_1_regular &&
> + >mode_1_exec && chmod +x mode_1_exec &&
> + git status -s ":(exclude,attr:builtin_objectmode=100644)" "mode_1_*" >actual &&
> + echo ?? mode_1_exec >expect &&
> + test_cmp expect actual &&
> +
> + git status -s ":(exclude,attr:builtin_objectmode=100755)" "mode_1_*" >actual &&
> + echo ?? mode_1_regular >expect &&
> + test_cmp expect actual
> +'
> +
> test_done
^ permalink raw reply
* Re: [PATCH v5 0/3] rebase: support --autosquash without -i
From: Junio C Hamano @ 2023-11-16 0:27 UTC (permalink / raw)
To: Phillip Wood; +Cc: Andy Koppe, git, phillip.wood
In-Reply-To: <eb62435f-08ca-494d-bcc7-2568df2bd7fd@gmail.com>
Phillip Wood <phillip.wood123@gmail.com> writes:
> Hi Andy
> ...
> Thanks for the re-roll this version looks good to me
>
> Best Wishes
>
> Phillip
Yup, looks good. Thanks, both.
Queued.
>
>> Andy Koppe (3):
>> rebase: fully ignore rebase.autoSquash without -i
>> rebase: support --autosquash without -i
>> rebase: rewrite --(no-)autosquash documentation
>> Documentation/config/rebase.txt | 4 ++-
>> Documentation/git-rebase.txt | 34 +++++++++++++----------
>> builtin/rebase.c | 17 +++++-------
>> t/t3415-rebase-autosquash.sh | 38 +++++++++++++++++++-------
>> t/t3422-rebase-incompatible-options.sh | 12 --------
>> 5 files changed, 58 insertions(+), 47 deletions(-)
>>
^ permalink raw reply
* Re: [PATCH] commit-graph: disable GIT_COMMIT_GRAPH_PARANOIA by default
From: Junio C Hamano @ 2023-11-16 0:07 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: Jeff King, git, Karthik Nayak
In-Reply-To: <ZVTJFOSnVonoPgZk@tanuki>
Patrick Steinhardt <ps@pks.im> writes:
>> Yeah. Just like we auto-enabled GIT_REF_PARANOIA for git-gc, etc, I
>> think we should do the same here.
>
> I'm honestly still torn on this one. There are two cases that I can
> think of where missing objects would be benign and where one wants to
> use `git rev-list --missing`:
>
> - Repositories with promisor remotes, to find the boundary of where
> we need to fetch new objects.
>
> - Quarantine directories where you only intend to list new objects
> or find the boundary.
>
> And in neither of those cases I can see a path for how the commit-graph
> would contain such missing commits when using regular tooling to perform
> repository maintenance.
I can buy the promisor remotes use case---we may expect boundary
objects missing without any repository corruption. I do not know
about the other one---where does our "rev-list --missing" start
traversing in a quarantine directory is unclear. Objects that are
still in quarantine are not (yet) made reachable from any refs, so
even "rev-list --missing --all" would not make a useful traversal,
no?
In any case, it sounds like you are not torn but are convinced that
we should leave this loose by default ;-) and after thinking it over
again, I tend to agree that it would be a better choice, as long as
the feature "rev-list --missing" has any good use case other than
corruption in repository.
So,... thanks for pushing back.
^ permalink raw reply
* What is the best way to fix divergent branches during push
From: Mun Johl @ 2023-11-15 23:43 UTC (permalink / raw)
To: git@vger.kernel.org
Hi all,
Our team recently moved from SVN to git and occasionally we get our workspace in a snarl. I could use some advice on the best way to resolve our issue.
In general, this is what happens:
1. git pull
2. bunch of edits which could last hours to days
3. git add
4. git commit
4a. sometimes there is a delay here before the next step because the user forgets a push is needed; but that is not always the case and the end results are the same
5. git push
At this point we have divergent branches. Not surprising. However, some users say no matter if the try a pull with ff-only, merge, or rebase that they get errors from git (sorry, I don't have the exact error text--but I hear 'git pull' continues to complain about divergent branches).
What is the recommended method to correct the divergent branches issue so that the 'git push' can proceed successfully?
Are the steps outlined above incorrect? Should we insert the following steps:
2.a git stash
2.b git fetch
2.c git pull
2.d git stash pop
I think the added steps may minimize the probability of divergent branches, but it is certainly not ensuring divergent branches will not occur.
Any advice in this regard would be greatly appreciated.
Best regards,
--
Mun
^ permalink raw reply
* Re: [PATCH v2 0/5] Avoid hang if curl needs eof twice + minor related improvements
From: Jonathan Tan @ 2023-11-15 23:28 UTC (permalink / raw)
To: Jiří Hruška; +Cc: Jonathan Tan, git, Jeff King, Junio C Hamano
In-Reply-To: <CAGE_+C4mUw8U6YK0m6hRvcqriv4pWdsELpyRJBCY-LrdHjWwgw@mail.gmail.com>
Jiří Hruška <jirka@fud.cz> writes:
> Proposed changes split into several commits for clarity
>
> Jiri Hruska (5):
> remote-curl: avoid hang if curl asks for more data after eof
I've already reviewed this [1] so I'll summarize what I think of the
rest.
[1] https://lore.kernel.org/git/20231115192027.2468887-1-jonathantanmy@google.com/
> remote-curl: improve readability of curl callbacks
> remote-curl: simplify rpc_out() - remove superfluous ifs
> remote-curl: simplify rpc_out() - less nesting and rename
> http: reset CURLOPT_POSTFIELDSIZE_LARGE between requests
Overall I can see how all of these make the code clearer, but in a
long-lived project like Git where it is very common to look at code
history to try to see why something was written the way it is, I'm a
bit reluctant to include 2/5 and 4/5. I think 3/5 (removes an "if"),
the part of 4/5 where we set "rpc.pos = 0;", and 5/5 (sets a parameter
that one could expect to be set) have significant benefit and should be
included, though. Having said that, I don't have strong opposition to
including all of them.
^ permalink raw reply
* Re: [PATCH] ci: avoid running the test suite _twice_
From: Josh Steadmon @ 2023-11-15 21:28 UTC (permalink / raw)
To: Jeff King
Cc: Johannes Schindelin via GitGitGadget, Phillip Wood, git,
Johannes Schindelin
In-Reply-To: <20231113184909.GB3838361@coredump.intra.peff.net>
On 2023.11.13 13:49, Jeff King wrote:
> On Mon, Nov 13, 2023 at 05:00:37PM +0000, Johannes Schindelin via GitGitGadget wrote:
>
> > This is a late amendment of 19ec39aab54 (ci: stop linking the `prove`
> > cache, 2022-07-10), fixing a bug that had been hidden so far.
>
> We don't seem to have that commit in Junio's tree; it is only in
> git-for-windows.
>
> Not that we should not fix things if they are broken, but I am trying
> to understand if git/git is experiencing the same bug. It sounds like
> not yet, though from looking at 19ec39aab54, I would expect to get these
> doubled runs any time we store the prove state. But maybe without that
> commit our state-file symlink is going somewhere invalid, and prove
> fails to actually store anything?
>
> > But starting with that commit, we run `prove` _twice_ in CI, and with
> > completely different sets of tests to run. Due to the bug, the second
> > invocation re-runs all of the tests that were already run as part of the
> > first invocation. This not only wastes build minutes, it also frequently
> > causes the `osx-*` jobs to fail because they already take a long time
> > and now are likely to run into a timeout.
> >
> > The worst part about it is that there is actually no benefit to keep
> > running with `--state=slow,save`, ever since we decided no longer to
> > try to reuse the Prove cache between CI runs.
> >
> > So let's just drop that Prove option and live happily ever after.
>
> Yes, I think this is the right thing to do regardless. If we are not
> saving the state to use between two related runs, there is no point
> storing it in the first place.
>
> I do have to wonder, though, as somebody who did not follow the
> unit-test topic closely: why are the unit tests totally separate from
> the rest of the suite? I would think we'd want them run from one or more
> t/t*.sh scripts. That would make bugs like this impossible, but also:
>
> 1. They'd be run via "make test", so developers don't have to remember
> to run them separately.
>
> 2. They can be run in parallel with all of the other tests when using
> "prove -j", etc.
The first part is easy, but I don't see a good way to get both shell
tests and unit tests executing under the same `prove` process. For shell
tests, we pass `--exec '$(TEST_SHELL_PATH_SQ)'` to prove, meaning that
we use the specified shell as an interpreter for the test files. That
will not work for unit test executables.
We could bundle all the unit tests into a single shell script, but then
we lose parallelization and add hoops to jump through to determine what
breaks. Or we could autogenerate a corresponding shell script to run
each individual unit test, but that seems gross. Of course, these are
hypothetical concerns for now, since we only have a single unit test at
the moment.
There's also the issue that the shell test arguments we pass on from
prove would be shared with the unit tests. That's fine for now, as
t-strbuf doesn't accept any runtime arguments, but it's possible that
either the framework or individual unit tests might grow to need
arguments, and it might not be convenient to stay compatible with the
shell tests.
Personally, I lean towards keeping things simple and just running a
second `prove` process as part of `make test`. If I was forced to pick a
way to get everything under one process, I'd lean towards autogenerating
individual shell script wrappers for each unit test. But I'm open to
discussion, especially if people have other approaches I haven't thought
of.
^ permalink raw reply
* Re: Bug: "Received" misspelled in remote message
From: Konstantin Ryabitsev @ 2023-11-15 19:45 UTC (permalink / raw)
To: Alan Dove; +Cc: git
In-Reply-To: <4e76dda1009a8365a1d66d9594865a4af31ab418.camel@gmail.com>
On Wed, Nov 15, 2023 at 01:46:10PM -0500, Alan Dove wrote:
> Hello:
>
> Using Git 2.40.1 on a private server, I see this message whenever I
> push a commit:
>
> "remote: Recieved update on checked-out branch, queueing deployment."
>
> "Received" is misspelled.
>
> I realize this is a very minor issue, but it should also be very easy
> to correct. As someone who suffers from Proofreader's Eye, this error
> deals psychic damage to me on a daily basis.
It's most likely coming from some CI/CD hook deployed on the server where
you're pushing, so you should reach out to your IT to have the spelling fixed.
In other words, the message is not coming from any software that is managed by
the git project itself (at least, nothing matches "recieved" in the git
repository tree).
Best regards,
-K
^ permalink raw reply
* PROPOSAL
From: BPBVI @ 2023-11-15 19:37 UTC (permalink / raw)
To: git
Hello,
Attached is a contract document for your review. Revert accordingly.
Thank You
Felix H
Project Manager
BPOPULARBVI
^ permalink raw reply
* Re: Bug: "Received" misspelled in remote message
From: Eric Wong @ 2023-11-15 19:26 UTC (permalink / raw)
To: Alan Dove; +Cc: git
In-Reply-To: <4e76dda1009a8365a1d66d9594865a4af31ab418.camel@gmail.com>
Alan Dove <alan.dove@gmail.com> wrote:
> Hello:
>
> Using Git 2.40.1 on a private server, I see this message whenever I
> push a commit:
>
> "remote: Recieved update on checked-out branch, queueing deployment."
Hi Alan, that's likely from a hook on the server itself.
Those phrases aren't a part of git at all.
^ permalink raw reply
* Re: [PATCH v2 1/5] remote-curl: avoid hang if curl asks for more data after eof
From: Jonathan Tan @ 2023-11-15 19:20 UTC (permalink / raw)
To: Jiří Hruška; +Cc: Jonathan Tan, git, Jeff King, Junio C Hamano
In-Reply-To: <CAGE_+C4JWA0DrcV4rT7J6hXsbYPL2Po31wFPvLESe_sKq_16FQ@mail.gmail.com>
Jiří Hruška <jirka@fud.cz> writes:
> It has been observed that under some circumstances, libcurl can call
> our `CURLOPT_READFUNCTION` callback `rpc_out()` again even after
> already getting a return value of zero (EOF) back once before.
>
> Because `rpc->flush_read_but_not_sent` is reset to false immediately
> the first time an EOF is returned, the repeated call goes again to
> `rpc_read_from_out()`, which tries to read more from the child process
> pipe and the whole operation gets stuck - the child process is already
> trying to read a response back and will not write anything to the
> output pipe anymore, while the parent/remote process is now blocked
> waiting to read more too and never even finishes sending the request.
>
> The bug is fixed by moving the reset of the `flush_read_but_not_sent`
> flag to `post_rpc()`, only before `rpc_out()` would be potentially used
> the next time. This makes the callback behave like fread() and return
> a zero any number of times at the end of a finished upload.
>
> Signed-off-by: Jiri Hruska <jirka@fud.cz>
Thanks for splitting this out - this makes it much easier to review. I
can see that the patch indeed works, but some things need to be clearer
(described below).
In the commit message, I think we should add a historical note,
something like:
`flush_read_but_not_sent` was introduced in a97d00799a (remote-curl:
use post_rpc() for protocol v2 also, 2019-02-21), which needed a way to
indicate that Git should not read from a certain child process anymore
once "flush" has been received from the child process. This field was
scoped to what was believed the minimum necessary - the interval between
"flush" being received and EOF being reported to Curl.
However, as described at the beginning of the commit message, we need
the scope of this to be greater than that - in case Curl continues to
ask us for more data, we still need to remember that "flush" has been
received. Therefore, change this field from `flush_read_but_not_sent` to
`flush_read`, which both is simpler and is a fix for this bug.
Feel free to use this verbatim, or adapt it as you wish (or write your
own).
As described in the historical note, I also think we need to change the
name of this field, since we are changing its semantics.
I am trying to be better at indicating when I think a prefix subset of
a patch set is worth merging on its own (so that, if some patches in
a patch set are good and some still need to be discussed, we have the
option of merging a prefix of a patch set). So, assuming my comments are
addressed, I think this patch is good to go in on its own, even if we
don't want some of the later patches. I'll review the rest of this patch
set later.
^ permalink raw reply
* [PATCH v2] RelNotes: tweak 2.43.0 release notes
From: Andy Koppe @ 2023-11-15 19:07 UTC (permalink / raw)
To: git; +Cc: Andy Koppe
In-Reply-To: <20231114223127.11292-1-andy.koppe@gmail.com>
Add some more detail on the $(decorate) log format placeholder and tweak
the wording on some other points.
Signed-off-by: Andy Koppe <andy.koppe@gmail.com>
---
Now with 100% more signature. Sorry for the unnecessary noise.
Documentation/RelNotes/2.43.0.txt | 20 +++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/Documentation/RelNotes/2.43.0.txt b/Documentation/RelNotes/2.43.0.txt
index 770543c464e..9a68074a4a5 100644
--- a/Documentation/RelNotes/2.43.0.txt
+++ b/Documentation/RelNotes/2.43.0.txt
@@ -10,8 +10,8 @@ Backward Compatibility Notes
prefix. If you are negatively affected by this change, please use
"--subject-prefix=PATCH --rfc" as a replacement.
- * "git rev-list --stdin" learned to take non-revisions (like "--not")
- recently from the standard input, but the way such a "--not" was
+ * "git rev-list --stdin" recently learned to take non-revisions (like
+ "--not") from the standard input, but the way such a "--not" was
handled was quite confusing, which has been rethought. The updated
rule is that "--not" given from the command line only affects revs
given from the command line that comes but not revs read from the
@@ -43,10 +43,10 @@ UI, Workflows & Features
* Git GUI updates.
- * "git format-patch" learns a way to feed cover letter description,
- that (1) can be used on detached HEAD where there is no branch
- description available, and (2) also can override the branch
- description if there is one.
+ * "git format-patch" learns option "--description-file" to feed in a
+ cover letter description that can be used when no branch description
+ is available, or that can override the branch description if there is
+ one.
* Use of --max-pack-size to allow multiple packfiles to be created is
now supported even when we are sending unreachable objects to cruft
@@ -56,7 +56,9 @@ UI, Workflows & Features
"--subject-prefix" option and used "[RFC PATCH]"; now we will add
"RFC" prefix to whatever subject prefix is specified.
- * "git log --format" has been taught the %(decorate) placeholder.
+ * "git log" format strings now support a "%(decorate)" placeholder that
+ can be used to customize the symbols and the tag prefix used in ref
+ decorations.
* The default log message created by "git revert", when reverting a
commit that records a revert, has been tweaked, to encourage people
@@ -99,7 +101,7 @@ UI, Workflows & Features
* The attribute subsystem learned to honor `attr.tree` configuration
that specifies which tree to read the .gitattributes files from.
- * "git merge-file" learns a mode to read three contents to be merged
+ * "git merge-file" learns a mode to read three files to be merged
from blob objects.
@@ -127,7 +129,7 @@ Performance, Internal Implementation, Development Support etc.
* The code to keep track of existing packs in the repository while
repacking has been refactored.
- * The "streaming" interface used for bulk-checkin codepath has been
+ * The "streaming" interface used for the bulk-checkin codepath has been
narrowed to take only blob objects for now, with no real loss of
functionality.
--
2.43.0-rc1
^ permalink raw reply related
* Bug: "Received" misspelled in remote message
From: Alan Dove @ 2023-11-15 18:46 UTC (permalink / raw)
To: git
Hello:
Using Git 2.40.1 on a private server, I see this message whenever I
push a commit:
"remote: Recieved update on checked-out branch, queueing deployment."
"Received" is misspelled.
I realize this is a very minor issue, but it should also be very easy
to correct. As someone who suffers from Proofreader's Eye, this error
deals psychic damage to me on a daily basis.
Thanks.
--
--Alan
Alan Dove, Ph.D.
alandove.com
917.273.0544
^ permalink raw reply
* Re: [PATCH] docs: submitting-patches: improve the base commit explanation
From: Borislav Petkov @ 2023-11-15 18:07 UTC (permalink / raw)
To: Kees Cook; +Cc: Jonathan Corbet, workflows, linux-doc, LKML, git
In-Reply-To: <202311150948.F6E39AD@keescook>
On Wed, Nov 15, 2023 at 09:49:31AM -0800, Kees Cook wrote:
> On Wed, Nov 15, 2023 at 06:03:30PM +0100, Borislav Petkov wrote:
> > From: "Borislav Petkov (AMD)" <bp@alien8.de>
> >
> > After receiving a second patchset this week without knowing which tree
> > it applies on and trying to apply it on the obvious ones and failing,
> > make sure the base tree information which needs to be supplied in the
> > 0th message of the patchset is spelled out more explicitly.
> >
> > Also, make the formulations stronger as this really is a requirement and
> > not only a useful thing anymore.
> >
> > Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
>
> Yup, I wonder if making "--base=auto" a default in git might be a good
> idea too?
Not a bad idea. And if not needed, one can simply ignore it when reading
the cover letter.
CCing the git ML for comment/opinions.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply
* [RFC PATCH v2 2/2] send-email: remove stray characters from usage
From: Todd Zullinger @ 2023-11-15 17:39 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, Ævar Arnfjörð Bjarmason,
Ondřej Pohořelský
In-Reply-To: <20231115173952.339303-1-tmz@pobox.com>
A few stray single quotes crept into the usage string in a2ce608244
(send-email docs: add format-patch options, 2021-10-25). Remove them.
Signed-off-by: Todd Zullinger <tmz@pobox.com>
---
This is not scrictly tied to the previous commit. It just stood out
while I was reviewing the usage output.
git-send-email.perl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 94046e0fb7..cd2f0ae14e 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -28,8 +28,8 @@
sub usage {
print <<EOT;
-git send-email' [<options>] <file|directory>
-git send-email' [<options>] <format-patch options>
+git send-email [<options>] <file|directory>
+git send-email [<options>] <format-patch options>
git send-email --dump-aliases
Composing:
--
2.43.0.rc2
^ permalink raw reply related
* [RFC PATCH v2 1/2] send-email: avoid duplicate specification warnings
From: Todd Zullinger @ 2023-11-15 17:39 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, Ævar Arnfjörð Bjarmason,
Ondřej Pohořelský
In-Reply-To: <20231115173952.339303-1-tmz@pobox.com>
With perl-Getopt-Long >= 2.55 a warning is issued for options which are
specified more than once. In addition to causing users to see warnings,
this results in test failures which compare the output. An example,
from t9001-send-email.37:
| +++ diff -u expect actual
| --- expect 2023-11-14 10:38:23.854346488 +0000
| +++ actual 2023-11-14 10:38:23.848346466 +0000
| @@ -1,2 +1,7 @@
| +Duplicate specification "no-chain-reply-to" for option "no-chain-reply-to"
| +Duplicate specification "to-cover|to-cover!" for option "to-cover"
| +Duplicate specification "cc-cover|cc-cover!" for option "cc-cover"
| +Duplicate specification "no-thread" for option "no-thread"
| +Duplicate specification "no-to-cover" for option "no-to-cover"
| fatal: longline.patch:35 is longer than 998 characters
| warning: no patches were sent
| error: last command exited with $?=1
| not ok 37 - reject long lines
Remove the duplicate option specs.
Teach `--git-completion-helper` to output the '--no-' options. They are
not included in the options hash and would otherwise be lost.
Signed-off-by: Todd Zullinger <tmz@pobox.com>
---
I compared the output from
git send-email --git-completion-helper | tr ' ' ' '\n' | sort
before and after the change to ensure no options were lost (or added).
I also confirmed that each of the options changed did not result in any
error. Unrecognized options result in an error from `git format-patch`,
e.g.:
$ git send-email --foo
fatal: unrecognized argument: --foo
format-patch -o /tmp/PaqtbH3jCw --foo: command returned error: 128
A little history:
Support for the '--no-' prefix was added in Getopt::Long >= 2.33, in
commit 8ca8b48 (Negatable options (with "!") now also support the
"no-" prefix., 2003-04-04). Getopt::Long 2.34 was included in
perl-5.8.1 (2003-09-25), per Module::CoreList[1].
We list perl-5.8 as the minimum version in INSTALL. This would leave
users with perl-5.8.0 (2002-07-18) with non-working arguments for
options where we're removing the explicit 'no-' variant.
The explicit 'no-' opts were added in f471494303 (git-send-email.perl:
support no- prefix with older GetOptions, 2015-01-30), specifically to
support perl-5.8.0 which includes the older Getopt::Long.
It may be time to bump the Perl requirement to 5.8.1 (2003-09-25) or
even 5.10.0 (2007-12-18). We last bumped the requirement from 5.6 to
5.8 in d48b284183 (perl: bump the required Perl version to 5.8 from
5.6.[21], 2010-09-24).
Another option to avoid the warning from Getopt::Long >= 2.55 would be
to remove the '!' negation, but that would drop support for the 'no'
prefix variants (e.g.: `--nocc-cover`). While these are not documented
(and I don't think they ever were[2]), they have worked for a long, long
time. Odds are good that some scripts rely on them and we don't want
anyone yelling at Junio.
I lean toward dropping support for the 21-year-old 5.8.0.
If there is a way to have our cake without any consequence, I'm happy to
hear it. If not, I'll add a commit which bumps the requirement in
general or notes that some git-send-email requires perl >= 5.8.1 and
adjusts the 'use' line there to `use 5.008001;`.
[1] http://perlpunks.de/corelist/mversion?module=Getopt%3A%3ALong
[2] The 'no-' opts were added in f471494303 (git-send-email.perl:
support no- prefix with older GetOptions, 2015-01-30). The commit
message says "the help only mentions the 'no-' prefix and not the
'no' prefix, add explicit support for the 'no-' prefix to support
older GetOptions versions."
git-send-email.perl | 19 ++++++-------------
1 file changed, 6 insertions(+), 13 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index cacdbd6bb2..94046e0fb7 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -119,13 +119,16 @@ sub completion_helper {
foreach my $key (keys %$original_opts) {
unless (exists $not_for_completion{$key}) {
- $key =~ s/!$//;
+ my $negate = ($key =~ s/!$//);
if ($key =~ /[:=][si]$/) {
$key =~ s/[:=][si]$//;
push (@send_email_opts, "--$_=") foreach (split (/\|/, $key));
} else {
push (@send_email_opts, "--$_") foreach (split (/\|/, $key));
+ if ($negate) {
+ push (@send_email_opts, "--no-$_") foreach (split (/\|/, $key));
+ }
}
}
}
@@ -491,7 +494,6 @@ sub config_regexp {
"bcc=s" => \@getopt_bcc,
"no-bcc" => \$no_bcc,
"chain-reply-to!" => \$chain_reply_to,
- "no-chain-reply-to" => sub {$chain_reply_to = 0},
"sendmail-cmd=s" => \$sendmail_cmd,
"smtp-server=s" => \$smtp_server,
"smtp-server-option=s" => \@smtp_server_options,
@@ -506,36 +508,27 @@ sub config_regexp {
"smtp-auth=s" => \$smtp_auth,
"no-smtp-auth" => sub {$smtp_auth = 'none'},
"annotate!" => \$annotate,
- "no-annotate" => sub {$annotate = 0},
"compose" => \$compose,
"quiet" => \$quiet,
"cc-cmd=s" => \$cc_cmd,
"header-cmd=s" => \$header_cmd,
"no-header-cmd" => \$no_header_cmd,
"suppress-from!" => \$suppress_from,
- "no-suppress-from" => sub {$suppress_from = 0},
"suppress-cc=s" => \@suppress_cc,
"signed-off-cc|signed-off-by-cc!" => \$signed_off_by_cc,
- "no-signed-off-cc|no-signed-off-by-cc" => sub {$signed_off_by_cc = 0},
- "cc-cover|cc-cover!" => \$cover_cc,
- "no-cc-cover" => sub {$cover_cc = 0},
- "to-cover|to-cover!" => \$cover_to,
- "no-to-cover" => sub {$cover_to = 0},
+ "cc-cover!" => \$cover_cc,
+ "to-cover!" => \$cover_to,
"confirm=s" => \$confirm,
"dry-run" => \$dry_run,
"envelope-sender=s" => \$envelope_sender,
"thread!" => \$thread,
- "no-thread" => sub {$thread = 0},
"validate!" => \$validate,
- "no-validate" => sub {$validate = 0},
"transfer-encoding=s" => \$target_xfer_encoding,
"format-patch!" => \$format_patch,
- "no-format-patch" => sub {$format_patch = 0},
"8bit-encoding=s" => \$auto_8bit_encoding,
"compose-encoding=s" => \$compose_encoding,
"force" => \$force,
"xmailer!" => \$use_xmailer,
- "no-xmailer" => sub {$use_xmailer = 0},
"batch-size=i" => \$batch_size,
"relogin-delay=i" => \$relogin_delay,
"git-completion-helper" => \$git_completion_helper,
--
2.43.0.rc2
^ permalink raw reply related
* [RFC PATCH v2 0/2] send-email: avoid duplicate specification warnings
From: Todd Zullinger @ 2023-11-15 17:39 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, Ævar Arnfjörð Bjarmason,
Ondřej Pohořelský
In-Reply-To: <xmqqy1ezx2mq.fsf@gitster.g>
Changes since v1:
* Teach `--git-completion-helper` to output the '--no-' options.
They are not included in the options hash and would otherwise be
lost.
* Restore the `--signed-off-cc` alias which was mistakenly removed.
Todd Zullinger (2):
send-email: avoid duplicate specification warnings
send-email: remove stray characters from usage
git-send-email.perl | 23 ++++++++---------------
1 file changed, 8 insertions(+), 15 deletions(-)
--
2.43.0.rc2
^ permalink raw reply
* Re: Git Rename Detection Bug
From: Philip Oakley @ 2023-11-15 16:51 UTC (permalink / raw)
To: Elijah Newren, Jeremy Pridmore; +Cc: git@vger.kernel.org, Paul Baumgartner
In-Reply-To: <CABPp-BHEX+SyophEfgRqDbNdrAS3=bptt_cKzHLBSutnBAxexw@mail.gmail.com>
Hi Elijah,
On 11/11/2023 05:46, Elijah Newren wrote:
> * filename similarity is extraordinarily expensive compared to exact
> renames, and if not carefully handled, can sometimes rival the cost of
> file content similarity computations given our spanhash
> representations.
I've not heard of spanhash representation before. Any references or
further reading?
> Exact renames are tasked with finding renames even
> if they are known to not be relevant, simply because exact renames can
> do so very quickly. If we change that, we throw a monkey wrench in
> our performance handling elsewhere and have to rethink a number of
> other things.
--
Philip
^ permalink raw reply
* gitmodulesSymlink .gitmodules is a symbolic link
From: flobee.code @ 2023-11-15 16:01 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 185 bytes --]
Hi
I can not rebase symlinks of an 6 years old repository.
See attached files (two languages, EN auto translation) for more details.
Created with `git bugreport`
Kind regards
Florian
[-- Attachment #2: git-bugreport-2023-11-15-1605-EN.txt --]
[-- Type: text/plain, Size: 7152 bytes --]
[EN](#EN) Translated by https://www.deepl.com/translator
# EN
Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your problem.
understand your problem.
What did you do before the error occurred? (Steps to reproduce your error
reproduce your error)
For 6 years I only did remote pushes locally to my local master.
github.com then refused to accept one.
The reason:
And now github.com but also `git` itself are bitching in detail.
github.com, as it no longer accepts a push:
index-pack failed
remote: error: object [hash]: gitmodulesSymlink: .gitmodules is a symbolic link
And `git` itself also aborts. So I can't solve the problems this way.
git filter-branch --tree-filter 'rm -f .gitmodules' HEAD
Rewrite [SomeHash] (3/185) (0 seconds passed, remaining 0 predicted) \
error: Invalid path '.gitmodules' Could not initialize the index
The same attempt also failed with an older VM where `git`
version 2.11.0 was still available.
What did you expect to happen? (Expected behavior)
Rebase should work. Always :-)
What happened instead? (Actual behavior)
Abort of git.
git filter-branch --tree-filter 'rm -f .gitmodules' HEAD
Rewrite [SomeHash] (3/185) (0 seconds passed, remaining 0 predicted) \
error: Invalid path '.gitmodules' Could not initialize the index
What is the difference between what you expected and what actually happened?
really happened?
With a current git version I can't fix such errors.
But in general I think the exclusion of symlinks to git system files is a mistake. It is implemented too sweepingly in my eyes.
Any other comments you would like to add:
My `.gitmodules` were always a matching file in the same directory to
to become aware that something is changing during a merge.
Branches are staging areas for me, among other things)
```
.gitmodules -> symlinks to one of these files
(depending on the current branch)
-> .gitmodules_stable
^ ------------------ Staging to stable, release
-> .gitmodules_testing
^ ------------------ Staging to testing, testing and preview
-> .gitmodules_unstable
^ ^ ^---<---------<-- Feature branch A
+-----<---------<-- Feature branch B
+-------<---------<-- Feature branch C ...
```
With a merge unstable -> testing (-ff), settings from unstable would simply be
would simply be included/adopted in testing without drawing attention to it.
attention. This also has the consequence that you are no longer made aware
that the dependencies of the submodules must also be raised,
before the merge is clean/finished.
If you are working on several submodules, this makes perfect sense. Especially
if you don't have or want to have everything online in order to check/test the current
to check/test the current status etc. before you then bind the hashes of the submodules and
then make everything public piece by piece depending on the dependency.
What an effort :-/
With `git` itself (version 2.39.0, Debian Bookworm, 2023) you can still work locally.
continue to work. With github.com, however, the fun is over. If it is in the
repository `git` system files like `.gitignore` or `.gitmodules` that are symlinks
are symlinks, github.com refuses to do any work to fix the bugs.
the bugs. Neither via the web interface nor via `git push --force` itself. Whew.
So: After 6 years! In between there were local updates from time to time, but these were
were not made public. The operating system, a Debian, is updated about every
updated every two years. So there have been at least 3 new `git` versions since then for
for this project. With the current version of `git` I cannot fix the problems
fix the problems. And that is really bad!
## Solution
Option 3. was the solution. A Debian Wheezy (7.3) brought a `git`
version 1.7.10.4, which I used to rebase one of the known and problematic commits.
known and problematic commits. I may have traveled too far into the
past, but this gave me a basis for testing.
Maybe it will stay that way and everything will be fine again?
Following this, and in order to do everything automatically again, the
git filter-branch came to mind again:
git filter-branch --tree-filter 'rm -f .gitmodules' HEAD
Did its job, but didn't help anything Direction github.com as `push --force` for
for this branch.
- git filter-branch --tree-filter 'rm -f .gitmodules' HEAD
+ git filter-branch --tree-filter 'rm -f .gitmodules'
So: complete and over everything please.
But to make this situation tidy:
.gitmodules ->- symlink to one of these... ->-
-> .gitmodules_master
-> .gitmodules_stable
-> .gitmodules_testing
-> .gitmodules_unstable
'rm -f .gitmodules' deletes, but does not delete the underlying bindings of the
submodules. Here, too, there were mixtures in the use/application, as the
history clearly showed on closer inspection. But the roadmap for doing it this way
remained consistent.
I had to fetch the local repository from the backup quite often in order to be able to repeat the many test steps.
to be able to repeat the many steps of tests...
Finally: Submodules (`.gitmodules`) were always a symlink in the idea.
So in order for it to fit for the repair in the future, all symlinks must be resolved into a
real file, so that the rebase via `git filter-branch
--tree-filter` can run cleanly and the dependencies in the base remain clean.
remain clean. And that looks like this:
# If .gitmodules is a symlink:
# - Find the path to the real file
# - Delete the symlink
# - Copy the real file to .gitmodules
git filter-branch --tree-filter \
'if [ -h .gitmodules ];then loc=$(readlink .gitmodules); rm -f .gitmodules; cp $loc .gitmodules; fi;'
This solved the problem. Symlinks removed and replaced with the real content
replaced by the real content. However, the complete history has now been rewritten. Locally as
as well as the newer `git` versions (clients and local server) reported
no more errors.
# Conclusion
I don't like the way `git` currently works. Symlinks help in
my case. They are transparent and available in every branch within the repository
and are maintained.
The most important thing: they make work easier as they draw attention to changes.
changes. This saves an enormous amount of time and running around afterwards if you forget to
to correct the submodules because with an almost forward merge it is simply treated
treated as new = better. Submodules are bound in the same branch workflow
in the same branch workflow.
Please check the rest of the error report below.
You can delete any line you do not want to report.
[System Info]
git Version:
git version 2.39.2
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 6.1.0-13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1 (2023-09-29) x86_64
Compiler Info: gnuc: 12.2
libc Info: glibc: 2.36
$SHELL (typically, interactive shell): /bin/zsh
[Aktivierte Hooks]
[-- Attachment #3: git-bugreport-2023-11-15-1605.txt --]
[-- Type: text/plain, Size: 7360 bytes --]
[DE](#DE)
[EN] See other text file
# DE
Vielen Dank für das Ausfüllen eines Git-Fehlerberichts!
Bitte antworten Sie auf die folgenden Fragen, um uns dabei zu helfen, Ihr
Problem zu verstehen.
Was haben Sie gemacht, bevor der Fehler auftrat? (Schritte, um Ihr Fehler
zu reproduzieren)
6 Jahre lang habe ich nur lokal zu meinem lokalen master remote pushes gemacht.
github.com hat dann eine Annahme verweigert.
Der Grund:
Und nun sind github.com aber auch `git` selbst im Detail zickig.
github.com, da es einen Push nicht mehr akzeptiert:
index-pack failed
remote: error: object [hash]: gitmodulesSymlink: .gitmodules is a symbolic link
Und `git` selbst bricht auch ab. Ich kann die Probleme so also nicht lösen.
git filter-branch --tree-filter 'rm -f .gitmodules' HEAD
Rewrite [SomeHash] (3/185) (0 seconds passed, remaining 0 predicted) \
error: Invalid path '.gitmodules' Could not initialize the index
Der gleiche Versuch scheiterte ebenfalls mit einer älteren VM, wo noch `git`
Version 2.11.0 verfügbar war.
Was haben Sie erwartet, was passieren soll? (Erwartetes Verhalten)
Rebase soll funktionieren. Immer :-)
Was ist stattdessen passiert? (Wirkliches Verhalten)
Abbruch von git.
git filter-branch --tree-filter 'rm -f .gitmodules' HEAD
Rewrite [SomeHash] (3/185) (0 seconds passed, remaining 0 predicted) \
error: Invalid path '.gitmodules' Could not initialize the index
Was ist der Unterschied zwischen dem, was Sie erwartet haben und was
wirklich passiert ist?
Mit einer aktuellen git Version kann ich derartige Fehler nicht bereinigen.
Aber ansich halte ich das ausgrenzen von symlinks zu git system Dateien für einen Fehler. Es ist zu Pauschal in meinen Augen implementiert.
Sonstige Anmerkungen, die Sie hinzufügen möchten:
Meine `.gitmodules` waren immer eine passende Datei im gleichen Verzeichnis, um
bei einem Merge darauf aufmerksam zu werden, das sich etwas ändert.
Branches sind bei mir u.a Staging- Bereiche)
```
.gitmodules -> symlinks zu einer dieser Dateien
(abhängig zum aktuellen Branch)
-> .gitmodules_stable
^ ------------------ Staging to stable, release
-> .gitmodules_testing
^ ------------------ Staging to testing, testing and preview
-> .gitmodules_unstable
^ ^ ^---<---------<-- Feature branch A
| +-----<---------<-- Feature branch B
+-------<---------<-- Feature branch C ...
```
Bei einem merge unstable -> testing (-ff) würden Einstellungen von unstable
einfach in testing mit einbezogen/übernommen werden, ohne darauf aufmerksam zu
werden. Was auch zur Folge hat, dass man nicht mehr darauf aufmerksam gemacht
wird, das die Abhängigkeiten der Submodule ebenfalls angehoben werden müssen,
bevor der merge sauber/ fertig ist.
Wenn an mehreren Submodulen gearbeitet wird, macht das durchaus Sinn. Gerade
dann, wenn man eben nicht alles online hat oder haben will, um einen aktuellen
Stand zu prüfen/testen etc. bevor man dann die Hashes der Submodule bindet und
alles dann je nach Abhängigkeit Stück für Stück öffentlich stellt.
Was für ein Aufwand :-/
Mit `git` selbst (Version 2.39.0, Debian Bookworm, 2023) kann man lokal noch
weiter arbeiten. Bei github.com ist allerdings Schluss mit lustig. Wenn es im
Repository `git` System Dateien gibt wie `.gitignore` oder `.gitmodules` die
Symlinks sind, verweigert github.com jegliche Arbeit, die Bugs beseitigen zu
können. Weder über das Webinterface noch via `git push --force` selbst. Uff.
Also: Nach 6 Jahren! Dazwischen gab es lokal immer wieder mal Updates, die aber
nicht öffentlich gestellt wurden. Das Betriebssystem, ein Debian, wird etwa alle
zwei Jahre aktualisiert. Neue `git` Versionen sind also mind. 3 Stk. seither für
dieses Projekt dabei. Mit der aktuellen Version von `git` kann ich die Probleme
allerdings nicht beheben. Und das ist wirklich schlecht!
## Lösungsweg
Option 3. war dann die Lösung. Ein Debian Wheezy (7.3) brachte eine `git`
Version 1.7.10.4 mit, mit der ich einen Rebase auf einen der mir bekannten und
problembehafteten Commits zulies. Ich bin vielleicht zu weit in die
Vergangenheit gereist, aber hiermit hatte ich erst einmal eine Basis zum testen.
Vielleicht bleibt es so und alles ist wieder gut!?
Darauf folgend und, um wieder automatisch alles zu erledigen, kam mir der
git filter-branch wieder in den Gedanken:
git filter-branch --tree-filter 'rm -f .gitmodules' HEAD
Tat seinen Dienst, half aber nichts Richtung github.com als `push --force` für
diesen Branch.
- git filter-branch --tree-filter 'rm -f .gitmodules' HEAD
+ git filter-branch --tree-filter 'rm -f .gitmodules'
Also: komplett und über alles bitte.
Damit diese Situation aber ordentlich wird:
.gitmodules ->- symlink zum einem dieser... ->-
-> .gitmodules_master
-> .gitmodules_stable
-> .gitmodules_testing
-> .gitmodules_unstable
'rm -f .gitmodules' löscht, löst aber nicht die zugrunde liegenden Bindungen der
Submodule. Auch hier gab es Mischungen in der Nutzung/ Verwendung, wie die
Historie beim genauen betrachten deutlich zeigte. Aber der Fahrplan, es so zu
machen, blieb einheitlich.
Ich habe das lokale Repository recht oft aus dem Back-up holen müssen, um dann
die vielen Steps von Tests wiederholen zu können...
Schließlich: Submodule (`.gitmodules`) waren in der Idee immer ein Symlink.
Damit es zukünftig für die Reparatur passt, müssen also alle symlinks in eine
echte Datei aufgelöst werden, damit der rebase via `git filter-branch
--tree-filter` sauber laufen kann und die Abhängigkeiten in der Basis sauber
bleiben. Und das sieht dann wie folgt aus:
# Wenn .gitmodules ein symlink ist:
# - Finde den Pfad zur echten Datei
# - Lösche den Symlink
# - Kopiere die echte Datei zu .gitmodules
git filter-branch --tree-filter \
'if [ -h .gitmodules ];then loc=$(readlink .gitmodules); rm -f .gitmodules; cp $loc .gitmodules; fi;'
Damit war dieses Problem erledigt. Symlinks weg und durch den echten Inhalt
getauscht. Allerdings wurde nun die komplette History neu geschrieben. Lokal als
auch die neueren `git` Versionen (Klienten und lokaler Server) meldeten
keinerlei Fehler mehr.
# Fazit
Ich mag diese Funktionsweise von `git` aktuell hierzu nicht. Symlinks helfen in
meinem Fall. Sie sind transparent und in jedem Branch innerhalb des Repositories
verfügbar und werden gepflegt.
Das wichtigste: Sie erleichten die Arbeit da sie auf Veränderungen aufmerksam
machen. Das spart ungemein viel Zeit und das hinterher laufen wenn man vergisst
die Submodule zu korrigieren da es bei einem fast forward merge schlicht weg
als neu = besser behandeld wird. Submudule werden im gleichen branch-Workflow
so gebunden.
Bitte überprüfen Sie den restlichen Teil des Fehlerberichts unten.
Sie können jede Zeile löschen, die Sie nicht mitteilen möchten.
[System Info]
git Version:
git version 2.39.2
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 6.1.0-13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1 (2023-09-29) x86_64
Compiler Info: gnuc: 12.2
libc Info: glibc: 2.36
$SHELL (typically, interactive shell): /bin/zsh
[Aktivierte Hooks]
# EN
^ permalink raw reply
* Re: Git Rename Detection Bug
From: Philip Oakley @ 2023-11-15 15:35 UTC (permalink / raw)
To: Junio C Hamano, Elijah Newren
Cc: Jeremy Pridmore, git@vger.kernel.org, Paul Baumgartner
In-Reply-To: <xmqqzfzimuv2.fsf@gitster.g>
On 12/11/2023 23:09, Junio C Hamano wrote:
> Elijah Newren <newren@gmail.com> writes:
>
>>> Could I suggest that we are missing a piece of terminology, to wit,
>>> BLOBSAME. It's a compatriot to TREESAME, as used in `git log` for
>>> history simplification (based on a tree's pathspec, most commonly a
>>> commit's top level path).
>>
>> We could add it, but I'm not sure how it helps. We already had 'exact
>> rename' which seems to fit the bill as well, and 'blob' is something
>> someone new to Git is unlikely to know.
>
> Also, as Philip said, TREESAME is a concept foreign to rename
> detection codepath. It is a property of a commit (not a tree)
That (property of a commit?) wasn't really obvious to me.
I'd always thought of it as a comparison between two trees, commonly
those associated with two commits. Though it could also be thought of as
the operation "TREESAME to" that binds in the second tree.
and
> tells us if it has the same tree object as its relevant parents (in
> which case it can be simplified away if it is a merge). I do not
> mind rename codepath using a jargon (or two) to express "in trees A
> and B, this subtree of A records the same tree object as a subtree
> of B at a different path (i.e., the contents of these two subtrees
> at different paths are the same)" but the word used to express that
> should not be TREESAME to avoid confusion.
Maybe it's that the explanation of TREESAME in
rev-list-options.txt#L419-L436 [1] has a similar set of confusions about
how subtrees are considered and the path v filename confusions.
And the other word to
> express "this path in tree A records a blob object that is identical
> to this other path in tree B" should not be BLOBSAME, as the word
> strongly hints it is somehow related to TREESAME.
Yep. Naming is hard.
>
> Thanks.
>
>
Philip
[1]
https://github.com/git/git/blob/master/Documentation/rev-list-options.txt#L419-L436
^ permalink raw reply
* Re: [PATCH v5 0/3] rebase: support --autosquash without -i
From: Phillip Wood @ 2023-11-15 15:09 UTC (permalink / raw)
To: Andy Koppe, git; +Cc: gitster, phillip.wood
In-Reply-To: <20231114214339.10925-1-andy.koppe@gmail.com>
Hi Andy
On 14/11/2023 21:43, Andy Koppe wrote:
> Make rebase --autosquash work without --interactive, but limit
> rebase.autoSquash's effects to interactive mode, and improve testing
> and documentation.
>
> Changes from v4:
> - Fix amend vs apply backend thinko in commit messages.
> - Squash patch 3 for testing into patch 2 and improve the commit
> message.
> - No source changes.
>
> Thanks again to Junio and Phillip for their reviews.
Thanks for the re-roll this version looks good to me
Best Wishes
Phillip
>
> Andy Koppe (3):
> rebase: fully ignore rebase.autoSquash without -i
> rebase: support --autosquash without -i
> rebase: rewrite --(no-)autosquash documentation
>
> Documentation/config/rebase.txt | 4 ++-
> Documentation/git-rebase.txt | 34 +++++++++++++----------
> builtin/rebase.c | 17 +++++-------
> t/t3415-rebase-autosquash.sh | 38 +++++++++++++++++++-------
> t/t3422-rebase-incompatible-options.sh | 12 --------
> 5 files changed, 58 insertions(+), 47 deletions(-)
>
^ permalink raw reply
* Re: [PATCH v6 00/14] Introduce new `git replay` command
From: Christian Couder @ 2023-11-15 14:51 UTC (permalink / raw)
To: Elijah Newren, Johannes Schindelin
Cc: git, Junio C Hamano, Patrick Steinhardt, John Cai, Derrick Stolee,
Phillip Wood, Calvin Wan, Toon Claes, Dragan Simic, Linus Arver
In-Reply-To: <CAP8UFD24fzhiecJtANqEsxvh1mxT4pKR=QjfUFZh8C6HQE-k1A@mail.gmail.com>
Hi Elijah and Dscho,
On Tue, Nov 7, 2023 at 10:43 AM Christian Couder
<christian.couder@gmail.com> wrote:
> On Tue, Nov 7, 2023 at 3:44 AM Elijah Newren <newren@gmail.com> wrote:
> > Looking good, just one comment on one small hunk...
> >
> > On Thu, Nov 2, 2023 at 6:52 AM Christian Couder
> > <christian.couder@gmail.com> wrote:
> > >
> > [...]
> >
> > > @@ builtin/replay.c: int cmd_replay(int argc, const char **argv, const char *prefix
> > > -
> > > strvec_pushl(&rev_walk_args, "", argv[2], "--not", argv[1], NULL);
> > >
> > > ++ /*
> > > ++ * TODO: For now, let's warn when we see an option that we are
> > > ++ * going to override after setup_revisions() below. In the
> > > ++ * future we might want to either die() or allow them if we
> > > ++ * think they could be useful though.
> > > ++ */
> > > ++ for (i = 0; i < argc; i++) {
> > > ++ if (!strcmp(argv[i], "--reverse") || !strcmp(argv[i], "--date-order") ||
> > > ++ !strcmp(argv[i], "--topo-order") || !strcmp(argv[i], "--author-date-order") ||
> > > ++ !strcmp(argv[i], "--full-history"))
> > > ++ warning(_("option '%s' will be overridden"), argv[i]);
> > > ++ }
> > > ++
> > 2) This seems like an inefficient way to provide this warning; could
> > we avoid parsing the arguments for an extra time? Perhaps instead
> > a) set the desired values here, before setup_revisions()
> > b) after setup_revisions, check whether these values differ from the
> > desired values, if so throw a warning.
> > c) set the desired values, again
>
> Yeah, that would work. The downside is that it would be more difficult
> in the warning to tell the user which command line option was
> overridden as there are some values changed by different options.
> Maybe we can come up with a warning message that is still useful and
> enough for now, as the command is supposed to be used by experienced
> users. Perhaps something like:
>
> warning(_("some rev walking options will be overridden as '%s' bit in
> 'struct rev_info' will be forced"), "sort_order");
I have implemented this in the v7 I just sent.
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