The actual need for the feature seems to be dependent on one's workflow
habits. This is also the problem I sense throughout the thread: some
people know exactly what I'm talking about, and would come up with the
almost identical design specs for the feature independent of myself, and
others need to be explained every tiny detail of the spec because they
are not familiar with the concept and can't imagine why/how it would be
used.
Let me try and describe once more the typical environment this origin field
is vital in:
Imagine a repository with:
- 33774 commits total
- 13 years of history
- 1 development branch
- 9 stable branches (forked off of the development branch at regular
intervals during the past 13 years).
- The stable branches are never merged with each other or with the
development branch.
- 2787 individual back/forward ports between the development and stable
branches.
In order to have meaningful output for git-blame, it needs to follow the
chain across cherry-picks reliably.
Once you alter a piece of code, in order to figure out what more to alter,
you need to verify if this piece of code was or wasn't forward/backported.
Reliable and fast reporting of this, and actual comparison of the
different forward/backports between the 9 branches is essential. It
basically means that you need to view the diffs of the patches across 9
branches on a regular basis.
Without the origin links, this workflow will cost a lot more time to
pursue (I know it, because I'm living it at the moment, and no, I'm not
the only developer, it's a development team).
This development model is not unique to my situation, it occurs at more
places.
--
Sincerely,
Stephen R. van den Berg.
"There are three types of people in the world;
those who can count, and those who can't."
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html