git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

             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).