Re: panic recovery

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Levend Sayar <levendsayar@xxxxxxxxx> writes:

> Yesterday one of my colleague tried to commit her two weeks of work.
> Nearly 10 source code files.

Ok.

> After an unsuccessful am and apply commands, she tried rebase. And git
> bothered something like you have to finish your am first.

I do not get this for two reasons.

What does "am" and "apply" have anything to do with committing her own
work in her own working tree to begin with? And even if "am" and/or
"apply" were the right tools for committing hear work, that would mean she
had the changes to be committed neatly made into patch form suitable to be
fed to these commands, so I would imagine that the recovery is just the
matter of "reset --hard" followed by attempts to apply those patches again
and fixing rejects more carefully than the first failed attempt?

A practical suggestion, without knowing what really went wrong, that would
be valuable, especially for git beginners but applicable also to git
experts, is this. First commit your own work proper before doing anything
that may cause conflicts such as merging other's possibly unrelated work
(e.g. merge, am, ...). Then do such mergy operation to make separate
commits. You can do fancy things like combining changes into a single
commit _after_ doing so, and it will be much safer because at the worst
case you will be unable to achieve the fanciness (e.g. combining the
changes) but will have the working results (i.e. a commit with your own
changes, and separate commits recording others changes).

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]