Re: Canonical cinnabar repository

[Myk Melez]

Myk Melez 
2017 September 26 at 17:40

Kartikaya Gupta 
2017 September 26 at 08:49
So from the discussion here it sounds like using a full (i.e.
non-grafted) cinnabar repository "just works" for most people. It has
the problem of missing CVS history but it seems like people who need
that often can use searchfox and/or a gecko-dev branch in a cinnabar
repo to get it.
Yes, and can we also integrate CVS history into a full cinnabar 
repository like mozilla/gecko using Git's "replace" command.
I've now done this for mozilla/gecko, so if you clone/fetch that repo, 
then you'll get both a "central" branch and a "cvs" branch.


The "central" branch contains mozilla-central history, and I continue to 
sync it with upstream mozilla-central using cinnabar. The "cvs" branch 
contains the CVS history.


To integrate them (without modifying either history), fetch replacement 
refs:


git fetch origin 'refs/replace/*:refs/replace/*'

(Replace "origin" with the name of your mozilla/gecko remote, if it 
differs.)


Then common Git commands (diff, log, bisect, etc.) will behave as if the 
oldest commit in "central" (e18f9a3) is the newest commit in "cvs" 
(3ec464b), and you can use them to traverse the entire history of Gecko 
transparently.


I've also updated https://wiki.mozilla.org/GitHub/Gecko_Repositories to 
include this information.


-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Canonical cinnabar repository

[Myk Melez]

Kartikaya Gupta 
2017 September 26 at 08:49
So from the discussion here it sounds like using a full (i.e.
non-grafted) cinnabar repository "just works" for most people. It has
the problem of missing CVS history but it seems like people who need
that often can use searchfox and/or a gecko-dev branch in a cinnabar
repo to get it.
Yes, and can we also integrate CVS history into a full cinnabar 
repository like mozilla/gecko using Git's "replace" command.



And we have mozilla/gecko on github which is a cinnabar mirror.
However this mirror is not "officially" supported (i.e. it's updated
by Myk but not by Release Operations). It also doesn't seem to have
branches for inbound/autoland.
Right, mozilla/gecko is unofficial and synced by me. See wikimo's 
GitHub/Gecko_Repositories 
 for more details on 
the differences between mozilla/[gecko-dev|gecko-projects|gecko].


And indeed, it doesn't have branches for inbound nor autoland. Adding 
those would be trivial, if they're useful, although it isn't clear how 
useful they can be until cinnabar metadata is syncable (in cinnabar 0.5?).



So it seems to me that the next step is to have the operations team
take over ownership of the mozilla/gecko mirror. dhouse, do you know
what the process would be for that? I'm guessing this just involves
running a cinnabar conversion and pushing to github on a cron job, but
Myk can provide more details, assuming he agrees this is what we want
to do.
I would be happy for the operations team to take over syncing of the 
mozilla/gecko mirror. My process for doing so is trivial, effectively just:


git checkout central && git pull && git push upstream central:central

Where "central" is a local branch whose upstream branch is the 
branches/default/tip branch on the 
hg::https://hg.mozilla.org/mozilla-central remote (fetched with 
cinnabar), and "upstream" is the g...@github.com:mozilla/gecko.git remote.


There are some additional details to work out: whether to maintain the 
option to use mozilla/gecko as a hub for shared development on feature 
branches, whether to sync tags to the repo (which are synced differently 
in cinnabar 0.5), which additional repos to sync, etc. I'm happy to chat 
through those with someone as appropriate.



Eventually once cinnabar supports storing metadata in the repo
we'll want that pushed to the github repo as well.

Indeed!

-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Canonical cinnabar repository

[Kartikaya Gupta]

So from the discussion here it sounds like using a full (i.e.
non-grafted) cinnabar repository "just works" for most people. It has
the problem of missing CVS history but it seems like people who need
that often can use searchfox and/or a gecko-dev branch in a cinnabar
repo to get it.

And we have mozilla/gecko on github which is a cinnabar mirror.
However this mirror is not "officially" supported (i.e. it's updated
by Myk but not by Release Operations). It also doesn't seem to have
branches for inbound/autoland.

So it seems to me that the next step is to have the operations team
take over ownership of the mozilla/gecko mirror. dhouse, do you know
what the process would be for that? I'm guessing this just involves
running a cinnabar conversion and pushing to github on a cron job, but
Myk can provide more details, assuming he agrees this is what we want
to do. Eventually once cinnabar supports storing metadata in the repo
we'll want that pushed to the github repo as well.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Canonical cinnabar repository

[Myk Melez]

Ehsan Akhgari 
2017 September 18 at 12:59
I think there is a way to have our cake and eat it too, which is 
enabling git-cinnabar to understand a custom mapping of SHA1 so that 
we can rewrite the history and have cinnabar be able to deal with that 
when it maps hg/git revisions to each other.
We might be able to use Git's replace command [1], which enables you to 
"graft" one history onto another without rewriting revision IDs, such 
that Git commands like log, bisect, and blame traverse the two histories 
as one.


To test this out, I created a new repository mykmelez/gecko-test [2]; 
imported CVS history into a branch called "cvs"; imported the "central" 
branch from mozilla/gecko [3] (which is synced with cinnabar); and 
replaced e18f9a37a98d, which is the initial (earliest) commit on the 
central branch, with 3ec464b55782, which is the tip (latest) commit on 
the cvs branch.


The resulting log, starting from a9d623d0878b (the third-earliest commit 
on central), still shows e18f9a37a98d but decorates it with the 
"(replaced)" label and displays its replacement's commit message, after 
which the next two commits (55d824018c96 and 62453dda752a) are from CVS 
history:



 git log --oneline --decorate a9d623d0878b

a9d623d0878b Bug 374866. Reftests for text-transform. r=dbaron
028d2077b626 Free the (distributed) Lizard! Automatic merge from CVS: 
Module mozilla: tag HG_REPO_INITIAL_IMPORT at 22 Mar 2007 10:30 PDT,
e18f9a37a98d (replaced) - update headers - remove pango workarounds - 
update wget files paths

55d824018c96 - updating headers
62453dda752a split out breakpad symbol build and upload into two config 
options, r=preed


Neither history is altered, as the replacement is stored as a ref (in 
refs/replace/), which most Git commands respect ("except those doing 
reachability traversal (prune, pack transfer and fsck)"). So the store 
still contains the original initial mozilla-central commit:



 git --no-replace-objects log --oneline --decorate e18f9a37a98d

e18f9a37a98d Set up .hgignore to ignore CVS files.

And removing the replacement ref reverts the "graft," returning the two 
histories to their original, disconnected state.


A downside of this approach is that the replacement ref isn't fetched by 
default. You need to fetch it manually after cloning the repo:


git fetch origin 'refs/replace/*:refs/replace/*'

But you only need to do that once. And if you don't do it, you still get 
a working clone with a central branch that is the equivalent of 
mozilla-central cloned with cinnabar, along with a branch containing the 
CVS history. You just don't get combined history.


The CVS history doesn't take much space either. A fresh clone of 
mozilla/gecko takes 4.9GB on my system, while a fresh clone of 
mykmelez/gecko-test takes 5.2GB (about the same as gecko-dev, which is 
5.3GB).


So this seems like a promising option for having our cake and eating it 
too. Although further investigation is warranted to ensure that it works 
well with the Git commands (and editor integrations) that developers use 
when traversing history.


-myk

[1] https://git-scm.com/book/en/v2/Git-Tools-Replace
[2] https://github.com/mykmelez/gecko-test
[3] https://github.com/mozilla/gecko

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Canonical cinnabar repository

[J. Ryan Stinnett]

There are also some details about MozReview with git-cinnabar at:

http://mozilla-version-control-tools.readthedocs.io/en/latest/mozreview/install-git.html

though it doesn't seem to appear in the contents sidebar on the left, so it
would be nice to make it more discoverable. (Though I suppose Phabricator
will be the tool we use soonish...)

- Ryan

On Wed, Sep 20, 2017 at 12:04 PM, Jeff Muizelaar 
wrote:

> I would recommend
> https://github.com/glandium/git-cinnabar/wiki/Mozilla:-A-
> git-workflow-for-Gecko-development.
>
> The other places should probably be updated to point at that.
>
> -Jeff
>
> On Wed, Sep 20, 2017 at 12:57 PM, Ethan Glasser-Camp
>  wrote:
> > Sorry if this is a bit off-topic. It seems from these threads that there
> is
> > a more-or-less canonical way to use git to hack on Firefox. Where can I
> > find out more about it?
> >
> > Looking online, the only information I could find was at
> > https://github.com/glandium/git-cinnabar/wiki/Mozilla:-A-
> git-workflow-for-Gecko-development.
> > Is that the best source of information? I didn't see anything under
> > https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide,
> > http://mozilla-version-control-tools.readthedocs.io/en/latest/, or
> > https://firefox-source-docs.mozilla.org/.
> >
> > Thanks!
> >
> > Ethan
> >
> >
> > On Mon, Sep 18, 2017 at 10:05 AM, Kartikaya Gupta 
> > wrote:
> >
> >> This message was inspired by the `mach try` thread but is off-topic
> >> there so I think deserves its own thread.
> >>
> >> It seems to me that a lot of people are now assuming a cinnabar repo
> >> is the canonical way for git users to develop on mozilla-central. If
> >> we want to make this mozilla policy I don't really have objections,
> >> but I think that if we do that, we should maintain a canonical git
> >> repo that is built using cinnabar, rather than having everybody have
> >> their own "grafted" version of a cinnabar repo. The problem with the
> >> latter approach is that different people will have different SHAs for
> >> the same upstream commit, thus making it much harder to share repos.
> >>
> >> I've tried using cinnabar a couple of times now and the last time I
> >> tried, this was the dealbreaker for me. My worfklow often involves
> >> moving a branch from one machine to another and the extra hassle that
> >> results from mismatched SHAs makes it much more complicated than it
> >> needs to be. gecko-dev doesn't have this problem as it has a canonical
> >> upstream that works much more like a regular git user expects.
> >>
> >> As an aside, I also think that the cinnabar workflow as it exists now
> >> actually demotes git to more of a "second-class citizen".
> >> Conceptually, if you're using gecko-dev, everything works exactly as a
> >> git user would expect, and only when you need to push to official
> >> mozilla hg repos do you need to overcome the vcs translation hurdle
> >> (which things like moz-git-tools help with). However if you use
> >> cinnabar the vcs translation is more woven into your everyday git
> >> commands (e.g. git pull) and you need to be more consciously aware of
> >> it. This makes it harder to use whatever your normal git workflow is,
> >> which is why I claim it demotes git to second-class. It would be great
> >> if we could come up with a way to avoid this but honestly since I
> >> haven't used a cinnabar workflow for any significant period of time I
> >> haven't given much thought as to how to go about doing this.
> >>
> >> Discussion welcome!
> >>
> >> Cheers,
> >> kats
> >> ___
> >> dev-platform mailing list
> >> dev-platform@lists.mozilla.org
> >> https://lists.mozilla.org/listinfo/dev-platform
> >>
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Canonical cinnabar repository

[Soledad Penadés]

I started with that wiki page, but I am (lazy|efficient), so I automated 
it the next time I had to perform those steps in a different computer:


https://github.com/sole/cinnabarify

My script will set up remotes and stuff including setting up the helper 
(otherwise it'll be too slow for practical purposes). If you just want 
to look at what it does instead of running it:


https://github.com/sole/cinnabarify/blob/master/main.sh

There's also a list of frequent tasks and how to perform them e.g. 
updating from 'm-c', sending patches, pushing to mozreview, etc, as I 
didn't know how to use the resulting repo.


Hope that's useful. I particularly use the README all the time :)

Caveats: I couldn't make it work in Bash on windows, and it doesn't 
"say" in Linux, but the rest should work.


sole


On 20/09/2017 18:04, Jeff Muizelaar wrote:

I would recommend
https://github.com/glandium/git-cinnabar/wiki/Mozilla:-A-git-workflow-for-Gecko-development.

The other places should probably be updated to point at that.

-Jeff

On Wed, Sep 20, 2017 at 12:57 PM, Ethan Glasser-Camp
 wrote:

Sorry if this is a bit off-topic. It seems from these threads that there is
a more-or-less canonical way to use git to hack on Firefox. Where can I
find out more about it?

Looking online, the only information I could find was at
https://github.com/glandium/git-cinnabar/wiki/Mozilla:-A-git-workflow-for-Gecko-development.
Is that the best source of information? I didn't see anything under
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide,
http://mozilla-version-control-tools.readthedocs.io/en/latest/, or
https://firefox-source-docs.mozilla.org/.

Thanks!

Ethan


On Mon, Sep 18, 2017 at 10:05 AM, Kartikaya Gupta 
wrote:


This message was inspired by the `mach try` thread but is off-topic
there so I think deserves its own thread.

It seems to me that a lot of people are now assuming a cinnabar repo
is the canonical way for git users to develop on mozilla-central. If
we want to make this mozilla policy I don't really have objections,
but I think that if we do that, we should maintain a canonical git
repo that is built using cinnabar, rather than having everybody have
their own "grafted" version of a cinnabar repo. The problem with the
latter approach is that different people will have different SHAs for
the same upstream commit, thus making it much harder to share repos.

I've tried using cinnabar a couple of times now and the last time I
tried, this was the dealbreaker for me. My worfklow often involves
moving a branch from one machine to another and the extra hassle that
results from mismatched SHAs makes it much more complicated than it
needs to be. gecko-dev doesn't have this problem as it has a canonical
upstream that works much more like a regular git user expects.

As an aside, I also think that the cinnabar workflow as it exists now
actually demotes git to more of a "second-class citizen".
Conceptually, if you're using gecko-dev, everything works exactly as a
git user would expect, and only when you need to push to official
mozilla hg repos do you need to overcome the vcs translation hurdle
(which things like moz-git-tools help with). However if you use
cinnabar the vcs translation is more woven into your everyday git
commands (e.g. git pull) and you need to be more consciously aware of
it. This makes it harder to use whatever your normal git workflow is,
which is why I claim it demotes git to second-class. It would be great
if we could come up with a way to avoid this but honestly since I
haven't used a cinnabar workflow for any significant period of time I
haven't given much thought as to how to go about doing this.

Discussion welcome!

Cheers,
kats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


--
http://soledadpenades.com

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Canonical cinnabar repository

[Jeff Muizelaar]

I would recommend
https://github.com/glandium/git-cinnabar/wiki/Mozilla:-A-git-workflow-for-Gecko-development.

The other places should probably be updated to point at that.

-Jeff

On Wed, Sep 20, 2017 at 12:57 PM, Ethan Glasser-Camp
 wrote:
> Sorry if this is a bit off-topic. It seems from these threads that there is
> a more-or-less canonical way to use git to hack on Firefox. Where can I
> find out more about it?
>
> Looking online, the only information I could find was at
> https://github.com/glandium/git-cinnabar/wiki/Mozilla:-A-git-workflow-for-Gecko-development.
> Is that the best source of information? I didn't see anything under
> https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide,
> http://mozilla-version-control-tools.readthedocs.io/en/latest/, or
> https://firefox-source-docs.mozilla.org/.
>
> Thanks!
>
> Ethan
>
>
> On Mon, Sep 18, 2017 at 10:05 AM, Kartikaya Gupta 
> wrote:
>
>> This message was inspired by the `mach try` thread but is off-topic
>> there so I think deserves its own thread.
>>
>> It seems to me that a lot of people are now assuming a cinnabar repo
>> is the canonical way for git users to develop on mozilla-central. If
>> we want to make this mozilla policy I don't really have objections,
>> but I think that if we do that, we should maintain a canonical git
>> repo that is built using cinnabar, rather than having everybody have
>> their own "grafted" version of a cinnabar repo. The problem with the
>> latter approach is that different people will have different SHAs for
>> the same upstream commit, thus making it much harder to share repos.
>>
>> I've tried using cinnabar a couple of times now and the last time I
>> tried, this was the dealbreaker for me. My worfklow often involves
>> moving a branch from one machine to another and the extra hassle that
>> results from mismatched SHAs makes it much more complicated than it
>> needs to be. gecko-dev doesn't have this problem as it has a canonical
>> upstream that works much more like a regular git user expects.
>>
>> As an aside, I also think that the cinnabar workflow as it exists now
>> actually demotes git to more of a "second-class citizen".
>> Conceptually, if you're using gecko-dev, everything works exactly as a
>> git user would expect, and only when you need to push to official
>> mozilla hg repos do you need to overcome the vcs translation hurdle
>> (which things like moz-git-tools help with). However if you use
>> cinnabar the vcs translation is more woven into your everyday git
>> commands (e.g. git pull) and you need to be more consciously aware of
>> it. This makes it harder to use whatever your normal git workflow is,
>> which is why I claim it demotes git to second-class. It would be great
>> if we could come up with a way to avoid this but honestly since I
>> haven't used a cinnabar workflow for any significant period of time I
>> haven't given much thought as to how to go about doing this.
>>
>> Discussion welcome!
>>
>> Cheers,
>> kats
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Canonical cinnabar repository

[Ethan Glasser-Camp]

Sorry if this is a bit off-topic. It seems from these threads that there is
a more-or-less canonical way to use git to hack on Firefox. Where can I
find out more about it?

Looking online, the only information I could find was at
https://github.com/glandium/git-cinnabar/wiki/Mozilla:-A-git-workflow-for-Gecko-development.
Is that the best source of information? I didn't see anything under
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide,
http://mozilla-version-control-tools.readthedocs.io/en/latest/, or
https://firefox-source-docs.mozilla.org/.

Thanks!

Ethan


On Mon, Sep 18, 2017 at 10:05 AM, Kartikaya Gupta 
wrote:

> This message was inspired by the `mach try` thread but is off-topic
> there so I think deserves its own thread.
>
> It seems to me that a lot of people are now assuming a cinnabar repo
> is the canonical way for git users to develop on mozilla-central. If
> we want to make this mozilla policy I don't really have objections,
> but I think that if we do that, we should maintain a canonical git
> repo that is built using cinnabar, rather than having everybody have
> their own "grafted" version of a cinnabar repo. The problem with the
> latter approach is that different people will have different SHAs for
> the same upstream commit, thus making it much harder to share repos.
>
> I've tried using cinnabar a couple of times now and the last time I
> tried, this was the dealbreaker for me. My worfklow often involves
> moving a branch from one machine to another and the extra hassle that
> results from mismatched SHAs makes it much more complicated than it
> needs to be. gecko-dev doesn't have this problem as it has a canonical
> upstream that works much more like a regular git user expects.
>
> As an aside, I also think that the cinnabar workflow as it exists now
> actually demotes git to more of a "second-class citizen".
> Conceptually, if you're using gecko-dev, everything works exactly as a
> git user would expect, and only when you need to push to official
> mozilla hg repos do you need to overcome the vcs translation hurdle
> (which things like moz-git-tools help with). However if you use
> cinnabar the vcs translation is more woven into your everyday git
> commands (e.g. git pull) and you need to be more consciously aware of
> it. This makes it harder to use whatever your normal git workflow is,
> which is why I claim it demotes git to second-class. It would be great
> if we could come up with a way to avoid this but honestly since I
> haven't used a cinnabar workflow for any significant period of time I
> haven't given much thought as to how to go about doing this.
>
> Discussion welcome!
>
> Cheers,
> kats
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Canonical cinnabar repository

[Jeff Muizelaar]

On Mon, Sep 18, 2017 at 5:02 PM, Ehsan Akhgari  wrote:
> On 09/18/2017 03:30 PM, Bobby Holley wrote:
>>
>> CVS history feels like an odd bar for cinnabar. The goal of cinnabar is to
>> enable seamless integration between git and mercurial with reproducible, 1:1
>> commit mappings. Our canonical mercurial repositories don't have CVS
>> history, so we shouldn't expect the cinnabar clones of those repositories to
>> have CVS history either.
>
> FWIW the question here is moving from a canonical repository with CVS
> history to one without.

I can't think of a reason we can't have a repo with cvs history and one without.

-Jeff
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Canonical cinnabar repository

[Jean-Yves Avenard]

On Mon, Sep 18, 2017 at 4:05 PM, Kartikaya Gupta  wrote:

>
> I've tried using cinnabar a couple of times now and the last time I
> tried, this was the dealbreaker for me. My worfklow often involves
> moving a branch from one machine to another and the extra hassle that
> results from mismatched SHAs makes it much more complicated than it
> needs to be.
>

I just clone or pull the local git repo. There's no issue with SHA then.

The only time I use cinnabar is pulling/pushing from the central mercurial
repository
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Canonical cinnabar repository

[Ehsan Akhgari]

On 09/18/2017 03:30 PM, Bobby Holley wrote:
CVS history feels like an odd bar for cinnabar. The goal of cinnabar 
is to enable seamless integration between git and mercurial with 
reproducible, 1:1 commit mappings. Our canonical mercurial 
repositories don't have CVS history, so we shouldn't expect the 
cinnabar clones of those repositories to have CVS history either.
FWIW the question here is moving from a canonical repository with CVS 
history to one without.


Really, we should think of gecko-dev as an entirely different tool 
that provides full history at the cost of being read-only with respect 
to our canonical repositories. Personally, I prefer to use a cinnabar 
clone for a first-class pull/push repo experience, and using searchfox 
whenever I want to see pre-2008 blame.
Searchfox is great, and I use it a lot, but for me the CVS history in 
the repository is valuable because it integrates with my text editor, so 
I can also use it as I'm editing the code without switching to Searchfox 
and figure out where the unedited line of code comes from.




bholley

On Mon, Sep 18, 2017 at 11:35 AM, Jeff Muizelaar 
> wrote:


FWIW, https://github.com/jrmuizel/gecko-cinnabar
 doesn't have the CVS
history so is no better than https://github.com/mozilla/gecko
. Having
a canonical repo that includes the CVS history will make the SHA's
incompatible with doing a direct conversion of hg which is a
disadvantage. I'm not sure what's more valuable.

-Jeff

On Mon, Sep 18, 2017 at 2:21 PM, Ehsan Akhgari
> wrote:
> On 09/18/2017 01:16 PM, Bobby Holley wrote:
>>
>> On Mon, Sep 18, 2017 at 8:25 AM, Andrew McCreight
>
>> wrote:
>>
>>> On Mon, Sep 18, 2017 at 7:05 AM, Kartikaya Gupta
>
>>> wrote:
>>>
 I've tried using cinnabar a couple of times now and the last
time I
 tried, this was the dealbreaker for me. My worfklow often
involves
 moving a branch from one machine to another and the extra
hassle that
 results from mismatched SHAs makes it much more complicated
than it
 needs to be. gecko-dev doesn't have this problem as it has a
canonical
 upstream that works much more like a regular git user expects.

>>> For what it is worth, I regularly pull from one machine to
another with
>>> git-cinnabar, and it works just fine without any problems from
mismatched
>>> SHAs. For me, the switch from a clone of gecko-dev to
git-cinnabar has
>>> been
>>> totally transparent.
>>>
>> +1. The non-stable SHA problem was solved a long time ago. Same
goes for
>> any big performance issues. In my experience, cinnabar is
pretty darn
>> transparent.
>>
>> https://github.com/mozilla/gecko
 is effectively the canonical
repo people
>> are talking about. I sometimes pull that, but git-cinnabar is
fast enough
>> that it works fine to just clone the hg repo directly. If it
weren't for
>> the occasional annoyance of mapping commits between local revs
and hg.m.o
>> links, I would basically forget that the core infrastructure is
running
>> hg.
>
> That repo doesn't have the CVS history.  :-(  I realize that is
fixable with
> a local graft and a clone of gecko-dev, but a lot of blood and
sweat went
> into making our current canonical git repo include the full CVS
history (I
> maintained it myself for ~3 years and a lot of people spent
quite a bit of
> time and energy to stand up the current infrastructure that
maintains
> gecko-dev.)  Would it be possible to base the canonical
git-cinnabar repo on
> https://github.com/jrmuizel/gecko-cinnhabar
 which does have the
full CVS
> history?
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-platform





___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Canonical cinnabar repository

[Ehsan Akhgari]

On 09/18/2017 02:35 PM, Jeff Muizelaar wrote:

FWIW, https://github.com/jrmuizel/gecko-cinnabar doesn't have the CVS
history so is no better than https://github.com/mozilla/gecko.


Right.  Jeff corrected my confusion on IRC.  His repo has both lines of 
history, and the cinnabar conversion is on the cinnabar branch without 
the CVS history.



Having
a canonical repo that includes the CVS history will make the SHA's
incompatible with doing a direct conversion of hg which is a
disadvantage. I'm not sure what's more valuable.
I think there is a way to have our cake and eat it too, which is 
enabling git-cinnabar to understand a custom mapping of SHA1 so that we 
can rewrite the history and have cinnabar be able to deal with that when 
it maps hg/git revisions to each other.


It is difficult for me to compare these two things and say which is more 
valuable, but it seems like a very bad choice to have to choose one of 
these two alternatives.  The CVS history is extremely valuable to people 
dealing with code that still has a lot of its root back in the old 
days.  Losing it seems like a step backwards to me.




-Jeff

On Mon, Sep 18, 2017 at 2:21 PM, Ehsan Akhgari  wrote:

On 09/18/2017 01:16 PM, Bobby Holley wrote:

On Mon, Sep 18, 2017 at 8:25 AM, Andrew McCreight 
wrote:


On Mon, Sep 18, 2017 at 7:05 AM, Kartikaya Gupta 
wrote:


I've tried using cinnabar a couple of times now and the last time I
tried, this was the dealbreaker for me. My worfklow often involves
moving a branch from one machine to another and the extra hassle that
results from mismatched SHAs makes it much more complicated than it
needs to be. gecko-dev doesn't have this problem as it has a canonical
upstream that works much more like a regular git user expects.


For what it is worth, I regularly pull from one machine to another with
git-cinnabar, and it works just fine without any problems from mismatched
SHAs. For me, the switch from a clone of gecko-dev to git-cinnabar has
been
totally transparent.


+1. The non-stable SHA problem was solved a long time ago. Same goes for
any big performance issues. In my experience, cinnabar is pretty darn
transparent.

https://github.com/mozilla/gecko is effectively the canonical repo people
are talking about. I sometimes pull that, but git-cinnabar is fast enough
that it works fine to just clone the hg repo directly. If it weren't for
the occasional annoyance of mapping commits between local revs and hg.m.o
links, I would basically forget that the core infrastructure is running
hg.

That repo doesn't have the CVS history.  :-(  I realize that is fixable with
a local graft and a clone of gecko-dev, but a lot of blood and sweat went
into making our current canonical git repo include the full CVS history (I
maintained it myself for ~3 years and a lot of people spent quite a bit of
time and energy to stand up the current infrastructure that maintains
gecko-dev.)  Would it be possible to base the canonical git-cinnabar repo on
https://github.com/jrmuizel/gecko-cinnhabar which does have the full CVS
history?

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Canonical cinnabar repository

[Bobby Holley]

CVS history feels like an odd bar for cinnabar. The goal of cinnabar is to
enable seamless integration between git and mercurial with reproducible,
1:1 commit mappings. Our canonical mercurial repositories don't have CVS
history, so we shouldn't expect the cinnabar clones of those repositories
to have CVS history either.

Really, we should think of gecko-dev as an entirely different tool that
provides full history at the cost of being read-only with respect to our
canonical repositories. Personally, I prefer to use a cinnabar clone for a
first-class pull/push repo experience, and using searchfox whenever I want
to see pre-2008 blame.

bholley

On Mon, Sep 18, 2017 at 11:35 AM, Jeff Muizelaar 
wrote:

> FWIW, https://github.com/jrmuizel/gecko-cinnabar doesn't have the CVS
> history so is no better than https://github.com/mozilla/gecko. Having
> a canonical repo that includes the CVS history will make the SHA's
> incompatible with doing a direct conversion of hg which is a
> disadvantage. I'm not sure what's more valuable.
>
> -Jeff
>
> On Mon, Sep 18, 2017 at 2:21 PM, Ehsan Akhgari 
> wrote:
> > On 09/18/2017 01:16 PM, Bobby Holley wrote:
> >>
> >> On Mon, Sep 18, 2017 at 8:25 AM, Andrew McCreight <
> amccrei...@mozilla.com>
> >> wrote:
> >>
> >>> On Mon, Sep 18, 2017 at 7:05 AM, Kartikaya Gupta 
> >>> wrote:
> >>>
>  I've tried using cinnabar a couple of times now and the last time I
>  tried, this was the dealbreaker for me. My worfklow often involves
>  moving a branch from one machine to another and the extra hassle that
>  results from mismatched SHAs makes it much more complicated than it
>  needs to be. gecko-dev doesn't have this problem as it has a canonical
>  upstream that works much more like a regular git user expects.
> 
> >>> For what it is worth, I regularly pull from one machine to another with
> >>> git-cinnabar, and it works just fine without any problems from
> mismatched
> >>> SHAs. For me, the switch from a clone of gecko-dev to git-cinnabar has
> >>> been
> >>> totally transparent.
> >>>
> >> +1. The non-stable SHA problem was solved a long time ago. Same goes for
> >> any big performance issues. In my experience, cinnabar is pretty darn
> >> transparent.
> >>
> >> https://github.com/mozilla/gecko is effectively the canonical repo
> people
> >> are talking about. I sometimes pull that, but git-cinnabar is fast
> enough
> >> that it works fine to just clone the hg repo directly. If it weren't for
> >> the occasional annoyance of mapping commits between local revs and
> hg.m.o
> >> links, I would basically forget that the core infrastructure is running
> >> hg.
> >
> > That repo doesn't have the CVS history.  :-(  I realize that is fixable
> with
> > a local graft and a clone of gecko-dev, but a lot of blood and sweat went
> > into making our current canonical git repo include the full CVS history
> (I
> > maintained it myself for ~3 years and a lot of people spent quite a bit
> of
> > time and energy to stand up the current infrastructure that maintains
> > gecko-dev.)  Would it be possible to base the canonical git-cinnabar
> repo on
> > https://github.com/jrmuizel/gecko-cinnhabar which does have the full CVS
> > history?
> >
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Canonical cinnabar repository

[Jeff Muizelaar]

FWIW, https://github.com/jrmuizel/gecko-cinnabar doesn't have the CVS
history so is no better than https://github.com/mozilla/gecko. Having
a canonical repo that includes the CVS history will make the SHA's
incompatible with doing a direct conversion of hg which is a
disadvantage. I'm not sure what's more valuable.

-Jeff

On Mon, Sep 18, 2017 at 2:21 PM, Ehsan Akhgari  wrote:
> On 09/18/2017 01:16 PM, Bobby Holley wrote:
>>
>> On Mon, Sep 18, 2017 at 8:25 AM, Andrew McCreight 
>> wrote:
>>
>>> On Mon, Sep 18, 2017 at 7:05 AM, Kartikaya Gupta 
>>> wrote:
>>>
 I've tried using cinnabar a couple of times now and the last time I
 tried, this was the dealbreaker for me. My worfklow often involves
 moving a branch from one machine to another and the extra hassle that
 results from mismatched SHAs makes it much more complicated than it
 needs to be. gecko-dev doesn't have this problem as it has a canonical
 upstream that works much more like a regular git user expects.

>>> For what it is worth, I regularly pull from one machine to another with
>>> git-cinnabar, and it works just fine without any problems from mismatched
>>> SHAs. For me, the switch from a clone of gecko-dev to git-cinnabar has
>>> been
>>> totally transparent.
>>>
>> +1. The non-stable SHA problem was solved a long time ago. Same goes for
>> any big performance issues. In my experience, cinnabar is pretty darn
>> transparent.
>>
>> https://github.com/mozilla/gecko is effectively the canonical repo people
>> are talking about. I sometimes pull that, but git-cinnabar is fast enough
>> that it works fine to just clone the hg repo directly. If it weren't for
>> the occasional annoyance of mapping commits between local revs and hg.m.o
>> links, I would basically forget that the core infrastructure is running
>> hg.
>
> That repo doesn't have the CVS history.  :-(  I realize that is fixable with
> a local graft and a clone of gecko-dev, but a lot of blood and sweat went
> into making our current canonical git repo include the full CVS history (I
> maintained it myself for ~3 years and a lot of people spent quite a bit of
> time and energy to stand up the current infrastructure that maintains
> gecko-dev.)  Would it be possible to base the canonical git-cinnabar repo on
> https://github.com/jrmuizel/gecko-cinnhabar which does have the full CVS
> history?
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Canonical cinnabar repository

[Ehsan Akhgari]

On 09/18/2017 01:16 PM, Bobby Holley wrote:

On Mon, Sep 18, 2017 at 8:25 AM, Andrew McCreight 
wrote:


On Mon, Sep 18, 2017 at 7:05 AM, Kartikaya Gupta 
wrote:


I've tried using cinnabar a couple of times now and the last time I
tried, this was the dealbreaker for me. My worfklow often involves
moving a branch from one machine to another and the extra hassle that
results from mismatched SHAs makes it much more complicated than it
needs to be. gecko-dev doesn't have this problem as it has a canonical
upstream that works much more like a regular git user expects.


For what it is worth, I regularly pull from one machine to another with
git-cinnabar, and it works just fine without any problems from mismatched
SHAs. For me, the switch from a clone of gecko-dev to git-cinnabar has been
totally transparent.


+1. The non-stable SHA problem was solved a long time ago. Same goes for
any big performance issues. In my experience, cinnabar is pretty darn
transparent.

https://github.com/mozilla/gecko is effectively the canonical repo people
are talking about. I sometimes pull that, but git-cinnabar is fast enough
that it works fine to just clone the hg repo directly. If it weren't for
the occasional annoyance of mapping commits between local revs and hg.m.o
links, I would basically forget that the core infrastructure is running hg.
That repo doesn't have the CVS history.  :-(  I realize that is fixable 
with a local graft and a clone of gecko-dev, but a lot of blood and 
sweat went into making our current canonical git repo include the full 
CVS history (I maintained it myself for ~3 years and a lot of people 
spent quite a bit of time and energy to stand up the current 
infrastructure that maintains gecko-dev.)  Would it be possible to base 
the canonical git-cinnabar repo on 
https://github.com/jrmuizel/gecko-cinnhabar which does have the full CVS 
history?

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Canonical cinnabar repository

[Bobby Holley]

On Mon, Sep 18, 2017 at 8:25 AM, Andrew McCreight 
wrote:

> On Mon, Sep 18, 2017 at 7:05 AM, Kartikaya Gupta 
> wrote:
>
> > I've tried using cinnabar a couple of times now and the last time I
> > tried, this was the dealbreaker for me. My worfklow often involves
> > moving a branch from one machine to another and the extra hassle that
> > results from mismatched SHAs makes it much more complicated than it
> > needs to be. gecko-dev doesn't have this problem as it has a canonical
> > upstream that works much more like a regular git user expects.
> >
>
> For what it is worth, I regularly pull from one machine to another with
> git-cinnabar, and it works just fine without any problems from mismatched
> SHAs. For me, the switch from a clone of gecko-dev to git-cinnabar has been
> totally transparent.
>

+1. The non-stable SHA problem was solved a long time ago. Same goes for
any big performance issues. In my experience, cinnabar is pretty darn
transparent.

https://github.com/mozilla/gecko is effectively the canonical repo people
are talking about. I sometimes pull that, but git-cinnabar is fast enough
that it works fine to just clone the hg repo directly. If it weren't for
the occasional annoyance of mapping commits between local revs and hg.m.o
links, I would basically forget that the core infrastructure is running hg.

bholley



> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Canonical cinnabar repository

[Gregory Szorc]

A few posts here and in the other thread have mentioned abstracting away
complexity to servers as if it is a magical solution that makes all
problems go away.

Yes, deploying a server-side solution to do some "syncing" is doable and
solves a subset of notable problems.

But I advise extreme caution against asserting simplicity for anything.

One of the large shifts that we're starting to see take place for Firefox
tooling are the breakdown of the barriers between a) the build system and
version control b) the build system and automation. Transitively, we're
seeing all 3 of these things (which are easy to mentally model as
independent concepts) start to merge. This is both terrifying and exciting.

I really owe a blog post or gdoc or something on this topic, but
essentially we're at a few tipping points in terms of scale where we need
tighter cohesion between these systems to continue to scale in a way that
meets developers' needs. Artifact builds are an example of such a system.
Automation builds these artifacts and indexes against the version control
revision (currently Mercurial). The build system ties it all together. In
order to use an artifact build locally, you need to find an artifact build
from automation. This means knowing the indexed version control revision.
With git-cinnabar, the commit map is locally known (read: fast and
well-defined). With vanilla Git, that commit map is... not local. (Yes, we
could work our way out of this commit mapping problem using various
mechanisms (notably caching and/or content-based hashing for indexing). But
there is no obvious solution at this time.) Artifact builds are only the
tip of the iceberg for this class of problem.

In 2-4 years I see us in a position where version control, the build
system, and automation function as one logical system working in harmony.
We're still in the early stages of this shift, which is probably why you
haven't noticed it. Therefore, decisions and policies around how to support
version control today thus incur a magnitude more effort to support down
the road (and even then may result in poorer outcomes for the user base not
on the "primary" set of tools). I'm particularly sensitive to the butterfly
effect on this (likely inevitable) transition and I don't want to hamstring
future productivity efforts by committing us to a short-sighted version
control support policy that won't easily scale.

That being said, I think a canonical git-cinnabar repository might be
doable. I view that as a glorified cache to offload the expensive
first-time conversion. But using it with vanilla Git is a bit more
concerning from a future compatibility perspective, so we should set
expectations for appropriate use accordingly.

On Mon, Sep 18, 2017 at 8:59 AM, Nicholas Hurley  wrote:

> I've had quite a few times (every time I get a new machine) that I've had
> issues with git-cinnabar and multiple machines. This has resulted in me
> just scp'ing my entire repo every time I get a new machine (which comes
> with its own set of issues... messed up paths in the .git/config, for
> example). I grant that some of this is due to my own stupidity, but aren't
> tools supposed to make it harder for one's own stupidity to get in the way?
>
> I haven't even tried to share anything with anyone else via git, I just
> send them a patch. The chance of mismatched sha's is Too Damn High! This
> is, as the saying goes, suboptimal.
>
> All this to say, I think having an official cinnabar repo (preferably with
> cinnabar metadata I can fetch, too) would make things significantly easier
> for a lot of use-cases, and I can't think of a single use-case that it
> would make things worse for over the long-term (ie, once we have autoland
> everywhere and no manual pushes to m-c or try). The initial fetch might
> take a while if we include metadata, but that's a one-time (per machine)
> cost.
>
> Even better would be the "all the magic happens server-side" solution. Then
> I could Just Use Git, and never have to worry about any of this junk ever
> again.
>
> On Mon, Sep 18, 2017 at 8:25 AM, Andrew McCreight 
> wrote:
>
> > On Mon, Sep 18, 2017 at 7:05 AM, Kartikaya Gupta 
> > wrote:
> >
> > > I've tried using cinnabar a couple of times now and the last time I
> > > tried, this was the dealbreaker for me. My worfklow often involves
> > > moving a branch from one machine to another and the extra hassle that
> > > results from mismatched SHAs makes it much more complicated than it
> > > needs to be. gecko-dev doesn't have this problem as it has a canonical
> > > upstream that works much more like a regular git user expects.
> > >
> >
> > For what it is worth, I regularly pull from one machine to another with
> > git-cinnabar, and it works just fine without any problems from mismatched
> > SHAs. For me, the switch from a clone of gecko-dev to git-cinnabar has
> been
> > totally transparent.
> > 

Re: Canonical cinnabar repository

[Kartikaya Gupta]

On Mon, Sep 18, 2017 at 11:04 AM, Myk Melez  wrote:
> Having said that, I agree that it's worth enabling developers to clone a
> canonical Git repo. I've been syncing mozilla/gecko using cinnabar for a
> while to experiment with ways of doing this.

That's great, thanks. If we can do something like this but (a) with
all the pre-mercurial history, and (b) include integration/release
branches, that would basically be exactly what I want as a canonical
upstream cinnabar repo.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Canonical cinnabar repository

[Nicholas Hurley]

I've had quite a few times (every time I get a new machine) that I've had
issues with git-cinnabar and multiple machines. This has resulted in me
just scp'ing my entire repo every time I get a new machine (which comes
with its own set of issues... messed up paths in the .git/config, for
example). I grant that some of this is due to my own stupidity, but aren't
tools supposed to make it harder for one's own stupidity to get in the way?

I haven't even tried to share anything with anyone else via git, I just
send them a patch. The chance of mismatched sha's is Too Damn High! This
is, as the saying goes, suboptimal.

All this to say, I think having an official cinnabar repo (preferably with
cinnabar metadata I can fetch, too) would make things significantly easier
for a lot of use-cases, and I can't think of a single use-case that it
would make things worse for over the long-term (ie, once we have autoland
everywhere and no manual pushes to m-c or try). The initial fetch might
take a while if we include metadata, but that's a one-time (per machine)
cost.

Even better would be the "all the magic happens server-side" solution. Then
I could Just Use Git, and never have to worry about any of this junk ever
again.

On Mon, Sep 18, 2017 at 8:25 AM, Andrew McCreight 
wrote:

> On Mon, Sep 18, 2017 at 7:05 AM, Kartikaya Gupta 
> wrote:
>
> > I've tried using cinnabar a couple of times now and the last time I
> > tried, this was the dealbreaker for me. My worfklow often involves
> > moving a branch from one machine to another and the extra hassle that
> > results from mismatched SHAs makes it much more complicated than it
> > needs to be. gecko-dev doesn't have this problem as it has a canonical
> > upstream that works much more like a regular git user expects.
> >
>
> For what it is worth, I regularly pull from one machine to another with
> git-cinnabar, and it works just fine without any problems from mismatched
> SHAs. For me, the switch from a clone of gecko-dev to git-cinnabar has been
> totally transparent.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Canonical cinnabar repository

[Andrew McCreight]

On Mon, Sep 18, 2017 at 7:05 AM, Kartikaya Gupta  wrote:

> I've tried using cinnabar a couple of times now and the last time I
> tried, this was the dealbreaker for me. My worfklow often involves
> moving a branch from one machine to another and the extra hassle that
> results from mismatched SHAs makes it much more complicated than it
> needs to be. gecko-dev doesn't have this problem as it has a canonical
> upstream that works much more like a regular git user expects.
>

For what it is worth, I regularly pull from one machine to another with
git-cinnabar, and it works just fine without any problems from mismatched
SHAs. For me, the switch from a clone of gecko-dev to git-cinnabar has been
totally transparent.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Canonical cinnabar repository

[Jeff Muizelaar]

I agree having a canonical version would be very valuable. In the mean
time if you want to avoid having to do the entire conversion locally
you can start by cloning the cinnabar branch of
https://github.com/jrmuizel/gecko-cinnabar which is a local full
conversion that I painfully uploaded to github.

-Jeff

On Mon, Sep 18, 2017 at 11:04 AM, Myk Melez  wrote:
>> Kartikaya Gupta 
>> 2017 September 18 at 07:05
>> It seems to me that a lot of people are now assuming a cinnabar repo
>> is the canonical way for git users to develop on mozilla-central. If
>> we want to make this mozilla policy I don't really have objections,
>> but I think that if we do that, we should maintain a canonical git
>> repo that is built using cinnabar, rather than having everybody have
>> their own "grafted" version of a cinnabar repo. The problem with the
>> latter approach is that different people will have different SHAs for
>> the same upstream commit, thus making it much harder to share repos.
>
> Note that there's a third option, which is for everyone to have their own
> non-grafted version of a cinnabar repo. If you clone mozilla-central using
> cinnabar, instead of grafting commits onto a gecko-dev clone, then that's
> what you get, since cinnabar revision ID conversion is deterministic (as I
> understand it, anyway).
>
> Having said that, I agree that it's worth enabling developers to clone a
> canonical Git repo. I've been syncing mozilla/gecko using cinnabar for a
> while to experiment with ways of doing this. There've also been
> conversations about syncing new commits to mozilla/gecko-dev with cinnabar
> for a few years, although I don't know of any active efforts to do this.
>
> -myk
>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Canonical cinnabar repository

[Myk Melez]

Kartikaya Gupta 
2017 September 18 at 07:05
It seems to me that a lot of people are now assuming a cinnabar repo
is the canonical way for git users to develop on mozilla-central. If
we want to make this mozilla policy I don't really have objections,
but I think that if we do that, we should maintain a canonical git
repo that is built using cinnabar, rather than having everybody have
their own "grafted" version of a cinnabar repo. The problem with the
latter approach is that different people will have different SHAs for
the same upstream commit, thus making it much harder to share repos.
Note that there's a third option, which is for everyone to have their 
own non-grafted version of a cinnabar repo. If you clone mozilla-central 
using cinnabar, instead of grafting commits onto a gecko-dev clone, then 
that's what you get, since cinnabar revision ID conversion is 
deterministic (as I understand it, anyway).


Having said that, I agree that it's worth enabling developers to clone a 
canonical Git repo. I've been syncing mozilla/gecko using cinnabar for a 
while to experiment with ways of doing this. There've also been 
conversations about syncing new commits to mozilla/gecko-dev with 
cinnabar for a few years, although I don't know of any active efforts to 
do this.


-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform