Howto git PART 1

How to do things, solutions, recipes, tutorials
Message
Author
User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#31 Post by MochiMoppel »

Translation: Wrong approach. Good. We are making progress.

Now I have 2 options:
a) Stay in my master and change the file and issue pull request. Easiest way.
b) Get the file somehow into my testing branch and issue pull request. Difficulties already explained.

I prefer option a)
May I go ahead with a)?

User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

#32 Post by mavrothal »

MochiMoppel wrote:Translation: Wrong approach. Good. We are making progress.

Now I have 2 options:
a) Stay in my master and change the file and issue pull request. Easiest way.
b) Get the file somehow into my testing branch and issue pull request. Difficulties already explained.

I prefer option a)
May I go ahead with a)?
You can but is wrong.

Merging master into testing is as simple as

Code: Select all

git checkout master
git pull --all #make sure you are current with the repos
git checkout testing
git pull #to update it
git merge master --no-commit # so you can make needed changes
#resolve any conflicts by adding removing files by 'git add' or 'git rm' <file>
git commit -am "merge master into testing"
git push #to update the repos with the local changes
Done!
Now whatever it was added or changed in master and not in testing after the point of their diversion, is added/changed into testing too.
Whatever was deleted in master and not in testing will be deleted in testing.
Whatever was added in testing and not in master stays in testing.
Master stays as it was.
If a file was modified in testing and deleted in master or vice versa, after the point of diversion, you may have a conflict and your need to decide which way to go (keep the modified file or delete it).

You may have other conflicts depending how procedural you are with your committing, but are usually all solvable.

In general when merging, changes that happened only in the branch that you merge in will be transferred in the branch that you merge into, including their commit history. When the same file is changed simultaneously in both branches you have a conflict. Even if it is the same change!
That is why is a better idea to work in another branch (say, testing) and only when you are happy with the changes and feel they are mature enough you merge back into your master.
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#33 Post by MochiMoppel »

OK, I went ahead with plan b)

mavrothal, please understand that your perception of 'simple' and mine are very different. I know that this seems very simple for you as you do this on a daily basis and anyway need more powerful tools than the web interface can offer, but for mere mortals like me, whose modest aim is to change a few lines of code in a textfile that is displayed right in front of me in the browser, what you describe seems to be total overkill. You said yourself that the web approach is possible for simple tasks, so let's do it. Don't scare well-minded and reasonably patient users like me away by setting entry hurdles that are too high.

I now made some very minor changes to the file installpkg.sh in my testing branch and issued a pull request in the main testing branch. At least this was my intention. Please let me know if this worked. If it did, I will add some bug fixes for the same file.
There was only one thing that irritated me: In the header it said "MochiMoppel wants to commit 272 commits into master from testing". Well, I made only 1 commit in testing and I don't want to commit anything to master. Should I worry? The pull request queue shows only the pull request that I initiated, so it looks OK to me.

User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

#34 Post by mavrothal »

MochiMoppel wrote:OK, I went ahead with plan b)

mavrothal, please understand that your perception of 'simple' and mine are very different. I know that this seems very simple for you as you do this on a daily basis and anyway need more powerful tools than the web interface can offer, but for mere mortals like me, whose modest aim is to change a few lines of code in a textfile that is displayed right in front of me in the browser, what you describe seems to be total overkill. You said yourself that the web approach is possible for simple tasks, so let's do it. Don't scare well-minded and reasonably patient users like me away by setting entry hurdles that are too high.

I now made some very minor changes to the file installpkg.sh in my testing branch and issued a pull request in the main testing branch. At least this was my intention. Please let me know if this worked. If it did, I will add some bug fixes for the same file.
There was only one thing that irritated me: In the header it said "MochiMoppel wants to commit 272 commits into master from testing". Well, I made only 1 commit in testing and I don't want to commit anything to master. Should I worry? The pull request queue shows only the pull request that I initiated, so it looks OK to me.
Actually using the web interface is something I did only 2 or 3 times! So I'm the wrong person to advise on its full potential, but I did use pull reuest :)
So coming to your pull request, I did see it and rejected it (you should have a mail by now) because, what you actually tried to do was to commit your testing branch to the woof_CE master branch. Thus the 272 commits. You should compare your testing branch with the woof-CE testing with testing branch and issue the pull request on their difference, that should only be the file you changed.
Here is a short and simple guide in case I'm not clear enough (as usually...)
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#35 Post by MochiMoppel »

OK, second attempt. Looks better, though I can't quite remember how I revived my commit.

My problem in my first attempt was that I couldn't figure out how to create a pull request from my account, then switched to the main account and saw 2 promising buttons to create a pull request and surely I selected the bigger of the two. Seemed to be logical since I want to pull into the main account. If I would be operating in my own account this would be more like a push. So in all there are 3 buttons and 2 are wrong...I'll try to learn.

I keep my fingers crossed.

stemsee

#36 Post by stemsee »

Exactly.

The entire github website has a very poor linguistic model. The labels are of mixed perspectives. A mess of English language i.e. American.

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#37 Post by MochiMoppel »

Hallelujah, it worked! Thanks mavrothal for the merger and also for providing a suitable description. I've also seen the mail and your notification on the website. So I think this is the way to go for me, and once I get the hang of it and know which button to press it will be the fastest way for me to propose changes.

--------
A few hours later the next experiment. Another pull request for a bug fix. I also changed a README file to see if I can
a) revert changes after committing (apparently not)
b) can exclude a committed file from a pull request.

Surprisingly b) seems not possible. I manually reverted the README file to its original state, which consequently was recorded as commit #2, but since versions in master and testing are again equal I didn't expect these 2 commits to become included in the pull request.

User avatar
James186282
Posts: 270
Joined: Tue 08 Sep 2009, 19:14
Location: Minnesota

Re: Howto git PART 1

#38 Post by James186282 »

Each line has some purpose. A working example is always a good thing but what on earth are we doing when we do these calls to git? making directories and changing to them is all fine. I think you can assume some givens but when it comes to git I think the basic idea of lets all use this single source of source code but????

*And to the comment about having a lot of code that never compiles anyway. AMEN Brother!! I will never understand what the point of all the multi millions files are when there are always a bazillion other ones that are never included and there is little to no clue where to find them or what they do (And how likely it is that loading them will blow up your OS)

I go out of my way to look for things that have low to no overhead and are commented in detail because the frustration level is so high.
Karl Godt wrote:As many have recognized, there is

https://github.com/puppylinux-woof-CE

Since there are not many contributors, I would like to give a tutorial about how to use it .

First , you'll need the git package installed, should be part of most common devx_puppy-version.sfs .

Second , open a console urxvt or xterm window in your preferred home directory and type

Code: Select all

mkdir puppylinux-woof-CE.d
Then change into that new created directory :

Code: Select all

cd puppylinux-woof-CE.d
Third - now the git part begins .
Type

Code: Select all

git init
which will answer
initialized empty Git repository in /root/puppylinux-woof-CE.d/.git/

then type

Code: Select all

git remote add woofce https://github.com/puppylinux-woof-CE/woof-CE
which will answer nothing

then type

Code: Select all

git pull woofce
that will download the woof and print into the terminal like :

Code: Select all

remote: Counting objects: 9530, done.
remote: Compressing objects: 100% (4818/4818), done.
remote: Total 9530 (delta 3973), reused 9071 (delta 3531)
Receiving objects: 100% (9530/9530), 19.89 MiB | 388.00 KiB/s, done.
Resolving deltas: 100% (3973/3973), done.
From https://github.com/puppylinux-woof-CE/woof-CE
 * [new branch]      firmware   -> woofce/firmware
 * [new branch]      master     -> woofce/master
 * [new branch]      testing    -> woofce/testing
From https://github.com/puppylinux-woof-CE/woof-CE
 * [new tag]         0.1        -> 0.1
 * [new tag]         woof-CE-0.1 -> woof-CE-0.1
You asked to pull from the remote 'woofce', but did not specify
a branch. Because this is not the default configured remote
for your current branch, you must specify a branch on the command line.
Fourth , it ineeds to initialize the branches :

Code: Select all

git checkout firmware
will answer
Branch firmware set up to track remote branch firmware from woofce.
Switched to a new branch 'firmware'


and in the filer window you will see the created file and folder tree .

This has to be done for master and testing branches, too :

Code: Select all

git checkout testing
Branch testing set up to track remote branch testing from woofce.
Switched to a new branch 'testing'

Code: Select all

 git checkout master
Branch master set up to track remote branch master from woofce.
Switched to a new branch 'master'



#*** END of LESSON PART 1

Questions ?
Science is what we understand well enough to explain to a computer.
Art is everything else we do.
[i]Donald Knuth [/i]

Lassar
Posts: 235
Joined: Tue 08 Jul 2014, 20:01

git checkout firmware gives error

#39 Post by Lassar »

First I am a newbie when it comes to wolf-ce and git.

Command "git checkout firmware" gives me "error: pathspec 'firmware' did not match any file(s) known to git."

I followed the instructions. What went wrong?

User avatar
Semme
Posts: 8399
Joined: Sun 07 Aug 2011, 20:07
Location: World_Hub

#40 Post by Semme »

Notice there's no "firmware" branch in YOUR results:

Code: Select all

From https://github.com/puppylinux-woof-CE/woof-CE
 * [new branch]      legacy     -> woofce/legacy
 * [new branch]      master     -> woofce/master
 * [new branch]      rationalise -> woofce/rationalise
 * [new branch]      rk3288     -> woofce/rk3288
 * [new branch]      testing    -> woofce/testing
 * [new branch]      woof-next  -> woofce/woof-next
 * [new tag]         0.1        -> 0.1
 * [new tag]         0.2        -> 0.2
 * [new tag]         v0.3       -> v0.3
 * [new tag]         woof-CE-0.1 -> woof-CE-0.1
Go ahead and try'n work through it with:

Code: Select all

git checkout --help
Keep your mind flexible. :wink:
>>> Living with the immediacy of death helps you sort out your priorities. It helps you live a life less trivial <<<

Post Reply