From: Ramkumar Ramachandra <artagnon@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: What should "git fetch origin +next" should do?
Date: Mon, 17 Oct 2011 21:40:56 +0530 [thread overview]
Message-ID: <CALkWK0kXyovFrJO+5AD3gOs1YuutBZouH8aESXSKA-1nX3T6rw@mail.gmail.com> (raw)
In-Reply-To: <7v7h45s8rh.fsf@alter.siamese.dyndns.org>
Hi Junio,
Junio C Hamano writes:
> I just tried to update one of them with "git pull --ff-only", and after
> seeing that the fetch phase failed with non-ff on 'next', ran
>
> $ git fetch origin +next
>
> which happily copied the tip of updated next to FETCH_HEAD and nowhere
> else. Of course, a colon-less refspec means do not store it anywhere,
> i.e. "<colon-less-refspec>" === "<colon-less refspec>:", so prefixing it
> with '+' to force would logically be a no-op. But it nevertheless was
> somewhat surprising and irritating.
Interesting: I wouldn't have expected this behavior either. I'll see
if I can add something useful to this.
> As some might know, I use the traditional non-separate-remotes layout in
> many of my working trees. I am old fashioned.
As an interesting aside, I recently stopped using the word 'origin' to
name a remote since I started using multiple remotes: your remote is
called 'junio', mine's called 'ram', Jonathan's is called 'jrn', and
so on. I personally use a variation of `git fetch junio master:master
next:next +pu:pu`. It "fails" when:
1. Some uncommitted work is left: I'm a bit messy with multiple
worktrees (git-new-workdir).
2. I'm doing some work directly on top of `master` or some other
upstream branch, and haven't forked out yet (I only fork out and name
the branch if the volume of work justifies it).
3. Sometimes `next` is non-ff, and I'm curious about what happened. I
inspect the changes before invariably using a `git reset --hard
junio/next` to throw away the useless commits.
> (2) Do notice '+' and understand that it is a request to force fetch into
> some ref locally, and from the lack of colon and RHS, assume that the
> user wants Git to infer the RHS using the configured refspec (in my
> case, "refs/heads/next:refs/heads/next" is one of the configured
> fetch refspec; "refs/heads/*:refs/remotes/origin/*" would be the one
> that would match in the separate-remotes layout). In other words,
> treat it as if the user typed "+refs/heads/next:refs/heads/next" (or
> "+refs/heads/next:refs/remotes/origin/next" in the separate-remote
> layout) from the command line.
Ugh, no. Such smartness is probably desirable at the `pull` level.
> (3) Do notice '+' is applied to 'next' but otherwise ignore the fact that
> it is a command line pathspec, which would cause us to ignore
> configured refspecs. In other words, fetch normally as if there were
> no refspec on the command line, but when updating refs/heads/next (or
> refs/remotes/origin/next in the separate-remotes layout), allow non
> fast-forward updates.
This is unnecessarily complicated and ugly imho. I think `git fetch`
is trying to be over-smart here: If I don't choose to update my local
refs by hand immediately after the fetch, I'll be surprised later.
> Perhaps we can/want to implement (1)?
Yeah, I think it's the right thing to do. For the implementation,
should we update the condition in fetch.c:451 or try to implement it
at the refspec-parsing level?
Thanks.
-- Ram
next prev parent reply other threads:[~2011-10-17 16:11 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-16 7:20 What should "git fetch origin +next" should do? Junio C Hamano
2011-10-17 14:35 ` Marc Branchaud
2011-10-17 16:15 ` Ramkumar Ramachandra
2011-10-17 17:09 ` Junio C Hamano
2011-10-17 16:10 ` Ramkumar Ramachandra [this message]
2011-10-17 17:10 ` Jeff King
2011-10-17 18:34 ` Junio C Hamano
2011-10-17 22:02 ` Marc Branchaud
2011-10-19 4:31 ` Junio C Hamano
2011-10-19 13:45 ` Marc Branchaud
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALkWK0kXyovFrJO+5AD3gOs1YuutBZouH8aESXSKA-1nX3T6rw@mail.gmail.com \
--to=artagnon@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).