Re: [PATCH] Added guilt.reusebranch configuration option.
- From
Ramkumar Ramachandra <artagnon@gmail.com>
- Date
- May 23, 2013, 09:52 UTC
- Message-ID
- <CALkWK0kyRno4eMYHXC3RkJFCVZ6DJWgFX=pR+WCu8=Gaf9q=Mw@mail.gmail.com>
- In-Reply-To
- <20130523021123.GA23155@thunk.org>
Theodore Ts'o wrote:
Show 6 quoted lines
> 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.
Show 10 quoted lines
> 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.