Re: Network graph

[Jason Felice]

On Mon, Mar 7, 2011 at 2:25 AM, Matt Di Pasquale <livelov...@gmail.com> wrote:

Cool. Can you make sure that when you cherry pick another fork's commit to your master branch that that commit disappears from that fork on your network graph so that your network graph starts to look clean? That would be sweet!

I'm not sure what controls this, but I need to cherry pick because some pull requests which aren't on topic branches have other patches with them.

[Matt Di Pasquale]

If you do a merge commit instead of a cherry pick, it should cause the commit that you merge in to disappear. If there are conflicts, you can correct them and make another commit. If they have other patches, when you merge in that commit, you'll also be merging in those other patches and they should disappear too.

when you do a cherry-pick, you are creating a new commit (with a different commit SHA), so Git & GitHub think they're different commits (cause they are), but really, both commits have the same diff/patch (minus and fixes you make), so it's ideal to merge.

Matt

[Matt Di Pasquale]

Essentially, if you just merge in the tip of everyone else's branches, you'll be the only branch listed on your network tab cause you'll have all the other commits. when you merge, this doesn't change the branch history. when you cherry pick, it disregards the branch history (it just takes one commit at a time). Merging takes ALL the differences between the two branches and merges them together and will include all the commits in history in your branch with the same SHA's. So, you get rid of all the dots on another branch by merging the tip of that branch into your branch because all those dots in the other branch are now part of your branch.

If you do it by cherry picking, it's confusing for others looking at the graph, because we don't know which commits you've cherry picked or not...

Matt

[Matt Di Pasquale]

One thing you could do, is continue to cherry pick. And then, when you think you've got all the commits "merged" in by cherry-picking (cherry-picked-branch), create a new branch (let's call it merged-branch) and merge in the tips of all the other branches on the network. this will make it look clean. Then, do a diff of the merged-branch and the cherry-picked-branch and make a new commit on the merged-branch so that it's the same as the cherry-picked-branch (one way you could do this is just check out the cherry-picked-branch, copy the project directory to the Desktop. Then, check out the merged-branch and just replace the project directory with the one on the desktop, then commit the changes.)

Now, the branches should have the same code, ie, git diff merged-branch cherry-picked-branch shouldn't output anything. But, the merged-branch will have all the commits from the other branches merged into its history, and so, these commits should not show on other branches on your network graph.

The only thing to be careful of here is that this is an all or nothing approach. If you are wiling to go through all the commits and make sure you're not leaving anything out, then this is fine. but if you just merge everything in, and then make a new commit to erase all that you just merged, then those commits will no longer appear on the graph, even tho they should because that code is not in the repo anymore (even tho the commit is, because you just undid the code in your last commit). So, we'd want those commits to show if it's changes that have not been incorporated into your repo.

Matt

[Jason Felice]

I prefer to merge branches when they are clean enough to merge anyway, but that isn't always the case.

The fact that the network graph is treating merging of all individual commits differently from merging of branches is a bit disturbing.  (And it is, I just confirmed.)  I had assumed since they both have the same parent commits, github would know.

This makes it all-or-nothing for branch merging, and I can't promise that.  For example, uhnmdi submitted two features which both have a parent commit that does something to the Rakefile which I don't understand and might be local changes for them.

[Matt Di Pasquale]

Excuse me, I think I was wrong that merging in another branch will delete that branch.

I think it'll still show the branch, but it'll make an arrow from the tip of that branch (that you merge into yours) to a new commit (the merge commit) on the tip of your branch. Anyway, that's what we want