From: Zing <zing@fastmail.fm>
To: git@vger.kernel.org
Subject: Re: [PATCH] Documentation: do not advertise --all in git-pull(1)
Date: Thu, 7 Jan 2010 18:25:15 +0000 (UTC) [thread overview]
Message-ID: <hi58ub$c0l$1@ger.gmane.org> (raw)
In-Reply-To: a6112d286c5deeb4cc2ccfb1a90ff384440c1341.1262880109.git.trast@student.ethz.ch
On Thu, 07 Jan 2010 17:09:33 +0100, Thomas Rast wrote:
> This one fixes the documentation problem, but I think there's a deeper
> misunderstanding. What did you hope to do with 'git pull --all'? I
> suspect most people on this list would take it to mean "fetch all
> branches from all remotes, and merge them into HEAD". I cannot imagine
> a use-case where that would make any sense. (And it wouldn't work,
> because the current implementation of 'git fetch --all' leaves only the
> last remote's branches in FETCH_HEAD.)
>
> From earlier discussions on the non-intuitiveness of git-pull, I kind of
> suspect you wanted to fetch all remotes, and then "update" all local
> branches that track some remote with their corresponding remote-tracking
> branches. In which case the question is: why do you use local branches
> if you have them "blindly" track the upstream?
Let me just state first that I'm a casual git user and I would have
missed those earlier discussions.... sorry if this old news:
I do basically just use git to just "blindly" track upstream repos/
projects using local branches. I realize this is "dumb" in a sense,
because it's basically just a copy of the remote branch that needs to be
fast-forwarded all the time; but it's just a handy lazy way for me to
remember which remote branches I want to "watch" with just a 'git branch'
command, plus it's easier and shorter to just type the local branch names
I specify than to type for example "origin/something" or "myotherremote/
something".
What I thought 'git pull --all' would do is just pass down the --all flag
to fetch and that's it:
1. do a 'git fetch --all'
2. then do a 'git merge <tracked remote branch of the current local
branch>', basically, in my case, just fast-forwarding my current local
branch if need be.
I didn't think that 'git pull --all' would "update" all local branches
that needed to be fast-forwarded. It would be too, how to say, "messy"
in the output, and not really what 'git pull' alone was doing before. I
did think it could be a possibility, so, really, I was trying it out to
see what would happen.
The other possibility you mentioned about fetching all branches and then
merging all of them to HEAD, didn't occur to me at all. I can see now
how it could make more intuitive sense from the perspective of a more
"experienced" git person. Personally, I don't think I'd ever need
something like that. HTH.
prev parent reply other threads:[~2010-01-07 18:26 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <hi2mu8ob@ger.gmane.org>
2010-01-07 16:09 ` [PATCH] Documentation: do not advertise --all in git-pull(1) Thomas Rast
2010-01-07 18:25 ` Zing [this message]
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='hi58ub$c0l$1@ger.gmane.org' \
--to=zing@fastmail.fm \
--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 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).