Currently, if there is a bare git subrepo, but it is at the "right"
revision, calling dirty() will error because diff-index does not work
on bare repos. This patch makes it so bare subrepos are always
considered dirty.
With Python >= 2.6 the original code already works correct, therefore the
fix for issue2556 on Python <= 2.5 broke relative subrepositories with
newer versions of Python.
This happens more often than expected. Say you have an svn subrepository with
python code. Python would have generated unknown .pyc files. Now, you rebase
this setup on a revision where a directory containing python code does not
exist. Subversion is first asked to remove this directory when updating, but
will not because it contains untracked items. Then it will have to bring back
the directory after the merge but will fail because it now collides with an
untracked directory.
Using --force is not very elegant and only works with svn >= 1.5 but the only
alternative I can think of is to write our own purge command for subversion.
This happens more often than expected. Say you have an svn subrepository with
python code. Python would have generated unknown .pyc files. Now, you rebase
this setup on a revision where a directory containing python code does not
exist. Subversion is first asked to remove this directory when updating, but
will not because it contains untracked items. Then it will have to bring back
the directory after the merge but will fail because it now collides with an
untracked directory.
Using --force is not very elegant but it is much simpler than rewriting our own
purge command for subversion.
This changes the prompts on git subrepos to show only the first seven
digits of git changeset IDs (as git's command line does):
$ hg update
subrepository sources for s differ (in checked out version)
use (l)ocal source (32a3438) or (r)emote source (da5f5b1)?
Consider a repository with a single subrepository. The changesets in
the main repository reference the subrepository changesets like this:
m0 -> s0
m1 -> s1
m2 -> s2
Starting from a state (m1, s0), doing 'hg update m2' in the main
repository will yield a conflict: the subrepo is at revision s0 but
the target revision says it should be at revision s2.
Before this change, Mercurial would do (m1, s0) -> (m2, s2) and thus
ignore the conflict between the working copy and the target revision.
With this change, the user is prompted to resolve the conflict by
choosing which revision he wants. This is consistent with 'hg merge',
which also prompts the user when it detects conflicts in the merged
.hgsubstate files.
The prompt looks like this:
$ hg update tip
subrepository sources for my-subrepo differ
use (l)ocal source (fc627a69481f) or (r)emote source (12a213df6fa9)?
This makes 'hg update --clean' behave the same way for both kinds of
subrepositories. Before Subversion subrepos did not take the clean
parameter into account, but just updated to the given revision and
merged uncommitted changes into that.
A subversion project revisions are a subset of the repository revisions, you
can ask subversion to update a working directory from one revision to another
without changing anything. Unfortunately, Mercurial will think the
subrepository has changed and will commit it again. To avoid useless commits,
we compare the subrepository state to its actual "parent" revision. To ensure
ascending compatibility with existing subrepositories which might reference
fake revisions, we also keep comparing with the subrepo working directory
revision.
NOTE: not sure if this should go in stable or not.
Just a little change to bring the comments in the dirty() methods of the
various subrepo classes into a uniform structure. This clarifies the
meaning of the states checked.
This makes 'hg update --clean' behave the same way for all three kinds
of subrepositories [hg, svn, git]. Before git subrepos did not take
the clean parameter into account, but just updated to the given
revision and merged uncommitted changes into that.
This patch conforms gitsubrepo code to the variable naming scheme of the other
subrepo implementations. All user-facing path references should be relative
to the root repository.
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.
This patch avoids empty commit when .hgsubstate is dirty. Empty commit
was caused by .hgsubstate being updated back to the state of the
working copy parent when committing, if a user had changed it manually
and not made any changes in subrepositories.
The subrepository state from the working copies parent is compared
with the state calculated as a result of trying to commit the
subrepositories. If the two states are the same, then return None
otherwise the commit is just done.
The line: "committing subrepository x" will be written if there is
nothing committed, but .hgsubstate is dirty for x subrepository.
Despite its name, git-diff-index compares a revision to the files in the
working directory. This seems way less sketchy and more future proof than
parsing human-readable git-status.
