New evolve docs, take 2: 2/3: user-guide.rst

Martin Geisler martin at geisler.net
Sat May 31 09:46:21 UTC 2014


Greg Ward <greg at gerg.ca> writes:

> On 29 May 2014, Pierre-Yves David said:
>> 
>> Maybe: we could emphasize the fact that a changeset turns public when
>> it is -exchanged-. Because rewriting it will have consequence on
>> other repo we do not control. Then say that for this happen
>> automatically when you push
>
> I don't understand. I've just done a quick test to confirm my
> assumptions, and they were correct: draft changesets in repo A only
> become public when they are pushed to a publishing repo B. Pulling
> from A to B doesn't affect A. Cloning A to B doesn't affect A. Only
> pushing affects A. (I'm not sure if that is the *desired* behaviour,
> but it's what I'm seeing.)

It was decided that read-only operations (pull, clone) shouldn't modify
the repository they read from -- they should remain read-only. The
thinking is that read operations often cannot modify the repository and
it would be confusing to let them change phases only sometimes.

>> >Modify (rewrite) a changeset: ``commit --amend``
>> >------------------------------------------------
>> 
>> We can probably be more specific. What `commit --amend` does is
>> "adding more changes to a changeset" not sure about how to phrase
>> that.
>
> Well... no. You know better than I do that all this talk of
> "modification" is an oversimplification. IMHO "rewrite" is an
> excellent one-word description of what's really going on. So is
> "replace", which has the advantage of an obvious noun form:
> "replacement".

I think "replace" is the best word: to me, it clearly implies that a new
commit takes the place of an old commit, and that the old commit is left
unmodified. The last bit is important since we've explained people that
commits are immutable.

>> E. Taking advantage of the obsgraph
>> 
>>   - how to see obsolete changeset
>
> Just to make sure I'm not missing an easier way, this is "hg --hidden
> log -vp -r $OBSREV" right?

Well, technically you just need to tell people that "--hidden" shows the
hidden changesets. That's a global flag and can thus be used with all
commands. Whatever other flags they want to tag onto 'hg log' is then up
to them.

>>   - how to compare to them
>
> And this is "hg --hidden diff -r $OBSREV:$REV"?

Yes, or you could use the precursors/successors revsets and do

  hg --hidden diff -r "precursors(R):R"

Pierre-Yves: has there been talk about letting some revset functions
turn on the --hidden flag automatically? I think that would be handy for
revsets like this where (as far as I can tell?) you always want to show
hidden commits.

>>   - how to restore previous version
>
> hg touch, right? I've actually never used it! Does it need --hidden?

Me neither :) Testing shows that it does need --hidden. That's
consistent, but a little silly somehow.

-- 
Martin Geisler

http://google.com/+MartinGeisler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-evolve-testers/attachments/20140531/be31d719/attachment.asc>


More information about the Evolve-testers mailing list