From: John Keeping <john@keeping.me.uk>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Michael Haggerty <mhagger@alum.mit.edu>
Subject: Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)
Date: Wed, 7 May 2014 20:28:05 +0100 [thread overview]
Message-ID: <20140507192805.GA9035@serenity.lan> (raw)
In-Reply-To: <xmqqvbtha04t.fsf@gitster.dls.corp.google.com>
On Wed, May 07, 2014 at 11:56:18AM -0700, Junio C Hamano wrote:
> 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.
> 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.
next prev parent reply other threads:[~2014-05-07 19:38 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-29 22:38 What's cooking in git.git (Apr 2014, #09; Tue, 29) Junio C Hamano
2014-05-05 18:45 ` John Keeping
2014-05-05 19:08 ` Felipe Contreras
2014-05-05 19:55 ` John Keeping
2014-05-05 20:34 ` Felipe Contreras
2014-05-05 21:43 ` Felipe Contreras
2014-05-06 17:59 ` Junio C Hamano
2014-05-06 18:54 ` Felipe Contreras
2014-05-05 23:50 ` Junio C Hamano
2014-05-06 0:20 ` Felipe Contreras
2014-05-06 0:39 ` Felipe Contreras
2014-05-06 8:07 ` John Keeping
2014-05-06 8:32 ` Felipe Contreras
2014-05-06 19:34 ` Junio C Hamano
2014-05-06 19:39 ` Felipe Contreras
2014-05-07 11:44 ` Greg Troxel
2014-05-07 19:54 ` Felipe Contreras
2014-05-07 23:38 ` Greg Troxel
2014-05-08 0:18 ` Felipe Contreras
2014-05-08 7:29 ` Chris Packham
2014-05-08 7:56 ` Felipe Contreras
2014-05-09 0:40 ` David Lang
2014-05-09 0:58 ` Felipe Contreras
2014-05-09 0:58 ` Submodule improvements (Re: What's cooking in git.git (Apr 2014, #09; Tue, 29)) Jonathan Nieder
2014-05-08 18:31 ` What's cooking in git.git (Apr 2014, #09; Tue, 29) Junio C Hamano
2014-05-07 0:01 ` Junio C Hamano
2014-05-07 0:17 ` Felipe Contreras
2014-05-07 8:05 ` John Keeping
2014-05-07 9:26 ` Felipe Contreras
2014-05-07 18:56 ` Junio C Hamano
2014-05-07 19:28 ` John Keeping [this message]
2014-05-07 19:50 ` Felipe Contreras
2014-05-07 20:26 ` Felipe Contreras
2014-05-07 20:44 ` John Keeping
2014-05-07 21:38 ` Felipe Contreras
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140507192805.GA9035@serenity.lan \
--to=john@keeping.me.uk \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=mhagger@alum.mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).