All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Amadeusz Żołnowski" <aidecoe@aidecoe.name>
To: Luke Diamand <luke@diamand.org>
Cc: Junio C Hamano <gitster@pobox.com>
Cc: Git Users <git@vger.kernel.org>
Subject: Re: [PATCH] git-p4.py: Make submit working on bare repository
Date: Tue, 23 Feb 2016 20:56:32 +0000	[thread overview]
Message-ID: <871t83cfi7.fsf@freja.aidecoe.name> (raw)
In-Reply-To: <CAE5ih7_vBMsi+zRZRTCaO56VrOYZUR0NQ0CSSE+Do48xkJ_BwA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2585 bytes --]

Hi Luke,

Luke Diamand <luke@diamand.org> 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 between Perforce and
pure Git repos. Changes pushed to master branch on this bridge repo get
submitted to Perforce repository (referenced via remote p4/master).


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

It actually has all information needed. It submits commits from a given
branch to a branch specified with --branch option (or default p4
remote). When submitting from a non-bare repo git-p4 has the same set of
information: the current branch and a branch specified with --branch (or
default p4 remote).


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

I agree, a good point.


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

While having additional --skip-rebase is a good idea, having git-p4
doing rebase would be more elegant for those who actually use GitP4 in
bare repository. In message 87fuwnd4u7.fsf@freja.aidecoe.name I have
described how state of branches changes during submit. It clearly shows
that in case of a bare repository it ends up in undesired state.

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 what he/she is doing - especially if he/she reads man page. (-:


Kind regards,

-- 
Amadeusz Żołnowski

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 950 bytes --]

  reply	other threads:[~2016-02-23 23:16 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-17 22:46 [PATCH] git-p4.py: Don't try to rebase on submit from bare repository Amadeusz Żołnowski
2016-02-19  9:47 ` Luke Diamand
2016-02-19 17:21   ` Junio C Hamano
2016-02-19 18:27     ` Amadeusz Żołnowski
2016-02-19 18:40       ` Eric Sunshine
2016-02-19 21:57         ` [PATCH] git-p4.py: Make submit working on " Amadeusz Żołnowski
2016-02-19 22:44           ` Junio C Hamano
2016-02-20 11:00             ` Amadeusz Żołnowski
2016-02-21  7:36               ` Junio C Hamano
2016-02-22 18:50                 ` Amadeusz Żołnowski
2016-02-23  6:59                   ` Junio C Hamano
2016-02-23 12:05                     ` Luke Diamand
2016-02-23 20:56                       ` Amadeusz Żołnowski [this message]
2016-02-28  4:26                         ` Luke Diamand
2016-02-28 20:46                           ` Amadeusz Żołnowski
2016-02-29 15:29                             ` Luke Diamand
2016-04-12 23:25                               ` Junio C Hamano
2016-04-13 20:27                                 ` Amadeusz Żołnowski
2016-04-13 21:47                                   ` Junio C Hamano
2016-06-07 20:32                                     ` Amadeusz Żołnowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=871t83cfi7.fsf@freja.aidecoe.name \
    --to=aidecoe@aidecoe.name \
    --cc=gitster@pobox.com \
    --cc=luke@diamand.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.