Skip to content
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

Closed

Conversation

derrickstolee
Copy link
Collaborator

Commits pulled from @dscho's derrickstolee#14.

This PR exists to more easily generate a Windows installer to check the whole flow.

@dscho
Copy link
Member

dscho commented Dec 24, 2020

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 headless-git.exe).

dscho added a commit to git-for-windows/git-sdk-64 that referenced this pull request Dec 24, 2020
The `-lcomdlg32` option is implied by `-mwindows`.

This is needed for microsoft/git#304.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho
Copy link
Member

dscho commented Dec 24, 2020

I'll continue playing with this later.

@dscho dscho force-pushed the headless-git branch 3 times, most recently from 9e91eb4 to 27ef221 Compare December 25, 2020 00:54
@dscho
Copy link
Member

dscho commented Dec 25, 2020

@derrickstolee I'm happy to report that I got the build green (finally!).

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>
@derrickstolee
Copy link
Collaborator Author

Needed to add 12fd7fa because an encoding mismatch caused schtasks failures on my machine. How did I not catch this before?

@derrickstolee
Copy link
Collaborator Author

derrickstolee commented Dec 30, 2020

@jeffhostetler I could use your help here. I get the following BUG with my Scalar repos when running the maintenance this way:

BUG: gvfs-helper-client.c:189: verify_odb_line: unexpeced odb path 'C:/.scalarCache/id_ba47400f-eebe-4850-a8bf-ef694ef81414' vs 'C:\.scalarCache\id_ba47400f-eebe-4850-a8bf-ef694ef81414'

I'm sure it's related to my commit making maintenance care about gvfs.sharedCache, and so I probably did it wrong. However, how can we make this more robust? Or, is this check actually helping us anymore? Was it just for testing?

Edit: I added a90be59 as a potential workaround.

@jeffhostetler
Copy link

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>
@derrickstolee
Copy link
Collaborator Author

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.

@dscho
Copy link
Member

dscho commented Jan 6, 2021

Interesting that I can't re-target this PR after its initial target was deleted

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'",
Copy link
Collaborator Author

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.

derrickstolee added a commit that referenced this pull request Jan 14, 2021
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.
dscho pushed a commit that referenced this pull request Mar 4, 2021
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.
dscho pushed a commit that referenced this pull request Mar 4, 2021
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.
dscho pushed a commit that referenced this pull request Mar 4, 2021
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.
dscho pushed a commit that referenced this pull request Mar 5, 2021
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.
dscho pushed a commit that referenced this pull request Mar 8, 2021
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.
jeffhostetler pushed a commit that referenced this pull request Mar 15, 2021
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.
jeffhostetler pushed a commit that referenced this pull request Mar 16, 2021
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.
derrickstolee added a commit that referenced this pull request May 17, 2021
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.
derrickstolee added a commit that referenced this pull request May 17, 2021
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.
derrickstolee added a commit that referenced this pull request May 17, 2021
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.
dscho pushed a commit that referenced this pull request May 21, 2021
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants