Hi All,
I find myself in this situation a lot: Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: platforms/Cross/plugins/IA32ABI/ia32abi.h modified: platforms/Cross/plugins/IA32ABI/x64ia32abicc.c modified: platforms/Cross/plugins/IA32ABI/xabicc.c Untracked files: (use "git add <file>..." to include in what will be committed) platforms/Cross/plugins/IA32ABI/.ia32abicc.c.swp What's the one liner to add the modified files and ignore the untracked files? What's the one-liner to add and commit the modified files and ignore the untracked files? [hate the word "add" being used to mean "stage". This thing was written by a sadist]. _,,,^..^,,,_ best, Eliot |
Eliot, regarding how to ignore the untracked files, you could ignore those files by adding them to .gitignore, and they won't bother you again. here's the documentation On Sat, Jun 18, 2016 at 8:58 PM, Eliot Miranda <[hidden email]> wrote:
Bernardo E.C. Sent from a cheap desktop computer in South America. |
Actually, calling all git mavens - please, please, point the rest of us to some documentation that might possibly be understood by humans. Some of us have no idea at all how this works and need something in style of ‘see spot download some code. See spot build it. Run it, spot, run it! Oh dear, spot - a bug. Fix the bug, spot, fix it! Now save the code. Now pour the custard in m’boots!' and so on. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim ...now touch these wires to your tongue! |
In reply to this post by Eliot Miranda-2
On Sun, Jun 19, 2016 at 7:58 AM, Eliot Miranda <[hidden email]> wrote: > > Hi All, > > I find myself in this situation a lot: > > Changes not staged for commit: > (use "git add <file>..." to update what will be committed) > (use "git checkout -- <file>..." to discard changes in working directory) > > modified: platforms/Cross/plugins/IA32ABI/ia32abi.h > modified: platforms/Cross/plugins/IA32ABI/x64ia32abicc.c > modified: platforms/Cross/plugins/IA32ABI/xabicc.c > > Untracked files: > (use "git add <file>..." to include in what will be committed) > > platforms/Cross/plugins/IA32ABI/.ia32abicc.c.swp > > What's the one liner to add the modified files and ignore the untracked files? git stage -u (i.e. git stage --update) > What's the one-liner to add and commit the modified files and ignore the untracked files? git commit -a > > [hate the word "add" being used to mean "stage". This thing was written by a sadist]. > _,,,^..^,,,_ > best, Eliot > |
In reply to this post by timrowledge
On Sat, 2016-06-18 at 17:41 -0700, tim Rowledge wrote: > > Actually, calling all git mavens - please, please, point the rest of > us to some documentation that might possibly be understood by humans. > Some of us have no idea at all how this works and need something in > style of ‘see spot download some code. See spot build it. Run it, > spot, run it! Oh dear, spot - a bug. Fix the bug, spot, fix it! Now > save the code. Now pour the custard in m’boots!' and so on. > > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > ...now touch these wires to your tongue! > > There's a *lot* of content out there for migrating from svn (and other systems) to git. This looks like a good 'I know how to do it in svn, now how do I do it in git?' basics page: http://git.or.cz/course/svn.ht ml and here's a version that might look nicer in hard copy form: https: //www.git-tower.com/blog/git-for-subversion-users-cheat-sheet/ |
In reply to this post by timrowledge
I think Ben meant to post `git add -u` (there is no "stage" command, but you can create aliases). Long post follows, tl;dr/toc: a book recommendation; do not rely on svn-to-git tables forever; a possible explanation for why add is called add; a use case for staging (for those who might see it as an unnecessary complication); remember the "stash" command; you might like "bisect" for bug-hunting. What documentation have you already read except for the manpages? I liked the book mentioned on the git Homepage: https://git-scm.com/book/en/v2 But I don't remember how good I knew git already when I read parts of it. I found the Git Internals chapter to be particularly enlightening, but I understand if you do not wish to deal with the internals just to get going with it. :-) Although SVN to Git migration guides and "translation" tables might be what you look for in the beginning, you should definitely adjust to Git's vocabulary for a happier life (at least happier on condition that you work with Git). Regarding the "add" for "stage": imagine that you do not track files with git, but content (that's also how its database is built like). So you "add" changes to Git's knowledge of your content. The really nice part about the staging, by the way, is that it allows you to commit only part of your changes, for smaller and more focused commits even after you "went into the flow", fixed a hundred bugs, and added ten features along the way, including that nifty utility function that everyone ought to have on their branches (and want to cherry-pick)... You can even can add individual lines from changed files instead of the whole file (git add -p/--patch). I use it all the time in my (non-Smalltalk) projects, but SVN cannot do that. I figure it does not help so much with Smalltalk code, but could be handy for all that C. Also, if you ever happen to be working on something you do not want to commit yet (even though you commit locally), but you have to switch branches or merge something anyway (which svn update forces on you all the time), you should remember the "git stash" command. It basically puts aside local changes to tracked files for later retrieval. I would say this is a must-know because Git won't in general let you perform destructive operations on files with uncommitted changes (merge and checkout are probably the most common ones), so you don't accidentally lose any changes. Git is really quite good at not letting you lose something, but it takes time to get used to it and appreciate that it only wants to help. And you still have to know the commands to get stuff back after you made a wrong decision. ;-) But remember that you won't get something back you have never "added" to Git. For the bug spotting part in tim's story, you might find the bisect command interesting, when you have some time to read up about it. If you are really proficient with that, you can make it automatically search the history for a commit that introduced a bug you just discovered. But I guess we would need some tooling to exploit that to its fullest. Well, I think that's enough text for today, sorry. ;-) 2016-06-19 7:37 GMT+02:00 Phil (list) <[hidden email]>: > > On Sat, 2016-06-18 at 17:41 -0700, tim Rowledge wrote: >> >> Actually, calling all git mavens - please, please, point the rest of >> us to some documentation that might possibly be understood by humans. >> Some of us have no idea at all how this works and need something in >> style of ‘see spot download some code. See spot build it. Run it, >> spot, run it! Oh dear, spot - a bug. Fix the bug, spot, fix it! Now >> save the code. Now pour the custard in m’boots!' and so on. >> >> tim >> -- >> tim Rowledge; [hidden email]; http://www.rowledge.org/tim >> ...now touch these wires to your tongue! >> >> > > There's a *lot* of content out there for migrating from svn (and other > systems) to git. This looks like a good 'I know how to do it in svn, > now how do I do it in git?' basics page: http://git.or.cz/course/svn.ht > ml and here's a version that might look nicer in hard copy form: https: > //www.git-tower.com/blog/git-for-subversion-users-cheat-sheet/ |
On Sun, Jun 19, 2016 at 10:53 PM, Jakob Reschke <[hidden email]> wrote: > > I think Ben meant to post `git add -u` (there is no "stage" command, > but you can create aliases). oh but there is ;) see `man git-stage` ? I was surprised to find it. btw, git version 2.1.4 cheers -ben |
In reply to this post by Jakob Reschke-2
2016-06-19 16:57 GMT+02:00 Ben Coman <[hidden email]>: > > On Sun, Jun 19, 2016 at 10:53 PM, Jakob Reschke > <[hidden email]> wrote: >> >> I think Ben meant to post `git add -u` (there is no "stage" command, >> but you can create aliases). > > oh but there is ;) > see `man git-stage` ? > I was surprised to find it. > btw, git version 2.1.4 > > cheers -ben Oops, you're right! I had never seen that. Although it already exists since 1.6.1... I stand corrected -- suspected a typo before. |
In reply to this post by Eliot Miranda-2
git commit -a
will add all the modified files and open an editor where you can write the commit message. Once the editor exits it git will complete the commit. git commit -am"Here is my commit message" will add all modified files to the commit, make the commit message 'Here is my commit message' and then commit. To configure a specific editor (e.g. emacs, vim, textmate) that can be used when writing lengthier commit messages by one time per computer running git config --global core.editor "emacsclient"
|
In reply to this post by timrowledge
On Sun, Jun 19, 2016 at 8:41 AM, tim Rowledge <[hidden email]> wrote: > > Actually, calling all git mavens - please, please, point the rest of us to some documentation that might possibly be understood by humans. Some of us have no idea at all how this works I found these Atlassian tutorials really nice (and often refer to them)... * https://www.atlassian.com/git/tutorials Github Help "Fork a repo" provides a scratch repo for you to practice on without fear. * https://help.github.com/ git - the simple guide (I only just bumped into this, looks good) * http://rogerdudler.github.io/git-guide/ > and need something in style of ‘see spot download some code. See spot build it. Run it, spot, run it! Oh dear, spot - a bug. Fix the bug, spot, fix it! Now save the code. Now pour the custard in m’boots!' and so on. Okay Spot. Here is a proposed recipe. This is for those having having write access to the official repository and cloned that to work in. I'll follow up with an adaption for forked repos tomorrow. 1. Go to https://github.com/OpenSmalltalk/vm 2. Click the green <Clone or download> button. (If you've already set up your SSH keys, click "Use SSH".) then copy the url to the clipboard. 3. Clone to your local machine $ git clone #paste url from the clipboard here $ cd vm $ git remove -v origin [hidden email]:OpenSmalltalk/vm.git (fetch) origin [hidden email]:OpenSmalltalk/vm.git (push) or... origin https://github.com/OpenSmalltalk/vm.git (fetch) origin https://github.com/OpenSmalltalk/vm.git (push) ...depending on ssh or https clone respectively 4. Create a branch to work on... $ git fetch #updates all branches to latest $ git checkout -b SomeBug Cog 5. Edit, compile, test cycle. Commit often along the way. * make required changes $ git stage -u $ git diff ; git diff HEAD $ git commit -m "SomeBug - part way there" Repeat as necessary 6. Ready to submit. Clean up *local* history (since we committed quite often) $ git rebase -i # Squash inconsequential commits. Rebase is okay before publishing. Ref: https://www.atlassian.com/git/articles/git-team-workflows-merge-or-rebase/ https://www.atlassian.com/git/tutorials/merging-vs-rebasing/conceptual-overview 7. Catch up to official Cog branch $ git fetch # updates origin/* $ git log HEAD..origin/Cog # review other updates $ git diff origin/Cog # review other updates Depending on whether the final history should be linear (more like SVN??) $ git rebase origin/Cog # rebase okay since not yet published or show the branching... $ get merge origin/Cog ...might depend on whether its a small fix or a larger feature added. 8. Submit for review $ git push # to server You will see... fatal: The current branch SomeBug has no upstream branch. which is because the SomeBug branch only exists locally, not on the github server. The following creates the branch on the "origin" server and sets things so subsequently this branch only requires "git push". $ git push --set-upstream origin SomeBug * On github, from the <Branch> pulldown button, select your SomeBug branch. * Click <New pull request> button. For more detail refer... https://help.github.com/articles/using-pull-requests/ (In the meantime, work on some other branch) 7. Reviewers can download PR to test locally as described here... https://help.github.com/articles/checking-out-pull-requests-locally/ (though I've not done that since I've not been on the receiving side of a pull request before) 8. Respond to reviewer comments. Edit, compile, test, resubmit. $ git checkout SomeBug * make required changes $ git stage -u $ git commit -m "changed per feedback " $ git push # Pull request auto updated (Repeat as required) 9. Pull request acceptable. Optionally (and some policy discussion required) squash changes from review period. $ git rebase -i $ git push -f Note this does rewrite the history of the published SomeBug branch, but presumably the branch is thrown away after integration so no real foul. But forcing pushing may be risk for accidentally doing it to the Cog or master branches. (btw, has the force protection on those two branches been tested?) 10. On github, integrator accepts pull request. 11. Delete branch. |
Whoops, correction down below... On Mon, Jun 20, 2016 at 1:00 AM, Ben Coman <[hidden email]> wrote: > On Sun, Jun 19, 2016 at 8:41 AM, tim Rowledge <[hidden email]> wrote: >> >> Actually, calling all git mavens - please, please, point the rest of us to some documentation that might possibly be understood by humans. Some of us have no idea at all how this works > > I found these Atlassian tutorials really nice (and often refer to them)... > * https://www.atlassian.com/git/tutorials > > Github Help "Fork a repo" provides a scratch repo for you to practice > on without fear. > * https://help.github.com/ > > git - the simple guide (I only just bumped into this, looks good) > * http://rogerdudler.github.io/git-guide/ > >> and need something in style of ‘see spot download some code. See spot build it. Run it, spot, run it! Oh dear, spot - a bug. Fix the bug, spot, fix it! Now save the code. Now pour the custard in m’boots!' and so on. > > Okay Spot. Here is a proposed recipe. This is for those having having > write access to the official repository and cloned that to work in. > I'll follow up with an adaption for forked repos tomorrow. > > 1. Go to https://github.com/OpenSmalltalk/vm > > 2. Click the green <Clone or download> button. > (If you've already set up your SSH keys, click "Use SSH".) > then copy the url to the clipboard. > > 3. Clone to your local machine > $ git clone #paste url from the clipboard here > $ cd vm sorry, this should have been $ git remote -v > origin [hidden email]:OpenSmalltalk/vm.git (fetch) > origin [hidden email]:OpenSmalltalk/vm.git (push) > or... > origin https://github.com/OpenSmalltalk/vm.git (fetch) > origin https://github.com/OpenSmalltalk/vm.git (push) > ...depending on ssh or https clone respectively > > 4. Create a branch to work on... > $ git fetch #updates all branches to latest > $ git checkout -b SomeBug Cog > > 5. Edit, compile, test cycle. Commit often along the way. > * make required changes > $ git stage -u > $ git diff ; git diff HEAD > $ git commit -m "SomeBug - part way there" > Repeat as necessary > > 6. Ready to submit. Clean up *local* history (since we committed quite often) > $ git rebase -i # Squash inconsequential commits. Rebase is > okay before publishing. > Ref: https://www.atlassian.com/git/articles/git-team-workflows-merge-or-rebase/ > https://www.atlassian.com/git/tutorials/merging-vs-rebasing/conceptual-overview > > 7. Catch up to official Cog branch > $ git fetch # updates origin/* > $ git log HEAD..origin/Cog # review other updates > $ git diff origin/Cog # review other updates > Depending on whether the final history should be linear (more like SVN??) > $ git rebase origin/Cog # rebase okay since not yet published > or show the branching... > $ get merge origin/Cog > ...might depend on whether its a small fix or a larger feature added. > > 8. Submit for review > $ git push # to server > You will see... > fatal: The current branch SomeBug has no upstream branch. > which is because the SomeBug branch only exists locally, not on the > github server. The following creates the branch on the "origin" server > and sets things so subsequently this branch only requires "git push". > $ git push --set-upstream origin SomeBug > * On github, from the <Branch> pulldown button, select your SomeBug branch. > * Click <New pull request> button. For more detail refer... > https://help.github.com/articles/using-pull-requests/ > > (In the meantime, work on some other branch) > > 7. Reviewers can download PR to test locally as described here... > https://help.github.com/articles/checking-out-pull-requests-locally/ > (though I've not done that since I've not been on the receiving side > of a pull request before) > > 8. Respond to reviewer comments. Edit, compile, test, resubmit. > $ git checkout SomeBug > * make required changes > $ git stage -u > $ git commit -m "changed per feedback " > $ git push # Pull request auto updated > (Repeat as required) > > 9. Pull request acceptable. Optionally (and some policy discussion > required) squash changes from review period. > $ git rebase -i > $ git push -f > Note this does rewrite the history of the published SomeBug branch, > but presumably the branch is thrown away after integration so no real > foul. But forcing pushing may be risk for accidentally doing it to > the Cog or master branches. (btw, has the force protection on those > two branches been tested?) > > 10. On github, integrator accepts pull request. > > 11. Delete branch. |
In reply to this post by Ben Coman
Update for people working from a forked repository... (btw a tip, try using tab completion for repo names:) On Mon, Jun 20, 2016 at 1:00 AM, Ben Coman <[hidden email]> wrote: > On Sun, Jun 19, 2016 at 8:41 AM, tim Rowledge <[hidden email]> wrote: >> >> Actually, calling all git mavens - please, please, point the rest of us to some documentation that might possibly be understood by humans. Some of us have no idea at all how this works > 1. Go to https://github.com/OpenSmalltalk/vm 1b. Click the <Fork> button in the top right. You'll then be looking at https://github.com/YOURNAME/vm > 2. Click the green <Clone or download> button. > (If you've already set up your SSH keys, click "Use SSH".) > then copy the url to the clipboard. > > 3. Clone to your local machine > $ git clone #paste-url-from-the-clipboard-here > $ cd vm # or opensmalltalk-vm if official repo is renamed > $ git remote -v > origin [hidden email]:OpenSmalltalk/vm.git (fetch) > origin [hidden email]:OpenSmalltalk/vm.git (push) > or... > origin https://github.com/OpenSmalltalk/vm.git (fetch) > origin https://github.com/OpenSmalltalk/vm.git (push) > ...depending on ssh or https clone respectively > 3b. Additionally, set up quick reference to the upstream repository $ git remote add OpenSmalltalk https://github.com/OpenSmalltalk/vm $ git remote -v OpenSmalltalk https://github.com/OpenSmalltalk/vm (fetch) OpenSmalltalk https://github.com/OpenSmalltalk/vm (push) origin [hidden email]:bencoman/vm.git (fetch) origin [hidden email]:bencoman/vm.git (push) > 4. Create a branch to work on... > $ git fetch #updates all branches to latest > $ git checkout -b SomeBug Cog 4. Instead, now do... $ git fetch OpenSmalltalk $ git checkout -b ABug OpenSmalltalk/Cog Good to create server repo straight away to avoid later "no upstream branch" error $ git push -u origin $ git branch --all # oldTrunk & plugin branches not shown for clarity * ABug Cog master remotes/OpenSmalltalk/Cog remotes/OpenSmalltalk/master remotes/origin/ABug remotes/origin/Cog remotes/origin/HEAD -> origin/Cog remotes/origin/master > 5. Edit, compile, test cycle. Commit often along the way. > * make required changes > $ git stage -u > $ git diff ; git diff HEAD > $ git commit -m "SomeBug - part way there" > Repeat as necessary > > 6. Ready to submit. Clean up *local* history (since we committed quite often) > $ git rebase -i # Squash inconsequential commits. Rebase is > okay before publishing. > Ref: https://www.atlassian.com/git/articles/git-team-workflows-merge-or-rebase/ > https://www.atlassian.com/git/tutorials/merging-vs-rebasing/conceptual-overview > > 7. Catch up to official Cog branch > $ git fetch # updates origin/* > $ git log HEAD..origin/Cog # review other updates > $ git diff origin/Cog # review other updates > Depending on whether the final history should be linear (more like SVN??) > $ git rebase origin/Cog # rebase okay since not yet published > or show the branching... > $ get merge origin/Cog > ...might depend on whether its a small fix or a larger feature added. 7. Instead now do... $ git fetch OpenSmalltalk $ dit diff OpenSmalltalk/Cog $ git rebase OpenSmalltalk/Cog or... $ git merge OpenSmalltalk/Cog > 8. Submit for review > $ git push # to server > You will see... > fatal: The current branch SomeBug has no upstream branch. > which is because the SomeBug branch only exists locally, not on the > github server. The following creates the branch on the "origin" server > and sets things so subsequently this branch only requires "git push". > $ git push --set-upstream origin SomeBug > * On github, from the <Branch> pulldown button, select your SomeBug branch. > * Click <New pull request> button. For more detail refer... > https://help.github.com/articles/using-pull-requests/ > > (In the meantime, work on some other branch) > > 7. Reviewers can download PR to test locally as described here... > https://help.github.com/articles/checking-out-pull-requests-locally/ > (though I've not done that since I've not been on the receiving side > of a pull request before) > > 8. Respond to reviewer comments. Edit, compile, test, resubmit. > $ git checkout SomeBug > * make required changes > $ git stage -u > $ git commit -m "changed per feedback " > $ git push # Pull request auto updated > (Repeat as required) > > 9. Pull request acceptable. Optionally (and some policy discussion > required) squash changes from review period. > $ git rebase -i > $ git push -f > Note this does rewrite the history of the published SomeBug branch, > but presumably the branch is thrown away after integration so no real > foul. But forcing pushing may be risk for accidentally doing it to > the Cog or master branches. (btw, has the force protection on those > two branches been tested?) > > 10. On github, integrator accepts pull request. > > 11. Delete branch. cheers -ben |
In reply to this post by timrowledge
Hi Tim-- > Actually, calling all git mavens - please, please, point the rest of > us to some documentation that might possibly be understood by humans. Definitely read the fine documentation others have mentioned, but also try one of the decent visual interfaces for git, such as SourceTree[1]. -C [1] https://www.sourcetreeapp.com -- Craig Latta Black Page Digital Amsterdam [hidden email] +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS) |
Free forum by Nabble | Edit this page |