From: "Martin Langhoff" <martin.langhoff@gmail.com>
To: "Junio C Hamano" <gitster@pobox.com>
Cc: "Jeff King" <peff@peff.net>, "Steffen Prohaska" <prohaska@zib.de>,
"Git Mailing List" <git@vger.kernel.org>
Subject: Re: Minor annoyance with git push
Date: Sun, 10 Feb 2008 00:50:20 +1300 [thread overview]
Message-ID: <46a038f90802090350rc4780d1ted60c03b9abf1fc0@mail.gmail.com> (raw)
In-Reply-To: <7vtzkihkx5.fsf@gitster.siamese.dyndns.org>
On Feb 9, 2008 4:24 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Is there anything wrong with "git push $there $branch_name"?
This works, but is rather verbose to type all the time.
> $ git push origin HEAD
>
> and you are done. No need to spell out the long branch name you
> are currently on.
Didn't know this was meant to work. I'll give it a go.
> I do not know if this was part of the last round of patches, but
> I suspect it is not a problem to allow
>
> $ git push HEAD
>
> if it is unambiguous. That is, "HEAD? Do we have such a remote
> nickname? No. Then can we default to 'origin' and use it as
> the ref to push? Yeah, we can, so the user meant 'git push
> origin HEAD'".
If I can say git push HEAD it will be nice.
Still, the big fat ![rejected] do seem over the top when I know it
really means "stale".
And I don't completely follow how bad the impact of
auto-fast-forwarding local tracking branches on a merge. If it's a
fast-forward, my "local state" wasn't that exciting to begin with ;-)
and revlogs can potentially rescue my olden state (but what's the use
case for the local state being interesting, anyway?). Yes - user state
is important, but something that resolves to a fast-forward means that
the user state, whatever it is, is in sync with the repo.
As per the subject, these are minor annoyances. The whole
remotes+local heads setup works like a charm ;-)
cheers,
m
next prev parent reply other threads:[~2008-02-09 11:50 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-08 4:44 Minor annoyance with git push Martin Langhoff
2008-02-08 4:50 ` Martin Langhoff
2008-02-08 7:48 ` Junio C Hamano
2008-02-09 11:22 ` Steffen Prohaska
2008-02-10 3:44 ` Junio C Hamano
2008-02-10 12:21 ` Johannes Schindelin
2008-02-08 11:52 ` Johannes Schindelin
2008-02-08 22:23 ` Martin Langhoff
2008-02-08 22:27 ` Mike Hommey
2008-02-08 5:38 ` Sean
2008-02-08 6:29 ` Steffen Prohaska
2008-02-08 11:50 ` Johannes Schindelin
2008-02-08 22:27 ` Martin Langhoff
2008-02-08 22:57 ` Johannes Schindelin
2008-02-09 2:46 ` Jeff King
2008-02-09 2:54 ` Jeff King
2008-02-09 13:04 ` Johannes Schindelin
2008-02-09 13:22 ` Jeff King
2008-02-09 11:22 ` Steffen Prohaska
2008-02-09 3:00 ` Jeff King
2008-02-09 3:24 ` Junio C Hamano
2008-02-09 3:55 ` Jeff King
2008-02-09 11:50 ` Martin Langhoff [this message]
2008-02-09 13:06 ` Johannes Schindelin
2008-02-10 2:24 ` Junio C Hamano
2008-02-10 10:13 ` Jeff King
2008-02-10 12:22 ` Johannes Schindelin
2008-02-17 1:08 ` [RFC] checkout to notice forks (Re: Minor annoyance with git push) Junio C Hamano
2008-02-17 3:31 ` Daniel Barkalow
2008-02-17 4:11 ` Junio C Hamano
2008-02-17 6:39 ` Daniel Barkalow
2008-02-17 7:37 ` Junio C Hamano
2008-02-17 17:36 ` Daniel Barkalow
2008-02-17 12:28 ` Jeff King
2008-02-20 16:01 ` Santi Béjar
2008-02-19 17:03 ` Martin Langhoff
2008-02-20 23:05 ` [PATCH] checkout: tone down the "forked status" diagnostic messages Junio C Hamano
2008-02-21 1:45 ` Jeff King
2008-02-21 3:42 ` [PATCH] checkout: updates to tracking report Junio C Hamano
2008-02-21 5:27 ` Jay Soffian
2008-02-21 17:02 ` Daniel Barkalow
2008-02-21 2:56 ` [PATCH] checkout: tone down the "forked status" diagnostic messages Jay Soffian
2008-02-09 10:53 ` Minor annoyance with git push Steffen Prohaska
2008-02-09 13:10 ` Johannes Schindelin
2008-02-10 2:07 ` Junio C Hamano
2008-02-10 2:15 ` Johannes Schindelin
2008-02-10 10:17 ` Jeff King
2008-02-10 12:20 ` Johannes Schindelin
2008-02-10 12:23 ` Jeff King
2008-02-10 13:04 ` Johannes Schindelin
2008-02-10 13:07 ` Jeff King
2008-02-20 8:23 ` Junio C Hamano
2008-02-20 13:06 ` Johannes Schindelin
2008-02-20 15:20 ` Jay Soffian
2008-02-20 15:38 ` Johannes Schindelin
2008-02-21 22:35 ` Steven Walter
2008-02-22 0:11 ` Johannes Schindelin
2008-02-20 14:03 ` Jeff King
2008-02-20 17:54 ` Junio C Hamano
2008-02-20 18:15 ` Jeff King
2008-02-20 18:17 ` Jeff King
2008-02-20 18:19 ` Junio C Hamano
2008-02-20 18:23 ` Jeff King
2008-02-10 14:03 ` Wincent Colaiuta
2008-02-10 15:02 ` Steven Walter
2008-02-10 16:29 ` Johannes Schindelin
2008-02-10 16:26 ` Johannes Schindelin
2008-02-10 18:18 ` Wincent Colaiuta
2008-02-10 22:34 ` Jeff King
2008-02-10 22:59 ` Junio C Hamano
2008-02-10 23:29 ` Jeff King
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=46a038f90802090350rc4780d1ted60c03b9abf1fc0@mail.gmail.com \
--to=martin.langhoff@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
--cc=prohaska@zib.de \
/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).