-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Maintenance: create headless-git.exe to avoid foreground windows #304
Maintenance: create headless-git.exe to avoid foreground windows #304
Conversation
f6c7e55
to
5fc9c4a
Compare
Good idea! This shows two problems, one in the minimal Git artifact (I think), and the other in the vs-build part (where I did not make the necessary adjustments to build |
The `-lcomdlg32` option is implied by `-mwindows`. This is needed for microsoft/git#304. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
I'll continue playing with this later. |
9e91eb4
to
27ef221
Compare
@derrickstolee I'm happy to report that I got the build green (finally!). |
dc86de5
to
3bc657f
Compare
On Windows, there are two kinds of executables, console ones and non-console ones. Git's executables are all console ones. When launching the former e.g. in a scheduled task, a CMD window pops up. This is not what we want for the tasks installed via the `git maintenance` command. To work around this, let's introduce `headless-git.exe`, which is a non-console program that does _not_ pop up any window. All it does is to re-launch `git.exe`, suppressing that console window, passing through all command-line arguments as-are. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We just introduced a helper to avoid showing a console window when the scheduled task runs `git.exe`. Let's actually use it. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
27ef221
to
a7b10df
Compare
Needed to add 12fd7fa because an encoding mismatch caused |
@jeffhostetler I could use your help here. I get the following BUG with my Scalar repos when running the maintenance this way:
I'm sure it's related to my commit making maintenance care about Edit: I added a90be59 as a potential workaround. |
i think it is fine to remove the check. i shouldn't have used strcmp() there anyway. or rather, should have normalized probably both args first (to get the same type of slashes). besides, the second BUG would have crashed it the structure arg was null. thanks |
This check verifies that the ODB matches what we supplied, but there are some subtleties around Windows path names that can cause inexact matches to be logically the same. Since this check is really intended only for debugging and development purposes, let's remove it for now as a quick workaround. Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
a90be59
to
6d020f0
Compare
Interesting that I can't re-target this PR after its initial target was deleted. I'll leave it closed until we have a final upstream version to merge in. |
Ooops. I had not even realized that I closed this PR. 🤦 |
|
||
if (!gh_client__chosen_odb || | ||
strcmp(v1_odb_path, gh_client__chosen_odb->path)) | ||
BUG("verify_odb_line: unexpeced odb path '%s' vs '%s'", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jeffhostetler @dscho I hit this BUG during one of the functional tests near the end of the Scalar release build process so I'm going to cherry-pick this on top of vfs-2.30.0
.
This check verifies that the ODB matches what we supplied, but there are some subtleties around Windows path names that can cause inexact matches to be logically the same. Since this check is really intended only for debugging and development purposes, let's remove it for now as a quick workaround. This was originally part of #304, as I hit it more often in that effort. However, this was hit during the Scalar release process, so I'll need to generate new installers.
This check verifies that the ODB matches what we supplied, but there are some subtleties around Windows path names that can cause inexact matches to be logically the same. Since this check is really intended only for debugging and development purposes, let's remove it for now as a quick workaround. This was originally part of #304, as I hit it more often in that effort. However, this was hit during the Scalar release process, so I'll need to generate new installers.
This check verifies that the ODB matches what we supplied, but there are some subtleties around Windows path names that can cause inexact matches to be logically the same. Since this check is really intended only for debugging and development purposes, let's remove it for now as a quick workaround. This was originally part of #304, as I hit it more often in that effort. However, this was hit during the Scalar release process, so I'll need to generate new installers.
This check verifies that the ODB matches what we supplied, but there are some subtleties around Windows path names that can cause inexact matches to be logically the same. Since this check is really intended only for debugging and development purposes, let's remove it for now as a quick workaround. This was originally part of #304, as I hit it more often in that effort. However, this was hit during the Scalar release process, so I'll need to generate new installers.
This check verifies that the ODB matches what we supplied, but there are some subtleties around Windows path names that can cause inexact matches to be logically the same. Since this check is really intended only for debugging and development purposes, let's remove it for now as a quick workaround. This was originally part of #304, as I hit it more often in that effort. However, this was hit during the Scalar release process, so I'll need to generate new installers.
This check verifies that the ODB matches what we supplied, but there are some subtleties around Windows path names that can cause inexact matches to be logically the same. Since this check is really intended only for debugging and development purposes, let's remove it for now as a quick workaround. This was originally part of #304, as I hit it more often in that effort. However, this was hit during the Scalar release process, so I'll need to generate new installers.
This check verifies that the ODB matches what we supplied, but there are some subtleties around Windows path names that can cause inexact matches to be logically the same. Since this check is really intended only for debugging and development purposes, let's remove it for now as a quick workaround. This was originally part of #304, as I hit it more often in that effort. However, this was hit during the Scalar release process, so I'll need to generate new installers.
This check verifies that the ODB matches what we supplied, but there are some subtleties around Windows path names that can cause inexact matches to be logically the same. Since this check is really intended only for debugging and development purposes, let's remove it for now as a quick workaround. This was originally part of #304, as I hit it more often in that effort. However, this was hit during the Scalar release process, so I'll need to generate new installers.
This check verifies that the ODB matches what we supplied, but there are some subtleties around Windows path names that can cause inexact matches to be logically the same. Since this check is really intended only for debugging and development purposes, let's remove it for now as a quick workaround. This was originally part of #304, as I hit it more often in that effort. However, this was hit during the Scalar release process, so I'll need to generate new installers.
This check verifies that the ODB matches what we supplied, but there are some subtleties around Windows path names that can cause inexact matches to be logically the same. Since this check is really intended only for debugging and development purposes, let's remove it for now as a quick workaround. This was originally part of #304, as I hit it more often in that effort. However, this was hit during the Scalar release process, so I'll need to generate new installers.
This check verifies that the ODB matches what we supplied, but there are some subtleties around Windows path names that can cause inexact matches to be logically the same. Since this check is really intended only for debugging and development purposes, let's remove it for now as a quick workaround. This was originally part of #304, as I hit it more often in that effort. However, this was hit during the Scalar release process, so I'll need to generate new installers.
This check verifies that the ODB matches what we supplied, but there are some subtleties around Windows path names that can cause inexact matches to be logically the same. Since this check is really intended only for debugging and development purposes, let's remove it for now as a quick workaround. This was originally part of #304, as I hit it more often in that effort. However, this was hit during the Scalar release process, so I'll need to generate new installers.
Commits pulled from @dscho's derrickstolee#14.
This PR exists to more easily generate a Windows installer to check the whole flow.