git cherry improvements suggestions

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

 



Hi,

Short version:

1. The <limit> is misleading IMO
2. Please extend the output to show "full diff"
3. Please add numerical/time <limit>
4. Would it be possible to use "=" for "equivalent change"?

Please tell me your opinions.


Long version:

I have a branch that have diverged long time ago from main branch. I can't use
merge, so I'm using cherry-pick to transplant changes between branches
(the other reason is I'm using git-svn...)

I noticed I did not transplant a certain commit recently. I wanted to
see if there
are any other commits I didn't transplant. I tried using git cherry:


1. man page says: git cherry [-v] [<upstream> [<head> [<limit>]]]

   $ git cherry -v master 9_1 20
   fatal: Unknown commit 20

After reading man page I though the limit is a numeric limit, like "check
last 20 commits".

I just realized it is a commit sha1. I think man could be improved to explicitly
say it's sha1 - maybe change the name from <limit> to something else
(<sha1>? <sha1_limit>?)


2. The cherry currently shows only changes against one branch:

   Every commit that doesn’t exist in the <upstream> branch has its id (sha1)
   reported[...] The ones that have equivalent change already in the <upstream>
   branch are prefixed with a minus (-) sign, and those that only exist in the
   <head> branch are prefixed with a plus (+)  symbol

So it will not show commits that exist only in <upstream> but not in <head>.

In my case changes are transplanted both ways (in general), so I have to check
both branches.

I understand I can switch branch positions, but this requires post-processing
to get rid of equivalent commits, maybe something like this:.

    git cherry upstream head | grep '^[+]' > head_only
    git cherry head upstream | grep '^[+]' > upstream_only

This is not very convenient, and I think you won't be able to see transplanted
changes with different ids (e.g. with conflicts) next to each other (such
commits would have probably the same commit message and it's possible
they were done at the same/close time, so it should be easy to see that
although the commits are shown as different, they represent the same change)

I think it would be usable to be able to see all changes:
    - commits in upstream only
    - commits in head only
    - equivalent commits (in both upstream and head)

Not sure how it should act in case of <limit> - maybe it should be illegal
to use <limit> in this mode. See also next point.


3. I think a numerical limit (or even: time limit etc) of checked commits would
be useful, especially in "full diff" mode. Without it would be not
possible to do a
full diff with a limit, and when switching branch positions you'd have to lookup
two commits:

    <find commit on head>
    git cherry upstream head  head_limit | grep '^[+]' > head_only
    <find commit on upstream>
    git cherry head upstream upstream_limit | grep '^[+]' > upstream_only

In case of numerical <limit> it should probably take <limit> changes
from head and
<limit> changes from upstream and see what is their status. So the actual
output would list from <limit> to 2*<limit> commits depending if all
commits are on
both branches, or no commit is equal.


4. The output format uses "-" to show commits that exist in both branches.
I find this unnatural. There probably is a reason for this? But maybe it would
be possible to change the symbols? For example:

   - commit in upstream only
   + commit in head only
   = equivalent commit

Or "<", ">", " " or any other graphic symbol.


Thanks for you time reading this long post :)

-- 
Piotr Krukowiecki
--
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]