On Wed, Oct 5, 2011 at 9:57 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Jay Soffian <jaysoffian@xxxxxxxxx> writes: >> Now they do what? Either commit --force or create a new branch? >> Wouldn't it have been better to create the new branch before they >> started editing? > > If they are going to commit, and if they knew that they are going to > commit, yes. Committing is obviously the common case for a checked-out branch. > But why do you want to forbid people from just checking things out if they > are not interested in committing? That is where I think you are going > backwards. Because if they do decide to commit, it's now harder for them to do so. It would be great if git could intervene after the checkout, but before they edit any files, so that they don't have uncommitted work. Obviously that's not possible, so git should prevent them from getting to that point. Let's consider the various situations: 1. master is checked out w/edits in workdir1, user wants to work on topic in workdir2. There's nothing to warn about in workdir2 neither at checkout nor commit time. 2. master is checked out w/edits in workdir1, user wants examine unedited master in workdir2 At checkout time in workdir2: My preference: checkout advices user to use --detach or --force. Your preference: checkout is silent. Now user decides they want to commit to master in workdir2 (which is insane, they've got uncommitted changes to it in workdir1). What happens? In my scenario, the commit happens on a detached HEAD. When they eventually switch back to a branch, git tells them how to move their commit to a branch. In your scenario, commit complains. User now has to --force, stash, or create a new branch. It's just seems insane to me putting in obstacles to the user committing their work. That's where I think you are going backwards. You have a use case where using a detached HEAD doesn't work because you've scripted around the same branch multiply checked out. I think that's probably an exceedingly rare use case, and justifies "checkout --force". >> I guess it depends what you mostly use your workdirs for. For me, it's >> to have different branches checked out, not to have the same branch >> checked out in multiple locations. > > Then you wouldn't have any problem if commit refused to make commit on the > branch that is checked out elsewhere, no? Yes, I would, because by that point, I've already made the mistake of checking out the same branch twice. I want git to prevent me from doing that by accident. Because I don't want to ever be in the situation which comes next, which is that I've got uncommitted work for the same branch in two places! > I am not saying we should never have an option to _warn_ checking out the > same branch in multiple places. I am saying it is wrong to forbid doing so > by default. I am not saying we should never have an option to allow checking out the same branch in multiple places. I am saying it is wrong to allow doing so by default. j. -- 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