Completely baffled

[Becker, Mischa J]

> -----Original Message-----
> From: mercurial-bounces at selenic.com [mailto:mercurial-bounces at selenic.com] On Behalf Of Haszlakiewicz, Eric
> Sent: Monday, December 05, 2011 9:47 AM
> To: Isaac Jurado; Liam Routt
> Cc: mercurial at selenic.com
> Subject: RE: Completely baffled
>
>> -----Original Message-----
>> From: mercurial-bounces at selenic.com [mailto:mercurial-
>>
>> On Mon, Dec 5, 2011 at 10:37 AM, Liam Routt
>> <liam.routt at mediasaints.com> wrote:
>> >
>> > Just as a followup, we managed to lose the last two days of work by one of
>> > our developers today with Mercurial, which really hurts.
>> >
>> > Prior to doing the checkin of the work he'd done, he did a pull + update.
>
> He didn't happen to specify --clean when he ran the update command, did he?
>
>> This is a bad practice and a curse inherited from Subversion and
>> similar systems (like Bazaar in centrlized mode).
>>
>> In distributed VCS you always commit first, then pull and merge (or
>> rebase, depends on how confident you are with the tool).  I had a hard
>> time explaining my colleagues at work to stop using "hg pull -u" and
>> committing first instead.

> For many people that's a completely absurd workflow.  Just because I'm pulling
> in changes from someone else doesn't mean that I'm anywhere near ready to
> commit my changes.  I often (i.e. every week) work on things where my local
> files have assorted changes that are inappropriate to make part of the change
> history.   e.g. comments I add while figuring out the logic of the code
> (occasionally obscene, if the code is particularly bad :) ), temporary debugging
> statements, misguided experiments, etc...
>
> I'm pretty sure I'm not the only one that works this way; just look at the popularity
> of things like mq and shelve.
>
> eric

Yeah, I used to do that, then I'd spend half a day coding in a certain direction only to discover that I was going in the wrong direction and making things worse, not better.  At that point I want to revert the code back to where it was that morning, only I couldn't because I hadn't done any commits for the very reasons you give.  It finally dawned on me that just because you should commit often, doesn't mean you have to commit to the working/development branch.  In those situations, I create a branch named temp and commit to it.  I can then pull and merge other people's code into my temp branch if needed.  When I'm ready to do a 'real' commit I move my completed change to the working branch using whatever works best. (rebase collapse/shelve/mq/etc.) and then strip the temp branch.  If you are worried about accidently pushing the temp branch, create a hook to prevent it.

Mischa Becker

________________________________

This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is confidential and protected by law from unauthorized disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.