1 |
On Fri, 1 Jun 2012 23:23:34 +1200 |
2 |
Kent Fredric <kentfredric@×××××.com> wrote: |
3 |
|
4 |
> On 1 June 2012 22:54, Rich Freeman <rich0@g.o> wrote: |
5 |
> > Rebasing re-applies the same diff to the new head to give you a new |
6 |
> > set of commits. When you apply the same diff to a different parent |
7 |
> > you end up with a different tree, so the tree signature won't be the |
8 |
> > same either. |
9 |
> |
10 |
> Not nessecarily. Given that : |
11 |
> |
12 |
> a file with a given content has a fixed SHA |
13 |
> A tree is just a list of these SHA's , and that in turn is referenced |
14 |
> by SHA, so if 2 commits have identical file content, their 'tree' sha |
15 |
> will be the same ( in theory ). |
16 |
> |
17 |
> So that means, if you perform a rebase, assuming the filesystem looks |
18 |
> the same as it did before the rebase, it will have the same SHA1 for |
19 |
> the tree, regardless of the process of how it got to be that way. |
20 |
|
21 |
I don't think that 'not necessarily' makes any difference here. Maybe |
22 |
in our particular case this is not as likely as with regular source |
23 |
code tree but while rebasing you can hit conflicts. And then files |
24 |
start to change... |
25 |
|
26 |
-- |
27 |
Best regards, |
28 |
Michał Górny |