Arrgh! That was an e-mail I was drafting when I suffered a power
failure. That's why it's full of incomplete sentences and repeitions;
I was trying different wordings.
It was never supposed to be sent, and when the power came back on
I decided not to try to resurrect it. But apparently when the
> 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
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 nat
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 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-
8dc21b317d4bd671fa171c3a7abd3 and modified in Edit foo. Version Edit
foo of foo left in tree.
Failed to merge 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,
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 underscore
> 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.or
"George Spelvin" 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
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 " gets me the changes, but makes an
ordinary single-parent commit, not a merge.
"git rebase -p --onto HEAD commit^ commit" does the right th
> 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
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:
> Have you tried "git rebase --autosquash"? It does part of what you are
> asking for and additionally allows multiple fixup commits to be queued
> up and processed in a single rebase.
No, I hadn't! It's not *quite* as simple as what I had hoped for, but
definitely is progress in that directio
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 HE
15 matches
Mail list logo
