Re: [git-users] Dark theme / Night mode

[rhkramer]

On Tuesday, September 08, 2020 04:31:29 PM Michael wrote:
> Ignoring the issue for the moment that "git" is not "github", the question
> is, what is this "health" issue of light mode?

+1 

Thank you!

Your post builds on the rant I've wanted to make whenever I hear someone make 
a similar request / complaint about lack of a night mode -- I'd just like to 
add my $0.02 (or maybe $0.04):

1.  For thousands of years, text has been dark (or colored) on a light 
background (at least, after cuneiform)

2.  I used to work with people and use shared computers with green screens -- 
every time I came to use the computer, the brightness (and contrast) would be 
turned all the way up, leading to screen burn in (and a health issue with my 
eyes)

 
> Proper calibration starts with "the light level of a white screen on your
> monitor should match the light level of the walls in the background." At
> that point, your eyes are getting as many photons/sec from the background
> wall as from the monitor. That's the "no eyestrain" level. Or, if your
> work is "preparing stuff for print", then your white level should match a
> blank piece of paper -- again, about the same photons/sec as background
> reflected light.
> 
> Now, if there's a problem with systems that assume "monitors must be at max
> brightness", and assume a fixed gamma drop-off that cannot be adjusted,
> that's an entirely different problem. (There's a viewing-dependent
> black-level, a viewing-dependent white level, and then you have anywhere
> from 224 to 255 visible steps between them depending on the color space
> standard you are using. Mapping from a image's color space to the user
> monitor is a GUI driver's jobs (X, or apple/microsoft/google OS).

Re: [git-users] How to track changes to db

[rhkramer]

On Wednesday, August 05, 2020 07:43:53 PM SJW wrote:
> On Wednesday, 5 August 2020 at 23:15:49 UTC+10 rhkr...@gmail.com wrote:
> > Interesting puzzle ;-)
> > 
> > Do you create one file named feature.txt, or do you create a different
> > file for
> > each feature with a unique name?
> > 
> > (I'm trying to understand "all these text files" from below.)
> > 
> > One thing I'd consider is just having one file named feature.txt, or
> > notes.txt
> > and modify that as appropriate and commit it with each change.
> > 
> > Then when you checkout a feature branch, you get the notes (DB ALTER
> > statements) associated with that feature, and it stays associated with
> > that
> > feature branch.
> > 
> > You could choose another name for the text file, perhaps: db_alter.txt
> 
> I have a different file for each feature - problem is, when I merge the
> feature and delete the branch, the notes get merged so if I have 5 feature
> branchs, I end up with 5 rogue feature.txt files

I guess you mean you have a .txt file for each feature, each with a 
different name.

In retrospect (retrospect is easy ;-), not the way I'd do it.

I don't know how big your repository is and how hard / time consuming it would 
be to go back and rename each of those .txt files with the same name, 
and then, as discussed earlier, merge those files at the same time you merge 
the features.

(E.g., you probably don't need this, but to clarify: you might have a file sort 
of like a history file (probably in reverse chronological sequence?)>:

(e.g.) file features.txt

 Feature 




...

 Feature 




Now that you're in the present condition, I don't have another suggestion to 
offer.

Re: [git-users] How to track changes to db

[rhkramer]

On Tuesday, August 04, 2020 10:34:59 PM SJW wrote:
> I am trying to find a good way to track changes to the db but havn't got it
> down pat yet.
> 
> What I am doing
> 
> ```
> git branch feature
> git checkout feature
> ```
> 
> modify code and add/modify database tables
> ...
> create a txt file called feature.txt and list changes. e.g. DB ALTER
> statements etc. that I need to apply to staging and production db's

Interesting puzzle ;-)

Do you create one file named feature.txt, or do you create a different file for 
each feature with a unique name?

(I'm trying to understand "all these text files" from below.)

One thing I'd consider is just having one file named feature.txt, or notes.txt 
and modify that as appropriate and commit it with each change.  

Then when you checkout a feature branch, you get the notes (DB ALTER 
statements) associated with that feature, and it stays associated with that 
feature branch.  

You could choose another name for the text file, perhaps: db_alter.txt



> ...
> 
> ```
> git add .
> git commit -m "Message"
> git checkout staging
> git merge feature
> git checkout master
> git merge feature
> ```
> 
> Problem I have is that I have all these txt files that are just notes so I
> delete them but they keep reappearing ( because I merged them into master
> and then create new branch etc. )
> 
> I found this was a bit annoying so I stopped adding and committing the txt
> files but now I have these txt files sitting in the unstaged changes area
> of all projects - not a great idea either.
> 
> Any suggestions on how to better manage these notes and somehow ensure they
> remain linked to each feature branch?
> 
> Thanks

Re: [git-users] Re: How to make git work!

[rhkramer]

On Wednesday, May 06, 2020 03:06:12 AM SJW wrote:
> In the grand scheme of things - it probably doesn't matter but from a
> cleanliness point of view, I'd prefer to not have to commit comment
> changes...

From the peanut gallery: if you don't commit comment changes, how would you 
expect them to get into the repository (if that is the right word)?

Re: [git-users] [offtopic] new mailing list for programming and the state-of-the-art.

[rhkramer]

I am interested in signing up for that mail list -- please send me the URL for 
signing up.

I'd also suggest you post it on this list -- one time should not be a major 
spamming problem.

On Thursday, September 05, 2019 04:43:45 PM theProphet wrote:
> Sorry for the bother, but there's a new mailing list for programmers who
> want to discuss the current state-of-the-art on googlegroups:
> programming-topics.  Since this is a group for programmers and there aren't
> that many vigorous forums on the net these days, I thought I'd share it.  I
> won't repost or respond to any replies here, only privately.
> 
> Best of luck, programmers!
> 
> \0xDynamite

Re: [git-users] Grouping of git repos

[rhkramer]

On Friday, December 14, 2018 12:35:27 PM Brett Walker wrote:
> I have 120+ Visual Studio solutions and 320+ databases (using Red Gate
> Source Control) 

What is a Visual Studio solutions (i'm too lazy at the moment to google that) 
-- is that a program / piece of software, part of a program, or is that a 
"repo" representing various commits toward a particular piece of software.

If each "solution" represents commits toward a particular piece of software, 
I'd consider combining them all into one git repo.  If the 320+ databases are 
directly related to those programs, and are not too big, I might consider 
putting all of that in one git repo.

There is no limitation (that I'm aware of) on the size or contents of a git 
repo, beyond various hardware / software limits (things like maximum size of a 
file, maximum files in a directory, ...) for a specific OS.

There is no limitation on what kind or subject of content that can be in a 
given git repository.

If they are 120 different programs, I'd seriously consider making them 120 
separate repos, unless some of the programs were closely coupled to make 
several of them part of a common (mashup?) application.

I guess my point is, make it easy on yourself and your fellow developers.

Re: [git-users] Third way to create a bare repository?

[rhkramer]

Mark (and all),

Thanks very much for your help!  I think I've got it working now, and 
reviewing what you wrote helped me realize what I had missed, basically the 
step of "naming" the bare / remote repository with =git remote add=.

I thought I'd record (on the list) more precisely what I actually did both for 
my own records and for posterity.

I had to sort of translate what you did into what I needed to do--a major 
difference is that the code I want to work on is maintained in a Mercurial 
repository upstream--I don't need to or plan to push my changes back up to 
there until I've pretty much accomplished what I want to accomplish, and, at 
that point, I'll just make a patch file to send.

A more minor difference is that I need to work on two bodies of code, so I 
needed two working repositories and two corresponding local backup 
repositories, but I will show only the steps for one of them here.

I'm starting with a working repository created in /rhk03/sciscint_git/scite, 
the code body downloaded as a tarball, opened in /rhk03/sciscint_git/scite, 
and then git committed (into /rhk03/sciscint_git/scite/.git).  My intent is to 
setup a bare repository in /back03/sciscint_git/scite/git for regular pushes 
for backup.

Note that all asterisk are extraneous--they are a means of bolding text in my 
own notetaking system.

<*set up a parent directory on filesystem back03 for the bare / remote / backup 
repositories and move to it*>
=
rhk@s31:/*back03*$ mkdir sciscint_git
rhk@s31:/back03$ cd sciscint_git
=

<*create an empty directory under that parent directory and initialize it as 
an (empty) git repository (git init --bare )*>
=
rhk@s31:/*back03/sciscint_git$ git init --bare scite_remote/git*
Initialized empty Git repository in /back03/sciscint_git/scite_remote/

rhk@s31:/back03/*sciscint_git$ ls scite_remote/git*
branches  config  description  HEAD  hooks  info  objects  refs
=

<*name the backup bare repository as a remote of the working repository (from 
within the working repository on filesystem rhk03)*>
=
rhk@s31:/back03/sciscint_git/$ cd rhk03/sciscint_git/scite
rhk@s31:/*rhk03*/sciscint_git/*scite$ git remote add scite_remote 
/back03/sciscint_git/scite_remote/git*
=

<*if you make a mistake in naming (I made several, fixed since)*>
rhk@s31:/rhk03/sciscint_git/scite$ git remote remove 

<*to see (names of) remotes for a repository*>
rhk@s31:/rhk03/sciscint_git/scite$ git remote

<*first push from working repository to remote (backup) repository--first a dry 
run*>
=
rhk@s31:/*rhk03*/sciscint_git/*scite$ git push  --dry-run* --set-upstream 
scite_remote master
To /back03/sciscint_git/scite_remote/git
 * [new branch]  master -> master
Would set upstream of 'master' to 'master' of 'scite_remote'
rhk@s31:/rhk03/sciscint_git/scite$ 

rhk@s31:/*rhk03*/sciscint_git/*scite$ git push --set-upstream scite_remote 
master*
Counting objects: 302, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (301/301), done.
Writing objects: 100% (302/302), 979.01 KiB | 0 bytes/s, done.
Total 302 (delta 26), reused 0 (delta 0)
To /back03/sciscint_git/scite_remote/git
 * [new branch]  master -> master
Branch master set up to track remote branch master from scite_remote.
=





On Monday, February 12, 2018 12:42:37 PM Mark Waite wrote:
> On Mon, Feb 12, 2018 at 9:28 AM  wrote:
> > I'm a newbie to git, but from what I've learned so far, I want to have
> > both a
> > working git repository and a "bare" git repository for some development I
> > want
> > to do.
> > 
> > I've seen two ways to create a bare repository (iirc, init --bare ... and
> > clone --bare ...) , and I've had a few problems using those so far.
> > 
> > I'm wondering if a third way will work--I would propose to copy the
> > entire contents of my working repository to another directory, then
> > delete all that
> > is not under the .git directory, and then rename the .git directory to
> > git.
> 
> That would probably work, but I think there is an easier way to resolve
> your concern for losing work from your working repository.
> 
> Create a bare repository cloned from the origin repository
> $ mkdir -p ~/git/bare
> $ cd ~/git/bare
> $ git clone --bare git@server:directory/repo.git
> 
> Create a working repository cloned from the origin repository (reference
> the bare repository if the repository is large)
> $ mkdir -p ~/git
> $ cd ~/git
> $ git clone --reference ~/git/bare/repo.git git@server:directory/repo.git
> 
> Add the bare repository as a remote of the working repository
> $ cd ~/git/repo
> $ git remote add bare ~/git/bare/repo.git
> 
> Make changes in the working repository
> $ git checkout -b feature-branch
> $ git commit -m "Your message" your-file
> 
> Push changes to both the origin repository and the bare repository
> $ git push origin --set-upstream feature-branch
> $ git push bare
> 
> That sequence keeps a separate local git repository in the ~/git/bare/
> directory in addition to the 

Re: [git-users] Using a FUSE with git?

[rhkramer]

On Wednesday, February 21, 2018 11:19:52 AM Duane Knesek wrote:
> Is that only for Windows?
> 
> If it runs in Linux, then yes that is exactly what I'd need.

I guess I'd divide that into two questions (assuming my understanding is 
correct)--my questions would be:

   * can the GVFS "service" run on Linux?

   * even if GVFS must run on Windows, can Linux clients use it?

I'm not the OP, but if I was, it would be one thing to install one or a few 
Windows servers, vs. converting (presumably) many Linux users to Windows to 
use it as a client.

[git-users] Third way to create a bare repository?

[rhkramer]

I'm a newbie to git, but from what I've learned so far, I want to have both a 
working git repository and a "bare" git repository for some development I want 
to do.

I've seen two ways to create a bare repository (iirc, init --bare ... and 
clone --bare ...) , and I've had a few problems using those so far.

I'm wondering if a third way will work--I would propose to copy the entire 
contents of my working repository to another directory, then delete all that 
is not under the .git directory, and then rename the .git directory to git.

AFAICT, this should work (although maybe I need to completely remove the .git 
directory level and move it to the parent).

In other words, assume I have:

   .../scite with a work space and a .git directory

I would plan to copy this to:

   .../back/scite with no workspace but a git directory

or:

   .../back/scite with no workspace and the content of the git directory here 
(no git subdirectory)

Comments?

Am I setting a trap for myself?

Some background:

I am paranoid about losing work, and having a hidden directory (.git) where I 
am doing development makes me more paranoid (in the past, I have done things 
like delete directories with hidden subdirectories or files because I forgot 
about the hidden stuff).  So, as I develop, after I commit to the 
.../scite/.git repository, I plan to push to the .../back/scite repository.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[git-users] Maintaining two (related) projects in one git repository at different revision levels

[rhkramer]

Background: 

I am a newbie (mostly) to C and C++ (and GCC, and git)

I am preparing to do some development on the Scintilla project (which is an 
editor control / widget / whatever).  There is a companion project named Scite 
(which is a word processor, originally developed as a platform for testing 
Scintilla).

Normally, revisions of Scite and Scintilla are ket in sync--I mean, when, for 
example, a 3.7.6 version of Scintilla is release, a 3.7.6 version of Scite is 
released at the same time.

When I understood that to be the case (and it is still usually the case) I 
intended to have a basic directory structure like the following (i.e., 
separate scite and scintilla under a sciscint directory with a .git in the 
sciscint directory to deal with both scite and scintilla)

.../sciscint   
.../sciscint/scintilla
.../sciscint/scite

Because I'm using an older OS (Debian 9.n) with older versions of GCC, I can't 
develop on the most up-to-date version of scite and scintilla as they now 
require features of (iiuc) C++ version 14 (and maybe 17), available starting 
with GCC 7.1, which is not (normally) available on Debian 9.n.

Scintilla does have a long term support version which I can compile / develop 
on Debian 9.n (version 3.7.6), but, unfortunately, the source code for scite 
3.7.6 seems to be unavailable (or at least not readily available).

Thus, I expect to start my developmen using scintilla 3.7.6 and scite 3.7.5 
for testing, and, when I compile, I expect to compile both.

So, now I'm thinking maybe I'd be better off with a directory structure like 
the following:

.../sciscint 
.../sciscint/scintilla
.../sciscint/scite

My question is, with the earlier directory structure, will I have problems 
trying to maintain scintilla at one version level and scite at a different 
version level.

In fact, now that I think about it, maybe the second directory structure is 
more appropriate in any case (as they are two different applications, and (I 
presume) I will have to compile them separately.,

Comments?

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] reverting back to earlier version to find a bug

[rhkramer]

On Saturday, December 09, 2017 11:32:32 PM Russ P wrote:
> How would it be implemented? I suppose it would be done by the build
> system. I am using Scala and sbt. Could sbt be made to automatically do a
> commit every time it builds successfully? I don't see why not. Heck, maybe
> it has that feature already and I just don't know it! And perhaps git could
> allow for "minor" commits without a comment. At least that would allow
> someone like me to locate a bug easier. What do you think?

As someone who hasn't done much development in the last 20 years, I think it 
is a great idea.  (I do write a lot of text documents, and often fail to make 
an interim save and later regret it (for any of a number of reasons).)

As far as a comment, without having used git extensively or recently (maybe 
3-4 years ago), I think some sort of automatic  comment would be useful, 
something like:

"20171210, 07:08, nn.nn.n:8" 

The nn.nn.n:8 meaning the 8th automatic commit (on a compile) after named 
branch nn.nn.n)"

Or something similar for any named commit (not necessarily a branch.

I know that some or all of that information is fairly easily available, but, 
for me, to be able to see it as a comment often seems more convenient.

I think it would also be useful to be able to easily force an "interim" auto 
commit if you've made extensive (or difficult) changes without doing a 
compilation.

"20171210, 07:08, nn.nn.n:8:3" 

The nn.nn.n:8:3 meaning the 3rd interim commit after the 8th automatic commit 
(on a compile) after named branch nn.nn.n)"

And, in both cases, git could prompt optional for additional comments (to be 
added after the automatic commit message).

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Where does git on windows store the repositories?

[rhkramer]

It may be helpful to add that the (hidden) .git directory is a subdirectory of 
the project directory.  (Which seems to be true in my experience--maybe that's 
not always the case?)

On Thursday, October 26, 2017 03:55:23 PM Philip Oakley wrote:
> The ".git" sub-directory that stores the whole repository is normally a
> hidden directory (as are most directories with a name starting with a
> dot). You can make windows explorer show them by setting an option. --
> Philip
> 
> 
>   If the repository is a working directory (not bare), then the repository
> is stored in the ".git" directory.
> 
> 
>   If the repository is bare, then it is stored in the directory itself. 
> Bare repositories typically are used on git servers, rather than on
> development desktops.
> 
>   Mark Waite
> 
> 
>   On Thu, Oct 26, 2017 at 11:50 AM Greg Quintana  wrote:
> 
> Where does git on windows store the repositories?
> 
> 
> 
> Thanks
> Greg Quintana

Re: [git-users] Recreating repo structure without content?

[rhkramer]

On Wednesday, September 27, 2017 01:56:40 PM Konstantin Khomoutov wrote:
> On Wed, Sep 27, 2017 at 12:52:34PM -0400, Paul Smith wrote:
> > Hi all.  I'm wondering if anyone has a script or something that will
> > allow me to create a new repository which recreates the commit
> > structure (parent/child, branches, merges) of an existing repository,
> > but with obfuscated content.  It's OK if this is slow.

For future readers (and based on the subject line) presumably you don't mean 
obfuscated but more like omitted (or elided).


> 
> You need the `git filter-branch` command.
> 
> To make it as fast as possible, you can use it with the "--index-filter"
> command-line option and script around it with `git cat-file` and
> `git update-index`.
> 
> If you'd prefer to trade speed for easiness of implementation, consider
> the "--tree-filter" command-line option instead.

Re: [git-users] Recreating repo structure without content?

[rhkramer]

On Wednesday, September 27, 2017 12:52:34 PM Paul Smith wrote:
> Hi all.  I'm wondering if anyone has a script or something that will
> allow me to create a new repository which recreates the commit
> structure (parent/child, branches, merges) of an existing repository,
> but with obfuscated content.  It's OK if this is slow.

Re: [git-users] keeping two branches with partially different history in sync

[rhkramer]

I see no evidence your messages are being deleted from this list.  Are you 
referring to something else?  You do know that (for some reason I don't know) 
messages that you send to most lists are either not sent back to you or, at 
least, are not displayed in typical mail clients?

On Wednesday, May 17, 2017 11:32:31 AM matevz.lan...@borea.si wrote:
> Hi,
> 
> do you have any idea why my messages are being deleted?
> 
> regards,
>   Matevz

Re: [git-users] How to generate those horizontal history graphs?

[rhkramer]

On Sunday, October 23, 2016 07:21:42 AM rhkra...@gmail.com wrote:
> (I'm not the op, and) I'm still learning git, but yesterday I was skimming
> (for another reason) man git log, and I saw some ASCII art diagrams--at the
> time, I assumed they could be generated by git.  I haven't gone back to
> check, but I will at some point.  They might have even been in the man git
> log section dealing with something like the criss-cross merge...
> 
> I'm using git version 2.1.4 (on Debian Jessie).

Ok, I did a little more looking, and there is a --graph option available for 
git log (that also works with git log --pretty=oneline --graph).

It tries to make a graph, more of a vertical thing (rather than horizontal).

ATM, I am working my way through Ry's tutorial on git (which is helping me a 
lot, so far), but the point is that I currently have no branches (or, I'm not 
sure of the best terminology, maybe I should say I have only the MASTER 
branch?), and the graph isn't that helpful nor is it complex...

But, it might be helpful with more branches, or give you an easy means to 
translate to the horizontal type diagram that you (and I) think is helpful...

Re: [git-users] How to generate those horizontal history graphs?

[rhkramer]

On Sunday, October 23, 2016 05:26:02 AM Philip Oakley wrote:
> The ascii-art is done using the technique / tool of keyboard, hand/eye
> coordination and mono-spaced editor ;-) [Unfortunately]
> 
> As an aside, you will notice that most of the horizontal (left to right
> history) graphs are not of real history, but are of carefully selected
> examples designed to show some point, hence the hand-eye-brain coordination
> requirement.
> 
> Even the ascii --graph can be poor relative to a hand tweaked one.  Now if
> there were a way to add the right (that 'brain' input step) emphasis to --
> graph then that would be a good improvement - e.g. a criss-cross merge (see
> 'git help merge-base').

(I'm not the op, and) I'm still learning git, but yesterday I was skimming 
(for another reason) man git log, and I saw some ASCII art diagrams--at the 
time, I assumed they could be generated by git.  I haven't gone back to check, 
but I will at some point.  They might have even been in the man git log 
section dealing with something like the criss-cross merge...

I'm using git version 2.1.4 (on Debian Jessie).

[git-users] Re: Using git in an unusual way, need advice

[rhkramer]

The other post, previously sent to the wrong list:

On Sunday, October 16, 2016 09:39:41 PM rhkra...@gmail.com wrote:
> I am probably using git in an unusual way.

...

> But, I'm not sure how to handle further updates after I've made local
> changes to the source code.
> 
> The one approach I can think of is to create a patch file before I download
> the next update, then download and untar the next update, and then apply
> that patch file (while doing git adds and commits at the appropriate
> times, which I have to think about).
> 
> But the patch file approach seems rather cumbersome and un-git (and un-CMS)
> like--is there a better approach?

I've done / am doing more reading, and my approach is probably not as unusual 
as I thought, and I've found instructions on creating and applying patches to 
/ from git, so I'll probably be (close to) OK after I do some more reading.

[git-users] Using git in an unusual way, need advice

[rhkramer]

I sent this and the next email to another list and didn't get any response--
I've partially resolved my issue (see next post), and I'm also beginning to 
understand that branches might also solve my issue (but patches see more 
straightforward.

I'm resending it here as I welcome comments and suggestions:

Original email:

I am probably using git in an unusual way.

I want to do some development for a project that is managed by Mercurial 
(scite / scintilla), but, for the sake of learning git (and minimizing the 
need to learn anything else)  I want to use git for the work I do.

I've downloaded the source code as tarballs (which are available--I could also 
have downloaded the source code using Mercurial, but, as long as the tarballs 
are available, I'd prefer to do it using tarballs).

I originally downloaded version 3.66 of the source code, untarred it into a 
working directory, initialized a git repository, and then added and committed 
the source code to the git repository.

So far, I haven't actually made any changes to the source code.

Now version 3.70 is available, and I sort of repeated the process, that is, I 
untarred the new version into the working directory that I had previously 
created, then did a git status--it seemed to recognize the modified files, 
which 
I then added and committed.

So far, so good.

But, I'm not sure how to handle further updates after I've made local changes 
to the source code.

The one approach I can think of is to create a patch file before I download the 
next update, then download and untar the next update, and then apply that 
patch file (while doing git adds and commits at the appropriate times, which I 
have to think about).

But the patch file approach seems rather cumbersome and un-git (and un-CMS) 
like--is there a better approach?

Thanks!

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[git-users] Re: Using git in an unusual way, need advice

[rhkramer]

On Sunday, October 16, 2016 09:39:41 PM rhkra...@gmail.com wrote:
> I am probably using git in an unusual way.

...

> But, I'm not sure how to handle further updates after I've made local
> changes to the source code.
> 
> The one approach I can think of is to create a patch file before I download
> the next update, then download and untar the next update, and then apply
> that patch file (while doing git adds and commits at the appropriate
> times, which I have to think about).
> 
> But the patch file approach seems rather cumbersome and un-git (and un-CMS)
> like--is there a better approach?

I've done / am doing more reading, and my approach is probably not as unusual 
as I thought, and I've found instructions on creating and applying patches to 
/ from git, so I'll probably be (close to) OK after I do some more reading.

Re: [git-users] Newbie: How to get my working tree back using git checkout?

[rhkramer]

On Friday, August 26, 2016 04:25:20 PM Dale R. Worley wrote:
> rh kramer  writes:
> > I've tried a number of variations, but I'm not getting the software (I
> > guess git would call it the working tree) back.  Some of the variations
> > (all run from within sciscint_git):
> > 
> > git checkout HEAD
> > git checkout MASTER
> > git checkout 76641b5
> > 
> > I've also tried those with the -b option.
> > 
> > What am I doing wrong?
> 
> The problem is that "Local modifications to the files in the working
> tree are kept, so that they can be committed to the ."
> 
> What I think you need to do is "git reset --hard HEAD".

Ahh, ok.  

Then, maybe another option is to go ahead and add and commit those deletions, 
then checkout the earlier branch?

I'll try that a little later tonight before I try the reset, unless somebody 
tells me that would be a big mistake.  (I guess after I do the add and commit, 
I won't need the reset, but in the meantime, I'll read up on reset.)

Thanks!

Randy Kramer