Re: git-{diff,merge} refactor round 2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



David Aguilar, 05.04.2009:
> On  0, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> > David Aguilar <davvid@xxxxxxxxx> writes:
> > 
> > I'll try to queue all the outstanding da/difftool patches tonight, but I
> > think the patches in the series are getting to the point of needing a
> > fresh redoing.  Patches like "oops, these non-user scripts should have
> > been named with double-dash" can and should disappear.
> > 
> > Currently they are:
> > 
> > $ git log --oneline next..da/difftool
> > [..]
> 
> It goes back even farther...
> 
> d3b8cec difftool: move 'git-difftool' out of contrib
> 
> d3db8cec is currently sitting in 'next' and is where the
> "oops, I should have used double-dash" lack of foresight
> began.

> 1. Base it on the current master, completely throwing away
> the existing da/difftool branch.  That would include throwing
> away the commit that's in next if we really want to be clean
> about the history.  In the process, move Markus' mergetool
> fixes for windows to the top so that they can be applied
> independently if necessary.  This series would then depend
> on them.

This is my favourite, too.

Additionally, what about basing these on master as well? They also are
unrelated to the refactoring:

def88c8 mergetool-lib: specialize opendiff options when in diff mode
2a83022 mergetool-lib: add diffuse as merge and diff tool
73c59d9 mergetool-lib: specialize xxdiff options when in diff mode
273e7a2 mergetool-lib: specialize kdiff3 options when in diff mode

And start refactoring on top of these?
Then these could go into master or next, since they are mostly bugfixes
and the refactoring can start in pu.

> This would probably mean a merge conflict with next at some
> point.

Revert "d3b8cec difftool: move 'git-difftool' out of contrib" from next?

> Regardless of which it's based on, it's obvious that there'll
> be some squashing going on.  Tentatively,
> 
> Will be squashed:
> 588954e difftool: use valid_tool from git-mergetool-lib
> 8af4556 mergetool: use valid_tool from git-mergetool-lib
> 
> Will be squashed:
> 72286b5 difftool: use get_mergetool_path from git-mergetool-lib
> d03b97f mergetool: use get_mergetool_path from git-mergetool-lib
> c6afc72 Add a mergetool-lib scriptlet for holding common merge tool functions
> 
> Will be squashed:
> 99511d8 mergetool: use run_mergetool from git-mergetool-lib
> 37c48c7 difftool: use run_mergetool from git-mergetool-lib
> 4e314b5 mergetool-lib: introduce run_mergetool
> 
> Will be squashed:
> def88c8 mergetool-lib: specialize opendiff options when in diff mode
> 73c59d9 mergetool-lib: specialize xxdiff options when in diff mode
> 273e7a2 mergetool-lib: specialize kdiff3 options when in diff mode

Yes, some squashing would be nice. Similar commit messages are confusing
when reading the history.

Markus

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]