From: Junio C Hamano <gitster@pobox•com>
To: Steffen Prohaska <prohaska@zib•de>
Cc: git@vger•kernel.org
Subject: Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
Date: Wed, 31 Oct 2007 14:31:05 -0700 [thread overview]
Message-ID: <7vlk9jgeee.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <B16F7DA1-E3E5-47A4-AFD3-6680741F38F1@zib.de> (Steffen Prohaska's message of "Wed, 31 Oct 2007 22:09:21 +0100")
Steffen Prohaska <prohaska@zib•de> writes:
>> You forgot a lot more important part. Pushing into publishing
>> repositories. And the discussion is about git-push command.
>
> Exactly, here are two examples:
>
> If you push only to publishing repositories that are read
> only by others, you'll never encounter the problem that
> 10/10 tried to solve. The publishing repository is never
> changed by others. You are the only one who pushes to this
> repository. Therefore the remote never advances unexpectedly.
Wrong.
People can and do work from more than one private repositories
(I do). In a sense, that is sharing the repository with
oneself.
I may do an emergency patch to fix breakage on 'maint' (and
'maint' only) from a location that is not my primary development
box and push the fix out. I fully expect that the push will
push out 'maint' and expect the other branches such as 'master'
on the remote side to stay the same, as I haven't touched
'master' on that box for quite a while and it is now stale. In
that situation, I _want_ the "git push" itself to report failure
to notify me that it did not push what _I_ asked it to push out,
so that I can be reminded that I'd better do "git push $remote
maint" the next time. In the meantime, even though it reports
a failure, 'master' on the remote side is _not_ updated, so the
behaviour is still _safe_.
> Another difference is the way changes are integrated. In
> a workflow without shared repositories, only pull is used
> for integration, while push in only used for publishing the
> changes.
Wrong. push is a mirror of fetch and does not do _any_
integration. It is just a safe (because it insists on
fast-forward) propagation mechanism. Your integration still
happens with pull (actually, shared repository people seem to
prefer "fetch + rebase" over "pull" which is "fetch + merge").
> This is different if you work with a shared repository. Bob
> checks out the shared branch foo to his local branch bar and
> later he needs to push bar back to the shared branch foo. Bob
> needs to push changes from his local branch bar to the branch
> foo in the remote repository, a branch with a different name.
> This need does not emerge when working with two publishing
> repositories, as described above.
So you do "git push $remote bar:foo". If you do that regulary,
there are configuration mechanisms to help you reduce your
keyboard wear. What's the problem?
next prev parent reply other threads:[~2007-10-31 21:31 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-28 17:46 [PATCH 0/10 v3] improve refspec handling in push Steffen Prohaska
2007-10-28 17:46 ` [PATCH 01/10] push: change push to fail if short refname does not exist Steffen Prohaska
2007-10-28 17:46 ` [PATCH 02/10] push: teach push new flag --create Steffen Prohaska
2007-10-28 17:46 ` [PATCH 03/10] push: support pushing HEAD to real branch name Steffen Prohaska
2007-10-28 17:46 ` [PATCH 04/10] push: add "git push HEAD" shorthand for 'push current branch to default repo' Steffen Prohaska
2007-10-28 17:46 ` [PATCH 05/10] rename ref_matches_abbrev() to ref_abbrev_matches_full_with_fetch_rules() Steffen Prohaska
2007-10-28 17:46 ` [PATCH 06/10] add ref_abbrev_matches_full_with_rev_parse_rules() comparing abbrev with full ref name Steffen Prohaska
2007-10-28 17:46 ` [PATCH 07/10] push: use same rules as git-rev-parse to resolve refspecs Steffen Prohaska
2007-10-28 17:46 ` [PATCH 08/10] push: teach push to accept --verbose option Steffen Prohaska
2007-10-28 17:46 ` [PATCH 09/10] push: teach push to pass --verbose option to transport layer Steffen Prohaska
2007-10-28 17:46 ` [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref Steffen Prohaska
2007-10-30 8:29 ` Junio C Hamano
2007-10-30 10:15 ` Steffen Prohaska
2007-10-30 10:26 ` Andreas Ericsson
2007-10-30 10:53 ` Steffen Prohaska
2007-10-30 19:19 ` Junio C Hamano
2007-10-31 7:53 ` Steffen Prohaska
2007-10-31 8:45 ` Junio C Hamano
[not found] ` <B3C76DB8-076D-4C43-AC28-99119A05325C@z ib.de>
2007-10-31 9:14 ` Junio C Hamano
2007-10-31 10:50 ` Steffen Prohaska
2007-10-31 18:51 ` Junio C Hamano
2007-10-31 21:09 ` Steffen Prohaska
2007-10-31 21:31 ` Junio C Hamano [this message]
2007-11-01 7:03 ` Steffen Prohaska
2007-11-01 9:11 ` Andreas Ericsson
2007-11-01 16:43 ` Steffen Prohaska
2007-11-01 20:18 ` Junio C Hamano
2007-11-02 7:21 ` Steffen Prohaska
2007-11-02 7:52 ` Junio C Hamano
2007-11-02 10:03 ` Steffen Prohaska
2007-11-02 10:44 ` Junio C Hamano
2007-11-02 11:40 ` Steffen Prohaska
2007-11-02 10:03 ` Andreas Ericsson
2007-11-02 13:24 ` Tom Prince
2007-11-02 13:52 ` Andreas Ericsson
2007-11-02 14:49 ` Steffen Prohaska
2007-11-02 19:42 ` Junio C Hamano
2007-11-02 20:19 ` Junio C Hamano
2007-11-01 8:18 ` Andreas Ericsson
2007-11-01 8:36 ` Steffen Prohaska
2007-11-01 9:29 ` Andreas Ericsson
2007-11-02 8:18 ` Wincent Colaiuta
2007-11-02 12:14 ` Johannes Schindelin
2007-11-02 12:48 ` Steffen Prohaska
2007-11-02 13:11 ` Wincent Colaiuta
2007-10-30 18:00 ` Daniel Barkalow
2007-10-30 8:28 ` [PATCH 07/10] push: use same rules as git-rev-parse to resolve refspecs Junio C Hamano
2007-10-30 8:49 ` Steffen Prohaska
2007-10-30 8:28 ` [PATCH 04/10] push: add "git push HEAD" shorthand for 'push current branch to default repo' Junio C Hamano
2007-10-30 8:28 ` [PATCH 03/10] push: support pushing HEAD to real branch name Junio C Hamano
2007-10-30 8:29 ` [PATCH 01/10] push: change push to fail if short refname does not exist Junio C Hamano
2007-10-30 8:56 ` Steffen Prohaska
2007-10-30 9:22 ` Junio C Hamano
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=7vlk9jgeee.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=prohaska@zib$(echo .)de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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