Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref

[Andreas Ericsson <ae@op5.se>]

Steffen Prohaska wrote:
> 
> On Nov 1, 2007, at 10:11 AM, Andreas Ericsson wrote:
> 
>>
>> It's easier to bisect. If git bisect lands you on a merge-commit,
>> you need to start a new bisect for each of the parents included
>> in the merge. Hopefully the nature of the merge gives a clue so
>> the user can make an educated guess as to which parent introduced
>> the bogus commit, but for an "evil octopus" (unusual) or if the
>> merge had conflicts which were resolved in a buggy way (not
>> exactly uncommon), it can be quite a hassle to get things right.
>> With a mostly linear history, this problem goes away.
> 
> This is really an interesting point. I did not start to use
> git bisect regularly. But I certainly plan to do so in the future.
> 
> Couldn't bisect learn to better cope with non-linear history?
> 

Perhaps it could, but it's far from trivial. I started hacking on
a wrapper for git-bisect which would do just that, but gave up
rather quickly as the book-keeping required to remember each and
every parent-point tried just got out of hand, and it *still*
wouldn't run in full automatic. It broke down because I also
wanted merges on non-first-line parents to be delved into. If
that didn't happen, I wouldn't *know* the bisect would run fine
without me watching it, so then it was as useless as if I'd have
had to sit there the entire time anyway.


> 
> BTW, what do you thing about the proposal to add branch.$name.push [1]?
> 
> [1] http://marc.info/?l=git&m=119384331712996&w=2
> 

I'm not so sure about it. I rather liked the "don't warn if local is
strict subset of remote" thing though. I teach our devs to just
ignore that warning, but with the same leaden feeling in my stomach
that someone, sometime, is going to get bit by it. It's worked so
far though, perhaps because our update-hook contains a check meaning
I'm the only one allowed to do "git-push --force".

>>
>> Except that it doesn't work unless you either detach the HEAD
>> (which prints a big fat ugly message) or give it -D to force
>> it, which I really, really don't recommend. We use git because
>> I'm pretty confident in its capabilities of never ever losing
>> anything. Using the seemingly harmless -D switch to git-branch
>> puts us at risk of wiping history quite without noticing.
> 
> I don't like -D either. I liked the idea mentioned recently
> to check -d against the remotes. If a remote tracking branch
> has the history it should be considered fully merged.
> 

Yes. Since remote branches are considered when prune'ing anyway,
and the git-branch -d warning is there to make sure we don't
accidentally lose any tip pointers, it should be safe to use
*all* "named" refs when checking for git-branch -d's sake (that
is, everything under refs/{heads,remotes,tags}/**/*).

> Another idea may be to distinguish between detached head and
> checkout of remote tracking branch. Maybe we could do some
> useful things if get knew that the user is 'on a remote tracking
> branch'. Committing could be forbidden.

Committing nearly *has* to be forbidden.

> A suggestion would be
> printed instead to use "git checkout -b something", which could act
> as if the remote branch was mentioned on the command line.
> 
> Something like that would be needed before I'd seriously
> suggest to delete local branches after you finished your work.
> 

Yup. I'll never suggest using "git branch -D" to my co-workers. Sooner
or later there'll be cries of anguish echoing throughout the office
when that happens ;-)

> 
> 
>>> Independently of what the best practice is, leaving the local
>>> work branch there shouldn't do any harm because I'm sure that
>>> some devs will forget to clean up, independently of what I tell
>>> them.
>>
>> I wholeheartedly agree with this one.
> 
> So I think we need to resolve this first.
> 
> Do you already have post-checkout script that makes useful
> suggestions.  I remember you mentioned something like that
> during the 200-local-branches discussion.
> 

No. Junio suggested I'd implement it as a post-checkout hook, but it
would only save me one command and could cause confusion as diff
output would change depending on whether one has checked out the
one branch or another prior to running git diff, so I decided against
it.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231