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

Aardwolf toiletpot at gmail.com
Thu Apr 22 10:34:45 CDT 2010


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 have no problems changing my workflow for mercurial, I even want to find
the right workflow :)

But giving up the ability to have uncommitted changes while doing other
things is hard. I mean, sometimes there just is that settings file that I
want to keep my uncommitted adjustement in forever, and sometimes I just
want to push to the central server to have a backup of something, or because
something is needed there "right now", even when I still need to write a lot
of code in other things.

And working with multiple local repositories seems to solve a lot of things,
but it's also a bit inconvenient at first sight. A reliable shelve tool
would be best I think, someone mentioned the attic extension elsewhere, I'll
give that one a try and hopefully that solves a lot of things for me.

The first version control system I worked with was SVN. Then later I had
unfortunately to work with CVS, and I liked SVN a lot better. Then now we
switched to HG and I hoped it'd be better than SVN, but I appear to have a
very hard time adjusting, simply because I still can't grasp while working
in different files than other people could even require a merge at all or
give problems with my working directory at all. Technically there seems to
be no reason for problems here. And SVN handled this always exactly as I
would expect.


Jason Harris-8 wrote:
> 
> Also some people when they are familiar with Mercurial use a few more
> advanced tools to clean up their revision history a bit before *pushing*
> Eg rebase, hist-edit, or mercurial queues.
> 
> For me I just commit with reckless abandon lots of the time without really
> thinking in huge detail about my commits (With CVS I used to have triple
> check that I didn't make some stupid goof that would be enshrined making
> me look like an idiot for all time.) 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.
> 
> Actually I find that in the end I don't always move things around. Its
> more common for me to do lots of commits and then occasionally rebase or
> reorder stuff before pushing.
> 
> (Admittedly I might find things frustrating if I couldn't occasional
> rewrite history before doing a push...)
> 
> Cheers,
>   Jas
> 
> 
> On Apr 22, 2010, at 5:10 PM, Mads Kiilerich wrote:
> 
>> Aardwolf wrote, On 04/22/2010 04:49 PM:
>>> But again, if I have uncommitted changes to file A, I have committed
>>> changes
>>> to file B, and on the "central" repository there are changes to file C.
>>> How
>>> hard can it be to automatically solve this by the tools? Isn't that what
>>> the
>>> tools are for?
>>> 
>>> Why do I have to manually do so many tricks for that situation? I'm here
>>> to
>>> write code, not someone who loves constantly playing with version
>>> control
>>> systems. They're a very good tool to me to look up file histories (what
>>> did
>>> other people do), give my changes to the rest, and get their changes,
>>> but
>>> that's about it.
>>>   
>> 
>> You are trying to use a workflow that (often) works with CVS or SVN. And
>> because these VCSs enforces a linear history you actually have to use a
>> workflow like you describe. The disadvantage is that you don't know
>> exactly what you are committing, and you can't verify that the merge is
>> correct. And sometimes things go terribly wrong.
>> 
>> Mercurial always tracks whole repositories and doesn't encourage
>> workflows where you have many different changes in your working directory
>> at once. For example, when you merge then Mercurial will use the working
>> directory to resolve conflicts,  and after the merge the working
>> directory contains exactly how the changeset will look when you commit
>> the merge. There can thus not be other changes in the working directory.
>> 
>> You have to change your work-flow a bit if you want to use Mercurial.
>> 
>> In your case I would probably wait with the merge until I am ready to
>> commit my local changes, commit them, and then merge and commit the
>> merge. If the merge goes wrong it can be discarded before commit and done
>> again.
>> 
>> If I need the other changes in order to continue I would create another
>> clone / working directory, pull the changesets that has to be merged into
>> it, do the merge and commit, and pull the result into the first working
>> directory and update. But note that the update with pending changes in
>> the working directory is slightly risky if you end up with conflicts and
>> can't resolve them correctly. Merging tracked revisions is more reliable.
>> 
>> In the trivial case where distinct files are changed then Mercurials
>> work-flow is a bit overkill. But it is 100% reliable and works in all
>> cases.
>> 
>> (And I suggest that you forget about extensions until you are familiar
>> with these work-flows.)
>> 
>> /Mads
>> _______________________________________________
>> Mercurial mailing list
>> Mercurial at selenic.com
>> http://selenic.com/mailman/listinfo/mercurial
> 
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
> 
> 

-- 
View this message in context: http://old.nabble.com/Why-can%27t-I-merge-when-there-are-uncommitted-outstanding-changes--tp28329783p28330593.html
Sent from the Mercurial mailing list archive at Nabble.com.



More information about the Mercurial mailing list