[kwlug-disc] Using the alias command with the Git Command Line Interface
John Johnson
jvj at golden.net
Thu Feb 15 00:12:08 EST 2018
I will ask readers to note that I did not use the term: commit in the
descriptions associated with my diagrams.
I did use the term "milestones" but these could be widely spaced with
many commits between the milestones.
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.
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.
JohnJ
On 2/14/2018 21:31, Adam Glauser wrote:
> 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.
>
> 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.
>
> 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.
>
> [1]http://www.gnu.org/software/rcs/manual/rcs.html#Quick-tour
> [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.
>
> On Wed, Feb 14, 2018 at 8:44 PM John Johnson <jvj at golden.net
> <mailto:jvj at golden.net>> wrote:
>
> In my UNIX days we did not use RCS. The UNIX box was experimental
> and was not used for development.
> However, reaching back in my distant memory the RCS version
> numbers would not have any bearing on branches.
> (Caveat: This might be specific to a particular organization.)
>
> Let's refer to the diagram I provided earlier.
> This time we will let A B and C be defined by distinct product /
> part number identifiers.
> And we will let the + signs denote development milestones aka
> versions within each stream.
> The + signs aka versions in one stream do not have anything to do
> with the versions in other streams.
> Baseloads from one stream to the next are taken at a development
> milestone aka version.
>
>
> A +-----+-----+-----+-----+......| EOL
> |
> B +-------+-----+-----+-----+-----+-----+-----+-----+.....| EOL
> |
> C +-------+------+------+------+-----+-----+-----+-----+.....| EOL
>
> (use fixed width font for this diagram)
>
>
> JohnJ
>
> On 2/14/2018 16:20, Federer Fanatic wrote:
>> I have a query about how one can adapt familiarity of RCS usage
>> to Git usage. My impression is that version numbers
>> like RCS can be simulated using "branches" in git? I haven't used
>> Git much beyond pulling interesting source code.
>>
>> FF
>>
>>
>>
>>
>> --------------------------------------------------------------
>> Roger Federer Fanatic Extraordinaire :-)
>>
>> On Wed, Feb 14, 2018 at 11:06 AM, Adam Glauser
>> <adamglauser at gmail.com <mailto:adamglauser at gmail.com>> wrote:
>>
>> 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).
>>
>> 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.
>>
>> # ~/.profile
>> export P_A_DIR=/c/Users/user/projects/projectA
>> export P_B_DIR=/c/Users/user/projects/projectB
>>
>> You can then do things like:
>> $ cd $P_A_DIR
>> $ diff $P_A_DIR/path/to/file $P_B_CODE/path/to/file
>>
>> 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.
>> $ scp $P_A_DIR/path/to/file user at server:$P_A_TEST/path/to/file
>> or
>> $ scp $P_A_DIR/path/to/file user at server:$P_A_RELEASE/path/to/file
>>
>> Hope this helps,
>> Adam
>>
>>
>>
>> On Wed, Feb 14, 2018 at 10:36 AM John Johnson <jvj at golden.net
>> <mailto:jvj at golden.net>> wrote:
>>
>> Update
>> A while ago I was informed about the use of alias command.
>> My Bad: I had forgotten about the alias command, as I
>> used it back when
>> was UNIX sysadm, many eons ago.
>>
>> While my application is not in Linux what I have shown
>> below shows how I
>> am using the alias command with the git command window.
>> The same can apply to Linux.
>>
>> In the other OS, I have placed .bashrc (shown below) in
>> the git home
>> directory /c/Users/user/.
>> I have a number of projects, each with their own
>> development directory
>> and git repository.
>> In the git command window, I use the alias commands shown
>> below to
>> define shortcuts that will put me in the development
>> directory for the
>> current project.
>>
>> # .bashrc
>> # created 20180211
>> alias cdprojectA="cd /c/Users/user/projects/projectA"
>> alias cdprojectB="cd /c/Users/user/projects/projectB"
>> alias cdprojectC="cd /c/Users/user/projects/projectC"
>> # done
>>
>> Next: Study & use the git control files: .gitignore and
>> .ignore.
>>
>> And yes! At this time, I prefer to use git from the
>> command line window.
>> Using the git gui will come later.
>>
>> JohnJ
>>
>>
>> _______________________________________________
>> kwlug-disc mailing list
>> kwlug-disc at kwlug.org <mailto:kwlug-disc at kwlug.org>
>> http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org
>>
>>
>> _______________________________________________
>> kwlug-disc mailing list
>> kwlug-disc at kwlug.org <mailto:kwlug-disc at kwlug.org>
>> http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org
>>
>>
>>
>>
>> _______________________________________________
>> kwlug-disc mailing list
>> kwlug-disc at kwlug.org <mailto:kwlug-disc at kwlug.org>
>> http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org
>
> _______________________________________________
> kwlug-disc mailing list
> kwlug-disc at kwlug.org <mailto:kwlug-disc at kwlug.org>
> http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org
>
>
>
> _______________________________________________
> kwlug-disc mailing list
> kwlug-disc at kwlug.org
> http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20180215/f634b438/attachment.htm>
More information about the kwlug-disc
mailing list