On Wed, Aug 6, 2014 at 6:26 PM, Nico Williams <n...@cryptonector.com> wrote:
> On Wed, Aug 6, 2014 at 10:58 AM, Jakub Narębski <jna...@gmail.com> wrote:
>> W dniu 2014-08-01 22:55, Nico Williams pisze:
>>> It would help if cherry-pick history where recorded somewhere (beyond
>>> the reflog)...
>>> Cherry-picks should record two parents, like merges.
>>> (Of course, it does no good to know about an unreachable parent, when
>>> a commit with two parents is pushed to a repo that doesn't have one of
>>> those parents, which can happen when topic branches aren't pushed
>>> upstream.)
>> There was (long time ago) a long thread about idea of adding some
>> kind of 'weak' references (links), 'weakparent' that can be automatically
>> used by Git but do not pollute the commit message,
>> and do not affect reachability calculations.  Ultimately it went
>> nowhere (as you can see) - there were many problems.
> My proposal was to put this sort of ancillary history info in a
> "branch object" (and that branches should be objects).  This would
> have a number of benefits, not the least of which is that at push time
> you can drop such ancillary history without having to alter the
> commits being pushed.

Is it something like object-ified reflog, similar to how replacement
objects (git-replace) can be thought to be object-ified grafts (I know
they are more)? Do I understand it correctly?

Did you plan to (ab)use known object types: tree and commit (a bit
similar to git-replace and git-note object, though there is no need for
fanout trees - the top level tree can reproduce refs hierarchy)? I see
that you planned to (ab)use existing transfer mechanism of refs and

BTW. sometimes I do wonder if we are not making a mistake trying
to shoehorn new features like stash, replacements and notes into
DAG, objects (commit, tree, blob), refs and reflogs. I'd rather Git
did not make the same mistake (well, I think it was a mistake) that
Mercurial did with .hgtags file, (ab)using file transfer for tags, instead
of adding separate transfer mechanism like Git has... which led to
contortions in interpreting / deling with said file (most recent version
is used, not the one in checked out revision) and things like having
to commit creating a tag for it to be transferrable.

>> For example: how it would work for reverts and rebases?
> Reverts upstream?  The revert should record the commit hash of the
> commit it reverts (but file-level reverts lose), so that this could be
> noticed.

If it is object-ified reflog then reverts are not a problem...

> Rebases upstream?  Well, that shouldn't happen, but if it does then
> you must rebase --onto and any cherry-picks of upstream rebased
> commits lose their ties to those (but this can be detected).

With rebases the problem is that it would be nice to have (at least
for a short time) the history of series of patches (the metahistory,
or history of a branch), but usually one doesn't need old pre-rebase
version after cleaning up the history for publishing.

> In general recording more metadata (assuming there's not privacy
> issues to consider) can't hurt.  Using it might, but having the option
> to can also help.


Jakub Narębski
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to