git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@gmail.com>
To: "Karl Hasselström" <kha@treskal.com>
Cc: git <git@vger.kernel.org>
Subject: Re: bug?: stgit creates (unneccessary?) conflicts when pulling
Date: Fri, 03 Mar 2006 22:07:38 +0000	[thread overview]
Message-ID: <4408BE2A.1060601@gmail.com> (raw)
In-Reply-To: <20060303142413.GB16456@diana.vm.bytemark.co.uk>

Karl Hasselström wrote:
> On 2006-02-28 22:45:56 +0000, Catalin Marinas wrote:
>>I attached another patch that should work properly. It also pushes
>>empty patches on the stack if they were merged upstream (a 'stg
>>clean' is required to remove them). This is useful for the push
>>--undo command if you are not happy with the result.
> 
> It appears to work for me. I still had to fix things up manually when
> pulling the uncommit patch though, since you had made a minor change
> in "uncommit.py":
> 
>   Pushing patch "uncommit"...Error: File "stgit/commands/uncommit.py" added in branches but different

Yes, I made some minor modifications (one of them was the copyright).

> Is there a way to make stgit not fall on its face when faced with this
> situation? Surely it ought to be possible to create a merged file with
> conflict markers? (I realize this is harder when there is no common
> ancestor, but these files are 95% identical!)

I've been thinking about this but it's not straight-forward. I tried
using /dev/null as the common ancestor but both diff3 and wiggle put the
whole file text in the conflict regions. These tools are not smart
enough to compare the conflict regions and reduce them.

Another approach would be to have a script that creates the common
ancestor only with the common lines between the two files and pass this
file as an argument to diff3. This wouldn't probably be that difficult,
maybe some combination of diff and sed and apply the result to one of
the files to remove the diff'ed lines.

Catalin

  reply	other threads:[~2006-03-03 22:07 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-27 20:42 bug?: stgit creates (unneccessary?) conflicts when pulling Karl Hasselström
2006-02-27 21:45 ` Sam Vilain
2006-02-27 22:17 ` Catalin Marinas
2006-02-28 15:00   ` Catalin Marinas
2006-02-28 18:53     ` Catalin Marinas
2006-02-28 22:45   ` Catalin Marinas
2006-03-01 17:39     ` Chuck Lever
2006-03-01 17:53       ` Catalin Marinas
2006-03-03 14:13         ` Karl Hasselström
2006-03-03 21:57           ` Catalin Marinas
2006-03-03 14:24     ` Karl Hasselström
2006-03-03 22:07       ` Catalin Marinas [this message]
2006-02-27 22:26 ` Shawn Pearce
2006-03-01 10:59   ` Catalin Marinas
2006-03-01 14:51     ` Shawn Pearce
2006-03-01 15:08       ` Catalin Marinas
2006-03-01 15:50         ` Shawn Pearce
2006-03-09 22:00           ` Catalin Marinas
2006-03-09 23:20             ` Junio C Hamano
2006-03-10 11:13               ` Catalin Marinas
2006-03-11  6:46                 ` Junio C Hamano
2006-03-10 16:23             ` Shawn Pearce

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=4408BE2A.1060601@gmail.com \
    --to=catalin.marinas@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=kha@treskal.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).