Always shrink and never expand keywords during a diff operation.
Avoid user distraction e.g. because of spurious differences
appearing in the commit editor.
Even though just enforcing expansion after overwriting files in
the working directory caused no problems that we know of, this avoids
a potential source of problems (e.g. in collaboration other extensions)
at no costs.
When cloning, prevent [keyword] filename patterns configured locally
in the source directory to persist during the update in the destination.
a) move [keyword] retrieval (back) to reposetup
b) remove the corresponding global kwtools attributes
Add test cases.
We can check for file existence in the working directory (needed
in case of recording) by simply using the given context and
calculate the manifest only when there are in fact candidates
for expansion/shrinking.
this helps users to know what kind of option is:
- no value is required(flag option)
- value is required
- value is required, and multiple occurrences are allowed
each kinds are shown as below:
-f --force force push
-e --ssh CMD specify ssh command to use
-b --branch BRANCH [+] a specific branch you would like to push
if one or more 3rd type options are shown, explanation for '[+]' mark
is also shown as footnote.
Now that we have retrieved the context in every calling function
except commit, pass it as argument to kwtemplater.overwrite to
avoid looking it up twice.
Reorder arguments to kwtemplater.overwrite to reflect their
importance.
Turn node argument into a simple boolean and rename it to iswctx.
Before this bugfix a file whose changes were entirely recorded was still
considered modified by "hg status".
Note: the test must use hg record -l/--logfile, because this is not
reproducible with hg record -m/--message.
svn-like default keywords can be set in a new configuration section
called [keywordset] -- thanks to timeless for the name.
Move setup of default keywordmaps into dedicated function used by
kwtemplater.__init__ and demo.
HeadURL/URL is not supported (by default).
Provide extendable keyword.recordextensions variable, so other
extensions beside hgext.record which provide the dorecord function
can cooperate with hgext.keyword like so (example from crecord):
def extsetup():
try:
keyword = extensions.find('keyword')
keyword.restricted += ' crecord qcrecord'
try:
# use record support in keyword.py if present
keyword.recordcommands += ' crecord qcrecord'
keyword.recordextensions += ' crecord'
except AttributeError:
pass
except KeyError:
pass
1) use kwtemplater.record attribute for clarity
2) drop optional context argument; consider the speed loss by
duplicating the dictionary lookup repo['.'] as negligible
Monkeypatch hgext.dorecord to trigger keyword expansion.
Read data from working directory, not from filelog.
Prevent keyword expansion from within record's commitfunc,
thereby fixing a bug/inconsistency where files which are clean
after recording were overwritten twice.
Monkeypatching patch.diff takes care of this since 224e03d75428.
Test mq more thoroughly by loosening [keywordmaps] and comparing
the output of hg cat with keyword expansion enabled and disabled.
Detecting and showing the path to a keyword extension in a
non-standard place only made sense while keyword.py was not
shipped with Mercurial.
The test output has changed because we do not have a spurious
space at eol anymore.
1) Set the branchname always silently with
dirstate.setbranch().
We create a branch so that testing the {branches} template
does not come up empty. But kwdemo is hardly the place to
inform the user by inference why {branches} is empty on the
default branch.
"demobranch" is ascii and cannot be changed, so using the
internal command instead of commands.branch() is safe.
2) Do not show full path to temporary directory
(distracting long lines on Mac OS X).
3) No special debug output. Output only related to keyword,
no internals like unsetting of commit hooks etc.
- kwcommitctx is inside the wlock of repo.commit: no lock
- _kwfwrite only needs wlock
wlock outside try block, so we don't need to import lock.release
_kwfwrite should even be safer that way, as we moved the status
call inside the try-except block.
Thanks to Benoit Boissinot for help.
kw_diff actually disabled restricted mode when 2 revisions were given,
because it effectively disables the extension in this case.
But the commands working with diff and patch need restricted mode
always enabled, i.e. expansion enabled when writing to the
working directory and - crucial for these commands - no expansion
when reading the filelog.
Remove extra documentation of -u/--unknown, as this is covered in
the option help already.
Like commands.status the code now zips the status flags.
Add more kwfiles tests.
Better reflect the actual behaviour of the extension:
- Make map arguments and -f/--rcfile not mutually exclusive but
extend the current configuration
- Map arguments and -f/--rcfile both override the defaults even
when -d/--default is specified
- -d/--default only overrides the current configuration
Inform the user about extending/overriding behaviour, but only at
the beginning; the following messages become terser, making the
output translatable without too much code clutter.
Rephrase help (use "short/long" option notation etc.).
- delete kwrepo.commitctx after using the tweaked version
- prefer self.hook over repo.hook to avoid nesting
Also pass arguments to commit as arbitrary list.
Thanks to Simon Heimberg and Matt Mackall for guidance.
This avoids forcing the dirstate of overwritten files to normal
during a commit.
Thanks to Dan Villiom Podlaski Christiansen for the idea of a
"double wrapper", so other extensions can still wrap
repo.commitctx safely.
- just use "files" instead of "filenames" (analogous to "hg status -h")
- reference the extension help wrt pattern configuration
Kudos to timeless for helpful suggestions.
Trying as much as possible to consistently:
- use a present tense predicate followed by a direct object
- verb referring directly to the functionality provided
(ie. not "add command that does this" but simple "do that")
- keep simple and to the point, leaving details for the long help
(width is tight, possibly even more so for translations)
Thanks to timeless, Martin Geisler, Rafael Villar Burke, Dan Villiom
Podlaski Christiansen and others for the helpful suggestions.
The intent is to fix many issues involving patching when win32ext is enabled.
With win32ext, the working directory and repository files EOLs are not the same
which means that patches made on a non-win32ext host do not apply cleanly
because of EOLs discrepancies. A theorically correct approach would be
transform either the patched file or the patch content with the
encoding/decoding filters used by win32ext. This solution is tricky to
implement and invasive, instead we prefer to address the win32ext case, by
offering a way to ignore input EOLs when patching and rewriting them when
saving the patched result.
Make merge and resolve trigger kwtemplater.restricted to compare
data without keyword expansion.
The keyword stays outside the conflict:
$Keyword$
<<<<<<< local
bar
=======
foo
>>>>>>> other
and will again be expanded on commit.
Demonstrate in test case.
add _checklink var to dirstate
introduce dirstate.flagfunc
switch users of util.execfunc/linkfunc to flagfunc
change manifestdict.set to take a flags string
change ctx.fileflags to ctx.flags
change gitmode func to a dict
remove util.execfunc/linkfunc
These two commands care about the list of modified files returned
by repo.status and we may need to do a full content comparison to
populate that list.
Expansion in hgweb view of changesets and diffs is not needed and
only distracting.
Expansion stays enable in file and archive requests where it
makes sense.
prevent issues due to global [keyword] filename patterns:
- add email to nokwcommands
- protect everything under .hg from expansion
(tested with qcommit)
- exclude everything starting with .hg* just in case
prevent abort when pulling from bundlerepo:
- do not set up kwrepo for bundlerepo
expansion inside a bundle is nonsense
bundlerepo issue spotted and test case provided by pmezard.