p...@padd.com wrote on Thu, 05 Jul 2012 08:30 -0400:
> l...@diamand.org wrote on Thu, 05 Jul 2012 08:20 +0100:
> > On 04/07/12 14:34, Pete Wyckoff wrote:
> > >The code is unused. Delete.
> >
> > I've used that non-interactive code path in the past, in the very
> > early days of using it (setting interactive to false manually).
> >
> > The nice thing about it is that if you're using git-p4 for the very
> > first time it lets you do the final submission to p4 by hand,
> > without having to trust the script to do the right thing. Once I
> > convinced myself that git-p4 was doing the right thing, I then
> > stopped using it.
> >
> > Is it worth retaining, perhaps fixed so that it can be set on the
> > command line and documented? Or just discard?
>
> My biggest complaint is that there's no way to enable the option.
> You have to edit the code to change self.interactive to False, as
> you pointed out.
>
> Then it doesn't help you with the submit message, and doesn't
> do the little details of cleaning up pure-copied files or
> changing the username for preserveUser.
>
> What you're doing makes sense, though, but maybe there's a
> cleaner way to provide that functionality.
>
> We could build the change then say "type p4 submit -c ... if it
> looks good". Still doesn't handle the little details.
>
> We could spawn a shell to let them go inspect.
>
> We could try to implement a "--continue" option, and give them
> a chance to edit.
>
> I've got an upcoming series that changes the interaction loop on
> conflict, and makes it easier to do some interaction at each
> patch, possibly before applying too. Might make things easier.
I did code up two new options to "git p4 submit":
--dry-run : just show the commits that would be submitted
--prepare-p4-only : open/add, apply patch, but do not submit
The latter prints a rather lengthy message about how to submit
or revert the changes. It fills the role of self.interactive,
hopefully.
I'll send the patches out for review once the other in-flight
changes have settled.
-- Pete
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
