Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
- From
Andreas Ericsson <ae@op5.se>
- Date
- Nov 2, 2007, 10:03 UTC
- Message-ID
- <472AF5F8.40208@op5.se>
- In-Reply-To
- <3550D197-CA8C-4B06-9A95-3C7F18EBEFA7@zib.de>
Steffen Prohaska wrote:
Show 18 quoted lines
> > 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.
Show 5 quoted lines
> > 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".
Show 12 quoted lines
>> >> 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.
Show 7 quoted lines
> 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 ;-)
Show 15 quoted lines
> > >>> 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