Junio C Hamano writes:
> Amadeusz Żołnowski writes:
>
>>> Has anything happened to this topic after this? I am wondering if I
>>> should discard the topic az/p4-bare-no-rebase without prejudice.
I think you can discard the topic, because we're moving
Amadeusz Żołnowski writes:
>> Has anything happened to this topic after this? I am wondering if I
>> should discard the topic az/p4-bare-no-rebase without prejudice.
>
> Sorry, I haven't got time to take a loot at this, but I'll return to
> that soon, OK? I'll prepare a
Hi,
Junio C Hamano writes:
> Has anything happened to this topic after this? I am wondering if I
> should discard the topic az/p4-bare-no-rebase without prejudice.
Sorry, I haven't got time to take a loot at this, but I'll return to
that soon, OK? I'll prepare a patch with
Luke Diamand writes:
> On 28 February 2016 at 20:46, Amadeusz Żołnowski wrote:
>
>>
>> True. For now I have these cases covered by wrapper scripts. The minimum
>> I need from git-p4 is just not to fail on git submit from bare
>> repository which is
On 28 February 2016 at 20:46, Amadeusz Żołnowski wrote:
>
> True. For now I have these cases covered by wrapper scripts. The minimum
> I need from git-p4 is just not to fail on git submit from bare
> repository which is covered by patch I have submitted. If I get my
>
Luke Diamand writes:
> On 23 February 2016 at 20:56, Amadeusz Żołnowski wrote:
>>
>> To simplify things, why not just update ref during submit from bare
>> repository? As you have pointed out, if user invokes submit in this
>> context he/she actually
On 23 February 2016 at 20:56, Amadeusz Żołnowski wrote:
>
> To simplify things, why not just update ref during submit from bare
> repository? As you have pointed out, if user invokes submit in this
> context he/she actually wants to submit from bare repo and probably
> knows
Hi Luke,
Luke Diamand writes:
> 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.
I have created a Git repository acting as a bridge
On 23 February 2016 at 06:59, Junio C Hamano wrote:
> Amadeusz Żołnowski writes:
>
>> Junio C Hamano writes:
>>> I wonder if it makes sense to just silently allowing submit without
>>> rebasing, and without telling the user how to
Amadeusz Żołnowski writes:
> Junio C Hamano 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
Junio C Hamano 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
Amadeusz Żołnowski 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
Hi Junio,
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
Amadeusz Żołnowski writes:
> git-p4 can be successfully used from bare repository (which may act as a
> bridge between Perforce repository and pure Git repositories). After
> submitting changelist to Perforce, git-p4 performs unconditional rebase
> which obviously fails.
>
git-p4 can be successfully used from bare repository (which may act as a
bridge between Perforce repository and pure Git repositories). After
submitting changelist to Perforce, git-p4 performs unconditional rebase
which obviously fails.
Perform rebase only on non-bare repositories, so submit
15 matches
Mail list logo