[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [mylyn-reviews-dev] git best practices
- From: Matthias Sohn <matthias.sohn@xxxxxxxxxxxxxx>
- Date: Mon, 7 Feb 2011 18:19:16 +0100
- Delivered-to: email@example.com
- Domainkey-signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=uvntdQ7r6LuFPnv0in15+7hP1u9fqS6vu6UDX7vUt0VFrTO0H3b2lI/DQayfkSVmY/ reGqoJuS/gARTzROFehzfH9BR/smJT0UJPN0fSRRLEv9tomWZI6/vPSWerpApK+KmD/K 16uC9qPKxkpxlU20kp3t+dwAS7Vl9Op6ADZ7A=
2011/2/7 Lohre, Jan <jan.lohre@xxxxxxx>
when I have a series of commits and rebase them, each and every commit gets individually reapplied. But I will only check the latest one for correctness and consistency (although I could of course go through all commits, get them to my working tree, build and test them). This could lead to commits that would not even compile.
that's true, this is the inherent priceyou have to payÂwhen rebasing a patch series as allÂ
commits are rewritten. When doing a merge instead only the new merge commit has toÂ
be tested (if all the other commits haveÂbeen already tested earlier). But, then the
history isn't linear anymore ;-()
Or if I have a commit introducing a null guard â and on the central git repository somebody removed the possible null condition, after a rebase it looks like I have introduced a null guard where null could never happen.
But it's also possible that a merge creates logical nonsense as the algorithm operates on plain
text level and doesn't know anything about semantics. So if you add the null check and then merge
in another change which adds the same null-check three lines earlier the merge won't raise a conflict
but you would end up with a redundant null-check.