Re: What's cooking in git.git (topics)
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Feb 21, 2008, 10:40 UTC
- Message-ID
- <alpine.LSU.1.00.0802211024200.17164@racer.site>
- In-Reply-To
- <7v8x1fymei.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 20 Feb 2008, Junio C Hamano wrote:
> ---------------------------------------------------------------- > [New Topics] > > * js/branch-track (Tue Feb 19 11:24:38 2008 -0500) 2 commits
Heh, now it gets confusing ;-) Three regular contributors with the same initials? ;-)
Show 6 quoted lines
> * js/merge (Sun Feb 17 19:07:40 2008 +0000) 2 commits > + xdl_merge(): introduce XDL_MERGE_ZEALOUS_ALNUM > + xdl_merge(): make XDL_MERGE_ZEALOUS output simpler > > This makes conflicting merges that have hunks separated by only > a few common lines much easier to read.
The question is: what to do about ALNUM. Use it in merge-recursive? Make it a config variable?
Show 7 quoted lines
> * db/push-single-with-HEAD (Wed Feb 20 12:54:05 2008 -0500) 1 commit > + Resolve value supplied for no-colon push refspecs > > Kills two birds with a commit by (1) fixing "git push $there +HEAD" > to force the single push, and (2) allowing you to set > "remote.$there.push = HEAD" so that "git push $there" will push > only the current branch.
The question is now: should we initialise remote.origin.push to HEAD like you said? And if so, shouldn't we have git-remote's "add" do the same?
Speaking of which, I think it would make sense to teach git-remote's "add" to detect if you are installing a remote "origin" and set up branch.$(git symbolic-ref HEAD).{remote,merge} like clone would. After all, if you are setting up "origin", chances are that you just initialised a remote repository with your current one.
Thoughts?
Show 7 quoted lines
> * js/reflog-delete (Fri Jan 4 19:11:37 2008 -0600) 2 commits > + builtin-reflog.c: fix typo that accesses an unset variable > + Teach "git reflog" a subcommand to delete single entries > > There was a patch that uses this to implement "git-stash drop", > which I didn't queue, as the command name and the UI was > undecided yet. Dscho was in favor of "pop" without "drop".
Maybe it is time to "drop" this topic?
Show 7 quoted lines
> * nd/dashless (Wed Nov 28 23:21:57 2007 +0700) 1 commit > - Move all dashed-form commands to libexecdir > > Scheduled for 1.6.0. I am not sure if we should merge this to > 'next' before 1.5.5. Most active people will be on 'next' and > if we have this there, the resulting 1.5.5 release might end up > having issues that come from differences this one introduces.
I think this is a good plan. Better safe 'n sorry.
Ciao, Dscho