On Wed, May 18, 2011 at 3:22 PM, Eric Firing <efiring@...> wrote:
> On 05/18/2011 08:47 AM, Benjamin Root wrote:
>> On Tue, May 17, 2011 at 9:07 PM, Gerald Storer <gds@...
>> <mailto:gds@...>> wrote:
>> On 18/05/2011 5:14 AM, Eric Firing wrote:
>> > 3) We don't have to always push sets of changes from an original pull
>> > request to upstream; they can be consolidated using any of a
>> variety of
>> > methods to form a new local feature branch with the same net
>> effect but
>> > fewer commits (maybe only one), and then that can be merged (which
>> > should be fast-forward, no merge commit) and pushed to upstream.
>> > takes a little more work than simply accepting (merging) a pull
>> > as-is, but in many cases it may be worth it because it can yield a
>> > cleaner history. Similarly, if someone is developing a feature
>> > on github, and the net effect is correct but the branch has
>> > commits that distract from the net result, then a good practice
>> would be
>> > for that person to consolidate the changes into a new feature branch
>> > with a cleaner history, close the pull request on the old one and
>> open a
>> > new request for the polished branch.
>> I believe this script more or less automates the process:
>> Don't know if this was a mistake or not, but I see that commit e7f1e83
>> (the one to fix a clipping issue when a patch's line width is 1 but
>> there is no color) seems to have been merged back into itself...
>> somehow... in commit 0c886b8. I have seen things like this before, and
>> I never quite understood how they happen. Plus, do we want to get that
>> patch merged down to master?
> Yes, it needs to get merged to master; but no, I don't think anything
> was "merged back into itself"; instead, it is just a case where a
> fast-forward with no merge commit would have left a simpler history--one
> commit instead of two.
> Merging from v1.0.x to master doesn't have to be done after every change
> to v1.0.x, but it shouldn't be left undone for very long. A few days
> ago I wasted a chunk of time thrashing around on master because of a bug
> that had been fixed on 1.0.x but was not yet merged into master--and I
> had not thought to check their relative states. The bug had actually
> been introduced to master via a recent change merged from 1.0.x.
> We are experiencing some bumps on the git/github learning curve, but not
> nearly enough to make me pine for svn.
>> I think we definitely need to see what sort of controls we can put in
>> place to prevent mix-ups in the future. One thing I did like about SVN
>> was that it was next to impossible to change the history. Meanwhile,
>> with git, it becomes possible. Is there some way we can disallow forced
>> pushes, maybe? Just a thought...
> I suspect the anomalies have not resulted from forced pushes, but from
> local pulls and merges followed by innocuous pushes. So the key is
> understanding how to ensure one's local branches have the desired
> history before pushing to github. (And making sure one is pushing from
> the correct source to the correct destination. Trying first with
> --dry-run can help.)
Before pushing, I also recommend inspecting the history graph, either
with "gitk --all" or "git log --oneline --graph --all". I try to
remember to make sure the history graph looks the way I expect it
should before I push anywhere.