On Tue, Dec 02, 2008 at 10:55:34AM -0500, Jason Riedy wrote:
> Ah, ok, thanks! Issuing a warning makes sense. I'm not sure if
> denying such a push by default does...
I don't know if Junio has made a decision on whether or when the default
should be flipped to 'deny'.
> > Doing git push $remote HEAD:branch-that-is-checked-out
> > has _never_ worked without further action on $remote. Now we're warning
> > about it.
>
> It works just fine. I suspect we have different definitions of
> "works".
Fair enough. To be more precise: such a push has always resulted in a
state on the remote end that the user must be aware of when making
further commits, and the result of _not_ being aware and blindly running
"git commit" is to accidentally revert all of the pushed changes. And
even if one _is_ aware, sorting out any existing changes in the index
from pushed changes can be difficult.
So yes, there are workflows that can legitimately make use of a push to
the current branch. But it is still a dangerous operation for a large
number of users (I would argue the majority, but I don't have actual
numbers) that we have seen numerous complaints about.
> To me, that push updates the branch's reference. The working
> copy and index now may be out of sync, but neither the working
> copy nor the index is the branch's reference. Trying to commit
> from the index correctly refuses. The warning is a nice
How is committing from the index refused? Try this:
mkdir parent &&
(cd parent &&
git init &&
echo content >file &&
git add file &&
git commit -m one) &&
git clone parent child &&
(cd child &&
echo changes >>file &&
git commit -a -m two &&
git push) &&
(cd parent &&
git commit -m oops &&
git show
)
You will find that you have just reverted the changes from 'two' with
'oops'.
Committing straight from the working tree (via "git commit <path>" or
"git commit -a") has the same problem.
> (And in context: I used to update the IEEE754 group's web site by
> a git push to the checked-out master, with a hook to reset
> everything. Worked just fine (and very quickly) until they shut
> off shell access. There was no need for an extra branch on the
> server side.)
Follow the earlier parts of the thread and you will see that is one of
the sane workflows that has been mentioned. You are aware of the lack of
sync (and you have a hook to address it) and you don't plan on having
any local changes (so sorting them out is easy -- you just "git reset
--hard" to take the pushed content).
> I'll try to find time when I encounter another. I'm pretty sure
> that switching to denying pushes to checked-out branches is the
> first one that *really* will make me change how I work.
It shouldn't make you change how you work. At most, it will break an
existing setup until you set receive.denycurrentbranch to false (again,
if and when the default value changes). You can prepare for any such
change now by pre-emptively setting the config value.
-Peff
--
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
