When working with an object, there is a chance that another developer has made modifications as well since many developers work off of the same database.

When committing, it would be nice to be able to see a history of modifications. Each time an object is modified (F5) take a commitable snapshot of that object.

When a developer goes to commit, they could see the different times an object was modified and commit all at one time or commit the individual changes made over time. Doing a commit will roll-up all previous commits made.

Example:
Day 1: Dev A: Adds Parameter
Day 2: Dev B: Sets Default Parameter value
Day 3: Dev A: Changes the default

Dev A forgot to commit their initial change, but would like to log a commit for it.
Dev A could open up SQL Source Control, find that Pending object and "commit" his Day 1 change to SQL Source Control WITHOUT affecting any current changes made.

This isn't a great use case for an example, I'm sure others can come up with better examples.

You would need the ability to use Modification Date for the commit date, see my other suggestion:
https://redgate.uservoice.com/forums/39019-sql-source-control/suggestions/19443883-option-to-use-modification-date-as-the-commit-date

With SQL, when you modify an object, that object is now out there to be used or tweaked by other developers. Committing it is really just a statement of, I'm done working with this object and here's what I've done.

We have the problem of not committing objects as timely as we should. We make a modification and go our way until we realize a week later, we forgot to commit. So we commit, but the date time stamp of the commit is not helpful. That is just when the developer remembered.

I think it would be much, much more useful to know "when was this object changed". Maybe we don't know why it was changed or by whom since the commit is pending, but if we can at least know when and what, we can figure out the who and why.

In order to access some options, such as enabling SQL Source Control in multiple instances of SSMS, you have to access a section of the setup tab that you can only get to after you have a database linked to a version control. This kind of thing should be available without having to go through all of that.

As an example of where this comes into play, I open a local DB that I have no intention of attaching to SC and do some work. I then open another DB in another SSMS instance that I do want to deal with source control. I have to close both and open them in the correct order to even be able to get to the option to make this possible.

It is my opinion that no piece of software that is intended to make my life easier should force me to close something (completing breaking my workflow) outside of completing an update.

Hello,
I have a table with only one PK column of type nvarchar(200) which contains static data.
Source Control keeps telling that there are changes even after saving the changes. It seems that it has some issues with the value s'

Database version:
-- Only In Database

INSERT INTO [dbo].[tab_54_Voorvoegsels] ([Voorvoegsel]) VALUES (N's''')

-- Identical

INSERT INTO [dbo].[tab_54_Voorvoegsels] ([Voorvoegsel]) VALUES (N'a')
INSERT INTO [dbo].[tab_54_Voorvoegsels] ([Voorvoegsel]) VALUES (N'aan')
INSERT INTO [dbo].[tab_54_Voorvoegsels] ([Voorvoegsel]) VALUES (N'aan de')

Latest source control version:
-- Only In Source Control

INSERT INTO [dbo].[tab_54_Voorvoegsels] ([Voorvoegsel]) VALUES (N's''')
-- Identical

INSERT INTO [dbo].[tab_54_Voorvoegsels] ([Voorvoegsel]) VALUES (N'a')
INSERT INTO [dbo].[tab_54_Voorvoegsels] ([Voorvoegsel]) VALUES (N'aan')
INSERT INTO [dbo].[tab_54_Voorvoegsels] ([Voorvoegsel]) VALUES (N'aan de')

I'm using version 5.6.0.5731

Redgate is throwing an error that is costing a lot of our time to be wasted. I can link to source control no problem, but when I go to the commit tab, I see steps 1 through 4/4 complete, then I see the list of changes to check in, but this error pops up and after submitting the error report, the list of changes disappears. I have tried a lot of things and cannot get it to work. Here is what I tried:

Unlink redgate
Close SSMS
Delete entire directory -> C:\Users\AlbersM099\AppData\Local\Red Gate\SQL Source Control 5
Restart computer
Open SSMS
Link redgate
Get error

Additionally, I got it to link 1 time without the error, and it allowed me to commit the ComparisonOptions.xml file and that was it. I am now trying to link and commit the filter file, and the entire database. Also including a screen shot of the filter file options.

Git requires a commit message by default however SQL Source Control circumvents this setting and commits without a message. There are a few other submissions attempting to get this fixed which have been declined. Seems you are missing the point.

In the case "Empty commit message for git is invalid" the very article you've linked points out that it takes special command line flag to commit without a message. SQL source control commits without a message and provides no mechanism to prevent this. There is no configuration for git that will do this because the default git behavior is already requires a commit message! Unfortunately SQL source control is subverting this. Please stop subverting the default git commit behavior or provide a setting to enforce a commit message...