Is your feature request related to a problem? Please describe.
The current Git feature just adds a Sync feature to the FM Dashboard and defaults the Commit Message (which in my opinion is bad practice).
Also, the feature Published isn't tracked per file file in Git which will give the wrong impression when using the FM Dashboard.
Describe the solution you'd like
Replace Published/Draft status with Working/Staged/Stashed/Commited/Synced for tracked files (or simply remove it, as this is already handled by other extensions such as GitLens, GitGraph and VS Code itself).
Add Conventional Commit option to force manual Commit message each time when trying to Sync, adding three lines in the commit message to be replaced (See https://www.conventionalcommits.org/). Only the first line should be mandatory of course.
<type of change>[optional scope]: <What was changed>
<Why was it changed>
<BREAKING CHANGE: Does the change break links/coherence etc.>
**Is your feature request related to a problem? Please describe.**
The current Git feature just adds a `Sync` feature to the FM Dashboard and defaults the Commit Message (which in my opinion is bad practice).
Also, the feature `Published` isn't tracked per file file in Git which will give the wrong impression when using the FM Dashboard.
**Describe the solution you'd like**
* Replace `Published/Draft` status with `Working/Staged/Stashed/Commited/Synced` for tracked files (or simply remove it, as this is already handled by other extensions such as GitLens, GitGraph and VS Code itself).
* Add `Conventional Commit` option to force manual Commit message each time when trying to `Sync`, adding three lines in the commit message to be replaced (See https://www.conventionalcommits.org/). Only the first line should be mandatory of course.
~~~
<type of change>[optional scope]: <What was changed>
<Why was it changed>
<BREAKING CHANGE: Does the change break links/coherence etc.>
~~~
<!-- github-sync-id:1438821207 -->
@DennisL68 Published is the status used to tell most SSG to generate content for the site that the public can view. I could be misunderstanding what you are referring to, maybe you could clarify.
@DennisL68 `Published` is the status used to tell most SSG to generate content for the site that the public can view. I could be misunderstanding what you are referring to, maybe you could clarify.
<!-- github-comment-id:1308781192 -->
In our case, when using Git and branches, anything in the main branch is to be published.
There is no need to use additional ways of handling revisions with Git revisioning. We are already using Git. Marking files as "draft" is redundant.
In our case, when using Git and branches, anything in the main branch *is* to be published.
There is no need to use additional ways of handling revisions with Git revisioning. We are already using Git. Marking files as "draft" is redundant.
<!-- github-comment-id:1309228528 -->
@DennisL68 like @apowell656 said this is related to the static-site generators. By default, Front Matter will use a boolean field for content to be drafted/published. You don't have to use this draft field if you don't want to, you can override the default content type.
Also, you can change the draft field from using a boolean value to an array of values as you proposed (Working/Staged/Stashed/Commited/Synced). More information can be found here: https://frontmatter.codes/docs/content-creation/fields#draft
Will you use the draft field?
Add Conventional Commit option
So in your case, when you click on the sync button, you want to get a popup in which you can enter the commit message. Once provided, it will do the sync?
> Draft/published status
@DennisL68 like @apowell656 said this is related to the static-site generators. By default, Front Matter will use a boolean field for content to be drafted/published. You don't have to use this `draft` field if you don't want to, you can override the default content type.
Also, you can change the draft field from using a boolean value to an array of values as you proposed (`Working/Staged/Stashed/Commited/Synced`). More information can be found here: https://frontmatter.codes/docs/content-creation/fields#draft
Will you use the draft field?
> Add `Conventional Commit` option
So in your case, when you click on the sync button, you want to get a popup in which you can enter the commit message. Once provided, it will do the sync?
<!-- github-comment-id:1310200537 -->
In case you don't want to use the draft status of the page, what we can do is make the following options available:
Remove the draft/publish status from the card
Add a new No status option tabbed navigation
In case you don't want to use the draft status of the page, what we can do is make the following options available:

1. Remove the draft/publish status from the card
2. Add a new **No status** option tabbed navigation
<!-- github-comment-id:1310223260 -->
Yes, that looks promising.
When using Git branches, a Published/Draft status in the Dashboard will be confusing (if not labeling it SSG - Published and SSG - Draft).
However, if using a SSG generator, a Published value is still needed in the markdown-document itself, right?
So what I'm proposing for the Dashboard when using Git is:
Set document status automatically to Published as that is what's needed in many instances anyhow, once the doc is merged to the main/master branch
(don't do this if the branch is main/master as many systems has a policy that blocks pushing changes to main)
Hide (or relabel) SSG Status and Display Git Status instead (not stored in markdown but in Git)
The Git status of changed files in the current branch is displayed using git status -s -b which I would like to see in the Dashboard instead, in case of using Git (a .git folder is available in the project root).
A git branch needed to be synced will have an [ahead] or [behind] value stated.
The current branch name is the first part before ... in the example ## feature/login...origin/feature/login [ahead 1]
## feature/login...origin/feature/login [ahead 1]
"Changes to be committed"
lists modifications and deletions in your local files that you have already added
to the staging area for the next commit.
D - Deleted
A - Added
"Unmerged paths"
are files that are in a conflict state at the moment and that you need to resolve.
UU - Unmerged because in conflict
"Changes not staged for commit"
are also modifications in your local files - but ones that you haven't added to the staging area, yet.
M - Modified
"Untracked files"
lists new files that are not yet under version control.
?? - Untracked
But most of this is already available in VS Code anyhow when using i.e. GitLens. So mostly you just need to clarify that the status doesn't concern Git Status.
Yes, that looks promising.
When using Git branches, a Published/Draft status in the Dashboard will be confusing (if not labeling it `SSG - Published` and `SSG - Draft`).
However, if using a SSG generator, a Published value is still needed in the markdown-document itself, right?
So what I'm proposing for the Dashboard when using Git is:
* Set document status automatically to Published as that is what's needed in many instances anyhow, once the doc is merged to the main/master branch
(don't do this if the branch is main/master as many systems has a policy that blocks pushing changes to main)
* Hide (or relabel) SSG Status and Display Git Status instead (not stored in markdown but in Git)
The Git status of changed files in the current branch is displayed using [git status -s -b](https://www.git-tower.com/learn/git/commands/git-status/) which I would like to see in the Dashboard instead, in case of using Git (a `.git` folder is available in the project root).
A git branch needed to be synced will have an [ahead] or [behind] value stated.
The current branch name is the first part before `...` in the example
`## feature/login...origin/feature/login [ahead 1]`
~~~
## feature/login...origin/feature/login [ahead 1]
"Changes to be committed"
lists modifications and deletions in your local files that you have already added
to the staging area for the next commit.
D - Deleted
A - Added
"Unmerged paths"
are files that are in a conflict state at the moment and that you need to resolve.
UU - Unmerged because in conflict
"Changes not staged for commit"
are also modifications in your local files - but ones that you haven't added to the staging area, yet.
M - Modified
"Untracked files"
lists new files that are not yet under version control.
?? - Untracked
~~~
But most of this is already available in VS Code anyhow when using i.e. GitLens. So mostly you just need to clarify that the status doesn't concern Git Status.
<!-- github-comment-id:1310705790 -->
Yes, if I've selected a (future) Git - Conventional Commits option, I'd like a pop-out window for entering a Commit message my self each time I use Synchronize (if there is anything that needs commiting).
Yes, if I've selected a (future) `Git - Conventional Commits` option, I'd like a pop-out window for entering a Commit message my self each time I use Synchronize (if there is anything that needs commiting).
<!-- github-comment-id:1310714605 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Is your feature request related to a problem? Please describe.
The current Git feature just adds a
Syncfeature to the FM Dashboard and defaults the Commit Message (which in my opinion is bad practice).Also, the feature
Publishedisn't tracked per file file in Git which will give the wrong impression when using the FM Dashboard.Describe the solution you'd like
Replace
Published/Draftstatus withWorking/Staged/Stashed/Commited/Syncedfor tracked files (or simply remove it, as this is already handled by other extensions such as GitLens, GitGraph and VS Code itself).Add
Conventional Commitoption to force manual Commit message each time when trying toSync, adding three lines in the commit message to be replaced (See https://www.conventionalcommits.org/). Only the first line should be mandatory of course.@DennisL68
Publishedis the status used to tell most SSG to generate content for the site that the public can view. I could be misunderstanding what you are referring to, maybe you could clarify.In our case, when using Git and branches, anything in the main branch is to be published.
There is no need to use additional ways of handling revisions with Git revisioning. We are already using Git. Marking files as "draft" is redundant.
@DennisL68 like @apowell656 said this is related to the static-site generators. By default, Front Matter will use a boolean field for content to be drafted/published. You don't have to use this
draftfield if you don't want to, you can override the default content type.Also, you can change the draft field from using a boolean value to an array of values as you proposed (
Working/Staged/Stashed/Commited/Synced). More information can be found here: https://frontmatter.codes/docs/content-creation/fields#draftWill you use the draft field?
So in your case, when you click on the sync button, you want to get a popup in which you can enter the commit message. Once provided, it will do the sync?
In case you don't want to use the draft status of the page, what we can do is make the following options available:
Yes, that looks promising.
When using Git branches, a Published/Draft status in the Dashboard will be confusing (if not labeling it
SSG - PublishedandSSG - Draft).However, if using a SSG generator, a Published value is still needed in the markdown-document itself, right?
So what I'm proposing for the Dashboard when using Git is:
(don't do this if the branch is main/master as many systems has a policy that blocks pushing changes to main)
The Git status of changed files in the current branch is displayed using git status -s -b which I would like to see in the Dashboard instead, in case of using Git (a
.gitfolder is available in the project root).A git branch needed to be synced will have an [ahead] or [behind] value stated.
The current branch name is the first part before
...in the example## feature/login...origin/feature/login [ahead 1]But most of this is already available in VS Code anyhow when using i.e. GitLens. So mostly you just need to clarify that the status doesn't concern Git Status.
Yes, if I've selected a (future)
Git - Conventional Commitsoption, I'd like a pop-out window for entering a Commit message my self each time I use Synchronize (if there is anything that needs commiting).