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@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
-
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
