<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
I will ask readers to note that I did not use the term: commit in
the descriptions associated with my diagrams.<br>
I did use the term "milestones" but these could be widely spaced
with many commits between the milestones.<br>
<br>
Commits could be executed daily, while milestones could be defined
by an arbitrary date, say monthly, or quarterly, or possibly
incorporate a level of QA acceptance along with performance
according to a feature/product criteria set by a product manager.
Thus the individual commits might not necessarily refer to a
"version" associated with the milestone.<br>
<br>
Referring back to git and the SHA-1 hashes mentioned by Adam, one
can see these hashes displayed in the output generated by the git
log command.<br>
JohnJ
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 2/14/2018 21:31, Adam Glauser wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAFgBy5_HA=EUw1dvUsJQBjzCOajM_acsuH675PY3DHttMB4vAQ@mail.gmail.com">
<div dir="ltr">I'm not familiar with RCS, but I've just done a
little reading. There is an example of branching at the end of
the "Quick Tour" section[1] in the GNU Docs.
<div><br>
</div>
<div>In Git, the identifiers for each revision of the codebase
are SHA-1 hashes. So "1.2" might be more something like
"A94A8FE5CCB19BA61C4C0873D391E987982FBBD3", or "A94A8F " if
you're feeling frisky[2]. As John suggests, there's no way to
infer from the SHA-1 of a given commit in branch B that it was
branched from a particular commit in branch A.</div>
<div><br>
</div>
<div>The SHA-1 clearly isn't particularly useful as a mnemonic.
Branch names can be used to denote, for example, that a
particular branch is the 1.3 maintenance branch. As I
understand it, it would not be very idiomatic to have a 1.3.1
branch as well, but rather to tag a commit in the 1.3
maintenance branch as the 1.3.1 release.</div>
<div>
<div><br>
</div>
<div>[1]<a
href="http://www.gnu.org/software/rcs/manual/rcs.html#Quick-tour"
moz-do-not-send="true">http://www.gnu.org/software/rcs/manual/rcs.html#Quick-tour</a><br>
</div>
</div>
<div>[2] IIRC, you can refer to a commit in a given repository
using the shortest intial substring of the SHA-1 that uniquely
identifies it.</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Wed, Feb 14, 2018 at 8:44 PM John Johnson <<a
href="mailto:jvj@golden.net" moz-do-not-send="true">jvj@golden.net</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"> In my UNIX days we did
not use RCS. The UNIX box was experimental and was not used
for development.<br>
However, reaching back in my distant memory the RCS version
numbers would not have any bearing on branches.<br>
(Caveat: This might be specific to a particular
organization.)<br>
<br>
Let's refer to the diagram I provided earlier.<br>
This time we will let A B and C be defined by distinct
product / part number identifiers.<br>
And we will let the + signs denote development milestones
aka versions within each stream.<br>
The + signs aka versions in one stream do not have anything
to do with the versions in other streams.<br>
Baseloads from one stream to the next are taken at a
development milestone aka version.<br>
<p><tt><br>
</tt></p>
<p><tt>A +-----+-----+-----+-----+......| EOL</tt><tt><br>
</tt><tt> |</tt><tt><br>
</tt><tt>B
+-------+-----+-----+-----+-----+-----+-----+-----+.....|
EOL</tt><tt><br>
</tt><tt> |</tt><tt><br>
</tt><tt>C
+-------+------+------+------+-----+-----+-----+-----+.....|
EOL</tt><tt><br>
</tt></p>
</div>
<div text="#000000" bgcolor="#FFFFFF">
<p><tt>(use fixed width font for this diagram)<br>
</tt></p>
<br>
JohnJ<br>
<br>
</div>
<div text="#000000" bgcolor="#FFFFFF">
<div class="m_-2054163075399295683moz-cite-prefix">On
2/14/2018 16:20, Federer Fanatic wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">I have a query about how one can adapt
familiarity of RCS usage to Git usage. My impression is
that version numbers
<div>like RCS can be simulated using "branches" in git?
I haven't used Git much beyond pulling interesting
source code.</div>
<div><br>
</div>
<div>FF</div>
</div>
<div class="gmail_extra"><br clear="all">
<div>
<div class="m_-2054163075399295683gmail_signature"
data-smartmail="gmail_signature"><br>
<br>
<br>
--------------------------------------------------------------<br>
Roger Federer Fanatic Extraordinaire :-)</div>
</div>
<br>
<div class="gmail_quote">On Wed, Feb 14, 2018 at 11:06
AM, Adam Glauser <span dir="ltr"><<a
href="mailto:adamglauser@gmail.com"
target="_blank" moz-do-not-send="true">adamglauser@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Thanks for sharing this John. For
what it's worth, I've been using Git for years
now, and I strongly prefer the CLI over any GUI
I've used. That being said, I do use GUI tools for
certain operations. For example, see `git
mergetool`. My preferred tool is KDiff3 (which is
available on the other OS as well).
<div><br>
</div>
<div>My approach to your problem is to use
environment variables. An advantage of this
approach is that you can then refer to those
paths in a variety of use cases.</div>
<div><br>
</div>
<div># ~/.profile</div>
<div>export P_A_DIR=<span
style="color:rgb(33,33,33)">/c/Users/user/projects/project</span><span
style="color:rgb(33,33,33)">A</span></div>
<div>export P_B_DIR=<span
style="color:rgb(33,33,33)">/c/Users/user/projects/projectB</span></div>
<div><br>
</div>
<div>You can then do things like:</div>
<div>$ cd $P_A_DIR<span
style="color:rgb(33,33,33)"><br>
</span></div>
<div>$ diff $P_A_DIR/path/to/file
$P_B_CODE/path/to/file</div>
<div><br>
</div>
<div>In particular, I find this handy for
referring to locations on remote boxes, where I
may not be able to use aliases or remote env.
vars. easily.</div>
<div>$ scp $P_A_DIR/path/to/file
user@server:$P_A_TEST/path/to/file</div>
<div> or</div>
<div>$ scp $P_A_DIR/path/to/file
user@server:$P_A_RELEASE/path/to/file<br>
</div>
<div><br>
</div>
<div>Hope this helps,</div>
<div>Adam</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Wed, Feb 14, 2018 at 10:36 AM
John Johnson <<a href="mailto:jvj@golden.net"
target="_blank" moz-do-not-send="true">jvj@golden.net</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0
0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">Update<br>
A while ago I was informed about the use of
alias command.<br>
My Bad: I had forgotten about the alias command,
as I used it back when<br>
was UNIX sysadm, many eons ago.<br>
<br>
While my application is not in Linux what I have
shown below shows how I<br>
am using the alias command with the git command
window.<br>
The same can apply to Linux.<br>
<br>
In the other OS, I have placed .bashrc (shown
below) in the git home<br>
directory /c/Users/user/.<br>
I have a number of projects, each with their own
development directory<br>
and git repository.<br>
In the git command window, I use the alias
commands shown below to<br>
define shortcuts that will put me in the
development directory for the<br>
current project.<br>
<br>
# .bashrc<br>
# created 20180211<br>
alias cdprojectA="cd
/c/Users/user/projects/projectA"<br>
alias cdprojectB="cd
/c/Users/user/projects/projectB"<br>
alias cdprojectC="cd
/c/Users/user/projects/projectC"<br>
# done<br>
<br>
Next: Study & use the git control files:
.gitignore and .ignore.<br>
<br>
And yes! At this time, I prefer to use git from
the command line window.<br>
Using the git gui will come later.<br>
<br>
JohnJ<br>
<br>
<br>
_______________________________________________<br>
kwlug-disc mailing list<br>
<a href="mailto:kwlug-disc@kwlug.org"
target="_blank" moz-do-not-send="true">kwlug-disc@kwlug.org</a><br>
<a
href="http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org"
rel="noreferrer" target="_blank"
moz-do-not-send="true">http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org</a><br>
</blockquote>
</div>
<br>
_______________________________________________<br>
kwlug-disc mailing list<br>
<a href="mailto:kwlug-disc@kwlug.org"
target="_blank" moz-do-not-send="true">kwlug-disc@kwlug.org</a><br>
<a
href="http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org"
rel="noreferrer" target="_blank"
moz-do-not-send="true">http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org</a><br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset
class="m_-2054163075399295683mimeAttachmentHeader"></fieldset>
<br>
<pre>_______________________________________________
kwlug-disc mailing list
<a class="m_-2054163075399295683moz-txt-link-abbreviated" href="mailto:kwlug-disc@kwlug.org" target="_blank" moz-do-not-send="true">kwlug-disc@kwlug.org</a>
<a class="m_-2054163075399295683moz-txt-link-freetext" href="http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org" target="_blank" moz-do-not-send="true">http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org</a>
</pre>
</blockquote>
<br>
</div>
_______________________________________________<br>
kwlug-disc mailing list<br>
<a href="mailto:kwlug-disc@kwlug.org" target="_blank"
moz-do-not-send="true">kwlug-disc@kwlug.org</a><br>
<a
href="http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org</a><br>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
kwlug-disc mailing list
<a class="moz-txt-link-abbreviated" href="mailto:kwlug-disc@kwlug.org">kwlug-disc@kwlug.org</a>
<a class="moz-txt-link-freetext" href="http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org">http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org</a>
</pre>
</blockquote>
<br>
</body>
</html>