search

git-for-windows / git

A fork of Git containing Windows-specific patches.
http://gitforwindows.org/
Other
8.22k stars 2.5k forks source link

I would like to have permission to publish your app on the Windows Store #1146

Closed dgsimone15 closed 11 months ago

dgsimone15 commented 7 years ago

Hi, I'm part of the UWP Open Source Community (https://github.com/UWP-Open-Source-Community). Our intent is to take Win32 Open Source applications and convert them into UWP apps through the Windows Bridge (Project Centennial). We like your app and that's why we decided to convert it. In case you would like to take charge of this app and publish it yourself on the store (make us very pleased) contact us the first possible please! Otherwise, we may be responsible for publishing your app. If you do not want to take over the publication on the Store, can you give us permission to do so? Sorry for my poor English. Thanks for your help.

dscho commented 7 years ago

If you tell me how to wrap Git for Windows as UWP app, and how to upload it to the Store, I can try to incorporate that into my regular release process.

shiftkey commented 7 years ago

@dgsimone15 what benefits are there to the porting process and making it into a UWP app?

dgsimone15 commented 7 years ago

@shiftkey, UWP applications have more recent and advanced frameworks ... but since in the simple porting the app does not become native to 100% you will not have these advantages immediately ... anyway, a UWP application compiled with Visual Studio 2017 is compiled with .NET Native that gives it up to 12% more performance and lighterness. You have access to all new Windows APIs and what's going to be a future, just because you can control and integrate interactive notifications, Action Center, Cortana, Neon, Live Titles, etc ... with a little extra effort. Upload it to the store, and then have more visibility as well as a better upgrade system, a better user approach: Search-> Install. The ability to install it with a click and uninstall it at the same speed, the ability to access the major features that the OS offers for these software, such as the native SandBox, and therefore the best security, reset and reset the application etc ...

dgsimone15 commented 7 years ago

For example you can see here some of the projects on which we started working: https://github.com/UWP-Open-Source-Community

shiftkey commented 7 years ago

@dgsimone15 this really doesn't feel like it benefits the Git for Windows project but I'll defer to @dscho on whether it's worth investing time in.

dgsimone15 commented 7 years ago

Thanks!!!

dscho commented 7 years ago

Git for Windows will always stay relatively close to upstream Git, meaning that a one-time conversion is not an option. In that light, I think it may be easier to try to wrap Git for Windows as an APPX. If you can help us automate that, I would be very interested!

dgsimone15 commented 7 years ago

Fantastic !! we invite you to visit our humble community, GitHub: https: //github.com/UWP-Open-Source-Community and Telegram: https://t.me/joinchat/AAAAAAwQXHEh77kozW9DFQ we have already converted some programs and believe That for voied your software there will be no problem ... when I found that the new version of Windows (Cloud) could turn Centennial Converted Software I immediately thought to you because your software could be really useful for the school. During the conversation there should be no big problems, only a few things should be able to cause a small retouch in the code ... the icons, but this is not difficult, just put the right icons in the right folder and write some lines of code (in our documentation will be possible Download a file that automates even more the process, it takes only a few minutes for that). They may bother log extensions and registry keys. Since the software runs in SandBox and not to dirty and degrade the performance of the operating system, have removed all the logs to the registry, this could be a small problem because it could cause the links to disappear (so need a little modification). So there are updates Automatic, since there is no alternative update system on the store (there may be but should be differentiated from that of Win32 software, which is very useless is uncomfortable since it is one of the main advantages of the store). In any case, The process does not require any great effort, and the result beyond these finesse is excellent. Clearly it's a Bridge, it's the beginning, it will not take native UWP native software, it will not enjoy huge performance benefits, it will not be able to take it to other platforms Windows 10, but the OS recognizes it as UWP and all the features that the OS have in addition are perfectly functional (See Slack, was brought via Centennial, you can answer Carlo, reset etc ...), and the ability to use the latest UWP Windows APIs. In any case you can see some of our Open source software (initial) porting On GitHub, the back of the documentation adds it here even if I always recommend watching Channel 9 or official Microsoft channels where the operation is well explained. Https://github.com/UWP-Open-Source-Community/Documentation/tree/master/DesktopBridge

PhilipOakley commented 7 years ago

@dgsimone15, A few spaces and blank lines between the paragraphs of the UWP blub would not come amiss ;-)

It was hard to read it all in one breath. Hope it all goes well.

dgsimone15 commented 7 years ago

Sorry for my poor englesh😔

dscho commented 7 years ago

I still do not know how to start converting :frowning_face: I had hoped for a little more explicit guidance so that I can fit the conversion in between bug fixes and new features for Git.

dgsimone15 commented 7 years ago

This is not a problem!! I'm happy to help you!! Start by having to send a trusted and reliable source. This is a demonstration video where VLC is "bundled" as a Demo. Made by two Microsoft engineers: "https://channel9.msdn.com/events/Build/2016/P504", if you want to have a faster (maybe initial) experience, you can also use: https://bridge10.azurewebsites.net" or the Online version. If you want a better contact system (I realize the limits of GitHub and its discomfort) I will try to find a solution !! In the meantime I rewrite your request to the team, they will be very happy and everyone will participate in their own way to help you!! For whatever you can ask, but the guide to getting started is quite exhaustive :) I felt the need to show it !!! Ask me anything else!! Can I ask you a question? What software does your framework use? I warn you that for security issues before publishing your story app will have to have a module at Microsofot along with the installer, the software will have to pass tests to test bugs and issues (Microsoft is responsible for tight security and wants to avoid There may be problems with customers) In any case I suggest waiting for Bud 2017, the image of the software is old and must receive a Major Update, Microsoft would be thinking of giving everyone the ability to convert and publish without any problems and could There are also other interesting news!

dscho commented 7 years ago

What software does your framework use?

As Git is written (mostly) in plain C, we use the Microsoft Visual C Runtime. No MFC, no ATL, no .NET. Plain Win32 API, for backwards compatibility.

Almost certainly not what you wanted to hear, right?

Ask me anything else!!

How does a Windows Store application differ from what we have right now (i.e. a stand-alone installer)? Like, specifically, e.g. is it like a .zip file with a certain directory layout a la NuGet, or is it more like an .msi?

dgsimone15 commented 7 years ago

The windows store appx file is like a zip file that can be installed via the store or easily double click on it. It extract all the programs data to an hidden folder and can be moved between disks from settings. You can delete it without an uninstaller everything get erased without leaving any trace. All the data must be on the main hidden folder. The app will be updated directly via the store without installer and only the edited byte will be downloaded, so you don't have to download the entire new version. The app edit a copy of the registry so it doesn't slow the pc.

dgsimone15 commented 7 years ago

No, indeed !! It's perfect ... unfortunately some software (eg those written in Java) can not be converted !! You should not have any problem with converting, as soon as I try to conjure myself (if I can) the software to see if there are any complications (even if they should not be). For the Online version the software has to be written with a frame above 4.1.6, but it is not a problem, because (as I have already said), the Online version is more a test, it is better to use the real software.

jfmherokiller commented 7 years ago

this is just my two cents but i don't think a command line application would be good for uwp unless it's possible to create shims or symlinks to files such as git.exe. This is because it would break a lot of my powershell based pre-commit hooks which rely on files like git.exe to exist and be on the path.

dscho commented 7 years ago

For the Online version the software has to be written with a frame above 4.1.6, but it is not a problem, because (as I have already said), the Online version is more a test, it is better to use the real software.

Whatever that Online version is, I cannot use it, because (as I pointed out) Git for Windows is not implemented in C# let alone uses the .NET framework.

That leaves me curious as to what the "real" software is.

I am still puzzled how I would start to convert, and what it would take to make an .appx (is that the right way to describe it? I really did not get much in the way of details of the process so far).

Maybe a concrete, tiny example would help me understand what it would entail to package some software and to publish it via the Windows Store.

shiftkey commented 7 years ago

@dscho the instructions for manually porting a project are here - you create a manifest and run a tool against the files your installer needs, and can then test it locally to see how it performs. That's probably the quickest way to dip your toes into this.

The debugging instructions might also be helpful, depending on how you prefer to debug Git for Windows.

Lastly, the behind the scenes bit is probably very important to read, as it explains what your app can and cannot do once it's bundled in this way.

dgsimone15 commented 7 years ago

@shiftkey thank you for your contribution. @dscho I would like to add some information that might be useful to you. Windows Cloud (the official name is Windows 10S) was announced during #MicrosoftEducation, and works exactly as expected (with some additional features). After the announcement they also announced the arrival of important software such as iTunes, Spotify, Office and Adobe Creative Cloud Platform ... at the same time these ads came from Inkscape, Telegram, WhatsApp (beta), Gravit Design etc ... I recommend Try at least one of these converted software to understand how they work ... try first a software that has been converted for more time than Slack, and a recent one like Telegram (which does not yet use any of the new Windows APIs because it just came) . In addition, they announced that Windows 10 is the most used desktop operating system in the world, this is important to you since most people use it more than one person have access to the store. Finally, here is the link to the Microsoft Windows Desktop Bridge official page, from which you can access the documentation (where it explains how and where it works) and ask for a contact form for Microsoft. So in case you wanted more news, who better than Microsoft could help us !!? Also because (for now) to publish on the store you need to have Microsoft's consent through this form ... here are the two links to you: developer.microsoft.com/en-us/windows/bridges

developer.microsoft.com/en-us/windows/projects/campaigns/desktop

Sorry for my poor english

YasharF commented 6 years ago

+1 for having a published app in the Microsoft Store

A benefit that I like to gain is that Microsoft Store in Windows 10 does automated app updates without user intervention in the background (I think they happen when the system is idle). I like to depart from having to manually check to see if I am running an out of date version of the binaries, followed by downloading and installing the latest version; and instead always get the benefits of the latest version without any effort or disruptions :)

dscho commented 6 years ago

+1 for having a published app in the Microsoft Store

Okay, I'll bite. Just how much do you +1 this? Enough to put in a bit of energy and time yourself? Assuming you do, these are the issues that need to be addressed:

dscho commented 4 years ago

For the record, I would still be interested in helping with this project. I just cannot drive it myself, it will need a volunteer enthusiastic enough to tackle it.

duble0 commented 4 years ago

For the record, I would still be interested in helping with this project. I just cannot drive it myself, it will need a volunteer enthusiastic enough to tackle it.

Hi dscho! I'm pleased that you are interested, I don't know what is your plan for convert Git… in my opinion the best way is to convert Git with GUI or a client with open license. For do this you can use directly MSIX Packaging Tool, follow the instructions and Bang!.. you done it..it will be a clone of the exe software. If you are interested to improvements like a version for ARM64 PC (Aarch64) you must start from the code and recompile it with visualstudio! At the same time, you can take the opportunity and add a UWP interface and/or windows functions like notification (in example if someone make changes over your code)… But this meaning more work and I can't support you...

dscho commented 4 years ago

in my opinion the best way is to convert Git with GUI or a client with open license.

Well, you know, that's just your opinion, man.

I guess I should start to wonder how Python did it instead.

If you are interested to improvements like a version for ARM64 PC (Aarch64) you must start from the code and recompile it with visualstudio!

Right. And that way, I can also completely forget about the MSYS2 stuff, such as the Bash or Perl interpreters. Oh wait, but then Git cannot fetch submodules anymore. Or bisect. Oh well, people will survive that, I guess...

😜

But this meaning more work and I can't support you...

Right, and it also distracts us from the original topic of this ticket: how to get Git for Windows into the Windows Store.

Don't get me wrong, I appreciate your desire to help, but I fear that we're past the stage where we wonder what we want, we already have a pretty good idea what we want, now we only need volunteers who can do it.

dscho commented 4 years ago

how to get Git for Windows into the Windows Store.

I guess we'll need to follow the instructions at https://docs.microsoft.com/en-us/windows/msix/desktop/desktop-to-uwp-manual-conversion

YasharF commented 4 years ago

what are the options to configure a Store app? We have quite a few setting that we offer to the user while installing, we cannot just drop that part of the installer.

If it makes it easier to push to the store, my two cents would be to just go with one pre-set configuration that is simple. I like how the Python release includes a disclaimer "NOTE: The Microsoft Store release of Python 3.7 is primarily for evaluation purposes, and not all features are guaranteed stable". For me, what they have in the store was good enough to use, since each once in a while I may need to run a python script in Power Shell, and don't want to have to think about keeping the python compiler up to date.

I don't know what data you have on feature usage from the community. I can tell you that for my use-case the only reason that I install git in Windows is that Visual Studio Code wants the git executables. I use VS Code as my code editor for all SW development, and I pretty much do all compiling, execution and git operations in Windows 10 WSL/Ubuntu. In the WSL side, apt-get takes care of updating git, but in the Windows VS Code side, I have to manually redownload and install the installer from git-scm to keep the installation up to date. As far as GIT GUI, in my particular case, I don't use it since the command line tools and VS Code UI are sufficient. I have never used Git Bash in Windows either, and it seems like that WSL makes it somewhat redundant.

fourpastmidnight commented 4 years ago

Whereas I’m in Git Bash all the time. 😉

Sent from my Windows 10 phone

From: Yashar Fakhari Sent: Monday, January 6, 2020 22:05 To: git-for-windows/git Cc: Subscribed Subject: Re: [git-for-windows/git] I would like to have permission to publishyour app on the Windows Store (#1146)

what are the options to configure a Store app? We have quite a few setting that we offer to the user while installing, we cannot just drop that part of the installer. If it makes it easier to push to the store for the first time, my two cents would be to just go with one pre-set configuration that is simple. I like how the Python release includes a disclaimer "NOTE: The Microsoft Store release of Python 3.7 is primarily for evaluation purposes, and not all features are guaranteed stable". For me, what they have in the store was good enough to use, since each once in a while I may need to run a python script in Power Shell, and don't want to have to think about keeping the python compiler up to date. I don't know what data you have on feature usage by the community. I can tell you that for my usecase the only reason that I install git in Windows is that Visual Studio Code wants the git executables. VS Code is the UI that I use for all SW development, and I pretty much only use Windows 10 WSL/Ubuntu for compiling execution and git operations. In the WSL side, apt-get takes care of updating git, but in the Windows VS Code side, I have to manually redownload and install the msi to keep the installation up to date. As far as GIT GUI, in my particular case, I don't use it since the command line tools and VS Code UI are sufficient. I have never used Git Bash in Windows either. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

totkeks commented 4 years ago

Just stumbled upon this, because the update check often doesn't check for updates for me, so I was wondering if git could come to the MS store. Main reason for me would be the automatic updates, whenever a new version releases.

dscho commented 4 years ago

@totkeks feel free to help! :smile:

davidanthoff commented 3 years ago

I just went through the exercise of building an MSIX installer for the Julia programming language and publishing it in the Windows Store. So at the moment I have a pretty good understanding of how to create an installer for that and I'd be interested in taking a stab at doing the same for git. @dscho, I take it that you are still interested in that, right? I could probably do most of the steps myself, but I'm pretty sure I would need some help when it comes to specific questions how git for Windows does certain things, how this can be integrated in the normal build process etc.

Before we embark on this, it might make sense to just make sure everyone agrees with some of the implications this would have, as some things would be quite different from the existing setup experience. Here is the list of things that I can come up with right now:

I think those three things are probably the most drastic changes. I'm sure we would discover other things down the road, though...

My initial stab would be to start from the portable version, and just try to package that as a MSIX installer. Does that sound reasonable? One thing that would help me is to understand which file and registry locations git normally modifies. Does it ever write into its own install folder? Probably not, right? Is that also true for the portable version? Are there any locations under %APPDATA% where it stores stuff?

Finally, I think it would make sense to integrate that into some sort of Github Actions setup right away. Is https://github.com/git-for-windows/git/blob/main/.github/workflows/git-artifacts.yml the right place to integrate that? I looked at that, but don't fully understand it. Is there some stage that outputs an artifact that is essentially the portable installer? If so, I could just add another stage that takes that artifact in and then creates the MSIX installer. For Julia I created a Github Workflow that goes all the way and deploys the MSIX to the Windows Store, so there is essentially no manual step involved at all (see here). The way I set that up is that whenever one pushes a git tag to the repo, it will trigger the jobs that push things to the store, but the jobs that do the push to the store are gated with environments, so that the maintainer can very easily "release" a given build to the store with one click. I also have it setup so that there are different flights in the store (think of this as channels), i.e. one dev channel, a release preview channel and the "real" release. So whenever a MSIX is created, each of these channels is gated by its own environment. Not sure whether that kind of setup would fit into the existing release process here, but if it does, it makes for a smooth experience.

And finally, we would have to register all of this with the Windows Store itself. That step can be.... interesting, to put it mildly. It took us many, many weeks to fight our way through the various intricacies of the Microsoft identity/store/partner center situation for Julia... I think @dscho if you are generally interested in this whole project, it might make most sense that you and I connect directly and I can try to let you know how we in the end maneuvered through that piece of the puzzle for Julia.

Also, before I start to actual build something, if anyone has some other questions what all of this would imply, or how it would work, please bring them up now! I'd be more than happy to try to sort those out before we actually put time and effort into this :)

Oh, and this of course would also help with https://github.com/git-for-windows/git/issues/3307, because git would have app identity if it was distributed via the store.

rimrul commented 3 years ago
  • There cannot be any configuration during setup, i.e. all the UI options in the existing installer would not be present in a store installer and we would have to go with default for all of these.

Not great, but not the end of the world.

  • Git would auto-update. As far as I can tell, store apps always auto-update. So the current model where one gets a notification about updates and then can decide when to install that update would be replaced with a mandatory auto-update behavior.

I don't think that's a big issue. Since that seems to be the way all apps distributed via the windows store behave, that's probably the behaviour users expect.

  • By default, store apps run in a container that virtualizes the entire registry and everything under ~\AppData. So any changes that any binary we ship would make to those file locations or to the registry would not be visible to any other software that runs on this system. I'm not sure whether that is relevant for git, but it can be really tricky if say git were to write information to the registry that third party software then relies on and tries to read. There are ways around that (for example, for Julia this really didn't work at all), but it is a bit more involved and we would probably need special permissions from MS for such a store submission.

We only touch appdata for the Windows Terminal fragments and the registry implications should also be mostly fine. Some third party applications might use the registry to discover a Git for Windows installation, but I think there are simple ways to query the system for installed store apps, so that shouldn't be an issue.

My initial stab would be to start from the portable version, and just try to package that as a MSIX installer. Does that sound reasonable?

If we have to go with defaults anyways, then I guess portable git is a good starting point.

One thing that would help me is to understand which file and registry locations git normally modifies.

Various registry locations, but AFAIK not in portable git.

Does it ever write into its own install folder?

That can happen with things like git config --system, but the next update would undo most changes in there.

Is that also true for the portable version?

Yes.

Are there any locations under %APPDATA% where it stores stuff?

We do create the Windows Terminal profile fragments there in a per-user install and store some files under $HOME.

Oh, and this of course would also help with https://github.com/git-for-windows/git/issues/3307, because git would have app identity if it was distributed via the store.

Does that mean a select few executables (likely git-bash.exe and git-cmd.exe, maybe cmd\git-gui.exe and cmd\gitk.exe) or do you intend to patch every single executable?

dscho commented 3 years ago

@davidanthoff thank you for the offer! I am fairly interested in this, even if I must caution that we still have Windows 7 users and therefore cannot exclusively distribute Git for Windows via the Windows Store.

A couple answers in addition to @rimrul's:

Git itself does not write into the registry, like, ever. The Git for Windows installer does, and some 3rd-party applications use that information to detect the presence. Likewise, we never write into AppData. But we write into the home directory (which is usually the same as USERPROFILE).

About MSIX: we do have (stalled) beginnings of an MSI installer (relying on WIX). Not sure whether that helps anything.

Does it ever write into its own install folder?

That can happen with things like git config --system, but the next update would undo most changes in there.

During the configuration steps of the installer, that's exactly what we usually do.

Likewise, when we configure Git Bash to run in ConHost instead of MinTTY, we modify the resources of git-bash.exe via edit-git-bash.exe.

Also, to use Cygwin's pseudo TTY support, we write /etc/git-bash.config and git-bash.exe reads it.

If there is any use in consolidating these two to also read from /etc/git-bash.config if we want to run via ConHost, that is quite doable.

I'm just not sure how we allow our users to discover how to configure things. The installer is a nice, central place to do that. With Windows Store applications, that is not the case. (And I am not prepared to spit out information when you run git.exe, as it might break the use case where 3rd-party applications run git.exe in the background.

Is https://github.com/git-for-windows/git/blob/main/.github/workflows/git-artifacts.yml the right place to integrate that?

For the moment (and probably at least until GitHub workflows grow support for re-running just the failed jobs), I won't go forward with it, but yes, my long-term idea was to port the Azure Pipeline we use to build the Git artifacts over to a GitHub workflow, and git-artifacts.yml was a first step in that direction.

This wiki page has more information how Git for Windows' release process looks like.

davidanthoff commented 3 years ago

Thanks for all that info! Here are some responses on various topics:

We only touch appdata for the Windows Terminal fragments

The terminal fragments are no problem, there is a MSIX way of doing that, and we've used that for the Julia installer as well.

Various registry locations, but AFAIK not in portable git.

I looked through the registry things the installer writes, and there seemed to be three types of things: 1) generic setup info (where is it installed etc), I think we'll probably lose that, 2) font configuration stuff, again not sure how we could do that, but maybe also not the end of the world, given that defaults tend to get better on Windows? 3) file associations, those can be done declaratively in MSIX, so I think that should be easy.

Does it ever write into its own install folder?

That can happen with things like git config --system

Likewise, when we configure Git Bash to run in ConHost instead of MinTTY, we modify the resources of git-bash.exe via edit-git-bash.exe. Also, to use Cygwin's pseudo TTY support, we write /etc/git-bash.config and git-bash.exe reads it.

In general, writes into the install folder itself are not allowed with MSIX, i.e. we'll have to think of the entire folder that we deploy as read-only. So that probably requires some thinking... One question is what git config --system should do. MSIX installs are always per user, so the whole idea of a system wide configuration probably doesn't really jive with the entire Windows Store idea. Or maybe we'd have to find a new location for those settings, not entirely sure. Likewise for the edit-git-bash.exe and /etc/git-bash.config stuff that @dscho mentions. I'm tempted to ignore for now and just see whether we can get an installer up and working and then revisit?

store some files under $HOME

That should be no problem.

Oh, and this of course would also help with #3307, because git would have app identity if it was distributed via the store.

Does that mean a select few executables (likely git-bash.exe and git-cmd.exe, maybe cmd\git-gui.exe and cmd\gitk.exe) or do you intend to patch every single executable?

There is no patching happening, it is just that every binary that is distributed via a MSIX will run with app identity automatically.

even if I must caution that we still have Windows 7 users and therefore cannot exclusively distribute Git for Windows via the Windows Store

Yes, that makes a lot of sense!

About MSIX: we do have (stalled) beginnings of an MSI installer (relying on WIX). Not sure whether that helps anything.

The only thing MSI and MSIX share is the first three letters of their names, other than that they are completely different technologies with no overlap at all :)

I'm just not sure how we allow our users to discover how to configure things. The installer is a nice, central place to do that. With Windows Store applications, that is not the case. (And I am not prepared to spit out information when you run git.exe, as it might break the use case where 3rd-party applications run git.exe in the background.

Yeah, that is probably a pretty central question. I completely agree that we can't spit out random info at start of git.exe. I think one option might be to add a small GUI program to the distribution that shows up in the start menu and could be named Git Configuration and it provides UI that allows users to configure most (or all) of the things that are currently configured during setup. Or maybe there is already a way to configure these things via the command line in some way? I think at the end of the day the only options we have is something like that, and relying much more on defaults... But maybe that is ok? I assume that a lot more people will install git via winget going forward, and that also doesn't provide any configuration during a default install, right?

For the moment (and probably at least until GitHub workflows grow support for re-running just the failed jobs), I won't go forward with it, but yes, my long-term idea was to port the Azure Pipeline we use to build the Git artifacts over to a GitHub workflow, and git-artifacts.yml was a first step in that direction.

This wiki page has more information how Git for Windows' release process looks like.

Ah, good to know! So I started working on this yesterday (before I saw your message) by integrating it into the GitHub workflow and got it to a point where it does produce a MSIX installer. One benefit for now is that I can actually trigger these workflows relatively easily in my fork, so maybe I'll for now just continue hacking away on that, and then if we feel it all works we try to move it over to the Azure pipelines?

My current status is that this build did produce a MSIX installer for all three platforms (x64, x86 and arm64). But it isn't signed yet, and one can't really try it without that. I think I'm going to just sign with a self issued cert for now, just to keep things moving forward, and once I'm at a point where I have an installer that I can try locally on my system and that works we can work on the next steps.

If anyone wants to see where I'm working on this, it is https://github.com/git-for-windows/build-extra/pull/366 and https://github.com/davidanthoff/git/blob/b83ac2df699dbc0bd92a08b70853917222c68aaf/.github/workflows/git-artifacts.yml#L519, essentially.

davidanthoff commented 3 years ago

Signing the MSIX turned out to be a bit more complicated. In particular, it seems that there is one file in the portable archive (mingw64\libexec\git-core\WebView2Loader.dll or the corresponding other folders for different platforms) that if included in the MSIX prevents signtool to sign the MSIX... signtool has the most cryptic error messages imaginable, but I had this situation before if a file had a corrupt signature, so my best guess at the moment is that WebView2Loader.dll for some reason has a corrupt signature. If I just delete that file before I package everything up as a MSIX (i.e. just not include it), then everything works and I can create a signed MSIX installer that I can then install and run git from.

I think at this point we have two options: 1) we could try to setup one of the pipelines so that it creates a signed MSIX automatically, or 2) we could go right away to putting the installer into the Windows Store.

In general, there is no way to install (even for testing) a MSIX directly that is not signed. One can create a self issues cert (that is what I did), but the whole workflow is cumbersome to no end, in particular if one wants to create say a version and have some other folks try it out. So I think if we were to try to create signed MSIX installers, it would only make sense to set the pipeline up in such a way that the MSIX gets signed with @dscho's certificate.

The other option is that we start to push the installer into the Windows Store. In that case we don't have to sign it, so that part is easier, but we do have to fight our way through account creation etc. for the Store. We could publish the MSIX as "unlisted" in the Store, which would mean that only folks with the direct link to the store listing could install it, i.e. that would allow for a almost non-public test phase to just figure things out.

I think my vote would be that we try to get the store setup up-and-running right away, but I'd also be happy to help with the other option.

I tried to understand the release process, but at the moment the various interactions are still a bit of a mystery to me... So I think I'll probably need some help with integrating what I did so far properly into the existing release process. @dscho I'm almost wondering whether it might be easiest to sort some of these one-time setup things out on a zoom call or something like that? Same for the next steps re the store: you'll have to do most of those, the entire thing is super brittle and so it might make sense if we chat and I just relay how we got around those things for Julia... If that sounds good to you, you can see my email on my Github profile and connecting there would be easiest.

Oh, one other thing: is there an SVG version of the logo/icon that we would want to use? If so, I can use VS to create all the different resolution PNG files we'll need for a store submission with it.

dscho commented 3 years ago

I started working on this yesterday (before I saw your message) by integrating it into the GitHub workflow and got it to a point where it does produce a MSIX installer. One benefit for now is that I can actually trigger these workflows relatively easily in my fork, so maybe I'll for now just continue hacking away on that, and then if we feel it all works we try to move it over to the Azure pipelines?

Excellent. I meant to suggest going forward with the GitHub workflow for exactly those reasons.

Does it ever write into its own install folder?

That can happen with things like git config --system

Likewise, when we configure Git Bash to run in ConHost instead of MinTTY, we modify the resources of git-bash.exe via edit-git-bash.exe. Also, to use Cygwin's pseudo TTY support, we write /etc/git-bash.config and git-bash.exe reads it.

In general, writes into the install folder itself are not allowed with MSIX, i.e. we'll have to think of the entire folder that we deploy as read-only. So that probably requires some thinking... One question is what git config --system should do. MSIX installs are always per user, so the whole idea of a system wide configuration probably doesn't really jive with the entire Windows Store idea. Or maybe we'd have to find a new location for those settings, not entirely sure. Likewise for the edit-git-bash.exe and /etc/git-bash.config stuff that @dscho mentions. I'm tempted to ignore for now and just see whether we can get an installer up and working and then revisit?

Yes, this is a problem. I guess git config --system will simply not work, and we will have to ship with reasonable defaults in the system config, then ensure that users know to use git config --global instead.

one option might be to add a small GUI program to the distribution

That's probably the best option we have. And there is already precedent with the Git Credential Helper Selector: It is a small program written in C that offers a simple GUI. We could copy/edit this, also make it part of the git-extra package, and bundle it.

Signing the MSIX turned out to be a bit more complicated. In particular, it seems that there is one file in the portable archive (mingw64\libexec\git-core\WebView2Loader.dll or the corresponding other folders for different platforms) that if included in the MSIX prevents signtool to sign the MSIX... signtool has the most cryptic error messages imaginable, but I had this situation before if a file had a corrupt signature, so my best guess at the moment is that WebView2Loader.dll for some reason has a corrupt signature. If I just delete that file before I package everything up as a MSIX (i.e. just not include it), then everything works and I can create a signed MSIX installer that I can then install and run git from.

Hmm. This file comes from GCM Core:

$ pacman -Qo /mingw64/libexec/git-core/WebView2Loader.dll
/mingw64/libexec/git-core/WebView2Loader.dll is owned by mingw-w64-x86_64-git-credential-manager-core 2.0.475.64295-1

@mjcheetham any ideas?

I think if we were to try to create signed MSIX installers, it would only make sense to set the pipeline up in such a way that the MSIX gets signed with @dscho's certificate.

I am very much in favor of going the simple route. Do MSIX files get signed with a regular code-signing certificate? Since you mention signtool elsewhere, I assume that is so. In that case, did you

git-for-windows/build-extra#366 and https://github.com/davidanthoff/git/blob/b83ac2df699dbc0bd92a08b70853917222c68aaf/.github/workflows/git-artifacts.yml#L519, essentially.

This is great! Could you open a PR at https://github.com/git-for-windows/git/compare/main...davidanthoff:main? That way, we can efficiently collaborate on this and have a record.

I think my vote would be that we try to get the store setup up-and-running right away, but I'd also be happy to help with the other option.

Or we do both.

Question is: do we simply run signtool *.msix afterwards? If so, we can easily imitate https://github.com/davidanthoff/git/blob/b83ac2df699dbc0bd92a08b70853917222c68aaf/.github/workflows/git-artifacts.yml#L169-L180 in the msix job, and then call git signtool *.msix.

I'm almost wondering whether it might be easiest to sort some of these one-time setup things out on a zoom call or something like that? Same for the next steps re the store: you'll have to do most of those, the entire thing is super brittle and so it might make sense if we chat and I just relay how we got around those things for Julia... If that sounds good to you, you can see my email on my Github profile and connecting there would be easiest.

That sounds good. I'll shoot you an email.

Oh, one other thing: is there an SVG version of the logo/icon that we would want to use? If so, I can use VS to create all the different resolution PNG files we'll need for a store submission with it.

There is: https://github.com/git-for-windows/build-extra/blob/ca0750cac61e79517dd29ce4a945e92af7871399/git-for-windows.svg. I would, however, want to set up some automated build to render the .png files. Or maybe there is a way to tell Windows Store to use the scale-invariant .svg instead?

rimrul commented 3 years ago

is there an SVG version of the logo/icon that we would want to use? If so, I can use VS to create all the different resolution PNG files we'll need for a store submission with it.

There is this.

rimrul commented 3 years ago

I would, however, want to set up some automated build to render the .png files.

We could add a compile time dependency on imagemagick to git-extra …

Or maybe there is a way to tell Windows Store to use the scale-invariant .svg instead?

Looking at this, png seems to be the only option.

dscho commented 3 years ago

I would, however, want to set up some automated build to render the .png files.

We could add a compile time dependency on imagemagick to git-extra …

Or we could use the much more light-weight option to use a node.js step:

npm install -g svgexport
MSYS_NO_PATHCONV=1 svgexport git-for-windows.svg g.png 0:0:128:128 2x

This will output a g.png that is 256x256 pixels, and you can easily adjust the 2x to specify a different scale factor.

Or maybe there is a way to tell Windows Store to use the scale-invariant .svg instead?

Looking at this, png seems to be the only option.

Thank you for digging this out.

davidanthoff commented 3 years ago

I opened a new issue https://github.com/git-for-windows/git/issues/3332 to track remaining TODOs. I wanted an issue that I own so that I can keep the first post updated with a running todo list.

rakleed commented 2 years ago

@dscho now with the release of Windows 11, you can submit traditional Win32 applications to the Microsoft Store - https://developer.microsoft.com/en-us/microsoft-store/desktop-apps/. Can you submit the current version to the Store while the MSIX installer is being finalized?

dscho commented 2 years ago

with the release of Windows 11, you can submit traditional Win32 applications to the Microsoft Store - https://developer.microsoft.com/en-us/microsoft-store/desktop-apps/.

Does that work for Windows 10, too?

If not, I find it quite limiting, i.e. not a lot of return for the quite substantial hassle of first paying to get a developer account on the Microsoft Store, just to be able to then spend more time on both figuring out how to publish and maintaining yet another way to run Git for Windows, with its own challenges.

rimrul commented 2 years ago

Does that work for Windows 10, too?

There's a little 3 minute video at the bottom of the page explaining the process to upload a new application for the first time. From 2:03 to 2:17 there is a Checkbox visible at the bottom of the screen that's labeled "Let Microsoft decide whether to make this application available to any future device families in addition to Windows 10 Desktop".

Under the video it links to aka.ms/newstore which has another video at the top of the page that talks about "You can bring win 32 applications, no matter [...] how you package your applications. [...] The new Microsoft store will be available on Windows 11 and Windows 10".

I'd interpret both of those videos to mean yes, it works on Windows 10.

Do note that there is currently a waiting list to join this "limited public preview", though.

There's also the slight problem that the Microsoft store would want to run the installer silently, which means we can't offer those users any customization through the installer.

treestryder commented 2 years ago

I read the plan was for the "new" store, which is the default on Windows 11, will come to Windows 10 once it is out of preview.

I also read somewhere that the Win32 installs will not have auto-update capability.

Sadly, someone at Microsoft has forgotten the security, privacy and reliability benefits of UWP. And, forgot why do-whatever-they-want EXE and MSI installers were not allowed in the Store. The store WAS more than just a list of installable apps. By requiring legacy apps to be APPX packaged or better, MSIX packaged UWP apps, it got us closer to the security and privacy model that Android and iOS have.

dscho commented 11 months ago

Closing as stale.