luke@xxxxxxxxxxx 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html