From: Martin von Zweigbergk <hidden> Date: 2016-06-15 22:52:00
On Thu, 8 Sep 2011, Francis Moreau wrote:
On Thu, Sep 8, 2011 at 3:14 PM, Martin von Zweigbergk
[off-list ref] wrote:
quoted
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, 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
and as I said, it has been on my todo list for a long time. If
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.
Martin
From: Francis Moreau <hidden> Date: 2016-06-15 22:52:00
On Fri, Sep 9, 2011 at 4:23 AM, Martin von Zweigbergk
[off-list ref] wrote:
On Thu, 8 Sep 2011, Francis Moreau wrote:
quoted
On Thu, Sep 8, 2011 at 3:14 PM, Martin von Zweigbergk
[off-list ref] wrote:
quoted
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.
quoted
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
From: Martin von Zweigbergk <hidden> Date: 2016-06-15 22:52:00
On Fri, 9 Sep 2011, Francis Moreau wrote:
On Fri, Sep 9, 2011 at 4:23 AM, Martin von Zweigbergk
[off-list ref] wrote:
quoted
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 ?
Yes. (I actually did mean "all commits in master..foo", but "_any_
commits in master..foo~10" is more clear and exact.)
please let me know when you submitting your work, I'm interested to see it.
Will do. It's not really that much work, but I'm not sure when I will
have time for it. If you or anyone else is interested in doing it, you
are of course welcome.
quoted
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)
Yes, but this hypothetical flag would only be to speed things up by
avoid going to the roots to find out that the histories are disjoint.
Martin
From: Francis Moreau <hidden> Date: 2016-06-15 22:52:00
On Fri, Sep 9, 2011 at 3:06 PM, Martin von Zweigbergk
[off-list ref] wrote:
On Fri, 9 Sep 2011, Francis Moreau wrote:
quoted
On Fri, Sep 9, 2011 at 4:23 AM, Martin von Zweigbergk
[off-list ref] wrote:
quoted
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 ?
Yes. (I actually did mean "all commits in master..foo", but "_any_
commits in master..foo~10" is more clear and exact.)
quoted
please let me know when you submitting your work, I'm interested to see it.
Will do. It's not really that much work, but I'm not sure when I will
have time for it. If you or anyone else is interested in doing it, you
are of course welcome.
I'm a simple mortal user ;)
quoted
quoted
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)
Yes, but this hypothetical flag would only be to speed things up by
avoid going to the roots to find out that the histories are disjoint.
You're right but in my (mortal) experience, I'm always rebasing
branches onto another one which is not disjoint, so I'm assuming it's
the (very) common case, but I may be wrong. And what I'm assuming is
correct, I think it's make more sense to do the filtering by default
unless the flag tells to do otherwise.
Thanks
--
Francis
From: Martin von Zweigbergk <hidden> Date: 2016-06-15 22:52:02
On Fri, 9 Sep 2011, Martin von Zweigbergk wrote:
On Fri, 9 Sep 2011, Francis Moreau wrote:
quoted
please let me know when you submitting your work, I'm interested to see it.
Will do. It's not really that much work [...]
It seems to be a little less straight-forward than I had first
expected.
We want to get all commits in $oldbase..$branch that do not share
patch-id with commits in $oldbase..$newbase. These are the commits
prefixed by '+' in 'git cherry $newbase $branch $oldbase'. However,
just getting the list of commits is not enough, because we currently
don't explicitly provide a list of commits to create patches from, but
instead run something like 'git format-patch --ignore-if-in-upstream
--stdout | git am --rebasing'.
I can see a few different solutions.
1. Teach git-format-patch a --stdin option that makes it read the
list of commits from the command line. git-format-patch currently
itself walks the history, so I'm not sure how such an option
should interact with current option. The options should probably
be mutually exclusive.
2. Somehow modify git-rebase--am.sh not to depend on format-patch. In
[1], Junio mentions rewriting git-rebase--am.sh "to have
format-patch avoid the cost of actually generating the patch text"
and "when using "am" for rebasing we do not really care anything
but the commit object names". If all we need is the commit name,
why would we not use cherry-pick/sequencer instead of git-am?
Sorry if this makes no sense; I'm not familiar with the git-am
code.
3. If I'm reading the code correctly, 'git cherry $upstream $branch
$limit' does one walk to find patch-ids for "$upstream
^$branch". It then walks "$branch ^$upstream ^$limit" and removes
the commits that have the same patch-id as a commit found in the
first walk. Since format-patch uses the revision walking
machinery, we could make it possible to ask git-rev-list directly
what git-cherry does, i.e. to ask for "commits in a..b that don't
share patch-id with commits in c..d". We could even make it more
generic by allowing queries like "commits in
$rev_list_expression_1 that don't share patch-id with commits in
$rev_list_expression_2".
I'm not sure which option is better. Option 1 seems easiest to
implement. Option 3 seems a bit harder, but may bring more value. I'm
just not sure if teaching rev-list about patch-ids is generally useful
or if it would feel more like a hack for this specific case. Option 2
is less clear to me and I would probably need more input before
implementing, but I trust Junio that it would be a good long-term
solution.
I will be moving soon and I don't know how much time I will have to
implement any of this. Still, I would be happy to hear your
opinions. Maybe I'm just missing something and there is even a simple
solution to my problem.
Martin
[1] http://thread.gmane.org/gmane.comp.version-control.git/180976/focus=181085