contrib/editmerge
author FUJIWARA Katsunori <foozy@lares.dti.ne.jp>
Mon, 18 May 2015 02:52:55 +0900
changeset 25174 86298718b01c
parent 20831 864c56cb8945
child 26421 4b0fc75f9403
permissions -rwxr-xr-x
import-checker: make imported_modules yield absolute dotted_name_of_path This patch makes `imported_modules()` always yield absolute `dotted_name_of_path()`-ed name by strict detection with `fromlocal()`. This change improves circular detection in some points: - locally defined modules, of which name collides against one of standard library, can be examined correctly For example, circular import related to `commands` is overlooked before this patch. - names not useful for circular detection are ignored Names below are also yielded before this patch: - module names of standard library (= not locally defined one) - non-module names (e.g. `node.nullid` of `from node import nullid`) These redundant names decrease performance of circular detection. For example, with files at 1ef96a3b8b89, average loops per file in `checkmod()` is reduced from 165 to 109. - `__init__` can be handled correctly in `checkmod()` For example, current implementation has problems below: - `from xxx import yyy` doesn't recognize `xxx.__init__` as imported - `xxx.__init__` imported via `import xxx` is treated as `xxx`, and circular detection is aborted, because `key` of such module name is not `xxx` but `xxx.__init__` - it is easy to enhance for `from . import xxx` style or so (in the future) Module name detection in `imported_modules()` can use information in `ast.ImportFrom` fully. It is assumed that all locally defined modules are correctly specified to `import-checker.py` at once. Strictly speaking, when `from foo.bar.baz import module1` imports `foo.bar.baz.module1` module, current `imported_modules()` yields only `foo.bar.baz.__init__`, even though also `foo.__init__` and `foo.bar.__init__` should be yielded to detect circular import exactly. But this limitation is reasonable one for improvement in this patch, because current `__init__` files in Mercurial seems to be implemented carefully.

#!/usr/bin/env bash
# A simple script for opening merge conflicts in the editor.
# Use the following Mercurial settings to enable it.
#
# [ui]
# merge = editmerge
#
# [merge-tools]
# editmerge.args=$output
# editmerge.check=changed
# editmerge.premerge=keep

FILE=$1

getlines() {
  grep -n "<<<<<<" $FILE | cut -f1 -d:
}

# editor preference loosely based on http://mercurial.selenic.com/wiki/editor
# hg showconfig is at the bottom though, since it's slow to run (0.15 seconds)
ED=$HGEDITOR
if [ "$ED" = "" ] ; then
  ED=$VISUAL
fi
if [ "$ED" = "" ] ; then
  ED=$EDITOR
fi
if [ "$ED" = "" ] ; then
  ED=$(hg showconfig ui.editor)
fi
if [ "$ED" = "" ] ; then
  echo "merge failed - unable to find editor"
  exit 1
fi

if [ "$ED" = "emacs" ] || [ "$ED" = "nano" ] || [ "$ED" = "vim" ] ; then
  FIRSTLINE=$(getlines | head -n 1)
  PREVIOUSLINE=""

  # open the editor to the first conflict until there are no more
  # or the user stops editing the file
  while [ ! "$FIRSTLINE" = "" ] && [ ! "$FIRSTLINE" = "$PREVIOUSLINE" ] ; do
    $ED +$FIRSTLINE $FILE
    PREVIOUSLINE=$FIRSTLINE
    FIRSTLINE=$(getlines | head -n 1)
  done
else
  $ED $FILE
fi

# get the line numbers of the remaining conflicts
CONFLICTS=$(getlines | sed ':a;N;$!ba;s/\n/, /g')
if [ ! "$CONFLICTS" = "" ] ; then
  echo "merge failed - resolve the conflicts (line $CONFLICTS) then use 'hg resolve --mark'"
  exit 1
fi

exit 0