Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Sun 22 Apr 2018, 10:37
All times are UTC - 4
 Forum index » House Training » HOWTO ( Solutions )
Howto git PART 1
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 3 of 3 [40 Posts]   Goto page: Previous 1, 2, 3
Author Message
MochiMoppel


Joined: 26 Jan 2011
Posts: 1497
Location: Japan

PostPosted: Tue 03 Feb 2015, 06:48    Post subject:  

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)?
Back to top
View user's profile Send private message 
mavrothal


Joined: 24 Aug 2009
Posts: 2964

PostPosted: Tue 03 Feb 2015, 07:08    Post subject:  

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:
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.

_________________
== Here is how to solve your Linux problems fast ==
Back to top
View user's profile Send private message 
MochiMoppel


Joined: 26 Jan 2011
Posts: 1497
Location: Japan

PostPosted: Thu 05 Feb 2015, 03:57    Post subject:  

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.
Back to top
View user's profile Send private message 
mavrothal


Joined: 24 Aug 2009
Posts: 2964

PostPosted: Thu 05 Feb 2015, 06:06    Post subject:  

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 Smile
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...)

_________________
== Here is how to solve your Linux problems fast ==
Back to top
View user's profile Send private message 
MochiMoppel


Joined: 26 Jan 2011
Posts: 1497
Location: Japan

PostPosted: Thu 05 Feb 2015, 07:55    Post subject:  

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.
Back to top
View user's profile Send private message 
stemsee

Joined: 27 Jun 2013
Posts: 2138
Location: In The Way

PostPosted: Thu 05 Feb 2015, 08:09    Post subject:  

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.
Back to top
View user's profile Send private message MSN Messenger 
MochiMoppel


Joined: 26 Jan 2011
Posts: 1497
Location: Japan

PostPosted: Thu 05 Feb 2015, 22:33    Post subject:  

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.
Back to top
View user's profile Send private message 
James186282


Joined: 08 Sep 2009
Posts: 257
Location: Minnesota

PostPosted: Sat 21 Feb 2015, 16:55    Post subject: Re: Howto git PART 1
Subject description: Using git
 

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:
mkdir puppylinux-woof-CE.d

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


Third - now the git part begins .
Type
Code:
git init
which will answer
initialized empty Git repository in /root/puppylinux-woof-CE.d/.git/

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

then type
Code:
git pull woofce
that will download the woof and print into the terminal like :
Code:
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:
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:
git checkout testing

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

Code:
 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.
Donald Knuth
Back to top
View user's profile Send private message 
Lassar

Joined: 08 Jul 2014
Posts: 215

PostPosted: Thu 23 Mar 2017, 15:43    Post subject: git checkout firmware gives error  

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?
Back to top
View user's profile Send private message 
Semme


Joined: 07 Aug 2011
Posts: 7826
Location: World_Hub

PostPosted: Thu 23 Mar 2017, 17:48    Post subject:    

Notice there's no "firmware" branch in YOUR results:
Code:
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:
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 <<<
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 3 of 3 [40 Posts]   Goto page: Previous 1, 2, 3
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » House Training » HOWTO ( Solutions )
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.0679s ][ Queries: 13 (0.0144s) ][ GZIP on ]