[DO NOT MERGE] bump(code.google.com/p/gographviz):454bc64fdfa20468f637d99162e1edc60c1a6...

[0xmichalis]

...677
Related pr: #1229

I have removed testdata and the gographviz parser since we won't need it for now. @smarterclayton ptal

[ncdc]

I know it makes it harder to review PRs in github if you have the bump commit in the same PR as your changes, but if there is a lot of time between when your bump PR gets merged and when your other PR gets merged, anyone trying to also work with Godeps will see a lot of unwanted deletions. What happens is Godeps doesn't see anything using the updated dependency (because your 2nd PR hasn't merged yet), so it marks any files added by your bump PR for deletion.

Would you be ok combining them into 1 PR?

[0xmichalis]

@ncdc I am not against combining them into one PR, the problem that rises though is that I have to maintain two different commits which is much harder than maintaining them separately. I'll merge them together once the other one is done, if that's ok with you guys.

tl;dr bare with me and consider this a WIP

[ncdc]

What sort of challenges are you having maintaining 2 separate commits? I'd be happy to work with you to make things easier for you!

Sent from my iPhone

On Mar 12, 2015, at 5:38 AM, Michail Kargakis [email protected] wrote:

@ncdc I am not against combining them into one PR, the problem that rises though is that I have to maintain two different commits which is much harder than maintaining them separately. I'll merge them together once the other one is done, if that's ok with you guys.

tl;dr bare with me and consider this a WIP

—
Reply to this email directly or view it on GitHub.

[0xmichalis]

What sort of challenges are you having maintaining 2 separate commits? I'd be happy to work with you to make things easier for you!

Cool. So here is the story: when I maintain two commits in a branch, I cannot (or don't know how to more precisely) edit the first one and squash the edits on it since there is the second commit in between. eg.

pick <commit-hash> Godeps
pick <commit-hash> Actual-commit
pick <commit-hash> Godeps-edit

How am I supposed to squash here?

[ncdc]

With "git rebase -i " you can reorder commits and squash at will. I'd recommend reading the Git Book online and playing around with some dummy commits in a play repo to get comfortable with this. When I'm online later we can chat more.

Sent from my iPhone

On Mar 12, 2015, at 6:54 AM, Michail Kargakis [email protected] wrote:

What sort of challenges are you having maintaining 2 separate commits? I'd be happy to work with you to make things easier for you!

Cool. So here is the story: when I maintain two commits in a branch, I cannot (or don't know how to more precisely) edit the first one and squash the edits on it since there is the second commit in between. eg.

pick Godeps
pick Actual-commit
pick Godeps-edit
How am I supposed to squash here?

—
Reply to this email directly or view it on GitHub.

[0xmichalis]

With "git rebase -i " you can reorder commits and squash at will. I'd recommend reading the Git Book online and playing around with some dummy commits in a play repo to get comfortable with this. When I'm online later we can chat more.

Thanks for the tip, I'll definitely have a look at it.

[ncdc]

Great :-) I used this technique while working on remote command execution upstream, and at various times I had to update multiple Godeps, sometimes the same one multiple times with bug fixes, and you'll be able to use git rebase -i to get the ordering and squashing the way you want it. But watch out - it is possible to delete commits and lose them forever if you delete a commit line from the interactive rebase editing session and forget to move it where you want it.

[0xmichalis]

So the trick is just to reorder my commits? Based on the above example what should I do is:

pick <commit-hash> Godeps
f <commit-hash> Godeps-edit
pick <commit-hash> Actual-commit

Is that right?

[smarterclayton]

git checkout reflog@{1} when you do that (I think that's the "undo last rebase", but double check).

On Mar 12, 2015, at 7:11 AM, Andy Goldstein [email protected] wrote:

Great :-) I used this technique while working on remote command execution upstream, and at various times I had to update multiple Godeps, sometimes the same one multiple times with bug fixes, and you'll be able to use git rebase -i to get the ordering and squashing the way you want it. But watch out - it is possible to delete commits and lose them forever if you delete a commit line from the interactive rebase editing session and forget to move it where you want it.

—
Reply to this email directly or view it on GitHub.

[ncdc]

@Kargakis yes, just reorder the commits like you did in your comment. And then both s and f will squash a commit into the one above it (s keeps the commit message; f discards it).

[0xmichalis]

@ncdc thanks, I've moved this commit in my initial PR.

Closing this...