From: "Jacob Keller"
On Mon, Sep 28, 2015 at 1:42 PM, Junio C Hamano wrote:
"George Spelvin" writes:
I understand that "git reset --soft" makes no sense with a path, but
why not --hard?
I do not think there is anything fundamentally wrong for wishing for
"reset --hard ". It probably is ju
> I agree with you if we limit the scope to "reset --hard" that does
> not mention any commit on the command line (or says "HEAD").
>
> However, for things like:
>
> $ git reset --hard HEAD^ Makefile
> $ git reset --hard HEAD@{4.hours.ago} Makefile
>
> I do not think "reset --hard" is a go
On Mon, Sep 28, 2015 at 2:19 PM, Junio C Hamano wrote:
> I agree with you if we limit the scope to "reset --hard" that does
> not mention any commit on the command line (or says "HEAD").
>
> However, for things like:
>
> $ git reset --hard HEAD^ Makefile
> $ git reset --hard HEAD@{4.hours.
Junio C Hamano wrote:
> "George Spelvin" writes:
>> "git checkout " modifies the index?
>>
>> Damn, I've been using git for years and I never knew that.
>
> ... which would be an indication that the behaviour is most likely
> the most natural one.
I think it's more that often, staging a file to
"George Spelvin" writes:
> Junio C Hamano wrote:
>> "git checkout HEAD " is a 99% acceptable substitute for it
>> (the only case where it makes a difference is when you added a path to
>> the index that did not exist in HEAD).
>
> Er, wait a minute...
>
> "git checkout " modifies the index?
>
>
Junio C Hamano wrote:
> "git checkout HEAD " is a 99% acceptable substitute for it
> (the only case where it makes a difference is when you added a path to
> the index that did not exist in HEAD).
Er, wait a minute...
"git checkout " modifies the index?
Damn, I've been using git for years and
I personally have in my .gitconfig:
[alias]
revert-file = checkout HEAD --
I'm not sure revert-file is the best name, but it's what I've used
because I've been contaminated by the concept/naming of "p4 revert",
which I do use a fair amount to undo local edits for one or more files
when I'
Jacob Keller writes:
> On Mon, Sep 28, 2015 at 1:42 PM, Junio C Hamano wrote:
>> "George Spelvin" writes:
>>> I understand that "git reset --soft" makes no sense with a path, but
>>> why not --hard?
>>
>> I do not think there is anything fundamentally wrong for wishing for
>> "reset --hard ".
On Mon, Sep 28, 2015 at 1:42 PM, Junio C Hamano wrote:
> "George Spelvin" writes:
>> I understand that "git reset --soft" makes no sense with a path, but
>> why not --hard?
>
> I do not think there is anything fundamentally wrong for wishing for
> "reset --hard ". It probably is just that nobody
"George Spelvin" writes:
> I was applying an old forgotten stash to see if there were any edits in
> it I wanted to preserve, and my old changes to one file made no sense
> any more. I wanted to drop then all and keep the version in HEAD.
>
> I'd been using git reset after resolving conflicts,
I was applying an old forgotten stash to see if there were any edits in
it I wanted to preserve, and my old changes to one file made no sense
any more. I wanted to drop then all and keep the version in HEAD.
I'd been using git reset after resolving conflicts, to leave
the changes in the same un-
11 matches
Mail list logo