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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]