RE : git fetch --rebase to have a linear history

[PICCA Frédéric-Emmanuel]

> Sometimes we work on the repository at the same time as someone else.
> And when we run git fetch, a merge happens. Often, it is only for one
> commit, almost nothing. But the history becomes non linear (which is not
> so interesting to have.

> To see an example, run the following command on the compiler repository:

    gitk af8653371f44b285cea456e63b4eca2fabc7ff12

> In those cases, when the changes you have locally haven't been published
> anywhere, you can rebase your changes instead of merging them. It will
> take a diff of all your local commits, and apply them on top of the
> branch published on the internet.

> The only problem is that it changes the SHA1 of the commits, but if they
> are local that's not a problem.


We should look at the git repository to see how they deal with this problem.

> And it makes history linear.

is it that important to have a linear history

> To do so, instead of running git fetch that automatically do a merge,
> you can run

>     git fetch --rebase

> I think that would be great.

that's why, it would be great to have someone responsible for the integration of all the patch
in the official repository.

just my 2 cents :)

See you

Frédéric



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 3449 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/lisaac-devel/attachments/20090907/92448588/attachment.bin>