All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vincent van Ravesteijn <vfr@lyx.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: Edit a rerere conflict resolution
Date: Mon, 12 Mar 2012 22:39:32 +0100	[thread overview]
Message-ID: <4F5E6D14.2060306@lyx.org> (raw)
In-Reply-To: <7vipi9pkpw.fsf@alter.siamese.dyndns.org>

Op 12-3-2012 22:34, Junio C Hamano schreef:
> Vincent van Ravesteijn<vfr@lyx.org>  writes:
>
>>> The problem I have with "rerere edit" is it is an offline process,
>>> and to validate that the update is correct, I would have to have the
>>> problematic merge in my working tree once _anyway_.  And at that
>>> point, updating the target file in the working tree and recording
>>> the updated resolution using the usual "git rerere" feels a more
>>> natural way to do so, and more importantly, it is a more convenient
>>> way to do the "update and validate".  On the other hand, "rerere
>>> edit" is a more convenient way to "update but not validate the
>>> result".
>> This last part probably makes the difference indeed. In my case the
>> merge resolution was very very easy (the conflicting hunks have
>> fileformat version numbers), but it is a bit annoying and it requires
>> some 'vim'-skills to redo the merge conflict just to correct a newline
>> somewhere, or a missing ','.
> Now you confused me.  How do you envision your "rerere edit" not to
> require "vim-skills" that is needed to navigate to the problematic
> line to correct a newline or comma?  To put it another way, how much
> more "vim-skills" is needed to fix the conflict in the real file,
> than "rerere edit"?

Well, I often paste lines in the line below the line I wanted to paste 
to, in python files I often get whitespace errors,  when cutting line I 
always have to guess how many lines there are... anyway, I don't feel 
very comfortable.

Editing the postimage by just inserting an enter seems easier.

Vincent

  reply	other threads:[~2012-03-12 21:39 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-12 19:14 Edit a rerere conflict resolution Vincent van Ravesteijn
2012-03-12 20:01 ` Junio C Hamano
2012-03-12 20:20   ` Vincent van Ravesteijn
2012-03-12 20:34     ` Junio C Hamano
2012-03-12 21:21       ` Vincent van Ravesteijn
2012-03-12 21:34         ` Junio C Hamano
2012-03-12 21:39           ` Vincent van Ravesteijn [this message]
2012-03-12 21:40         ` Jakub Narebski
2012-03-12 21:52           ` Junio C Hamano
2012-03-16 15:54   ` Vincent van Ravesteijn
2012-03-16 16:01     ` Junio C Hamano
2012-03-16 16:14       ` Vincent van Ravesteijn
2012-03-16 16:20         ` Junio C Hamano
2012-03-16 16:37           ` Vincent van Ravesteijn
2012-03-16 16:42           ` Junio C Hamano
2012-03-17 11:03             ` Vincent van Ravesteijn

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=4F5E6D14.2060306@lyx.org \
    --to=vfr@lyx.org \
    --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 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.