Matt Mackall <mpm@selenic.com> [Thu, 16 Dec 2010 14:50:37 -0600] rev 13161
check-code: catch os.path.relpath
Matt Mackall <mpm@selenic.com> [Thu, 16 Dec 2010 14:50:36 -0600] rev 13160
check-code: catch "except as"
Matt Mackall <mpm@selenic.com> [Thu, 16 Dec 2010 14:50:27 -0600] rev 13159
tests: eliminate fast-forward merge in test-tag
Mads Kiilerich <mads@kiilerich.com> [Tue, 07 Dec 2010 03:29:21 +0100] rev 13158
merge: fast-forward merge with descendant
issue2538 gives a case where a changeset is merged with its child (which is on
another branch), and to my surprise the result is a real merge with two
parents, not just a "fast forward" "merge" with only the child as parent.
That is essentially the same as issue619.
Is the existing behaviour as intended and correct?
Or is the following fix correct?
Some extra "created new head" pops up with this fix, but it seems to me like
they could be considered correct. The old branch head has been superseeded by
changes on the other branch, and when the changes on the other branch is merged
back to the branch it will introduce a new head not directly related to the
previous branch head.
(I guess the intention with existing behaviour could be to ensure that the
changesets on the branch are directly connected and that no new heads pops up
on merges.)
Steve Borho <steve@borho.org> [Wed, 08 Dec 2010 22:14:18 -0600] rev 13157
record: teach parsepatch() about non-git style headers
These changes are not useful to record itself, since it is hard coded
to always generate git style diffs. But it makes parsepatch() more
generally useful for parsing normal patch files.
Eric Eisner <ede@mit.edu> [Mon, 13 Dec 2010 10:30:15 -0500] rev 13156
template: add showbranch template for {branch}
Like showbranches, but always yields exactly one branch. Replaces the less
correct {branches|nonempty}.
Erik Zielke <ez@aragost.com> [Mon, 29 Nov 2010 09:37:23 +0100] rev 13155
subrepo: avoids empty commit when .hgsubstate is dirty (issue2403)
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.
Augie Fackler <durin42@gmail.com> [Thu, 16 Dec 2010 07:45:22 -0600] rev 13154
progress: don't compute estimate without a total
Without this, computing an estimate crashes. Test included.
Eric Eisner <ede@mit.edu> [Tue, 14 Dec 2010 21:58:13 -0500] rev 13153
subrepo: use low-level git-diff-index for dirty()
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.
Eric Eisner <ede@mit.edu> [Tue, 14 Dec 2010 21:56:43 -0500] rev 13152
subrepo: defer determination of git's current branch