Guillaume Desmottes <guillaume.desmottes@collabora.co.uk> writes:I think you would need a bit more than that to trigger this "behaviour". Your resolution needs to be such that it is identical to the HEAD where the rebased change is applied to, iow, among the series of commits, the final effect chosen by you from this particular one is not to do anything. So, not just "Now git diff produces an empty diff" in the above sequence, which merely means that the three-way --cc diff between the conflicted parties are resolved by taking from one side, after that "git add", "git diff HEAD" will have to be empty, for you to see the message. In essence, the final effect chosen by you is to skip this commit. You might want to say "git rebase --skip" here if that is the case. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
| Roland Dreier | Re: Integration of SCST in the mainstream Linux kernel |
| Jan Engelhardt | intel iommu (Re: -mm merge plans for 2.6.23) |
| Greg Kroah-Hartman | [PATCH 005/196] Chinese: add translation of SubmittingDrivers |
| Linus Torvalds | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
git: | |
| Linus Torvalds | Re: [GIT]: Networking |
| Gerrit Renker | [PATCH 0/37] dccp: Feature negotiation - last call for comments |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Frans Pop | svc: failed to register lockdv1 RPC service (errno 97). |
