To git-id or to quit git-id

[Schmoozerd]

I personally like the easy to read revision numbers.

And actually I see no reason to not keep them in the master branch.

True, they are not very git'ish, but they reflect the progress that comes with a commit.

Ofc this is not reasonable for dev-branches, but then again: when a dev branch is ready to be included into main branch, there is no problem to rebase it and assign revision-numbers (either individually or for the "merge" commit)

I just think a clean history is worth very much.

As i personally have worked very much with different branches, I never encountered problems related to the revision numbers in my dev branches.

Infact the strict naming convention makes it easier to keep sql stuff and similar well organized with git (by just using names like 99990_01_ as names for the sql-files. Conflict free, organized, and will be directly converted to final naming when the branch is ready.

[stfx_]

I think the history still looks clean even without hardcoded revision numbers. I understand that this was something that made it easier when mangos switched from SVN to GIT. However after having worked on some projects where no revision numbers were used it just seems so stupid because:

- You cannot use Github UI which is very nice for quick changes

- You cannot accept pull requests which will be crucial for the new policy

- You cannot easily merge branches

- You waste time doing stupid stuff

- Users cannot jump to progress conclusions based on the amount of commits (those could be all just one-line changes or they could be massive mindblowing commits)

- It is a pain when backporting for One and Zero

[TheLuda]

I have moved the git-id discussion here, since it should be a topic on its' own.

[VladimirMangos]

I think the history still looks clean even without hardcoded revision numbers. I understand that this was something that made it easier when mangos switched from SVN to GIT. However after having worked on some projects where no revision numbers were used it just seems so stupid because:

- You cannot use Github UI which is very nice for quick changes

- You cannot accept pull requests which will be crucial for the new policy

- You cannot easily merge branches

- You waste time doing stupid stuff

- Users cannot jump to progress conclusions based on the amount of commits (those could be all just one-line changes or they could be massive mindblowing commits)

- It is a pain when backporting for One and Zero

And this all less important that easy sql updates support and later DB up-to-date checks.

Nothing required all commits have rev numbers. So i not see where you see problem with merge or online small edits.

But last look also that you not test chnages before commit.

[stfx_]

But last look also that you not test chnages before commit.

You don't miss much, do you?

[Schmoozerd]

Also as note:

The revision numbers make bug reports easier to file.

Assume only the git hashes would be available, only one custom addition (and be it the whenever applied sd2 cmake patch) - and it would be impossible to tell for which version the bug report is.

Edit:

If you have a project, where only devs use the development versions, and a use version is provided every now and then (like with the linux kernel) - commit tagging is a great way to go (and that is what it is designed for).

But in our case users use the latest "development" version (as every version is considered development) - hence we would have to tag every commit (in the master branch) - to follow git style.

And compared with this way "our" way of custom revision numbers is in my view by far the superior system

[VladimirMangos]

But last look also that you not test chnages before commit.

You don't miss much, do you?

I only meaning for online edits and

- You cannot accept pull requests which will be crucial for the new policy

If you test changes then have local copy changes + use lot more time for this that need for form correct commit and run git_id.

Comment changes ofc not strong required revision apppy because not expected bug reports related to its, so can be aplied online directly.

Nothing personal has been expected in my prev reply.

[Schmoozerd]

About pull requests:

Big pull requests require serious testing - which is always locally - anyways, and then running git-id is no trouble.

And small pull requests that could be merged directly with github

- like https://github.com/mangos/mangos/pull/47

they are also no trouble to "pick" from github, paste locally and use git-id on.

Yes this is slower, but these 5secs slower are irrelevant compared to the time it takes to understand and approve such a pull request.

[herrtrigger]

Since so far it's all devs posting, I dunno if I should mingle here, while just being a user/tester.

Anyways, from here in the back rows, I share these thoughts:

- Users cannot jump to progress conclusions based on the amount of commits (those could be all just one-line changes or they could be massive mindblowing commits)

-The revision numbers make bug reports easier to file.

Also, for applying sql updates, the clear rev numbering used now (and for years) is very nice/clear.

But, these humble opinions won't outweigh the advantage it might bring you guys for dev'ing (just guessing), so I personally offcourse not having a problem with a change for the better.

[TheLuda]

Since so far it's all devs posting, I dunno if I should mingle here, while just being a user/tester.

Of course, you should. We want to move away from private/developer only discussions and have the community involved in everything.

Also, for applying sql updates, the clear rev numbering used now (and for years) is very nice/clear.

This would be solved if we implement database migrations, e.g. using a library such as liteqsql.

[stfx_]

Assume only the git hashes would be available, only one custom addition (and be it the whenever applied sd2 cmake patch) - and it would be impossible to tell for which version the bug report is.

This might look like the biggest issue however I dont really see a problem here either. If someone posts a github bug report with the revision hash it will automatically get translated into a link to the commit on github which makes it actually faster to find it than by number.

If this hash is now one of a custom branch or a custom commit you can immediately see if its not pure mangos code as we dont support custom code.

As for some small patches like the sd2 cmake patch which actually make sense the user simply should not use that commit as the hash number but thats common sense as he will also see that the revision doesnt turn into a link upon posting. Also if it turns out that he didnt notice it we can still simply ask / point it out in a sticky post somewhere

[Skirnir]

What about using git tags? [1] Last Tag is two years ago. If you create tags every few days, you can name them according to the "revision" numbers. Users will know which sql to apply and it would be possible to say problem x came with core version foo.

Regards

Skirnir

[1] http://learn.github.com/p/tagging.html

[TheLuda]

I can only repeat this: we need a proper system for database migrations which is independent from the git version control, such as litesql. This would solve any issues with database upgrades, and even would allow for database downgrades in case of issues.

[lillecarl]

I can only repeat this: we need a proper system for database migrations which is independent from the git version control, such as litesql. This would solve any issues with database upgrades, and even would allow for database downgrades in case of issues.

This would be more then awesome! And actually i do not see a reason to keep doing all this work for just a few numbers... TrinityCore has stopped signing their commits. They are using dates instead ^^, But yeah lets say for the scriptdev2 compability, as soon as scriptdev is no longer compatilble: Make a tag or so?

[TheLuda]

litesql will need a bit of work though to integrate. The current library version is not marked for production usage, so there may be a few minor and major issues, but we just have to try it out.

Luckily I'll be on vacation the last three July weeks so I plan to push a test branch with litesql integrated then.

[Schmoozerd]

You guys are aware that git-id is no trouble and causes no trouble?

[TheLuda]

Database upgrades do cause trouble, and that is probably the conclusion of this topic.

[Schmoozerd]

Sure, and the solution with a clear revision number ensures that db-updates are done in correct order and based on a correct state of the database. Hence there are no conflicts.

[lillecarl]

Sure, and the solution with a clear revision number ensures that db-updates are done in correct order and based on a correct state of the database. Hence there are no conflicts.

But if we start using git branching and git merge them into master, then revision numbers will be invalid!

[VladimirMangos]

Why? if you use its only at master branch and any merge final commit get own rev number.

Yes, some commits will merged in middle of rev. commits line at master branch if see commits list, but its still be part of last merge commit...

I not see how rev numbers at master branch can confict with any merges or branches

Rev numbers important for DB/script projects for have stable reference and link with appropriate core state.

For DB/scripts not important existance any branches, in fact from DB/script point branch have last revision before fork or last sync merge from master to branch.

[lillecarl]

Why? if you use its only at master branch and any merge final commit get own rev number.

Yes, some commits will merged in middle of rev. commits line at master branch if see commits list, but its still be part of last merge commit...

I not see how rev numbers at master branch can confict with any merges or branches

Rev numbers important for DB/script projects for have stable reference and link with appropriate core state.

For DB/scripts not important existance any branches, in fact from DB/script point branch have last revision before fork or last sync merge from master to branch.

Ah smart, yeah but then there will be several commits in log without id's, bu maybe that doesnt matter ^^,

[VladimirMangos]

In past always exist like commits (without rwv number) by different reasons: online github edits, just forgot adding, or single push for more-one commits with added rev only for last in list. In fact no problems with commits without revs with 3 limitations/problems:

1) With current way work you can't have sql update correctly working (core check for DB up-to-date state) in commit withoput rev. You _need_ register sql update with revision assign for correct work.

2) If code change affect core API used by sd2-scripts then core will can't proper check that sd2 version up-to-date for commit state API.

3) if some bug will be in comit without rev. assigned then bug reports will reported with big chance for prev. revision commit.

No other problems. Only (1) really fatal problem for commit rev. absent.

[Schmoozerd]

Also about branching/merging:

There is no reaso to use revision numbers within special branches - hence there are no conflicts (and besides - these one-line conflicts are so simple to fsolve, why care about them anyways..)

The revision number system won't hold in case we use branchs with database changes, but this is so rare, that I also don't think we need a better system just for this. v(and they can always be make easier by providing some "revert" sqls for such a branch.

Also about the cleaness of a history - even with branching I see no reason to not use rebasing for a final "merge" - makes it more clean by default, and usually also doesn't cost problems.

Especially not with git rerere - which was explicitly designed to make it possible to get a neat history.

[VladimirMangos]

Also about the cleaness of a history - even with branching I see no reason to not use rebasing for a final "merge" - makes it more clean by default, and usually also doesn't cost problems.

Agree if this possible then this made later code changes view more clear.

[zergtmn_]

My 2 cents.

I suggest to switch to numbering DB revisions only. This will make developers' and contributors' life much easier while still keeping DB-related benefits of git-id.

I personally want to be able to merge pull requests directly on github but I cannot because of git-id.