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

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

 



Amadeusz Żołnowski <aidecoe@xxxxxxxxxxxx> writes:

> To submit changes from master branch to Perforce, new commits should be
> based on a remote branch p4/master:
>
> (1)
>                   E'---F' master
>                  /
>     A---B---C---D p4/master
>
> Commits from A to D map to Perforce changelists. These commits include
> additional metadata in commit message which most important is changelist
> number.
>
> On submit git-p4 prepares changelists for commits E'-F' and submits
> these to Perforce repository. After this operation it syncs back remote
> branch p4/master. This is the common part for both bare and non-bare
> repository.
>
> (2)
>                   E'---F' master
>                  /
>     A---B---C---D---E---F p4/master
>
> In non-bare repository git rebase is performed and it results in
> following state:
>
> (3)
>     A---B---C---D---E---F p4/master, master

That is because you would want your further work to be built on top
of F, not F'.

> In bare repository this operation cannot be performed, so it remains in
> state (2).

And that is what made me wonder.

> With special care state (2) can be transformed to state (3) with manual
> update of refs/heads/master with refs/remotes/p4/master.

What do you mean by transforming with special care?  Do you mean running

    $ git update-ref master remotes/p4/master

or does it involve something else?  Is it a fairly involved
procedure, I wonder if it makes sense to just silently allowing
submit without rebasing, and without telling the user how to clean
it up.

And if it is really is the matter of update-ref, wouldn't that
procedure apply equally well to a submit made from a non-bare
repository?

> I understand that implementing rebase for bare repository is unsafe and
> it wouldn't be appreciated. Therefore we have to resort to such a
> barbarity and git-p4 submit shouldn't attempt to perform a rebase
> operation itself. Especially because it performs other operations before
> and we end up in the intermediate state (2) anyway.
>
> Is this explanation satisfactory?

Not quite yet.  It is better than no explanation, but it does not
quite convince me (a non-git-p4 user) that it makes sense to allow
submitting in a bare repository in the first place.

This is not an informed objection; I want to first understand why
doing this is safe and does not hurt the end users.


--
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]