Why can't I merge when there are uncommitted outstanding changes?

Cameron Simpson cs at zip.com.au
Thu Apr 22 19:53:33 CDT 2010


On 22Apr2010 08:34, Aardwolf <toiletpot at gmail.com> wrote:
| Jason Harris-8 wrote:
[...]
| > For me I just commit with reckless abandon lots of the time without really
| > thinking in huge detail about my commits [...] Now I just commit, commit, commit,
| > and then before I push I clean things up a bit if necessary. This is a
| > *much* *much* faster workflow for me.  There is really no reason not to
| > commit before doing other changes. Committing makes a "unit" package of
| > the parts. This can then be moved around, reordered, etc if you need to.
|
| I'm already using rebase, because, unless there is actually a *reason* to
| merge (that is, there is a change by two people in the same file), I don't
| like seeing two branches merging in the history, and also don't like seeing
| my name on files that I didn't actually type code in in the history (when
| merging, then other peoples files are suddenly somehow related to me...).
| But rebase has the exact same problem as merge: doesn't want to if there are
| uncommitted changes.

I think Jason's point is that you might consider committing your outstanding
changes, merging, then moving your previously-outstanding changes off to the
side before you push. That way you have a little mini-branch with your
outstanding changes, which after all are exactly that in a sense.
-- 
Cameron Simpson <cs at zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

library, n., a place with a large number of people, a slightly larger number
        of books, and a very small number of photocopiers, of which at any
        given time at least 50% will be out of order.


More information about the Mercurial mailing list