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
>
>
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 h
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 do
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
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 --mer
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 thi
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
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 adv
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
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.
>
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
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 ad
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 f
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 t
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
--
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 ho
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
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
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'
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,
25 matches
Mail list logo
