Lesson on mapping git commands to SVN about first-analysis-steps HOT 8 CLOSED

Will this go in a callout box for the developing LHCb code lesson?

from first-analysis-steps.

What about svn status -u

from first-analysis-steps.

Personal preference, can we not teach people the horrible habit of commit -am? Below some personal opinion/justification:

If you learn git add you learn that you can add only some of the file to a commit to keep changes separated even though they are all there right now (maybe one day learning that you can even add individual hunks). The fact that you have to add things explicitly means you reduce the number of times you commit some kind of garbage that you didn't mean to.

commit -m is evil, because it encourages you to write single line, short commit messages. I can't remember how to put a line break in a commit message using the command line. With an editor popping open you have a few seconds to think and edit what you write. It also gives you one final chance to check that the files you are about to modify are the ones you want to modify and that you didn't forget anything.

If having to exit the editor or the wrong editor appearing is the problem, we can fix that. It slows you down marginally. Compared to having to re-read the docs and then fix the disaster you invariably cause when trying to re-write history after commits have been made, it is much quicker.

Strong vote for more explicit, less implicit. Though it seems lots of others don't share this opinion so we should do a quick survey.

Some say that this is too slow, or that it is confusing to have an editor open, all I know is that you get better commits this way.

from first-analysis-steps.

@betatim I was thinking to have it as a very short separate lesson, so as to not overload the LHCb development lesson.

@kdungs I did not know about that, looks useful! I'll include it.

I will also mention how SVN's branching model is much less lightweight than git's, such that development in LHCb is almost always done in the trunk/HEAD.

from first-analysis-steps.

@betatim I imagine the -am stuff is up to the Software Carpentry people, no? We/you should discuss those points with them before they teach it today, as I don't think we'll have the time to teach more git (plus we really wouldn't want to contradict them).

I agree that -am often misses the point of using git (very well-defined, small commits). The reason I mentioned it here is because svn commit -m is equivalent to git commit -am: SVN commits everything in the working directory that's changed. (You can specify individual files, but you can't do those piecemeal, like git commit -p, which I think is where the real power is.)

Personally, I switch between using -m and using an editor for commit messages, depending on what I want in the message; “evil” I would disagree with, and generally has a somewhat religious tone and should be avoided. You can use multiple -m flags for each line, e.g. git commit -m "First line stuff." -m "Second line stuff." but I agree that an editor is better for multiline commits.

from first-analysis-steps.

from first-analysis-steps.

When committing to LHCb software, I usually copy and paste what I wrote in the release notes.

from first-analysis-steps.

Good point on the commit -a, when we show off svn <-> git we should keep it as you can't make choices in svn.

And yes, this is more a religious/political debate and it seems like a lot of others disagree. I just feel the urge to tell people what I think is the "one true way". Before telling the SWC guys we should try and find out their thread (they must have one) where they discussed this.

from first-analysis-steps.