Dumb question about git

Kevin Cox kevincox.ca at gmail.com
Thu Mar 1 09:23:08 PST 2012


On Mar 1, 2012 12:15 PM, "H. S. Teoh" <hsteoh at quickfur.ath.cx> wrote:
>
> On Thu, Mar 01, 2012 at 10:22:33AM -0500, Kevin Cox wrote:
> > When people say git encourages rewriting history.  Don't listen.  Once
> > you have pushed your changes to the world they are immutable.  This is
> > because git uses cryptography internally and changing the history
> > messes everything up.  If you haven't pushed you can change all of
> > your history and it will all be fine.  But if someone else (github)
> > has the old hisory bad things happen.  If you are sure nobody has
> > pulled from github you can use --force when pushing (I think).  It
> > will work no matter what but you will piss off people if they have
> > pulled from you.  Please note that this kind of history modifying is
> > considered bad practice.
> [...]
>
> OK, so what's the right way to do it then? I have some changes in a
> branch, but master has been updated since, so I want to merge in the
> latest updates so that the branch changes are compatible with the latest
> code. If I just pull from master, then my changes get buried underneath
> the newest changes.
>
> I guess I still don't quite understand how things are supposed to work
> in situations like this.
>
>
> T
>
> --
> Music critic: "That's an imitation fugue!"

This time I would just --force.  In the future the idea is to only push
changes once you are happy with them.

What I would do next time is:
- work
- commit
- work
- commit
- pull
- rebase (make what you have done look pretty)
- push
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-learn/attachments/20120301/f177c6f6/attachment.html>


More information about the Digitalmars-d-learn mailing list