Theodore Ts'o <ty...@mit.edu> writes: > On Wed, May 22, 2013 at 10:58:49AM -0700, Junio C Hamano wrote: >> Theodore Ts'o <ty...@mit.edu> writes: >> >> > I was actually thinking that it might be interesting to have a >> > branch.<branch>.rewindable, which would change the guilt defaults, and >> > could also key changes in key git behavior which makes it less likely >> > that a user shoots him or herself in the foot --- i.e., give warnings >> > if he or she has modified the branch in such a way that >> > remotes.origin.<branch> is no longer contained within the branch head. >> >> At least "rebase" can pay attention to it and might make the world a >> better place. > > Yeah, rebase was the primary command I was thinking about. The other > one would be "git commit --amend" after the branch had been pushed > out.
It may or may not matter for the kernel folks, but let me pick your brain while we are on this subject. The "upstream" (your remotes.origin.<branch>) is that on top of which you build your work. You clone from there to bootstrap yourself, you add your work (which may include integrating the work of your contributors, if you are a mid-tier maintainer/integrator aka a lieutenant) on top of it, and arrange the result to reach the "upstream" in some way. For the simplest (and still widely used) workflow that employs a central shared repository, the way to make the result to reach the "upstream" is by directly pushing into it yourself. In that sense, the word "upstream" and the traditional behaviour of "git push" that pushes back to the 'origin' (or branch.<branch>.remote) to update your "upstream" (or branch.<branch>.merge at 'origin') both make perfect sense. Also, if you are rebasing, @{u} refers to that place you integrate with, i.e. your "upstream", in the central shared repository workflow. But in a triangular workflow, the way to make the result reach the "upstream" is *not* by pushing there yourself. For developers at the leaf level, it is to push to their own repository (often on GitHub), which is different from where they (initially) clone from in order to bootstrap themselves, and (subsequently) pull from in order to keep them up-to-date. And then they request the published work to be pulled by the "upstream". Even in a triangular workflow, @{u} should still refer to the place you integrate with, i.e. your "upstream", not to the place you push to publish the result of your work. This branch.<branch>.rewindable safety however cannot be tied to @{u}. The bottom boundary you want to be warned when you cross is the change you pushed out to your publishing repository, and it may not have reached remotes.origin.<branch> yet. We will be introducing remote.pushdefault configuration in the upcoming 1.8.3 release, so that you can say: [remote "origin"] url = git://g.k.o/pub/scm/linux/kernel/git/torvalds/linux.git/ fetch = +refs/heads/*:refs/remotes/origin/* [remote "ext4"] url = g.k.o:/pub/scm/linux/kernel/git/tytso/ext4.git/ fetch = +refs/heads/*:refs/remotes/ext4/* [remote] pushdefault = ext4 and hopefully it would let you do this: git checkout master ... after working on it ... git push As remote.pushdefault is set to ext4, without any extra arguments, the result will pushed to the "ext4" remote. If you are using the traditional push.default=matching, it may also try to push out dev, dev-next and other branches you may have in your local repository and at k.org; if you are using push.default=simple or other "single branch" modes like "current", "upstream", etc, it will only push out your current branch (i.e. "master") to "ext4" remote. You may however be using your local "master" branch for your development, and pushing the result out to "dev". With only the remote.pushdefault setting to push to ext4 (instead of origin), you still would have to say git push ext4 master:dev There is another change discussed on the list recently to also let you configure your local "master" branch to update "dev" in your publishing repository. It may go like this: [branch "master"] push = refs/heads/dev In any case, refs/remotes/ext4/dev would be the remote tracking branch (not refs/remotes/origin/anything) that keeps track of what you pushed out there the last time. And that would be what your new safety based on "branch.master.rewindable = no" needs to check against, not "refs/remotes/origin/master" which is your master@{u}. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html