git@vger.kernel.org mailing list mirror (one of many)
 help / Atom feed
From: Johannes Sixt <j6t@kdbg.org>
To: Stefan Beller <sbeller@google.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH/RFC] git-post: the opposite of git-cherry-pick
Date: Thu, 5 Oct 2017 23:22:01 +0200
Message-ID: <3d362037-3eb6-83db-a17f-47a984135580@kdbg.org> (raw)
In-Reply-To: <CAGZ79kbr=zBc5GEL7hYyCnBcbdE8ZRp65QwxKMUVsQ+qXvRAAw@mail.gmail.com>

Am 05.10.2017 um 21:33 schrieb Stefan Beller:
> On Thu, Oct 5, 2017 at 12:13 PM, Johannes Sixt <j6t@kdbg.org> wrote:
>> +git-post(1)
>> +===========
>> +
>> +NAME
>> +----
>> +git-post - Apply a commit on top of a branch that is not checked out
> 
> Contrasted to:
>    git-cherry-pick - Apply the changes introduced by some existing commits
> Some questions on top of my head:
> * Do we want to emphasize the cherry-pick to say checked out?

Maybe. Maybe "cherry picking" is sufficiently clear that it is not needed.

> * Is it a good design choice to have a different command, just because the
>    target branch is [not] checked out?

I would not want to make it a sub-mode of cherry-pick, if that is what 
you mean, because "cherry picking" is about getting something, not 
giving something away.

> * Naming: I just searched for synonyms "opposite of cherry-picking" and
>    came up with cherry-put, cherry-post, target-commit

With command line completion, we have to type 'git cherr<TAB>-<TAB>' 
currently. If we add another command that begins with 'cherry-', another 
<TAB> is needed. Therefore, I do not want to use a name starting with 
'cherry-'.

> * What was the rationale for naming it "post" (it sounds very generic to me)?

Yes, it is generic, but I did not find a better word that means "give 
away" a commit. Perhaps "tack"?

> * Does it play well with worktrees? (i.e. if a worktree has a branch checked
>    out, we cannot post there, or can we?)

Good point. It should be forbidden, but there are no safety checks, 
currently.

>> +EXAMPLES
>> +--------
>> +
>> +Assume, while working on a topic, you find and fix an unrelated bug.
>> +Now:
>> +
>> +------------
>> +$ git commit                                   <1>
>> +$ git post master                              <2>
>> +$ git show | git apply -R && git reset HEAD^   <3>
>> +------------
>> +
>> +<1> create a commit with the fix on the current branch
>> +<2> copy the fix onto the branch where it ought to be
>> +<3> revert current topic branch to the unfixed state;
>> +can also be done with `git reset --keep HEAD^` if there are no
>> +unstaged changes in files that are modified by the fix
>> +
>> +Oftentimes, switching branches triggers a rebuild of a code base.
>> +With the sequence above the branch switch can be avoided.
>> +That said, it is good practice to test the bug fix on the
>> +destination branch eventually.
> 
> This is a cool and motivating example.

Thanks. Another use case is when you receive a patch to be applied on a 
different branch while you are in the middle of some work. If it can be 
applied on the current branch, then you can post it to the destination, 
rewind, and continue with your work.

>> +BUGS
>> +----
>> +
>> +The change can be applied on `dest-branch` only if there is
>> +no textual conflict.
> 
> This is not a bug per se, it could be signaled via a return code that
> the posting was unsuccessful.

Oh, it does so return an error. But there are some cases that one 
expects that work, but where git-apply is not capable enough.

-- Hannes

  reply index

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-05 19:13 Johannes Sixt
2017-10-05 19:33 ` Stefan Beller
2017-10-05 21:22   ` Johannes Sixt [this message]
2017-10-13 10:51     ` Ævar Arnfjörð Bjarmason
2017-10-15 15:09       ` Johannes Sixt
2017-10-16 23:01         ` Rafael Ascensao
2017-10-17 17:30           ` Johannes Sixt
2017-10-17 21:15             ` Igor Djordjevic

Reply instructions:

You may reply publically 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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3d362037-3eb6-83db-a17f-47a984135580@kdbg.org \
    --to=j6t@kdbg.org \
    --cc=git@vger.kernel.org \
    --cc=sbeller@google.com \
    /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

git@vger.kernel.org mailing list mirror (one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/
       or Tor2web: https://www.tor2web.org/

AGPL code for this site: git clone https://public-inbox.org/ public-inbox