On Oct 25, 2007, at 12:27 PM, Johannes Schindelin wrote:

quoted text
> Hi,
>
> On Thu, 25 Oct 2007, Steffen Prohaska wrote:
>
>> On Oct 25, 2007, at 1:28 AM, Johannes Schindelin wrote:
>>
>>> On Thu, 25 Oct 2007, Steffen Prohaska wrote:
>>>
>>>> On Oct 25, 2007, at 12:14 AM, Johannes Schindelin wrote:

[...]

quoted text
>>>>> But here is a proposal which should make you and your developers
>>>>> happy, _and_ should be even easier to explain:
>>>>>
>>>>> Work with topic branches.  And when you're done, delete them.
>>>>
>>>> Again, if you want to share the topic branch the situation gets  
>>>> more
>>>> complex.
>>>
>>> Hardly so.  In my proposed solution to your problem, there is  
>>> nothing
>>> which prevents you from working off of another branch than "master".
>>
>> Well if you have several local branches checked out that are
>> shared with others you run into the "git push" problem again ...
>> (see below at git push origin master).
>
> Do the same as I, always say "git push origin master" (of course, you
> should exchange "master" with whatever branch you want to push).  Be
> precise.

Well, I'm lazy. git already knows everything. It knows that
the current branch is associated with a specific remote and it
pushes matching branches by default. And I took care to not
pollute the namespace. All my branches are named identical
in all repositories I'm dealing with. It's reasonable to want
"git push" to do the right thing.



quoted text
>>>>> So the beginning of the day could look like this:
>>>>>
>>>>> 	git fetch
>>>>> 	git checkout -b todays-topic origin/master
>>>>>
>>>>> 	[hack hack hack]
>>>>> 	[test test test]
>>>>> 	[debug debug debug]
>>>>> 	[occasionally commit]
>>>>> 	[occasionally git rebase -i origin/master]
>>>>>
>>>>> and the end of the topic
>>>>>
>>>>> 	git branch -M master
>>
>> Isn't this a bit dangerous? It forces to overwrite master no matter
>> what's on it. You don't see diffstats nor a fast forward message that
>> confirms what you're doing.
>
> Yeah, I should have said something like "git branch -m master"
> (implicitely assuming that you have no current "master" branch).
>
>>>>> 	git push origin master
>>
>> I'd like to see "git push" here.
>
> I think it is not asking too much for the user to be a bit more  
> precise.
> If you really do not trust your developers to be capable of that,  
> point
> them to git gui.

Well I was more precise and got lazy over time. Now the most I do
is "git push --dry-run" and if it looks good I do "git push".
Most of the time I just say "git push".

As I pointed out earlier, "git push origin <some-branch>" can create
a new branch on the remote. "git push" never creates a new branch.
I believe "git push" is safer.


quoted text
>>    git branch -m <shared_branch>
>>    git push origin <shared_branch>
>>    git checkout do-not-work-here
>>    git branch -D <shared_branch>
>
> Actually, the last two commands would better be
>
> 	git checkout HEAD^{commit}
> 	git branch -d <shared_branch>

Wow, looks weird (not too me but to someone who doesn't know git).


quoted text
>>> The problem I see here: you know git quite well.  Others don't, and
>>> will be mightily confused why pull updates local branches sometimes,
>>> and sometimes not.
>>
>> But it already happens now. "git pull" sometimes merges a remote  
>> branch
>> (--track) and sometimes it reports an error that is fails to do so
>> (--no-track).
>
> If there really is an inconsistent behaviour, then we'll have to  
> fix that.
> We should not introduce inconsistent behaviour on top of that.

It's not inconsistent. It's an option of a branch. Git supports two
flavours of local branches. Some branches automatically merge and other
don't.

	Steffen
-
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