git pull opinion

Hello,

I am not sure this is the best place to write about this. Anyway,
we just switched a couple of repositories to git (from svn) here
at work and one thing people find annoying is a pull into
a dirty directory. Before the "stash" feature it was even worse
but now we can type:

    git stash
    git pull
    git stash apply

But isn't that something we should be able to specify to the "pull"
command ? Additionally and if I am not mistakn, those commands will
create "dangling" commits and blobs. So one has to execute:

    git prune

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 :).

For now, I am recommanding to my colleagues to commit very often
(even unfinished changes), pull, and then rebase the commits into
a more meaningful commit before pushing. Which seems to be a good
practice anyway,

Thank you for git,

- Aghiles.

ps; if someone is interested to hear what is the general opinion
on switching to git from svn in our company, I could elaborate.

Aghiles wrote:

I am not sure this is the best place to write about this. Anyway,
we just switched a couple of repositories to git (from svn) here
at work and one thing people find annoying is a pull into
a dirty directory. Before the "stash" feature it was even worse
but now we can type:

    git stash
    git pull
    git stash apply

But isn't that something we should be able to specify to the "pull"
command ?

If I remember correctly there is/was some preliminary work (at most 'pu'
stages) about adding --dirty option to git-merge, git-pull and git-rebase.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Aghiles, Mon, Nov 05, 2007 22:52:12 +0100:

ps; if someone is interested to hear what is the general opinion
on switching to git from svn in our company, I could elaborate.

Yes, please. And how did you manage to convince them to switch, if possible:
there are still some suckers here trying to do the same to their colleagues.

On Mon, Nov 05, 2007 at 04:52:12PM -0500, Aghiles [off-list ref] wrote:

    git stash
    git pull
    git stash apply

who will run git stash clear? :)

- VMiklos

Hi,

On Mon, 5 Nov 2007, Jakub Narebski wrote:

Aghiles wrote:

quoted

I am not sure this is the best place to write about this. Anyway,
we just switched a couple of repositories to git (from svn) here
at work and one thing people find annoying is a pull into
a dirty directory. Before the "stash" feature it was even worse
but now we can type:

? ? git stash
? ? git pull
? ? git stash apply

But isn't that something we should be able to specify to the "pull"
command ?

If I remember correctly there is/was some preliminary work (at most 'pu'
stages) about adding --dirty option to git-merge, git-pull and git-rebase.

There was, but AFAICT these are dead now.

The consense was that you are much better off committing first, then 
pulling.  And if the work you are doing really is not committable, but you 
_have_ to pull _now_, you use stash.  Although you are quite likely to 
revert the pull when it succeeds, and _then_ unstash.

Ciao,
Dscho

Hello,

who will run git stash clear? :)

Yes you are right. By the way, in the context of merging into a
dirty tree, "git stash clear" seems to be a dangerous command:
there is a risk of loosing all your changes without a question
asked!

I know unix is a harsh world but ...

- Aghiles.

Hello,

The consense was that you are much better off committing first, then
pulling.  And if the work you are doing really is not committable, but you
_have_ to pull _now_, you use stash.  Although you are quite likely to
revert the pull when it succeeds, and _then_ unstash.

Sorry but I don't really understand why one should "revert the pull" ? Could
elaborate for a newbie ? :)

- Aghiles.

On Nov 6, 2007, at 5:16 AM, Aghiles wrote:

Hello,

quoted

who will run git stash clear? :)

Yes you are right. By the way, in the context of merging into a
dirty tree, "git stash clear" seems to be a dangerous command:
there is a risk of loosing all your changes without a question
asked!

I know unix is a harsh world but ...

Be *very* careful, because it's worse than that.  If you run, say,  
`git stash clean', instead of `clear' (that's the sort of typo that  
quickly slips through), then it will stash all your changes in a new  
stash named "clean".  Once you realize you made a typo, you will most  
probably correct it and run `git stash clear' but...   Oops, you just  
wiped your changes that were in the "clean" stash.
That happened to me and other people I know, so now I'm utterly  
cautious when I start a command with "git stash".

As far as I remember, a patch was proposed to change this mis- 
behavior of "git stash" (one could argue that it's a PEBCAK issue,  
but I really think this command is *way* too dangerous) but I don't  
think it's been accepted at this time.

Cheers,

-- 
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory

Hello,

* Benoit Sigoure wrote on Tue, Nov 06, 2007 at 06:29:58AM CET:

On Nov 6, 2007, at 5:16 AM, Aghiles wrote:

quoted

quoted

who will run git stash clear? :)

Yes you are right. By the way, in the context of merging into a
dirty tree, "git stash clear" seems to be a dangerous command:
there is a risk of loosing all your changes without a question
asked!

I would love it if for once in the git world, there were a pair of
commands that would do the exact opposite of each other and where the
naive newbie (me) would immediately recognize that from their names:
  git stash push
  git stash pop

Both applied in this order should be a no-op on both the working tree,
the index, and also the stash.  There's room for extensions (pop
--keep-stash to not remove the stashed information), explicit naming of
stashes, doing multiple pops at once, and so on.  Please don't add more
of the git-push/git-pull, git-add/git-rm unsymmetrical interfaces.
Even if they're perfectly clear to git intimates, each one of them
takes precious extra time to learn due to this lack of symmetry.

Since I simply don't have the time resources to just implement that,
I'll thank you for your attention and go back to lurking mode now.

Thanks,
Ralf

Hello,

As far as I remember, a patch was proposed to change this mis-
behavior of "git stash" (one could argue that it's a PEBCAK issue,
but I really think this command is *way* too dangerous) but I don't
think it's been accepted at this time.

I think that people will use this a lot with the pull command and some
accidents will happen.  I am of the opinion that the semantics of this
command must be  changed.
Additionally, having "git stash [command]" and "git stash [argument]"
mixed together seems strange. One suggestion would be:

    git stash store/add/create [stash-name]
    git stash apply [stash-name]
    git stash clear <stash-name>  (accepts wildcards but no empty args)
    ...

- Aghiles.

On Tue, Nov 06, 2007 at 05:29:58AM +0000, Benoit Sigoure wrote:

On Nov 6, 2007, at 5:16 AM, Aghiles wrote:

quoted

Hello,

quoted

who will run git stash clear? :)

Yes you are right. By the way, in the context of merging into a
dirty tree, "git stash clear" seems to be a dangerous command:
there is a risk of loosing all your changes without a question
asked!

I know unix is a harsh world but ...

Be *very* careful, because it's worse than that.  If you run, say, `git 
stash clean', instead of `clear' (that's the sort of typo that quickly 
slips through), then it will stash all your changes in a new stash named 
"clean".  Once you realize you made a typo, you will most probably 
correct it and run `git stash clear' but...   Oops, you just wiped your 
changes that were in the "clean" stash.
That happened to me and other people I know, so now I'm utterly cautious 
when I start a command with "git stash".

As far as I remember, a patch was proposed to change this mis-behavior of 
"git stash" (one could argue that it's a PEBCAK issue, but I really think 
this command is *way* too dangerous) but I don't think it's been accepted 
at this time.

  no it's a command issue. git stash <random non command name> should
_NOT_ be an alias to git stash save <random name>. Either the command
should be mandatory _or_ it should be a long option to avoid such kind
of conflicts.

  It's just a bad ui design.

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

Hi,

On Tue, 6 Nov 2007, Ralf Wildenhues wrote:

* Benoit Sigoure wrote on Tue, Nov 06, 2007 at 06:29:58AM CET:

quoted

On Nov 6, 2007, at 5:16 AM, Aghiles wrote:

quoted

quoted

who will run git stash clear? :)

Yes you are right. By the way, in the context of merging into a
dirty tree, "git stash clear" seems to be a dangerous command:
there is a risk of loosing all your changes without a question
asked!

I would love it if for once in the git world, there were a pair of
commands that would do the exact opposite of each other and where the
naive newbie (me) would immediately recognize that from their names:
  git stash push
  git stash pop

Both applied in this order should be a no-op on both the working tree,
the index, and also the stash.  There's room for extensions (pop
--keep-stash to not remove the stashed information), explicit naming of
stashes, doing multiple pops at once, and so on.  Please don't add more
of the git-push/git-pull, git-add/git-rm unsymmetrical interfaces.
Even if they're perfectly clear to git intimates, each one of them
takes precious extra time to learn due to this lack of symmetry.

Since I simply don't have the time resources to just implement that, 
I'll thank you for your attention and go back to lurking mode now.

You might as well be honest, and say that they are not time constraints, 
but lack of motivation. There is -- still! -- the patch "Teach "git 
reflog" a subcommand to delete single entries" in "pu" to delete 
single reflogs (and being in "pu" means it is only a fetch and a 
cherry-pick away).

Implementing that feature would be a piece of cake, but I will not do it, 
since _you_ want it, not _I_.  In spite of that, I implemented that reflog 
deleting, which was the hardest part of the exercise.

So, out, out with you, out of lurking mode!

Ciao,
Dscho

Hi,

On Mon, 5 Nov 2007, Aghiles wrote:

quoted

The consense was that you are much better off committing first, then 
pulling.  And if the work you are doing really is not committable, but 
you _have_ to pull _now_, you use stash.  Although you are quite 
likely to revert the pull when it succeeds, and _then_ unstash.

Sorry but I don't really understand why one should "revert the pull" ? 
Could elaborate for a newbie ? :)

Yes, no problem.

A pull is just a fetch and a merge.  And a merge is a commit with more 
than one parent.  So you can use the command "git reset --hard HEAD^" to 
undo a merge, just as you can undo any other commit.

NOTE: if you pushed that commit (merge or not), do _not_ use reset.  This 
effectively rewrites history, and _will_ upset people pulling from you.  
If you really have to undo a commit you already published, use "git revert 
<commit>".

Hth,
Dscho

Aghiles a écrit :

Hello,

I am not sure this is the best place to write about this. Anyway,
we just switched a couple of repositories to git (from svn) here
at work and one thing people find annoying is a pull into
a dirty directory. Before the "stash" feature it was even worse
but now we can type:

    git stash
    git pull
    git stash apply

But isn't that something we should be able to specify to the "pull"
command ? Additionally and if I am not mistakn, those commands will
create "dangling" commits and blobs. So one has to execute:

    git prune

Is there an "easier" way to pull into a dirty directory ? 

I'm using:

$ git config --global alias.update '!git stash && git pull && git stash
apply'

Then in a git repository just do:

$ git update

ps; if someone is interested to hear what is the general opinion
on switching to git from svn in our company, I could elaborate.

Would be nice to hear about that indeed.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

* Johannes Schindelin wrote on Tue, Nov 06, 2007 at 12:59:07PM CET:

On Tue, 6 Nov 2007, Ralf Wildenhues wrote:

quoted

Since I simply don't have the time resources to just implement that, 
I'll thank you for your attention and go back to lurking mode now.

You might as well be honest, and say that they are not time constraints, 
but lack of motivation.

No.  I will not do it, because the marginal cost of getting to
know not only git but also its source is too high for my precious
time ATM.  Maybe next year.

Will you do it for me if I buy you some beer?  If I promise to
(continue to) proofread git documentation for a couple of months?
If I do more audit of git's shell code, searching for nonportable
constructs?  Or if I promise to try to help you with any autotools
issue you might have?  Or would money be needed?  This:

Implementing that feature would be a piece of cake [...]

doesn't sound like it, but I would understand very well if it
needed that.

Please consider that division of work really can be advantageous
and that not all git users want to be or can be developers at all
times.

Cheers,
Ralf

Complain to STDERR unless 'git stash save' is explicitly used.
This is in preparation for completely disabling the "default save"
behavior of the command in the future.

Signed-off-by: Brian Downing <redacted>
---
 Documentation/git-stash.txt |    9 ++++-----
 git-stash.sh                |    8 +++++++-
 t/t3903-stash.sh            |   14 +++++++++++++-
 3 files changed, 24 insertions(+), 7 deletions(-)

diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index c0147b9..61cf95d 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt

@@ -9,7 +9,7 @@ SYNOPSIS
 --------
 [verse]
 'git-stash' (list | show [<stash>] | apply [<stash>] | clear)
-'git-stash' [save] [message...]
+'git-stash' save [message...]
 
 DESCRIPTION
 -----------

@@ -39,8 +39,7 @@ OPTIONS
 save::
 
 	Save your local modifications to a new 'stash', and run `git-reset
-	--hard` to revert them.  This is the default action when no
-	subcommand is given.
+	--hard` to revert them.
 
 list::
 

@@ -119,7 +118,7 @@ perform a pull, and then unstash, like this:
 $ git pull
 ...
 file foobar not up to date, cannot merge.
-$ git stash
+$ git stash save
 $ git pull
 $ git stash apply
 ----------------------------------------------------------------

@@ -147,7 +146,7 @@ You can use `git-stash` to simplify the above, like this:
 +
 ----------------------------------------------------------------
 ... hack hack hack ...
-$ git stash
+$ git stash save
 $ edit emergency fix
 $ git commit -a -m "Fix in a hurry"
 $ git stash apply

diff --git a/git-stash.sh b/git-stash.sh
index f39bd55..a8b854a 100755
--- a/git-stash.sh
+++ b/git-stash.sh

@@ -1,7 +1,7 @@
 #!/bin/sh
 # Copyright (c) 2007, Nanako Shiraishi
 
-USAGE='[ | list | show | apply | clear]'
+USAGE='[save | list | show | apply | clear]'
 
 SUBDIRECTORY_OK=Yes
 . git-sh-setup

@@ -223,6 +223,12 @@ help | usage)
 	if test $# -gt 0 && test "$1" = save
 	then
 		shift
+	else
+		cat >&2 <<EOF
+'git stash [message...]' is deprecated, please use
+'git stash save [message...]' instead.
+
+EOF
 	fi
 	save_stash "$*" && git-reset --hard
 	;;

diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index 9a9a250..adfac4b 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh

@@ -16,7 +16,7 @@ test_expect_success 'stash some dirty working directory' '
 	git add file &&
 	echo 3 > file &&
 	test_tick &&
-	git stash &&
+	git stash save &&
 	git diff-files --quiet &&
 	git diff-index --cached --quiet HEAD
 '

@@ -73,4 +73,16 @@ test_expect_success 'unstashing in a subdirectory' '
 	git stash apply
 '
 
+test_expect_success 'stash with no args' '
+	echo 7 > file &&
+	test_tick &&
+	git stash
+'
+
+test_expect_success 'stash with bare message' '
+	echo 8 > file &&
+	test_tick &&
+	git stash "a message"
+'
+
 test_done

-- 
1.5.3.5.1547.gf6d81-dirty

Having 'git stash random stuff' actually stash changes is poor
user interface, due to the likelyhood of misspelling another legitimate
argument.  Require an explicit 'save' command instead.

Signed-off-by: Brian Downing <redacted>
---
    This commit can be applied on top of the previous whenever it
    is decided "enough time" has passed for the hard behavior change
    of "git stash" to take place.

 git-stash.sh     |   16 +++++-----------
 t/t3903-stash.sh |    4 ++--
 2 files changed, 7 insertions(+), 13 deletions(-)

diff --git a/git-stash.sh b/git-stash.sh
index a8b854a..e900d40 100755
--- a/git-stash.sh
+++ b/git-stash.sh

@@ -219,17 +219,11 @@ create)
 help | usage)
 	usage
 	;;
-*)
-	if test $# -gt 0 && test "$1" = save
-	then
-		shift
-	else
-		cat >&2 <<EOF
-'git stash [message...]' is deprecated, please use
-'git stash save [message...]' instead.
-
-EOF
-	fi
+save)
+	shift
 	save_stash "$*" && git-reset --hard
 	;;
+*)
+	usage
+	;;
 esac

diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index adfac4b..4896da0 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh

@@ -73,13 +73,13 @@ test_expect_success 'unstashing in a subdirectory' '
 	git stash apply
 '
 
-test_expect_success 'stash with no args' '
+test_expect_failure 'stash with no args' '
 	echo 7 > file &&
 	test_tick &&
 	git stash
 '
 
-test_expect_success 'stash with bare message' '
+test_expect_failure 'stash with bare message' '
 	echo 8 > file &&
 	test_tick &&
 	git stash "a message"

-- 
1.5.3.5.1547.gf6d81-dirty

Hello,

I'm using:

$ git config --global alias.update '!git stash && git pull && git stash apply'

I wonder how this works, if the merge produces conflicts...

Best regards
Uwe

-- 
Uwe Kleine-König

http://www.google.com/search?q=1+year+in+days

Uwe Kleine-König a écrit :

Hello,

quoted

I'm using:

$ git config --global alias.update '!git stash && git pull && git stash apply'

I wonder how this works, if the merge produces conflicts...

If you have conflicts it will not do the "git stash apply" as git pull
will return with an error. So you'll need to fix the conflicts and do
you the final git stash manually.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Brian Downing schrieb:

Complain to STDERR unless 'git stash save' is explicitly used.
This is in preparation for completely disabling the "default save"
behavior of the command in the future.

...
-'git-stash' [save] [message...]
+'git-stash' save [message...]

Can't we have these two?

	git-stash
	git-stash save [message...]

'git stash' without a message as an equivalent of 'git stash save' is still 
very handy.

-- Hannes

El 7/11/2007, a las 9:00, Johannes Sixt escribió:

Brian Downing schrieb:

quoted

Complain to STDERR unless 'git stash save' is explicitly used.
This is in preparation for completely disabling the "default save"
behavior of the command in the future.
...
-'git-stash' [save] [message...]
+'git-stash' save [message...]

Can't we have these two?

	git-stash
	git-stash save [message...]

'git stash' without a message as an equivalent of 'git stash save'  
is still very handy.

Agreed.

Wincent

On Wed, Nov 07, 2007 at 12:26:44AM +0000, Brian Downing wrote:

Complain to STDERR unless 'git stash save' is explicitly used.
This is in preparation for completely disabling the "default save"
behavior of the command in the future.

  No arguments at all should not IMHO be deprecated, it's very useful,
and is not ambiguous. The issue with git stash <random> is that if you
thought you typed a command that doesn't in fact exists, you stash which
is not what you meant _at all_.

  When you type `git stash` you certainly want to stash, and it's what
it does.

Here is how it should work:

git-stash (list | show [<stash>] | apply [<stash>] | clear)
git-stash [save <message>]


-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org