From: Pete Wyckoff <pw@padd.com>
To: Luke Diamand <luke@diamand.org>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 03/12] git p4: gracefully fail if some commits could not be applied
Date: Fri, 17 Aug 2012 07:58:57 -0400 [thread overview]
Message-ID: <20120817115857.GB29214@padd.com> (raw)
In-Reply-To: <502DF10A.2040306@diamand.org>
luke@diamand.org wrote on Fri, 17 Aug 2012 08:21 +0100:
> On 17/08/12 00:35, Pete Wyckoff wrote:
> >If a commit fails to apply cleanly to the p4 tree, an interactive
> >prompt asks what to do next. In all cases (skip, apply, write),
> >the behavior after the prompt had a few problems.
> >
> >Change it so that it does not claim erroneously that all commits
> >were applied. Instead list the set of the patches under
> >consideration, and mark with an asterisk those that were
> >applied successfully. Like this example:
>
> I could be wrong about this, but this change doesn't seem to help
> out with "git p4 rebase", which for me at least, is where the
> conflicts usually get picked up first.
Right, this is only about the submit path. I wasn't thinking
about rebase when I worked on this code (or read your message
about rebase ORIG_HEAD).
> I modified a file in p4, and the same file in git, and then did 'git
> p4 rebase' and it just failed in the rebase in the usual way with a
> big 'ol python backtrace.
The backtraces are not pretty, and should be fixed. I confess I
never use git p4 rebase, because it should be only git p4 sync +
git rebase @{u}. There's no conflict handling at all in the git
p4 code.
> If this patch series is intended to sort out conflict handling, then
> it needs a bit more work.
This patch series tries to fix the conflict handling in the
submit path only. Have to start somewhere.
What do you think we might do about the rebase path? It feels
like a situation that belongs to native git. Are there
p4-specific things like $Id$ tags that need help? We could
just catch the errors from git rebase more gracefully, or exec
directly into git rebase.
-- Pete
next prev parent reply other threads:[~2012-08-17 11:59 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-16 23:35 [PATCH 00/12] git p4: submit conflict handling Pete Wyckoff
2012-08-16 23:35 ` [PATCH 01/12] git p4 test: remove bash-ism of combined export/assignment Pete Wyckoff
2012-08-17 3:08 ` Junio C Hamano
2012-08-16 23:35 ` [PATCH 02/12] git p4 test: use p4d -L option to suppress log messages Pete Wyckoff
2012-08-17 6:07 ` Luke Diamand
2012-08-16 23:35 ` [PATCH 03/12] git p4: gracefully fail if some commits could not be applied Pete Wyckoff
2012-08-17 6:53 ` Johannes Sixt
2012-08-17 11:49 ` Pete Wyckoff
2012-08-17 7:21 ` Luke Diamand
2012-08-17 11:58 ` Pete Wyckoff [this message]
2012-08-16 23:35 ` [PATCH 04/12] git p4: remove submit failure options [a]pply and [w]rite Pete Wyckoff
2012-08-16 23:35 ` [PATCH 05/12] git p4: move conflict prompt into run, use [c]ontinue and [q]uit Pete Wyckoff
2012-08-16 23:35 ` [PATCH 06/12] git p4: standardize submit cancel due to unchanged template Pete Wyckoff
2012-08-16 23:35 ` [PATCH 07/12] git p4: test clean-up after failed submit, fix added files Pete Wyckoff
2012-08-16 23:35 ` [PATCH 08/12] git p4: rearrange submit template construction Pete Wyckoff
2012-08-16 23:35 ` [PATCH 09/12] git p4: revert deleted files after submit cancel Pete Wyckoff
2012-08-16 23:35 ` [PATCH 10/12] git p4: accept -v for --verbose Pete Wyckoff
2012-08-16 23:35 ` [PATCH 11/12] git p4: add submit --dry-run option Pete Wyckoff
2012-08-16 23:35 ` [PATCH 12/12] git p4: add submit --prepare-p4-only option Pete Wyckoff
2012-08-17 6:04 ` [PATCH 00/12] git p4: submit conflict handling Luke Diamand
2012-08-17 12:21 ` Pete Wyckoff
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=20120817115857.GB29214@padd.com \
--to=pw@padd.com \
--cc=git@vger.kernel.org \
--cc=luke@diamand.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 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.