Hi there,
On 5/26/2016 2:19 PM, Mark Murphy/STAR BASE Consulting Inc. wrote:
In Git, you enter a comment for each commit.
[SNIP]
I completely agree with that Mark is saying here. I would also say that
anyone who things they're "losing" something by losing the line-by-line
source dates has clearly never worked with a source version control
system like git (or mercurial, subversion, CVS, etc). Believe me, you
have all that information and 1000 times more.
And to whomever said they use the columns 1-5 to put "marks"... you
don't actually lose those columns when you convert to a stream file,
they are still there and you can still use them. I personally don't
like that technique, and wouldn't use them myself, I think there are
much better ways to do things, but that's still there if you want it.
One thing I do want to clarify in Mark's post that I'm replying to,
though... when he says "you enter a comment for each commit", he is NOT
referring to a comment that goes inside your source code. It's just a
log entry that git maintains that tells you all of the changes made to
the source, so you can examine the log and the "comment" (using the
English word rather than the programming term "comment") will say
something like 'Fixed the problem where the program would crash with an
array index error when loading more than 7000 skus' (or whatever the
reason for the change was) Then if you ask git to tell you what was
changed, it'll show you precisely what lines were changed and how.
It will also let you see changes made across many sources. So you might
add a log entry like "changed the way sales taxes are calculated for
2016" and it might show changes across 30 different source members all
relating to that one change, if appropriate.
At any point, you can roll things back to the way they used to be at any
given time and run that level of code. And git has a great tool called
'bisect' that can be used to search for which change caused a bug, so if
you find a bug, but you knew it worked in April, you can tell git "I
knew this was good on April 10th" and it'll show you that code and let
you test it, and "I know this is broken on May 26th" and it'll show you
that code and let you test it, and then it'll give you all of the
changes made in between (by using a binary tree search algorithm) in the
most efficient way to determine exactly which change broke your code.
When working on a team of many programmers (as I do) you frequently have
multiple people working on the same progams at the same time. Git (and
similar tools) make it easy to merge those changes together. They also
make it much easier to deal with loads of changes happening all the time.
And it's FREE.
Sorry, but... the source dates on the right-hand side, and the marks in
columns 1-5 just don't cut it anymore.
The fancy commercial tools like Arcad, PTC, Aldon, Softlanding, Midrange
Dynamics, etc all do this stuff as well, and they also have the
databases of stuff like build instructions, dependencies, etc that takes
it even a step further. But if you're not going to use those things,
then please at least given the open source stuff a chance.
Git right now is the most popular. (Subversion is considered passe
today. CVS is considered very old school and outdated. Some people
would argue the benefits of stuff like Mercurial vs Git... But git is
really the leader today.)
-SK
midrange.com
