Matthieu Moy matthieu@grenoble-inp.fr writes:
Stephen Leake stephen_le...@stephe-leake.org writes:
So a message merge complete; you can drop the stash would be the most
git should do.
From the user experience point of view, that would be good. It could
bother some users, but we have
Junio C Hamano gits...@pobox.com writes:
Stephen Leake stephen_le...@stephe-leake.org writes:
Matthieu Moy matthieu@grenoble-inp.fr writes:
li...@haller-berlin.de (Stefan Haller) writes:
Your intention was clearly to drop the stash, it just wasn't dropped
because of the conflict.
Brandon McCaig bamcc...@gmail.com writes:
On Thu, Feb 27, 2014 at 9:57 PM, Stephen Leake
stephen_le...@stephe-leake.org wrote:
You might be adding other files for other reasons. But if you add a file
that does resolve a conflict caused by 'git stash pop', it is not
guessing.
Staging a file
Stephen Leake stephen_le...@stephe-leake.org writes:
So it appears that adding a file _does_ tell git that the conflict is
resolved.
Yes it does. Git _knows_ that you consider the conflict to be resolved.
It cannot know how happy you are with the result.
Similarly, in a conflicted merge, the
Stephen Leake stephen_le...@stephe-leake.org writes:
Brandon McCaig bamcc...@gmail.com writes:
On Thu, Feb 27, 2014 at 9:57 PM, Stephen Leake
stephen_le...@stephe-leake.org wrote:
You might be adding other files for other reasons. But if you add a file
that does resolve a conflict caused by
Matthieu Moy matthieu@grenoble-inp.fr writes:
Stephen Leake stephen_le...@stephe-leake.org writes:
So it appears that adding a file _does_ tell git that the conflict is
resolved.
Yes it does. Git _knows_ that you consider the conflict to be resolved.
It cannot know how happy you are
David Kastrup d...@gnu.org writes:
Stephen Leake stephen_le...@stephe-leake.org writes:
Brandon McCaig bamcc...@gmail.com writes:
On Thu, Feb 27, 2014 at 9:57 PM, Stephen Leake
stephen_le...@stephe-leake.org wrote:
You might be adding other files for other reasons. But if you add a file
Stephen Leake stephen_le...@stephe-leake.org writes:
Matthieu Moy matthieu@grenoble-inp.fr writes:
li...@haller-berlin.de (Stefan Haller) writes:
Your intention was clearly to drop the stash, it just wasn't dropped
because of the conflict. Dropping it automatically once the conflict
is
Stephen Leake stephen_le...@stephe-leake.org writes:
I was not aware that the git system could support more than one version
of a file in one branch.
The index only. The history itself does not.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line
Stephen Leake stephen_le...@stephe-leake.org writes:
So a message merge complete; you can drop the stash would be the most
git should do.
From the user experience point of view, that would be good. It could
bother some users, but we have advice.* to silent this kind of warnings.
From the
Matthieu Moy wrote in message vpqzjlf5q2z@anie.imag.fr:
Maybe status should display a stash count if that count is 0, as
this is part of the state of the repo.
Maybe it would help some users, but not me for example. My main use of
git stash is a safe replacement for git reset --hard:
Junio C Hamano gits...@pobox.com writes:
Stephen Leake stephen_le...@stephe-leake.org writes:
One _could_ argue that stashed changes are what could be reflected
to the working tree and form the source of the latter, but my gut
feeling is that it is a rather weak argument. At that point you
Simon Ruderich si...@ruderich.org writes:
On Mon, Feb 24, 2014 at 05:21:40PM +0100, Matthieu Moy wrote:
One easy thing to do OTOH would be to show a hint at the end of git
stash pop's output, like
I think that's a good idea. It makes it obvious that Git has kept
the stash and that the user
Matthieu Moy matthieu@grenoble-inp.fr writes:
Omar Othman omar.oth...@booking.com writes:
Though I don't know why you think this is important:
Now, the real question is: when would Git stop showing this advice. I
don't see a real way to answer this, and I'd rather avoid doing just a
Matthieu Moy matthieu@grenoble-inp.fr writes:
li...@haller-berlin.de (Stefan Haller) writes:
Your intention was clearly to drop the stash, it just wasn't dropped
because of the conflict. Dropping it automatically once the conflict
is resolved would be nice.
Your intention when you ran
Junio C Hamano gits...@pobox.com writes:
... So resolve the conflicts is assuming the intention of
the user who issued pop too much (let alone manually---it does
not matter how the user resolves conflicts---the only thing we want
to say is Git did all it would and no further automated help
Stephan:
On Thu, Feb 27, 2014 at 9:57 PM, Stephen Leake
stephen_le...@stephe-leake.org wrote:
You might be adding other files for other reasons. But if you add a file
that does resolve a conflict caused by 'git stash pop', it is not
guessing.
Staging a file doesn't tell git that you resolved
Omar Othman omar.oth...@booking.com writes:
Though I don't know why you think this is important:
Now, the real question is: when would Git stop showing this advice. I
don't see a real way to answer this, and I'd rather avoid doing just a
guess.
If it is really annoying for the user, we can
Junio C Hamano gits...@pobox.com wrote:
Stephen Leake stephen_le...@stephe-leake.org writes:
Dropping the stash on a git add operation would be really, really
weird...
Why? That is when the merge conflicts are resolved, which is what
logically indicates that the stash is no longer
li...@haller-berlin.de (Stefan Haller) writes:
Your intention was clearly to drop the stash, it just wasn't dropped
because of the conflict. Dropping it automatically once the conflict
is resolved would be nice.
Your intention when you ran git stash pop, yes. Your intention when
you ran git
On Tue, Feb 25, 2014 at 11:12:10AM -0800, Junio C Hamano wrote:
So, I tend to agree with you, while I do understand where I want to
know about what is in stash is coming from (and that is why we do
have git stash list command).
One thing that would be nice is if there was built-in git stash
Matthieu Moy matthieu@grenoble-inp.fr writes:
Omar Othman omar.oth...@booking.com writes:
Though I don't know why you think this is important:
Now, the real question is: when would Git stop showing this advice. I
don't see a real way to answer this, and I'd rather avoid doing just a
Junio C Hamano gits...@pobox.com writes:
I'd however have to say that even please resolve the conflicts
manually is over-assuming.
I understand your point, but in a short hint message, I still find it
reasonable. Fixing conflicts is the natural way to go after a stash
pop, and the user who do
Matthieu Moy matthieu@grenoble-inp.fr writes:
Junio C Hamano gits...@pobox.com writes:
I'd however have to say that even please resolve the conflicts
manually is over-assuming.
I understand your point, but in a short hint message, I still find it
reasonable. Fixing conflicts is the
Matthieu Moy matthieu@grenoble-inp.fr writes:
Junio C Hamano gits...@pobox.com writes:
I'd however have to say that even please resolve the conflicts
manually is over-assuming.
I understand your point, but in a short hint message, I still find it
reasonable. Fixing conflicts is the
David Kastrup d...@gnu.org writes:
All that verbosity...
$ git stash pop
Auto-merging foo.txt
CONFLICT (content): Merge conflict in foo.txt
Cowardly refusing to drop stash.
$
Actually, modulo Cowardly, that may be the most harmless phrasing,
as apply_stash may try to signal an error for
Junio C Hamano gits...@pobox.com writes:
David Kastrup d...@gnu.org writes:
All that verbosity...
$ git stash pop
Auto-merging foo.txt
CONFLICT (content): Merge conflict in foo.txt
Cowardly refusing to drop stash
$
Actually, modulo Cowardly, that may be the most harmless phrasing,
as
Am 24.02.2014 17:21, schrieb Matthieu Moy:
$ git add foo.txt
$ git status
On branch master
Changes to be committed:
(use git reset HEAD file... to unstage)
modified: foo.txt
Maybe status should display a stash count if that count is 0, as this
is part of the state of the repo.
Holger Hellmuth hellm...@ira.uka.de writes:
Am 24.02.2014 17:21, schrieb Matthieu Moy:
$ git add foo.txt
$ git status
On branch master
Changes to be committed:
(use git reset HEAD file... to unstage)
modified: foo.txt
Maybe status should display a stash count if that count
Well, it's called `git stash` and not `git trash`... :-D
That's your own usage of it, but its main usage is different.
This is not a solution, but it's better than nothing and I second it.
On 25-02-14 13:33, Matthieu Moy wrote:
Holger Hellmuth hellm...@ira.uka.de writes:
Am 24.02.2014
Brandon:
Please note that what I am asking for is not always dropping the stash,
but doing that *only* when the merge conflict is resolved. This is
simply getting the whole command to be consistent. If you do `git stash
pop` and it succeeds, the stash reference is dropped. If you do `git
Omar Othman omar.oth...@booking.com writes:
Brandon:
Please, don't top-post on this list. Look how other people answer to
each other and follow the use.
Please note that what I am asking for is not always dropping the
stash, but doing that *only* when the merge conflict is resolved. This
is
Please note that what I am asking for is not always dropping the
stash, but doing that *only* when the merge conflict is resolved. This
is simply getting the whole command to be consistent. If you do `git
stash pop` and it succeeds, the stash reference is dropped. If you do
git stash pop` and
Omar Othman omar.oth...@booking.com writes:
[omar_othman main (trunk|MERGING*)]$ git add path/to/file.txt
[omar_othman main (trunk*)]$
Note how the status message has changed to show that git is now happy.
It is at that moment that the stash reference should be dropped
Dropping the stash on
Matthieu Moy matthieu@grenoble-inp.fr writes:
Holger Hellmuth hellm...@ira.uka.de writes:
Am 24.02.2014 17:21, schrieb Matthieu Moy:
$ git add foo.txt
$ git status
On branch master
Changes to be committed:
(use git reset HEAD file... to unstage)
modified: foo.txt
Matthieu Moy matthieu@grenoble-inp.fr writes:
Omar Othman omar.oth...@booking.com writes:
[omar_othman main (trunk|MERGING*)]$ git add path/to/file.txt
[omar_othman main (trunk*)]$
Note how the status message has changed to show that git is now happy.
It is at that moment that the
Junio C Hamano gits...@pobox.com writes:
status is about reminding the user what changes are already in the
index (i.e. what you would commit) and what changes are in the
working tree, from which you could further update the index with
(i.e. what you could commit).
I believe status should
Stephen Leake stephen_le...@stephe-leake.org writes:
One _could_ argue that stashed changes are what could be reflected
to the working tree and form the source of the latter, but my gut
feeling is that it is a rather weak argument. At that point you are
talking about what you could
Stephen Leake stephen_le...@stephe-leake.org writes:
Dropping the stash on a git add operation would be really, really
weird...
Why? That is when the merge conflicts are resolved, which is what
logically indicates that the stash is no longer needed,...
Not necessarily. Imagine a case where
On Tue, Feb 25, 2014 at 01:33:56PM +0100, Matthieu Moy wrote:
Holger Hellmuth hellm...@ira.uka.de writes:
Maybe status should display a stash count if that count is 0, as
this is part of the state of the repo.
Maybe it would help some users, but not me for example. My main use of
git
On Mon, Feb 24, 2014 at 05:21:40PM +0100, Matthieu Moy wrote:
One easy thing to do OTOH would be to show a hint at the end of git
stash pop's output, like
I think that's a good idea. It makes it obvious that Git has kept
the stash and that the user should drop it when he's done - if he
wants
[omar_othman main (trunk|MERGING*)]$ git add path/to/file.txt
[omar_othman main (trunk*)]$
Note how the status message has changed to show that git is now happy.
It is at that moment that the stash reference should be dropped
Dropping the stash on a git add operation would be really, really
Am 24.02.2014 17:21, schrieb Matthieu Moy:
$ git add foo.txt
$ git status
On branch master
Changes to be committed:
(use git reset HEAD file... to unstage)
modified: foo.txt
Maybe status should display a stash count if that count is 0, as
this is part of the state of the
Matthieu Moy matthieu@grenoble-inp.fr writes:
Holger Hellmuth hellm...@ira.uka.de writes:
Am 24.02.2014 17:21, schrieb Matthieu Moy:
$ git add foo.txt
$ git status
On branch master
Changes to be committed:
(use git reset HEAD file... to unstage)
modified: foo.txt
Omar:
On Mon, Feb 24, 2014 at 3:32 AM, Omar Othman omar.oth...@booking.com wrote:
In general, whenever something a user should do, git always tells. So, for
example, when things go wrong with a merge, you have the option to abort.
When you are doing a rebase, git tells you to do git commit
Brandon McCaig bamcc...@gmail.com writes:
Unlike a merge, when you pop a stash that history is lost. If you
screw up the merge and the stash is dropped then there's generally no
reliable way to get it back. I think that it's correct behavior for
the stash to not be dropped if the merge
46 matches
Mail list logo
