From: Piotr Krukowiecki <piotr.krukowiecki@gmail.com>
To: Git Mailing List <git@vger.kernel.org>
Subject: git cherry improvements suggestions
Date: Wed, 23 Mar 2011 09:11:24 +0100 [thread overview]
Message-ID: <AANLkTimk0bkOGVy2W+XddHRuf-1xw+d0RwzPhnk40vi8@mail.gmail.com> (raw)
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
next reply other threads:[~2011-03-23 8:11 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-23 8:11 Piotr Krukowiecki [this message]
2011-03-23 10:46 ` git cherry improvements suggestions Michael J Gruber
2011-03-23 13:23 ` Piotr Krukowiecki
2011-03-23 13:33 ` Michael J Gruber
2011-03-23 14:43 ` Piotr Krukowiecki
2011-03-23 14:44 ` Michael J Gruber
2011-03-23 19:28 ` Piotr Krukowiecki
2011-03-24 7:40 ` Piotr Krukowiecki
2011-03-24 7:47 ` Michael J Gruber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AANLkTimk0bkOGVy2W+XddHRuf-1xw+d0RwzPhnk40vi8@mail.gmail.com \
--to=piotr.krukowiecki@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).