FATAL mach bootstrap: after accepting the change for clang-format and js-format in ~.hgrc, |hg qnew -Ue| now invokes editor four (4) times for editing commit message (-e) for MQ "hg qnew" each time and messes patch queue completely.
Categories
(Developer Infrastructure :: Lint and Formatting, defect)
Tracking
(Not tracked)
People
(Reporter: ishikawa, Unassigned)
Details
What were you doing?
Downloaded the latest source code last week.
Thought I messed up my source tree of comm-central portion, and refreshed that portion
mozilla/comm by downloading that part afresh in the last 24 hours.
I thought updating the .hgrc file, etc. using "mach bootstrap" was a good idea for the newly fetched |comm| subtree.
Well, it was not good as I stated below.
- First step
During "mach bootstrap", I have accepted the enabling of clang-format and js-format.
(I should not.)
This is because I know tree-wide formatting using pretty-printer is under way. Why not have a tool for local development?
This has brought about a disaster as you see below.
I am using MQ extenstion of mercurial.
I use "-Ue" (-U for adding From: address and -e for editing commit message with external editor) for "hg qnew" to create a new patch. -Ue is in [default] section of my ~/.hgrc.
- Second step
When I invoked hg qnew newpatchname, I get an editor invocation with a temporary file name. I edit the commit message and finish it.
But to my surprise, I get ANOTHER editor invocation with a different temporary file name.
Puzzled, I edit the message again, and finish the editor session.
But anther great surprise is that another editor invocation with another different temporary file name.
All in all, an external editor is invoked four times with different temporary file names.
- After doing this for three major patches, I found my patch queue contains blank patches only.
That is, only, the From line and the commit message, but nothing else.
So even if I tried to pop a patch to revert to the source tree, obviously the empty patch does not have the change history (diff output to use for reverting the change).
As a result, after I "hg qpop" three mqueue patch files, the source tree to revert to the original pristine state is still in a state where the changes of three patches are already applied. (But MQ thinks the patches are qpopped.)
I have no way of reverting the changes using hg MQ commands any more.
Disaster...
What should have happened?
hg qnew -e
ought to have invoked the external editor to edit the commit message ONCE and record the correct MQ patch and store it permanently for correct MQ operation.
Was was the expected result? ("Not crashing" may be a valid answer.)
No way.
Anything else we should know?
I tracked down the strange multiple invocation of external editor to the two extensions
which "mach bootstrap" added two my ~/.hgrc.
clang-format, and
js-format.
I checked by enabling and disabling the two extensions, and found that
each of them multiplies the invocation of editor 2 times.
So enabling |clang-format| invokes external editor two times when I issue "hg qnew -e".
Enabling |js-format| alone also invokes external editor two times.
However, when I enable the two extensions together, I see four (4) invocations of external editor with different temporary names |hg qnew -e| just as I observed initially.
I am not sure what goes on here , but it surely messes up my patch queue completely :-(
(My guess: I suspect that these extensionsdoes try to modify the patch queue content by running formartting after applying the patch and re-create the patch based on the changed source tree again. But it inadvertedly invokes the message commit editor with the already changed source tree AGAIN, but at that time the tree produces no diff any more? Anyway, there seems to be an incorrect loop of a sort to try to run external editor with already modified tree when clang-format and js-format are enabled.)
Now, I am on to re-creating my source tree, the patches are relatively straightforward, but it takes time to recreate them...
Thank you for the great package.
I have trusted |mach| for the last few years.
This is the first time it bit my fingers badly.
|
||
Comment 1•6 years ago
|
||
|
Reporter | |
Comment 2•6 years ago
|
||
(In reply to Release mgmt bot [:sylvestre / :calixte / :marco for bugbug] from comment #1)
Bugbug thinks this bug is a task, but please change it back in case of error.
I don't believe that a suggestion that messes up one's patch quitebadly is waiting for an enhancement task.
This is a serious bug IMHO, trashing developer's files in an unrecoverable way.
So I am making this into a defect.
Or I am a bit unclear of the meaning of task. What is exactly the difference of "defect" that needs to be fixed immediately, and a task.
Is the immediate fixing of a serious bug considered a top-priority "task"?
TIA
|
|
Reporter | |
Comment 3•6 years ago
|
||
(In reply to ISHIKAWA, Chiaki from comment #2)
(In reply to Release mgmt bot [:sylvestre / :calixte / :marco for bugbug] from comment #1)
Bugbug thinks this bug is a task, but please change it back in case of error.
I don't believe that a suggestion that messes up one's patch quitebadly is waiting for an enhancement task.
This is a serious bug IMHO, trashing developer's files in an unrecoverable way.
So I am making this into a defect.
Or I am a bit unclear of the meaning of task. What is exactly the difference of "defect" that needs to be fixed immediately, and a task.
Is the immediate fixing of a serious bug considered a top-priority "task"?TIA
I checked https://mozilla.github.io/bug-handling/bug-types and figure that this is indeed a defect that needs fixing instead of "task".
Quoting from the above URL:
Defect regression, crash, hang, security vulnerability and any other reported issue <--- THIS IS IT!
Enhancement new feature, improvement in UI, performance, etc. and any other request for user-facing enhancements to the product, not engineering changes
Task refactoring, removal, replacement, enabling or disabling of functionality and any other engineering task
TIA
|
||
Comment 4•6 years ago
|
||
DevTools means Web Console, ScratchPad, Inspector, etc.
|
||
Comment 5•6 years ago
|
||
We're not supporting MQ in our tools any more. It is recommended to use newer Mercurial tools such as histedit, evolve, rebase, graft and strip.
|
|
Reporter | |
Comment 6•6 years ago
|
||
(In reply to Mark Banner (:standard8) from comment #5)
We're not supporting MQ in our tools any more. It is recommended to use newer Mercurial tools such as histedit, evolve, rebase, graft and strip.
OK. Fair enough. I wonder if there is a document that summarizes a possible way to carry over work flow using MQ to a new work flow using the later tools such as histedit, evolve, rebase, graft and strip.
|
|
||
Comment 7•6 years ago
|
||
(In reply to ISHIKAWA, Chiaki from comment #6)
(In reply to Mark Banner (:standard8) from comment #5)
We're not supporting MQ in our tools any more. It is recommended to use newer Mercurial tools such as histedit, evolve, rebase, graft and strip.
OK. Fair enough. I wonder if there is a document that summarizes a possible way to carry over work flow using MQ to a new work flow using the later tools such as histedit, evolve, rebase, graft and strip.
I failed at finding it yesterday, but I've just found it now: https://mozilla-version-control-tools.readthedocs.io/en/latest/hgmozilla/workflows.html
Not sure if it has the latest things such as evolve, but I believe all the ideas are the same.
|
|
Reporter | |
Comment 8•6 years ago
|
||
(In reply to Mark Banner (:standard8) from comment #7)
...
I failed at finding it yesterday, but I've just found it now: https://mozilla-version-control-tools.readthedocs.io/en/latest/hgmozilla/workflows.html
Not sure if it has the latest things such as evolve, but I believe all the ideas are the same.
Thank you very much for locating this. I will study it.
To be honest, for an occasional patch submitter (I am a user of TB and want it to be more robust.),
the change of tools and web interface from bugzilla to phabricator is a tad daunting.
B ut I should not complain since TB is open source software made available for free. (Well, actually considering all the debug/development time I have devoted, it is not free at all, though !).
Thank you again.
|
||
Updated•3 years ago
|
Description
•