Re: Random Git Issues/Wishlist

From: Shawn Pearce <spearce@spearce.org>
Date: Jul 23, 2006, 04:27 UTC
Message-ID: <20060723042725.GA12306@spearce.org>
In-Reply-To: <20060722195502.GS13776@pasky.or.cz>

Petr Baudis <pasky@suse.cz> wrote:

>   (iii) Lazy clone, shallow clone, whatever you call it. This has
> several possible degrees of implementation:

I'd love to work on this, but I just don't have time.  :-(

>   (vi) Renames - should we follow them in logs? Will we? When? How
> exactly in the interesting cases?

I thought this has been settled as ``we will not record renames directly, but instead rely on after-the-fact comparsions to identify renames and copies based on content similarity''.

The rename identification code in diffcore isn't the fastest, but
I think someone suggested caching the results of rename comparsions
under .git as a way of speeding that up.  Unfortunately nobody has
stepped forward with a reasonable caching implementation, and I
think it was also debated that caching is probably not worthwhile
due to the high number of permutations people would typically be
asking for from diffcore.

>   (viii) Patches versioning in StGit - many people I've told about StGit
> complained that it doesn't version patches (and possibly moved to mq?).
> We should have some scheme for doing meta-history (especially
> interesting when/if we aim to make altering history easy).

Doesn't StGit now have a single ref for every patch commit? What about turning on reflog support on those refs and reading the reflog for the ``history'' of that patch? Granted the reflog isn't prune proof but it is a history of that ref's values over time.

You can already go back in that history with the @{yesterday}
syntax (e.g. "HEAD@{yesterday}") anywhere a sha1 expression is
valid (e.g. git-log) but StGit doesn't take advantage of it.

>   (xii) Special merging - I now maintian the SuSE glibc package in git
> and I'd like to use something more sensible than diff3 merger for
> merging the changelogs from various branches; it's trivially solvable
> conflicts all the time

I've been waiting for the C based recursive merger to get stable before I take a crack at parameterizing the `merge` invocation. I much prefer using patch reject files for conflict resolution, but that's just me. (Besides opening a single patch process and shoving a stream of all diffs at it is faster on Cygwin than forking 30+ merge processes for 30 files with conflicts.)

I take it you are really asking for a way to parameterize the 3 way merge tool on a file-by-file basis, e.g. adding to the config file:

	[mergetool "default"]
		program = merge %real %stage1 %stage3
		real = stage2

	[mergetool "ChangeLog"]
		program = change-log-merger %stage1 %stage2 %stage3 %real

	[mergetool "some/bad/binary-file"]
		program = cp %stage2 %real

An issue with storing this data in the config file is what happens if the stuff stored at the path "some/bad/binary-file" changes such that simply using `cp` (as above) is horribly wrong. Another is how do you pass these "reasonable defaults" off to other team members on a repository-by-repository basis, assuming you all have access to the same tools (e.g. the change-log-merger mentioned above).

-- 
Shawn.