From: Josef Weidendorfer <josef.weidendorfer@gmx.de>
Date: Tue, 27 Sep 2005 14:35:12 GMT
Subject: Re: [PATCH] Fix default pull not to do an unintended Octopus.
Message-ID: <200509271635.12907.Josef.Weidendorfer@gmx.de>
In-Reply-To: <20050927125434.GF30889@pasky.or.cz>

On Tuesday 27 September 2005 14:54, you wrote:
> Yes. I'm actually inclined to keep this setup, simply because it is
>
>   * easy
>   * simple
>   * sufficient in most of the cases

I would almost say: sufficient for all cases.
The .git/remotes stuff is about providing a shortcut for remote
repositories and about defaults for this repository.
I am not really sure this is needed, and this second use of a name
(additionally to head names) can be confusing.

> > 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.
>
> No. If you are in the branches/ playground, please keep it strictly
> one-to-one mapping. That's what makes it easy and simple and that's what
> makes it good.

Ah, no. Any line in a branches/ file is a pure attribute for the given
head, and does not change its 1:1 relationship.

E.g. a branches/master file with

	Push: git:/.../git.git#public-master
	Merge: origin

would specify:
- If the current head is master, a cg-merge will merge with
head origin
- If the current head is master, a cg-push will publish the
local master to the given remote URL

The branches/master does nothing say about the origin branch/head.

> > 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?
>
> Yes.
>
> > 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.
>
> If ever doing that, this should be done at some other place than
> branches/.

Hmm, perhaps. We could go with .git/push-defaults and .git/merge-defaults.
But then, IMHO .git/branches should be renamed to .git/fetch-defaults,
as it holds the remote URL needed for fetching changes.

By creating the needed defaults on a cg-clone, you can get rid of the
above mentioned hardcoded things.

> And I'm sceptical about it anyway. Really, introducing some 
> new configuration mechanism just to tell Cogito what default branch name
> should it pick up when you call fetch/update/merge without a parameter?

It is about storing pull/push remote URLs for a given head.
Ok, in the case "merge", it is about defaults (useful to
get rid of the hardcoding of merging origin into master on a cg-update).

I really think that the "push" URL currently is missing in Cogito.
Pushing the master by using the origin URL works, but I would like to
see this working for arbitrary heads.

By the way, am I correct than cogito currently misses a command to
switch the branch? cg-seek is only for temporal switching. What are
the prefered options? A "cg-seek -f", a "cg-jump" or "cg-switch"?

Josef