 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2021-10-02 8:10 PM (-4), Cousin Ricky wrote:
>
> When I connect to a new Wi-Fi, KDE opens up a wallet and asks for my
> credentials. On my old system, all I did was supply a password, but now
> it's asking me to create a new one. The last time I had to do this was
> in 2013; best I figure is some hidden data from my old system didn't get
> copied over. But I don't remember what I did 8 years ago.
>
> It asks me to choose between classic, blowfish (whatever that is) and
> GPG (whatever that is), for better protection. I choose GPG, and am
> immediately told that my system has no keys suitable for encryption, and
> to please set up at least one encryption key. I search the Web for how
> to set up a GPG encryption key, and end up thoroughly confused. I
> remember, years ago, trying to learn PGP, and I never understood that
> either.
A month of this computer harassing me to set up a GPG encryption key,
and I find out that GPG is not installed! (This would explain why I
could make no sense of the instructions I found online.) Why is an OS
asking me to use software that isn't installed?
Not only am I on the verge of a hostile divorce from Windows (this dual
boot thing isn't working out), but I'm seriously considering ditching
openSUSE and buying a computer with Linux Mint pre-installed.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2021-10-04 7:01 PM (-4), Jim Henderson wrote:
> It sounds like you probably need to do a rebase. I don't know how to do
> that in git-cola, but basically a pull just pulls the changes from the
> remote repository. A rebase "is the process of moving or combining a
> sequence of commits to a new base commit. Rebasing is most useful and
> easily visualized in the context of a feature branching workflow." (from
> https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase)
>
> What I might be inclined to do (I work from the CLI) is:
>
> git stash
> git pull --rebase
> git stash pop
>
> Stash puts your changes in a ... stash. (I know, kinda useless self-
> referential definition). It sets them aside. The pull --rebase does the
> rebase, basically making sure you have a clean copy of the upstream repo.
> The stash pop then re-applies the diffs that you stashed.
>
> From there you should be able to do a commit.
>
> Of course, if you're the only one committing to the repo, then it's
> unlikely that the remote repo is out of sync with your local copy.
Thanks. I think the problem was that I obediently added the description
and license, and that caused the conflict with the local repo. I just
deleted the GitHub repo and started over. I figure I can add the
description and license later.
I found this tutorial on YouTube. I still have questions, but it's been
helpful.
https://youtu.be/RGOj5yH7evk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2021-10-05 10:19 PM (-4), Cousin Ricky wrote:
> On 2021-10-04 7:01 PM (-4), Jim Henderson wrote:
>> It sounds like you probably need to do a rebase. I don't know how to do
>> that in git-cola, but basically a pull just pulls the changes from the
>> remote repository. A rebase "is the process of moving or combining a
>> sequence of commits to a new base commit. Rebasing is most useful and
>> easily visualized in the context of a feature branching workflow." (from
>> https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase)
>>
>> What I might be inclined to do (I work from the CLI) is:
>>
>> git stash
>> git pull --rebase
>> git stash pop
>>
>> Stash puts your changes in a ... stash. (I know, kinda useless self-
>> referential definition). It sets them aside. The pull --rebase does the
>> rebase, basically making sure you have a clean copy of the upstream repo.
>> The stash pop then re-applies the diffs that you stashed.
>>
>> From there you should be able to do a commit.
>>
>> Of course, if you're the only one committing to the repo, then it's
>> unlikely that the remote repo is out of sync with your local copy.
>
> Thanks. I think the problem was that I obediently added the description
> and license, and that caused the conflict with the local repo. I just
> deleted the GitHub repo and started over. I figure I can add the
> description and license later.
Damn. I added a license and readme to GitHub, tried to pull the changes
to my local repo, and it's still giving me exit status 128. Do I have
to do this rebase thing every time I make a change? Why does every
simple thing have to be so freaking complicated?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 05 Oct 2021 23:18:53 -0400, Cousin Ricky wrote:
> On 2021-10-05 10:19 PM (-4), Cousin Ricky wrote:
>> On 2021-10-04 7:01 PM (-4), Jim Henderson wrote:
>>> It sounds like you probably need to do a rebase. I don't know how to
>>> do that in git-cola, but basically a pull just pulls the changes from
>>> the remote repository. A rebase "is the process of moving or
>>> combining a sequence of commits to a new base commit. Rebasing is most
>>> useful and easily visualized in the context of a feature branching
>>> workflow." (from
>>> https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase)
>>>
>>> What I might be inclined to do (I work from the CLI) is:
>>>
>>> git stash git pull --rebase git stash pop
>>>
>>> Stash puts your changes in a ... stash. (I know, kinda useless self-
>>> referential definition). It sets them aside. The pull --rebase does
>>> the rebase, basically making sure you have a clean copy of the
>>> upstream repo.
>>> The stash pop then re-applies the diffs that you stashed.
>>>
>>> From there you should be able to do a commit.
>>>
>>> Of course, if you're the only one committing to the repo, then it's
>>> unlikely that the remote repo is out of sync with your local copy.
>>
>> Thanks. I think the problem was that I obediently added the
>> description and license, and that caused the conflict with the local
>> repo. I just deleted the GitHub repo and started over. I figure I can
>> add the description and license later.
>
> Damn. I added a license and readme to GitHub, tried to pull the changes
> to my local repo, and it's still giving me exit status 128. Do I have
> to do this rebase thing every time I make a change? Why does every
> simple thing have to be so freaking complicated?
A rebase shouldn't be needed every time - how did you add the license/
readme to github?
--
"I learned long ago, never to wrestle with a pig. You get dirty, and
besides, the pig likes it." - George Bernard Shaw
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2021-10-06 12:09 PM (-4), Jim Henderson wrote:
> On Tue, 05 Oct 2021 23:18:53 -0400, Cousin Ricky wrote:
>> Damn. I added a license and readme to GitHub, tried to pull the changes
>> to my local repo, and it's still giving me exit status 128. Do I have
>> to do this rebase thing every time I make a change? Why does every
>> simple thing have to be so freaking complicated?
>
> A rebase shouldn't be needed every time - how did you add the license/
> readme to github?
When you create an empty repo on GitHub, it encourages you to create a
readme and a license as part of the creation process.
For the rest of my modules, I sidestepped the problem by creating the
readme and license files in my local directories, and uploading them as
part of the initial push.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2021-10-06 10:55 PM(-4), Cousin Ricky wrote:
> On 2021-10-06 12:09 PM (-4), Jim Henderson wrote:
>> On Tue, 05 Oct 2021 23:18:53 -0400, Cousin Ricky wrote:
>>> Damn. I added a license and readme to GitHub, tried to pull the changes
>>> to my local repo, and it's still giving me exit status 128. Do I have
>>> to do this rebase thing every time I make a change? Why does every
>>> simple thing have to be so freaking complicated?
>>
>> A rebase shouldn't be needed every time - how did you add the license/
>> readme to github?
>
> When you create an empty repo on GitHub, it encourages you to create a
> readme and a license as part of the creation process.
>
> For the rest of my modules, I sidestepped the problem by creating the
> readme and license files in my local directories, and uploading them as
> part of the initial push.
Ignore that last answer; it's not just that all this wrestling with Git
has caused me to lose track of days, it has caused me to lose track of
my state of confusion. Actually, after I pushed the project to GitHub,
I used the buttons dedicated to adding the readme and the license.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 07 Oct 2021 08:40:08 -0400, Cousin Ricky wrote:
> On 2021-10-06 10:55 PM(-4), Cousin Ricky wrote:
>> On 2021-10-06 12:09 PM (-4), Jim Henderson wrote:
>>> On Tue, 05 Oct 2021 23:18:53 -0400, Cousin Ricky wrote:
>>>> Damn. I added a license and readme to GitHub, tried to pull the
>>>> changes to my local repo, and it's still giving me exit status 128.
>>>> Do I have to do this rebase thing every time I make a change? Why
>>>> does every simple thing have to be so freaking complicated?
>>>
>>> A rebase shouldn't be needed every time - how did you add the license/
>>> readme to github?
>>
>> When you create an empty repo on GitHub, it encourages you to create a
>> readme and a license as part of the creation process.
>>
>> For the rest of my modules, I sidestepped the problem by creating the
>> readme and license files in my local directories, and uploading them as
>> part of the initial push.
>
> Ignore that last answer; it's not just that all this wrestling with Git
> has caused me to lose track of days, it has caused me to lose track of
> my state of confusion. Actually, after I pushed the project to GitHub,
> I used the buttons dedicated to adding the readme and the license.
Once done, you probably just needed to do a pull before making additional
changes in your local copy. But since those would be the only files that
changed upstream, a rebase (or the stash option I mentioned earlier)
should resolve it.
The only time a rebase should be necessary is if there are changes both
remote and local that need to be reconciled, IIRC.
Jim
--
"I learned long ago, never to wrestle with a pig. You get dirty, and
besides, the pig likes it." - George Bernard Shaw
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson <nos### [at] nospam com> wrote:
> On Thu, 07 Oct 2021 08:40:08 -0400, Cousin Ricky wrote:
>
> > On 2021-10-06 10:55 PM(-4), Cousin Ricky wrote:
> >> On 2021-10-06 12:09 PM (-4), Jim Henderson wrote:
> >>> On Tue, 05 Oct 2021 23:18:53 -0400, Cousin Ricky wrote:
> >>>> Damn. I added a license and readme to GitHub, tried to pull the
> >>>> changes to my local repo, and it's still giving me exit status 128.
> >>>> Do I have to do this rebase thing every time I make a change? Why
> >>>> does every simple thing have to be so freaking complicated?
> >>>
> >>> A rebase shouldn't be needed every time - how did you add the license/
> >>> readme to github?
> >>
> >> When you create an empty repo on GitHub, it encourages you to create a
> >> readme and a license as part of the creation process.
> >>
> >> For the rest of my modules, I sidestepped the problem by creating the
> >> readme and license files in my local directories, and uploading them as
> >> part of the initial push.
> >
> > Ignore that last answer; it's not just that all this wrestling with Git
> > has caused me to lose track of days, it has caused me to lose track of
> > my state of confusion. Actually, after I pushed the project to GitHub,
> > I used the buttons dedicated to adding the readme and the license.
>
> Once done, you probably just needed to do a pull before making additional
> changes in your local copy. But since those would be the only files that
> changed upstream, a rebase (or the stash option I mentioned earlier)
> should resolve it.
>
> The only time a rebase should be necessary is if there are changes both
> remote and local that need to be reconciled, IIRC.
>
> Jim
>
>
>
> --
> "I learned long ago, never to wrestle with a pig. You get dirty, and
> besides, the pig likes it." - George Bernard Shaw
Please the experts correct me if I'm wrong, but here is the beliefs that have
kept me relatively out trouble for a while:
Almost number one thing to understand, maybe someone already explained: but
Remember that commit and push are two different actions (picture attached) and
that you have to do both every time you "finalize" some changes so that your
local(commit) and remote(push) repositories stay in synch.
Git is specific because it is decentralized (every developer works on a local
duplicate copy of the whole project tree) and its workflow can be pictured as a
raft boat floating on the water of that remote whole project, because you can
keep your local changes floating over the changes made by other people while you
were working, by doing a pull --rebase (think of your changes as being held
aside, the other dev's update done
and then your updates layered over as if they had been made after.)
So, it is best practice to *always* do that pull --rebase (avoiding many
blocking "repo not clean" error) at least before pushing your changes and also
additionally anytime you suspect some remote changes may impact your current
work to correct it accordingly and avoid drafty history.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 11 Oct 2021 10:48:25 -0400, Mr wrote:
> Please the experts correct me if I'm wrong, but here is the beliefs that
> have kept me relatively out trouble for a while:
> Almost number one thing to understand, maybe someone already explained:
> but
>
> Remember that commit and push are two different actions (picture
> attached) and that you have to do both every time you "finalize" some
> changes so that your local(commit) and remote(push) repositories stay in
> synch.
That is correct. Commit just creates a revision in the local repo. Push
uploads your commits to the remote repo.
>
> Git is specific because it is decentralized (every developer works on a
> local duplicate copy of the whole project tree) and its workflow can be
> pictured as a raft boat floating on the water of that remote whole
> project, because you can keep your local changes floating over the
> changes made by other people while you were working, by doing a pull
> --rebase (think of your changes as being held aside, the other dev's
> update done and then your updates layered over as if they had been made
> after.)
>
> So, it is best practice to *always* do that pull --rebase (avoiding many
> blocking "repo not clean" error) at least before pushing your changes
> and also additionally anytime you suspect some remote changes may impact
> your current work to correct it accordingly and avoid drafty history.
That is a good practice, certainly - I was going with the assumption that
Ricky was the only committer to his repo.
It's generally considered best practice for developers to work in their
own branches, and then to merge their branch back with the main branch
when their work is done.
That way, multiple developers can be working on different things without
stepping on each other - and the merge is the right place to resolve any
conflicts. This also encourages (per Linus' intention in the design of
git) communication between developers, since file locking isn't a thing
that happens in git (some see that as a weakness; but file locking
encourages less communication, so I see where he's coming from).
(I'm nowhere near an expert, but this is just based on my experience
working with a development team)
--
"I learned long ago, never to wrestle with a pig. You get dirty, and
besides, the pig likes it." - George Bernard Shaw
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/3/2021 8:57 PM, Kenneth wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
>
>>
>> I think I've seen enough tutorials to learn the basics of Git, and I've
>> installed Git-Cola because I need an easy visual reference for what's
>> going on.
>
> Not that I know *anything* about this stuff, but...
>
> On the Wikipedia page "Comparison of Git GUIs", it lists 50+ apps there, or
> whatever they are. Perhaps there is another easier-to-use (and 'visual') tool
> than git-cola? It's workings sound like a nightmare to fathom, from your
> description.
I really really like SmartGit.
You can't get around having to understand the basics of git (what it
does), but SmartGit does a great job of burying it by default.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
