On Wed, Dec 16, 2015 at 10:27 AM, Gaurav M. Bhandarkar <
gaurav.a...@gmail.com> wrote:

> > The end result is theoretically the equivalent of having started your
> branch at the latest trunk tip instead of where ever you really started it
>
>
> fast forward merges is just one of the advantages of rebase. It is done to
> avoid the extra “merge-commit” and thus reduces the noise in repo history.
>

The forced "merge commit" is (IMO) a design flaw in git, as such a forced
commit _could not possibly_ have been tested by a person before the
committing.

Then I run “git rebase -i master” which gives me an option to “squash”
> commits that happened after “where-master-is-currently-at”. I can now
> remove those commits that had binary files, code samples etc. from my local
> branch’s history while keeping the actual code-changes and their commit
> messages. In the end I get a clean revision history ready to be merged in
> the master.
>
>
> I really miss this feature when I use fossil.
>

If "cleanliness is godliness" then git might have fossil beat in that
regard. One of the reasons i always liked StarWars better than Star Trek is
because in Star Trek everything is so antiseptically _clean_, whereas in
Star Wars ships have dirt ("carbon scoring") and scratches on them, and the
lights don't all work (some flicker).

While we're cleaning up, we can go ahead and do:

git branch -D master
git push origin:master

:-D

-- 
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Reply via email to