On Mon, 2022-06-06 at 08:33 -0400, Mouse wrote:
>
> > I've recently come to realize a thing with git I really abhor. It
> > has a very loose view on history immutability. I've seen branches,
> > which claims to come from some point, where the branch is way older
> > than the revision it claims to have been branched off. Which
> > obviously is impossible. But history 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.
What Mouse said. Rebasing or force pushing what was _published_
before is even frowned upon. What you do to your local tree is up
to you. Go and arrange at will. This results in a better
submission that is easier to maintain at the upstream project's
side by the way, a useful feature and the reason why it exists.
But what was published, and what others are working with, "is
sacred" and must not change.
Rebasing a work in progress upon submission to upstream is a
useful feature, if the project prefers a linear history. The maze
of merges for feature branches are not preferred by everybody
alike. Rebase is not about making yourself look better to others.
It's beyond cosmetics. It's a means to achieve a code base that
is easier to work with at the maintainers' side.
As always: Go try it for yourself. Get a copy of a kernel, work
for weeks on a local change, and see how rebase against the
then-current version of upstream works for you. I liked it a lot.
It's careless force-pushing which makes me mad, and I don't want
to work with such a repo either. It's unfriendly behaviour.
Regarding dates, that an interesting thing. Git has the concept
of author date and commit date, which reflects the organization
of the project where the tool originated. Work on a change really
can have happened in any order which need not be the order of
acceptance into the common tree. And which repo is considered
_the_ tree of the project is not a git feature, but a convention
among involved persons. Some UIs may be adding to the confusion,
I believe github is one of those which doesn't present the order
of commits as they are in the repo. Their implementation detail,
not a limitation nor the fault of the git tool.
This git feature also BTW lets you locally use and explore work
that others are currently at, without going through one central
server. This is the very point of being distributed. No copying
patch files around manually.
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.
