On Wed, 15 Nov 2006, Carl Worth wrote:
>
> 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.
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html