El 3/10/2007, a las 10:57, Miles Bader escribió:While much of this debate can be shortcircuited simply by making the behaviour configurable, I would like to take you up on the point that you raise here. If we're going to talk about what kind of system Git is then consider this: - it's inherently distributed and this design actively encourages users to treat their local repositories as sandboxes where things are tried out, perfected, and then pushed out into the public via one means or another - it's built from the ground up to be good at branching and merging; this, combined with my previous point, means that users are likely to have multiple heads and often some of them will be "works in progress" that aren't yet ready for publication So it's in that light I see accidentally pushing more than you thought you would as "dangerous"; when you make this mistake you're basically making stuff available that's not yet ready for consumption, and by its nature this mistake is basically irreversible: you can't really "unpush" what you pushed, you can only push out additional amendments which correct it. So, in this light, when you say: I don't know how much it has to do with mental models. I think in this case it's a bit simpler than that where you make the mistake once or twice and very quickly learn that "git push" means "push what's in my repo", not "push only what's on my current branch". It's a *very* easy lesson to learn if you get burnt and hardly requires any adjustments to ones "mental model". I personally would be in favour of changing the default because I tend to work on a particular branch at a time and then want to push *that* out -- generally I'm thinking about one general area or one task at a time, and that means one branch at a time; I almost never think along the lines of getting all my branches into shape at once and then pushing them out in a batch. I think this is more likely to be a common pattern, although obviously that remains speculation at this point. Changing the default would be great for people like me; by not having to pass additional parameters to git-push I save some keystrokes. If I ever want to push everything an "--all" switch would do the job. But if people prefer to keep the old default then there'll be .gitconfig for people like me. In any case I think more people need to speak up on the topic so that we can find out what most people really think about changing the default. Cheers, Wincent - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
| Linus Torvalds | Re: [REPORT] cfs-v4 vs sd-0.44 |
| Mariusz Kozlowski | [PATCH 02] kmalloc + memset conversion to kzalloc |
| Andi Kleen | [PATCH] [16/22] x86: Move swsusp __pa() dependent code to arch portion |
| Vegard Nossum | [RFC][PATCH] bitfields API |
git: | |
| Carl Worth | [PATCH] commit: Steer new users toward "git commit -a" rather than update-index |
| Wincent Colaiuta | Re: [ANNOUNCE] GIT 1.5.4 |
| Junio C Hamano | Re: Decompression speed: zip vs lzo |
| Nicolas Pitre | Re: cloning the kernel - why long time in "Resolving 313037 deltas" |
| Alexey Suslikov | OT: OpenBSD on Asus eeePC |
| Bertram Scharpf | First install: Grub doesn't find partitions |
| GVG GVG | ssh_exchange_identification: Connection closed by remote host |
| bsd_news | LC_COLLATE and PostgreSQL |
| David Miller | [PATCH]: Fix networking scatterlist regressions. |
| Indan Zupancic | Re: Realtek 8111C transmit timed out |
| Ilpo Järvinen | [RFC PATCH 6/8] [NET]: uninline skb_trim, de-bloats |
| Patrick McHardy | Re: [NETFILTER]: Introduce nf_inet_address |
