Junio C Hamano writes:
> Stephen Leake writes:
>
>> Matthieu Moy 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
Matthieu Moy writes:
> Stephen Leake 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.
>
>
>
>
Stephen Leake 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 implementation point of view,
Stephen Leake 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 "unsubscribe git" in
the bod
Stephen Leake writes:
> Matthieu Moy 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 intentio
David Kastrup writes:
> Stephen Leake writes:
>
>> Brandon McCaig writes:
>>
>>> On Thu, Feb 27, 2014 at 9:57 PM, Stephen Leake
>>> 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
g
Matthieu Moy writes:
> Stephen Leake 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 merg
Stephen Leake writes:
> Brandon McCaig writes:
>
>> On Thu, Feb 27, 2014 at 9:57 PM, Stephen Leake
>> 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 does
Stephen Leake 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 last "git add" does not trigg
Brandon McCaig writes:
> On Thu, Feb 27, 2014 at 9:57 PM, Stephen Leake
> 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 a c
Stephan:
On Thu, Feb 27, 2014 at 9:57 PM, Stephen Leake
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 a conflict. Git will
happily
Junio C Hamano 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 in
> reso
Matthieu Moy 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 "git stash pop", ye
Matthieu Moy writes:
> Omar Othman 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
Simon Ruderich 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 should dr
Junio C Hamano writes:
> Stephen Leake 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
Matthieu Moy wrote in message :
>> 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": when I want to
> disc
Junio C Hamano writes:
> David Kastrup 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_sta
David Kastrup 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 reaso
Matthieu Moy writes:
> Junio C Hamano 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
Matthieu Moy writes:
> Junio C Hamano 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
Junio C Hamano 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 not want to
Matthieu Moy writes:
> Omar Othman 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
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 s
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 "
Junio C Hamano wrote:
> Stephen Leake 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.
Omar Othman 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 just have a
> con
Matthieu Moy writes:
Holger Hellmuth 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 ..." to unstage)
modified: foo.txt
Maybe status should display a stash count if that coun
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 ..." 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.
[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
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
On Tue, Feb 25, 2014 at 01:33:56PM +0100, Matthieu Moy wrote:
> Holger Hellmuth 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 stash" is a s
Stephen Leake 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 you used stash to qui
Stephen Leake 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 potentially change in the workin
Junio C Hamano 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 tell me ever
Matthieu Moy writes:
> Omar Othman 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
>
> Droppi
Matthieu Moy writes:
> Holger Hellmuth 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 ..." to unstage)
>>>
>>> modified: foo.txt
>>
>> Maybe status should disp
Omar Othman 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 a "git add" operat
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 it
Omar Othman 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 simply getting the
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
stas
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 writes:
Am 24.02.2014 17:21, schrieb Matthieu M
Holger Hellmuth 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 ..." to unstage)
>>
>> modified: foo.txt
>
> Maybe status should display a stash count if that count is >
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 ..." 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.
Brandon McCaig 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 conflicts.
Agreed.
Omar:
On Mon, Feb 24, 2014 at 3:32 AM, Omar Othman 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 --amend, and
> then gi
Hi there,
I'm fairly new to git and I wanted to ask about a certain behavior that
I want to fix myself (if you agree with me that it is a misbehavior)...
since I've never contributed to open source and it'll be an important
step for me to start and get something done.
In general, whenever so
Hi there,
I'm fairly new to git and I wanted to ask about a certain behavior
that I want to fix myself (if you agree with me that it is a
misbehavior)... since I've never contributed to open source and it'll
be an important step for me to start and get something done.
In general, whenever somethi
48 matches
Mail list logo
