-
Notifications
You must be signed in to change notification settings - Fork 26.4k
git-p4: fix fast import when empty commit is first #1609
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
/allow |
User daebo01 is now allowed to use GitGitGadget. WARNING: daebo01 has no public email address set on GitHub; |
c2a335f
to
fa0b456
Compare
/allow |
User daebo01 already allowed to use GitGitGadget. |
/preview |
Error: Could not determine full name of daebo01 |
/preview |
Error: Could not determine full name of daebo01 |
/preview |
Preview email sent as pull.1609.git.git.1700639569598.gitgitgadget@gmail.com |
/submit |
Submitted as pull.1609.git.git.1700639764041.gitgitgadget@gmail.com To fetch this version into
To fetch this version to local tag
|
On the Git mailing list, Junio C Hamano wrote (reply to this): "Alisha Kim via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Alisha Kim <pril@pril.cc>
>
> When executing p4 sync by specifying an excluded path, an empty commit
> will be created if there is only a change in the excluded path in
> revision.
> If git-p4.keepEmptyCommits is turned off and an empty commit is the
> first, fast-import will fail.
The above describe under what condition a failure gets triggered,
but there is no description on what approach the proposed solution
takes. You could teach "fast-import" to deal with an empty commit
properly, you could ignore empty commits and not produce input for
the fast-import command, you could probably turn these initial empty
commits into non-empty commits by adding dummy contents, etc. We
want to see in our proposed log messages what solution was taken and
how the solution was designed to satisfy what requirements. This is
to help future developers who will have to change the code that is
given by this patch, so that their updates can still adhere to what
ever design criteria you had in working on this change [*].
Side note: Your solution might be to ignore empty commits
despite keepEmptyCommits option is set (as I said, you did not
describe it at all in the above, so this is a hypothetical
example). If the reason behind choosing that design were "I
just do not want it to fail---I do not care if the resulting
history coming out of fast-import is crappy (I lose the p4 CL
descriptions for these commits, even though the user wants to
keep them)", then future developers can safely "fix" your fix
here by turning the initial empty commits into non-empty ones by
adding fake contents.
> @@ -3876,10 +3878,12 @@ class P4Sync(Command, P4UserMap):
> self.commit(description, filesForCommit, branch, parent)
> else:
> files = self.extractFilesFromCommit(description)
> - self.commit(description, files, self.branch,
> + isCommitted = self.commit(description, files, self.branch,
> self.initialParent)
> # only needed once, to connect to the previous commit
> - self.initialParent = ""
> + if isCommitted:
> + self.initialParent = ""
"is" does not sound grammatically correct. "didCommit" (i.e., "we
made a commit"), "haveCommitted" (i.e., "we have made a commit")
might be more understandable.
> except IOError:
> print(self.gitError.read())
> sys.exit(1)
>
> base-commit: cfb8a6e9a93adbe81efca66e6110c9b4d2e57169 |
This branch is now known as |
This patch series was integrated into seen via c125338. |
When executing p4 sync by specifying an excluded path, an empty commit will be created if there is only a change in the excluded path in revision. If git-p4.keepEmptyCommits is turned off and an empty commit is the first, fast-import will fail. Change the return type of the commit function from void to bool and return whether a commit has been created. This failure was prevented by modifying initialParent to be initialized only when a commit was actually created. Signed-off-by: Alisha Kim <pril@pril.cc>
/submit |
Submitted as pull.1609.v2.git.git.1700806464802.gitgitgadget@gmail.com To fetch this version into
To fetch this version to local tag
|
I've added explanations for the changes I suggested. The problem with correct grammar that you mentioned has also been changed. |
On the Git mailing list, Alisha Kim wrote (reply to this): On Thu, Nov 23, 2023 at 10:57 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> "Alisha Kim via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
> > From: Alisha Kim <pril@pril.cc>
> >
> > When executing p4 sync by specifying an excluded path, an empty commit
> > will be created if there is only a change in the excluded path in
> > revision.
> > If git-p4.keepEmptyCommits is turned off and an empty commit is the
> > first, fast-import will fail.
>
> The above describe under what condition a failure gets triggered,
> but there is no description on what approach the proposed solution
> takes. You could teach "fast-import" to deal with an empty commit
> properly, you could ignore empty commits and not produce input for
> the fast-import command, you could probably turn these initial empty
> commits into non-empty commits by adding dummy contents, etc. We
> want to see in our proposed log messages what solution was taken and
> how the solution was designed to satisfy what requirements. This is
> to help future developers who will have to change the code that is
> given by this patch, so that their updates can still adhere to what
> ever design criteria you had in working on this change [*].
>
> Side note: Your solution might be to ignore empty commits
> despite keepEmptyCommits option is set (as I said, you did not
> describe it at all in the above, so this is a hypothetical
> example). If the reason behind choosing that design were "I
> just do not want it to fail---I do not care if the resulting
> history coming out of fast-import is crappy (I lose the p4 CL
> descriptions for these commits, even though the user wants to
> keep them)", then future developers can safely "fix" your fix
> here by turning the initial empty commits into non-empty ones by
> adding fake contents.
I've added explanations for the changes I suggested.
>
>
> > @@ -3876,10 +3878,12 @@ class P4Sync(Command, P4UserMap):
> > self.commit(description, filesForCommit, branch, parent)
> > else:
> > files = self.extractFilesFromCommit(description)
> > - self.commit(description, files, self.branch,
> > + isCommitted = self.commit(description, files, self.branch,
> > self.initialParent)
> > # only needed once, to connect to the previous commit
> > - self.initialParent = ""
> > + if isCommitted:
> > + self.initialParent = ""
>
> "is" does not sound grammatically correct. "didCommit" (i.e., "we
> made a commit"), "haveCommitted" (i.e., "we have made a commit")
> might be more understandable.
The problem with correct grammar that you mentioned has also been
changed. Thank you for your good comments.
>
>
> > except IOError:
> > print(self.gitError.read())
> > sys.exit(1)
> >
> > base-commit: cfb8a6e9a93adbe81efca66e6110c9b4d2e57169 |
User |
There was a status update in the "New Topics" section about the branch Expecting a reroll. source: <pull.1609.git.git.1700639764041.gitgitgadget@gmail.com> |
This patch series was integrated into seen via ddbe5c2. |
/allow |
Error: User Eason-S-Lu is not yet permitted to use GitGitGadget |
This patch series was integrated into seen via 37e7253. |
There was a status update in the "Cooking" section about the branch Expecting a reroll. source: <pull.1609.git.git.1700639764041.gitgitgadget@gmail.com> |
This patch series was integrated into seen via 23d0799. |
This patch series was integrated into seen via 51726b0. |
There was a status update in the "Cooking" section about the branch Expecting a reroll. source: <pull.1609.git.git.1700639764041.gitgitgadget@gmail.com> |
This patch series was integrated into seen via 76a6e2f. |
Wondering if this fixes the case where the macos-13 CI jobs sometimes time out after hanging on some of the p4-related tests? It seems to happen non-deterministically, so it wouldn't necessarily still be showing in the CI checks overview if someone re-ran them... |
There was a status update in the "Discarded" section about the branch Expecting a reroll. source: <pull.1609.git.git.1700639764041.gitgitgadget@gmail.com> |
Did the expected reroll ever happen? |
When executing p4 sync by specifying an excluded path, an empty commit
will be created if there is only a change in the excluded path in
revision.
If git-p4.keepEmptyCommits is turned off and an empty commit is the
first, fast-import will fail. Change the return type of the commit
function from void to bool and return whether a commit has been
created. This failure was prevented by modifying initialParent
to be initialized only when a commit was actually created.
The error log is as follows
Ignoring revision 14035 as it would produce an empty commit.
fast-import failed: warning: Not updating refs/heads/p4/master (new tip
new commit hashdoes not containparent commit hash)fast-import statistics:
...
cc: Alisha Kim admin@pril.cc