Re: git pull opinion

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

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.

Hth,
Dscho