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