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? ;-)
> * 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?
> * 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?
> * 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?
> * 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
