Re: [PATCH] git-p4.py: Make submit working on bare repository

From: Luke Diamand <luke@diamand.org>
Date: Feb 23, 2016, 12:05 UTC
Message-ID: <CAE5ih7_vBMsi+zRZRTCaO56VrOYZUR0NQ0CSSE+Do48xkJ_BwA@mail.gmail.com>
In-Reply-To: <xmqqegc33oal.fsf@gitster.mtv.corp.google.com>

On 23 February 2016 at 06:59, Junio C Hamano <gitster@pobox.com> wrote:

Show 19 quoted lines

> Amadeusz Żołnowski <aidecoe@aidecoe.name> writes:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>>> I wonder if it makes sense to just silently allowing submit without
>>> rebasing, and without telling the user how to clean it up.
>>
>> It is a good point. Maybe submit shouldn't be allowed by default at all
>> From bare repository. What do you think about following approach?  If
>> core.base is true, then if git-p4.submitFromBare is also true then
>> submit without performing proper rebase, but update master ref from
>> p4/master. If core.base is true, but git-p4.submitFromBare is false,
>> abort immediately. Submitting from bare repository would require aware
>> decision from a user.
>
> (I think you meant "bare" where you wrote "base" in the above).
>
> As a non user of git-p4, the above sounds a safe and sensible
> approach, but I'd like to hear from Luke, who has been active in
> this area and is far more expert than I am ;-)

Sorry, I've been travelling so not been able to reply earlier. Jetlag has now kicked-in, and 4am is the perfect time to reply to this!

I think it would help to understand why we're doing a git-p4 submit from a bare repo in the first place.

The usual workflow is you have a normal repo and submit from that.

I'm guessing that the reason for using a bare repo is so that changes can be pushed to it from several different git repos. This then saves doing the initial git-p4 clone multiple times.

As Amadeusz pointed out, the submit fails:

$ git p4 submit --git-dir=/path/to/bare/repo ... ... fatal: This operation must be run in a work tree Some files in your working directory are modified and different than what is in your index. You can use git update-index <filename> to bring the index up-to-date or stash away all your changes with git stash.

If this had actually worked, I think the next thing I would want to do is to rebase one or more branches in the bare repo against p4/master. I don't think there's any way that git-p4 can work out which branches would be rebased, and nor should it.

I think the approach of using a submitFromBare config variable to force the user to make a choice feels a bit bogus, since they clearly *want* to submit from this bare repo, as otherwise they wouldn't have done "git-p4 submit" in the first place.

It might make sense to have a command-line or config option ("--skip-rebase" ?) to tell "submit" to only do the submit part, and skip the rebase stage (and get the rebase stage to give a more useful error message on a bare repo when the option isn't used). That would then mean that git-p4 does not have to know if it's running in a bare repo or not, and the submit-without-rebase functionality is available to people doing other different things not involving bare repos (which we haven't though of yet) but still requiring submit without rebase.

Luke

>
> Thanks.
>