> I don't have a strong opinion about whether this would go in the
> design doc. I suppose the doc could have an "implementation plan"
> section describing temporary stopping points on the way to the final
> result, but it's not necessary to include that.
As long as this is something I'm just
Hi Stefan
On 20/11/2018 20:24, Stefan Xenos wrote:
>> If a merge has been cherry-picked we cannot update it as we don't record
>> which parent was used for the pick, however it is probably not a problem
>> in practice - I think it is unusual to amend merges.
>
> I've read and reread that
Stefan Xenos wrote:
> Jonathan Nieder wrote:
>> putting it in the commit message is a way to
>> experiment with the workflow without changing the object format
>
> As long as we're talking about a temporary state of affairs for users
> that have opted in, and we're explicit about the fact that
> putting it in the commit message is a way to
> experiment with the workflow without changing the object format
As long as we're talking about a temporary state of affairs for users
that have opted in, and we're explicit about the fact that future
versions of git won't understand the change
Stefan Xenos wrote:
> On Tue, Nov 20, 2018 at 1:43 AM Ævar Arnfjörð Bjarmason
> wrote:
>> I think it sounds better to just make it, in the header:
>>
>> x-evolve-pt content
>> x-evolve-pt obsolete
>> x-evolve-pt origin
>>
>> Where "pt = parent-type", we could of course spell that out
> If a merge has been cherry-picked we cannot update it as we don't record
> which parent was used for the pick, however it is probably not a problem
> in practice - I think it is unusual to amend merges.
I've read and reread that sentence several times and don't fully
understand it. Could you
> This explains why we have 'origin' fields in the meta commits, it might
> be worth putting a forward reference or note earlier on to explain why
> recording the origin is useful. (I didn't find gerrit needs it very
> convincing on its own but it is actually more general than gerrit's
> specific
This sounds like a proposal for general namespacing. I like it - that
would pave the way for other header extensions - but that should
probably be the subject of a separate proposal (who owns the content
of a namespace, what is the process for adding a new namespace or a
new attribute within a
> I was trying to see if this is something we can leave out to limit the
> initial scope.
Oh, in that case, "yes". :-) If there's a need to cut something,
origin parents would be a viable candidate.
I was thinking that this file could document the final goal so that if
anyone else wanted to
On 15/11/2018 00:55, sxe...@google.com wrote:
From: Stefan Xenos
+Obsolescence across cherry-picks
+
+By default the evolve command will treat cherry-picks and squash merges as
being
+completely separate from the original. Further amendments to the original
On 20/11/2018 12:18, Phillip Wood wrote:
On 15/11/2018 00:55, sxe...@google.com wrote:
From: Stefan Xenos
+Divergence
+--
+From the user’s perspective, two changes are divergent if they both
ask for
+different replacements to the same commit. More precisely, a target
commit is
Hi Stefan
Thanks for working on this, I think it could be a really useful addition
to git. I'd echo Gábor's comments about making commands descriptive and
easy for the user to find, git has aliases, accepts abbreviated option
names and has shell completion so I don't think typing is really
On Tue, Nov 20 2018, Jonathan Nieder wrote:
> Ævar Arnfjörð Bjarmason wrote:
>> On Thu, Nov 15 2018, sxe...@google.com wrote:
>
>>> +Parent-type
>>> +---
>>> +The “parent-type” field in the commit header identifies a commit as a
>>> +meta-commit and indicates the meaning for each of its
Ævar Arnfjörð Bjarmason wrote:
> On Thu, Nov 15 2018, sxe...@google.com wrote:
>> +Parent-type
>> +---
>> +The “parent-type” field in the commit header identifies a commit as a
>> +meta-commit and indicates the meaning for each of its parents. It is never
>> +present for normal commits.
Hi,
Stefan Xenos wrote:
> But since several comments have focused on the commands, let's brainstorm!
>
> Here's some options that occur to me:
>
> 1. Three commands: evolve + change + obslog as top-level commands (the
> current proposal). Change gets a bunch of subcommands for manipulating
> the
Stefan Xenos writes:
>> But it is not immediately obvious to me how it would help to have
>> "Z was cherry-picked from W" in "evolve".
>
> The evolve command would use it for handling the
> obsolescence-over-cherry-pick (OOCP) feature. If someone cherry-picks
> a commit and then amends the
> Subcommand names and --long-options are just as descriptive.
Yeah, I'm convinced about the descriptiveness. If you check the latest
version of the patch, I've already updated the "change" command to use
subcommands rather than lettered arguments.
> If a user wants to deal with reflogs, then
Hi,
Xenos wrote:
> Lets explore the "when" question. I think there's a compelling reason
> to add them as soon as possible - namely, gerrit. If and when we come
> to some sort of agreement on this proposal, gerrit could start adding
> tooling to understand change graphs as an alternative to
> But it is not immediately obvious to me how it would help to have "Z was
> cherry-picked from W" in "evolve".
The evolve command would use it for handling the
obsolescence-over-cherry-pick (OOCP) feature. If someone cherry-picks
a commit and then amends the original, the evolve command would
On Sat, Nov 17, 2018 at 12:30:58PM -0800, Stefan Xenos wrote:
> > Further, I see that this document tries to suggest a proliferation of new
> > commands
>
> It does. Let me explain a bit about the reasoning behind this
> breakdown of commands. My main priority was to keep the commands as
>
Stefan Xenos writes:
> The scenario you describe would not produce an origin edge in the
> metacommit graph. If the user amended X, there would be no origin
> edges - just a replacement. If you cherry-picked Z you'd get no
> replacements and just an origin. In neither case would you get both
>
Stefan Xenos writes:
>> I meant the project's history, not the meta-graph thing.
>
> In that case, we agree. The proposal suggests that "origin" should be
> reachable from the meta-graph for the cherry-picked commit, NOT the
> cherry-picked commit itself. Does that resolve our disagreement, or
> I meant the project's history, not the meta-graph thing.
In that case, we agree. The proposal suggests that "origin" should be
reachable from the meta-graph for the cherry-picked commit, NOT the
cherry-picked commit itself. Does that resolve our disagreement, or is
reachability from the
Stefan Xenos writes:
>> And the other half is that while I consider the "origin" thing is
>> unnecessary for the above reasons, having it means we need to not
>> just transfer the history reading to aa7ce555 and d664309ee (which
>> are necessary anyway while we have histories to transplant from
> Am I correct to understand that the reason why a commit object is
> (ab|re)used to represent a meta-commit is because by doing so we
> would get connectivity (i.e. fetching & pushing would transfer all
> the associated objects along) for free, and by not representing it
> as a new and different
Stefan Xenos writes:
>> I don't think this counts as a typical modification and is probably hard to
>> detect automatically.
>
> Clever use of commands! (side: wouldn't it just be easier to just use
> git commit --amend, though?)
When an original commit is mostly an early part of a feature,
> This breaks the "git change" symmetry with "git branch", but after
> responding to other messages regarding that command, I'm starting to
> think that's not really a problem.
Sorry, I appended that sentence to the wrong paragraph. It should have
gone with the previous one that regarding the
> I don't think this counts as a typical modification and is probably hard to
> detect automatically.
Clever use of commands! (side: wouldn't it just be easier to just use
git commit --amend, though?)
Either way, I agree that there should be a way to manually create a
change graph or modify one
Resending this without HTML enabled... sorry if you receive it twice.
> The file name and the title are in a mismatch.
Good point. However, the focus of this proposal really is supposed to
be on the underlying data structure, not just the evolve command
(which is the driving use-case for the
> I am not sure that we necessarily need this to be a graph. I think part
> of the problems with not being able to GC *any* of this is by this
> requirement to have it stored in a graph, rather than having mappings from
> which you could reconstruct any non-GC'ed parts of that graph, if you
>
sxe...@google.com writes:
> +Detailed design
> +===
> +Obsolescence information is stored as a graph of meta-commits. A meta-commit
> is
> +a specially-formatted merge commit that describes how one commit was created
> +from others.
> +
> +Meta-commits look like this:
> +
> +$ git
On Thu, Nov 15, 2018 at 2:00 AM wrote:
> +Goals
> +-
> +Legend: Goals marked with P0 are required. Goals marked with Pn should be
> +attempted unless they interfere with goals marked with Pn-1.
> +
> +P0. All commands that modify commits (such as the normal commit --amend or
> +rebase
On 11/14/2018 7:55 PM, sxe...@google.com wrote:
From: Stefan Xenos
This document describes what an obsolescence graph for
git would look like, the behavior of the evolve command,
and the changes planned for other commands.
Thanks for putting this together!
diff --git
On Thu, Nov 15 2018, sxe...@google.com wrote:
> +Detailed design
> +===
> +Obsolescence information is stored as a graph of meta-commits. A meta-commit
> is
> +a specially-formatted merge commit that describes how one commit was created
> +from others.
> +
> +Meta-commits look like
Hi Stefan,
On Wed, 14 Nov 2018, sxe...@google.com wrote:
> From: Stefan Xenos
>
> This document describes what an obsolescence graph for
> git would look like, the behavior of the evolve command,
> and the changes planned for other commands.
Thanks, this is a good discussion starter.
>
From: Stefan Xenos
This document describes what an obsolescence graph for
git would look like, the behavior of the evolve command,
and the changes planned for other commands.
Signed-off-by: Stefan Xenos
---
Documentation/technical/evolve.txt | 885 +
1 file
36 matches
Mail list logo
