8:41 a.m.
Hi,
for coint2 and var/vecm the "--seasonal" option is deprecated I think
but still tolerated.
In the guide, however, it still appears twice, in sections 30.3 and 30.4.
(When will I ever become comfortable with git, this would be an easy
fix...?)
cheers,
sven
6:42 p.m.
On Tue, 24 Apr 2018, Sven Schreiber wrote:
(When will I ever become comfortable with git, this would be an
easy fix...?)
Following up on the second point in Sven's posting. Git is really
pretty simple. Here's a capsule guide for anyone wanting to modify a
single file.
1. Ensure your local copy is up to date. _Always_ do this first to
avoid grief later:
git pull
2. Edit the file of interest and save your changes.
3. If you're at all unsure that you made the changes you really
intended, take a look:
git diff
4. If that's OK, register your changes locally:
git commit -a # or instead of "-a", a specific filename
5. Then push your modification to sourceforge:
git push
6. To double-check that all is OK:
git status
You should see:
"Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree clean"
Summary: git pull, edit, git commit, git push
Allin
6:28 p.m.
Am 29.04.2018 um 20:42 schrieb Allin Cottrell:
Thanks for this git-for-dummies guide.
5. Then push your modification to sourceforge:
git push
And what should be done to make a proposed patch known but not apply
/push it right away? Something like: check if this would be OK.
thanks,
sven
7 p.m.
On Thu, 3 May 2018, Sven Schreiber wrote:
If I'm understanding you right, that would be a case for
git diff > trythis.diff
and emailing the diff to people to try out. A more complicated
approach would be to create an experimental branch in the git
repository, switch to the new branch, and commit your changes on that.
Then you could tell people to try out your branch.
I can't say that I'm entirely comfortable with the latter myself,
though it's standard git procedure and I should get to know it.
There's scope for things going nastily wrong if you don't really know
what you're doing.
Allin
8:16 a.m.
Am 03.05.2018 um 21:00 schrieb Allin Cottrell:
On Thu, 3 May 2018, Sven Schreiber wrote:
> Am 29.04.2018 um 20:42 schrieb Allin Cottrell:
And would that come before or after "git commit ..." ? (Before "git
push" in any case, that much is clear.)
Part of my confusion/insecurity with git is the term "commit" which
sounds far-reaching but apparently isn't.
thanks,
sven
1:19 p.m.
On Fri, 4 May 2018, Sven Schreiber wrote:
This is to do with the inherently distributed nature of git. I agree
it can be confusing. "commit" updates the metadata in your local copy
only; "push" sends the update to "origin" (in this case sourceforge).
As for "git diff": in its plain form this should come before "commit",
because after a local commit of the relevant file(s) there is no
"diff" between those files and (local) git's records. However, if you
do a commit first and then want to see how your local copy differs
from "origin" you can still do that with a modified command:
git diff origin/master
So the order doesn't really matter much. This sort of thing is spelled
out a bit more at
http://gretl.sourceforge.net/gretl-git-basics.html
Allin
2528
days inactive
2538
days old
6 comments
2 participants
participants (2)
-
Allin Cottrell -
Sven Schreiber