From: Junio C Hamano <hidden> Date: 2016-06-15 22:42:15
Junio C Hamano [off-list ref] writes:
Don Zickus [off-list ref] writes:
quoted
I notice if I create a branch (and switch to it) in the linux kernel
off of say version 2.6.14, then later do a git pull, things get ugly.
It seems like all the upstream changes are being merged into the
2.6.14 branch (instead of the latest kernel tag).
Is this a user error because the tool is still fragile?
I do not understand the question.
The user wanted all the good developments from the mainline into
the fork he created starting at 2.6.14, and the tool did what
was asked. Why would you want to forbid that from happening,
and what did you want to happen instead?
Actually I think I do understand the question. You have a clone
of linux-2.6 repository, and your "origin" branch tracks the
bleeding edge from Linus. You also have "myhack" branch that
was forked off from 2.6.14, and wanted to see what new things
Linus has by updating "origin", and perhaps merge those changes
into your "master" which keeps track of your hacks based on
Linus tip, but unfortunately you were on "myhack" branch.
Ouch.
So what you wanted to do was probably:
$ git fetch ;# this updates "origin" to Linus tip
instead of
$ git pull ;# this updates "origin" to Linus tip *and*
# merges that into the current branch
As you may probably know, you can recover by
$ git reset --hard
While I am sympathetic, this "Oops, I said pull when I meant
fetch" sounds remotely similar to "oops, I said 'rm -r' when I
meant to say 'ls -r'". Is it that the tool is too fragile?
From: Don Zickus <hidden> Date: 2016-06-15 22:42:15
While I am sympathetic, this "Oops, I said pull when I meant
fetch" sounds remotely similar to "oops, I said 'rm -r' when I
meant to say 'ls -r'". Is it that the tool is too fragile?
Sorry, wrong choice of words. Didn't mean to imply anything negative.
Though, I am still learning the tool and its features, I do appreciate
your feedback and your last email was correct in understanding the
mess I created. I'll go read up on the differences between 'fetch'
and 'pull'.
Cheers,
Don
From: Carl Baldwin <hidden> Date: 2016-06-15 22:42:15
Hello,
Here are my two cents. I'll try my best to make a case for those poor
souls who get into this sort of mess.
Whenever I give a colleage an introduction to git I emphatically
recommend that they start with using git fetch and git merge
independantly of each other and stay away for git pull at least until
they know what they're doing. This is because I have found that people
are really surprised at what happens when they type git pull until it
really sinks in that 'pull = fetch + merge to current branch, whatever
that may be'.
The difference between the words fetch and pull is much more subtle than
the difference between remove and list which are the basis for the
commands rm and ls. I see nothing in the English dictionary to suggest
that pull means fetch + merge. This is a gitism. Even after reading
documentation clearly and even using git for a while the difference
really takes some time to sink in.
I think a great degree of understanding should be shown toward those who
dig themselves into this kind of thing. I also recommend that some
extra care should be taken in the tutorials and documentation to warn
about this difference up front and possibly suggest avoiding the use of
pull for those new to git.
Carl
PS The issue was exacerbated when cogito and git were inconsistent on
their respective usages of pull and fetch. I think this has gone away,
hasn't it? I haven't used cogito in some time so I really don't know.
On Thu, Dec 15, 2005 at 03:53:38PM -0800, Junio C Hamano wrote:
Junio C Hamano [off-list ref] writes:
quoted
Don Zickus [off-list ref] writes:
quoted
I notice if I create a branch (and switch to it) in the linux kernel
off of say version 2.6.14, then later do a git pull, things get ugly.
It seems like all the upstream changes are being merged into the
2.6.14 branch (instead of the latest kernel tag).
Is this a user error because the tool is still fragile?
I do not understand the question.
The user wanted all the good developments from the mainline into
the fork he created starting at 2.6.14, and the tool did what
was asked. Why would you want to forbid that from happening,
and what did you want to happen instead?
Actually I think I do understand the question. You have a clone
of linux-2.6 repository, and your "origin" branch tracks the
bleeding edge from Linus. You also have "myhack" branch that
was forked off from 2.6.14, and wanted to see what new things
Linus has by updating "origin", and perhaps merge those changes
into your "master" which keeps track of your hacks based on
Linus tip, but unfortunately you were on "myhack" branch.
Ouch.
So what you wanted to do was probably:
$ git fetch ;# this updates "origin" to Linus tip
instead of
$ git pull ;# this updates "origin" to Linus tip *and*
# merges that into the current branch
As you may probably know, you can recover by
$ git reset --hard
While I am sympathetic, this "Oops, I said pull when I meant
fetch" sounds remotely similar to "oops, I said 'rm -r' when I
meant to say 'ls -r'". Is it that the tool is too fragile?
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Junio C Hamano <hidden> Date: 2016-06-15 22:42:15
Don Zickus [off-list ref] writes:
quoted
While I am sympathetic, this "Oops, I said pull when I meant
fetch" sounds remotely similar to "oops, I said 'rm -r' when I
meant to say 'ls -r'". Is it that the tool is too fragile?
Sorry, wrong choice of words. Didn't mean to imply anything negative.
Though, I am still learning the tool and its features, I do appreciate
your feedback and your last email was correct in understanding the
mess I created. I'll go read up on the differences between 'fetch'
and 'pull'.
I too was a bit too defensive, and I agree the tool is prone to
easy errors; the worst part is that there is no "rm -i"
equivalent to be extra careful [*1*]. On the other hand, we
have "git reset" to recover from, so it is not as bad as
a mistake with "rm" ;-).
If for example there were a way to say "this `origin' shortcut
is to be pulled into `master' branch and nothing else", we could
have caught the "git pull" you had trouble with. There was a
discussion on the list in the past to extend remotes/ files to
allow such restriction of the patchflow to be expressed, but
back then I felt the kind of restriction the proposal could
express was too limiting, and the discussion was a bit premature
because we did not have recommended patterns yet.
We might want to revive the discussion post 1.0. Taking the
example of the topic-branch workflow by Tony, the "patch flow"
language needs to be able to express something at least this:
- topic branches -- branched from 'origin' somewhere in the
past; commits accumulated but usually nothing is merged
into them.
- 'test' -- branched from 'origin' somewhere in the past; used
solely to merge topic branches into it and no commits are
made into it directly; branches that are regularly merged
into it are:
- topic branches
- 'origin'
- 'release'
- 'release' -- branched from 'origin' somewhere in the
past; trivial/obviously correct commits are made into it
directly; proven to be good topic branches are merged into it
for consumption by others; branches that are regularly merged
into it are:
- topic branches
- 'origin'
- never 'test'
[Footnote]
*1* IMHO "rm -i" is not that safe, though. If one overuses it,
it trains one's fingers to say "y" without much thinking.
While I am sympathetic, this "Oops, I said pull when I meant
fetch" sounds remotely similar to "oops, I said 'rm -r' when I
meant to say 'ls -r'". Is it that the tool is too fragile?
Didn't bk come with some kind of (one-level) undo pull? It should not
be too hard to create something similar considering that one could
just leave new objects in the db orphaned.
M.