From: Elijah Newren <email@example.com> To: Jonathan Tan <firstname.lastname@example.org> Cc: Git Mailing List <email@example.com>, firstname.lastname@example.org, Junio C Hamano <email@example.com>, Derrick Stolee <firstname.lastname@example.org> Subject: Re: [PATCH v3] rebase --merge: optionally skip upstreamed commits Date: Fri, 10 Apr 2020 19:46:07 -0700 Message-ID: <CABPp-BFQSZeeM-WNQi0vFzX_1M099yfHrHcAEoQOHgg8TvnjWg@mail.gmail.com> (raw) In-Reply-To: <email@example.com> On Fri, Apr 10, 2020 at 6:11 PM Jonathan Tan <firstname.lastname@example.org> wrote: > > > > Reapply all clean cherry-picks of any upstream commit instead of > > > dropping them. (If these commits then become empty after rebasing, > > > because they contain a subset of already upstream changes, the > > > behavior towards them is controlled by the `--empty` flag.) > > > > Perhaps add "preemptively" in there, so that it reads "...instead of > > preemptively dropping them..."? > > Sounds good. Yes I can do this. > > > > If this works, I'll send out a new version containing Elijah's patches > > > and mine in whatever branch my patch shows up in . > > > > > >  https://email@example.com/ > > > > Yeah, I was making changes to this exact same area in my series to > > reference your flags. > > > >  https://firstname.lastname@example.org/ > > > > Would you mind if I took your proposed changes, put them in your > > patch, and then rebased your patch on top of my series and touched up > > the wording in the manpage to have the options reference each other? > > Go ahead! Thanks. Cool, please double check that I made the changes as you expected: https://email@example.com/ > > > > Why not just list --keep-cherry-pick[s] in the list of options that > > > > require use of the merge backend (i.e. the list containing '--merge') > > > > instead of adding another sentence here? > > > > > > My reading of the list containing "--merge" is that they *trigger* the > > > merge backend, not require the merge backend. My new option requires but > > > does not trigger it (unless we want to change it to do so, which I'm > > > fine with). > > > > Interesting; what part of the man page comes across that way? That > > may just be poor wording. > > "--merge" is documented as "Use merging strategies to rebase", which I > interpret as triggering the merge backend. There are other things in the > list like "--strategy" and "--interactive", which seem to be things that > trigger the merge backend too, so I concluded that the list is about > triggering the merge backend, not requiring it. > > > However, if an option requires a certain backend, is there a reason > > why we would want to require the user to manually specify that backend > > for their chosen option to work? We know exactly which backend they > > need, so we could just trigger it. For every other case in rebase I > > can think of, whenever a certain backend was required for an option we > > always made the option trigger that backend (or throw an error if a > > different backend had already been requested). > > I guess I wanted to leave open the option to have the same feature in > the "apply" (formerly "am") backend. The use cases I am thinking of > won't need that in the near future (for partial clone to make use of it > in the "apply" backend, the "apply" backend would have to be further > improved to batch fetching of missing blobs), though, so it might be > best to just require and trigger "merge" (like the other cases you > mention). I'll do that in the next version. Putting them in the list doesn't mean that they're designed to only work with one backend, just a reflection of what the current requirements/incompatibilities are. We've removed things from the list before when we implemented it in the other backend(s).
next prev parent reply index Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-03-09 20:55 [PATCH] " Jonathan Tan 2020-03-10 2:10 ` Taylor Blau 2020-03-10 15:51 ` Jonathan Tan 2020-03-10 12:17 ` Johannes Schindelin 2020-03-10 16:00 ` Jonathan Tan 2020-03-10 18:56 ` Elijah Newren 2020-03-10 22:56 ` Jonathan Tan 2020-03-12 18:04 ` Jonathan Tan 2020-03-12 22:40 ` Elijah Newren 2020-03-14 8:04 ` Elijah Newren 2020-03-17 3:03 ` Jonathan Tan 2020-03-18 17:30 ` [PATCH v2] " Jonathan Tan 2020-03-18 18:47 ` Junio C Hamano 2020-03-18 19:28 ` Jonathan Tan 2020-03-18 19:55 ` Junio C Hamano 2020-03-18 20:41 ` Elijah Newren 2020-03-18 23:39 ` Junio C Hamano 2020-03-19 0:17 ` Elijah Newren 2020-03-18 20:20 ` Junio C Hamano 2020-03-26 17:50 ` Jonathan Tan 2020-03-26 19:17 ` Elijah Newren 2020-03-26 19:27 ` Junio C Hamano 2020-03-29 10:12 ` [PATCH v2 4/4] t3402: use POSIX compliant regex(7) Đoàn Trần Công Danh 2020-03-30 4:06 ` [PATCH v3] rebase --merge: optionally skip upstreamed commits Jonathan Tan 2020-03-30 5:09 ` Junio C Hamano 2020-03-30 5:22 ` Danh Doan 2020-03-30 12:13 ` Derrick Stolee 2020-03-30 16:49 ` Junio C Hamano 2020-03-30 16:57 ` Jonathan Tan 2020-03-31 11:55 ` Derrick Stolee 2020-03-31 16:27 ` Elijah Newren 2020-03-31 18:34 ` Junio C Hamano 2020-03-31 18:43 ` Junio C Hamano 2020-04-10 22:27 ` Jonathan Tan 2020-04-11 0:06 ` Elijah Newren 2020-04-11 1:11 ` Jonathan Tan 2020-04-11 2:46 ` Elijah Newren [this message] 2020-03-26 7:35 [PATCH 0/3] add travis job for linux with musl libc Đoàn Trần Công Danh 2020-03-26 7:35 ` [PATCH 1/3] ci: libify logic for usage and checking CI_USER Đoàn Trần Công Danh 2020-03-26 7:35 ` [PATCH 2/3] ci: refactor docker runner script Đoàn Trần Công Danh 2020-03-26 16:06 ` Eric Sunshine 2020-03-28 17:53 ` SZEDER Gábor 2020-03-29 6:36 ` Danh Doan 2020-03-26 7:35 ` [PATCH 3/3] travis: build and test on Linux with musl libc and busybox Đoàn Trần Công Danh 2020-03-29 5:49 ` [PATCH 0/3] add travis job for linux with musl libc Junio C Hamano 2020-03-29 10:12 ` [PATCH v2 0/4] Travis + Azure jobs " Đoàn Trần Công Danh 2020-03-29 10:12 ` [PATCH v2 1/4] ci: libify logic for usage and checking CI_USER Đoàn Trần Công Danh 2020-03-29 10:12 ` [PATCH v2 2/4] ci: refactor docker runner script Đoàn Trần Công Danh 2020-04-01 21:51 ` SZEDER Gábor 2020-03-29 10:12 ` [PATCH v2 3/4] travis: build and test on Linux with musl libc and busybox Đoàn Trần Công Danh 2020-04-01 22:18 ` SZEDER Gábor 2020-04-02 1:42 ` Danh Doan 2020-04-07 14:53 ` Johannes Schindelin 2020-04-07 21:35 ` Junio C Hamano 2020-04-10 13:38 ` Johannes Schindelin 2020-03-29 16:23 ` [PATCH v2 0/4] Travis + Azure jobs for linux with musl libc Junio C Hamano 2020-04-02 13:03 ` [PATCH v3 0/6] " Đoàn Trần Công Danh 2020-04-02 13:04 ` [PATCH v3 1/6] ci: make MAKEFLAGS available inside the Docker container in the Linux32 job Đoàn Trần Công Danh 2020-04-02 13:04 ` [PATCH v3 2/6] ci/lib-docker: preserve required environment variables Đoàn Trần Công Danh 2020-04-03 8:22 ` SZEDER Gábor 2020-04-03 10:09 ` Danh Doan 2020-04-03 19:55 ` SZEDER Gábor 2020-04-02 13:04 ` [PATCH v3 3/6] ci/linux32: parameterise command to switch arch Đoàn Trần Công Danh 2020-04-02 13:04 ` [PATCH v3 4/6] ci: refactor docker runner script Đoàn Trần Công Danh 2020-04-02 13:04 ` [PATCH v3 5/6] ci/linux32: libify install-dependencies step Đoàn Trần Công Danh 2020-04-02 13:04 ` [PATCH v3 6/6] travis: build and test on Linux with musl libc and busybox Đoàn Trần Công Danh 2020-04-02 17:53 ` [PATCH v3 0/6] Travis + Azure jobs for linux with musl libc Junio C Hamano 2020-04-03 0:23 ` Danh Doan 2020-04-04 1:08 ` [PATCH v4 0/6] Travis " Đoàn Trần Công Danh 2020-04-04 1:08 ` [PATCH v4 1/6] ci: make MAKEFLAGS available inside the Docker container in the Linux32 job Đoàn Trần Công Danh 2020-04-04 1:08 ` [PATCH v4 2/6] ci/lib-docker: preserve required environment variables Đoàn Trần Công Danh 2020-04-04 1:08 ` [PATCH v4 3/6] ci/linux32: parameterise command to switch arch Đoàn Trần Công Danh 2020-04-04 1:08 ` [PATCH v4 4/6] ci: refactor docker runner script Đoàn Trần Công Danh 2020-04-04 1:08 ` [PATCH v4 5/6] ci/linux32: libify install-dependencies step Đoàn Trần Công Danh 2020-04-04 1:08 ` [PATCH v4 6/6] travis: build and test on Linux with musl libc and busybox Đoàn Trần Công Danh 2020-04-05 20:39 ` [PATCH v4 0/6] Travis jobs for linux with musl libc Junio C Hamano 2020-04-07 14:55 ` Johannes Schindelin 2020-04-07 19:25 ` Junio C Hamano
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=CABPp-BFQSZeeM-WNQi0vFzX_1M099yfHrHcAEoQOHgg8TvnjWg@mail.gmail.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.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 Mailing List Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/git/0 git/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 git git/ https://lore.kernel.org/git \ firstname.lastname@example.org public-inbox-index git Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.git AGPL code for this site: git clone https://public-inbox.org/public-inbox.git