Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?)



At Wed, 13 May 2020 22:11:20 -0400, John Franklin <franklin%elfie.org@localhost> wrote:
Subject: Re: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?)
>
> Put another way, it’s nothing more than “please consider the changes
> in branch jqcoder/foo for inclusion in your project.” Any DVCS that
> can handle branches reasonably well can do something like a “pull
> request.” If you like it, `${DVCS} merge jqcoder/foo`.  The way GitHub
> handles PRs, the branch lives in their private clone of the
> repository, not the main project’s copy.  It prevents the master
> repository from getting polluted with dozens of pull request branches.

Yes, sort of.

Just to be pedantic though -- on githup "clones" are actually just
custom "views" of the same repository, storage-wise; and this gives
github the ability to quickly show all progress in all clones all at
once in one graph view.

My desire here is to see a (clean) history of branch commits be fully
imported into the NetBSD repository, complete with all its _original_
VCS metadata, but perhaps with the visible branch name removed.
I.e. the final repo DAG should contain all submitted commits, and all
that history should be visible to those who look for it (just as is the
case with merges from github "pull requests").

> It should be possible to go both ways.  I’ve seen very clean pull
> requests of a few commits that should be merged including the full
> history, and some that were 300+ commits with one-third of the commit
> messages including the words “revert” or “undo” in them.  (In some
> cases, the commit message was simply “revert”.)  Following the chain
> was fruitless, only comparing the branch to the mainline was of any
> value, and a squash commit is the only way to handle such things.

Well, the point of what Kun was getting at, I think, and what I would
like to see for NetBSD, is that a reviewer should entirely reject an
un-clean commit history.  Commit history that shows and documents the
intent and progress of changes is what's desired (and what makes review
easier for some/many reviewers), but of course a lot of false paths and
ugly hacks that are undone and tried again and again doesn't help tell
any real story about the final code or the path actually taken to get to
just that final result.  Commit history is exactly that -- a history
meant to be read and remembered by the humans who come afterwards.

--
					Greg A. Woods <gwoods%acm.org@localhost>

Kelowna, BC     +1 250 762-7675           RoboHack <woods%robohack.ca@localhost>
Planix, Inc. <woods%planix.com@localhost>     Avoncote Farms <woods%avoncote.ca@localhost>

Attachment: pgppflaJ1GQMA.pgp
Description: OpenPGP Digital Signature



Home | Main Index | Thread Index | Old Index