view tests/test-patch.t @ 15708:309e49491253

push: propagate --new-branch and --ssh options when pushing subrepos Up until now the all the push command options were ignored when pushing subrepos. In particular, the fact that the --new-branch command was not passed down to subrepos made it not possible to push a repo when any of its subrepos had a new branch, even if you used the --new-branch option of the push command. In addition the error message was confusing since it showed the following hint: "--new-branch hint: use 'hg push --new-branch' to create new remote branches". However using the --new_branch flag did not fix the problem, as it was ignored when pushing subrepos. This patch passes the --new-branch and --ssh flags to every subrepo that is pushed. Issues/Limitations: - All subrepo types get these flags, but only the mercurial subrepos use them. - It is no longer possible to _not_ pass down these flags to subrepos when pushing: * An alternative would be to introduce a --subrepos flag that should be used to pass down these flags to the subrepos. * If we did this, it could make sense to make the --force flag respect this new --subrepos flag as well for consistency's sake. - Matt suggested that the ssh related flags could also be passed down to subrepos during pull and clone. However it seems that it would be the "update" command that would need to get those, since subrepos are only pulled on update. In any case I'd prefer to leave that for a later patch.
author Angel Ezquerra <angel.ezquerra@gmail.com>
date Thu, 29 Sep 2011 17:20:04 +0200
parents 0705f2ac79d6
children 75be14993fda
line wrap: on
line source

  $ cat > patchtool.py <<EOF
  > import sys
  > print 'Using custom patch'
  > if '--binary' in sys.argv:
  >     print '--binary found !'
  > EOF

  $ echo "[ui]" >> $HGRCPATH
  $ echo "patch=python ../patchtool.py" >> $HGRCPATH

  $ hg init a
  $ cd a
  $ echo a > a
  $ hg commit -Ama -d '1 0'
  adding a
  $ echo b >> a
  $ hg commit -Amb -d '2 0'
  $ cd ..

This test checks that:
 - custom patch commands with arguments actually work
 - patch code does not try to add weird arguments like
 --binary when custom patch commands are used. For instance
 --binary is added by default under win32.

check custom patch options are honored

  $ hg --cwd a export -o ../a.diff tip
  $ hg clone -r 0 a b
  adding changesets
  adding manifests
  adding file changes
  added 1 changesets with 1 changes to 1 files
  updating to branch default
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved

  $ hg --cwd b import -v ../a.diff
  applying ../a.diff
  Using custom patch
  applied to working directory

Issue2417: hg import with # comments in description

Prepare source repo and patch:

  $ rm $HGRCPATH
  $ hg init c
  $ cd c
  $ printf "a\rc" > a
  $ hg ci -A -m 0 a -d '0 0'
  $ printf "a\rb\rc" > a
  $ cat << eof > log
  > first line which can't start with '# '
  > # second line is a comment but that shouldn't be a problem.
  > A patch marker like this was more problematic even after d7452292f9d3:
  > # HG changeset patch
  > # User lines looks like this - but it _is_ just a comment
  > eof
  $ hg ci -l log -d '0 0'
  $ hg export -o p 1
  $ cd ..

Clone and apply patch:

  $ hg clone -r 0 c d
  adding changesets
  adding manifests
  adding file changes
  added 1 changesets with 1 changes to 1 files
  updating to branch default
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
  $ cd d
  $ hg import ../c/p
  applying ../c/p
  $ hg log -v -r 1
  changeset:   1:cd0bde79c428
  tag:         tip
  user:        test
  date:        Thu Jan 01 00:00:00 1970 +0000
  files:       a
  description:
  first line which can't start with '# '
  # second line is a comment but that shouldn't be a problem.
  A patch marker like this was more problematic even after d7452292f9d3:
  # HG changeset patch
  # User lines looks like this - but it _is_ just a comment
  
  
  $ cd ..