From: Junio C Hamano <junkio@cox.net>
To: Daniel Barkalow <barkalow@iabervon.org>
Cc: git@vger.kernel.org
Subject: Re: [RFC] Reverting "git push logic change"?
Date: Sun, 22 Jan 2006 13:31:00 -0800 [thread overview]
Message-ID: <7vu0bw9ch7.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <7vr770c8db.fsf@assigned-by-dhcp.cox.net> (Junio C. Hamano's message of "Sun, 22 Jan 2006 12:31:28 -0800")
Junio C Hamano <junkio@cox.net> writes:
> ... This is a user error but that is not their fault. It
> means that we need to document this better:
I hope something like this is clear enough?
-- >8 --
[PATCH] Recommend to remove unused `origin` in a shared repository
It is a common mistake to leave an unsed `origin` branch behind
if a shared public repository was created by first cloning from
somewhere else. Subsequent `git push` into it with the default
"push all the matching ref" would push the `origin` branch from
the developer repository uselessly.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index b8fa299..35579cc 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -1667,6 +1667,26 @@ complain, telling you that the remote `m
fast forward. You need to pull and merge those other changes
back before you push your work when it happens.
+The `git push` command without any explicit refspec parameter
+pushes the refs that exist both in the local repository and the
+remote repository. So the last `push` can be done with either
+one of these:
+------------
+$ git push origin
+$ git push repo.shared.xz:/pub/scm/project.git/
+------------
+as long as the shared repository does not have any branches
+other than `master`.
+[NOTE]
+============
+If you created your shared repository by cloning from somewhere
+else, you may have the `origin` branch. Your developers
+typically do not use that branch; remove it. Otherwise, that
+would be pushed back by the `git push origin` because your
+developers' repository would surely have `origin` branch to keep
+track of the shared repository, and would be counted as "exist
+on both ends".
+============
Advanced Shared Repository Management
-------------------------------------
next prev parent reply other threads:[~2006-01-22 21:31 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-20 22:53 "git push" logic changed? Greg KH
2006-01-21 0:03 ` Junio C Hamano
2006-01-21 0:15 ` Greg KH
2006-01-21 0:54 ` Junio C Hamano
2006-01-21 0:59 ` Junio C Hamano
2006-01-21 7:46 ` [RFC] Reverting "git push logic change"? Junio C Hamano
2006-01-22 19:09 ` Daniel Barkalow
2006-01-22 20:31 ` Junio C Hamano
2006-01-22 21:31 ` Junio C Hamano [this message]
2006-01-22 21:42 ` sean
2006-01-22 21:42 ` sean
2006-01-22 23:09 ` Junio C Hamano
2006-01-23 1:31 ` Junio C Hamano
2006-01-24 5:05 ` Greg KH
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=7vu0bw9ch7.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox.net \
--cc=barkalow@iabervon.org \
--cc=git@vger.kernel.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.