d about the desire to make
better use of the memory pool, but I've also included those
refinements in later versions of the patch series. Does that answer
your question?
> thanks for working on this.
And thank you for taking the time to review it and consider its inclusion!
- Stefan
On
That should let me use pointers for everything,
without the ints - so I probably won't need the union.
On Tue, Jan 29, 2019 at 10:02 AM Junio C Hamano wrote:
>
> Stefan Xenos writes:
>
> > Sorry, folks. I normally can't do any open source work on weekdays.
> > That al
Sorry, folks. I normally can't do any open source work on weekdays.
That also includes writing responses on the mailing list, so there
will normally be a week or two lag for me to iterate on this sort of
thing.
Feel free to either include this fix or revert my patch if there's a
problem with it -
Good point. Done.
> as for this patch it is not relevant what we we'll be using it for
> later, but rather that it touches the oidset class?
>
> > From: Stefan Xenos
> >
> > Implement a "contains_nondestructive" function for oid_array that won't
>
I've just sent my current set of stable patches for the evolve command
to the list.
The code should be stable, but there's follow-up stuff I still want to do:
- Add more tests for the new code.
- Make better use of the memory pool in change-table.c (ideally, all
the memory it uses should come from
I'm guessing the patch was just too big. I'll break it up and submit it in bits.
- Stefan
On Mon, Jan 21, 2019 at 12:21 PM Eric Wong wrote:
>
> Stefan Xenos wrote:
> > I've tried to upload a patch twice but it doesn't seem to be showing
> > up in my m
I've tried to upload a patch twice but it doesn't seem to be showing
up in my mailbox or in the mailing list archives. The patch title was
"[RFC PATCH] evolve: Implement the git change command".
Has anyone seen it? Is there a reason the mailing list would reject a patch?
- Stefan
I've just uploaded a new evolve proposal that includes a spec for the
"hiddenmetas" namespace, where we can store historical cherry-pick
information.
On Tue, Dec 18, 2018 at 6:40 AM Stefan Xenos wrote:
>
> Heya, Tejun!
>
> Thanks for getting in touch. I agree
Heya, Tejun!
Thanks for getting in touch. I agree with Junio that we probably
shouldn't be tracking the same information in two ways if we can think
of something that does both... so let's see if we can think of
something! The evolve proposal suggests having a metas/ namespace to
track ongoing cha
>
> Which brings us back to your "git checkout-files " use case
> above. It should be treat the same way in my opinion, so we either do
>
> git checkout-files --from=tree-ish :/
>
> or
>
> git checkout-files --from=tree-ish .
>
> But "git checkout-files --from=tree-ish" alone is rejected.
Agreed
More thoughts:
git switch-branch should never detach HEAD unless asked to do so
explicitly. That also means that "git switch-branch" shouldn't accept
any of the non-branch tree-ish arguments that would have caused "git
checkout" to do so.
On Wed, Nov 28, 2018 at 3:
an alias for this
functionality for some time.
- Stefan
On Wed, Nov 28, 2018 at 3:22 PM Stefan Xenos wrote:
>
> > Since the other one is already "checkout-files", maybe this one could just
> > be "checkout-branch".
>
> I rather like switch-branch and d
> Since the other one is already "checkout-files", maybe this one could just be
> "checkout-branch".
I rather like switch-branch and dislike the word "checkout" since it
has been overloaded in git for so long (does it mean moving HEAD or
copying files to my working tree?)
> nobody will become "s
git switch-branch --detach
git detach
git switch-branch HEAD
- Stefan
On Wed, Nov 28, 2018 at 2:48 PM Stefan Xenos wrote:
>
> I think users have problems with detached heads for several reasons:
>
> 1. Users often enter the detached head state unexpectedly (for example, by
> mistyp
be more willing to commit to deliverables.
- Stefan
On Tue, Nov 20, 2018 at 5:33 PM Jonathan Nieder wrote:
>
> Stefan Xenos wrote:
> > Jonathan Nieder wrote:
>
> >> putting it in the commit message is a way to
> >> experiment with the workflow without changing th
understand the change graphs that are produced
during that temporary state of affairs, I'm fine with using the commit
message. We can move it to the header prior to enabling the feature by
default.
- Stefan
On Tue, Nov 20, 2018 at 2:06 PM Jonathan Nieder wrote:
>
> Stefan Xenos wrote:
>
- Stefan
On Tue, Nov 20, 2018 at 5:03 AM Phillip Wood wrote:
>
> On 15/11/2018 00:55, sxe...@google.com wrote:
> > From: Stefan Xenos
> >
> > +Obsolescence across cherry-picks
> > +
> > +By default the evolve command will treat
> 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 u
g:
> >>
> >> tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
> >> parent aa7ce55545bf2c14bef48db91af1a74e2347539a
> >> parent-type content
> >> parent d64309ee51d0af12723b6cb027fc9f195b15a5e9
> >> parent-type obsolete
> >> paren
> 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 cont
e to scroll past a bunch of
transformation-enablement options that are only relevant to evolve.
Based on your log feedback above, I'm thinking #5 may make sense.
- Stefan
On Mon, Nov 19, 2018 at 7:55 AM SZEDER Gábor wrote:
>
> On Sat, Nov 17, 2018 at 12:30:58PM -0800, Stefan Xenos wr
cases so
this would block adoption in gerrit.
- Stefan
On Sun, Nov 18, 2018 at 8:15 PM Junio C Hamano wrote:
>
> 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
&
> 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 meta-gra
same email again.
On Sun, Nov 18, 2018 at 6:02 PM wrote:
>
> From: Stefan Xenos
>
> This document describes what a change graph for
> git would look like, the behavior of the evolve command,
> and the changes planned for other commands.
>
> Signed-off-by: Stefan Xenos
>
> 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 o
ith the previous one that regarding the "git change" command.
On Sun, Nov 18, 2018 at 2:27 PM Stefan Xenos wrote:
>
> > I don't think this counts as a typical modification and is probably hard to
> > detect automatically.
>
> Clever use of commands! (side: wouldn&#x
+# Share the full history of edits for the this_is_a_test change
> > +# with a review server
> > +$ git push origin metas/this_is_a_test:refs/for/master
> > +# Share the lastest commit for “Unrelated change”, without history
> > +$ git push origin HEAD:refs/for/master
>
> How do
t merge-base (ancestor) would be P. With
the change graph, the closest merge base would be C.
> If we GC'd commit A but still have the newer A', I can either thinkthat
I'm not sure I followed that. Are you suggesting a change to the
proposal or asking for a clarification?
On Fri
hes too closely. If you're not already familiar with the
distinction, you may see unexpected behavior when the "branch" you
think you're manipulating turns out to be a change.
- Stefan
On Thu, Nov 15, 2018 at 4:52 AM Johannes Schindelin
wrote:
>
> Hi Stefan,
>
> On W
then share their
results -- or if a user amends a commit, resets back to the original,
and then amends it again.
> Count me in to review the technical details.
Will do!
On Mon, Oct 1, 2018 at 5:37 AM, Derrick Stolee wrote:
> On 9/29/2018 7:00 PM, Stefan Xenos wrote:
>>
>> Hell
Gerrit uses notes and branches of meta-commits internally for its
database, but it still uses the change-id footers to associate an
uploaded commit with a change within its database.
On Thu, Oct 4, 2018 at 9:05 AM, Jakub Narebski wrote:
> Junio C Hamano writes:
>> Stefan Xeno
; On Tue, Oct 02 2018, Taylor Blau wrote:
>
>> Hi Stefan,
>>
>> On Sat, Sep 29, 2018 at 04:00:04PM -0700, Stefan Xenos wrote:
>>> Hello, List!
>>>
>>> I'm interested in porting something like Mercurial's evolve command to
>>> Git.
&
for stuff a user is actively
working on, but we could discard it (with 0 cost) for commits they're
done with or were never interested in editing.
On Sat, Sep 29, 2018 at 5:55 PM, Junio C Hamano wrote:
> Stefan Xenos writes:
>
>> What is the evolve command?
>> ...
>> -
Hello, List!
I'm interested in porting something like Mercurial's evolve command to
Git. I'll be following up with a formal proposal shortly, but before I
do I thought I'd introduce myself to the list and find out if anyone
else is interested in this topic.
What is the evolve command?
Imagine yo
34 matches
Mail list logo
