Theodore Ts'o wrote:
> Right now I do this just by being careful, but if there was an
> automatic safety mechanism, it would save me a bit of work, since
> otherwise I might not catch my mistake until I do the "git push
> publish", at which point I curse and then start consulting the reflog
> to back the state of my tree out, and then reapplying the work I had
> to the right tree.
My scenario is a bit different, and I think this safety feature is
highly overrated. It's not that "I'll never rewind some branches, but
rewind other branches", but rather "I might rewind anything at any
time, but I want immediate information so I can quickly inspect @{1}
to see if that was undesirable". To put it another way, my philosophy
is not "auto-deny unintended changes", but rather "tell me immediately
about undesirable changes". To this effect, my prompt looks like:
artagnon|push-current-head=:~/src/git$
The = indicates that I'm in sync with upstream, and that there's
nothing to push. When I make some changes, that character changes to
>, which means that there are ff changes to push. Finally,
artagnon|push-current-head<>:~/src/git$
has my immediate attention. <> means that I've diverged from
upstream. Since the prompt is present all the time, I catch the
divergence just-in-time. Moreover, I push very frequently resetting
the prompt to = periodically.
So, do you still need this rewinding safety thing?
> So what I do is something like this:
>
> git push publish ; git push repo ; git push code
While we can definitely make the UI better for this (maybe push
--multiple?), there is no fundamental change: we have to re-initialize
all the refspecs, connect to the remote via the transport layer and
prepare a packfile to send. In other words, it's impossible to make
it any faster than what you get with the above.
> where....
>
> [remote "publish"]
> url = ssh://gitolite@xxxxxxxxxxxxx/pub/scm/fs/ext2/e2fsprogs.git
> fetch = +refs/heads/*:refs/heads/*
> push = next
> push = master
> push = maint
> push = debian
> push = +pu
So you're a batched-push person. And the above makes it clear that
you don't want to explicitly differentiate between a push and push -f
(the +pu thing). And this assumes that you never create any new
branches (I branch out all the time), otherwise you'd have rules for
refs/heads/*. Just out of curiosity, do you ever have ref-renaming
requirements (like push = refs/heads/*:refs/heads/tt/*)? We were
discussing that on another thread, but I haven't found an
implementation I'm happy with yet.
--
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