git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: git-rebase skips automatically no more needed commits

From
FMFrancis Moreau <francis.moro@gmail.com>
Date
Sep 9, 2011, 06:43 UTC
Message-ID
<CAC9WiBhApjEr-NYm9NkyXaZPNCivoJ65c=xx2bg5Li60kfZMTQ@mail.gmail.com>
In-Reply-To
<alpine.DEB.2.00.1109082123300.12564@debian>

On Fri, Sep 9, 2011 at 4:23 AM, Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> wrote:

Show 22 quoted lines
> On Thu, 8 Sep 2011, Francis Moreau wrote:
>
>> On Thu, Sep 8, 2011 at 3:14 PM, Martin von Zweigbergk
>> <martin.von.zweigbergk@gmail.com> wrote:
>> >
>> > Patches that are in both sides of v2.6.39...foo will be filtered, but
>>
>> what do you mean by "both sides" ?
>
> See the section called "SPECIFYING RANGES" in "git --help
> rev-parse". It doesn't define "both sides", but what I mean by that is
> "both in v2.6.39..foo and in foo..v2.6.39". I believe that section
> will answer most of the other questions too.
>
>> Yes my use of "git rebase --onto master foo~10 foo"  is equivalent to
>> "git rebase master foo, the only difference is that the --onto variant
>> allow me to limit the range of commits that I want to rebase. So I
>> still want git rebase to do its the filtering process.
>
> Ok, that is different. I think you used v2.6.39 instead of foo~10
> previously. Assuming that v2.6.39 is the merge base of foo and master
> and that foo~10 is a later commit than v2.6.39,
That's what I meant.
> you are right that
> "git rebase --onto master foo~10 foo" could potentially filter out
> patches already in foo..master, without calculating patch-ids for all
> commits in master..foo for that matter. I think that would make sense
you meant master..foo~10, didn't you ?
> and as I said, it has been on my todo list for a long time. If
please let me know when you submitting your work, I'm interested to see it.
> necessary, we could have a flag to disable the filtering e.g. when the
> user knows that master is part of a completely separate history from
> foo.
Can't git figure this out itself ? (I'm not saying the switch is useless)
Thanks
-- 
Francis
Previous: Martin von ZweigbergkNext: Martin von Zweigbergk
Message 9 of 19 in “git-rebase skips automatically no more needed commits”
  1. Francis MoreauSep 6, 2011
  2. Junio C HamanoSep 6, 2011
  3. Francis MoreauSep 6, 2011
  4. Michael J GruberSep 7, 2011
  5. Junio C HamanoSep 7, 2011
  6. Francis MoreauSep 8, 2011
  7. Martin von ZweigbergkSep 8, 2011
  8. Martin von ZweigbergkSep 9, 2011
  9. Francis MoreauSep 9, 2011
  10. Martin von ZweigbergkSep 9, 2011
  11. Francis MoreauSep 9, 2011
  12. Martin von ZweigbergkSep 15, 2011
  13. Junio C HamanoSep 15, 2011
  14. Martin von ZweigbergkSep 16, 2011
  15. Martin von ZweigbergkSep 20, 2011
  16. Ramkumar RamachandraSep 24, 2011
  17. Martin von ZweigbergkSep 25, 2011
  18. Thomas RastSep 26, 2011
  19. Martin von ZweigbergkSep 28, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.