C-hglib - Level 0, API proposal.

[Martin Geisler]

Giovanni Gherdovich <g.gherdovich at gmail.com> writes:

> Hello Iulians,
>
> sorry for my latency in replying, been a bit busy lately.
>
> I am going to answer your mail with more details later today,
> but just a few "spoilers" for now:
>
>> b) hg log <- can produce huge output
>> I know that some repo could have a huge log,
>> but I don't know if the user will use that huge output.
>> My single thought right now is to set a limit for the huge mass of data.
>
> Err... No way.
>
> Please work harder on this. Discarding output from `hg log`
> is simply not acceptable. We can do (much) better.
>
>> d) hg merge <- has prompts
>> By default, if there will be any prompts the merge will abort.
>
> Again, no.
>
> A merge prompt is "Dear user, I have found some conflicts while
> merging this two files. I would really appreciate your help in solving
> them."
> Replying "F*ck you" to such a gentle request from mercurial
> would be very unpolite. We are a bunch of nice guys.

I think you should look at how python-hglib and JavaHg does this. They
both use a callback function that the programmer who uses the library
must supply. The callback function should answer the prompts.

In JavaHg we call this a ManifestMergeOracle and you can see how it's
used here:

  https://bitbucket.org/aragost/javahg/src/2b111ee65545/src/test/java/com/aragost/javahg/commands/MergeCommandTest.java?at=default#cl-125

The idea is that a GUI can run the merge and let Mercurial answer with a
default answer to the 'foo modified in local and deleted in other'
prompts. The overall merge state is tracked and the GUI can get a list
of missing answers afterwards. They will typically be presented to the
user, who must fill in the correct answers.

I believe the python-hglib tries to do something similar, but that it
doesn't yet track the merge state in a dedicated object. The handlers in
python-hglib are here:

  http://selenic.com/repo/python-hglib/file/c13b99b01008/hglib/merge.py

-- 
Martin Geisler