Should I hard-wrap SVN commit messages
In the Git user community it's a widely adopted practice to hard-wrap commit message bodies to 72–76 character width; everybody knows this and tools like 'git gui' usually make it clear that hard-wrapping is expected. But that doesn't seem to be the case for SVN. For example, TortoiseSVN's commit dialog gives absolutely no hint about wrapping. Does it mean that it's preferred to leave commit message unwrapped? Or should I chose my own boundary? Is there a clear authoritative guiding about that?
svn version-control tortoisesvn commit-message
edited Nov 4 '18 at 19:26
bahrep
21.8k1074109
asked Oct 24 '18 at 17:40
firegurafikufiregurafiku
1,5381626
add a comment |
In the Git user community it's a widely adopted practice to hard-wrap commit message bodies to 72–76 character width; everybody knows this and tools like 'git gui' usually make it clear that hard-wrapping is expected. But that doesn't seem to be the case for SVN. For example, TortoiseSVN's commit dialog gives absolutely no hint about wrapping. Does it mean that it's preferred to leave commit message unwrapped? Or should I chose my own boundary? Is there a clear authoritative guiding about that?
svn version-control tortoisesvn commit-message
edited Nov 4 '18 at 19:26
bahrep
21.8k1074109
asked Oct 24 '18 at 17:40
firegurafikufiregurafiku
1,5381626
add a comment |
In the Git user community it's a widely adopted practice to hard-wrap commit message bodies to 72–76 character width; everybody knows this and tools like 'git gui' usually make it clear that hard-wrapping is expected. But that doesn't seem to be the case for SVN. For example, TortoiseSVN's commit dialog gives absolutely no hint about wrapping. Does it mean that it's preferred to leave commit message unwrapped? Or should I chose my own boundary? Is there a clear authoritative guiding about that?
svn version-control tortoisesvn commit-message
edited Nov 4 '18 at 19:26
bahrep
21.8k1074109
asked Oct 24 '18 at 17:40
firegurafikufiregurafiku
1,5381626
In the Git user community it's a widely adopted practice to hard-wrap commit message bodies to 72–76 character width; everybody knows this and tools like 'git gui' usually make it clear that hard-wrapping is expected. But that doesn't seem to be the case for SVN. For example, TortoiseSVN's commit dialog gives absolutely no hint about wrapping. Does it mean that it's preferred to leave commit message unwrapped? Or should I chose my own boundary? Is there a clear authoritative guiding about that?
svn version-control tortoisesvn commit-message
svn version-control tortoisesvn commit-message
edited Nov 4 '18 at 19:26
bahrep
21.8k1074109
asked Oct 24 '18 at 17:40
firegurafikufiregurafiku
1,5381626
edited Nov 4 '18 at 19:26
bahrep
21.8k1074109
asked Oct 24 '18 at 17:40
firegurafikufiregurafiku
1,5381626
edited Nov 4 '18 at 19:26
bahrep
21.8k1074109
edited Nov 4 '18 at 19:26
bahrep
21.8k1074109
edited Nov 4 '18 at 19:26
bahrep
21.8k1074109
21.8k1074109
asked Oct 24 '18 at 17:40
firegurafikufiregurafiku
1,5381626
asked Oct 24 '18 at 17:40
firegurafikufiregurafiku
1,5381626
asked Oct 24 '18 at 17:40
firegurafikufiregurafiku
1,5381626
1,5381626
add a comment |
add a comment |
3 Answers
3
active
oldest
votes
It really depends on your organizations requirements.
If you are exporting your subversion commits for some type of document that requires a 72-76 width, then you can enforce that amongst the team (there is probably even a regular expression check you could write in a pre-commit hook that could literally enforce this). Otherwise, I see no need to restrict a character width (that svn doesn't automatically keep count of anyway).
However, if you're simply asking about best practices/authoritative guide to give you an answer, you won't find any. Log messages are open to interpretation and use by your team.
answered Oct 25 '18 at 18:41
ChrisChris
1,529318
Nice point about the pre-commit hook. However, it's not reasonable to expressionlessly enforce the rule: for example, it's a common situation in Git commit messages to have long URLs unwrapped.
– firegurafiku
Oct 25 '18 at 19:58
Exactly, and that's why it's open to interpretation. You're 100% correct. I wrote a regular expression for my organization in a hook to check to see if a certain string exist (basically[see #310]because there are certain repositories that we want to make sure are tied to a ticket every time something is changed. That would be a valid reason to enforce commits to be a certain way.For your case, it's all up to you! :)
– Chris
Oct 25 '18 at 20:01
I would avoid using a pre-commit hook just to check for log message line width.
– bahrep
Oct 31 '18 at 12:05
add a comment |
There is no global standard/"best practice" for this with Subversion. Do whatever works for your organization and project.
answered Oct 25 '18 at 16:02
alrocalroc
22.9k33364
add a comment |
TortoiseSVN shows a hint for wrapping the commit messages. You need to add the tsvn:logwidthmarker property to your repository. You can also define various log message templates.
BTW, VisualSVN Commit Selection window also supports tsvn:logwidthmarker.
answered Oct 31 '18 at 12:00
bahrepbahrep
21.8k1074109
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f52975034%2fshould-i-hard-wrap-svn-commit-messages%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
It really depends on your organizations requirements.
If you are exporting your subversion commits for some type of document that requires a 72-76 width, then you can enforce that amongst the team (there is probably even a regular expression check you could write in a pre-commit hook that could literally enforce this). Otherwise, I see no need to restrict a character width (that svn doesn't automatically keep count of anyway).
However, if you're simply asking about best practices/authoritative guide to give you an answer, you won't find any. Log messages are open to interpretation and use by your team.
answered Oct 25 '18 at 18:41
ChrisChris
1,529318
Nice point about the pre-commit hook. However, it's not reasonable to expressionlessly enforce the rule: for example, it's a common situation in Git commit messages to have long URLs unwrapped.
– firegurafiku
Oct 25 '18 at 19:58
Exactly, and that's why it's open to interpretation. You're 100% correct. I wrote a regular expression for my organization in a hook to check to see if a certain string exist (basically[see #310]because there are certain repositories that we want to make sure are tied to a ticket every time something is changed. That would be a valid reason to enforce commits to be a certain way.For your case, it's all up to you! :)
– Chris
Oct 25 '18 at 20:01
I would avoid using a pre-commit hook just to check for log message line width.
– bahrep
Oct 31 '18 at 12:05
add a comment |
It really depends on your organizations requirements.
If you are exporting your subversion commits for some type of document that requires a 72-76 width, then you can enforce that amongst the team (there is probably even a regular expression check you could write in a pre-commit hook that could literally enforce this). Otherwise, I see no need to restrict a character width (that svn doesn't automatically keep count of anyway).
However, if you're simply asking about best practices/authoritative guide to give you an answer, you won't find any. Log messages are open to interpretation and use by your team.
answered Oct 25 '18 at 18:41
ChrisChris
1,529318
Nice point about the pre-commit hook. However, it's not reasonable to expressionlessly enforce the rule: for example, it's a common situation in Git commit messages to have long URLs unwrapped.
– firegurafiku
Oct 25 '18 at 19:58
Exactly, and that's why it's open to interpretation. You're 100% correct. I wrote a regular expression for my organization in a hook to check to see if a certain string exist (basically[see #310]because there are certain repositories that we want to make sure are tied to a ticket every time something is changed. That would be a valid reason to enforce commits to be a certain way.For your case, it's all up to you! :)
– Chris
Oct 25 '18 at 20:01
I would avoid using a pre-commit hook just to check for log message line width.
– bahrep
Oct 31 '18 at 12:05
add a comment |
It really depends on your organizations requirements.
If you are exporting your subversion commits for some type of document that requires a 72-76 width, then you can enforce that amongst the team (there is probably even a regular expression check you could write in a pre-commit hook that could literally enforce this). Otherwise, I see no need to restrict a character width (that svn doesn't automatically keep count of anyway).
However, if you're simply asking about best practices/authoritative guide to give you an answer, you won't find any. Log messages are open to interpretation and use by your team.
answered Oct 25 '18 at 18:41
ChrisChris
1,529318
It really depends on your organizations requirements.
If you are exporting your subversion commits for some type of document that requires a 72-76 width, then you can enforce that amongst the team (there is probably even a regular expression check you could write in a pre-commit hook that could literally enforce this). Otherwise, I see no need to restrict a character width (that svn doesn't automatically keep count of anyway).
However, if you're simply asking about best practices/authoritative guide to give you an answer, you won't find any. Log messages are open to interpretation and use by your team.
answered Oct 25 '18 at 18:41
ChrisChris
1,529318
answered Oct 25 '18 at 18:41
ChrisChris
1,529318
answered Oct 25 '18 at 18:41
ChrisChris
1,529318
answered Oct 25 '18 at 18:41
ChrisChris
1,529318
1,529318
Nice point about the pre-commit hook. However, it's not reasonable to expressionlessly enforce the rule: for example, it's a common situation in Git commit messages to have long URLs unwrapped.
– firegurafiku
Oct 25 '18 at 19:58
Exactly, and that's why it's open to interpretation. You're 100% correct. I wrote a regular expression for my organization in a hook to check to see if a certain string exist (basically[see #310]because there are certain repositories that we want to make sure are tied to a ticket every time something is changed. That would be a valid reason to enforce commits to be a certain way.For your case, it's all up to you! :)
– Chris
Oct 25 '18 at 20:01
I would avoid using a pre-commit hook just to check for log message line width.
– bahrep
Oct 31 '18 at 12:05
add a comment |
Nice point about the pre-commit hook. However, it's not reasonable to expressionlessly enforce the rule: for example, it's a common situation in Git commit messages to have long URLs unwrapped.
– firegurafiku
Oct 25 '18 at 19:58
Exactly, and that's why it's open to interpretation. You're 100% correct. I wrote a regular expression for my organization in a hook to check to see if a certain string exist (basically[see #310]because there are certain repositories that we want to make sure are tied to a ticket every time something is changed. That would be a valid reason to enforce commits to be a certain way.For your case, it's all up to you! :)
– Chris
Oct 25 '18 at 20:01
I would avoid using a pre-commit hook just to check for log message line width.
– bahrep
Oct 31 '18 at 12:05
Nice point about the pre-commit hook. However, it's not reasonable to expressionlessly enforce the rule: for example, it's a common situation in Git commit messages to have long URLs unwrapped.
– firegurafiku
Oct 25 '18 at 19:58
Nice point about the pre-commit hook. However, it's not reasonable to expressionlessly enforce the rule: for example, it's a common situation in Git commit messages to have long URLs unwrapped.
– firegurafiku
Oct 25 '18 at 19:58
Exactly, and that's why it's open to interpretation. You're 100% correct. I wrote a regular expression for my organization in a hook to check to see if a certain string exist (basically
[see #310] because there are certain repositories that we want to make sure are tied to a ticket every time something is changed. That would be a valid reason to enforce commits to be a certain way.For your case, it's all up to you! :)– Chris
Oct 25 '18 at 20:01
Exactly, and that's why it's open to interpretation. You're 100% correct. I wrote a regular expression for my organization in a hook to check to see if a certain string exist (basically
[see #310] because there are certain repositories that we want to make sure are tied to a ticket every time something is changed. That would be a valid reason to enforce commits to be a certain way.For your case, it's all up to you! :)– Chris
Oct 25 '18 at 20:01
I would avoid using a pre-commit hook just to check for log message line width.
– bahrep
Oct 31 '18 at 12:05
I would avoid using a pre-commit hook just to check for log message line width.
– bahrep
Oct 31 '18 at 12:05
add a comment |
There is no global standard/"best practice" for this with Subversion. Do whatever works for your organization and project.
answered Oct 25 '18 at 16:02
alrocalroc
22.9k33364
add a comment |
There is no global standard/"best practice" for this with Subversion. Do whatever works for your organization and project.
answered Oct 25 '18 at 16:02
alrocalroc
22.9k33364
add a comment |
There is no global standard/"best practice" for this with Subversion. Do whatever works for your organization and project.
answered Oct 25 '18 at 16:02
alrocalroc
22.9k33364
There is no global standard/"best practice" for this with Subversion. Do whatever works for your organization and project.
answered Oct 25 '18 at 16:02
alrocalroc
22.9k33364
answered Oct 25 '18 at 16:02
alrocalroc
22.9k33364
answered Oct 25 '18 at 16:02
alrocalroc
22.9k33364
answered Oct 25 '18 at 16:02
alrocalroc
22.9k33364
22.9k33364
add a comment |
add a comment |
TortoiseSVN shows a hint for wrapping the commit messages. You need to add the tsvn:logwidthmarker property to your repository. You can also define various log message templates.
BTW, VisualSVN Commit Selection window also supports tsvn:logwidthmarker.
answered Oct 31 '18 at 12:00
bahrepbahrep
21.8k1074109
add a comment |
TortoiseSVN shows a hint for wrapping the commit messages. You need to add the tsvn:logwidthmarker property to your repository. You can also define various log message templates.
BTW, VisualSVN Commit Selection window also supports tsvn:logwidthmarker.
answered Oct 31 '18 at 12:00
bahrepbahrep
21.8k1074109
add a comment |
TortoiseSVN shows a hint for wrapping the commit messages. You need to add the tsvn:logwidthmarker property to your repository. You can also define various log message templates.
BTW, VisualSVN Commit Selection window also supports tsvn:logwidthmarker.
answered Oct 31 '18 at 12:00
bahrepbahrep
21.8k1074109
TortoiseSVN shows a hint for wrapping the commit messages. You need to add the tsvn:logwidthmarker property to your repository. You can also define various log message templates.
BTW, VisualSVN Commit Selection window also supports tsvn:logwidthmarker.
answered Oct 31 '18 at 12:00
bahrepbahrep
21.8k1074109
edited Oct 31 '18 at 12:06
answered Oct 31 '18 at 12:00
bahrepbahrep
21.8k1074109
answered Oct 31 '18 at 12:00
bahrepbahrep
21.8k1074109
answered Oct 31 '18 at 12:00
bahrepbahrep
21.8k1074109
21.8k1074109
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f52975034%2fshould-i-hard-wrap-svn-commit-messages%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
