| Re: [AD] switching to git, 2012 edition |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Mon, 2 Jul 2012 10:53:14 +1000
Peter Wang <novalazy@xxxxxxxxxx> wrote:
> On Sun, 1 Jul 2012 18:21:36 -0600, Thomas Fjellstrom
> <tfjellstrom@xxxxxxxxxx> wrote:
> > On Sun Jul 1, 2012, Peter Wang wrote:
> > > On Sun, 1 Jul 2012 14:32:37 +0200, Elias Pschernig
> > <elias.pschernig@xxxxxxxxxx> wrote:
> > >
> > > You can make pull --rebase the default for a certain branch, or
> > > all new branches that you create:
> > > http://mislav.uniqpath.com/2010/07/git-tips/
> > >
> > > Peter
> >
> > >From what I've heard rebase'ing is a /bad/ thing in most cases.
> > >Because then
> > you lose history and the like.
>
> There's entirely too much fear mongering about this.
> Rebasing is a very useful tool. I use it *constantly* on local
> changes.
>
> The only history lost here is that you made your local changes (C1,
> C2) on top of version A, instead of on top of version B. This is
> usually irrelevant information unless you have a very long-lived
> local branch, where A and B have diverged significantly in the mean
> time.
>
> i.e. with git pull (merging):
>
> A ---> A1 ---> A2 ---> B (public)
> \ \
> ---> C1 ---> C2 ---> M (local)
>
> M is the useless merge commit.
>
> With git pull --rebase:
>
> A ---> A1 ---> A2 ---> B (public)
> \
> ---> C1' ---> C2' (local)
>
> Then push back a nice linear history:
>
> A ---> A1 ---> A2 ---> B ---> C1' ---> C2' (public)
>
Yes, definitely should use rebase - the merge commit is just extra
noise. If I understand right it only matters if you commit things
locally while someone else pushed changes. So I guess for normal
svn-like commits (pull, commit change, push) like we have it's not all
that likely to happen (unless two people are working at the same time).