Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)

On Wed, May 07, 2014 at 11:56:18AM -0700, Junio C Hamano wrote:

John Keeping [off-list ref] writes:

quoted

On Tue, May 06, 2014 at 05:01:59PM -0700, Junio C Hamano wrote:
...

quoted

Another thing to keep in mind is that we need to ensure that we give
a good way for these third-party tools to integrate well with the
core Git tools to form a single toolchest for the users.  I would
love to be able to do

    $ (cd git.git && make install)
    $ (cd git-imerge.git && make install)

and then say "git imerge", "git --help imerge", etc.  The same for
the remote helpers that we may be splitting out of my tree into
their own stand-alone projects.

This can already work given suitable installation.  With
git-integration[1] I can type `git help integration` and it shows me the
man page in the same way that `git help commit` does.  When I manually
linked the HTML file to the right place `git help -w integration` worked
as well.

That "when I manually" part is what I meant by "we give a good way
for these third-party tools" above, and "make it really easy to
install these third-party tools" in the remaining part of the
message you are responding to.

quoted

I think this is enough...

Having thought about it a bit more after reading Felipe's reply, it
would be nice if there were some way for third-party tools to install
HTML documentation without relying on `git --html-path` but I cannot see
an obvious way to do that as there isn't a standard $HTML_PATH to match
$MAN_PATH and $PATH.

I've never tried `git help --info` until this thread, but I think we
could make some trivial improvements to that in order to support .info
documentation for third-party tools.

The reason why I CC'ed Michael was primarily because I thought you
were not one of those third-party tools maintainers (and secondarily
I am a fairly big fan of imerge), but it is good to hear your
opinion as another third-party provider.  Your git-integrate might
turn into something I could augment my workflow with with some
additions.  What is missing (I only read the full manual page at
http://johnkeeping.github.io/git-integration/git-integration.html)
to support my workflow seems to be:

 - specifying a merge strategy per branch being merged;

This is already supported by the "merge" instruction:

	If any options are given after the ref (and on the same line)
	then these are passed to git merge. This may be useful for
	specifying an alternative merge strategy for a branch.

 - support evil merges or picking a fix-up commit;

I have an implementation of this on a branch, but have never merged it
because it's not something I need to do often and it is very hard to
support for git-integration's "status" output.

One of my primary use cases for git-integration involves pulling
together branches owned by others (either in the same repository or by
having fetched from their repositories); in this case it is interesting
to see if/how a branch has changed since the last time the integration
branch was built.  This also handles changes to the instruction sheet
without an immediate rebuild.

I have not found a good way of figuring out whether a fixup commit has
been applied and squashed into a merge) so I have let the branch sit
there awaiting a perfect solution (which I doubt exists).  It may be
that the status of a fixup is unimportant, so it could just be marked as
unknown; I am mostly convinced that marking it as unknown is going to be
better than an heuristic that is right most of the time.

 - leaving an empty commit only to leave comment in the history.

This would be easy to add.

and until that happens, I'll keep using the Reintegrate script found
in my 'todo' branch.

When I originally wrote git-integration I purposefully did not target
your workflow because I (perhaps wrongly) assumed that the interaction
between the different integration branches would mean that Git was
better served sticking to the custom Reintegrate script.