From: Catalin Marinas <catalin.marinas@arm.com>
To: Robin Rosenberg <robin.rosenberg.lists@dewire.com>
Cc: git@vger.kernel.org
Subject: Re: StGIT and rerere
Date: Thu, 26 Oct 2006 17:34:12 +0100 [thread overview]
Message-ID: <tnxu01r2fzv.fsf@arm.com> (raw)
In-Reply-To: <200610210039.10215.robin.rosenberg.lists@dewire.com> (Robin Rosenberg's message of "Sat, 21 Oct 2006 00:39:09 +0200")
Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
> It seems stgit does not use git-rerere, so why not? Any reason other
> than it hasn't been done yet?
I didn't know it exists. I've been thinking at a way to avoid
duplicating the conflict fixing but haven't got to any results. This
looks like a good idea.
> I abuse stgit heavily, by frequently reording patches, which for
> some patches result in re-occuring conflicts. git-rerere seems to be
> the solution.
My problem was with maintaining a public branch where re-basing
patches is not welcomed but I would still like to use StGIT in my
development branch. When pulling from upstream in my devel branch, I
get conflicts in some patches. The problem is that I get the same
conflicts in the patches already merged in the public branch where the
patches were previously checked in.
Another case is several branches with common patches that generate
conflicts.
> What's the "rules" for when to invoke rerere? It seems it is mostly
> automatic in git, but since only the porcelainish commands use it,
> that means StGIT doesn't.
It could probably be invoked by stgit.git.merge() if the git-read-tree
(and maybe the diff3 merge) failed (BTW, I replaced git-read-tree with
git-recursive-merge in my local tree and seems to detect renames
properly; I'll push it once I'm convinced there are no problems).
Note, however, that I haven't looked at how git-rerere works and I
might have misunderstood its functionality.
> So here is what I *think* needs to be done. Seems simple enough.
>
> stg push, stg pick, stg import, stg goto, stg fold, stg float do
> what push does and invoke git-rerere at the end whether the push
> ends with conflicts or not
the git.merge() function handles all the merges.
> stg pop
> nothing, or do I need to remove rr-cache/MERGE_RR, like
> git-reset does?
I think pop shouldn't do anything.
> stg status --reset, stg push --undo
> remove rr-cache/MERGE_RR ?
Yes (not sure for push --undo).
> stg refresh
> do what stgit does normally and then invoke git-rerere
Why should it invoke git-rerere? This just creates a commit. Or is it
needed for storing rerere ids?
> stg resolved:
> do what stgit does normally and then invoke git-rerere
No need to call rerere here since resolved is an StGIT-only function,
it doesn't affect the repository (it just unmarks the conflict files
so that stgit allows you to refresh).
> stg clean, stge delete:
> remove rr-cache/MERGE_RR ?
That's not needed. Delete can act like pop for the top patch.
--
next prev parent reply other threads:[~2006-10-26 16:34 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-20 22:39 StGIT and rerere Robin Rosenberg
2006-10-26 16:34 ` Catalin Marinas [this message]
2006-10-26 17:21 ` Junio C Hamano
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=tnxu01r2fzv.fsf@arm.com \
--to=catalin.marinas@arm.com \
--cc=catalin.marinas@gmail.com \
--cc=git@vger.kernel.org \
--cc=robin.rosenberg.lists@dewire.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.