Re: [mylyn-reviews-dev] git best practices

[Steffen Pingel <steffen.pingel@xxxxxxxxxxx>]

Sounds like there are benefits and risks to rebasing before pushing and there may not be a one-fits-all policy that works for all cases.

Looking at the specific history of the Reviews project repository it seems that most merge commits could have been eliminated as there weren't any conflicts to resolve. Since we have four different components that are fairly independent I would expect this will be a common case unless several people work in the same area of a component concurrently.

As a compromise, can we agree on a strong recommendation to run a "git pull --rebase" before pushing to keep the history as linear as possible? In the end it should be up to each committer to make the call whether it's worth the risk and trouble to rebase but generally I would like to encourage it.

Steffen

On Mon, Feb 7, 2011 at 11:01 AM, Robin Rosenberg <robin.rosenberg@xxxxxxxxxx> wrote:

On 2011-02-07 18.19, Matthias Sohn wrote:

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.

The non-sense can come from a merge or a rebase, since both involve conflicts. If a conlict comes from
a merge, you will most likely have a similar conflict in the rebase operation.

With a merge, one can conclude from the merge itself that it was the merge that introduced the non-sense
and not a mistake by the authors of the commits involved.

-- robin

_______________________________________________
mylyn-reviews-dev mailing list
mylyn-reviews-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mylyn-reviews-dev

-- 
Steffen Pingel
Committer, http://eclipse.org/mylyn
Senior Developer, http://tasktop.com