On 23 February 2016 at 06:59, Junio C Hamano <gits...@pobox.com> wrote:
> Amadeusz Żołnowski <aide...@aidecoe.name> writes:
>
>> Junio C Hamano <gits...@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.
>
--
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
