Thread (5 messages) flat view 5 messages, 3 authors, 2016-06-15

Re: [PATCH] Added guilt.reusebranch configuration option.

From: Ramkumar Ramachandra <hidden>
Date: 2016-06-15 22:57:25

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@ra.kernel.org/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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help