Re: Why not git reset --hard ?

> 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

Why not git reset --hard ?

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

Re: Why not git reset --hard ?

Junio C Hamano <gits...@pobox.com> wrote: > "George Spelvin" <li...@horizon.com> 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 th

Re: Why not git reset --hard ?

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

[BUG] rebase modify/delete conflict prints wrong SHA-1

in the changes. Patch failed at 0001 Edit foo The copy of the patch that failed is found in: /tmp/foo/.git/rebase-apply/patch For me, commit 52e1cece is the patch that removes bar, not foo: $ git show 52e1cece commit 52e1cece1e48dc21b317d4bd671fa171c3a7abd3 Author: George Spelvin li

Re: [PATCH v2] userdiff: update Ada patterns

Looking at the grammar at http://www.adahome.com/rm95/rm9x-P.html and http://www.adaic.org/resources/add_content/standards/05rm/html/RM-2-4.html I see the following restrictions apply: - A number must begin and end with a digit. There must be at least one digit on either side of each

Is there a way to cherry-pick a merge?

Sometimes I'd like to repeat a previously performed merge, preserving the commit message. And, if possible, the conflict resolutions. git cherry-pick -m 1 commit gets me the changes, but makes an ordinary single-parent commit, not a merge. git rebase -p --onto HEAD commit^ commit does the right

Re: Is there a way to cherry-pick a merge?

George Spelvin li...@horizon.com writes: Sometimes I'd like to repeat a previously performed merge, preserving the commit message. And, if possible, the conflict resolutions. Is it git merge commit^2? I suppose that was an obvious one to leave out of my alternatives list. This is what I've

Re: Is there a way to cherry-pick a merge?

In the meantime, git commit --amend -C commit would be a workaround, I would guess. Ah! A useful feature I was not familiar with. Definitely helps a great deal. Thank you! -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org

Re: git reflog delete HEAD@{1} HEAD@{2} caught me by surprise...

I would actually call that behaviour a bug. Well, yes, that was my inclination, too. But writing documentation was easier than writing a code patch. :-) Even when it is fixed, a comment about when it was fixed and what the buggy version did should live in the BUGS section for a while, to warn

git reflog delete HEAD@{1} HEAD@{2} caught me by surprise...

Try the following commands in an empty directory: (I'm using the bash extention for {1..5}.) git init for i in {1..5}; do git commit -m Commit $i --allow-empty; done git reflog bc93e06 HEAD@{0}: commit: Commit 5 e14f92d HEAD@{1}: commit: Commit 4 ac64d8e HEAD@{2}: commit:

Git feature request: --amend older commit

With git's commit frequently style, I often find that I end up with a commit that includes a typo in a comment or I forgot one call site when updating functions or something. And it's a few commits later before I notice the simple oops. This is of course fixable by making a commit, rebase -i