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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 23 February 2016 at 06:59, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Amadeusz Żołnowski <aidecoe@xxxxxxxxxxxx> writes:
>
>> Junio C Hamano <gitster@xxxxxxxxx> 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.
>
--
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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]