Re: [RTC/PATCH] Add 'update-branch' hook

2014-04-24 Thread Stephen Leake
Felipe Contreras  writes:

>> >> I have a branch which should always be recompiled on update;
>> >> post-update-branch would be a good place for that.
>> >
>> > And why would pre-update-branch not serve that purpose?
>> 
>> Because the code that needs to be compiled is not yet in the workspace
>
> And it won't be in 'post-update-branch' either.

Then you are using a very odd definition of "post update"

>  % git checkout master
>  % git branch feature-a stable
>  <- update-branch hook will be called here
>
> The hook will get 'feature-a' as the first argument, but the code in the
> workspace would correspond to 'master'; the checked out branch (pre or post).

Then the hooks should be called 'pre-branch', 'post-branch'; there is no
"update" involved.

The hook I need is actually "post-merge", since "merge" is the command that
updates the workspace.

Sorry for the noise.
-- 
-- Stephe
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RTC/PATCH] Add 'update-branch' hook

2014-04-23 Thread Stephen Leake
Felipe Contreras  writes:

> Stephen Leake wrote:
>> Felipe Contreras  writes:
>> 
>> > Ilya Bobyr wrote:
>> >> On 4/21/2014 2:17 PM, Felipe Contreras wrote:
>> >> > Ilya Bobyr wrote:
>> >> >
>> >> >> Also, most have names that start with either "pre-" or "post-".
>> >> >> It seems reasonable for both "pre-update-branch" and
>> >> >> "post-update-branch" to exist.
>> >> > I don't see what would be the point in that.
>> >> 
>> >> Do you see the point in the other hooks doing that?
>> >
>> > Yes, there a reason for the existance of those hooks. Now tell me why would
>> > anybody use post-update-branch instead of pre-update-branch?
>> 
>> I have a branch which should always be recompiled on update;
>> post-update-branch would be a good place for that.
>
> And why would pre-update-branch not serve that purpose?

Because the code that needs to be compiled is not yet in the workspace

-- 
-- Stephe
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RTC/PATCH] Add 'update-branch' hook

2014-04-22 Thread Stephen Leake
Felipe Contreras  writes:

> Ilya Bobyr wrote:
>> On 4/21/2014 2:17 PM, Felipe Contreras wrote:
>> > Ilya Bobyr wrote:
>> >
>> >> Also, most have names that start with either "pre-" or "post-".
>> >> It seems reasonable for both "pre-update-branch" and
>> >> "post-update-branch" to exist.
>> > I don't see what would be the point in that.
>> 
>> Do you see the point in the other hooks doing that?
>
> Yes, there a reason for the existance of those hooks. Now tell me why would
> anybody use post-update-branch instead of pre-update-branch?

I have a branch which should always be recompiled on update;
post-update-branch would be a good place for that.

-- 
-- Stephe
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: emacs buffer names

2014-04-02 Thread Stephen Leake
Duy Nguyen  writes:

> The --daemon part is probably not worth mentioning because I always
> have one emacs window open. The problem is switch-buffer based on file
> name can be confusing ("git.c" and "git.c<2>", which belongs to which
> checkout?). I ended up modifying files in the wrong checkout all the
> time.

(setq uniquify-buffer-name-style (quote post-forward-angle-brackets) nil 
(uniquify))

This puts enough of the directory name in the buffer name to make the
buffer names unique; very helpful!

-- 
-- Stephe
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RFC 0/3] Make git more user-friendly during a merge conflict

2014-03-01 Thread Stephen Leake
Matthieu Moy  writes:

> $ git status
> On branch master
> nothing to commit, working directory clean
> $

ok, you've lost your conflict resolutions.

>> In fact, it now seems that 'git reset --mixed' is always the same as
>> 'git reset --merge'. So I must be missing something!
>
> "git reset --merge" is an alias for "git merge --abort" (IIRC, it's
> actually the other way around). Essentially, it reverts, or tries to
> revert everything (worktree and index) as it was before the merge. That
> includes throwing away conflict resolution.

Ok.

> Now, I do agree that the documentation of "git reset" is terrible, 

Ok, good.

So is this a sufficient bug report to request that the documentation be
fixed? (I obviously don't know enough to even think about submitting a
patch).

-- 
-- Stephe
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RFC 0/3] Make git more user-friendly during a merge conflict

2014-03-01 Thread Stephen Leake
David Kastrup  writes:

> Stephen Leake  writes:
>
>> David Kastrup  writes:
>>
>>> Stephen Leake  writes:
>>>
>>>> David Kastrup  writes:
>>>>
>>>>> "do the right thing" commands also tend to do the wrong thing
>>>>> occasionally with potentially disastrous results when they are used
>>>>> in scripts where the followup actions rely on the actual result.
>>>>
>>>> That is bad, and should not be allowed. On the other hand, I have yet
>>>> to see an actual use case of bad behavior in this discussion.
>>>
>>> Huh.
>>>
>>> <http://permalink.gmane.org/gmane.comp.version-control.git/242744>
>>
>> That's about backward incompatibility, which is bad, but not what I was
>> talking about above.
>
> No, it isn't.  I quote:
>
> I sometimes run "git reset" during a merge to only reset the index
> and then examine the changes introduced by the merge. With your
> changes, someone doing so would abort the merge and discard the
> merge resolution.  I very rarely do this, but even rarely, I
> wouldn't like Git to start droping data silently for me ;-).
>
> You should not make statements like "I have yet to see an actual use
> case of bad behavior in this discussion" when you actually mean "I have
> not yet seen anything I would be interested in doing myself".

Clearly I misunderstood your point. Merely repeating the same statement
that I misunderstood, and adding a misunderstanding of what I said, is
not helpful.

So let me see if I can expand on your use case:

- you do 'git merge', which results in conflicts

- you edit some workspace files to resolve some of those conflicts 

(I added this step later, since it was implied but not explicit)

- you do 'git reset', intending 'git reset --mixed' (because that is the
  current default)

Actually, I can't find a precise definition of 'git reset'. Here is
the synopsis from the man page for 'git-reset' (from git 1.7.9):

   git reset [-q] [] [--] ...
   git reset (--patch | -p) [] [--] [...]
   git reset (--soft | --mixed | --hard | --merge | --keep) [-q] []

In 'git reset', there is no path, so it must be the second or third
form. But those _require_ one of the -- options. So 'git reset' is
illegal. Clearly something is wrong here; apparently the third line
should be:

   git reset [--soft | --mixed | --hard | --merge | --keep] [-q] []

with '--mixed' as the default, as is stated later. (perhaps the
original intent was to not have a default for the third form, but
that got changed sometime?).

This command "resets the index" but not the working tree. I'm not
clear what "reset the index" means here; does it mean "remove all
entries from the index", or "reset the index to some previous
state"? In other man pages, "reset" can have either meaning
depending on context.

- then you "examine changes introduced by the merge". I don't know what
  this means in detail. 

Before resetting the index, you could diff a workspace file against
either HEAD or index. Now you can only diff against HEAD, so I don't
understand why you wanted to reset the index. That's not relevant to
this use case; I'll just accept that resetting the index is a useful
thing to do here. But I would like to understand why.

- with the "do the right thing" patch, 'git reset' does 'git reset
  --merge' instead

That "Resets the index and updates the files in the working tree
that are different between  and HEAD". 

"" in this case defaults to HEAD, so the working tree is
not changed.

So as I understand it, this does _not_ lose your conflict resolutions.

In fact, it now seems that 'git reset --mixed' is always the same as
'git reset --merge'. So I must be missing something!

-- 
-- Stephe
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: `git stash pop` UX Problem

2014-03-01 Thread Stephen Leake
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 would be nice.
>>>
>>> Your intention when you ran "git stash pop", yes. Your intention when
>>> you ran "git add", I call that guessing.
>>
>> 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.
>
> The only thing you know for sure is that the user has consumed _one_
> part of the stashed change, no?  What if the stash had changes for
> more than one path?

Count the unmerged paths in the index; when the count is zero, all
conflicts are resolved.

paths in the stash that had no conflicts are already in the index.

So _if_ there is nothing going on except finishing the stash pop, an
unmerged path count of zero means you are done with the stash, and it
can be dropped.

> At the time of "git add $path", can you reliably tell if the
> conflict to the $path the user is resolving came from a previous
> "git stash pop", not from any other mergy operations, e.g. "git
> stash apply" or "git apply -3"?

This is the real problem. I can impose a rule on my team of "don't do
more than one merge at a time" by implementing that in the front-end,
but git can't assume that.

-- 
-- Stephe
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: `git stash pop` UX Problem

2014-03-01 Thread Stephen Leake
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.
>
> 
>
> So, I wouldn't object, but I don't think the implementation cost is
> worth the benefit.

Ok, that makes sense.

-- 
-- Stephe
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: `git stash pop` UX Problem

2014-02-28 Thread Stephen Leake
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
>>>> guessing.
>>>
>>> Staging a file doesn't tell git that you resolved a conflict. Git will
>>> happily accept a blob full of conflict markers. Git doesn't know the
>>> difference. Git expects the user to know what is right. The user has
>>> the freedom to manipulate the index as they see fit, which means both
>>> adding and removing from it anytime they wish.
>>
>> But git has a notion of "unresolved conflict".
>
> Not really.  It has a notion of "unmerged path".
>
> 

> The index contains the unmerged versions of the file.  Possibly also the
> version with conflict markers, but it's been too long since I last
> checked.

Paraphrasing, is this correct? 

"the index contains both versions of the unmerged file; any file
 with more than one version in the index is unmerged".

So what 'git add' does in this case is replace both versions of the file
in the index with a new version.

I was not aware that the git system could support more than one version
of a file in one branch. That makes it more like monotone :).

> If you apply a stash with unmerged paths to a worktree/index, possibly
> containing unmerged paths of its own, possibly getting new unmerged
> paths by failing to apply the stash, you get unmerged paths from several
> different unresolved conflicts.

Yes; doing too many things at once is a bad idea. But that should never
cause git to lose data or do something wrong.

At the same time, it seems all unmerged paths result from unresolved
merge conflicts, so the two notions are equivalent for git?

> Git has no idea about the history of unmerged paths.  So having "git
> add" modify the operation of "git reset" whenever "git add" overwrites
> an unmerged path in the index could lead to quite funny results.

Ok; I'll take that as describing a large class of "bad thing" use cases.

-- 
-- Stephe
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: `git stash pop` UX Problem

2014-02-28 Thread Stephen Leake
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 merge, the last "git add" does not trigger a
> commit silently. And a silent commit would be much less serious than a
> silent data drop.

Ok, I see your point now.

So a message "merge complete; you can drop the stash" would be the most
git should do.

-- 
-- Stephe
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RFC 0/3] Make git more user-friendly during a merge conflict

2014-02-28 Thread Stephen Leake
David Kastrup  writes:

> Stephen Leake  writes:
>
>> David Kastrup  writes:
>>
>>> "do the right thing" commands also tend to do the wrong thing
>>> occasionally with potentially disastrous results when they are used
>>> in scripts where the followup actions rely on the actual result.
>>
>> That is bad, and should not be allowed. On the other hand, I have yet
>> to see an actual use case of bad behavior in this discussion.
>
> Huh.
>
> <http://permalink.gmane.org/gmane.comp.version-control.git/242744>

That's about backward incompatibility, which is bad, but not what I was
talking about above.

Specifically, the proposed change is:

'git reset' will have different default actions depending on context:

- if a merge is not in progress, it will do 'git reset --mixed'

- if a merge is in progress, it will do 'git reset --merge'

Is there a use case where this will do the wrong thing?

Of course, I fully understand that not being able to come up with a
"wrong thing" use case is not the same as proving it cannot happen,
especially for a system as complex as git.

So it would be ok to say "we don't do that so we are not exposed to
unintended consequences".

But "wrong thing" use cases are more convincing :).

-- 
-- Stephe
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


git reset returns unwanted failure status

2014-02-28 Thread Stephen Leake
The use case:

I'm doing a 'git stash pop'; it had conflicts. At this point, 'git status' 
shows:

# On branch master
# Changes to be committed:
#   (use "git reset HEAD ..." to unstage)
#
#   modified:   Target.java
#
# Unmerged paths:
#   (use "git reset HEAD ..." to unstage)
#   (use "git add/rm ..." as appropriate to mark resolution)
#
#   both modified:  DriveByInches.java
#
# Changes not staged for commit:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
#   modified:   CommandBasedAutonomous.java
#
# Untracked files:
#   (use "git add ..." to include in what will be committed)
#
#   AerialAssist2014/src/org/usfirst/frc1939/AerialAssist2014/Autonomous/

As part of the conflict resolution, I decide to unstage Target.java:

stephe@takver$ git reset Target.java
Unstaged changes after reset:
M   CommandBasedAutonomous.java
U   DriveByInches.java
M   Target.java
stephe@takver$ echo $?
1


The issue is the error status and the messages about other files.

If I had not specified a path to 'git reset', the error status would
make sense; those files were not reset. However, since the file I
specified was reset, there should be no error.

Similarly, if I specify no path to a git command, I expect warning
messages about files in the workspace that might need attention.
However, if I do specify a path, I expect warning messages about files
in that path only.

This can be stated more concisely if the default path is considered to be
"*" (and recursive); don't error if the operation succeeded for all
files in the path; don't warn about files not in the path.

-- 
-- Stephe
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: `git stash pop` UX Problem

2014-02-28 Thread Stephen Leake
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 conflict. Git will
> happily accept a blob full of conflict markers. Git doesn't know the
> difference. Git expects the user to know what is right. The user has
> the freedom to manipulate the index as they see fit, which means both
> adding and removing from it anytime they wish.

But git has a notion of "unresolved conflict". For example, when I have
conflicts from a 'git stash pop', 'git status' shows:

stephe@takver$ git status
# On branch master
# Unmerged paths:
#   (use "git reset HEAD ..." to unstage)
#   (use "git add/rm ..." as appropriate to mark resolution)
#
#   both modified:  CommandBasedAutonomous.java
#   both modified:  DriveByInches.java
#
# ...

How does it know those files are "unmerged"? I'm guessing it has
recorded the fact that they had conflicts. Where does it record that?

In fact, at this point, I have edited CommandBasedAutonomous.java to
resolve the conflicts. But git apparently doesn't know that.

So I do 'git add CommandBasedAutonomous.java', then 'git status':

stephe@takver$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD ..." to unstage)
#
#   modified:   
AerialAssist2014/src/org/usfirst/frc1939/AerialAssist2014/commands/CommandBasedAutonomous.java
#
# Unmerged paths:
#   (use "git reset HEAD ..." to unstage)
#   (use "git add/rm ..." as appropriate to mark resolution)
#
#   both modified:  
AerialAssist2014/src/org/usfirst/frc1939/AerialAssist2014/commands/DriveByInches.java

And git thinks that file is now "merged".

So it appears that adding a file _does_ tell git that the conflict is
resolved.

Or am I still missing something?


>> So "git add" and "git stash *" are lower level tools; to get the effect
>> we are asking for, we should use a front-end (which is why I'm writing
>> one for Emacs :).
>
> You *can* use a front end, but I would argue that you shouldn't
> necessarily. Most third-party front ends only serve to confuse users.
> In general, they only cause problems and encourage ignorance.

Won't happen here; I'm writing it. It may confuse other people, but
not me :).

> Git is a very pure system.

Hmm. We'll have to disagree on that. git gives the impression of having
grown organically for quite a while, and therefore suffers from changing
and competing design paradigms and conflicting requirements due to
preserving backward compatiblity.

monotone is much cleaner, since it has had very few design paradigm
changes, and they were implemented cleanly, without preserving backward
compatibility. monotone is not as flexible as git, but what I've seen so
far could be added to monotone (I don't think it ever will be; monotone
is dying as a project).

We are probably using different definitions of "pure" here.

> It is up to the user to learn how to assemble those tools for
> good (and many front ends exist to help; sometimes arguably too many
> as it is, such as git-pull(1) for example).

Yes. Which is why we are discussing how much help git should be while
still learning the rules.

>  This isn't a case of the API being wrong. This is a case of PEBKAC,
> IMO.

(wikipedia to the rescue; PEBKAC = "operator error")

Yes, I'm not using it correctly, because I don't understand it yet.
That's the definition of "newbie".

> Dropping the stash after adding all changes to the index after a
> failed pop is not universal.

Not universal, but it appears to be very common; it is certainly what I
expect, as a newbie. So it could be the default as long as there is a
configuration option to have it not do that.

I _did_ "RTFM" (specifically the man page on 'git stash', and before
that the git book at http://git-scm.com/documentation (which did not
mention stash)); it did not explain the full cycle of how to resolve
conflicts after stash pop.

Perhaps there is a different manual that I could read instead?

In particular, one that explains what "unmerged paths" means in the 'git
status' output? The 'git-status' man page does not do that.

--
-- Stephe
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RFC 0/3] Make git more user-friendly during a merge conflict

2014-02-28 Thread Stephen Leake
David Kastrup  writes:

> Stephen Leake  writes:
>
>> I like commands that "do the right thing". So no, this would not be
>> confusing.
>
> I _hate_ commands that think they know better than to do what they are
> told.  In particular when doing destructive things.  And just because
> _you_ like them does not mean they are not confusing.

Ok, I should have said "not confusing for me".

People differ.

> In the long run, it is much more confusing if you come to rely on some
> commands doing "the right thing" while in other cases, the actually
> written thing is done.

There should always be the option of telling git exactly what to do. In
my emacs front end, the command that "does the right thing" is _called_
"do-the-right-thing". All of the other commands do exactly as told.

In this case, it is only "git reset" that would do the right thing,
since you did _not_ tell it specifically what to do.

Relying on a default is always problematic, in my experience; I much
prefer "no default" to "a default that people voted on 10 years ago, and
now we are stuck with it".

> "do the right thing" commands also tend to do the wrong thing
> occasionally with potentially disastrous results when they are used in
> scripts where the followup actions rely on the actual result.

That is bad, and should not be allowed. On the other hand, I have yet to
see an actual use case of bad behavior in this discussion.

-- 
-- Stephe
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Branch Name Case Sensitivity

2014-02-28 Thread Stephen Leake
Karsten Blees  writes:

> If I understand the issue correctly, the problem is that packed-refs
> are always case-sensitive, even if core.ignorecase=true. 

Perhaps that could be changed? if core.ignorecase=true, packed-refs
should be compared with case-insensitive string compares.

-- 
-- Stephe
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RFC 0/3] Make git more user-friendly during a merge conflict

2014-02-28 Thread Stephen Leake
Jonathan Nieder  writes:

> Hi,
>
> Andrew Wong wrote:
>
>> The first two patches are just about rewording a message, and adding messages
>> to tell users to use "git merge --abort" to abort a merge.
>
> Sounds like a good idea.  I look forward to reading the patches.
>
>> We could stop here and hope that the users would read the messages, but I 
>> think
>> git could be a bit more user-friendly. The last patch might be a bit more
>> controversial. It changes the default behavior of "git reset" to default to
>> "git reset --merge" during a merge conflict. I imagine that's what the user
>> would want most of the time, and not "git reset --mixed".
>
> I don't think that's a good idea.  I'm not sure what new users would
> expect; 

As a newbie, I would like to know how to abort the merge, so I like this
message. 

> in any case, making the command context-dependent just makes
> the learning process harder imho.  

I like commands that "do the right thing". So no, this would not be
confusing. 

> And for experienced users, this would be a bad regression.

Backward incompatibility is a real concern.

It might be best if "git reset" (with _no_ option) be made to error out,
so all users have to specify what they want.

The transition process Junio proposed sounds good to me.

-- 
-- Stephe
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: `git stash pop` UX Problem

2014-02-27 Thread Stephen Leake
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
> resolving is availble, but "manually" is not quite the word).

+1

> "The stash was not dropped" is the most important thing in your
> additional text.  How about rephrasing like this?
>
> $ git stash pop
> Auto-merging foo.txt
> CONFLICT (content): Merge conflict in foo.txt
>
> The stashed change could not be replayed cleanly, leaving
> conflicts in the working tree. The stash was not dropped in case
> you need it again.
>
> After you are done with the stash, you may want to "git stash
> drop" to discard it.

+1

-- 
-- Stephe
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: `git stash pop` UX Problem

2014-02-27 Thread Stephen Leake
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", yes. Your intention when
> you ran "git add", I call that guessing.

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.

> The condition for dropping the stash should be more "conflits
> resolutions are done AND the user is happy with it". Otherwise, if you
> mess up your conflict resolution, and notice it after running "git add",
> then you're screwed because Git just happily discarded your important
> data. The point of keeping the stash is to leave it up to the user to
> decide between "I'm happy, I can drop" or "I'm not, I should re-apply",
> and Git cannot tell which is which.

Yes, that makes sense.

> Hinting the user to run "stash pop" would be more acceptable, but
> talking about "git stash" in "git add"'s code is somehow a dependency
> order violation (stash is normally implemented on top of Git's basic
> features, not the other way around). Does not seem serious from at first
> from the user point of view, but this pushes the codebase one step in
> the direction of an unmaintainable mess.

Also makes sense.

So "git add" and "git stash *" are lower level tools; to get the effect
we are asking for, we should use a front-end (which is why I'm writing
one for Emacs :).

-- 
-- Stephe
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: `git stash pop` UX Problem

2014-02-27 Thread Stephen Leake
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 user, we can just have a
>> configuration parameter to switch this message on/off.
>
> Just saying "You have X stash" is OK to me as long as there is an option
> to deactivate it.

+1

> Hinting "You should now run "git stash drop"." OTOH is far more dangerous
> if guessed wrong. Keeping a stash active when you don't need it does no
> real harm, but droping one you actually needed is data loss.

I agree giving possibly incorrect advice is bad.

Can you construct a use case where git will give incorrect advice? 

I don't know git well enough to do that, nor to assert that it will never
happen. 

I think we need a more concrete proposal to move this forward.

-- 
-- Stephe
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: `git stash pop` UX Problem

2014-02-27 Thread Stephen Leake
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 drop it when he's done - if he
> wants to.

+1

This does not mean I don't _also_ think 'git add' dropping the stash
when the last conflict is resolved is a good idea. If that is
implemented, 'stash pop' might have to mention that effect as well; that
does make things more complicated.

-- 
-- Stephe
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: `git stash pop` UX Problem

2014-02-27 Thread Stephen Leake
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 potentially change in the working tree,
>>
>> No, I saved things in the stash on purpose. For example, I had changes
>> that were not ready to commit, but I wanted to do a merge from upstream.
>
> I often save things by running "git diff >P.diff" on purpose.

Ok. How is that better than 'git stash save'?

> Should "git status" read these patches and tell me what paths I
> could change in the working tree by applying it?  

No, 'git stash save' appears to be the method git provides to do this,
so it is the only one that git needs to support.

(The content of 'P.diff' already tells you what paths are modified, as
does 'git stash show')

But I am new to git, so I could just be missing the point.

>Where does it end?

Where we agree it ends :).

>> There are workflows where the stash is not important; provide an option
>> to 'git status' that means "ignore stash". 
>
> How is that different to tell those who want to know what are in the
> stash to type "git stash list" when they want to learn that
> information?

You are correct, this is a question of style. The question is:

Which style is best for git, considering the needs of newbies and
seasoned users?

As a newbie, I find these things confusing:

- the stash status is not displayed by 'git status'

- 'git add' does not report that all pending merge conflicts are now
resolved.

I'm sure I will discover other confusing things in the future :).


I am a seasoned user of CM systems in general; in all cases, I have
customized an Emacs front-end to do _exactly_ what I want, rather than
relying on the command line tools directly. So I have a rather extreme
perspective on this :). I do rely on the command line tools while
learning a new CM system.

In general, I expect seasoned users to be more accepting of the need to
provide additional options to customize the tools to their workflow.

-- 
-- Stephe
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: `git stash pop` UX Problem

2014-02-25 Thread Stephen Leake
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 everything git knows about the current
workspace in a resonably concise way. That includes the stash.

> 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 working tree,

No, I saved things in the stash on purpose. For example, I had changes
that were not ready to commit, but I wanted to do a merge from upstream.

There are workflows where the stash is not important; provide an option
to 'git status' that means "ignore stash". 

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

My Emacs front end currently checks both 'git status' and 'git stash
list' to build "the status of the current workspace".

-- 
-- Stephe
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: `git stash pop` UX Problem

2014-02-25 Thread Stephen Leake
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
>
> 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, _if_ the merge
conflicts are related to the stash, which is true in this use case.

There are other uses for 'git add' that don't indicate that; we'd have
to be very careful to not throw away the stash at the wrong time.

>> (or the user (somehow) is notified to do that herself if desired),
>> because this means that the popping operation has succeeded.
>
> But how would you expect to "be notified"?

When 'git add' checks to see if all merge conflicts are now resolved,
and those merge conflicts were related to the stash, it can either pop
the stash, or issue a message telling the user it is now safe to do so.
We would need a config setting to indicate which to do.

Maybe that check is hard to do in general?

-- 
-- Stephe
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Determining update/merge/current state of a workspace

2014-02-02 Thread Stephen Leake
I'm working on the DVC Emacs front-end for git
(http://www.emacswiki.org/emacs/DistributedVersionControl), adding
features similar to the ones I added for monotone
(http://www.monotone.ca). I'm used to monotone and new to git, so this
may seem like an odd workflow.

I always do 'fetch' and 'merge' separately, never 'pull'. So after a
'fetch', the DVC Emacs front end must determine what needs to happen
next. I think there are three cases:

1) 'fetch' did not retrieve any revisions from remote; the last local
   commit is the head of the branch.

The workspace is up to date (it may need to be comitted).

2) 'fetch' retrieved revisions, and there were no local commits since
   the previous fetch.

The last fetch is the head of the branch; if not equal to HEAD, the
workspace needs to be updated (via 'merge').

3) fetch retrieved revisions, and there were local commits since
   the previous fetch.

   There are two heads for the branch (the two described above), they
   need to be merged, then the workspace updated.

I'm not sure how 'git fetch' handles case 3); I have not tested that
case yet.

The question I have is:

What git queries can I run to determine which of the three states the
current workspace is in?

'rev-parse HEAD' gives the last workspace commit.

'rev-parse refs/remotes//' gives the head of the branch
in the remote repository as of the most recent fetch.

But to distinguish among the cases, I need to determine if one of these
two revs is a child of the other or not. I don't see a git query to
determine that directly.

I could try parsing a 'log' output; I have not investigated that.

This is easy in monotone; there is a command 'mtn heads' that gives this
result directly (it returns either one or two revs), and another command
'mtn automate toposort' that orders revs topologically (by parent/child
relationships).

-- 
-- Stephe
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: aborted 'git fetch' leaves workspace unusable

2014-01-02 Thread Stephen Leake
Junio C Hamano  writes:

> stephen_le...@stephe-leake.org writes:
>
>> However, in this case, even running the fetch was a mistake; I would
>> have prefered that it leave FETCH_HEAD in its previous state.
>
> I think the clearing of leftover FETCH_HEAD is one of the early
> things "git fetch" does, unless "--append" is in effect.  I haven't
> looked at the code for a long time, but it may be possible to move
> the logic of doing so around so that this clearing is done as lazily
> as possible.
>
> I however suspect that such a change may have fallouts on other
> people who are writing tools like yours; they may be depending on
> seeing FETCH_HEAD cleared after a failed fetch, and be surprised to
> see a stale contents after they (attempt to) run "git fetch" in it.
>
> So it is not so clear if it is a good thing to change the behaviour
> of "git fetch" not to touch FETCH_HEAD upon a failure.

Ok; backwards compatibility is important.

Perhaps FETCH_HEAD could be copied to FETCH_HEAD_prev or some such, to
allow recovering in an error case?

-- 
-- Stephe
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html