From: Catalin Marinas <catalin.marinas@gmail.com>
To: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Stgit - gitmergeonefile.py: handle removal vs. changes
Date: Tue, 15 Nov 2005 09:54:43 +0000 [thread overview]
Message-ID: <b0943d9e0511150154y2d2af24ck@mail.gmail.com> (raw)
In-Reply-To: <20051113194225.20447.57910.stgit@zion.home.lan>
On 13/11/05, Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> wrote:
> I just got a "removal vs. changed" conflict, which is unhandled by StGit. That
> is taken from git-merge-one-file resolver, but is bad, as stg resolved does not
> handle unmerged entries (and probably it should be fixed too).
I think it 'stg resolved' should be fixed as well (in case there are
unmerged entries for other reasons). My initial idea was to make
gitmergeonefile not to leave any unmerged entries in the index. As you
could see, there are cases where it failed.
I can see the following scenarios for a file:
1. deleted in the base and modified by the patch. It should leave the
file in the tree together with file.older. Another option would be to
remove the file and leave both file.older and file.remote in the tree
(here .remote means the version in the patch) but I would prefer the
first one.
2. changed in the base but deleted by the patch. It should remove the
file from the tree but leave file.older and file.local. The other
option is to leave the file in the tree but, as above, I prefer the
first one.
Maybe StGIT should try to track the renaming as well but I haven't
played with this feature in GIT at all.
--
Catalin
next prev parent reply other threads:[~2005-11-15 9:54 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-13 19:42 [PATCH] Stgit - gitmergeonefile.py: handle removal vs. changes Paolo 'Blaisorblade' Giarrusso
2005-11-15 9:54 ` Catalin Marinas [this message]
2005-11-16 14:44 ` Blaisorblade
2005-11-17 22:10 ` Catalin Marinas
2005-11-17 22:50 ` Chuck Lever
2005-11-21 21:32 ` Catalin Marinas
2005-12-30 17:59 ` Blaisorblade
2006-01-07 11:23 ` Catalin Marinas
2006-01-08 1:50 ` Chuck Lever
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=b0943d9e0511150154y2d2af24ck@mail.gmail.com \
--to=catalin.marinas@gmail.com \
--cc=blaisorblade@yahoo.it \
--cc=git@vger.kernel.org \
/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).