Re: [RFC] origin link for cherry-pick and revert

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

 



Nicolas Pitre wrote:
>On Thu, 11 Sep 2008, Stephen R. van den Berg wrote:
>> Anything I missed?

>Technically speaking, implementation d is obviously the most efficient.  
>but, as mentioned above, the actual need for this feature has not been 
>convincing so far.  Until then, it is not wise to add random stuff to 
>the very structure of a commit object, while c can be done even 
>externally from git which is a good way to demonstrate and convince 
>people about the usefulness of such feature.

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux