On Mon, 2022-06-06 at 15:39 +0200, Johnny Billquist wrote:
>
> On 2022-06-06 15:12, Mouse wrote:
> >>>>[H]istory rewriting seems to be a favorite pastime of git users.
> >>>That's not a fault of git; that's a fault of how some people use
> >>>git.
> >>Well, you could argue that it's a fault in git that it allows it.
> >
> >>If there is a way, then some people will use it that way.
> >
> >But, if there isn't, some people will add it. git rebase is very
> >little more than a loop containing git cherry-pick.
>
> It is more, since this can be done without any hint that this
> actually happened.
>
> Basically, what I've seen in git:
>
>
> o Some commit (1-Jan-2022)
> |
> | o Some branch commit (29-Dec-2021)
> | |
> | /
> | /
> | /
> |/
> o A commit (31-Dec-2021)
> |
> |
>
>
> Now, how could "some branch commit" happen on Dec 29, when what it
> was based on was committed Dec 31 that same year? That's obviously
> not possible, and yet, that is what I see in git.
This image may be incomplete. Are you "thinking centrally"
perhaps? Or am I missing something else?
It's true that commit "Some branch commit" could never have been
_committed_ before "A commit". But it perfectly could have been
_authored_ before that commit, pick, merge or whatever the action
was which made the commit appear in the tree. Could be helpful to
see --format=fuller, which is why I have an alias for that to
enable the option by default.
In my perspective git is just more honest here, and tries hard to
reflect what happened in the real world to the source code. Which
now makes you see roles that just did not exist at all in the
centralized setup. IIUC the CVS or SVN history only has the
concept of a committer doing a commit, and this name and this
date is taken and placed into the history. Which results in a
linear sequence based on the server machine's timebase. In git
you have the author (the person who created that content), which
can be different from the committer (a maintainer or integrator
or other user who happened to bring this content into _this_
specific repository). This better reflects the development model
of where git originated. May not translate equally well to the
NetBSD development model which appears to be centralized indeed.
But then git metadata will just have identical names and dates
for authoring and commits, no problem there.
In the past I had occurences where a maintainer picked up a
submitted change some three years after I submitted it. That's
not unusual AFAICS. The BSD projects probably also have branches
sitting somewhere which may get merged later into more recent
releases, and nobody would suggest that the content creation
would have been at the time of the merge. This could even be seen
as a misattribution of the work that was done. And this metadata
may matter with regard to prior art, licensing, or similar. You
remember AT&T who stalled some BSD development, and SCO who tried
to misrepresent the Linux history and resulting ownership?
Something similar would be seen when you pick fixes and merge
them to a release. The branch may be new but the commit with the
fixes may be newer or older than the branch point. Does that
explain what you outline above in the illustration, or am I
missing something?
virtually yours
Gerhard Sittig
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
