It seems that not many things need breaking, but we will break some.
Here are the ones that needed discussion and were discussed that I am
aware of, with my comments (which shouldn't be read as final decision).
The next step will be to design the migration path, and execution.
* "git branch --set-upstream <name>" should not be about setting the
upstream of <name> to the current branch.
From: Jay Soffian <jaysoffian@xxxxxxxxx>
Date: Tue, 1 Feb 2011 01:57:03 -0500
Message-ID: <AANLkTinUn2SMijphe3EmPMVOOwBjPB5ffFwwqZVxQmW0@xxxxxxxxxxxxxx>
-- summary --
The current behaviour is misdesigned. It should be setting the upstream
of the current branch to <name>.
-- comments --
I agree.
* "git push" default semantics will be "upstream" (renamed from
"tracking"), not "matching".
From: Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx>
Date: Mon, 14 Feb 2011 22:57:24 +0100
Message-ID: <vpqr5bath2z.fsf@xxxxxxxxxxxxxx>
-- comments --
Ok.
* "git merge" without "what to merge" default to @{upstream}
From: Junio C Hamano <gitster@xxxxxxxxx>
Date: Mon, 31 Jan 2011 12:50:30 -0800
Message-ID: <7vzkqg4x2h.fsf_-_@xxxxxxxxxxxxxxxxxxxxxxxx>
-- summary --
Instead of failing, "git merge" to behave more in line with "git pull".
-- comments --
I think this makes sense.
* Unify pathspec semantics
From: Junio C Hamano <gitster@xxxxxxxxx>
Date: Mon, 31 Jan 2011 09:07:14 -0800
Message-ID: <7voc6x57el.fsf_-_@xxxxxxxxxxxxxxxxxxxxxxxx>
-- summary --
Some commands and operations understand leading-path-components but not
globs, while many others do. This inconsistency leads to some surprises.
Make everybody understand globs.
-- comments --
This is already underway, I think.
* Making more operations full-tree by default.
From: Jeff King <peff@xxxxxxxx>
Date: Wed, 9 Feb 2011 18:46:21 -0500
Subject: Re: "git add -u" broken in git 1.7.4?
Message-ID: <20110209234621.GA12575@xxxxxxxxxxxxxxxxxxxxx>
-- summary --
These two commands currently affect only paths within the current
working directory when run from a subdirectory without a pathspec:
. "add -u"
. "add -A"
Make them to add everything in the working tree, from the root level,
even when they are run from a subdirectory.
The following are left as exceptions, keeping the current behaviour to
work within the current directory given no pathspecs:
. "grep"
. "archive"
. "clean"
Plumbing like these are also left as exceptions.
. "ls-files"
. "ls-tree"
-- comments --
As long as transition plan is made carefully, I think this is fine.
* Extend "separate remote" to tags and notes.
From: Johan Herland <johan@xxxxxxxxxxx>
Date: Mon, 07 Feb 2011 04:35:31 +0100
Message-ID: <201102070435.31674.johan@xxxxxxxxxxx>
-- summary --
Instead of using refs/remotes/origin/$branch to store copies of
branches, which has two downsides:
- HEAD as the "primary branch pointer" and as a branch name could
collide;
- tags are forced into a single global namespace.
Use refs/remotes/origin/{HEAD,heads/$branch,tags/$tag} to track what
we copy from a remote in separate namespaces.
-- comments --
Making this coexist with repositories created before 1.8.0 might be
tricky, but otherwise this is fine.
* "git checkout refs/heads/<name>" checks out <name> branch.
From: Martin von Zweigbergk <martin.von.zweigbergk@xxxxxxxxx>
Date: Mon, 7 Feb 2011 06:01:51 -0500 (EST)
Message-ID: <alpine.DEB.1.10.1102062234010.3788@debian>
-- summary --
In addition to "git checkout <name>" that names an existing branch,
special case "git checkout refs/heads/<name>" to check the branch out,
instead of detaching HEAD at the tip of the branch. If you want to
detach at a specific commit and wanted to disambiguate <name> that is
both a branch and another ref by checking out refs/heads/<name>, your
workflow will be broken by this change, but you can still say
refs/heads/<name>^0 to work it around.
-- comments --
I do not think this backward incompatible breakage would seriously
hurt in practice, and if people see newbies are hurt by getting a
detached HEAD when they check out refs/heads/<name>, this proposal
might be an improvement, but I have a feeling that this may be trying
to solve a wrong problem.
Why are these people _tempted_ to type refs/heads/ explicitly? It
could be our tutorial or documentation. That might be the thing to
fix.
* "git fetch $from $branch..." to update tracking branches
From: Thomas Rast <trast@xxxxxxxxxxxxxxx>
Date: Mon, 31 Jan 2011 22:44:09 +0100
Message-ID: <201101312244.10047.trast@xxxxxxxxxxxxxxx>
-- summary --
Traditionally, giving explicit refspecs from the command line was a way
to disable the tracking copy specified with "remote.<name>.fetch"
configuration. A good workflow should however not rely on such a
"pretending that a bad update on the other side did not happen".
Always update tracking branches we observed with "git fetch".
-- comments --
I think this makes sense.
* Moving files around in the source tree, thinning the top-level.
From: Nicolas Pitre <nico@xxxxxxxxxxx>
Date: Mon, 31 Jan 2011 15:28:37 -0500 (EST)
Message-ID: <alpine.LFD.2.00.1101311459000.8580@xxxxxxxxxxx>
-- summary --
well not concrete enough concensus to summarize other than "too many
files at the top is considered ugly".
-- comments --
I am not tempted to do the heavy-lifting myself; as long as the
resulting tree looks sane, I won't object ;-)
--
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