Re: git pull opinion

[Andreas Ericsson <ae@op5.se>]

Johannes Schindelin wrote:
> Hi,
> 
> On Tue, 6 Nov 2007, Andreas Ericsson wrote:
> 
>> Johannes Schindelin wrote:
>>
>>> On Tue, 6 Nov 2007, Andreas Ericsson wrote:
>>>
>>>> Bill Lear wrote:
>>>>> On Monday, November 5, 2007 at 15:33:31 (-0800) Junio C Hamano writes:
>>>>>> Aghiles <aghilesk@gmail.com> writes:
>>>>>>
>>>>>>> Is there an "easier" way to pull into a dirty directory ? I am
>>>>>>> asking this to make sure I understand the problem and not
>>>>>>> because I find it annoying to type those 4 commands to perform
>>>>>>> a pull (although some of my colleagues do find that annoying :).
>>>>>> You need to switch your mindset from centralized SVN workflow.
>>>>>>
>>>>>> The beauty of distributedness is that it redefines the meaning
>>>>>> of "to commit".  In distributed systems, the act of committing
>>>>>> is purely checkpointing and it is not associated with publishing
>>>>>> the result to others as centralized systems force you to.
>>>>>>
>>>>>> Stop thinking like "I need to integrate the changes from
>>>>>> upstream into my WIP to keep up to date."  You first finish what
>>>>>> you are currently doing, at least to the point that it is
>>>>>> stable, make a commit to mark that state, and then start
>>>>>> thinking about what other people did.  You may most likely do a
>>>>>> "git fetch" followed by "git rebase" to update your WIP on top
>>>>>> of the updated work by others.
>>>>>>
>>>>>> Once you get used to that, you would not have "a dirty
>>>>>> directory" problem.
>>>>> I respectfully beg to differ.  I think it is entirely reasonable, and
>>>>> not a sign of "centralized" mindset, to want to pull changes others
>>>>> have made into your dirty repository with a single command.
>>>>>
>>>> I find it much more convenient to just fetch them. I'd rather see
>>>> git-pull being given a --rebase option (which would ultimately mean
>>>> teaching git-merge about it) to rebase already committed changes on
>>>> top of the newly fetched tracking branch. It's being worked on, but
>>>> rather slowly.
>>> git-pull learning about --rebase does not mean teaching git-merge about it.
>>> See my patch, which you (and others) failed to enthusiastically embrace,
>>> which is the sole reason it is stalled.
>>>
>> I must have missed it. Found the thread now though. Gonna try the patch in
>> production for a while and see how it pans out.
>>
>> I'm curious about this hunk though. It seems unaffiliated with the --rebase
>> option as such, but was still in the patch. Would you care to clarify?
>>
>> @@ -86,7 +95,6 @@ merge_head=$(sed -e '/	not-for-merge	/d' \
>>
>> case "$merge_head" in
>> '')
>> -	curr_branch=$(git symbolic-ref -q HEAD)
>> 	case $? in
>> 	  0) ;;
>> 	  1) echo >&2 "You are not currently on a branch; you must
>> explicitly"
>>
> 
> No, it is not unaffiliated.  If you go back to the patch, you will find 
> that this line was not deleted, but moved to the start of git-rebase.sh.  
> We need to know the branch name to get the config settings, and might just 
> as well reuse the branch name for the merge_head case.
> 

Righto. I should learn to not write emails or read patches before 10am.
Thanks for clarifying.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231