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@xxxxxxxxx> 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 - 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
