Re: [PATCH] Fix default pull not to do an unintended Octopus.

On Tuesday 27 September 2005 09:38, Junio C Hamano wrote:

Hmm... What is the "intuitive" thing a user would expect when looking at a remotes file? It looks like including lists of default heads which are used for git commands when no further head is specified, i.e. which are automatically appended to the command line.

E.g. with .git/remotes/remoterep looking like

	URL: ...
	Pull: local1:remote1 local2:remote2
	Push: local3:remote3 local4:remote4

a
	git push remoterep

expands to (AFAIK)

	git push remoterep local3:remote3 local4:remote4

So for
	git pull remoterep

the expected command seems to be

	git pull local1:remote1 local2:remote2

and of course this does an octopus merge at the end. It may be a strange thing to do, but if the user does *not* want to do octopus merges, he probably only will give one default head in the Pull line of the remotes file.

So I would not change the current behavior.

It seems better to me to support an additional "Fetch:" line. IMHO, a "Merge:" lines does not make sense, as "git merge" has nothing to do with remote repositories at all [I just looked up the man page of git-merge, and confusingly it talks about "remotes", which are in fact local heads to be merged].

Like Pasky, I am not really comfortable with this remotes stuff. AFAIK, it was introduced to shorten some command line by providing defaults (to be used by the "GIT core porcelain"). But I still have to provide the remote shortcut on the command line.

As Cogito does, I expect the porcelain to store the mapping of a local head to a remote head, automatically using the right remote repository.

I want to type "git fetch maint" to get the maintanance branch of git, and not specify an additionally introduced arbitrary short name for the remote git repo (which is used quite less often than my head names: heads appear in gitk, I switch among heads...). And using the same name for a remote shortcut and a local head can confuse people.

So IMHO default actions should be stored for branches, not for shortcuts of remote positions. The branches stuff matches this better, as one file in branches/ corresponds exactly to one head with the same name, and specifies the attributes "remote repository" and "remote head".

This also shortens command lines much better then the remotes stuff, as you implicity specify a default head: The one you are on.

Perhaps we should have extended the branches file to allow different remote reps and heads depending on the command (fetch/pull/merge/push). A "URL:" is not needed, as you probably like to have different repos for pull and push. And in contrast to the remotes stuff above, a "Merge:" line makes quite sense here: When on "mybranch", a merge should default to merging the heads specified on the Merge line in branches/mybranch.

When cloning a remote head, Cogito creates a local "origin" head and corresponding mapping in branches/origin. Afterwards, it automatically generates a new local branch "master", which branches of at the origin. Further "cg-updates" (=git fetch+merge) fetch origin, and merge origin into master. I assume that this currently is hardcoded in scripts? Shouldn't there be created a branches/master, specifying that a default merge should happen with "origin"? This way, an "cg-update" would look into "branches/master" on the "Merge:" line. It sees that "origin" is bound to a remote head, and thus, does a fetch before merging.

Opinions?

Josef