Petr Baudis <pasky@xxxxxxx> 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.
-
: 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