Steffen Prohaska <prohaska@xxxxxx> writes: > On Nov 1, 2007, at 9:18 PM, Junio C Hamano wrote: > >> The context of this "forced" is that you say (in the following >> paragraph) the user's main objective was to "push", but I do not >> think "to push" is ever the main objective. > > Right. I should probably describe a bit more of the context. Boring ;-) > We have a shared branch for a group of developer who are located > ... > In this setting a user really want to push. Because only then > the code will be tested and available for all others. ... Pretty much expected, sane, and unsurprising. Then you are in the first category I quoted, and... >> - If it is to give integrated result for others to work further >> on, then you need to resolve before being able to achieve >> that goal. There is no escaping from it. ... it still holds that what the developer wants to do is not just "to push", but "to push after making sure what he is going to push is in a good enough shape to be pushed". Your _workflow_ is forcing to integrate right away before pushing; don't blame git for this. >> - On the other hand, if it is to show what you did as early as >> possible in a working shape, and if the updated shared >> repository has changes from somebody else that conflicts you, >> in a CVS/SVN style shared workflow, there is no way for you >> to show what you did in isolation. If you try to follow that >> model in git and insist pushing to the same branch, then you >> are forced to resolve first. >> >> But you do not have to. You could push out to another new >> branch, and say "Here is how you could do it, although this >> is based on an older codebase and conflicts with what >> recently happened to the tip". You could even ask other >> party whose changes conflict with yours to help with the >> merge by saying "I pushed it out, you are more familiar with >> that area of the code and with your changes near the tip of >> the trunk, so could you merge it and push out the result?" > > ... I know we could use git to establish a more complex workflow > that would give better guarantees on the published branches. Don't get me wrong. You do not always have to use the "push to a side branch and ask for help from others", but git opens the door for you to do so more conveniently, rather than strictly sticking to the CVS workflow. I re-quoted the whole "On the other hand" part because I think this is something not often done by people with CVS background --- with CVS you can do exactly the same thing but it is too cumbersome and people don't do so in practice. With git, such an interaction is not just possible but is a very natural thing to do. Your more advanced people can be the first ones to employ this "new communication medium" to help work better among them. You do not have to force the "side communication" as an official part of workflow to the whole group. SCM is just a tool to help developer communication. Use it wisely. > We haven't figured out much more of our workflow. The first > milestone is to migrate from CVS to git continuing to use a > CVS-style workflow. I think that is an interesting admission. As somebody else on the thread already said, if you are sticking to CVS workflow, there are things that can and cannot be naturally done with git. Don't break git when you hit the situation in the latter category without understanding how the world works. > error: remote 'refs/heads/master' is ahead of local 'refs/heads/ > master'. Use --verbose for more details. I'd rather have "Read section XXX of the user's guide". - 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
