Re: Random Git Issues/Wishlist

[Shawn Pearce <spearce@spearce.org>]

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.