So, welcome everyone, so I'm Pirate David, I'm walking at Octobus, and I've been walking
a Macreal contributor for about 15 years now, and for those who don't know Macreal is
a distributed version control, it's the same in generation as we have been created by
the same kind of people, by the same kind of, for the same kind of reason, with the same kind
of inspiration and the same kind of dynamitell. So, both Git and Macreal are about 20 years
or now, and Macreal is quite still active. It has also been the inspiration from multiple
of the new wave of DVCS like sapling and jiu-jitsu. It has a lot of great scaling, a lot of
feature, very extensible, it has distributed history, writing, and a bunch of things like that,
but I'm not going to cover all of that because it's a lighting talk, and I'm not going to dive into
what is Macreal and our innovation. Instead, I'm going to try to answer a common question of
what it's like to walk with Macreal that is kind of different than other tools. And so, I'm going to
go through a simple scenario to show some of the basic commands, I'm not going to cover everything,
I'm not going to explain much because I just want to give a feel of what it is. I'm not going
to show any comment graph, we have nice comment graph, they are nice for explaining things,
but we don't need to explain things, and we don't actually need to see them that much.
So, the lighting talk instruction where you're not going to use your own laptop,
and it's the beginning. And so, it's kind of the usual common kind of talk where I do demo in
a terminal, but I was not expecting a terminal. So, I have a terminal output, could be best
said in slide, and I'm going to try to make that still interesting. Some of the output are going
to be small because they are not that interesting and in an effort to make the interesting
output bigger. So, in that scenario, there is multiple people that are going to walk on a small
script. The small script is a Fibonacci sequence computation. If it's still small, it's on
purpose, if you can read it, it's not the point. But so, that's the script we're going to
welcome. And you're developer, and you want to write a first patch to fix something. So,
you've got some kind of you have AGDs that show you what I've shown in your walking
clipping, and you want to do a feature run to some review and everything. So, you say AG,
topic, robustness, the name of your feature branch, and you don't commit your type to commit
message, and you're good to go. Then you can push it, and it goes for review on the main server.
You also wrote two other patches to make the scenario more interesting, and I'm not going to
use patches because that's not the point. But so, now you have three patches, one is sent for review,
the other two, and I've just done finishing with them writing test and everything. And I get a
message from my review about the first patch. You say, okay, the patch looks good, but there was a
cheaper one, I fixed it, and you needed to rebase it, and I did it, and now it's merged. So,
thank you for your contribution. And it's like, okay, so someone touched my branch. But yeah, I mean,
multiple people who worked on the same branch, and I think of four, one trip, we may be someone
in Japan, to say, oh, you need to fix a typo and something, it just did it, and pushed it, and now it's
merged. So, what does it look from my perspective? Before I add the stack that I showed you before,
with the AG stack is showing you, basically, the content of your current feature range,
and I add the variables flag so that we see the actual commit ash, that we don't use that much,
because they change when you rewrite, but here at that point we want to see the content change. So,
I have three patches in my feature branch, and now I do a pull. The pull is adding two
chance sets, it's updating one chance set, which is the old version of mine, and I have two
or chance sets, we're going to talk more about the or chance later. And if I look back at the stack,
I only have two chance sets in my stack now. The first one I've been automatically removed from
the feature branch, because it's merged. And it's now the base of the two other one, and the
ash is different here. I am sure you remember the ash for the first, from two slides ago.
But so the ash is different. So, what happened to that thing? Like, as a developer someone touched
my patch, but what happened to it? Like, how can I add an idea of what happened, and is it fine?
So, I can say, AG upslug as zero, which is a strategy and defy her for the base, and I see that
add a version here, and it was amended to the content of the patch change by the reviewer,
and then, as we base, by the same reviewer, as a parent change, when the content didn't
according to the markers. And so, I have an idea of what happened by womb when, if I want to
validate something. And I can also ask for the patch to see what I have been changed in my patch,
in that case, going to focus on patch here. We also have, like, commit that, actually,
a false snapshot, but usually, when you do review, you focus on what other you'll change,
and you want to see the change to the patch itself, and not the rules that are fine.
And so, here, we see that it fixed the type on Fibonacci name somewhere, and that's about it.
That's the only thing that changed in my patch, so that's great. I'm appealing at it.
So, we're two or fans earlier. So, what are the off-hand? The off-hand are
chanted are based on something that's got to be written. And so, we know about that,
because we have the information of what is written, and we can flag them as off-hand.
It's look a bit scary, but actually it's not. Like, I run AGVOLV, and the two move them,
where they need to be doing the rebays and merging attitude. And so, now, I still have two
chanted in my stack, but they are longer off-hand. And I can just push them for review.
Until I go to my coffee, and then come back and have a few message from my reviewer.
He has feedback on the first chanted, he's back on the second chanted, I need to fix something
in the commit message. And he also say that he added type annotation in this clip, so maybe they
will conflict and see like that. So, now I need to update the two patch. I can move to the previous
patch, to the first patch. I'm liking AGV previews. And here I am. My check-out is now the first patch
of the stack, not the last patch of the stack. And I can do change, I have a diff, I knew an amend,
and that's it. When I do the amend, I have changed the base of the second chanted, I get an
orphan as before. But before it was not really scary to solve it, and in that case, it's even less
scary. So, if I, as the stack, what is the state of things, it's still not that there is the first
one, and the second one, that's going to be the second one, and if I say AG next, I move to the
second one, solving the orphan SN, and everything. And so, I could do an AG stack, and it would be
all fine. So, I need to fix the second chanted. In this case, I'm showing a different command,
which is PDF. This is going to show you the difference between the commit you have in your
walking copy and the file you have. And PDF is going to show you what is going to be the patch,
like the commit, if you do an amend. So, I can, I can validate either that I did the right
portions I wanted, or that the patch is going to look like I want. So, AG PDF, I have the patch I want,
I can AG and then dash dash edit. So, at that time, I actually, I did the commit message, and,
and that's it. I have a new version that is fixed, according to reviewer request.
So, there was still this thing about, oh, by the way, I added typing information. So,
I can just use AG pool to get the new version, and if you run AG stack, you get a new
information that say that your stack is behind by one chanted. So, I just run AG rebase,
because the stack no where it's going, and it's going to move the stack to the right location.
In this case, there was a small issue that, in one of the patch, I touched the function signature
and on the main branch, now we have typing information. So, we have a conflict. And so,
have a conflict, I solved it the usual way. I use AG continue to continue to do the current
operation. And then, it's fine, my two chanted rebase on the main branch, and I can push.
I just push, because it know that the new chanted replace the old chanted. So, it's pushing the new
chanted. It's pushing the introspection about the fact that they evolve to be the new chanted.
And it obsolete, we can make disappear the old chanted on the server.
Now, let's move to the point of view of the other person and getting to the reviewer seeds,
because in the first part, we saw that we were able to follow whether we were,
with you, or did, to my chanted. But it's also interesting for the reviewer of the review tool
to be able to see what happened to the chanted when some chanted were requested.
So, it's going to AG pull on his clone. You get the same kind of message, because you get the same
information that I just pushed. And then it can do the same kind of introspection that I did with
upslung. I'm not going to go into too much detail, because I don't want to, or everything, but in
that case, we see that there was a conflict. And we see information about there was a conflict
and now it was solved. And also, what was changed in the patch itself before it was updated and
re-based and in everything. And the same way for the second patch, there was this small change
that we have already seen, but there is also the fixed to the commit message. And we saw the
difference between the ultimate message and the new commit message to see that it was properly fixed.
And so, the reviewer at the same kind of tool that I had, and the reviewer tool at the same
kind of tool that I have to make sure that all this re-writing distributed is actually fine,
and we can follow what's going on. I don't know if you noticed, but when we stay the upsluck patch
for the less-than-thed, for example, we have a small diff that is the diff of what is the difference
between the patch, not as diff as diff, but difference between the states that we are intended.
Actually, if you look at the diff between the first version of the chenset, as at the full snapshots
and the last version of the chenset, as the full snapshots, you have something that is much bigger
because you insert all the diffs from the thing you were based on and the update you need on your
parents when you have the stack and everything. And so, this is already in this demo much bigger
and much harder to actually follow what is the actual thing that change. While the thing on the left
is the thing you want to see if you're just reviewing, okay, is this change updated as it should be.
And if you're in a company with like Android of 1000 of commit going on between each of your
the right side version is completely unusable. And so, just to conclude, there we go back to the
developer's seat, if you are agey pool, the two chenset that he pushed are now public, so they are
no longer in the future, but they have been accepted in the main branch. And the the future branch
basically fade away by itself and you don't have to care about deleting it in various places and
everything. Like it's done, everybody knows it's done and that's it. So, what do we have here?
We have simple commands with few lines like we just simple command for each for their purpose
doing their small things. We propagate the story we're writing so that you can actually do things
without troubles. We have the history of each commit to understand what happened if we want to.
You don't do that every day, but that's some time you do. We can automatically resolve the
instability that comes from rewriting other people patches and everything. The future branch is kind
of scoped and nice, you don't have to be too much concerned about, okay, this thing part of
one thing or another. And overall we can we can have a simple and safe collaboration of draft
which is nice. And this is not all the commands we have and everything, but this is the kind of
a version that you do every day with Michael Lee, where they fix some type or help them fix some
test testing like that. You can have more than one developers working on the same branch
with your collaboration tool, which is kind of the point. So, I hope the tickle your appetite. I'm
not doing it to any taking all the day of hours. If you're interested in material you can join us
or commit these things. If you need commercial support for material that's what Octobus is doing
and if you need hosting for material there is the Apple project which is a friendly
focus of Git lag with material support. If you have any question, you can meet me outside or maybe
you can have a few here.