From: Junio C Hamano <email@example.com> To: Michael J Gruber <firstname.lastname@example.org> Cc: email@example.com, Ekelhart Jakob <firstname.lastname@example.org>, Jeff King <email@example.com>, Johannes Schindelin <firstname.lastname@example.org> Subject: Re: [PATCH 2/3] merge-base: return fork-point outside reflog Date: Fri, 22 Sep 2017 18:14:39 +0900 Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> Michael J Gruber <email@example.com> writes: > I'm still trying to understand what the original intent was: If we > abstract from the implementation (as we should, as you rightly > emphasize) and talk about historical tips then we have to ask ourselves: > - What is "historical"? > - What is tip? > - Tip of what, i.e. what is a "branch"? The feature was meant to be a solution for "upstream rebased the branch I based my work on." Suppose you did git clone $URL git checkout -b mytopic origin/topic work work work and commit commit commit and then the next "git fetch" found that remote/origin/topic did not fast-forward, i.e. your upstream rewound and rebuilt the topic. Now, running git rebase origin/topic mytopic would be a disaster, as it would try to replay all the commits reachable from mytopic on top of the updated origin/topic, but the set of commits reachable from mytopic includes those the upstream used to have, on top of which you based your work, and you are not interested in replaying them at all. If you remember where you forked your topic from (you should be able to tell from "git log mytopic"), then git rebase --onto origin/topic $fork_point mytopic would be the way to replay "your" work on mytopic on top of the updated upstream. The reason why "--fork-point" exists is because people wanted to automate the "remember where you forked your topic from" part. Your upstream might have rewound the tip of topic many times while your repository did not fetch from it (iow, the reflog for origin/topic may not have _all_ the tips of other people observed to be historicallly at the tip of the remote), but that is immaterial for our purpose. As long as you built on top of origin/topic, the fork point must be one of the commits _you_ saw at the tip and it does not matter that you did not constantly fetch to observe all the changes at the remote. So the answers of these three questions are: - "historical": _you_ saw in your repository; - "tip": _you_ saw it pointed by the branch you forked your work from; and - "branch": whatever you consider you based your work on top of, typically a remote tracking branch. Of course, if you are employing a more advanced workflow, you might not have started your mytopic branch at any of the tip. E.g. if you wanted to extend Ben's fsmonitor topic, you would have forked your own topic like git checkout -b my-fsmonitor origin/pu^2 after fetching from me, and --fork-point would not be of much help obviously for such a workflow. But such users will use --onto and explicitly specify the fork point so it is outside the scope of the feature.
next prev parent reply index Thread overview: 25+ messages in thread (expand / mbox.gz / Atom feed / [top]) [not found] <c76e76a4ef11480da9995b0bec5a70e1@SFSWW2K12EX02.intern.fsw.at> 2017-09-13 15:07 ` merge-base not working as expected when base is ahead Ekelhart Jakob 2017-09-14 8:09 ` Michael J Gruber 2017-09-14 13:15 ` [PATCH 0/3] merge-base --fork-point fixes Michael J Gruber 2017-09-14 13:49 ` Johannes Schindelin 2017-09-14 14:38 ` Jeff King 2017-09-14 13:15 ` [PATCH 1/3] t6010: test actual test output Michael J Gruber 2017-09-14 14:34 ` Jeff King 2017-09-15 10:01 ` Michael J Gruber 2017-09-15 11:20 ` Jeff King 2017-09-14 13:15 ` [PATCH 2/3] merge-base: return fork-point outside reflog Michael J Gruber 2017-09-15 2:48 ` Junio C Hamano 2017-09-15 9:59 ` Phillip Wood 2017-09-15 10:23 ` Michael J Gruber 2017-09-15 18:24 ` Junio C Hamano 2017-09-21 6:27 ` Junio C Hamano 2017-09-21 9:39 ` Michael J Gruber 2017-09-22 1:49 ` Junio C Hamano 2017-09-22 8:34 ` Michael J Gruber 2017-09-22 9:14 ` Junio C Hamano [this message] 2017-10-03 6:05 ` Junio C Hamano 2017-11-08 8:52 ` Ekelhart Jakob 2017-11-08 9:33 ` Michael J Gruber 2017-11-09 2:49 ` Junio C Hamano 2017-09-14 13:15 ` [PATCH 3/3] merge-base: find fork-point outside partial reflog Michael J Gruber 2017-09-14 14:37 ` Jeff King
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 to all the recipients using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.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
email@example.com 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