Re: aborted 'git fetch' leaves workspace unusable

2014-01-02 Thread Stephen Leake
Junio C Hamano gits...@pobox.com 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

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'

Re: `git stash pop` UX Problem

2014-02-25 Thread Stephen Leake
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

Re: `git stash pop` UX Problem

2014-02-25 Thread Stephen Leake
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

Re: `git stash pop` UX Problem

2014-02-27 Thread Stephen Leake
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

Re: `git stash pop` UX Problem

2014-02-27 Thread Stephen Leake
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

Re: `git stash pop` UX Problem

2014-02-27 Thread Stephen Leake
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

Re: `git stash pop` UX Problem

2014-02-27 Thread Stephen Leake
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

Re: `git stash pop` UX Problem

2014-02-27 Thread Stephen Leake
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

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

2014-02-28 Thread Stephen Leake
Jonathan Nieder jrnie...@gmail.com 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

Re: Branch Name Case Sensitivity

2014-02-28 Thread Stephen Leake
Karsten Blees karsten.bl...@gmail.com 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

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

2014-02-28 Thread Stephen Leake
David Kastrup d...@gnu.org writes: Stephen Leake stephen_le...@stephe-leake.org 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

Re: `git stash pop` UX Problem

2014-02-28 Thread Stephen Leake
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

git reset path 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 file... to unstage) # # modified: Target.java # # Unmerged paths: # (use git reset HEAD file... to unstage) # (use

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

2014-02-28 Thread Stephen Leake
David Kastrup d...@gnu.org writes: Stephen Leake stephen_le...@stephe-leake.org writes: David Kastrup d...@gnu.org 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

Re: `git stash pop` UX Problem

2014-02-28 Thread Stephen Leake
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

Re: `git stash pop` UX Problem

2014-02-28 Thread Stephen Leake
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

Re: `git stash pop` UX Problem

2014-03-01 Thread Stephen Leake
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

Re: `git stash pop` UX Problem

2014-03-01 Thread Stephen Leake
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

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

2014-03-01 Thread Stephen Leake
David Kastrup d...@gnu.org writes: Stephen Leake stephen_le...@stephe-leake.org writes: David Kastrup d...@gnu.org writes: Stephen Leake stephen_le...@stephe-leake.org writes: David Kastrup d...@gnu.org writes: do the right thing commands also tend to do the wrong thing occasionally

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

2014-03-01 Thread Stephen Leake
Matthieu Moy matthieu@grenoble-inp.fr 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!

Re: emacs buffer names

2014-04-02 Thread Stephen Leake
Duy Nguyen pclo...@gmail.com 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.c2, which belongs to which checkout?). I ended up modifying files in the wrong

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

2014-04-22 Thread Stephen Leake
Felipe Contreras felipe.contre...@gmail.com 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

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

2014-04-23 Thread Stephen Leake
Felipe Contreras felipe.contre...@gmail.com writes: Stephen Leake wrote: Felipe Contreras felipe.contre...@gmail.com 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

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

2014-04-24 Thread Stephen Leake
Felipe Contreras felipe.contre...@gmail.com 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