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@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.
Righto. I should learn to not write emails or read patches before 10am.
Thanks for clarifying.
--
Andreas Ericsson andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
-
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
