From: Ingo Molnar <mingo@elte.hu>
To: git@vger.kernel.org
Cc: Junio C Hamano <gitster@pobox.com>
Subject: git-rerere observations and feature suggestions
Date: Mon, 16 Jun 2008 13:01:13 +0200 [thread overview]
Message-ID: <20080616110113.GA22945@elte.hu> (raw)
We are running a rather complex Git tree with heavy use of git-rerere
(the -tip kernel tree, with more than 80 topic branches). git-rerere is
really nice in that it caches conflict resolutions, but there are a few
areas where it would be nice to have improvements:
- Fixing resolutions: currently, when i do an incorrect conflict
resolution, and fix it on the next run, git-rerere does not pick up
the new resolution but uses the old (buggy) one on the next run. To
fix it up i have to find the right entries in .git/rr-cache/* and
manually erase them. Would be nice to have "git-rerere gc <pathspec>"
to flush out a single bad resolution.
- File deletion: would be nice if git-rerere picked up git-rm
resolutions. We hit this every now and then and right now i know
which ones need an extra git-rm pass.
- Automation: would be nice to have a git-rerere modus operandi where
it would auto-commit things if and only if all conflicting files were
resolved.
- Sharing .git/rr-cache. It's quite a PITA to share the .git/rr-cache
amongst -tip maintainers right now. It seems to have dependencies on
the index file, so if we want to share the conflict resolution data,
we have to copy our index file (which is dangerous anyway and assumes
very similar repositories).
It would be much nicer if we could share conflict resolutions with
each other - and with others as well. For example linux-next could
re-use our conflict resolution data as well - often Stephen Rothwell
has to re-do the same conflict resolution as well, creating
duplicated work.
( Also, it's a GPL nitpicky issue: the conflict resolution database
can be argued to be part of "source code" and as such it should be
shared with everyone who asks. With trivial merges the data is
probably not copyrightable hence probably falls outside the scope
of the GPL, but with a complex topic tree like -tip with dozens of
conflict resolutions, the boundary is perhaps more blurred. )
Ingo
next reply other threads:[~2008-06-16 11:02 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-16 11:01 Ingo Molnar [this message]
2008-06-16 11:09 ` git-rerere observations and feature suggestions Mike Hommey
2008-06-16 15:48 ` Pierre Habouzit
2008-06-16 15:57 ` Pierre Habouzit
2008-06-16 16:18 ` Sverre Rabbelier
2008-06-17 7:37 ` Karl Hasselström
2008-06-16 11:26 ` David Kastrup
2008-06-16 11:27 ` Theodore Tso
2008-06-16 12:38 ` David Kastrup
2008-06-16 19:52 ` Ingo Molnar
2008-06-16 20:25 ` Junio C Hamano
2008-06-16 20:46 ` Ingo Molnar
2008-06-16 21:37 ` Junio C Hamano
2008-06-16 18:46 ` Junio C Hamano
2008-06-16 19:09 ` Ingo Molnar
2008-06-16 20:50 ` Junio C Hamano
2008-06-22 9:47 ` [PATCH 1/5] rerere: rerere_created_at() and has_resolution() abstraction Junio C Hamano
2008-06-22 9:47 ` [PATCH 2/5] git-rerere: detect unparsable conflicts Junio C Hamano
2008-06-22 9:47 ` [PATCH 3/5] rerere: remove dubious "tail_optimization" Junio C Hamano
2008-06-22 9:48 ` [PATCH 4/5] t4200: fix rerere test Junio C Hamano
2008-06-22 9:48 ` [PATCH 5/5] rerere.autoupdate Junio C Hamano
2008-06-18 10:57 ` git-rerere observations and feature suggestions Ingo Molnar
2008-06-18 11:29 ` Miklos Vajna
2008-06-18 18:43 ` Ingo Molnar
2008-06-18 19:53 ` Miklos Vajna
2008-06-18 11:36 ` Ingo Molnar
2008-06-18 22:01 ` Jakub Narebski
2008-06-18 22:38 ` Miklos Vajna
2008-06-19 7:23 ` Karl Hasselström
2008-06-19 7:29 ` Miklos Vajna
2008-06-19 7:30 ` Junio C Hamano
2008-06-19 8:21 ` Karl Hasselström
2008-06-19 8:33 ` Miklos Vajna
2008-06-19 9:19 ` Karl Hasselström
2008-06-19 10:06 ` Miklos Vajna
2008-06-19 10:35 ` Karl Hasselström
2008-06-16 19:10 ` Junio C Hamano
2008-06-16 19:44 ` Ingo Molnar
2008-06-23 9:49 ` Ingo Molnar
2008-06-23 14:19 ` Peter Zijlstra
2008-06-23 14:26 ` Peter Zijlstra
2008-06-23 15:12 ` Jeff King
2008-06-23 15:22 ` Ingo Molnar
2008-06-16 20:11 ` Jakub Narebski
2008-06-17 10:24 ` Johannes Schindelin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080616110113.GA22945@elte.hu \
--to=mingo@elte.hu \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).