facebook/sapling
1
1
Fork 0
mirror of https://github.com/facebook/sapling.git synced 2024-10-08 15:57:43 +03:00
Code Issues Projects Releases Wiki Activity
c8cce47720
sapling/tests/test-mq-subrepo.t

515 lines
12 KiB
Perl
Raw Normal View History

subrepos: abort commit by default if a subrepo is dirty (BC) This changeset flips the default value of ui.commitsubrepos setting from True to False and adds a --subrepos flag to commit. The commit, status, and diff commands behave like this with regard to recusion and the ui.commitsubrepos setting: | recurses | recurses | by default | with --subrepos --------+---------------+---------------- commit: | commitsubrepo | True status: | False | True diff: | False | True By changing the default from True to False, the table becomes consistent in the two columns: * without --subrepos on the command line, commit will abort if a subrepo is dirty and status/diff wont show changes inside subrepos. * with --subrepos, all three commands will recurse. A --subrepos flag on the command line overrides the config settin.g
2011-10-21 02:33:08 +04:00
$ echo "[ui]" >> $HGRCPATH
$ echo "commitsubrepos = Yes" >> $HGRCPATH
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
$ echo "[extensions]" >> $HGRCPATH
$ echo "mq=" >> $HGRCPATH
$ echo "record=" >> $HGRCPATH
$ echo "[diff]" >> $HGRCPATH
$ echo "nodates=1" >> $HGRCPATH
test-mq-subrepo.t: correctly forward stdin to test functions - stdin was not forwarded in testrm1 and testrm2 - Forwarding content with EOL using command substitution (`foo`) does not work correctly, the lines are joined together which breaks the prompt readline. - EOFError is raised in ui.prompt() if the input is too short on Linux while OSX treats it as an empty line.
2011-01-07 19:44:23 +03:00
$ stdin=`pwd`/stdin.tmp
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
fn to create new repository w/dirty subrepo, and cd into it
$ mkrepo() {
> hg init $1
> cd $1
> hg qinit
> }
fn to create dirty subrepo
$ mksubrepo() {
> hg init $1
> cd $1
> echo a > a
> hg add
> cd ..
> }
$ testadd() {
test-mq-subrepo.t: correctly forward stdin to test functions - stdin was not forwarded in testrm1 and testrm2 - Forwarding content with EOL using command substitution (`foo`) does not work correctly, the lines are joined together which breaks the prompt readline. - EOFError is raised in ui.prompt() if the input is too short on Linux while OSX treats it as an empty line.
2011-01-07 19:44:23 +03:00
> cat - > "$stdin"
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
> mksubrepo sub
> echo sub = sub >> .hgsub
> hg add .hgsub
> echo % abort when adding .hgsub w/dirty subrepo
> hg status -S
> echo '%' $*
test-mq-subrepo.t: correctly forward stdin to test functions - stdin was not forwarded in testrm1 and testrm2 - Forwarding content with EOL using command substitution (`foo`) does not work correctly, the lines are joined together which breaks the prompt readline. - EOFError is raised in ui.prompt() if the input is too short on Linux while OSX treats it as an empty line.
2011-01-07 19:44:23 +03:00
> cat "$stdin" | hg $*
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
> echo [$?]
> hg -R sub ci -m0sub
> echo % update substate when adding .hgsub w/clean updated subrepo
> hg status -S
> echo '%' $*
test-mq-subrepo.t: correctly forward stdin to test functions - stdin was not forwarded in testrm1 and testrm2 - Forwarding content with EOL using command substitution (`foo`) does not work correctly, the lines are joined together which breaks the prompt readline. - EOFError is raised in ui.prompt() if the input is too short on Linux while OSX treats it as an empty line.
2011-01-07 19:44:23 +03:00
> cat "$stdin" | hg $*
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
> hg debugsub
> }
$ testmod() {
test-mq-subrepo.t: correctly forward stdin to test functions - stdin was not forwarded in testrm1 and testrm2 - Forwarding content with EOL using command substitution (`foo`) does not work correctly, the lines are joined together which breaks the prompt readline. - EOFError is raised in ui.prompt() if the input is too short on Linux while OSX treats it as an empty line.
2011-01-07 19:44:23 +03:00
> cat - > "$stdin"
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
> mksubrepo sub2
> echo sub2 = sub2 >> .hgsub
> echo % abort when modifying .hgsub w/dirty subrepo
> hg status -S
> echo '%' $*
test-mq-subrepo.t: correctly forward stdin to test functions - stdin was not forwarded in testrm1 and testrm2 - Forwarding content with EOL using command substitution (`foo`) does not work correctly, the lines are joined together which breaks the prompt readline. - EOFError is raised in ui.prompt() if the input is too short on Linux while OSX treats it as an empty line.
2011-01-07 19:44:23 +03:00
> cat "$stdin" | hg $*
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
> echo [$?]
> hg -R sub2 ci -m0sub2
> echo % update substate when modifying .hgsub w/clean updated subrepo
> hg status -S
> echo '%' $*
test-mq-subrepo.t: correctly forward stdin to test functions - stdin was not forwarded in testrm1 and testrm2 - Forwarding content with EOL using command substitution (`foo`) does not work correctly, the lines are joined together which breaks the prompt readline. - EOFError is raised in ui.prompt() if the input is too short on Linux while OSX treats it as an empty line.
2011-01-07 19:44:23 +03:00
> cat "$stdin" | hg $*
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
> hg debugsub
> }
$ testrm1() {
test-mq-subrepo.t: correctly forward stdin to test functions - stdin was not forwarded in testrm1 and testrm2 - Forwarding content with EOL using command substitution (`foo`) does not work correctly, the lines are joined together which breaks the prompt readline. - EOFError is raised in ui.prompt() if the input is too short on Linux while OSX treats it as an empty line.
2011-01-07 19:44:23 +03:00
> cat - > "$stdin"
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
> mksubrepo sub3
> echo sub3 = sub3 >> .hgsub
> hg ci -Aqmsub3
> $EXTRA
> echo b >> sub3/a
> hg rm .hgsub
> echo % update substate when removing .hgsub w/dirty subrepo
> hg status -S
> echo '%' $*
test-mq-subrepo.t: correctly forward stdin to test functions - stdin was not forwarded in testrm1 and testrm2 - Forwarding content with EOL using command substitution (`foo`) does not work correctly, the lines are joined together which breaks the prompt readline. - EOFError is raised in ui.prompt() if the input is too short on Linux while OSX treats it as an empty line.
2011-01-07 19:44:23 +03:00
> cat "$stdin" | hg $*
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
> echo % debugsub should be empty
> hg debugsub
> }
test-mq-subrepo.t: correctly forward stdin to test functions - stdin was not forwarded in testrm1 and testrm2 - Forwarding content with EOL using command substitution (`foo`) does not work correctly, the lines are joined together which breaks the prompt readline. - EOFError is raised in ui.prompt() if the input is too short on Linux while OSX treats it as an empty line.
2011-01-07 19:44:23 +03:00
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
$ testrm2() {
test-mq-subrepo.t: correctly forward stdin to test functions - stdin was not forwarded in testrm1 and testrm2 - Forwarding content with EOL using command substitution (`foo`) does not work correctly, the lines are joined together which breaks the prompt readline. - EOFError is raised in ui.prompt() if the input is too short on Linux while OSX treats it as an empty line.
2011-01-07 19:44:23 +03:00
> cat - > "$stdin"
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
> mksubrepo sub4
> echo sub4 = sub4 >> .hgsub
> hg ci -Aqmsub4
> $EXTRA
> hg rm .hgsub
> echo % update substate when removing .hgsub w/clean updated subrepo
> hg status -S
> echo '%' $*
test-mq-subrepo.t: correctly forward stdin to test functions - stdin was not forwarded in testrm1 and testrm2 - Forwarding content with EOL using command substitution (`foo`) does not work correctly, the lines are joined together which breaks the prompt readline. - EOFError is raised in ui.prompt() if the input is too short on Linux while OSX treats it as an empty line.
2011-01-07 19:44:23 +03:00
> cat "$stdin" | hg $*
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
> echo % debugsub should be empty
> hg debugsub
> }
handle subrepos safely on qnew
$ mkrepo repo-2499-qnew
$ testadd qnew -m0 0.diff
adding a
% abort when adding .hgsub w/dirty subrepo
A .hgsub
A sub/a
% qnew -m0 0.diff
abort: uncommitted changes in subrepository sub
[255]
% update substate when adding .hgsub w/clean updated subrepo
A .hgsub
% qnew -m0 0.diff
path sub
source sub
revision b2fdb12cd82b021c3b7053d67802e77b6eeaee31
$ testmod qnew -m1 1.diff
adding a
% abort when modifying .hgsub w/dirty subrepo
M .hgsub
A sub2/a
% qnew -m1 1.diff
abort: uncommitted changes in subrepository sub2
[255]
% update substate when modifying .hgsub w/clean updated subrepo
M .hgsub
% qnew -m1 1.diff
path sub
source sub
revision b2fdb12cd82b021c3b7053d67802e77b6eeaee31
path sub2
source sub2
revision 1f94c7611cc6b74f5a17b16121a1170d44776845
$ hg qpop -qa
patch queue now empty
$ testrm1 qnew -m2 2.diff
adding a
% update substate when removing .hgsub w/dirty subrepo
M sub3/a
R .hgsub
% qnew -m2 2.diff
% debugsub should be empty
$ hg qpop -qa
patch queue now empty
$ testrm2 qnew -m3 3.diff
adding a
% update substate when removing .hgsub w/clean updated subrepo
R .hgsub
% qnew -m3 3.diff
% debugsub should be empty
$ cd ..
handle subrepos safely on qrefresh
$ mkrepo repo-2499-qrefresh
$ hg qnew -m0 0.diff
$ testadd qrefresh
adding a
% abort when adding .hgsub w/dirty subrepo
A .hgsub
A sub/a
% qrefresh
abort: uncommitted changes in subrepository sub
[255]
% update substate when adding .hgsub w/clean updated subrepo
A .hgsub
% qrefresh
path sub
source sub
revision b2fdb12cd82b021c3b7053d67802e77b6eeaee31
$ hg qnew -m1 1.diff
$ testmod qrefresh
adding a
% abort when modifying .hgsub w/dirty subrepo
M .hgsub
A sub2/a
% qrefresh
abort: uncommitted changes in subrepository sub2
[255]
% update substate when modifying .hgsub w/clean updated subrepo
M .hgsub
% qrefresh
path sub
source sub
revision b2fdb12cd82b021c3b7053d67802e77b6eeaee31
path sub2
source sub2
revision 1f94c7611cc6b74f5a17b16121a1170d44776845
$ hg qpop -qa
patch queue now empty
tests: test-mq-subrepo.t Solaris 10 sh compliance Solaris 10 sh do apparently not like temporary environment variable assignment before a function call. There is no problem with commands.
2011-03-01 04:54:16 +03:00
$ EXTRA='hg qnew -m2 2.diff'
$ testrm1 qrefresh
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
adding a
% update substate when removing .hgsub w/dirty subrepo
M sub3/a
R .hgsub
% qrefresh
% debugsub should be empty
$ hg qpop -qa
patch queue now empty
tests: test-mq-subrepo.t Solaris 10 sh compliance Solaris 10 sh do apparently not like temporary environment variable assignment before a function call. There is no problem with commands.
2011-03-01 04:54:16 +03:00
$ EXTRA='hg qnew -m3 3.diff'
$ testrm2 qrefresh
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
adding a
% update substate when removing .hgsub w/clean updated subrepo
R .hgsub
% qrefresh
% debugsub should be empty
tests: test-mq-subrepo.t Solaris 10 sh compliance Solaris 10 sh do apparently not like temporary environment variable assignment before a function call. There is no problem with commands.
2011-03-01 04:54:16 +03:00
$ EXTRA=
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
$ cd ..
handle subrepos safely on qpush/qpop
$ mkrepo repo-2499-qpush
$ mksubrepo sub
adding a
$ hg -R sub ci -m0sub
$ echo sub = sub > .hgsub
$ hg add .hgsub
$ hg qnew -m0 0.diff
$ hg debugsub
path sub
source sub
revision b2fdb12cd82b021c3b7053d67802e77b6eeaee31
qpop
$ hg qpop
popping 0.diff
patch queue now empty
$ hg status -AS
$ hg debugsub
qpush
$ hg qpush
applying 0.diff
now at: 0.diff
$ hg status -AS
C .hgsub
C .hgsubstate
C sub/a
$ hg debugsub
path sub
source sub
revision b2fdb12cd82b021c3b7053d67802e77b6eeaee31
$ cd ..
handle subrepos safely on qrecord
$ mkrepo repo-2499-qrecord
$ testadd qrecord --config ui.interactive=1 -m0 0.diff <<EOF
> y
> y
> EOF
adding a
% abort when adding .hgsub w/dirty subrepo
A .hgsub
A sub/a
% qrecord --config ui.interactive=1 -m0 0.diff
diff --git a/.hgsub b/.hgsub
new file mode 100644
record: allow splitting of hunks by manually editing patches It is possible that unrelated changes in a file are on sequential lines. The current record extension does not allow these to be committed independently. An example use case for this is in software development for deeply embedded real-time systems. In these environments, it is not always possible to use a debugger (due to time-constraints) and hence inline UART-based printing is often used. When fixing a bug in a module, it is often convenient to add a large number of 'printf's (linked to the UART via a custom fputc) to the module in order to work out what is going wrong. printf is a very slow function (and also variadic so somewhat frowned upon by the MISRA standard) and hence it is highly undesirable to commit these lines to the repository. If only a partial fix is implemented, however, it is desirable to commit the fix without deleting all of the printf lines. This is also simplifies removal of the printf lines as once the final fix is committed, 'hg revert' does the rest. It is likely that the printf lines will be very near the actual fix, so being able to split the hunk is very useful in this case. There were two alternatives I considered for the user interface. One was to manually edit the patch, the other to allow a hunk to be split into individual lines for consideration. The latter option would require a significant refactor of the record module and is less flexible. While the former is potentially more complicated to use, this is a feature that is likely to only be used in certain exceptional cases (such as the use case proposed above) and hence I felt that the complexity would not be a considerable issue. I've also written a follow-up patch that refactors the 'prompt' code to base everything on the choices variable. This tidies up and clarifies the code a bit (removes constructs like 'if ret == 7' and removes the 'e' option from the file scope options as it's not relevant there. It's not really a necessity, so I've excluded it from this submission for now, but I can send it separately if there's a desire and it's on bitbucket (see below) in the meantime. Possible future improvements include: * Tidying up the 'prompt' code to base everything on the choices variable. This would allow entries to be removed from the prompt as currently 'e' is offered even for entire file patches, which is currently unsupported. * Allowing the entire file (or even multi-file) patch to be edited manually: this would require quite a large refactor without much benefit, so I decided to exclude it from the initial submission. * Allow the option to retry if a patch fails to apply (this is what Git does). This would require quite a bit of refactoring given the current 'hg record' implementation, so it's debatable whether it's worth it. Output is similar to existing record user interface except that an additional option ('e') exists to allow manual editing of the patch. This opens the user's configured editor with the patch. A comment is added to the bottom of the patch explaining what to do (based on Git's one). A large proportion of the changeset is test-case changes to update the options reported by record (Ynesfdaq? instead of Ynsfdaq?). Functional changes are in record.py and there are some new test cases in test-record.t.
2012-03-31 01:08:46 +04:00
examine changes to '.hgsub'? [Ynesfdaq?]
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
abort: uncommitted changes in subrepository sub
[255]
% update substate when adding .hgsub w/clean updated subrepo
A .hgsub
% qrecord --config ui.interactive=1 -m0 0.diff
diff --git a/.hgsub b/.hgsub
new file mode 100644
record: allow splitting of hunks by manually editing patches It is possible that unrelated changes in a file are on sequential lines. The current record extension does not allow these to be committed independently. An example use case for this is in software development for deeply embedded real-time systems. In these environments, it is not always possible to use a debugger (due to time-constraints) and hence inline UART-based printing is often used. When fixing a bug in a module, it is often convenient to add a large number of 'printf's (linked to the UART via a custom fputc) to the module in order to work out what is going wrong. printf is a very slow function (and also variadic so somewhat frowned upon by the MISRA standard) and hence it is highly undesirable to commit these lines to the repository. If only a partial fix is implemented, however, it is desirable to commit the fix without deleting all of the printf lines. This is also simplifies removal of the printf lines as once the final fix is committed, 'hg revert' does the rest. It is likely that the printf lines will be very near the actual fix, so being able to split the hunk is very useful in this case. There were two alternatives I considered for the user interface. One was to manually edit the patch, the other to allow a hunk to be split into individual lines for consideration. The latter option would require a significant refactor of the record module and is less flexible. While the former is potentially more complicated to use, this is a feature that is likely to only be used in certain exceptional cases (such as the use case proposed above) and hence I felt that the complexity would not be a considerable issue. I've also written a follow-up patch that refactors the 'prompt' code to base everything on the choices variable. This tidies up and clarifies the code a bit (removes constructs like 'if ret == 7' and removes the 'e' option from the file scope options as it's not relevant there. It's not really a necessity, so I've excluded it from this submission for now, but I can send it separately if there's a desire and it's on bitbucket (see below) in the meantime. Possible future improvements include: * Tidying up the 'prompt' code to base everything on the choices variable. This would allow entries to be removed from the prompt as currently 'e' is offered even for entire file patches, which is currently unsupported. * Allowing the entire file (or even multi-file) patch to be edited manually: this would require quite a large refactor without much benefit, so I decided to exclude it from the initial submission. * Allow the option to retry if a patch fails to apply (this is what Git does). This would require quite a bit of refactoring given the current 'hg record' implementation, so it's debatable whether it's worth it. Output is similar to existing record user interface except that an additional option ('e') exists to allow manual editing of the patch. This opens the user's configured editor with the patch. A comment is added to the bottom of the patch explaining what to do (based on Git's one). A large proportion of the changeset is test-case changes to update the options reported by record (Ynesfdaq? instead of Ynsfdaq?). Functional changes are in record.py and there are some new test cases in test-record.t.
2012-03-31 01:08:46 +04:00
examine changes to '.hgsub'? [Ynesfdaq?]
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
path sub
source sub
revision b2fdb12cd82b021c3b7053d67802e77b6eeaee31
$ testmod qrecord --config ui.interactive=1 -m1 1.diff <<EOF
> y
> y
> EOF
adding a
% abort when modifying .hgsub w/dirty subrepo
M .hgsub
A sub2/a
% qrecord --config ui.interactive=1 -m1 1.diff
diff --git a/.hgsub b/.hgsub
1 hunks, 1 lines changed
record: allow splitting of hunks by manually editing patches It is possible that unrelated changes in a file are on sequential lines. The current record extension does not allow these to be committed independently. An example use case for this is in software development for deeply embedded real-time systems. In these environments, it is not always possible to use a debugger (due to time-constraints) and hence inline UART-based printing is often used. When fixing a bug in a module, it is often convenient to add a large number of 'printf's (linked to the UART via a custom fputc) to the module in order to work out what is going wrong. printf is a very slow function (and also variadic so somewhat frowned upon by the MISRA standard) and hence it is highly undesirable to commit these lines to the repository. If only a partial fix is implemented, however, it is desirable to commit the fix without deleting all of the printf lines. This is also simplifies removal of the printf lines as once the final fix is committed, 'hg revert' does the rest. It is likely that the printf lines will be very near the actual fix, so being able to split the hunk is very useful in this case. There were two alternatives I considered for the user interface. One was to manually edit the patch, the other to allow a hunk to be split into individual lines for consideration. The latter option would require a significant refactor of the record module and is less flexible. While the former is potentially more complicated to use, this is a feature that is likely to only be used in certain exceptional cases (such as the use case proposed above) and hence I felt that the complexity would not be a considerable issue. I've also written a follow-up patch that refactors the 'prompt' code to base everything on the choices variable. This tidies up and clarifies the code a bit (removes constructs like 'if ret == 7' and removes the 'e' option from the file scope options as it's not relevant there. It's not really a necessity, so I've excluded it from this submission for now, but I can send it separately if there's a desire and it's on bitbucket (see below) in the meantime. Possible future improvements include: * Tidying up the 'prompt' code to base everything on the choices variable. This would allow entries to be removed from the prompt as currently 'e' is offered even for entire file patches, which is currently unsupported. * Allowing the entire file (or even multi-file) patch to be edited manually: this would require quite a large refactor without much benefit, so I decided to exclude it from the initial submission. * Allow the option to retry if a patch fails to apply (this is what Git does). This would require quite a bit of refactoring given the current 'hg record' implementation, so it's debatable whether it's worth it. Output is similar to existing record user interface except that an additional option ('e') exists to allow manual editing of the patch. This opens the user's configured editor with the patch. A comment is added to the bottom of the patch explaining what to do (based on Git's one). A large proportion of the changeset is test-case changes to update the options reported by record (Ynesfdaq? instead of Ynsfdaq?). Functional changes are in record.py and there are some new test cases in test-record.t.
2012-03-31 01:08:46 +04:00
examine changes to '.hgsub'? [Ynesfdaq?]
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
@@ -1,1 +1,2 @@
sub = sub
+sub2 = sub2
record: allow splitting of hunks by manually editing patches It is possible that unrelated changes in a file are on sequential lines. The current record extension does not allow these to be committed independently. An example use case for this is in software development for deeply embedded real-time systems. In these environments, it is not always possible to use a debugger (due to time-constraints) and hence inline UART-based printing is often used. When fixing a bug in a module, it is often convenient to add a large number of 'printf's (linked to the UART via a custom fputc) to the module in order to work out what is going wrong. printf is a very slow function (and also variadic so somewhat frowned upon by the MISRA standard) and hence it is highly undesirable to commit these lines to the repository. If only a partial fix is implemented, however, it is desirable to commit the fix without deleting all of the printf lines. This is also simplifies removal of the printf lines as once the final fix is committed, 'hg revert' does the rest. It is likely that the printf lines will be very near the actual fix, so being able to split the hunk is very useful in this case. There were two alternatives I considered for the user interface. One was to manually edit the patch, the other to allow a hunk to be split into individual lines for consideration. The latter option would require a significant refactor of the record module and is less flexible. While the former is potentially more complicated to use, this is a feature that is likely to only be used in certain exceptional cases (such as the use case proposed above) and hence I felt that the complexity would not be a considerable issue. I've also written a follow-up patch that refactors the 'prompt' code to base everything on the choices variable. This tidies up and clarifies the code a bit (removes constructs like 'if ret == 7' and removes the 'e' option from the file scope options as it's not relevant there. It's not really a necessity, so I've excluded it from this submission for now, but I can send it separately if there's a desire and it's on bitbucket (see below) in the meantime. Possible future improvements include: * Tidying up the 'prompt' code to base everything on the choices variable. This would allow entries to be removed from the prompt as currently 'e' is offered even for entire file patches, which is currently unsupported. * Allowing the entire file (or even multi-file) patch to be edited manually: this would require quite a large refactor without much benefit, so I decided to exclude it from the initial submission. * Allow the option to retry if a patch fails to apply (this is what Git does). This would require quite a bit of refactoring given the current 'hg record' implementation, so it's debatable whether it's worth it. Output is similar to existing record user interface except that an additional option ('e') exists to allow manual editing of the patch. This opens the user's configured editor with the patch. A comment is added to the bottom of the patch explaining what to do (based on Git's one). A large proportion of the changeset is test-case changes to update the options reported by record (Ynesfdaq? instead of Ynsfdaq?). Functional changes are in record.py and there are some new test cases in test-record.t.
2012-03-31 01:08:46 +04:00
record this change to '.hgsub'? [Ynesfdaq?]
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
abort: uncommitted changes in subrepository sub2
[255]
% update substate when modifying .hgsub w/clean updated subrepo
M .hgsub
% qrecord --config ui.interactive=1 -m1 1.diff
diff --git a/.hgsub b/.hgsub
1 hunks, 1 lines changed
record: allow splitting of hunks by manually editing patches It is possible that unrelated changes in a file are on sequential lines. The current record extension does not allow these to be committed independently. An example use case for this is in software development for deeply embedded real-time systems. In these environments, it is not always possible to use a debugger (due to time-constraints) and hence inline UART-based printing is often used. When fixing a bug in a module, it is often convenient to add a large number of 'printf's (linked to the UART via a custom fputc) to the module in order to work out what is going wrong. printf is a very slow function (and also variadic so somewhat frowned upon by the MISRA standard) and hence it is highly undesirable to commit these lines to the repository. If only a partial fix is implemented, however, it is desirable to commit the fix without deleting all of the printf lines. This is also simplifies removal of the printf lines as once the final fix is committed, 'hg revert' does the rest. It is likely that the printf lines will be very near the actual fix, so being able to split the hunk is very useful in this case. There were two alternatives I considered for the user interface. One was to manually edit the patch, the other to allow a hunk to be split into individual lines for consideration. The latter option would require a significant refactor of the record module and is less flexible. While the former is potentially more complicated to use, this is a feature that is likely to only be used in certain exceptional cases (such as the use case proposed above) and hence I felt that the complexity would not be a considerable issue. I've also written a follow-up patch that refactors the 'prompt' code to base everything on the choices variable. This tidies up and clarifies the code a bit (removes constructs like 'if ret == 7' and removes the 'e' option from the file scope options as it's not relevant there. It's not really a necessity, so I've excluded it from this submission for now, but I can send it separately if there's a desire and it's on bitbucket (see below) in the meantime. Possible future improvements include: * Tidying up the 'prompt' code to base everything on the choices variable. This would allow entries to be removed from the prompt as currently 'e' is offered even for entire file patches, which is currently unsupported. * Allowing the entire file (or even multi-file) patch to be edited manually: this would require quite a large refactor without much benefit, so I decided to exclude it from the initial submission. * Allow the option to retry if a patch fails to apply (this is what Git does). This would require quite a bit of refactoring given the current 'hg record' implementation, so it's debatable whether it's worth it. Output is similar to existing record user interface except that an additional option ('e') exists to allow manual editing of the patch. This opens the user's configured editor with the patch. A comment is added to the bottom of the patch explaining what to do (based on Git's one). A large proportion of the changeset is test-case changes to update the options reported by record (Ynesfdaq? instead of Ynsfdaq?). Functional changes are in record.py and there are some new test cases in test-record.t.
2012-03-31 01:08:46 +04:00
examine changes to '.hgsub'? [Ynesfdaq?]
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
@@ -1,1 +1,2 @@
sub = sub
+sub2 = sub2
record: allow splitting of hunks by manually editing patches It is possible that unrelated changes in a file are on sequential lines. The current record extension does not allow these to be committed independently. An example use case for this is in software development for deeply embedded real-time systems. In these environments, it is not always possible to use a debugger (due to time-constraints) and hence inline UART-based printing is often used. When fixing a bug in a module, it is often convenient to add a large number of 'printf's (linked to the UART via a custom fputc) to the module in order to work out what is going wrong. printf is a very slow function (and also variadic so somewhat frowned upon by the MISRA standard) and hence it is highly undesirable to commit these lines to the repository. If only a partial fix is implemented, however, it is desirable to commit the fix without deleting all of the printf lines. This is also simplifies removal of the printf lines as once the final fix is committed, 'hg revert' does the rest. It is likely that the printf lines will be very near the actual fix, so being able to split the hunk is very useful in this case. There were two alternatives I considered for the user interface. One was to manually edit the patch, the other to allow a hunk to be split into individual lines for consideration. The latter option would require a significant refactor of the record module and is less flexible. While the former is potentially more complicated to use, this is a feature that is likely to only be used in certain exceptional cases (such as the use case proposed above) and hence I felt that the complexity would not be a considerable issue. I've also written a follow-up patch that refactors the 'prompt' code to base everything on the choices variable. This tidies up and clarifies the code a bit (removes constructs like 'if ret == 7' and removes the 'e' option from the file scope options as it's not relevant there. It's not really a necessity, so I've excluded it from this submission for now, but I can send it separately if there's a desire and it's on bitbucket (see below) in the meantime. Possible future improvements include: * Tidying up the 'prompt' code to base everything on the choices variable. This would allow entries to be removed from the prompt as currently 'e' is offered even for entire file patches, which is currently unsupported. * Allowing the entire file (or even multi-file) patch to be edited manually: this would require quite a large refactor without much benefit, so I decided to exclude it from the initial submission. * Allow the option to retry if a patch fails to apply (this is what Git does). This would require quite a bit of refactoring given the current 'hg record' implementation, so it's debatable whether it's worth it. Output is similar to existing record user interface except that an additional option ('e') exists to allow manual editing of the patch. This opens the user's configured editor with the patch. A comment is added to the bottom of the patch explaining what to do (based on Git's one). A large proportion of the changeset is test-case changes to update the options reported by record (Ynesfdaq? instead of Ynsfdaq?). Functional changes are in record.py and there are some new test cases in test-record.t.
2012-03-31 01:08:46 +04:00
record this change to '.hgsub'? [Ynesfdaq?]
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
path sub
source sub
revision b2fdb12cd82b021c3b7053d67802e77b6eeaee31
path sub2
source sub2
revision 1f94c7611cc6b74f5a17b16121a1170d44776845
$ hg qpop -qa
patch queue now empty
tests: test-mq-subrepo.t Solaris 10 sh compliance Solaris 10 sh do apparently not like temporary environment variable assignment before a function call. There is no problem with commands.
2011-03-01 04:54:16 +03:00
$ testrm1 qrecord --config ui.interactive=1 -m2 2.diff <<EOF
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
> y
> y
> EOF
adding a
% update substate when removing .hgsub w/dirty subrepo
M sub3/a
R .hgsub
% qrecord --config ui.interactive=1 -m2 2.diff
diff --git a/.hgsub b/.hgsub
deleted file mode 100644
record: allow splitting of hunks by manually editing patches It is possible that unrelated changes in a file are on sequential lines. The current record extension does not allow these to be committed independently. An example use case for this is in software development for deeply embedded real-time systems. In these environments, it is not always possible to use a debugger (due to time-constraints) and hence inline UART-based printing is often used. When fixing a bug in a module, it is often convenient to add a large number of 'printf's (linked to the UART via a custom fputc) to the module in order to work out what is going wrong. printf is a very slow function (and also variadic so somewhat frowned upon by the MISRA standard) and hence it is highly undesirable to commit these lines to the repository. If only a partial fix is implemented, however, it is desirable to commit the fix without deleting all of the printf lines. This is also simplifies removal of the printf lines as once the final fix is committed, 'hg revert' does the rest. It is likely that the printf lines will be very near the actual fix, so being able to split the hunk is very useful in this case. There were two alternatives I considered for the user interface. One was to manually edit the patch, the other to allow a hunk to be split into individual lines for consideration. The latter option would require a significant refactor of the record module and is less flexible. While the former is potentially more complicated to use, this is a feature that is likely to only be used in certain exceptional cases (such as the use case proposed above) and hence I felt that the complexity would not be a considerable issue. I've also written a follow-up patch that refactors the 'prompt' code to base everything on the choices variable. This tidies up and clarifies the code a bit (removes constructs like 'if ret == 7' and removes the 'e' option from the file scope options as it's not relevant there. It's not really a necessity, so I've excluded it from this submission for now, but I can send it separately if there's a desire and it's on bitbucket (see below) in the meantime. Possible future improvements include: * Tidying up the 'prompt' code to base everything on the choices variable. This would allow entries to be removed from the prompt as currently 'e' is offered even for entire file patches, which is currently unsupported. * Allowing the entire file (or even multi-file) patch to be edited manually: this would require quite a large refactor without much benefit, so I decided to exclude it from the initial submission. * Allow the option to retry if a patch fails to apply (this is what Git does). This would require quite a bit of refactoring given the current 'hg record' implementation, so it's debatable whether it's worth it. Output is similar to existing record user interface except that an additional option ('e') exists to allow manual editing of the patch. This opens the user's configured editor with the patch. A comment is added to the bottom of the patch explaining what to do (based on Git's one). A large proportion of the changeset is test-case changes to update the options reported by record (Ynesfdaq? instead of Ynsfdaq?). Functional changes are in record.py and there are some new test cases in test-record.t.
2012-03-31 01:08:46 +04:00
examine changes to '.hgsub'? [Ynesfdaq?]
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
% debugsub should be empty
$ hg qpop -qa
patch queue now empty
tests: test-mq-subrepo.t Solaris 10 sh compliance Solaris 10 sh do apparently not like temporary environment variable assignment before a function call. There is no problem with commands.
2011-03-01 04:54:16 +03:00
$ testrm2 qrecord --config ui.interactive=1 -m3 3.diff <<EOF
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
> y
> y
> EOF
adding a
% update substate when removing .hgsub w/clean updated subrepo
R .hgsub
% qrecord --config ui.interactive=1 -m3 3.diff
diff --git a/.hgsub b/.hgsub
deleted file mode 100644
record: allow splitting of hunks by manually editing patches It is possible that unrelated changes in a file are on sequential lines. The current record extension does not allow these to be committed independently. An example use case for this is in software development for deeply embedded real-time systems. In these environments, it is not always possible to use a debugger (due to time-constraints) and hence inline UART-based printing is often used. When fixing a bug in a module, it is often convenient to add a large number of 'printf's (linked to the UART via a custom fputc) to the module in order to work out what is going wrong. printf is a very slow function (and also variadic so somewhat frowned upon by the MISRA standard) and hence it is highly undesirable to commit these lines to the repository. If only a partial fix is implemented, however, it is desirable to commit the fix without deleting all of the printf lines. This is also simplifies removal of the printf lines as once the final fix is committed, 'hg revert' does the rest. It is likely that the printf lines will be very near the actual fix, so being able to split the hunk is very useful in this case. There were two alternatives I considered for the user interface. One was to manually edit the patch, the other to allow a hunk to be split into individual lines for consideration. The latter option would require a significant refactor of the record module and is less flexible. While the former is potentially more complicated to use, this is a feature that is likely to only be used in certain exceptional cases (such as the use case proposed above) and hence I felt that the complexity would not be a considerable issue. I've also written a follow-up patch that refactors the 'prompt' code to base everything on the choices variable. This tidies up and clarifies the code a bit (removes constructs like 'if ret == 7' and removes the 'e' option from the file scope options as it's not relevant there. It's not really a necessity, so I've excluded it from this submission for now, but I can send it separately if there's a desire and it's on bitbucket (see below) in the meantime. Possible future improvements include: * Tidying up the 'prompt' code to base everything on the choices variable. This would allow entries to be removed from the prompt as currently 'e' is offered even for entire file patches, which is currently unsupported. * Allowing the entire file (or even multi-file) patch to be edited manually: this would require quite a large refactor without much benefit, so I decided to exclude it from the initial submission. * Allow the option to retry if a patch fails to apply (this is what Git does). This would require quite a bit of refactoring given the current 'hg record' implementation, so it's debatable whether it's worth it. Output is similar to existing record user interface except that an additional option ('e') exists to allow manual editing of the patch. This opens the user's configured editor with the patch. A comment is added to the bottom of the patch explaining what to do (based on Git's one). A large proportion of the changeset is test-case changes to update the options reported by record (Ynesfdaq? instead of Ynsfdaq?). Functional changes are in record.py and there are some new test cases in test-record.t.
2012-03-31 01:08:46 +04:00
examine changes to '.hgsub'? [Ynesfdaq?]
mq: update .hgsubstate if subrepos are clean (issue2499) This patch prevents MQ from creating an inconsistent subrepo state. If the .hgsub file has been changed, and none of the subrepos have uncommitted changes, creating or updating a patch (using qnew, qrefresh, or qrecord) will update .hgsubstate accordingly. If any subrepos _do_ have uncommitted changes, qnew/qrefresh/qrecord will abort. Thanks to pmezard for proposing this solution.
2010-12-08 07:14:43 +03:00
% debugsub should be empty
$ cd ..
subrepo: don't commit in subrepo if it's clean If a subrepo has changed relative to the outer repo's substate, but the subrepo itself is clean, we don't need to commit in the subrepo.
2011-07-19 22:43:53 +04:00
correctly handle subrepos with patch queues
$ mkrepo repo-subrepo-with-queue
$ mksubrepo sub
adding a
$ hg -R sub qnew sub0.diff
$ echo sub = sub >> .hgsub
$ hg add .hgsub
$ hg qnew 0.diff
tests: add missing trailing 'cd ..' Many tests didn't change back from subdirectories at the end of the tests ... and they don't have to. The missing 'cd ..' could always be added when another test case is added to the test file. This change do that tests (99.5%) consistently end up in $TESTDIR where they started, thus making it simpler to extend them or move them around.
2012-06-11 03:40:51 +04:00
$ cd ..
mq: add ".hgsubstate" to patch target list only if it is not listed up yet If ".hgsubstate" is already listed up as one of commit targets, qnew put diff of ".hgsubstate" twice into the patch file stored under ".hg/patches". It causes rejections at applying such patches. Other than the case like in added test script, this can also occur when qnew is executed just after rolling back the committing updated ".hgsubstate". This patch checks whether ".hgsubstate" is already listed up as one of commit targets, and put it into the appropriate list only if it is not listed up yet.
2012-06-27 17:03:22 +04:00
check whether MQ operations can import updated .hgsubstate correctly
both into 'revision' and 'patch file under .hg/patches':
$ hg init importing-hgsubstate
$ cd importing-hgsubstate
$ echo a > a
$ hg commit -u test -d '0 0' -Am '#0 in parent'
adding a
$ hg init sub
$ echo sa > sub/sa
$ hg -R sub commit -u test -d '0 0' -Am '#0 in sub'
adding sa
$ echo 'sub = sub' > .hgsub
$ touch .hgsubstate
$ hg add .hgsub .hgsubstate
$ hg qnew -u test -d '0 0' import-at-qnew
$ hg -R sub parents --template '{node} sub\n'
b6f6e9c41f3dfd374a6d2ed4535c87951cf979cf sub
$ cat .hgsubstate
b6f6e9c41f3dfd374a6d2ed4535c87951cf979cf sub
$ hg diff -c tip
diff -r f499373e340c -r b20ffac88564 .hgsub
--- /dev/null
+++ b/.hgsub
@@ -0,0 +1,1 @@
+sub = sub
diff -r f499373e340c -r b20ffac88564 .hgsubstate
--- /dev/null
+++ b/.hgsubstate
@@ -0,0 +1,1 @@
+b6f6e9c41f3dfd374a6d2ed4535c87951cf979cf sub
$ cat .hg/patches/import-at-qnew
# HG changeset patch
# Parent f499373e340cdca5d01dee904aeb42dd2a325e71
# User test
# Date 0 0
diff -r f499373e340c -r b20ffac88564 .hgsub
--- /dev/null
+++ b/.hgsub
@@ -0,0 +1,1 @@
+sub = sub
diff -r f499373e340c -r b20ffac88564 .hgsubstate
--- /dev/null
+++ b/.hgsubstate
@@ -0,0 +1,1 @@
+b6f6e9c41f3dfd374a6d2ed4535c87951cf979cf sub
$ hg qpop
popping import-at-qnew
patch queue now empty
$ hg qpush
applying import-at-qnew
now at: import-at-qnew
mq: create patch file after commit to import diff of ".hgsubstate" at qrefresh Even though the committed revision contains diff of ".hgsubstate", the patch file created by qrefresh doesn't contain it, because: - ".hgsubstate" is not listed up as one of target files of the patch for reasons below, so diff of ".hgsubstate" is not imported into patch file - status of ".hgsubstate" in working directory is usually "clean" - ".hgsubstate" is not specified explicitly by users - the patch file is created before commit processing which updates or creates ".hgsubstate" automatically, so there is no diff for it at that time This patch resolves this problem by: - putting ".hgsubstate" into target list of the patch, if needed: this allows "patch.diff()" to import diff of ".hgsubstate" into patch file. - creating the patch file after commit processing: this updates ".hgsubstate" before "patch.diff()" invocation. For the former fixing, this patch introduces "putsubstate2changes()" to share same implementation with qnew. This is invoked only once per qnew/qrefresh at most, so there is less performance impact. This patch also omits "match" argument for "patch.diff()" invocation, because "patch.diff()" ignores "match" if "changes" is specified.
2012-06-27 17:03:27 +04:00
$ hg qnew import-at-qrefresh
$ echo sb > sub/sb
$ hg -R sub commit -u test -d '0 0' -Am '#1 in sub'
adding sb
$ hg qrefresh -u test -d '0 0'
$ hg -R sub parents --template '{node} sub\n'
88ac1bef5ed43b689d1d200b59886b675dec474b sub
$ cat .hgsubstate
88ac1bef5ed43b689d1d200b59886b675dec474b sub
$ hg diff -c tip
diff -r 44f846335325 -r b3e8c5fa3aaa .hgsubstate
--- a/.hgsubstate
+++ b/.hgsubstate
@@ -1,1 +1,1 @@
-b6f6e9c41f3dfd374a6d2ed4535c87951cf979cf sub
+88ac1bef5ed43b689d1d200b59886b675dec474b sub
$ cat .hg/patches/import-at-qrefresh
# HG changeset patch
# Date 0 0
# User test
# Parent 44f846335325209be6be35dc2c9a4be107278c09
diff -r 44f846335325 .hgsubstate
--- a/.hgsubstate
+++ b/.hgsubstate
@@ -1,1 +1,1 @@
-b6f6e9c41f3dfd374a6d2ed4535c87951cf979cf sub
+88ac1bef5ed43b689d1d200b59886b675dec474b sub
mq: check subrepo synchronizations against parent of workdir or other appropriate context Before this patch, MQ checks each subrepo synchronizations against the working directory context, so ".hgsubstate" updating is not imported into MQ revision correctly in cases below: - qrefresh when current ".hgsubstate" is already synchronized with each subrepos: you can reproduce this easily by just twice or more qrefresh invocations - qnew just after rollback of commit which updates ".hgsubstate" This patch resolves this by checking subrepo states against: - the parent of "qtop" for qrefresh, or - the parent of working context otherwise
2012-06-27 17:03:27 +04:00
$ hg qrefresh -u test -d '0 0'
$ cat .hgsubstate
88ac1bef5ed43b689d1d200b59886b675dec474b sub
$ hg diff -c tip
diff -r 44f846335325 -r b3e8c5fa3aaa .hgsubstate
--- a/.hgsubstate
+++ b/.hgsubstate
@@ -1,1 +1,1 @@
-b6f6e9c41f3dfd374a6d2ed4535c87951cf979cf sub
+88ac1bef5ed43b689d1d200b59886b675dec474b sub
$ cat .hg/patches/import-at-qrefresh
# HG changeset patch
# Date 0 0
# User test
# Parent 44f846335325209be6be35dc2c9a4be107278c09
diff -r 44f846335325 .hgsubstate
--- a/.hgsubstate
+++ b/.hgsubstate
@@ -1,1 +1,1 @@
-b6f6e9c41f3dfd374a6d2ed4535c87951cf979cf sub
+88ac1bef5ed43b689d1d200b59886b675dec474b sub
$ hg update -C tip
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg qpop -a
popping import-at-qrefresh
popping import-at-qnew
patch queue now empty
$ hg -R sub update -C 0
0 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ echo 'sub = sub' > .hgsub
$ hg commit -Am '#1 in parent'
adding .hgsub
$ hg -R sub update -C 1
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
Merge spelling fixes
2012-09-11 19:36:09 +04:00
$ hg commit -Am '#2 in parent (but will be rolled back soon)'
mq: check subrepo synchronizations against parent of workdir or other appropriate context Before this patch, MQ checks each subrepo synchronizations against the working directory context, so ".hgsubstate" updating is not imported into MQ revision correctly in cases below: - qrefresh when current ".hgsubstate" is already synchronized with each subrepos: you can reproduce this easily by just twice or more qrefresh invocations - qnew just after rollback of commit which updates ".hgsubstate" This patch resolves this by checking subrepo states against: - the parent of "qtop" for qrefresh, or - the parent of working context otherwise
2012-06-27 17:03:27 +04:00
$ hg rollback
repository tip rolled back to revision 1 (undo commit)
working directory now based on revision 1
$ hg status
M .hgsubstate
$ hg qnew -u test -d '0 0' checkstate-at-qnew
$ hg -R sub parents --template '{node} sub\n'
88ac1bef5ed43b689d1d200b59886b675dec474b sub
$ cat .hgsubstate
88ac1bef5ed43b689d1d200b59886b675dec474b sub
$ hg diff -c tip
diff -r 4d91eb2fa1d1 -r 1259c112d884 .hgsubstate
--- a/.hgsubstate
+++ b/.hgsubstate
@@ -1,1 +1,1 @@
-b6f6e9c41f3dfd374a6d2ed4535c87951cf979cf sub
+88ac1bef5ed43b689d1d200b59886b675dec474b sub
$ cat .hg/patches/checkstate-at-qnew
# HG changeset patch
# Parent 4d91eb2fa1d1b22ec513347b9cd06f6b49d470fa
# User test
# Date 0 0
diff -r 4d91eb2fa1d1 -r 1259c112d884 .hgsubstate
--- a/.hgsubstate
+++ b/.hgsubstate
@@ -1,1 +1,1 @@
-b6f6e9c41f3dfd374a6d2ed4535c87951cf979cf sub
+88ac1bef5ed43b689d1d200b59886b675dec474b sub
mq: add ".hgsubstate" to patch target list only if it is not listed up yet If ".hgsubstate" is already listed up as one of commit targets, qnew put diff of ".hgsubstate" twice into the patch file stored under ".hg/patches". It causes rejections at applying such patches. Other than the case like in added test script, this can also occur when qnew is executed just after rolling back the committing updated ".hgsubstate". This patch checks whether ".hgsubstate" is already listed up as one of commit targets, and put it into the appropriate list only if it is not listed up yet.
2012-06-27 17:03:22 +04:00
$ cd ..
$ cd ..
Reference in New Issue Copy Permalink