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
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
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
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
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
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
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!
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
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
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
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
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
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
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
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
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
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
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 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
25 matches
Mail list logo
