Skip to content
Snippets Groups Projects
  1. Apr 25, 2012
    • Patrick Mézard's avatar
      rebase: preserve mq series order, guarded patches (issue2849) · b9f51f49bf2a
      Patrick Mézard authored
      The previous code was rebasing an applied series like:
      
        patch1 +guarded
        patch2
        patch3 +guarded
        patch4
        patch5 +guarded
      
      into:
      
        patch2
        patch4
        patch1 +guarded
        patch3 +guarded
        patch5 +guarded
      
      Reported by Lars Westerhoff <lars.westerhoff@newtec.eu>
      
      Also rename mq.series_dirty into mq.seriesdirty, missed by 599a72895c0d, and
      without effect since mq.qimport() was setting it already.
      b9f51f49bf2a
  2. Apr 26, 2012
    • Patrick Mézard's avatar
      subrepo/svn: improve error message on missing files · e37199a1f9d4
      Patrick Mézard authored
      From:
      
        abort: failed to commit svn changes
      
      to:
      
        abort: cannot commit missing svn entries
      e37199a1f9d4
    • Patrick Mézard's avatar
      subrepo/svn: abort on commit with missing file (issue3029) · 3d5d204a08c7
      Patrick Mézard authored
      Previous code was printing a traceback because it expected some error output
      from svn. But sometimes our definition of "changed" differs with the subversion
      one. For instance, subversion ignores missing files when committing. And when
      there are only missing files, svn commit will be a successful no-op with no
      output. Still, we should stick to our definition including missing files in
      changes as doing otherwise could cause surprising behaviour for the user.
      3d5d204a08c7
    • Katsunori FUJIWARA's avatar
      doc: flatten description of 'matching()' predicate to be formatted well · 5d803620ca05
      Katsunori FUJIWARA authored
      current description of 'matching()' revset predicate can't be
      formatted well on "hg help revset" output.
      
      each descriptions for revset predicates (or something like them) are
      split-ed into lines, and spaces on left side of them are stripped
      before minirst processing. so, bullet list can't be nested.
      
      this patch just flattens description of 'matching()' predicate to be
      formatted well.
      5d803620ca05
  3. Apr 27, 2012
  4. Apr 26, 2012
  5. Apr 21, 2012
  6. Apr 26, 2012
    • Patrick Mézard's avatar
      revset: fix adds/modifies/removes and patterns (issue3403) · 592701c8eac6
      Patrick Mézard authored
      The fast path was triggered if the argument was not like "type:value", with
      type a known pattern type. This is wrong for several reasons:
      - path:value is valid for the fast path
      - '*' is interpreted as a glob by default and is not valid for fast path
      
      Fast path detection is now done after the pattern is parsed, and the normalized
      path is extracted for direct comparison. All this seems a bit complicated, it
      is tempting to drop the fast path completely. Also, the hasfile() revset does
      something similar (only check .files()), without a fast path. If the fast path
      is really that efficient maybe it should be used there too.
      
      Note that:
      
        $ log 'modifies("set:modified()")'
      
      is different from:
      
        $ log 'modifies("*")'
      
      because of the usual merge ctx.files()/status(ctx.p1(), ctx) differences.
      
      Reported by Steffen Eichenberg <steffen.eichenberg@msg-gillardon.de>
      592701c8eac6
    • Matt Mackall's avatar
      merge with i18n · 4bce649a2b0f
      Matt Mackall authored
      4bce649a2b0f
  7. Apr 25, 2012
  8. Apr 24, 2012
  9. Apr 22, 2012
    • Matt Harbison's avatar
      largefiles: notice dirty large files in a subrepo · 597ddcb41b32
      Matt Harbison authored
      Summary and commit use dirty() to check the status of a subrepository,
      so this overrides dirty() in the subrepo in the same manner as
      status() to check the large files instead of their standins.
      
      Previously, if only a large file was changed in a subrepo, summary in
      the top level repo would not report the subrepo was dirty and commit
      -S would report nothing changed.  If any type of file was changed in
      the top repo and only a large file in the subrepo, commit -S would not
      commit the changes to the subrepo.
      597ddcb41b32
    • Matt Harbison's avatar
      largefiles: fix status -S reporting of subrepos (issue3231) · 12dabc22de77
      Matt Harbison authored
      Wrapping the status command will only invoke overridestatus() and set
      the lfstatus field for the top level repository.  Wrapping the status
      function is required to set the field on child repositories.
      
      Previously, status -S would report large files in a subrepo as '?'
      regardless of their actual states, and was inconsistent with what
      status would report from within that subrepo.
      12dabc22de77
  10. Apr 25, 2012
    • Katsunori FUJIWARA's avatar
      i18n: use locale insensitive format for datetimes as intermediate representation (issue3398) · 363e808de349
      Katsunori FUJIWARA authored
      on some non "en" locale environments, "hg convert" is aborted, because
      "util.parsedate()" fails.
      
      it fails in "memctx.__init__()" called by "putcommit()" of "convert".
      
      in "hg convert", datetimes gotten from source repository
      are usually formatted by "util.datestr()" with default format "%a %b
      %d %H:%M:%S %Y %1%2".
      
      but on some environments, "%a" and "%b" may cause locale sensitive
      string, and such string may cause parse error in "util.parsedate()".
      
      this path uses "%Y-%m-%d %H:%M:%S %1%2" as intermediate representation
      format for datetimes, because it consists only of locale insensitive
      elements.
      
      datetimes in above format are only used for passing them from
      conversion logic to memctx object, so it doesn't have to be formatted
      by locale sensitive one.
      
      this patch just avoids locale sensitivity problem of "datestr()" and
      "parsedate()" combintion.
      363e808de349
  11. Apr 24, 2012
  12. Apr 25, 2012
    • kiilerix's avatar
      docs: don't use :hg: at the beginning of lines in notes (issue3397) · c7c9473fcc46
      kiilerix authored
      It seem like docutils 0.8 interpret ':hg:`command`' roles at the beginning of
      indented lines in '.. note::' directives as a field that is an invalid argument
      to the directive. It fails with 'Error in "note" directive: invalid option
      block.' Docutils 0.7 accepted this arguably incorrect markup.
      
      Reflowing the text makes the problem go away. A leading '\ ' could perhaps also
      be used to mask the problem.
      c7c9473fcc46
  13. Apr 22, 2012
    • Patrick Mézard's avatar
      rebase: skip resolved but emptied revisions · eab9119c5dee
      Patrick Mézard authored
      When rebasing, if a conflict occurs and is resolved in a way the rebased
      revision becomes empty, it is not skipped, unlike revisions being emptied
      without conflicts.
      
      The reason is:
      - File 'x' is merged and resolved, merge.update() marks it as 'm' in the
        dirstate.
      - rebase.concludenode() calls localrepo.commit(), which calls
        localrepo.status() which calls dirstate.status(). 'x' shows up as 'm' and is
        unconditionnally added to the modified files list, instead of being checked
        again.
      - localrepo.commit() detects 'x' as changed an create a new revision where only
        the manifest parents and linkrev differ.
      
      Marking 'x' as modified without checking it makes sense for regular merges. But
      in rebase case, the merge looks normal but the second parent is usually
      discarded. When this happens, 'm' files in dirstate are a bit irrelevant and
      should be considered 'n' possibly dirty instead. That is what the current patch
      does.
      
      Another approach, maybe more efficient, would be to pass another flag to
      merge.update() saying the 'branchmerge' is a bit of a lie and recordupdate()
      should call dirstate.normallookup() instead of merge().
      
      It is also tempting to add this logic to dirstate.setparents(), moving from two
      to one parent is what invalidates the 'm' markers. But this is a far bigger
      change to make.
      
      v2: succumb to the temptation and move the logic in dirstate.setparents(). mpm
      suggested trying _filecommit() first but it is called by commitctx() which
      knows nothing about the dirstate and comes too late into the game. A second
      approach was to rewrite the 'm' state into 'n' on the fly in dirstate.status()
      which failed for graft in the following case:
      
        $ hg init repo
        $ cd repo
        $ echo a > a
        $ hg ci -qAm0
        $ echo a >> a
        $ hg ci -m1
        $ hg up 0
        1 files updated, 0 files merged, 0 files removed, 0 files unresolved
        $ hg mv a b
        $ echo c > b
        $ hg ci -m2
        created new head
        $ hg graft 1 --tool internal:local
        grafting revision 1
        $ hg --config extensions.graphlog= glog --template '{rev} {desc|firstline}\n'
        @  3 1
        |
        o  2 2
        |
        | o  1 1
        |/
        o  0 0
      
        $ hg log -r 3 --debug --patch --git --copies
        changeset:   3:19cd7d1417952af13161b94c32e901769104560c
        tag:         tip
        phase:       draft
        parent:      2:b5c505595c9e9a12d5dd457919c143e05fc16fb8
        parent:      -1:0000000000000000000000000000000000000000
        manifest:    3:3d27ce8d02241aa59b60804805edf103c5c0cda4
        user:        test
        date:        Thu Jan 01 00:00:00 1970 +0000
        extra:       branch=default
        extra:       source=a03df74c41413a75c0a42997fc36c2de97b26658
        description:
        1
      
      Here, revision 3 is created because there is a copy record for 'b' in the
      dirstate and thus 'b' is considered modified. But this information is discarded
      at commit time since 'b' content is unchanged. I do not know if discarding this
      information is correct or not, but at this time we cannot represent it anyway.
      
      This patch therefore implements the last solution of moving the logic into
      dirstate.setparents(). It does not sound crazy as 'm' files makes no sense with
      only one parent. It also makes dirstate.merge() calls .lookupnormal() if there
      is one parent, to preserve the invariant.
      
      I am a bit concerned about introducing this kind of stateful behaviour to
      existing code which historically treated setparents() as a basic setter without
      side-effects. And doing that during the code freeze.
      eab9119c5dee
    • Patrick Mézard's avatar
      test-rebase: exhibit revisions which should have been skipped · 475de53c08f4
      Patrick Mézard authored
      This will be fixed in the next commit.
      
      v2:
      - Display emptied grafted revisions
      - Use --git flag
      475de53c08f4
    • Patrick Mézard's avatar
      transplant: do not rollback on patching error (issue3379) · 1f020021adfa
      Patrick Mézard authored
      Otherwise, all transplanted revisions are gone and the failing one cannot be
      fixed (unless it is the first one).
      
      I do not know what is the expected behaviour with rollback, probably something
      pull-like. Non-conflicting cases should work as previously. But something like:
      
        $ hg transplant r1 r2
        commiting r1 as c1
        failing r2
        $ hg transplant --continue
        committing r2 as c2
        $ hg rollback
      
      would reset the repository to its state before the "transplant --continue"
      instead of the whole transplant session. To fix this we might need a way to
      open an existing journal file, not sure this is worth the pain.
      1f020021adfa
  14. Apr 21, 2012
    • Patrick Mézard's avatar
      patch: fix patch hunk/metdata synchronization (issue3384) · fc4e0fecf403
      Patrick Mézard authored
      Git patches are parsed in two phases: 1) extract metadata, 2) parse actual
      deltas and merge them with the previous metadata. We do this to avoid
      dependency issues like "modify a; copy a to b", where "b" must be copied from
      the unmodified "a".
      
      Issue3384 is caused by flaky code I wrote to synchronize the patch metadata
      with the emitted hunk:
      
       if (gitpatches and
           (gitpatches[-1][0] == afile or gitpatches[-1][1] == bfile)):
           gp = gitpatches.pop()[2]
      
      With a patch like:
      
       diff --git a/a b/c
       copy from a
       copy to c
       --- a/a
       +++ b/c
       @@ -1,1 +1,2 @@
        a
       +a
       @@ -2,1 +2,2 @@
        a
       +a
       diff --git a/a b/a
       --- a/a
       +++ b/a
       @@ -1,1 +1,2 @@
        a
       +b
      
      the first hunk of the first block is matched with the metadata for the block
      "diff --git a/a b/c", then the second hunk of the first block is matched with
      the metadata of the second block "diff --git a/a b/a", because of the "or" in
      the code paste above. Turning the "or" into an "and" is not enough as we have
      to deal with /dev/null cases for each file.
      
      We I remove this broken piece of code:
      
       # copy/rename + modify should modify target, not source
       if gp.op in ('COPY', 'DELETE', 'RENAME', 'ADD') or gp.mode:
           afile = bfile
      
      because "afile = bfile" set "afile" to stuff like "b/file" instead of "a/file",
      and because this only happens for git patches, which afile/bfile are ignored
      anyway by applydiff().
      
      v2:
      - Avoid a traceback on git metadata desynchronization
      fc4e0fecf403
    • Adrian Buehlmann's avatar
      commit: use ui.configbool when checking 'commitsubrepos' setting on --amend · db85c24dcdea
      Adrian Buehlmann authored
      Before this fix, having
      
         [ui]
         commitsubrepos = False
      
      in the config file lead to
      
         $ hg ci --amend -mx
         abort: cannot amend recursively
      db85c24dcdea
  15. Apr 22, 2012
  16. Apr 23, 2012
    • Cesar Mena's avatar
      encoding: protect against non-ascii default encoding · 72c6240a4b7d
      Cesar Mena authored
      If the default python encoding was changed from ascii, the attempt to
      encode as ascii before lower() could throw a UnicodeEncodeError.
      Catch UnicodeError instead to prevent an unhandled exception.
      72c6240a4b7d
    • Patrick Mézard's avatar
      update: fix case-collision with a clean wd and no --clean · 774e2dcd0a65
      Patrick Mézard authored
      cbf2ea2f5ca1 introduced some logic to avoid case-collision detection between
      source and destination revisions when it does not make sense: clean or to be
      cleaned working directories. Unfortunately, part of it was flawed and the
      related test was broken by another bug.
      
      This patch disables cross revision case collision detection for updates without
      option or with --check, if the working directory is clean.
      774e2dcd0a65
Loading