info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Canonical cinnabar repository
214 views
Skip to first unread message
Kartikaya Gupta
Sep 18, 2017, 10:05:17 AM9/18/17
to dev-platform
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
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
Myk Melez
Sep 18, 2017, 11:05:15 AM9/18/17
to Kartikaya Gupta, dev-platform
> Kartikaya Gupta <mailto:kgu...@mozilla.com>
> 2017 September 18 at 07:05
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
> 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
> 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.
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
Nicholas Hurley
Sep 18, 2017, 11:59:16 AM9/18/17
to Andrew McCreight, dev-platform, Kartikaya Gupta
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 <amccr...@mozilla.com>
wrote:
> On Mon, Sep 18, 2017 at 7:05 AM, Kartikaya Gupta <kgu...@mozilla.com>
> 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-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
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 <amccr...@mozilla.com>
wrote:
> On Mon, Sep 18, 2017 at 7:05 AM, Kartikaya Gupta <kgu...@mozilla.com>
> 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.
> >
>
> 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-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
Bobby Holley
Sep 18, 2017, 1:16:32 PM9/18/17
to Andrew McCreight, dev-platform, Kartikaya Gupta
On Mon, Sep 18, 2017 at 8:25 AM, Andrew McCreight <amccr...@mozilla.com>
wrote:
> On Mon, Sep 18, 2017 at 7:05 AM, Kartikaya Gupta <kgu...@mozilla.com>
> 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
wrote:
> On Mon, Sep 18, 2017 at 7:05 AM, Kartikaya Gupta <kgu...@mozilla.com>
> 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.
>
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
Jeff Muizelaar
Sep 18, 2017, 2:36:05 PM9/18/17
to Ehsan Akhgari, dev-platform, Andrew McCreight, Bobby Holley, Kartikaya Gupta
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 <ehsan....@gmail.com> wrote:
> 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?
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 <ehsan....@gmail.com> wrote:
> 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?
Bobby Holley
Sep 18, 2017, 3:32:53 PM9/18/17
to Jeff Muizelaar, dev-platform, Ehsan Akhgari, Andrew McCreight, Kartikaya Gupta
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 <jmuiz...@mozilla.com>
wrote:
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 <jmuiz...@mozilla.com>
wrote:
Ehsan Akhgari
Sep 18, 2017, 4:56:16 PM9/18/17
to Jeff Muizelaar, dev-platform, Mike Hommey, Andrew McCreight, Bobby Holley, Kartikaya Gupta
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
> FWIW, https://github.com/jrmuizel/gecko-cinnabar doesn't have the CVS
> history so is no better than https://github.com/mozilla/gecko.
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.
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.
Ehsan Akhgari
Sep 18, 2017, 5:03:01 PM9/18/17
to Bobby Holley, Jeff Muizelaar, dev-platform, Andrew McCreight, Kartikaya Gupta
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
> 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.
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.
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
> <jmuiz...@mozilla.com <mailto:jmuiz...@mozilla.com>> wrote:
>
> FWIW, https://github.com/jrmuizel/gecko-cinnabar
> <https://github.com/jrmuizel/gecko-cinnabar> doesn't have the CVS
> history so is no better than https://github.com/mozilla/gecko
> <https://github.com/mozilla/gecko>. Having
> history so is no better than https://github.com/mozilla/gecko
> 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.
>
> 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
> <ehsan....@gmail.com <mailto:ehsan....@gmail.com>> wrote:
> > On 09/18/2017 01:16 PM, Bobby Holley wrote:
> >>
> >> On Mon, Sep 18, 2017 at 8:25 AM, Andrew McCreight
> <amccr...@mozilla.com <mailto:amccr...@mozilla.com>>
>
> On Mon, Sep 18, 2017 at 2:21 PM, Ehsan Akhgari
> <ehsan....@gmail.com <mailto:ehsan....@gmail.com>> 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
> <kgu...@mozilla.com <mailto:kgu...@mozilla.com>>
> >>
> >>> On Mon, Sep 18, 2017 at 7:05 AM, Kartikaya Gupta
> > https://lists.mozilla.org/listinfo/dev-platform
> <https://lists.mozilla.org/listinfo/dev-platform>
>
>
Jean-Yves Avenard
Sep 19, 2017, 11:18:27 AM9/19/17
to Kartikaya Gupta, dev-platform
On Mon, Sep 18, 2017 at 4:05 PM, Kartikaya Gupta <kgu...@mozilla.com> 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.
>
> 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.
>
The only time I use cinnabar is pulling/pushing from the central mercurial
repository
Jeff Muizelaar
Sep 20, 2017, 1:04:16 PM9/20/17
to Ethan Glasser-Camp, dev-platform, Kartikaya Gupta
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
<eglass...@mozilla.com> 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
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
<eglass...@mozilla.com> 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 <kgu...@mozilla.com>
> wrote:
>
>> This message was inspired by the `mach try` thread but is off-topic
>> there so I think deserves its own thread.
>>
>
> On Mon, Sep 18, 2017 at 10:05 AM, Kartikaya Gupta <kgu...@mozilla.com>
> 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.
>>
>> 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
>> 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.
>>
>> 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
>> 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-pl...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>> dev-platform mailing list
>> dev-pl...@lists.mozilla.org
>>
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
J. Ryan Stinnett
Sep 20, 2017, 1:18:34 PM9/20/17
to Jeff Muizelaar, Ethan Glasser-Camp, dev-platform, Kartikaya Gupta
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 <jmuiz...@mozilla.com>
wrote:
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 <jmuiz...@mozilla.com>
wrote:
Myk Melez
Sep 20, 2017, 11:30:47 PM9/20/17
to Ehsan Akhgari, Kartikaya Gupta, Andrew McCreight, Bobby Holley, Mike Hommey, Jeff Muizelaar, dev-platform
> Ehsan Akhgari <mailto:ehsan....@gmail.com>
> 2017 September 18 at 12:59
"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
> 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
> 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.
"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
Kartikaya Gupta
Sep 26, 2017, 11:50:11 AM9/26/17
to David House, Myk Melez, dev-platform
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.
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.
Myk Melez
Sep 26, 2017, 8:41:10 PM9/26/17
to Kartikaya Gupta, dev-platform, David House
> Kartikaya Gupta <mailto:kgu...@mozilla.com>
> 2017 September 26 at 08:49
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
<https://wiki.mozilla.org/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
> 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
> 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.
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.
GitHub/Gecko_Repositories
<https://wiki.mozilla.org/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.
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.
-myk
Jonathan Watt
Oct 9, 2017, 12:17:04 PM10/9/17
to Kartikaya Gupta, David House, Myk Melez, dev-platform
On 26/09/2017 16:49, Kartikaya Gupta wrote:
> 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 filed https://bugzilla.mozilla.org/show_bug.cgi?id=1406792 to keep the ball
> 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?
rolling.
Jonathan Watt
Oct 9, 2017, 12:17:10 PM10/9/17
to Kartikaya Gupta, David House, Myk Melez, dev-platform
On 26/09/2017 16:49, Kartikaya Gupta wrote:
> 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?
> take over ownership of the mozilla/gecko mirror. dhouse, do you know
> what the process would be for that?
Myk Melez
Oct 18, 2017, 7:28:23 PM10/18/17
to dev-platform
> Myk Melez <mailto:m...@mykzilla.org>
> 2017 September 26 at 17:40
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
> 2017 September 26 at 17:40
>> Kartikaya Gupta <mailto:kgu...@mozilla.com>
>> 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,
>> 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.
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/*'
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
0 new messages