Steven Grimm wrote:
Here's one use case for merge/pull/rebase that is, if not an everyday thing, then at least fairly common in my group: Person B fixes a bug in some code that's causing problems for the code person A is working on. Person A is not at a stopping point in his own work yet, but wants to get the fix.
I'll add that that's also the use case where I want git-pull and git-rebase to merge changes into my uncommitted working copy. It's probably less common in big distributed open-source projects where everyone is working on a logically separate, non-overlapping change to an otherwise stable code base, but in highly collaborative workgroup settings where 5 people are working on the same brand-new feature, it's not at all rare, and in those cases, where people are typically editing the same small set of files, you really do want to update early and often so as to minimize the scope of your merge conflicts and catch any integration problems as early as possible.
In that setting, I'd rather not have to commit before each update since I'd end up with a change history like "update" "update" "update" "implement function foo()" "update" "update" "fix a bug in bar()" etc., even if I use rebase.
Cogito handles this case reasonably well, though it has to play tricks to do it.
-Steve - 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