From: Junio C Hamano <hidden> Date: 2016-08-11 20:42:49
Nicolas Pitre [off-list ref] writes:
"You pull the remote changes with 'git-pull upstream,, then you can
merge them in your current branch with 'git-merge upstream'."
Isn't it much simpler to understand (and to teach) that way?
If it were "you download the remote changes with 'git download
upstream' and then merge with 'git merge'", then perhaps, but if
you used the word "pull" or "fetch", I do not think so.
I would be all for changing the semantics of "pull" from one
thing to another, if the new semantics were (1) what everybody
welcomed, (2) what "pull" traditionally meant everywhere else.
In that case, we have been misusing it to be confusing to
outsiders and I agree it makes a lot of sense to remove the
source of confusion. But I do not think CVS nor SVN ever used
the term, and I was told that BK was what introduced the term,
and the word meant something different from what you are
proposing.
You have to admit both pull and fetch have been contaminated
with loaded meanings from different backgrounds. I was talking
about killing the source of confusion in the longer term by
removing fetch/pull/push, so we are still on the same page.
That's where my "you download from the upstream and merge" comes
from.
From: Michael K. Edwards <hidden> Date: 2016-08-11 19:19:02
On 11/16/06, Carl Worth [off-list ref] wrote:
First, the pull may just fast-forward in which case there's no message
at all. And we've been through that topic enough recently that we all
know that no important information is lost by not doing any separate
recording in that case.
So you can't turn around and argue that the remote URL information is
suddenly important when it just so happens that it's not a fast
forward.
When it's a fast forward, the puller hasn't had to make any judgment
calls, so there's no editorial history to record. When it's not, but
the puller chooses to retain the result on a persistent branch, that
_is_ an editorial decision (even if the result of the auto-merge is
clean); I like having that in the history.
quoted
And in a truly distributed situation, "pull" is strictly more powerful
than a separate "fetch" + separate "merge".
I don't buy it. In my usage, I have several different remote
repositories I'm interested in tracking, each with any number of
branches. What I really want is an easy command that fetches all of
those branches, (even new ones that I've never heard about---but never
any of their "tracking branches" that wouldn't be of interest to
me). And I want to do that once, to get the online-access-required
part over with and get all the data into my local repository where I
can start working with it.
What do you want all of those branches for? They haven't been
published to you (that's a human interaction that doesn't go through
git), so for all you know they're just upstream experiments, and doing
things with them is probably shooting yourself in the foot.
I do agree that a robust form of "for b in .git/remotes/*; do git
fetch `basename $b`; done" would be a nice bit of porcelain. The
entries in .git/remotes would probably need to grow a "Fetch-options:"
field so that you could choose whether or not to follow tags, etc.
Patch to follow.
Cheers,
From: Nicolas Pitre <hidden> Date: 2016-08-11 19:19:41
On Wed, 15 Nov 2006, Petr Baudis wrote:
On Wed, Nov 15, 2006 at 03:10:16AM CET, Junio C Hamano wrote:
quoted
You have to admit both pull and fetch have been contaminated
with loaded meanings from different backgrounds. I was talking
about killing the source of confusion in the longer term by
removing fetch/pull/push, so we are still on the same page.
How was/is fetch contaminated?
I think "fetch" is sane. Its only problem is a missing symetrical
counterpart verb, like "get" and "put".
From: Carl Worth <hidden> Date: 2016-08-11 19:20:19
On Thu, 16 Nov 2006 09:57:00 -0800, "Michael K. Edwards" wrote:
What do you want all of those branches for? They haven't been
published to you (that's a human interaction that doesn't go through
git), so for all you know they're just upstream experiments, and doing
things with them is probably shooting yourself in the foot.
The same "what do you want them all for" question could be asked of
git-clone which also fetches all available branches. I really just
want to be able to easily watch what's going on in multiple
repositories.
I want to be able to just say "git update" (or whatever) and then be
able to list and browse and explore the stuff locally.
Yes, there's still outside communication that's necessary, but with
the ability to easily track all the remote branches that communication
can be even less formal if I can easily browse and explore things
locally. For example, I might not even know the name of the branch:
Me: Have you pushed a branch for your new work on the frob-widget?
Friend: Yes
And then I can "get fetch" and see "cool-new-frob" come in without
having to be told that name. Or I could have even just fetched
without the specific communication if I was already expecting it for
some reason.
-Carl
On Wed, 15 Nov 2006 11:18:36 -0800, Linus Torvalds wrote:
On Wed, 15 Nov 2006, Andy Parkins wrote:
quoted
On the one hand you're arguing that git syntax is easy to learn, and on the
other that no one will be able to learn a new syntax just as easily.
I'm saying that people who are new to git will _have_ to learn new
concepts ANYWAY.
I don't think the naming is the hard part.
It isn't - the unexpectedness of what happens is.
I've started by teaching how to do stuff locally, then "pushing" it out to
others (me). All the while being able to point out how this is either all
local, or sends stuff (without any local modifications) to others.
Come up to 'pull' and ere you have to point out that not only will you get
the remote changes but they are also merged into your repository. On the
wrong branch?
Too bad.
The problem with git-pull behaving illogically drove me to look at cogito
(an aside, perhaps cg-throw should be the corrollary to cg-fetch?)
instead. Alas it has problems with a cogito branch not being something you
can mentally map back to a git branch.
But I bet people don't teach it that way. They _start_ by teaching "pull".
Right?
From: Carl Worth <hidden> Date: 2016-08-11 19:23:10
On Fri, 17 Nov 2006 11:26:05 -0500, Shawn Pearce wrote:
Linus Torvalds [off-list ref] wrote:
quoted
- "ORIG_HEAD" is very useful indeed, and it's the head _before_ a merge
...
Although if you have reflog enabled on your current branch there
is a 1 character shorter syntax:
gitk HEAD@{1}..
Yes, this was my exact thought when reading what Linus
wrote. ORIG_HEAD might be fine and all, but it pales in functionality
compared to what reflog provides.
I would very much like to see reflog getting first-class citizen
support in git:
1. Be on by default
2. Get documented in all the right places, (much better than adding
documentation for ORIG_HEAD in my opinion)
3. Tighter integration with branch manipulations. Do we already delete
reflog when deleting a branch? We don't have a branch rename
operation, but if we get one, renaming the reflog should go
hand-in-hand, etc.
-Carl
I think "fetch" is sane. Its only problem is a missing symetrical
counterpart verb, like "get" and "put".
If you're a dog owner, the obvious counterpart for "fetch" is "throw" ;)
I think "get" and "put" would be bad, just because of confusion with
"sccs get" (ie it has that "get this file" connotations).
Maybe "fetch" and "push" aren't totally diametrically opposite, but
really, I don't think they are that hard to understand either. We do have
the BK legacy of "pull" implying a merge, and that's fairly fundamental.
It's also true that in a lot of usage schenarios, what people actually
_use_ is "pull" and "push", and no, they aren't mirror images (since push
will _not_ do the merge), but at the same time, from a _usage_ standpoint
they really _are_ each others opposites.
You "pull" to get other peoples data into your branch (and once you've
internalized local branches and the merge thing, you know what this
means), and you "push" to push your changes out. It really _is_ the usage
schenario, and using "opposite" words really _does_ make sense.
It's true that _technically_ "fetch" is the opposite of "push", but at the
same time, that really is about technology, not about usage models. You
normally wouldn't do a "git fetch + git push" pair. You _can_ do so, but
it's not the natural way to work - unless you're just doing a mirror
service.
From: Carl Worth <hidden> Date: 2016-08-11 19:24:19
On Thu, 16 Nov 2006 08:30:55 -0800 (PST), Linus Torvalds wrote:
The form I use is actually a lot simpler (conceptually) than the "short"
form.
When you do
git pull <reponame> <branchname>
Yes, that's what the user almost always wants. The UI problem here is
that the conceptually simpler form is syntactically longer, (which
means users aren't likely to find it).
So if we can just get <reponame> and <branchname> to default
correctly, (based on the current branch name, and clone/fetch/pull
history), then the conceptually simple form ends up syntactically
simple as "git pull".
And I definitely don't have any problem with that. I'd love to be able
to teach that kind of simple thing to new users.
driver tree, and because I'm always on that branch, what I do is
git pull origin modesetting
...
Well, as mentioned, I think even for non-developers, doing pulls with
explicit branchnames is actually perfectly sane.
The behavior is sane, but having to always type the branch name
specifically because it never changes... that's a user-interface bug.
This is a good example of the kind of thing I wanted to hit when
starting this thread. I don't think there are any big conceptual
changes needed in git to make it easier for new users. But there are
little things that are problems that really should be fixed. Wouldn't
it be great to have the following exchange:
User: How do I track on-going development in a branch?
Master: Use "git pull"
Rather than:
User: How do I track on-going development in a branch?
Master Use "git pull origin <name-of-branch-you-are-already-on>"
?
-Carl
From: Petr Baudis <hidden> Date: 2016-08-11 19:25:18
On Fri, Nov 17, 2006 at 02:22:35AM CET, Johannes Schindelin wrote:
On Thu, 16 Nov 2006, Linus Torvalds wrote:
quoted
For example, if you used one of the old-fashioned commit walkers, maybe we
got the initial commit, but we may not have gotten the whole _chain_. See?
Huh? I am quite certain that FETCH_HEAD is not updated in that case. If it
is, that's a bug.
It may be updated and then things may break _afterwards_. git-prune will
happily blow anything referenced by FETCH_HEAD, it's not considered by
the fsck-objects reachability analysis.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
On Thu, 16 Nov 2006 08:30:55 -0800 (PST), Linus Torvalds wrote:
quoted
The form I use is actually a lot simpler (conceptually) than the "short"
form.
When you do
git pull <reponame> <branchname>
Yes, that's what the user almost always wants. The UI problem here is
that the conceptually simpler form is syntactically longer, (which
means users aren't likely to find it).
Yeah.
And this is something I absolutely agree with. Our default branches for
"pull" are horrible. You can "fix" it, but you can only fix it by adding
_explicit_ branches to your .git/config file by hand, so I don't think
that's actually a real fix at all. We should just fix the default (where
even a "I don't know what branch you want" _error_ would be preferable
over the current situation).
Along with the "git checkout <tag>" thing, I think these two things are
definitely worth just fixing.
The behavior is sane, but having to always type the branch name
specifically because it never changes... that's a user-interface bug.
Yeah. Each branch should
(a) have a "default source" initialized on the initial "clone"
(b) have a way to set the source afterwards
(c) error out if you do just a "git pull" or "git pull remotename" if
there is no default branch for the current local branch for that
remote.
We actually have (b) in a weak form right now ("weak" because it requires
you to manually edit the config file: we've got the mechanism, but not a
nice UI for it), but (a) and (c) are just broken.
And yeah, we should allow pulling into a branch that hasn't been
initialized.
From: Josef Weidendorfer <hidden> Date: 2016-08-11 19:27:01
On Wednesday 15 November 2006 21:35, Petr Baudis wrote:
On Wed, Nov 15, 2006 at 09:31:13PM CET, Josef Weidendorfer wrote:
quoted
Often, I find myself doing "git branch" just to make sure that I am on
"master", so that a following pull does not do a bogus merge.
Can we please disable this behavior, e.g. by allowing a fake first
Pull line like "Pull: (not-for-merge)" to prohibit any merge?
Wait, if you don't want pull to merge, why do you pull and not fetch?
I am not really opposed to pull doing a merge. It only should work in
a useful way: ie. only do the merge of updated origin branch when
current branch is master (given "Pull: master:origin").
I want "git pull" being harmless if I find myself accidently on a
branch != master. I always can do "git checkout master; git pull . origin"
afterwards.
For this to work, I currently need to specify a "branch.<name>.merge"
config for _every_ branch I have, as otherwise I get this bogus pull
merge behavior. This is not needed if there was a way to configure no
merge at all as default pull behavior.
I just noted that allowing such a config option would be kind of a
working compromise for all the people which want
pull to be the opposite of push.
From: Nicolas Pitre <hidden> Date: 2016-08-11 19:28:09
On Wed, 15 Nov 2006, Linus Torvalds wrote:
I'm saying that even if you _never_ end up using "git fetch" ever again
(because in practice you always want to do a "fetch + merge == pull"),
people who teach others the concepts and usage of git should probably
start by talking about "git fetch".
Then, when the user says (and he obviously will say this) "but I don't
want to just fetch the other persons work into some local branch, I want
to actually get it into _my_ branch", you say "Ahhah!" and talk about how
"pull" is a shorthand for first fetching and then merging the result into
the current branch.
Actually I believe it would make things even clearer if "merge" was
taught at that point. Only when the user is comfortable with the
separate notions of fetching and merging might the pull shorthand
possibly be mentioned.
From: Nicolas Pitre <hidden> Date: 2016-08-11 19:32:34
On Wed, 15 Nov 2006, Linus Torvalds wrote:
On Wed, 15 Nov 2006, Shawn Pearce wrote:
quoted
I've taught the same fetch first, then merge strategy. Nobody I
know in meat-space pulls from a remote URL and merges in one shot;
Actually, with different people involved it's _much_ better to do it in
one shot.
Why? Because doing a separate "fetch to local space" + "merge from local
space" actually loses the information on what you are merging.
It's a lot more useful to have a merge message like
Merge branch 'for-linus' of git://one.firstfloor.org/home/andi/git/linux-2.6
than one like
Merge branch 'for-linus'
That is an implementation detail that should be easily overcome once the
notion of tracking branch with URL attribute is implemented. Then it
will be really easy to notice whether the branch argument is a local
branch or a tracking branch with remote reference.
- git itself has now done it that way for the last 18 months, and the
fact is, the people _complaining_ are a small subset of the people who
actually use git on a daily basis and don't complain.
that's not a good argument; the set of git users is a small subset of those
that looked at git, and dismissed it because they couldn't wrap their heads
around it.
And I've said this again, and I'll say it once more: that has basically
_nothing_ to do with whether you spell "pull" as "pull" or "merge".
The reason people have trouble wrapping their heads around git is because
they have been braindamaged by CVS and SVN, and just don't understand the
fairly fundamental new concepts and workflow.
> I claim that those "annoying little issues" are totally made up by
> people
> who had trouble wrapping their minds about git, and then make up
> reasons
> that have nothing to do with reality for why that might be so.
Let me put this more personally: I continue to be bitten by stupid
naming issues, and the myriad of little mostly non-orthogonal commands.
My head is doing just fine otherwise, and has no problems wrapping it
around the core of GIT. I've also used Darcs for almost a year. Darcs,
which is much less overwhelming.
This is not about CVS or SVN, so don't put them up as a strawman.
If you want to argue that my brain is warped, use other distributed VCs
as an example.
The following
mkdir x y
cd x
hg init
echo hoi > bla
hg add
hg commit -m 'yes, I am also too stupid to refuse explicit empty
commit messages'
cd ../y
hg init
hg pull ../x
pretty much works the same in Darcs, bzr and mercurial.
With GIT, this is what happens
[hanwen@haring y]$ git pull ../x
fatal: Needed a single revision
Pulling into a black hole?
[hanwen@haring y]$ git fetch ../x
warning: no common commits
remote: Generating pack...
Done counting 3 objects.
Deltifying 3 objects.
100% (3/3) done
Total 3, wremote: ritten 3 (delta 0), reused 0 (delta 0)
Unpacking 3 objects
100% (3/3) done
[hanwen@haring y]$ git checkout
fatal: ambiguous argument 'HEAD': unknown revision or path not in the
working tree.
Use '--' to separate paths from revisions
fatal: Not a valid object name HEAD
[hanwen@haring y]$ git branch master
fatal: Needed a single revision
at this point, I resort to adding a bogus commit and/or editing
.git/HEAD by hand. I'm sure there is a saner way of doing it, but I
still haven't found out what it is.
This might not be typical GIT use, but it does show the typical GIT user
experience, at least mine.
If you want to have another example of how not to design a
user-interface, try the above on Monotone.
That's totally different from then arguing about stupid naming issues.
Peopel seem to believe that changign a few names or doing other totally
_minimal_ UI changes would somehow magically make things understandable. I
claim that isn't so at all. The fact is, git is different from CVS and
SVN, and git _has_ to be different from CVS and SVN. It has to be
different because the whole model of CVS and SVN is simpyl fundamentally
BROKEN.
quoted
It's worth trying to get those on board by fixing the annoying
little issues that have popped up in this thread.
Let's face it, you could just alias "merge" to "pull", and it wouldn't
really change ANYTHING.
I don't want ANYTHING to really change, I just want a sane interface to it.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
From: Nicolas Pitre <hidden> Date: 2016-08-11 19:33:22
On Wed, 15 Nov 2006, Linus Torvalds wrote:
On Tue, 14 Nov 2006, Nicolas Pitre wrote:
quoted
But the fact is that HG (which has a growing crowd of happy campers,
maybe even larger than the BK crowd now) did work with and got used to a
sensible definition of what a "pull" is.
Guys, before you start thinking this way, the fact is, there's a lot of
happy git users.
So the reason for using "git pull" is
- bk did it that way, and like it or not, bk was the first usable
distributed system. hg is totally uninteresting.
- git itself has now done it that way for the last 18 months, and the
fact is, the people _complaining_ are a small subset of the people who
actually use git on a daily basis and don't complain.
Those arguments are somewhat flawed. If we stick to "BK did it that way
and it was first", then following that logic we would also carry a lot
of CVS baggage because "CVS did it that way, and it was the most
successful of its kind". Still, we decided not to follow CVS nor BK in
many ways already.
As for the fraction of people complaining being a small fraction of
current GIT users: that is easily explainable by the fact that most
people who would have grown the complainers group are simply not GIT
users anymore since they were turned away by GIT's current user
interface issues. The only complainers remaining are those who see
value in the GIT technology but who would like to bring more
intuitiveness to the GIT interface instead of going for the alternative
technology. And those kind of people are always few.
So don't fall for the classic "second system syndrome". The classic reason
for getting the second system wrong is because you focus on the issues
people complain about, and not on the issues that work well (because the
issues that work fine are obviously not getting a lot of attention).
The counter part of that is the possibility to fall for the "ivory tower
syndrome" where seasoned GIT users feel they are well satisfied with
what is currently available and unwilling to consider changes that would
reduce the barrier to entry for new users... simply because they are so
used to the way things work that they can't see why others have problems
with it.
If you think "pull" is confusing, I can guarantee you that _changing_ the
name is a hell of a lot more confusing.
Agreed. This is why the current discussion led to a proposition that
allows for "pull" to remain as is but to have a "get" version that would
be the alternate (saner) version.
In fact, I think a lot of the
confusion comes from cogito, not from git - the fact that cogito used
different names and different syntax was a mistake, I think.
And that '#' for branch naming in particular was (and is) total
braindamage. The native git branch naming convention is just fundamentally
much better, and allows you to very naturally fetch multiple branches at
once, in a way that cogito's syntax does not.
So when I see suggestions of using that brain-damaged cogito syntax as an
"improvement", I know for a fact that somebody hasn't thought things
through, and only thinks it's a better syntax beause of totally bogus
reasons.
Do you have comments on my proposed syntax (that would be implemented
with a git-get command) which I think doesn't really look like cogito?
I do agree that we probably could/should re-use the "git merge" name. The
current "git merge" is an esoteric internal routine, and I doubt a lot of
people use it as-is. I don't think it would be a mistake to make "git
merge" basically be an alias for "git pull", for example, and I doubt many
people would really even notice.
Agreed.
But the fact is, git isn't really that hard to work out, and the commands
aren't that complicated.
I agree with you in general, except for the "pull" behavior which is
really really odd. Maybe it made sense in the BK context, maybe it is
fine _once_ you get used to it, but otherwise it is really overloaded.
But trying to rename "pull" (or the "git" name itself) is just going to
cause more confusion than you fix.
But I bet people don't teach it that way. They _start_ by teaching "pull".
Right?
"git fetch" is certainly the right thing for the platform integration
role
I'm saying that even if you _never_ end up using "git fetch" ever again
(because in practice you always want to do a "fetch + merge == pull"),
people who teach others the concepts and usage of git should probably
start by talking about "git fetch".
Then, when the user says (and he obviously will say this) "but I don't
want to just fetch the other persons work into some local branch, I want
to actually get it into _my_ branch", you say "Ahhah!" and talk about how
"pull" is a shorthand for first fetching and then merging the result into
the current branch.
See? Once you explain "fetch" to somebody, I can pretty much guarantee
that they'll explain "pull" to themselves without you having to even work
at it. And then they'll probably happily use "pull" ever after, and never
worry about fetch, but now they'll understand the _concepts_.
It's only if you start the other way around that "pull" vs "fetch" vs
"push" become confusing. If you _start_ by explaining branches (and you
might use "gitk --all" on a small project as a visualization tool),
suddenly the concepts aren't all that complicated.
Sure, then you have to remember two words ("pull" vs "fetch"), but I'm
pretty sure that the thing that makes people confused is not the words
themselves, but their lack of understanding of the concepts behind them.
Why? We _do_ have the temporary branch. It's called FETCH_HEAD.
_Also_, git-pull not storing the fetched branches at least temporarily
often annoyed me: the pull did not work, and the SHA1 was so far away I
could not even scroll to it.
Again, why didn't you use FETCH_HEAD?
If the user doesn't give us a head to write to, we clearly MUST NOT write
to any long-term branch. That would be a _horrible_ mistake.
So all your complaints seem totally misplaced. The UI is both usable and
practical, and your complaint that git pull doesn't store the fetched
branches is just NOT TRUE.
And your "solution" is obviously totally unusable. git ABSOLUTELY MUST NOT
overwrite any existing branches unless explicitly told to do so by the
user.
So I really don't see your point.
A lot of the complaints seem to not be about the interfaces, but about
people not _understanding_ and knowing what the interfaces do. If you were
confused about something (like not realizing that FETCH_HEAD is there and
very much usable), how about sending in a patch to make FETCH_HEAD use
clearer in whatever docs you looked at and didn't find it mentioned in.
Now, there is no question that some of the interfaces can get a bit
"interesting" to use. For example, if you really don't want to re-fetch
for some reason, FETCH_HEAD actually does contain enough information that
you should be able to just re-do a failed merge, for example, including
the message generation. But at that point it really _does_ get a bit
complicated, and you end up doing something like
git merge "$(git fmt-merge-msg < .git/FETCH_HEAD)" HEAD FETCH_HEAD
which should _work_, but I'm not going to claim that it's all that easy to
understand.
(That said, read that one-liner a few times, and suddenly it doesn't seem
_that_ complicated any more, now does it? You can probably even guess what
it's really going to do, even if you don't know git all that well. It's
not unreadable line noise, is it?)
Of course, if I had a merge that failed (the most common reason being that
I had some uncommitted patch in a file that wanted to be updated by the
merge), I'd never actually do the above one-liner. I'd just re-do the
pull. But if networking was _really_ slow, and I _really_ cared, maybe I'd
do the above.
(And no, I didn't actually test the above one-liner. Maybe it doesn't work
for some reason. Somebody should check, just for fun).
From: Carl Worth <hidden> Date: 2016-08-11 19:35:24
On Thu, 16 Nov 2006 16:49:29 -0800 (PST), Linus Torvalds wrote:
So in many ways, HEAD, FETCH_HEAD, MERGE_HEAD and ORIG_HEAD are more
fundamental than any long-term branch has ever been, and maybe they should
be taught first as such.
Older in git's history as it developed is not a good match for more
fundamental in the concepts that git makes available today.
quoted
quoted
Again, why didn't you use FETCH_HEAD?
Because I am a Jar-HEAD?
Well, we clearly should document them better. Anybody?
I for one am totally unsatisfied with this approach.
Here's an operations I'd like to be able to do:
Given a (URL, branch) pair I'd like I'd like to be able to
investigate that code, (say with the fancy new "read-only
branch" concept we've been talking about).
What are my options for this operation? What might a new user's
reaction to them be?
a) git fetch URL branch
git checkout FETCH_HEAD
This is really ugly. A name like "FETCH_HEAD" is something a user
should really never have to type. It's hideously hard to type and
has no natural discoverability. Yuck, yuck, yuck.
b) vi .git/remotes/something
git fetch something
git checkout branch
Also yuck. I hope it's obvious that having to edit a configuration
for this simple operation is a non-starter.
c) git fetch URL branch:local-branch
git checkout local-branch
We're getting close to the desired functionality now, but the UI
makes users cringe? "What's that : for?" Why do I need another
name?" etc. Linus, you yourself said this is a form that users
should generally avoid.
d) git fetch URL branch:branch
git checkout branch
One step closer. But there's still that goofy extra ':' and a
doubled name in the first command. "Why is that there? Git sure is
weird...".
What I think this operation should look like is:
git fetch URL branch
git checkout branch
And the fetch should just complain if there's a name clash. Or better,
the fetch should tuck the fetched branch into its own URL-specific
namespace and then the checkout command can kindly prompt if there is
any ambiguity:
Which "branch" do you want?
local/branch
remote-url/branch
or whatever.
See? That's what reasonable UI should look like.
Please feel free to keep using vestiges like FETCH_HEAD as much as you
like, but please don't recommend documenting them better as a solution
for UI warts in git. (If you would only look at these warts closer,
you'd see they have some lovely locks of hair on them.)
-Carl
From: Petr Baudis <hidden> Date: 2016-08-11 19:36:06
On Wed, Nov 15, 2006 at 03:10:16AM CET, Junio C Hamano wrote:
You have to admit both pull and fetch have been contaminated
with loaded meanings from different backgrounds. I was talking
about killing the source of confusion in the longer term by
removing fetch/pull/push, so we are still on the same page.
How was/is fetch contaminated?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
git merge "$(git fmt-merge-msg < .git/FETCH_HEAD)" HEAD FETCH_HEAD
Btw, I'd like to claim that this is a _great_ user interface.
Yeah, it's different from other SCM's. I don't think you'd really want to
script a merge like this in CVS, especially not using standard UNIX
pipelines etc. But it's an example of how a lot of git operations - even
the "high level ones" are pretty scriptable, using very basic and very
simple standard UNIX shell scripting.
So even though I'd not actually _do_ the above one-liner, I think it's a
great example of how git really works, and how scriptable it can be,
without a lot of huge problems.
So considering that "FETCH_HEAD" works pretty much everywhere, and that
you can also use the totally non-scripting approach of doing "standard"
SCM things like
git diff ..FETCH_HEAD
or
gitk HEAD...FETCH_HEAD
to look at what got fetched (and in the latter case look at both the
current HEAD _and_ FETCH_HEAD, and what was in one but not the other), I
really think it's unfair to say that "git fetch" does not have a nice UI.
It's just that "git fetch" can be used two totally different ways:
- "git fetch" to get something temporary: use FETCH_HEAD, and do _not_
specify a destination branch
- "git fetch" as a way to update the branches you already have, by either
using explicit branch specifiers (which would be unusual, but works),
or by just having the branch relationships listed in your .git/remotes/
file or .git/config file.
both are actually very natural things to do.
What is probably _not_ that natural is to do the explicit branch
specifier, ie
git fetch somerepo remotebranch:localbranch
which obviously works, but you wouldn't want to actually do this very
often. Either you do something once (and use FETCH_HEAD, which is actually
nicer than a real branch in some respects: it also tells you were you
fetched _from_, and it can contain data on merging from _multiple_
branches), or you set up a "real translation" in your configuration files.
So I would say that the natural thing to do is:
- "git pull somerepo"
This will _also_ fetch all the branches you've said you want to track,
of course.
- "git fetch somerepo somebranch"
Look at FETCH_HEAD, and be happy
- "git fetch somerepo"
This is kind of strange, but it can be useful if you are basically just
mirroring another repo, and want to fetch all the branches you've said
you want to track, but don't actually want to check them out.
while the "complicated" scenario like the following is something you
should generally _avoid_, because it's just confusing and complex:
- "git fetch somerepo branch1:mybranch1 branch2:mybranch2"
This works, and I'm sure it's useful, and I've even used it (usually
with just one branch, though), but let's face it - it's too damn
complicated to be anything you want to do _normally_.
So git is definitely powerful, but I think some people have looked at the
_complicated_ cases more than the simple cases (ie maybe people have
looked too much at that last case, not realizing that there really isn't
much reason to use it - and FETCH_HEAD is one big reason why you seldom
need the complicated format).
From: Andreas Ericsson <hidden> Date: 2016-08-11 19:36:59
Theodore Tso wrote:
On Wed, Nov 15, 2006 at 12:40:43PM -0800, Linus Torvalds wrote:
quoted
And yes, this is why you should NOT try to use the same naming as "hg",
for example. Last I saw, hg still didn't even have local branches, To
mercurial, repository == branch, and that's it. It was what I came from
too, and I used to argue for using git that way too. I've since seen the
error of my ways, and git is simply BETTER.
Actually, that's not true. Mercurial has local branches, just as git
does. Some people choose not to *use* this particular feature, and
use the BK style repository == branch, but that's mainly because it's
conceptually easy for them, and a number of BK refugees are very
happily using Hg.
It's probably because of the BK refugee population that after you do
an hg pull, it will warn you that you need to do an "hg update" in
order to merge the working directory up to the latest version that was
just pulled --- and this change was made precisely because Hg supports
local branches, and merging with the current branch isn't always the
right thing, unlike with BK.
quoted
And the concept of local branches is exactly _why_ you have to have
separate "fetch" and "pull", but why you do _not_ need a separate "merge"
(because "pull ." does it for you).
It's just that the semantics are different, and many developers have
to use multiple DSCM's, depending on what project they happen to be
developing on. So the reality is that there are people who have to
use bzr, git, and hg, all at the same time. And while eventually
newbies will figure out and remember that "git pull ." == "merge", the
naming is simply confusing, that's all. (What does "pull" have to do
with "merge"? It's not at all obvious.)
For somoene who uses git full-time, and to the exclusion of all other
systems, I'm sure it's not a problem at all.
It seems we should, cheaply, be able to avoid a large part of the
confusion by
* Mentioning git-fetch before git-pull in all documentation newborn
gitizens are likely to come across. Most git-users aren't Linus, and for
every successful project the maintainers are outnumbered 100 to 1 by the
contributors. Those projects successful *because* maintainers are
heavily outnumbered so we should make it easier for contributors by
teaching them the right things from the start and possibly have a
separate man-page for maintainer (git-{maintainer,developer} man-pages,
anyone?).
* Creating "git update" which might possibly be an internal alias to
"git pull", except that it should read .git/remotes/* by default unless
a specific remotes-file is specified.
* Renaming git-merge to git-merge-driver
* Implementing a git-merge that actually does what its name implies,
possibly by making it an internal alias to pull, but with these differences:
- It always merges into your current branch.
- It understands "git merge branch" as well as "git merge . branch".
This is just the very low-hanging fruit. If we take these steps and let
things cool down a bit, it would probably be proper to take a fresh look
at this in a couple of months.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
(And the real reason for that is simple: "git pull" simply wants to have
something to _start_ with. It's not hugely fundamental, it's just how it
was written).
Here's a very lightly tested patch that allows you to use "git pull" to
populate an empty repository.
I'm not at all sure this is necessarily the nicest way to do it, but it's
fairly straightforward.
Junio, what do you think?
Linus
---
@@ -44,10 +44,10 @@ doshiftdone-orig_head=$(git-rev-parse--verifyHEAD)||die"Pulling into a black hole?"+orig_head=$(git-rev-parse--verifyHEAD2>/dev/null) git-fetch--update-head-ok--reflog-action=pull"$@"||exit1-curr_head=$(git-rev-parse--verifyHEAD)+curr_head=$(git-rev-parse--verifyHEAD2>/dev/null)iftest"$curr_head"!="$orig_head"then# The fetch involved updating the current branch.
@@ -80,6 +80,11 @@ case "$merge_head" inexit0;; ?*' '?*)+iftest-z"$orig_head"+then+echo>&2"Cannot merge multiple branches into empty head"+exit1+fivar=`git-repo-config--getpull.octopus`iftest-n"$var"then
@@ -95,6 +100,12 @@ case "$merge_head" in;;esac+iftest-z"$orig_head"+then+git-update-ref-m"initial pull"HEAD$merge_head""||exit1+exit+fi+case"$strategy_args"in'')
From: Johannes Schindelin <hidden> Date: 2016-08-11 19:37:35
Hi,
On Fri, 17 Nov 2006, Petr Baudis wrote:
On Fri, Nov 17, 2006 at 02:22:35AM CET, Johannes Schindelin wrote:
quoted
On Thu, 16 Nov 2006, Linus Torvalds wrote:
quoted
For example, if you used one of the old-fashioned commit walkers, maybe we
got the initial commit, but we may not have gotten the whole _chain_. See?
Huh? I am quite certain that FETCH_HEAD is not updated in that case. If it
is, that's a bug.
It may be updated and then things may break _afterwards_. git-prune will
happily blow anything referenced by FETCH_HEAD, it's not considered by
the fsck-objects reachability analysis.
This actually underlines my point: FETCH_HEAD is no _real_ branch, not
even a temporary one. If it was, git-prune would not lose the related
objects.
Ciao,
Dscho
This is not about CVS or SVN, so don't put them up as a strawman.
If you want to argue that my brain is warped, use other distributed VCs as an
example.
Your example has nothing at all to do with "pull" vs "fetch", though.
Your example is about something totally _different_, namely that under
git, "git init-db" is _only_ for creating a _new_ project.
The following
mkdir x y
cd x
hg init
echo hoi > bla
hg add
hg commit -m 'yes, I am also too stupid to refuse explicit empty commit messages'
cd ../y
hg init
hg pull ../x
pretty much works the same in Darcs, bzr and mercurial.
With GIT, this is what happens
[hanwen@haring y]$ git pull ../x
Bzzt. This is where you went wrong, and you blamed "pull".
The way you do this in git is to NOT do "git init". Instead, you replace
all the
mkdir y
cd ../y
hg init
hg pull ../x
with a simple
git clone x y
and YOU ARE DONE.
Now, we could certainly _make_ "git pull" work on an empty git project,
but that has _nothing_ to do with what people have been talking about.
In fact, the fact that "git fetch" kind of works is not exactly accidental
(because "git fetch" _is_ meant to add new local branches too), but all
the problems you have with it are due to the SAME issue. You started
without any branch at all, because you started with an empty git repo, and
you're simply not _supposed_ to do that.
So current rule (and this is not new, it's always been true): the ONLY
time you use "git init-db" is when you are going to start a totally new
project. Never _ever_ otherwise. If you want to track another project, use
"git clone".
This might not be typical GIT use, but it does show the typical GIT user
experience, at least mine.
It's not that it isn't typical, it's that you are using the wrong model.
Maybe it's not well documented, I can easily give you that, but ALL your
problems come from that fundamental starting point: you shouldn't have
used "git init-db" in the first place.
Somebody want to document it?
Alternatively, we certainly _could_ make "git pull" just accept an empty
git repo, and make it basically create the current branch.
(And we probably should improve the error messahe)
I don't want ANYTHING to really change, I just want a sane interface to it.
The sane interface _exists_. It's called "git clone".
From: Carl Worth <hidden> Date: 2016-08-11 19:39:07
On Thu, 16 Nov 2006 09:17:32 -0800 (PST), Linus Torvalds wrote:
So the way you'd normally set up a single repo that contains multiple
other existing repositories is to basically start with one ("git clone")
and then add the other branches and "git fetch" them.
For that we'd also need a way for clone to be able to fetch just a
single branch, and not all of them as well.
There is some clone vs. fetch asymmetry here that has annoyed me for a
while, and that I don't think has been mentioned in this thread
yet. Namely:
clone: can only be executed once, fetches all branches, "remembers"
URLs for later simplified use
fetch: can be executed many times, fetches only named branches,
doesn't remember anything for later
I've often been in the situation where I cloned a long time ago, but
I'd like to be able to fetch everything that I would get if I were to
start a fresh clone.
-Carl
- git itself has now done it that way for the last 18 months, and the
fact is, the people _complaining_ are a small subset of the people who
actually use git on a daily basis and don't complain.
that's not a good argument; the set of git users is a small subset of those
that looked at git, and dismissed it because they couldn't wrap their heads
around it.
And I've said this again, and I'll say it once more: that has basically
_nothing_ to do with whether you spell "pull" as "pull" or "merge".
The reason people have trouble wrapping their heads around git is because
they have been braindamaged by CVS and SVN, and just don't understand the
fairly fundamental new concepts and workflow.
That's totally different from then arguing about stupid naming issues.
Peopel seem to believe that changign a few names or doing other totally
_minimal_ UI changes would somehow magically make things understandable. I
claim that isn't so at all. The fact is, git is different from CVS and
SVN, and git _has_ to be different from CVS and SVN. It has to be
different because the whole model of CVS and SVN is simpyl fundamentally
BROKEN.
It's worth trying to get those on board by fixing the annoying
little issues that have popped up in this thread.
I claim that those "annoying little issues" are totally made up by people
who had trouble wrapping their minds about git, and then make up reasons
that have nothing to do with reality for why that might be so.
Let's face it, you could just alias "merge" to "pull", and it wouldn't
really change ANYTHING. You'd still have to learn the new model.
From: Andreas Ericsson <hidden> Date: 2016-08-11 19:39:51
Michael K. Edwards wrote:
On 11/15/06, Linus Torvalds [off-list ref] wrote:
quoted
Actually, with different people involved it's _much_ better to do it in
one shot.
Why? Because doing a separate "fetch to local space" + "merge from local
space" actually loses the information on what you are merging.
It's a lot more useful to have a merge message like
Merge branch 'for-linus' of
git://one.firstfloor.org/home/andi/git/linux-2.6
than one like
Merge branch 'for-linus'
which is what you get if you fetched it first.
Full ACK from a platform integrator's perspective. Local merge is
great for trial runs but the history in a persistent branch should be
as self-contained and self-explanatory as possible. It shouldn't
depend on what I name local tracking branches, which are just a
convenience so that I can still do trial runs when my connectivity is
broken.
[...]
Coming from me, this is all rather theoretical, as I haven't been
using this particular tool for the purpose long enough to have an
independent opinion. But for what it's worth, the workflow Linus
describes isn't just for the guy at the top of the pyramid.
I think it's unfortunate that git was originally written by Linus, since
he so obviously is "the guy at the top of the pyramid" in many more
senses than just "Linus said this and that patch was OK to commit",
since git was designed to work like king Arthur's round table; "Linus is
in the same circle as me, so ofcourse we help each other out".
All suggestions I've been reading about tracking branches,
separate-remotes and whatnot have their merit. If any of it gets
implemented, I'd still like to be able to do one-shot pulls from remote
repos *without* creating specific tracking branches for it. It's
extremely useful to fetch other peoples topic-branches into my own
"master" (or topic-branch) when I trust their changes to be good. Please
consider that when you're hacking away on whatever changes to do.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
You're misunderstanding me: the multi-repo is at git.sv.gnu.org is the
remote one. The example I gave was about locally creating a single
project repo from a remote multiproject repo.
Ahh.
Ok, try the patch I just sent out, and see if it works for you. It
_should_ allow you to do exactly that
mkdir new-repo
cd new-repo
git init-db
git pull <remote> <onehead>
and now your "master" branch should be initialized to "onehead".
Oh, except I just realized that I forgot to do a "git checkout" in my
patch, so you'd need to add that (or do it by hand, but you really
shouldn't need to, since the checkout is implied by the "pull").
The downside with this is that it does NOT populate your "remotes"
information (like "git clone" would have done), so either we'd need to
teach "git pull" to do that too, or you just have to do it by hand (so
that you then can do the shorthand "git pull" to update in the future).
On a tangent: why is there no reverse-clone? I have no shell access
to the machine, so when I created the remote repo, I had to push, and
ended up putting 1.2 Gb data on the server.
Yeah, you're supposed to "init-db" and "push". Right now, that tends to
unpack everything (which is bad), although that is hopefully getting fixed
(ie the receiving end shouldn't unpack any more if it is recent. Junio?)
<looks at manpage>
is this send-pack?
"git push" uses send-pack internally, you shouldn't ever need to use it
yourself.
From UI perspective it would be nice if this could also be done with clone,
git clone . ssh+git://....
The creation of a new archive tends to need special rights (with _real_
ssh access and a shell you could do it, but "ssh+git" really means "git
protocol over a connection that was opened with ssh, but doesn't
necessarily have a real shell at the other end").
So for most protocols, you simply cannot (and shouldn't) do it. Think
about services like the one that Pasky has set up, that allow you to set
up a new git repo - the setup phase really _has_ to be separate (because
you need to set up your keys etc).
So I think the above syntax is actually not a good one, because it cannot
work in the general case. It's much better to get used to setting up a
repo first, and then pushing into it, and just accepting that it's a
two-phase thing.
Also, from a bandwidth standpoint, you can often (although obviously not
always) make the setup start with something that is _closer_ to what you
want to do. So, for example, you'd often do something like:
(a) ssh to central repository
(b) create the new repository by cloning it _locally_ at the central
place from some other repository that is related
(c) then, from your local (non-central) repository, do a "git push --force"
to force your changes (which now only needs the _incremental_ thing).
An example of this is again the "forking" thing that he repos at at
http://git.or.cz/ already supports.
quoted
And that "git pull" semantic actually means that if you want a _bare_
repository, I think "git --bare init-db" + "git --bare fetch" actually
yes, this works. Two remarks:
* it needs
website/master:master
otherwise you still don't have a branch.
Right. In fact, you should probably do
website/master:refs/heads/master
just to make it really explicit.
* why are objects downloaded twice? If I do
git --bare fetch git://git.sv.gnu.org/lilypond.git web/master
it downloads stuff, but I don't get a branch.
A "fetch" by default won't actually generate a local branch unless you
told it to. It just squirrels the end result into the magic FETCH_HEAD
name, so that you can do
# do the fetch
git fetch git://git.sv.gnu.org/lilypond.git web/master
# look at changes
gitk ..FETCH_HEAD
# If you're happy with them, merge them in
git merge "merge new code" HEAD FETCH_HEAD
and you never actually created a real local branch at all.
If you want "git fetch" to fetch _into_ a branch, you need to tell it so,
by using the full "src:dest" format. Otherwise it doesn't know what branch
to fetch it into.
(And, of course, you can define that branch relationship in your remote
configuration, so you don't actually have to say it explicitly every time)
If I then do
git --bare fetch git://git.sv.gnu.org/lilypond.git web/master:master
it downloads the same stuff again.
Right. So you can either
(a) do it that way to begin with (because you now told it to put the
results in "master", so you never needed to do the second fetch in
the first place)
or
(b) after you did the first fetch (into FETCH_HEAD), you could also have
just decided to do
git update-ref HEAD FETCH_HEAD ""
(where that "" at the end is really not technically necessary, but it
tells "update-ref" that you _only_ want to do this if the old HEAD
was empty/undefined. Without it, "git update-ref" will just
overwrite HEAD without caring what it contained before, so it can be
a dangerous operation!)
See?
From: Carl Worth <hidden> Date: 2016-08-11 19:40:43
On Wed, 15 Nov 2006 13:45:58 -0800 (PST), Linus Torvalds wrote:
On Wed, 15 Nov 2006, Carl Worth wrote:
quoted
Well, one of the problems is that with current git I can teach, (and I
have), that there's a conceptual:
pull = fetch + merge
But then shortly after I have to teach an interface notion:
merge = pull .
This is why I would suggest teaching the _concept_ of the "merge", and not
the actual command.
I don't think you should basically ever use the "git merge" command
itself, not in teaching, and not in real life.
I think that's just and accident of git-merge having such a bad
syntax, (requiring a merge message, not using -m for that, requiring
two heads instead of defaulting to current, etc.). So the result is
accepting another bad syntax "pull ." for an operation that really is
merge.
Once you've explained the _concept_ of merging, you then introduce the
command to actually _execute_ the merge: it's "git pull".
I think we'll be doing better when there is a stronger correlation
between the concepts of the operations and the command names for
carrying them out.
Plus, when I'm teaching "fetch everything first, then manipulate it
locally", (which is what I teach, since that's the only way I use
git), then the "." looks really out of place when I teach the 'merge'
command. I end up saying, "Oh, that's there because you could do the
fetch and merge all in one step if you really wanted, but I never do
that.".
And that's because I _do_ teach fetch first, as you've suggested.
changes from both branches. So it's a _conceptual_ issue, and that's why I
said I think you should just totally gloss over the whole issue of "git
merge" syntax.
That doesn't work. I know I went looking at the git-merge
documentation when I started to learn git. "It can't really be this
hard, can it?" was my reaction to it. And then only after attending a
tutorial did I learn that "pull ." is the way it's really done.
That's nothing more than a user-interface trap for new users, plain
and simple.
The real fix is to stop glossing over git-merge and just give it a
usable syntax.
-Carl
Yes, this was my exact thought when reading what Linus
wrote. ORIG_HEAD might be fine and all, but it pales in functionality
compared to what reflog provides.
I would very much like to see reflog getting first-class citizen
support in git:
1. Be on by default
I have:
git repo-config --global core.logAllRefUpdates true
especially since Junio fixed it to only create logs for heads and
not tags. That way its on by default for me. But I think it should
be on by default in the next version of Git.
2. Get documented in all the right places, (much better than adding
documentation for ORIG_HEAD in my opinion)
Agreed. I'm not likely to do it anytime soon however, so I'm hoping
someone else will do it... :-)
3. Tighter integration with branch manipulations. Do we already delete
reflog when deleting a branch? We don't have a branch rename
operation, but if we get one, renaming the reflog should go
hand-in-hand, etc.
Yes, we delete the log when we delete the branch, and we prune
back the empty directories too just like we do on the branch side,
so that new branches can be correctly created.
There was a recent discussion about that from Junio if I recall.
Several people that I work with have asked that branch rename
support be added to Git, and that if you rename the branch the
reflog follows. Because in their mind they are simply changing
the name of the branch, any old history of that branch should
stick around.
I tried to think of an option to "git branch" to do the rename but
kept thinking that:
git rename-branch old new
is the better syntax... even though that's command number 133
or something like that...
We should stick a "null" event into the reflog during a branch
rename. Make both the old and new SHA1 the current SHA1 but drop
a message in saying "renamed branch old -> new" (for example).
--
From: Michael K. Edwards <hidden> Date: 2016-08-11 19:43:50
On 11/15/06, Linus Torvalds [off-list ref] wrote:
Actually, with different people involved it's _much_ better to do it in
one shot.
Why? Because doing a separate "fetch to local space" + "merge from local
space" actually loses the information on what you are merging.
It's a lot more useful to have a merge message like
Merge branch 'for-linus' of git://one.firstfloor.org/home/andi/git/linux-2.6
than one like
Merge branch 'for-linus'
which is what you get if you fetched it first.
Full ACK from a platform integrator's perspective. Local merge is
great for trial runs but the history in a persistent branch should be
as self-contained and self-explanatory as possible. It shouldn't
depend on what I name local tracking branches, which are just a
convenience so that I can still do trial runs when my connectivity is
broken.
I don't have to manually log the _mechanical_origin_ of a given delta;
git does that for me, and mostly just DTRT when the same delta arrives
via several paths. When I use git pull from a remote branch (with or
without an entry in remotes/heads, which for this purpose is just
shorthand), I don't have to manually log what conflicts I have and
haven't resolved, either; I must have assimilated whatever I cared
about in the remote branch's history up to that point, because as long
as there are things in that remote branch that I haven't decided how
to handle, I stick to cherry-picking.
Obviously, fetch to local space is great (especially when you spend
some of your working hours behind a firewall that blocks outbound TCP
9418). Fetch from local space is also great, when the local space you
are fetching from reflects local work (such as a sync point and
reconciliation of several upstream sources, which then needs to be
ported forward or back to the chosen core version for each platform).
Fetch from a local space that is just a tracker for remote work is not
great, because it doesn't capture the editorial decision implied by a
remote pull: I looked at what the remote branch had to offer as of
this date, systematically decided which bits did and didn't belong in
the branch to which I was pulling, and pulled.
The record of that pull becomes a first-class object because it's
attached to an actual content delta in the target branch. So it
propagates into branches that pull from it. Pulling this delta into
another branch is different from cherry-picking a feature delta; it
implies acceptance of the reconciliation and editorial work associated
with the merge in the source branch.
Coming from me, this is all rather theoretical, as I haven't been
using this particular tool for the purpose long enough to have an
independent opinion. But for what it's worth, the workflow Linus
describes isn't just for the guy at the top of the pyramid.
Cheers,
From: Michael K. Edwards <hidden> Date: 2016-08-11 19:44:11
On 11/16/06, Michael K. Edwards [off-list ref] wrote
The only entry placed in .git/remotes is the
"origin" of the new clone, which is the "master" of the remote
repository. That's for the user's convenience, and is about the only
thing in the new clone that _isn't_ a copy of something in the remote
tree.
Actually, this "origin" entry does contain "Pull:" lines for all of
the branches that were cloned, so that "git pull" fetches and merges
updates to all of these branches. (If upstream is in the habit of
reverting things, you may need "git pull -f"; I just did that on the
git repo to handle a failure to fast-forward on the "pu" branch.)
Presumably "git branch -D" should inspect everything under
.git/remotes to see whether one or more Pull: lines need to be deleted
along with the branch. Currently, it looks like "remotes" entries are
created only by "git clone" or by hand. Junio, are there any plans to
manage the contents of "remotes" through the tool instead of by hand?
Cheers,
From: Michael K. Edwards <hidden> Date: 2016-08-11 19:45:02
I would kind of like to see "git poll" -- visit all remote branches,
fetching objects and tags into the local repository, so that I can
inspect changes off-line and merge, cherry-pick, etc. to my heart's
content. That would fit the platform integrator's workflow nicely --
"git poll" into a tracking tree, do some merges there (such as
backporting a subsystem to a "stable" base kernel), then merge this
backport branch to each platform working copy and cherry-pick other
changes as necessary.
Cheers,
So current rule (and this is not new, it's always been true): the ONLY
time you use "git init-db" is when you are going to start a totally new
project. Never _ever_ otherwise. If you want to track another project, use
"git clone".
Actually, only a 2 weeks ago, you suggested that I share the website
and main source code for my project in a single repository for reasons
of organization.
In this setup I find it logical to do
git init-db
git pull ..url.. website/master
to wind up with just the 5mb website, instead of the complete 70mb
of packed source code with all of its branches and tags.
It's not that it isn't typical, it's that you are using the wrong model.
Maybe it's not well documented, I can easily give you that, but ALL your
problems come from that fundamental starting point: you shouldn't have
used "git init-db" in the first place.
Somebody want to document it?
Alternatively, we certainly _could_ make "git pull" just accept an empty
git repo, and make it basically create the current branch.
From: Carl Worth <hidden> Date: 2016-08-11 19:46:17
On Wed, 15 Nov 2006 12:40:43 -0800 (PST), Linus Torvalds wrote:
On Wed, 15 Nov 2006, Nicolas Pitre wrote:
quoted
Actually I believe it would make things even clearer if "merge" was
taught at that point. Only when the user is comfortable with the
separate notions of fetching and merging might the pull shorthand
possibly be mentioned.
I agree. I just expect that "merge" is such a simple concept that it
doesn't really need a whole lot of explaining.
Well, one of the problems is that with current git I can teach, (and I
have), that there's a conceptual:
pull = fetch + merge
But then shortly after I have to teach an interface notion:
merge = pull .
So there's this goofy circular notion that people end up with
mentally. If we fix it so that a local merge really is performed with
"git merge <branch>" instead of "git pull . <branch>" then teaching
pull=fetch+merge really is a lot easier.
In the meantime, pull would still be useless to me, I think. But maybe
that's just the "default branch to merge" selection being broken. If
that were fixed, maybe I would start using pull.
(a) explain what "branches" mean in git (and in that situation, "fetch"
is very natural - I think fetching itself is probably easier to
explain than "branches" are).
There's a piece missing here, namely the mapping between remote and
local branch names and any notion of "tracking branches". I think a
sane story for that is still being invented, (or if it exists now, I
haven't seen it yet).
(c) once "fetching branches" and "merging" have been explained, "pull" is
really pretty damn trivial, and in fact, if you then explain that
it's just easier to do "git pull . branchname" than to use "git
merge", I think people may just even agree with you.
Well, they get pretty darn confused at this point, in my experience.
Once you understand local branches, fetching and merging, it's actually
_easier_ to explain why we merge even local branches with "git pull .":
you just tell them that this way you can use the same command regardless
of whether you're merging something local or something remote. Again, if
it's explained that way, I bet a lot of people react with "ahh, that's
clever", and _like_ the fact that they only really need to learn _one_
command, instead of learning two.
No. It's really, really broken to use "pull ." for local merging. Not
a feature at all. We just got done establishing that pull is a
shorthand for doing fetch+merge, so reusing it when there is _no_
fetch at all is insane.
You just established quite clearly hat git has a huge advantge over
all other systems by having a model that everything is fetched in
and then worked with locally. I agree that this is a major
selling-point of git, and I'm also baffled that systems like bzr and
hg try so hard to push every branch into a separate repository.
But I think that git's "work with everything locally" story is undercut
a bit by regular usage being to use a transfer-inducing command like
"pull" for a totally local merge.
Anyway, I think we all agree that we'd really rather have "git merge
<branch>" be usable for local merges, so let's get that in place and
users can pick whichever they like.
But the real issue here is to explain local branches. I will happily admit
that local branches are very VERY different from just about any other SCM,
but I also claim that git is just much BETTER than other SCM's in this
respect.
From: Josef Weidendorfer <hidden> Date: 2016-08-11 19:47:27
On Wednesday 15 November 2006 19:28, you wrote:
Linus Torvalds wrote:
quoted
But the fact is, git isn't really that hard to work out, and the commands
aren't that complicated. There's no reason to rename them. We do have
other problems:
- default branch selection for merging is broken (it should definitely
take the current branch into account). When I do "git pull" with no
branch specification, and I happen to be on a branch that is associated
with something else than "master" in the remote, I shouldn't merge with
master.
This problem is _slightly_ migitated by branch.<name>.merge config variable.
Slightly because you have to specify branch to merge, instead of forbidding
merge if you are not on specific branch (and you don't override it).
We should change this.
The problem is that whatever is the first Pull line in remotes config gets
merged by default into current branch, which most often is not the right
thing to do.
Often, I find myself doing "git branch" just to make sure that I am on
"master", so that a following pull does not do a bogus merge.
Can we please disable this behavior, e.g. by allowing a fake first
Pull line like "Pull: (not-for-merge)" to prohibit any merge?
This even could be written by default in git-clone somewhere in the future,
and we suddenly get the behavior of pull being symmetric to push - at least
by default. And still, it is fully compatible to existing repositories.
To make pull do the right thing, we _have_ to configure branch.<name>.merge
whenever we create a new branch (which matters for git-clone, too).
Josef
quoted
- I agree that having to create temporary branches to just look at a tag
that you don't want to actually develop on is just unnecessarily
bothersome.
Actually I believe it would make things even clearer if "merge" was
taught at that point. Only when the user is comfortable with the
separate notions of fetching and merging might the pull shorthand
possibly be mentioned.
I agree. I just expect that "merge" is such a simple concept that it
doesn't really need a whole lot of explaining.
People kind of expect merging to be hard, but I think it's because CVS et
al have tought people that merging is _painful_. I don't think it's a very
complicated concept per se, especially if you have explained branches with
gitk already.
But yes, the order should be:
(a) explain what "branches" mean in git (and in that situation, "fetch"
is very natural - I think fetching itself is probably easier to
explain than "branches" are).
(b) once you've explained branches, the notion of "merge" comes next, and
I _think_ that is very obvious. This is where UI issues come in,
because "git merge" is really a totally internal program with a
pretty horrid UI, but I think we could fix the syntax, and even with
the current syntax you can really just gloss it over, because nobody
is really going to care.
(c) once "fetching branches" and "merging" have been explained, "pull" is
really pretty damn trivial, and in fact, if you then explain that
it's just easier to do "git pull . branchname" than to use "git
merge", I think people may just even agree with you.
I think I saw that particular discussion on #git: somebody didn't expect
"git pull . branch" to be the way to merge. And again, I think it's
not _really_ because "pull" is hard to understand, it's because people
haven't been walked through the thing in this way.
Once you understand local branches, fetching and merging, it's actually
_easier_ to explain why we merge even local branches with "git pull .":
you just tell them that this way you can use the same command regardless
of whether you're merging something local or something remote. Again, if
it's explained that way, I bet a lot of people react with "ahh, that's
clever", and _like_ the fact that they only really need to learn _one_
command, instead of learning two.
See? Explain it that way: "pull" really is simple. By using "pull", you
don't have to learn about "merge" syntax. You -can- use "merge" as a
separate program if you want to, but the syntax isn't very nice, exactly
because you're not really expected to.
But the real issue here is to explain local branches. I will happily admit
that local branches are very VERY different from just about any other SCM,
but I also claim that git is just much BETTER than other SCM's in this
respect.
And yes, this is why you should NOT try to use the same naming as "hg",
for example. Last I saw, hg still didn't even have local branches, To
mercurial, repository == branch, and that's it. It was what I came from
too, and I used to argue for using git that way too. I've since seen the
error of my ways, and git is simply BETTER.
And the concept of local branches is exactly _why_ you have to have
separate "fetch" and "pull", but why you do _not_ need a separate "merge"
(because "pull ." does it for you).
If you don't understand local branches, you'll never understand git usage.
And once you _do_ understand local branches, "fetch" vs "pull" actually is
rather simple.
A "fetch" by default won't actually generate a local branch unless you
told it to. It just squirrels the end result into the magic FETCH_HEAD
name [...]
Btw, the magic heads are probably not all that well documented. They do
come up in the man-pages, but I don't think there is any central place
talking about them. We have:
- "HEAD" itself, which is obviously the default pointer for a lot of
operations, and that specifies the current branch (ie it should
currently always be a symref, although we've talked about relaxing
that)
- "ORIG_HEAD" is very useful indeed, and it's the head _before_ a merge
(or some other operations, like "git rebase" and "git reset": think of
it as a "original head before we did some uncontrolled operation
where we otherwise can't use HEAD^ or similar")
I use "gitk ORIG_HEAD.." a lot, and if I don't like something I see
when I do it, I end up doing "git reset --hard ORIG_HEAD" to undo a
pull I've done. This is important exactly because ORIG_HEAD is _not_
the same as the first parent of a merge, since a merge could have been
just a fast-forward.
- "FETCH_HEAD" as mentioned. Normally you'd only use this in scripting, I
suspect, but it's potentially useful if you prefer to do a fetch first
and then check out it (perhaps cherry-picking stuff instead of merging,
for example).
So you could do (for example)
git fetch some-other-repo branch
gitk ..FETCH_HEAD
git cherry-pick <some-particular-commit-you-picked>
- "MERGE_HEAD" is kind of the opposite of "ORIG_HEAD" when you're in
the middle of a merge: it's the "other" branch that you're merging.
It's mainly useful for merge resolution, ie
git log -p HEAD...MERGE_HEAD -- some/file/with/conflicts
is a great way to see what happened along both branches (note the
_triple_ dot: it's a symmetric difference), to see _why_ the confict
happened.
Most of the above are used implicitly in various cases, not just HEAD. The
"--merge" flag to git-rev-list (and thus git log and friends) is just
shorthand for the above "HEAD...MERGE_HEAD" behaviour (with the addition
of also limiting the result to just conflicting files), so
git log -p --merge
is basically exactly the same as the above (except for _all_ files that
have conflicts in them rather than just one hand-specified one).
Anyway, maybe somebody didn't know about these, and finds them useful.
Normally, the only one you would _really_ use is "ORIG_HEAD" (which is
described in several of the tutorials and examples, so people hopefully
already know about it). Most of the others tend to mostly be used
implicitly, not by explicitly naming them - although you _can_.
@@ -95,6 +100,12 @@ case "$merge_head" in ;; esac+if test -z "$orig_head"+then+ git-update-ref -m "initial pull" HEAD $merge_head "" || exit 1+ exit+fi+
So this is the place that probably wants a "git-checkout" before the
exit, otherwise you'd (illogically) have to do it by hand for that
particular case.
Of course, we should _not_ do it if the "--bare" flag has been set, so you
migth want to tweak the exact logic here.
On Wed, 15 Nov 2006 15:26:44 -0500, Nicolas Pitre wrote:
On Wed, 15 Nov 2006, Petr Baudis wrote:
quoted
On Wed, Nov 15, 2006 at 03:10:16AM CET, Junio C Hamano wrote:
quoted
You have to admit both pull and fetch have been contaminated
with loaded meanings from different backgrounds. I was talking
about killing the source of confusion in the longer term by
removing fetch/pull/push, so we are still on the same page.
How was/is fetch contaminated?
I think "fetch" is sane. Its only problem is a missing symetrical
counterpart verb, like "get" and "put".
"throw" ?
But I think "I'll just 'throw' this set of patches at you" is a lot
harshers sounding than "I'll just 'push' this set of patches at you".
Anand
From: Jakub Narebski <hidden> Date: 2016-08-11 19:52:16
Linus Torvalds wrote:
But the fact is, git isn't really that hard to work out, and the commands
aren't that complicated. There's no reason to rename them. We do have
other problems:
- default branch selection for merging is broken (it should definitely
take the current branch into account). When I do "git pull" with no
branch specification, and I happen to be on a branch that is associated
with something else than "master" in the remote, I shouldn't merge with
master.
This problem is _slightly_ migitated by branch.<name>.merge config variable.
Slightly because you have to specify branch to merge, instead of forbidding
merge if you are not on specific branch (and you don't override it).
- I agree that having to create temporary branches to just look at a tag
that you don't want to actually develop on is just unnecessarily
bothersome.
Agreed.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
From: Nicolas Pitre <hidden> Date: 2016-08-11 19:53:05
On Tue, 14 Nov 2006, Junio C Hamano wrote:
Nicolas Pitre [off-list ref] writes:
quoted
"You pull the remote changes with 'git-pull upstream,, then you can
merge them in your current branch with 'git-merge upstream'."
Isn't it much simpler to understand (and to teach) that way?
If it were "you download the remote changes with 'git download
upstream' and then merge with 'git merge'", then perhaps, but if
you used the word "pull" or "fetch", I do not think so.
I would be all for changing the semantics of "pull" from one
thing to another, if the new semantics were (1) what everybody
welcomed, (2) what "pull" traditionally meant everywhere else.
In that case, we have been misusing it to be confusing to
outsiders and I agree it makes a lot of sense to remove the
source of confusion. But I do not think CVS nor SVN ever used
the term, and I was told that BK was what introduced the term,
and the word meant something different from what you are
proposing.
You have to admit both pull and fetch have been contaminated
with loaded meanings from different backgrounds. I was talking
about killing the source of confusion in the longer term by
removing fetch/pull/push, so we are still on the same page.
That's where my "you download from the upstream and merge" comes
from.
But the fact is that HG (which has a growing crowd of happy campers,
maybe even larger than the BK crowd now) did work with and got used to a
sensible definition of what a "pull" is. This means that their
definition is becoming rather more relevant with time than what it used
to, and because it is a saner definition than what GIT has for the same
word which HG users really have no issue with, I think we really should
leverage the "common wisdom" and consider aligning ourselves with them
in this case rather than trying to go into a totally different
direction. We simply won't gain anything trying to teach people "a pull
in HG is a download in GIT". If a pull becomes the same thing for both
then it's one less oddball in the GIT interface.
But the fact is that HG (which has a growing crowd of happy campers,
maybe even larger than the BK crowd now) did work with and got used to a
sensible definition of what a "pull" is.
Guys, before you start thinking this way, the fact is, there's a lot of
happy git users.
So the reason for using "git pull" is
- bk did it that way, and like it or not, bk was the first usable
distributed system. hg is totally uninteresting.
- git itself has now done it that way for the last 18 months, and the
fact is, the people _complaining_ are a small subset of the people who
actually use git on a daily basis and don't complain.
So don't fall for the classic "second system syndrome". The classic reason
for getting the second system wrong is because you focus on the issues
people complain about, and not on the issues that work well (because the
issues that work fine are obviously not getting a lot of attention).
If you think "pull" is confusing, I can guarantee you that _changing_ the
name is a hell of a lot more confusing. In fact, I think a lot of the
confusion comes from cogito, not from git - the fact that cogito used
different names and different syntax was a mistake, I think.
And that '#' for branch naming in particular was (and is) total
braindamage. The native git branch naming convention is just fundamentally
much better, and allows you to very naturally fetch multiple branches at
once, in a way that cogito's syntax does not.
So when I see suggestions of using that brain-damaged cogito syntax as an
"improvement", I know for a fact that somebody hasn't thought things
through, and only thinks it's a better syntax beause of totally bogus
reasons.
I do agree that we probably could/should re-use the "git merge" name. The
current "git merge" is an esoteric internal routine, and I doubt a lot of
people use it as-is. I don't think it would be a mistake to make "git
merge" basically be an alias for "git pull", for example, and I doubt many
people would really even notice.
But the fact is, git isn't really that hard to work out, and the commands
aren't that complicated. There's no reason to rename them. We do have
other problems:
- default branch selection for merging is broken (it should definitely
take the current branch into account). When I do "git pull" with no
branch specification, and I happen to be on a branch that is associated
with something else than "master" in the remote, I shouldn't merge with
master.
- I agree that having to create temporary branches to just look at a tag
that you don't want to actually develop on is just unnecessarily
bothersome.
But trying to rename "pull" (or the "git" name itself) is just going to
cause more confusion than you fix.
Why? We _do_ have the temporary branch. It's called FETCH_HEAD.
It is a terrible UI, because it was not that obvious to me. And I consider
myself not a git newbie.
Heh. The "temporary branches" are actually the _original_ branches as far
as git is concerned. The long-term branches only came later.
So in many ways, HEAD, FETCH_HEAD, MERGE_HEAD and ORIG_HEAD are more
fundamental than any long-term branch has ever been, and maybe they should
be taught first as such.
So you're newbie enough that you've only seen those new-fangled "real"
branches.
When I was young, we had to walk to school up-hill in three feet of snow
every day. And we _liked_ our FETCH_HEAD's.
Besides, it is not really a temporary branch. If it was, the pull would
_not_ download all these objects again, would it?
Well, exactly because they are temporary, we can't actually trust the
objects they point to. They have no "real" long-term life, so no, I'm
afraid that we always will have to re-fetch the objects, because fetching
them is the only way to know that we still have them.
That said, we could certainly _make_ them be honored by things like "git
prune" and friends. But yes, they really _are_ temporary branches right
now, and part of the meaning of that "temporary" is exactly the fact that
git fetch will not trust that you still have the objects.
For example, if you used one of the old-fashioned commit walkers, maybe we
got the initial commit, but we may not have gotten the whole _chain_. See?
Temporary branch indeed.
quoted
Again, why didn't you use FETCH_HEAD?
Because I am a Jar-HEAD?
Well, we clearly should document them better. Anybody?
On the one hand you're arguing that git syntax is easy to learn, and on the
other that no one will be able to learn a new syntax just as easily.
I'm saying that people who are new to git will _have_ to learn new
concepts ANYWAY.
I don't think the naming is the hard part.
The fact is, git is one of the very few (essentially _only_) SCM's that
make it very clear that all real operations are local and that if you want
to work with other repositories, you have to "fetch" those into local
branches first. The fact that "pull" exists at all is really just
shorthand.
If people have trouble explaining this to others, and have trouble
grasping "pull", then I will bet that the _real_ issue has nothing at all
to do with naming at all, and the real issue is that people are being
_taught_ the concepts in the wrong order.
Before you learn "pull", you should learn "fetch". Don't even _mention_
"pull" until the person got what "fetch" means. Because the fact is,
"fetch" is really the much more fundamental operation, and once you
really understand what "fetch" does, "pull" is obvious.
So I'll argue that the problem isn't naming, the "problem" is really that
git has a few fundamnetal concepts that people aren't used to. The most
fundamnetal of those is the notion of the local branch-space. EVERY other
(broken) SCM has branches as being some kind of totally idiotic separate
subdirectories, or doesn't really support branches at all (ie neither BK
nor CVS really support "branches" - even if a concept of that name exists
in CVS, it has nothing at all in common with the git model of branches).
But once you understand branches, and understand "fetch" (and it really
isn't _that_ complicated: fetch really does exactly what the name says, so
if you understand local branches, you will understand "fetch"), then it's
a much smaller step to explain "pull = fetch + merge".
But I bet people don't teach it that way. They _start_ by teaching "pull".
Right?
From: Petr Baudis <hidden> Date: 2016-08-11 19:54:57
On Wed, Nov 15, 2006 at 09:31:13PM CET, Josef Weidendorfer wrote:
Often, I find myself doing "git branch" just to make sure that I am on
"master", so that a following pull does not do a bogus merge.
Can we please disable this behavior, e.g. by allowing a fake first
Pull line like "Pull: (not-for-merge)" to prohibit any merge?
Wait, if you don't want pull to merge, why do you pull and not fetch?
(Disclaimer: I'm not intimately familiar with git pull/fetch and I
didn't read the whole thread yet.)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
Well, one of the problems is that with current git I can teach, (and I
have), that there's a conceptual:
pull = fetch + merge
But then shortly after I have to teach an interface notion:
merge = pull .
This is why I would suggest teaching the _concept_ of the "merge", and not
the actual command.
I don't think you should basically ever use the "git merge" command
itself, not in teaching, and not in real life. So after talking about
branches and having taught people to use "git fetch", the next stage is
not so much to teach people to use "git merge", but to explain to them the
_concept_ of merging.
I really think that's a fairly quick thing, partly exactly _because_ you
shouldn't at that point need to worry about syntax or details or anything
like that at all. You just tell them that there's a notion of "merging"
two branches by joining them together and havign the result have the
changes from both branches. So it's a _conceptual_ issue, and that's why I
said I think you should just totally gloss over the whole issue of "git
merge" syntax.
Once you've explained the _concept_ of merging, you then introduce the
command to actually _execute_ the merge: it's "git pull".
See? No circular thinking at all. One is a _concept_ ("join two branches
together by including both in the result") and the other is a command
("pull will fetch the remote data if any, and merge it into the current
branch").
If you explain it that way, then _obviously_ if you don't need to fetch
any remote data, doing "git pull . xyzzy" will merge the local branch
"xyzzy" into the current branch.
From: Carl Worth <hidden> Date: 2016-08-11 19:55:42
On Wed, 15 Nov 2006 15:33:43 -0800 (PST), Linus Torvalds wrote:
It's a lot more useful to have a merge message like
Merge branch 'for-linus' of git://one.firstfloor.org/home/andi/git/linux-2.6
than one like
Merge branch 'for-linus'
There's more information in the first, sure. But I absolutely don't
accept that it's necessarily more useful, and definitely not that this
is a good argument for using pull with a remote branch instead of
fetch followed by merge with a local branch.
First, the pull may just fast-forward in which case there's no message
at all. And we've been through that topic enough recently that we all
know that no important information is lost by not doing any separate
recording in that case.
So you can't turn around and argue that the remote URL information is
suddenly important when it just so happens that it's not a fast
forward.
And in a truly distributed situation, "pull" is strictly more powerful
than a separate "fetch" + separate "merge".
I don't buy it. In my usage, I have several different remote
repositories I'm interested in tracking, each with any number of
branches. What I really want is an easy command that fetches all of
those branches, (even new ones that I've never heard about---but never
any of their "tracking branches" that wouldn't be of interest to
me). And I want to do that once, to get the online-access-required
part over with and get all the data into my local repository where I
can start working with it.
As for the URL from which I'm fetching all this stuff, it's really not
interesting to me at all. The URL for "Keith's stuff" keeps changing
anyway---I have no interest in recording that. But I do think it's
worth recording that the commits came from Keith's repository. I do
that right now with a keith/ prefix for his branches. It could also be
done by bringing in his .git/description during the fetch and storing
it somewhere. But I honestly don't see how storing something like that
during would make the system any less distributed in any sense.
-Carl
A lot of the complaints seem to not be about the interfaces, but about
people not _understanding_ and knowing what the interfaces do. If you were
From the point of view of a user, there is not really a difference
between the two. As a user, you form a mental model of how things
work by looking at the interface. If the interface is bad, the user
creates a faulty model in his head, and starts doing things that
are perfectly logical in the faulty model, but stupid and silly when
you consider the actual internals.
A nice book about this is "The Design of Everyday Things" by Donald
Norman.
--
Plus, when I'm teaching "fetch everything first, then manipulate it
locally", (which is what I teach, since that's the only way I use
git), then the "." looks really out of place when I teach the 'merge'
command. I end up saying, "Oh, that's there because you could do the
fetch and merge all in one step if you really wanted, but I never do
that.".
And that's because I _do_ teach fetch first, as you've suggested.
Ditto. In every way.
I've taught the same fetch first, then merge strategy. Nobody I
know in meat-space pulls from a remote URL and merges in one shot;
they always fetch locally, look at the incoming changes, decide if
its worthwhile/ok, *then* merge with "git pull . branch".
The "." looks out of place for everyone...
--
- "ORIG_HEAD" is very useful indeed, and it's the head _before_ a merge
(or some other operations, like "git rebase" and "git reset": think of
it as a "original head before we did some uncontrolled operation
where we otherwise can't use HEAD^ or similar")
I use "gitk ORIG_HEAD.." a lot, and if I don't like something I see
when I do it, I end up doing "git reset --hard ORIG_HEAD" to undo a
pull I've done. This is important exactly because ORIG_HEAD is _not_
the same as the first parent of a merge, since a merge could have been
just a fast-forward.
Although if you have reflog enabled on your current branch there
is a 1 character shorter syntax:
gitk HEAD@{1}..
as recent Git understands that to mean the value that HEAD just had,
which is also what is in ORIG_HEAD. Except that unlike ORIG_HEAD
it can also show even older values (e.g. HEAD@{3}, 3 ops back)
and it works very, very well on tracking branches. "What did I
just fetch in next?" `git log next@{1}..next`
--
On Wed, Nov 15, 2006 at 12:40:43PM -0800, Linus Torvalds wrote:
And yes, this is why you should NOT try to use the same naming as "hg",
for example. Last I saw, hg still didn't even have local branches, To
mercurial, repository == branch, and that's it. It was what I came from
too, and I used to argue for using git that way too. I've since seen the
error of my ways, and git is simply BETTER.
Actually, that's not true. Mercurial has local branches, just as git
does. Some people choose not to *use* this particular feature, and
use the BK style repository == branch, but that's mainly because it's
conceptually easy for them, and a number of BK refugees are very
happily using Hg.
It's probably because of the BK refugee population that after you do
an hg pull, it will warn you that you need to do an "hg update" in
order to merge the working directory up to the latest version that was
just pulled --- and this change was made precisely because Hg supports
local branches, and merging with the current branch isn't always the
right thing, unlike with BK.
And the concept of local branches is exactly _why_ you have to have
separate "fetch" and "pull", but why you do _not_ need a separate "merge"
(because "pull ." does it for you).
It's just that the semantics are different, and many developers have
to use multiple DSCM's, depending on what project they happen to be
developing on. So the reality is that there are people who have to
use bzr, git, and hg, all at the same time. And while eventually
newbies will figure out and remember that "git pull ." == "merge", the
naming is simply confusing, that's all. (What does "pull" have to do
with "merge"? It's not at all obvious.)
For somoene who uses git full-time, and to the exclusion of all other
systems, I'm sure it's not a problem at all.
From: Petr Baudis <hidden> Date: 2016-08-11 19:59:27
On Wed, Nov 15, 2006 at 07:03:18PM CET, Linus Torvalds wrote:
If you think "pull" is confusing, I can guarantee you that _changing_ the
name is a hell of a lot more confusing. In fact, I think a lot of the
confusion comes from cogito, not from git - the fact that cogito used
different names and different syntax was a mistake, I think.
I would agree that having "pull" mean something different in Cogito
than in Git was a bad idea (explanation: historically, for some period
of time Cogito had cg-pull which meant the same as cg-fetch or hg pull;
later it got renamed to cg-fetch). But I'm also happy that Cogito just
does not use the "pull" expression at all currently: "updating" seems to
be a clear and unloaded enough concept for new people. Pull is really
_very_ confusing, with it meaning something different (but not different
enough) in _all_ other systems but BK (which is basically irrelevant
nowadays).
That said, I agree with your argument that changing it in Git now
might just result in more confusion. I'm just trying to explain Cogito's
choice here, and I believe it does no good nor harm to Core Git if it
just uses different name for the concept and avoids the original name at
all (except explaining in the docs that updating in Cogito is what
pulling is in Git).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
Until that time, it would be good goal to remove all idiosyncrasies,
all gratuitious asymetries and needless limitations in the commands of
git, eg.
Well, a lot of the assymmetries aren't actually gratuitous at all.
- clone but not a put-clone,
As mentioned, in order to "put-clone", you generally have to "create"
first, so the "put-clone" really makes no sense.
The _true_ reverse is really your
- "git init-db" on both sides
- "git pull" (your workflow ;) on receiving
- "git push" on sending.
The fact that we can do "git clone" on the _receiving_ side is an
assymmetry, but it's not gratutous: when receiving we don't need any extra
permissions or setup to create a new archive. In contrast, when sending,
you do have to have that "get permission to create new archive" phase.
- pull = merge + fetch, but no command for merge + throw
Again, this is not gratuitous, and the reason is very similar: when you
pull, you're pulling into something that _you_ control and _you_ have
access to, namely your working directory. In order to merge you have to
have the ability to fix up conflicts (whether automatically or manually),
and this is something that you _fundamentally_ can only do when you own
the repo space.
Again, when you do "push", the reason you can't merge is not a "gratuitous
assymmetry", but a _fundamental_ assymmetry: by definition, you're pushing
to a _remote_ thing, and as such you can't merge, because you can't fix up
any merge problems.
See?
In many ways, if you want _symmetry_, you need to make sure that the
_cases_ are symmetrical. If you have ssh shell access, you can often do
that, and the "reverse" of a "git pull" is actually just another "git
pull" from the other side:
ssh other-side "cd repo ; git pull back"
Now they really _are_ symmetrical: "git pull" is really in many ways ITS
OWN reverse operation.
But "push" and "pull" _fundamentally_ aren't symmetric operations, and you
simply cannot possibly make them symmetric. Any system that tries would be
absolutely horrible to use, exactly because it would be either:
- making local/remote operations totally equivalent
This sounds like a "good" thing, but from a real user perspective it's
actually horribly horribly bad. Knowing the difference between local
and remote is what allows a lot of performance optimizations, and a lot
of security. Your local repo is _yours_, and nobody can take that away
from you, and that's a really fundamental reason for why the symmetry
cannot exist, and why local/remote operations MUST NOT be something
that you can mix without thinking about them,
- limit local operations in a way to make them effectively unusable and
unscriptable.
You'd basically have to do everything even _locally_ through some
server interface, and you'd not be allowed to ever touch your local
checked-out repository directly. Again: local repositories really _are_
special, because you can touch the checked out copy. If you try to
suppress that, you're screwed.
- clone for getting all branches of a repo, but no command for
updating all branches of a repo.
As in sending? Sure there is: use "git push --all". It will push out every
branch (and tag) you have. Add "--force" if you want to make sure that it
also pushed out branches even if the result isn't a strict superset (of
course, the receiving end may actually end up refusing to take it, there's
a option for the receiver to say "I will refuse any update that isn't a
strict superset of what I had").
If you mean as in "receiving new branches", then yeah, you do have to
script it, with some fairly trivial "git ls-remote" to make sure you get
the new remotes.
Well, one of the problems is that with current git I can teach, (and I
have), that there's a conceptual:
pull = fetch + merge
But then shortly after I have to teach an interface notion:
merge = pull .
So there's this goofy circular notion that people end up with
mentally. If we fix it so that a local merge really is performed with
"git merge <branch>" instead of "git pull . <branch>" then teaching
pull=fetch+merge really is a lot easier.
On a conceptual level, can we not perhaps explain that if
pull = fetch + merge
then
merge = pull - fetch
and that the latter (pull - fetch) happens to be expressed with the
interface as 'git pull .' ?
My 2 cents.
Jérôme
From: Nicolas Pitre <hidden> Date: 2016-08-11 20:08:22
On Wed, 15 Nov 2006, Linus Torvalds wrote:
On Wed, 15 Nov 2006, Nicolas Pitre wrote:
quoted
I think "fetch" is sane. Its only problem is a missing symetrical
counterpart verb, like "get" and "put".
If you're a dog owner, the obvious counterpart for "fetch" is "throw" ;)
Yeah. You could always throw a branch to your dog.
Or maybe we should introduce the concept of "bones" to GIT in place of
branches? ;-)
I think "get" and "put" would be bad, just because of confusion with
"sccs get" (ie it has that "get this file" connotations).
Has SCCS really had a similar level of influence than BK or CVS in that
matter?
Maybe "fetch" and "push" aren't totally diametrically opposite, but
really, I don't think they are that hard to understand either. We do have
the BK legacy of "pull" implying a merge, and that's fairly fundamental.
It's also true that in a lot of usage schenarios, what people actually
_use_ is "pull" and "push", and no, they aren't mirror images (since push
will _not_ do the merge), but at the same time, from a _usage_ standpoint
they really _are_ each others opposites.
The problem is the "usage standpoint" distinction that has to be made.
Exactly because in GIT it is a bit distorted from what most people
expect from other standpoints.
You "pull" to get other peoples data into your branch (and once you've
internalized local branches and the merge thing, you know what this
means), and you "push" to push your changes out. It really _is_ the usage
schenario, and using "opposite" words really _does_ make sense.
But that's exactly why newbies have problems. Instead of simply
understanding the bare operation (fetch data in a branch _then_ merge
it) they sort of need to abstract the concept of branch away because a
"pull" does it all automagically. Which is fine as long as you're
willing to ignore branch concepts altogether. But once branches are
back in the picture for more involved operations then the "pull" word
simply feels odd. Even more so with the local merge syntax.
When I say to someone "just merge branch weezee with your current
branch" the most intuitive command would be:
git merge weezee
But because "pull" mixes two concepts together this makes the thing more
esoteric. Unless, of course, you get used to the mental model you
outlined above, but IMHO simply needing a mental model to explain the
tool is a sign that something is mapped wrong.
I've taught the same fetch first, then merge strategy. Nobody I
know in meat-space pulls from a remote URL and merges in one shot;
Actually, with different people involved it's _much_ better to do it in
one shot.
Why? Because doing a separate "fetch to local space" + "merge from local
space" actually loses the information on what you are merging.
It's a lot more useful to have a merge message like
Merge branch 'for-linus' of git://one.firstfloor.org/home/andi/git/linux-2.6
than one like
Merge branch 'for-linus'
which is what you get if you fetched it first.
Of course, in a situation like git itself, where most of the merges are
stuff that Junio has had pending in his own tree ('maint' branch etc),
things are different. But in a system where people actually use separate
trees, there really is an advantage to consider the fundamental operation
to be the "pull", not the "merge".
Again, the kernel really is more distributed than most projects, but this
is another thing people should recognize: git has been designed for "true
distributed development". Not the "fake" kind. Not the "I merge mainly my
own branches" kind of thing. Truly distributed.
And in a truly distributed situation, "pull" is strictly more powerful
than a separate "fetch" + separate "merge".
In other words, an SCM that does "pull" is _better_ than an SCM that does
"merge". You can implement "merge" as a special case of "pull" (which we
do), but you cannot conveniently do it the other way around without having
to tie them together some other way (ie you could have a "remember the
last place we fetched this branch from in order to tie the fetch and the
merge together" - but please realize that that is exactly what "pull"
_is_).
So I will generally do a "git pull" (possibly followed by a "git reset
--hard ORIG_HEAD" if I decided it wasn't good) over a "git fetch" + "git
merge". Exactly because the "pull" operation is actually more powerful.
Maybe people who aren't in my position don't always appreciate the _power_
of git. The reason "merge" is a second-class citizen is simply because IT
SHOULD BE.
From: Johannes Schindelin <hidden> Date: 2016-08-11 20:09:11
Hi,
On Wed, 15 Nov 2006, Linus Torvalds wrote:
Peopel seem to believe that changign a few names or doing other totally
_minimal_ UI changes would somehow magically make things understandable.
Never ever underestimate pet peeves. If we give many people an obvious
reason (however trivial and bike-shed-coloured) to complain, they will
complain.
If we pull (pun intended) that reason away under their collective
backsides, they will have to find another reason to complain. But by the
time they found something, they will already be happy git users!
But since you just provided a patch to make life easier on non-gitters, I
guess you agree with that already.
And hopefully you also agree that enhancing the syntax of git-merge to
grok "git-merge [-m message] <branch>" and "git-merge [-m message]
<url-or-remote> <branch>" would be a lovely thing, luring even more
people into using git.
Maybe they even start complaining about subversion and CVS calling a merge
"update", who knows?
Ciao,
Dscho
From: Nicolas Pitre <hidden> Date: 2016-08-11 20:09:42
On Wed, 15 Nov 2006, Linus Torvalds wrote:
On Wed, 15 Nov 2006, Nicolas Pitre wrote:
quoted
That is an implementation detail that should be easily overcome once the
notion of tracking branch with URL attribute is implemented.
Nope.
I simply don't _have_ those branches.
Why? Because the kernel is _distributed_. There is no central place
(certainly not my repository) that tracks all the possible branches that
might get merged.
In other words, I repeat: in a TRULY DISTRIBUTED ENVIRONMENT it makes more
sense to have a "pull" that fetches and merges, over something that
fetches separately and then merges.
[...]
OK fine. git-pull is there to stay and let's make sure it remains the
same.
Let's see if, for example, git-merge can be made more useful in the mean
time for those evidently inferior people that would prefer an interface
that maps more closely to the actual operation that is being performed.
And although I do understand what "pull" does, I think I should qualify
myself as one of those inferior people nevertheless since /pull . blah"
really irritates me. OK I must be really dumb to let myself being
disturbed by such an insignificant detail... but apparently I'm not
alone.
But I promise to never change the "pull" behavior if I ever attempt to
fix the "merge" command for the inferior mortals as myself. All power
to those with superior minds shall never be removed.
;-)
From: Johannes Schindelin <hidden> Date: 2016-08-11 20:12:48
Hi,
On Thu, 16 Nov 2006, Linus Torvalds wrote:
On Thu, 16 Nov 2006, Han-Wen Nienhuys wrote:
quoted
* why are objects downloaded twice? If I do
git --bare fetch git://git.sv.gnu.org/lilypond.git web/master
it downloads stuff, but I don't get a branch.
A "fetch" by default won't actually generate a local branch unless you
told it to.
This is actually a perfect example for
- a script that is porcelain as well as plumbing (you are supposed to use
it directly, or via pull), and for
- a terrible UI.
_If_ you use git-fetch directly you virtually always want to store the
result. I was tempted quite often to submit a patch which adds a command
line switch --no-warn, which is passed to git-fetch by git-pull, and
without which git-fetch complains if the branch-to-be-fetched is not
stored right away (and refuses to go along).
_Also_, git-pull not storing the fetched branches at least temporarily
often annoyed me: the pull did not work, and the SHA1 was so far away I
could not even scroll to it. The result: I had to pull (and fetch!) the
whole darned objects again. Again, I was tempted quite often to submit a
patch which makes git-pull fetch the branches into refs/fetch-temp/* and
only throw them away when the merge succeeded.
Ciao,
Dscho
Although if you have reflog enabled on your current branch there
is a 1 character shorter syntax:
gitk HEAD@{1}..
Heh. With a finnish keyboard, that "@" is AltGr+'2', and the '{'/'}' is
AltGr+'7'/'0', I guarantee that it's not "1 character shorter", it's
"three pretty complicated characters longer" and "off the normal path
where you hold your fingers on the keyboard ;)
I forgot that you use a finnish keyboard. :-)
I agree with you; its not easier to type, for you. Me, I'm a dumb
American who uses a Kinesis keyboard, therefore my left foot is
my shift key and its in sync with my fingers. I have no extra
pinky load for either syntax. And since the reflog syntax works
in a lot more contexts (e.g. after a fetch into a tracking branch)
I have just forgotten about ORIG_HEAD entirely. Oh sure, I know
its there, but its not something I think about using...
--
From: Marko Macek <hidden> Date: 2016-08-11 20:16:37
Shawn Pearce wrote:
Carl Worth [off-list ref] wrote:
quoted
Yes, this was my exact thought when reading what Linus
wrote. ORIG_HEAD might be fine and all, but it pales in functionality
compared to what reflog provides.
I would very much like to see reflog getting first-class citizen
support in git:
1. Be on by default
I agree.
I have:
git repo-config --global core.logAllRefUpdates true
especially since Junio fixed it to only create logs for heads and
not tags. That way its on by default for me. But I think it should
be on by default in the next version of Git.
Why is it not useful for tags for having logs?
I also have a question:
Does git-fsck-objects/prune check the ref logs?
Mark
My real point was/is that usually it's really not the "naming details"
that people _really_ have problems with. The real problems tend to be in
learning a new workflow.
I agree that discussions on naming may cloud the issue, but "learning
the workflow" implies that people should adapt to the limitations of
their tools. That's only a viable stance when the tools are finished
and completely perfect.
Until that time, it would be good goal to remove all idiosyncrasies,
all gratuitious asymetries and needless limitations in the commands of
git, eg.
- clone but not a put-clone,
- pull = merge + fetch, but no command for merge + throw
- clone for getting all branches of a repo, but no command for
updating all branches of a repo.
Of course, when all warts are fixed, backward compatibility will force
us to choose some new names. At that point, a discussion on naming is
in place.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
- git itself has now done it that way for the last 18 months, and the
fact is, the people _complaining_ are a small subset of the people who
actually use git on a daily basis and don't complain.
that's not a good argument; the set of git users is a small subset of
those that looked at git, and dismissed it because they couldn't wrap
their heads around it. It's worth trying to get those on board by
fixing the annoying little issues that have popped up in this thread.
The technical base for GIT is excellent, and the only reason for not
using it is its arcane interface.
A version control system is often only tangentially related to the real
work that needs to be done, so the incentive to learn it well is small,
and a steep learning curve only makes it worse.
FWIW, I regularly mess up with the differences between fetching, pulling
and merging. In particular, having to do a two step process to get
remote changes in,
git pull url-to-server master:master
..error message about not being a fast-forward..
git pull --update-head-ok url-to-server master:master
..still an error message about update not being a fast-forward..
(sigh)
git pull url-to-server master:scrap-branch
git pull . scrap-branch:my-current-branch
(make mental note of deleting scrap-branch)
--
The fact that we can do "git clone" on the _receiving_ side is an
assymmetry, but it's not gratutous: when receiving we don't need any extra
permissions or setup to create a new archive. In contrast, when sending,
you do have to have that "get permission to create new archive" phase.
quoted
- pull = merge + fetch, but no command for merge + throw
Again, this is not gratuitous, and the reason is very similar: when you
pull, you're pulling into something that _you_ control and _you_ have
But "push" and "pull" _fundamentally_ aren't symmetric operations, and you
simply cannot possibly make them symmetric.
Point taken; thank you.
In that case, we're full circle with the command naming issues. Push
and pull are fundamentally asymmetric operations, but then a
consistent UI would dictate that they wouldn't be named symmetrically,
as they are now.
--
From: Jakub Narebski <hidden> Date: 2016-08-11 20:19:45
Michael K. Edwards wrote:
Currently, it looks like "remotes" entries are
created only by "git clone" or by hand. Junio, are there any plans to
manage the contents of "remotes" through the tool instead of by hand?
Don't forget quite new work with managing remotes (and per-branch
configuration) in the config instead of separate remotes/ (or even older
branches/) file
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
From: Michael K. Edwards <hidden> Date: 2016-08-11 20:20:35
I think there's a fundamental assumption built into the design of git
that most programmers accustomed to a corporate environment don't
understand. Namely, that each programmer owns his or her entire
"repository", and can do whatever he or she darn well pleases with it
at any time. Go ahead and create hundreds of transient branches as
part of a scripted "merge complexity metric" calculation. Try three
different refactoring strategies on different branches, abandon two of
them, and prune them months later. And generally use the power of the
SCM to juggle a lot of things at once, because there's no sysadmin
gatekeeper stopping you, and the thing is designed and coded scalably
so it doesn't grind to a halt as soon as everyone has dozens of
private branches.
Even if you do find a way to push git in a direction that it doesn't
scale, it's no one's problem but your own -- people who pull from you
are pulling the _content_ on the branches they care about, not the
structure of your repository.
On 11/16/06, Han-Wen Nienhuys [off-list ref] wrote:
I agree that discussions on naming may cloud the issue, but "learning
the workflow" implies that people should adapt to the limitations of
their tools. That's only a viable stance when the tools are finished
and completely perfect.
Until that time, it would be good goal to remove all idiosyncrasies,
all gratuitious asymetries and needless limitations in the commands of
git, eg.
One person's gratuitous asymmetry is another's minimalism. (If the
symmetric thing doesn't make any sense or can't be implemented
scalably, leave it out.) It is more important that git continue to
work than that it appear symmetric without reference to its function.
- clone but not a put-clone,
What possible use would that be? git is not rsync.
- pull = merge + fetch, but no command for merge + throw
pull = fetch + merge. It is (almost?) always followed by a judgment
call based on the merge results. merge + throw doesn't make any sense
in terms of the job at hand, which is facilitating human judgments
about whether to accept someone else's work into one's working tree.
- clone for getting all branches of a repo, but no command for
updating all branches of a repo.
clone is shorthand for the steps involved in setting up a new
repository with content similar to an existing one. There isn't any
merge involved, and no scope for human judgment, so it's simplest to
clone the whole state of the remote repository (including tags and
branches) and let the user blow away any branches he doesn't need.
But once the clone is done, all of those branches are _truly_ _local_
-- they don't retain any reference to the remote branches, and you can
commit to all of them. The only entry placed in .git/remotes is the
"origin" of the new clone, which is the "master" of the remote
repository. That's for the user's convenience, and is about the only
thing in the new clone that _isn't_ a copy of something in the remote
tree.
So the "update all" process wouldn't look anything like a clone, it
would be a fetch and replay of each remote branch onto the
corresponding local branch. You and Carl seem to want "git clone" not
only to copy the heads of the remote branches but to populate
.git/remotes with trackers for all of those branches, and then to
start each "git update" by polling all of the remote repositories to
see if branches have been created or deleted, then pull every branch
in sight. What do you do when "upstream" creates a branch with the
same name as a local branch you have created? How do you deal with
branch points that don't exist in your repository because you touched
one of the "tracker" branches between pulls?
In short, if you want a local, read-only tracker for a whole remote
repository instead of a branch that's actually published to you (and
maintained accordingly), you might consider s/git/rsync/.
Cheers,
From: Johannes Schindelin <hidden> Date: 2016-08-11 20:21:32
Hi,
On Thu, 16 Nov 2006, Linus Torvalds wrote:
On Fri, 17 Nov 2006, Johannes Schindelin wrote:
quoted
Besides, it is not really a temporary branch. If it was, the pull would
_not_ download all these objects again, would it?
Well, exactly because they are temporary, we can't actually trust the
objects they point to.
Nonono.
We made _sure_ that FETCH_HEAD is only written once _all_ the objects were
received. So, actually, we _can_, and we _should_ trust the objects they
point to!
Or did I miss something?
For example, if you used one of the old-fashioned commit walkers, maybe we
got the initial commit, but we may not have gotten the whole _chain_. See?
Huh? I am quite certain that FETCH_HEAD is not updated in that case. If it
is, that's a bug.
Ciao,
From: Johannes Schindelin <hidden> Date: 2016-08-11 20:21:37
Hi,
On Thu, 16 Nov 2006, Linus Torvalds wrote:
On Thu, 16 Nov 2006, Johannes Schindelin wrote:
quoted
- a terrible UI.
Why? We _do_ have the temporary branch. It's called FETCH_HEAD.
It is a terrible UI, because it was not that obvious to me. And I consider
myself not a git newbie.
Besides, it is not really a temporary branch. If it was, the pull would
_not_ download all these objects again, would it?
quoted
_Also_, git-pull not storing the fetched branches at least temporarily
often annoyed me: the pull did not work, and the SHA1 was so far away I
could not even scroll to it.
Again, why didn't you use FETCH_HEAD?
Because I am a Jar-HEAD?
If the user doesn't give us a head to write to, we clearly MUST NOT write
to any long-term branch. That would be a _horrible_ mistake.
I was _not_ suggesting a long-term branch. Just a way to do-what-i-want
and not waste bandwidth.
And your "solution" is obviously totally unusable. git ABSOLUTELY MUST NOT
overwrite any existing branches unless explicitly told to do so by the
user.
Guess three times why I did not post the patches.
But the real problem is not necessarily the behaviour; it is the obscure
fashion of the behaviour. You may not understand that problem, because you
were there from the beginning. You saw the big-bang and how all the
quarks formed all of a sudden, and how matter and eventually planets
and suns came into being.
But others (me included) were not there. Or they did not really watch. And
now they see all these creatures, and plants, and bacteria, and they do
not understand how these are all connected, because of that. And now they
think "wow that must have been some intelligent design, and really a
miracle, and I cannot understand how it works." But that is not true
(the latter part of course).
There is something to be said about the simplicity of Mercurial. It's
inner workings may suck, but people get easily attracted by it.
I do not claim we should imitate Mercurial, or even hide the index (even
if I sometimes wonder if the index is not just a clever way to accelerate
commits, and nothing more).
So I really don't see your point.
A lot of the complaints seem to not be about the interfaces, but about
people not _understanding_ and knowing what the interfaces do.
But the interfaces should be usable interfaces! They should _explain_ what
they do. Other software does so, it can't be _that_ hard.
git merge "$(git fmt-merge-msg < .git/FETCH_HEAD)" HEAD FETCH_HEAD
I find that quite easy to understand. Why? Because I happen to _know_ the
syntax of -merge and -fmt-merge-msg. For similar reasons I _understand_
why -pull behaves like it does. But others don't; they will shudder and
then run.
Maybe it is not important that -pull fetches all objects all over again.
But it _is_ important to make things like merging branches (local or
remote) trivial. It _is_ important to make the user experience be fun.
Ciao,
Dscho
On Wed, 15 Nov 2006 20:05:27 +0100
Marko Macek [off-list ref] wrote:
I guess this is the reason that the GIT Tutorial for CVS/SVN users is talking about _cogito_ instead.
(which is very confusing for someone coming to _git_ home page, trying to learn git).
IMHO this is really bad. Pasky runs the Git web site and feels
that Cogito comes hand in hand with Git. When I asked him about
it he mentioned that Junio had approved. But it's very confusing
to click a link that purports to show you how to use Git and get
shown a bunch of Cogito stuff.
Git is confusing enough for new users without "Git" and "Cogito"
being mixed without comment on the Git webpage. At the very
least, the links should be changed to "Cogito for CVS/SVN users".
That is an implementation detail that should be easily overcome once the
notion of tracking branch with URL attribute is implemented.
Nope.
I simply don't _have_ those branches.
Why? Because the kernel is _distributed_. There is no central place
(certainly not my repository) that tracks all the possible branches that
might get merged.
In other words, I repeat: in a TRULY DISTRIBUTED ENVIRONMENT it makes more
sense to have a "pull" that fetches and merges, over something that
fetches separately and then merges. Because in a truly distributed
environment, you simply DO NOT HAVE static branches that you can associate
with particular sources.
See?
And the thing is, I think the git design should be geared towards true
distribution. It should NOT be geared toward a fairly static set of
branches that all have a fairly static set of other repositories
associated with them. Can you see the difference?
I'm personally convinced that one of the reasons people tend to use git in
a centralized manner is just a mental disease that has its roots in how
they used _other_ SCM's. I don't want git design to be polluted by such a
centralized notion.
So to repeat: you can always make "pull" boil down to "pull from myself"
(aka just "merge"), but you can _not_ make "fetch + merge" boil down to
"pull" without meking up extra state to track separately. In other words,
"pull" really is the strictly more powerful operation.
I am not really opposed to pull doing a merge. It only should work in
a useful way: ie. only do the merge of updated origin branch when
current branch is master (given "Pull: master:origin").
I absolutely agree.
We should _only_ use the default head when pulling from the default head
("master"). If we don't pull from within the default branch, we should
either require an explicit head _or_ we should require that an explicit
mapping has been set up in .git/config or in .git/remotes/..
So doing a "git pull" from any other branch than "master" should probably
by default say "which branch do you want to pull from today"?
From: Michael K. Edwards <hidden> Date: 2016-08-11 20:25:59
On 11/15/06, Linus Torvalds [off-list ref] wrote:
But once you understand branches, and understand "fetch" (and it really
isn't _that_ complicated: fetch really does exactly what the name says, so
if you understand local branches, you will understand "fetch"), then it's
a much smaller step to explain "pull = fetch + merge".
But I bet people don't teach it that way. They _start_ by teaching "pull".
Right?
"git fetch" is certainly the right thing for the platform integration
role, in which one is trying to maintain a series of integration
branches which track the bleeding edge of some subsystems while
keeping the core stable on each branch. This is not as impossible as
people make it out to be, but there certainly isn't much place for
automatic merges to _persistent_ branches.
It's fundamentally a backporting and cherry-picking effort, and the
git workflow puts it where it belongs: in the local repository, where
_transient_ branches can and should be created and destroyed casually
to track exploratory efforts. These may include automatic merges and
even cruder techniques (git diff, hack on patch, apply patch). Once
you figure out which bits you actually want to backport, you go back
to a fresh branch and cherry-pick the same bits with the tool instead
of manually, so that there is less noise in future merges. When
you've tested a little, you merge this branch to the persistent branch
that other repositories track.
Cheers,
Actually, only a 2 weeks ago, you suggested that I share the website
and main source code for my project in a single repository for reasons
of organization.
In this setup I find it logical to do
git init-db
git pull ..url.. website/master
I don't disagree per se. It should be easy to support, it's just that it's
not traditionally been something we've ever done.
So the way you'd normally set up a single repo that contains multiple
other existing repositories is to basically start with one ("git clone")
You're misunderstanding me: the multi-repo is at git.sv.gnu.org is the
remote one. The example I gave was about locally creating a single
project repo from a remote multiproject repo.
On a tangent: why is there no reverse-clone? I have no shell access
to the machine, so when I created the remote repo, I had to push, and
ended up putting 1.2 Gb data on the server.
<looks at manpage>
is this send-pack? From UI perspective it would be nice if this could
also be done with clone,
git clone . ssh+git://....
And that "git pull" semantic actually means that if you want a _bare_
repository, I think "git --bare init-db" + "git --bare fetch" actually
yes, this works. Two remarks:
* it needs
website/master:master
otherwise you still don't have a branch.
* why are objects downloaded twice? If I do
git --bare fetch git://git.sv.gnu.org/lilypond.git web/master
it downloads stuff, but I don't get a branch. If I then do
git --bare fetch git://git.sv.gnu.org/lilypond.git web/master:master
it downloads the same stuff again.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen