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

From: John Keeping <john@keeping.me.uk>
Date: May 7, 2014, 19:28 UTC
Message-ID: <20140507192805.GA9035@serenity.lan>
In-Reply-To: <xmqqvbtha04t.fsf@gitster.dls.corp.google.com>

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

Show 28 quoted lines

> John Keeping <john@keeping.me.uk> writes:
> 
> > On Tue, May 06, 2014 at 05:01:59PM -0700, Junio C Hamano wrote:
> > ...
> >> 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.
> 
> > 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.

Show 10 quoted lines

> 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.