Re: Slash at the end of directory (was Re: oddity with TeX-style-private ?)

[David Kastrup]

Uwe Brauer <oub@mat.ucm.es> writes:

>>>> "DK" == David Kastrup <dak@gnu.org> writes:
>
>> Uwe Brauer <oub@mat.ucm.es> writes:
>>>> Pushed. Oops, sorry, I overlooked that new commits had come in. A non
>>>> fast-forward merge commit was produced on savannah. Not good...
>>> 
>>> Actually I find non fast-forward merges much easier to understand than
>>> fast-forward one. ;-)
>
>> That's nonsensical since any non fast-forward commit consists of the
>> combination of fast-forwarding (direct) commits with a subsequent merge
>> commit of two branches with diverging history.  Rebased commits, in
>> contrast, are just what would have resulted from linear development.
>
> I know and that is why I don't like rebasing.
>
>> It may be easier on the developer, but certainly not on the reader.
>
> That might be so, but I think it is just a different philosophy. I'd
> prefer to know where a commit comes from (I mean from which branch), and
> that is why I find linearising (that is rebasing) confusing to say the
> least.

To me it looks like you are confusing the development of a feature with
long-running parallel branches.  For the latter, there is no point in
rebasing.  For the former, there is no point in identifying a branch
that isn't in any manner reflecting anything but an arbitrary point of
departure before development of a feature has finished.

Rebasing does not provide a historical record.  Its point is to convey a
logical sequence of changes rather than a diary.  For figuring out where
and when and why something went right or wrong, that tends to be
considerably more accessible.

> But I think it boils down to a question of personal taste. (And I
> admit that if there are to many no fast forward merges from many
> branches that might be confusing as well). Anyhow.

-- 
David Kastrup