git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Brandon Williams <bmwill@google.com>
To: Jacob Keller <jacob.keller@gmail.com>
Cc: Jonathan Nieder <jrnieder@gmail.com>,
	Git mailing list <git@vger.kernel.org>
Subject: Re: [PATCH v2 2/2] push: propagate push-options with --recurse-submodules
Date: Thu, 6 Apr 2017 10:39:36 -0700	[thread overview]
Message-ID: <20170406173936.GA142670@google.com> (raw)
In-Reply-To: <CA+P7+xq58Bc2KVb2ewBPWPj8Zyf82tJWgQeq=oFvbs0ACysvLQ@mail.gmail.com>

On 04/05, Jacob Keller wrote:
> On Fri, Mar 31, 2017 at 5:19 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> > Brandon Williams wrote:
> >
> >> Teach push --recurse-submodules to propagate push-options recursively to
> >> the pushes performed in the submodules.
> >
> > Some time in the future we may want "push --recurse-submodules" to do a
> > dry run pass before doing the final push, so that if it is known that
> > some of the pushes wouldn't succeed (e.g. due to not being
> > fast-forward, or the server not being reachable, or the server not
> > supporting push options) then git could stop early instead of some
> > succeeding and some failing.
> >
> > But that's a larger and separate change from this one.  Users of push
> > --recurse-submodules today know they are effectively asking for
> > multiple pushes that are not guaranteed to succeed or fail together.
> >
> 
> If you want it to be truly atomic it will require more effort than the
> above. Suppose that you do a dry-run first, and then find out
> everything will succeed. After this, you do the real pushes. But in
> between these two commands something could have changed, and you could
> still end up with a non-atomic set of pushes.
> 
> I think that's ok and better than before, but it should be noted that
> you stll don't guarantee that all the pushes succeed or fail together.
> 
> I'm really not sure if you even can make these pushes work atomically
> considering they are going to different hosts.

Yeah, really it becomes impossible to have submodules pushed to multiple
hosts in an atomic way.  I think what Jonathan is mentioning is a way to
ensure that the options and everything are supported by the server you
are communicating with (for each submodule), though you could just run
an explicit dry-run yourself.

If you truly wanted the superproject and all submodules updated in an
atomic way you would need some other server side service (e.g. gerrit)
to ensure that it was done properly.

-- 
Brandon Williams

  reply	other threads:[~2017-04-06 17:39 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-31 23:11 [PATCH] push: propagate push-options with --recurse-submodules Brandon Williams
2017-03-31 23:20 ` Jonathan Nieder
2017-03-31 23:26   ` Brandon Williams
2017-03-31 23:56 ` [PATCH v2 0/2] propagate push-options Brandon Williams
2017-03-31 23:56   ` [PATCH v2 1/2] push: unmark a local variable as static Brandon Williams
2017-04-01  0:11     ` Jonathan Nieder
2017-04-01  0:16       ` Brandon Williams
2017-03-31 23:56   ` [PATCH v2 2/2] push: propagate push-options with --recurse-submodules Brandon Williams
2017-04-01  0:19     ` Jonathan Nieder
2017-04-06  0:17       ` Jacob Keller
2017-04-06 17:39         ` Brandon Williams [this message]
2017-04-05 17:47   ` [PATCH v3 0/5] propagating push-options, remote and refspec Brandon Williams
2017-04-05 17:47     ` [PATCH v3 1/5] push: unmark a local variable as static Brandon Williams
2017-04-05 17:47     ` [PATCH v3 2/5] push: propagate push-options with --recurse-submodules Brandon Williams
2017-04-05 17:47     ` [PATCH v3 3/5] remote: expose parse_push_refspec function Brandon Williams
2017-04-05 17:47     ` [PATCH v3 4/5] submodule--helper: add push-check subcommand Brandon Williams
2017-04-05 17:47     ` [PATCH v3 5/5] push: propagate remote and refspec with --recurse-submodules Brandon Williams
2017-04-11  7:44     ` [PATCH v3 0/5] propagating push-options, remote and refspec Junio C Hamano
2017-04-11 16:33       ` Brandon Williams

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=20170406173936.GA142670@google.com \
    --to=bmwill@google.com \
    --cc=git@vger.kernel.org \
    --cc=jacob.keller@gmail.com \
    --cc=jrnieder@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).