Re: What's cooking in git.git (topics)
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Feb 21, 2008, 16:47 UTC
- Message-ID
- <7vejb6uuhp.fsf@gitster.siamese.dyndns.org>
- In-Reply-To
- <alpine.LSU.1.00.0802211024200.17164@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 9 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?
I'd say we'll leave it as is for now and use it everywhere later after making sure things work out Ok.
Show 10 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?
Perhaps we do not do anything further for now, other than telling shared repository people to put it in their config and see how well the behaviour matches their expectation. Protocol extensions to let clone notice what the other end is can come later (and we would need to do that anyway to set up HEAD symref as well). The same mechanism would be used in "git remote add", and at that point clone could be implemented as "init/remote add/fetch/checkout".
Show 9 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?
I've been waiting for somebody to come up with a clean "pop", as it probably is easy enough and would be an itch people other than you and me can scratch.