John Keeping [off-list ref] writes:
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.
I think this is enough...
Thanks.
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;
- support evil merges or picking a fix-up commit;
- leaving an empty commit only to leave comment in the history.
and until that happens, I'll keep using the Reintegrate script found
in my 'todo' branch.
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.
John Keeping wrote:
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.
Using `git --html-path` for that is wrong.
--
Felipe Contreras
Junio C Hamano wrote:
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.
We need two things:
1) Provied a pkg-config, as all sane shared components do
2) Split the testing framework so third-parties don't have to rely on
yet another third-parth (shareness)
Your git-integrate might turn into something I could augment my
workflow with with some additions.
- specifying a merge strategy per branch being merged;
git-reintegrate[1] supports this.
- support evil merges or picking a fix-up commit;
git-reintegrate supports this.
- leaving an empty commit only to leave comment in the history.
Done[2].
and until that happens, I'll keep using the Reintegrate script found
in my 'todo' branch.
My git-reintegrate supports everything John's git-integrate and in
addition it supports generating the commands from an existing branch,
like your Reintegrate. IOW; it's superior.
[1] https://github.com/felipec/git-reintegrate
[2] https://github.com/felipec/git-reintegrate/commit/332412470c6e084f10ac2f8dc11e86ab4680974a
--
Felipe Contreras
On Wed, May 07, 2014 at 03:26:15PM -0500, Felipe Contreras wrote:
Junio C Hamano wrote:
quoted
Your git-integrate might turn into something I could augment my
workflow with with some additions.
- specifying a merge strategy per branch being merged;
git-reintegrate[1] supports this.
quoted
- support evil merges or picking a fix-up commit;
git-reintegrate supports this.
quoted
- leaving an empty commit only to leave comment in the history.
Done[2].
quoted
and until that happens, I'll keep using the Reintegrate script found
in my 'todo' branch.
My git-reintegrate supports everything John's git-integrate and in
addition it supports generating the commands from an existing branch,
like your Reintegrate. IOW; it's superior.
And yet the documentation is unchanged from the version you copied in
from git-integration. Personally I would much rather use a project
which takes time to document all of the features rather than relying on
reading the code to figure out the options.
More features does not make a project superior.
John Keeping wrote:
On Wed, May 07, 2014 at 03:26:15PM -0500, Felipe Contreras wrote:
quoted
Junio C Hamano wrote:
quoted
Your git-integrate might turn into something I could augment my
workflow with with some additions.
- specifying a merge strategy per branch being merged;
git-reintegrate[1] supports this.
quoted
- support evil merges or picking a fix-up commit;
git-reintegrate supports this.
quoted
- leaving an empty commit only to leave comment in the history.
Done[2].
quoted
and until that happens, I'll keep using the Reintegrate script found
in my 'todo' branch.
My git-reintegrate supports everything John's git-integrate and in
addition it supports generating the commands from an existing branch,
like your Reintegrate. IOW; it's superior.
And yet the documentation is unchanged from the version you copied in
from git-integration.
Not much has changed since v0.1 since that version already worked
perfectly. But I'll update it.
Personally I would much rather use a project which takes time to
document all of the features rather than relying on reading the code
to figure out the options.
And I would rather use a project that concentrates on having the
features users need.
More features does not make a project superior.
No, better features do.
Either way. Documentation updated.
--
Felipe Contreras