Re: warning merge message
- From
- Josef Weidendorfer <josef.weidendorfer@gmx.de>
- Date
- Dec 23, 2006, 00:05 UTC
- Message-ID
- <200612230105.01408.Josef.Weidendorfer@gmx.de>
- In-Reply-To
- <7vy7ozv8lz.fsf@assigned-by-dhcp.cox.net>
On Saturday 23 December 2006 00:00, Junio C Hamano wrote:
Show 13 quoted lines
> Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes: > > > In a previous discussion, you talked about switching to > > the new behavior (ie. getting rid of this "first set of > > branches" rule) when there is at least one branch.*.merge > > setting in the config file. > > > > Unfortunately I can not see an easy way to check this with > > repo-config, as there is no wildcard support for keys > > (Ok, I can do a list of keys and grep). > > I think --get-regexp is what you want -- see my "patch for > discussion".
I see. I just read the thread.
The git mailing list is already quite high volume ;-) Around 150+ new postings a day. I think I first should browse through any new threads before answering any mail.
Show 5 quoted lines
> > I think it is better to provide an option > > "pull.do-not-follow-the-first-set-of-branches-rule". > > And we should make this the default after init-db or clone. > > Yes, but the problem is that old timers do make new clones.
Yes, they do. But this is not breaking existing repositories.
If you collect such incompatibilities for the 1.5.0 release notes and provide the workaround ("remove that pull.do-not ..." option) to get back the old behavior, it should be fine.
I can imagine that we want to add branch.*.remote/merge lines with "git checkout -b XXX remotes/YYY". Of course this should only be done if the pull.do-not is set. Relying on existance branch.*.merge lines seems fragile for me.
What about putting this option into the config template instead of setting it in clone? If somebody always wants the old behavior, he should provide a template with this option not set.
> pull.i-like-the-first-set-of-branches in ~/.gitconfig is the > only thing I can think of but that is too ugly and is already on > the slippery slope of user.expert configuration which I do not > think we want.
I agree.
Josef