Re: [PATCH] Fix default pull not to do an unintended Octopus.
- From
- Josef Weidendorfer <josef.weidendorfer@gmx.de>
- Date
- Sep 27, 2005, 14:35 UTC
- 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:
Show 5 quoted lines
> 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.
Show 10 quoted lines
> > 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.
Show 16 quoted lines
> > 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