Hello,
I would like to remind that I made this guide some time ago:
https://www.mediawiki.org/wiki/User:Petrb/Git_for_idiots
It always quite sucked and still does, but I tried to slightly rewrite it now, so it should contain more accurate information.
I would like to keep it as a super simple manual / cheat sheet for git, that is as much clear and simple as possible.
If you ever struggled with git, maybe it could help you. If you are a git expert you may want to contribute to it? The name of the guide may not be a best choice, so I might eventually move it to [[Git for dummies]] or something like that, so that it sounds a bit more friendly.
I don't know if we already have any super simple guide / cheat sheet for git, where you could find everything essential on 1 page (and it was a wiki page editable by everyone), but I think we don't. We might use this as one?
Now I also found this awesome guide: https://www.mediawiki.org/wiki/User:Aude/Git
Perhaps it would worth merging and putting to some central location?
On Tue, Nov 10, 2015 at 5:58 PM, Petr Bena benapetr@gmail.com wrote:
Hello,
I would like to remind that I made this guide some time ago:
https://www.mediawiki.org/wiki/User:Petrb/Git_for_idiots
It always quite sucked and still does, but I tried to slightly rewrite it now, so it should contain more accurate information.
I would like to keep it as a super simple manual / cheat sheet for git, that is as much clear and simple as possible.
If you ever struggled with git, maybe it could help you. If you are a git expert you may want to contribute to it? The name of the guide may not be a best choice, so I might eventually move it to [[Git for dummies]] or something like that, so that it sounds a bit more friendly.
I don't know if we already have any super simple guide / cheat sheet for git, where you could find everything essential on 1 page (and it was a wiki page editable by everyone), but I think we don't. We might use this as one?
Hi,
On 11/10/2015 09:06 AM, Petr Bena wrote:
Perhaps it would worth merging and putting to some central location?
Yes, that sounds like a good idea. I typically recommend https://www.mediawiki.org/wiki/User:Wctaiwan/Gerrit_cheatsheet to people who are confused with git.
-- Legoktm
On Tue, Nov 10, 2015 at 10:54 AM, Legoktm legoktm.wikipedia@gmail.com wrote:
Hi,
On 11/10/2015 09:06 AM, Petr Bena wrote:
Perhaps it would worth merging and putting to some central location?
Yes, that sounds like a good idea. I typically recommend https://www.mediawiki.org/wiki/User:Wctaiwan/Gerrit_cheatsheet to people who are confused with git.
+1, as someone who uses it rarely enough to /always/ have to consult the FAQs. I compiled a list at https://www.mediawiki.org/wiki/Git/Tips#See_also and posted at https://www.mediawiki.org/wiki/Topic:Ssg7cjp65lw1oc7y
Ok, I will try to merge all useful stuff in here: https://www.mediawiki.org/wiki/Git_for_dummies
On Tue, Nov 10, 2015 at 8:26 PM, Nick Wilson (Quiddity) nwilson@wikimedia.org wrote:
On Tue, Nov 10, 2015 at 10:54 AM, Legoktm legoktm.wikipedia@gmail.com wrote:
Hi,
On 11/10/2015 09:06 AM, Petr Bena wrote:
Perhaps it would worth merging and putting to some central location?
Yes, that sounds like a good idea. I typically recommend https://www.mediawiki.org/wiki/User:Wctaiwan/Gerrit_cheatsheet to people who are confused with git.
+1, as someone who uses it rarely enough to /always/ have to consult the FAQs. I compiled a list at https://www.mediawiki.org/wiki/Git/Tips#See_also and posted at https://www.mediawiki.org/wiki/Topic:Ssg7cjp65lw1oc7y
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, Nov 11, 2015 at 12:50 AM, Petr Bena benapetr@gmail.com wrote:
Ok, I will try to merge all useful stuff in here: https://www.mediawiki.org/wiki/Git_for_dummies
The problem is these are matters of widely-varying taste and background. When I tried to clean up in early 2013, git experts didn't even agree on whether the gerrit remote should be origin, or whether people should use `git review` at all. (Aside: right now [[Git]] has the awful community-splitting comment "To simply *browse & fork our code* you can use the GitHub mirror https://github.com/wikimedia." followed by the precisely wrong git clone command for someone trying to make a patch: git clone https://... Sigh.)
I would urge people to judiciously update the pages we have, and only create very targeted new pages rather than yet another starting point. https://www.mediawiki.org/wiki/Gerrit/Getting_started seems OK, it's focused on a new gerrit contributor. Gerrit/Tutorial is huge because this isn't simple.
So here's more taste and matters of opinion.
* "the minimal knowledge needed in order to push to all major repositories we use," Surely Dummies only use gerrit. Why explain anything else? * "VCS" term is not necessary, nobody uses it. * "master" explanation brings in irrelevant detail. It's "The thing you get from a remote repo and should never change" * The `svn commands` are irrelevant. Dummies don't know SVN. * Try not to use angle brackets, like git clone <repository goes here>, dummies will type them. (I realize the <source> tag won't let you italicize :-( ) * git pull --rebase is a bad idea, it leads to surprises. * The way to avoid merge conflicts is NEVER EVER make an edit without first creating a branch. * Then, the guaranteed reliable way to update is `git checkout master; git pull --ff-only`. That will stop you from making a mistake, it will stop you from having your own local master with local changes buried down the commit log. * The fact that git mergetool shows up so soon indicates this is no longer a guide for dummies, it's now a guide for troubleshooting. A guide for dummies should give commands and advice to avoid trouble. * git diff shows up too soon. Instead, dummies should be running `git status` all the time. The way pros do this is to change their shell prompt to show the repo status and branch. Setting this up will *change your life* [1]. But it's too advanced for a Dummies guide. (I think MW-Vagrant's shell should do it for you.)
* "If you want to push your branch to origin git push origin <branch_name>". Huh? I don't see how someone working on WMF projects can ever do that. The whole point of gerrit is you don't own master and should never ever edit it because that way lies misery.
I guess this is actually a guide for tool labs where people control their own remote repo and often do keep it on github. Fine, so say so: please please rename it Git/Guide_for_tool_labs_repo_users or whatever to avoid confusion.
Again, I acknowledge how hard this is.
[1] I used http://briancarper.net/blog/570/git-info-in-your-zsh-prompt , but I use the zsh shell so that's no help for 95%
On Tue, Nov 10, 2015 at 8:26 PM, Nick Wilson (Quiddity)
nwilson@wikimedia.org wrote:
On Tue, Nov 10, 2015 at 10:54 AM, Legoktm legoktm.wikipedia@gmail.com
wrote:
Hi,
On 11/10/2015 09:06 AM, Petr Bena wrote:
Perhaps it would worth merging and putting to some central location?
Yes, that sounds like a good idea. I typically recommend https://www.mediawiki.org/wiki/User:Wctaiwan/Gerrit_cheatsheet to people who are confused with git.
+1, as someone who uses it rarely enough to /always/ have to consult the
FAQs.
I compiled a list at https://www.mediawiki.org/wiki/Git/Tips#See_also and posted at https://www.mediawiki.org/wiki/Topic:Ssg7cjp65lw1oc7y
S Page wrote:
I would urge people to judiciously update the pages we have, and only create very targeted new pages rather than yet another starting point.
For sure. It might also make sense to investigate placing some of the more in-depth Git tutorial content on a project other than mediawiki.org such as Wikibooks. Wikibooks already has programming language guides, so adding version control system guides seems like a potentially nice complement. Ideally the documentation on mediawiki.org would focus more on contributing to MediaWiki (or Wikimedia code repositories).
https://www.mediawiki.org/wiki/Gerrit/Getting_started seems OK, it's focused on a new gerrit contributor.
I submit changesets to Gerrit infrequently enough that I still refer to this page. I've really enjoyed reading this thread and the links within it. A few people have told me that the "Git For Ages 4 And Up" video is decent (https://www.youtube.com/watch?v=1ffBJ4sVUb4), if anyone is interested in a non-textual Git guide.
MZMcBride
Le 12/11/2015 03:25, S Page a écrit :
On Wed, Nov 11, 2015 at 12:50 AM, Petr Bena benapetr@gmail.com wrote:
Ok, I will try to merge all useful stuff in here: https://www.mediawiki.org/wiki/Git_for_dummies
The problem is these are matters of widely-varying taste and background. When I tried to clean up in early 2013, git experts didn't even agree on whether the gerrit remote should be origin, or whether people should use `git review` at all.
Hello,
git-review is a python utility that acts as a thin wrapper around Gerrit workflow. It has been written by the OpenStack community which is a python shop.
It comes with few issues:
* the versions that comes with Linux distributions are fairly outdated and comes with known issues. * installing using the python package managers is not straightforward and has several permissions issues depending on your operating system (some install system wide which require root, others to a user writable dir etc) * old versions were pushing to the HEAD of the repo iirc which is troublesome when you are working on another branch * some global configuration is needed * you need a remote named gerrit
On that last point, git-review 1.26 comes with a new option 'usepushurl' which makes git-review reuse the origin repo and just set the push url to the ssh:// url. The 'gerrit' remote will no more be needed.
Ie in your ~/.gitconfig :
[gitreview] usepushurl = 1
What I did until that new version is that all my clones were done with a remote named 'gerrit' (git clone -o gerrit <url>).
Since folks are tired of debugging python stacktraces and incorrect git-review configuration, some are recommending to use the underlying Gerrit workflow command:
git push origin HEAD:refs/publish/<BRANCH>[/<TOPIC>]
Hashar: I think your criticisms of git-review might be out of date. On my debian system, "sudo apt-get install git-review" was sufficient to install a version of git review which is adequate for all my needs (I have never noticed any of the "known issues" you mention). And "git review -s" is a one-step way to set up the proper remotes and etc and leave you ready to use it. I am in the habit of typing "git review -u" since I noticed that sometimes it doesn't update its remotes, but I'm guessing that's more habit than necessity. None of the other steps you describe seem to be necessary. --scott
On Thu, Nov 12, 2015 at 4:10 AM, Antoine Musso hashar+wmf@free.fr wrote:
Le 12/11/2015 03:25, S Page a écrit :
On Wed, Nov 11, 2015 at 12:50 AM, Petr Bena benapetr@gmail.com wrote:
Ok, I will try to merge all useful stuff in here: https://www.mediawiki.org/wiki/Git_for_dummies
The problem is these are matters of widely-varying taste and background. When I tried to clean up in early 2013, git experts didn't even agree on whether the gerrit remote should be origin, or whether people should use `git review` at all.
Hello,
git-review is a python utility that acts as a thin wrapper around Gerrit workflow. It has been written by the OpenStack community which is a python shop.
It comes with few issues:
- the versions that comes with Linux distributions are fairly outdated
and comes with known issues.
- installing using the python package managers is not straightforward
and has several permissions issues depending on your operating system (some install system wide which require root, others to a user writable dir etc)
- old versions were pushing to the HEAD of the repo iirc which is
troublesome when you are working on another branch
- some global configuration is needed
- you need a remote named gerrit
On that last point, git-review 1.26 comes with a new option 'usepushurl' which makes git-review reuse the origin repo and just set the push url to the ssh:// url. The 'gerrit' remote will no more be needed.
Ie in your ~/.gitconfig :
[gitreview] usepushurl = 1
What I did until that new version is that all my clones were done with a remote named 'gerrit' (git clone -o gerrit <url>).
Since folks are tired of debugging python stacktraces and incorrect git-review configuration, some are recommending to use the underlying Gerrit workflow command:
git push origin HEAD:refs/publish/<BRANCH>[/<TOPIC>]
-- Antoine "hashar" Musso
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On WikiMedia Tools Lab neither "git review -s" nor "git review -u" work in my tools. They run endlessly until you abort then with a keyboard interrupt. That is annoying. Purodha
On 12.11.2015 17:35, C. Scott Ananian wrote:
Hashar: I think your criticisms of git-review might be out of date. On my debian system, "sudo apt-get install git-review" was sufficient to install a version of git review which is adequate for all my needs (I have never noticed any of the "known issues" you mention). And "git review -s" is a one-step way to set up the proper remotes and etc and leave you ready to use it. I am in the habit of typing "git review -u" since I noticed that sometimes it doesn't update its remotes, but I'm guessing that's more habit than necessity. None of the other steps you describe seem to be necessary. --scott
On Thu, Nov 12, 2015 at 4:10 AM, Antoine Musso hashar+wmf@free.fr wrote:
Le 12/11/2015 03:25, S Page a écrit :
On Wed, Nov 11, 2015 at 12:50 AM, Petr Bena benapetr@gmail.com
wrote:
Ok, I will try to merge all useful stuff in here: https://www.mediawiki.org/wiki/Git_for_dummies
The problem is these are matters of widely-varying taste and
background.
When I tried to clean up in early 2013, git experts didn't even
agree on
whether the gerrit remote should be origin, or whether people
should use
`git review` at all.
Hello,
git-review is a python utility that acts as a thin wrapper around Gerrit workflow. It has been written by the OpenStack community which is a python shop.
It comes with few issues:
- the versions that comes with Linux distributions are fairly
outdated and comes with known issues.
- installing using the python package managers is not
straightforward and has several permissions issues depending on your operating system (some install system wide which require root, others to a user writable dir etc)
- old versions were pushing to the HEAD of the repo iirc which is
troublesome when you are working on another branch
- some global configuration is needed
- you need a remote named gerrit
On that last point, git-review 1.26 comes with a new option 'usepushurl' which makes git-review reuse the origin repo and just set the push url to the ssh:// url. The 'gerrit' remote will no more be needed.
Ie in your ~/.gitconfig :
[gitreview] usepushurl = 1
What I did until that new version is that all my clones were done with a remote named 'gerrit' (git clone -o gerrit <url>).
Since folks are tired of debugging python stacktraces and incorrect git-review configuration, some are recommending to use the underlying Gerrit workflow command:
git push origin HEAD:refs/publish/<BRANCH>[/<TOPIC>]
-- Antoine "hashar" Musso
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
This seems like we need to fork the instructions for tools lab -vs- others, as has been suggested. --scott
On Thu, Nov 12, 2015 at 11:43 AM, Purodha Blissenbach < purodha@blissenbach.org> wrote:
On WikiMedia Tools Lab neither "git review -s" nor "git review -u" work in my tools. They run endlessly until you abort then with a keyboard interrupt. That is annoying. Purodha
On 12.11.2015 17:35, C. Scott Ananian wrote:
Hashar: I think your criticisms of git-review might be out of date. On my debian system, "sudo apt-get install git-review" was sufficient to install a version of git review which is adequate for all my needs (I have never noticed any of the "known issues" you mention). And "git review -s" is a one-step way to set up the proper remotes and etc and leave you ready to use it. I am in the habit of typing "git review -u" since I noticed that sometimes it doesn't update its remotes, but I'm guessing that's more habit than necessity. None of the other steps you describe seem to be necessary. --scott
On Thu, Nov 12, 2015 at 4:10 AM, Antoine Musso hashar+wmf@free.fr wrote:
Le 12/11/2015 03:25, S Page a écrit :
On Wed, Nov 11, 2015 at 12:50 AM, Petr Bena benapetr@gmail.com
wrote:
Ok, I will try to merge all useful stuff in here: https://www.mediawiki.org/wiki/Git_for_dummies
The problem is these are matters of widely-varying taste and
background.
When I tried to clean up in early 2013, git experts didn't even agree
on
whether the gerrit remote should be origin, or whether people should
use
`git review` at all.
Hello,
git-review is a python utility that acts as a thin wrapper around Gerrit workflow. It has been written by the OpenStack community which is a python shop.
It comes with few issues:
- the versions that comes with Linux distributions are fairly outdated
and comes with known issues.
- installing using the python package managers is not straightforward
and has several permissions issues depending on your operating system (some install system wide which require root, others to a user writable dir etc)
- old versions were pushing to the HEAD of the repo iirc which is
troublesome when you are working on another branch
- some global configuration is needed
- you need a remote named gerrit
On that last point, git-review 1.26 comes with a new option 'usepushurl' which makes git-review reuse the origin repo and just set the push url to the ssh:// url. The 'gerrit' remote will no more be needed.
Ie in your ~/.gitconfig :
[gitreview] usepushurl = 1
What I did until that new version is that all my clones were done with a remote named 'gerrit' (git clone -o gerrit <url>).
Since folks are tired of debugging python stacktraces and incorrect git-review configuration, some are recommending to use the underlying Gerrit workflow command:
git push origin HEAD:refs/publish/<BRANCH>[/<TOPIC>]
-- Antoine "hashar" Musso
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Purodha Blissenbach purodha@blissenbach.org wrote:
On WikiMedia Tools Lab neither "git review -s" nor "git review -u" work in my tools. They run endlessly until you abort then with a keyboard interrupt. That is annoying.
[…]
Then please file a bug report. When I run "git review -s" on a fresh clone of https://gerrit.wikimedia.org/r/operations/puppet, it fails because it does not have a key, but it does that very loudly.
Tim
Le 12/11/2015 17:35, C. Scott Ananian a écrit :
Hashar: I think your criticisms of git-review might be out of date. On my debian system, "sudo apt-get install git-review" was sufficient to install a version of git review which is adequate for all my needs (I have never noticed any of the "known issues" you mention). And "git review -s" is a one-step way to set up the proper remotes and etc and leave you ready to use it. I am in the habit of typing "git review -u" since I noticed that sometimes it doesn't update its remotes, but I'm guessing that's more habit than necessity. None of the other steps you describe seem to be necessary. --scott
Hello,
Yeah that was merely a rant about the state of git-review back when we switched from svn to git. I spent countless hours getting folks to set it up properly :(
The Debian/Ubuntu packages nowadays provides sufficiently recent versions and indeed apt-get install is probably the easiest way to get it installed.
I am diverging, but I run it from HEAD which is something like:
--- git clone ssh://review.openstack.org:29418/openstack-infra/git-review.git cd git-review pip install --user --develop .
export PATH=$PATH:~/.local/bin ---
So whenever I checkout a new commit, the command points to the new code base :-)
YMMV
Hi,
git clone ssh://review.openstack.org:29418/openstack-infra/git-review.git
fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists.
Greetings -- Purodha
On 13.11.2015 11:48, Antoine Musso wrote:
Le 12/11/2015 17:35, C. Scott Ananian a écrit :
Hashar: I think your criticisms of git-review might be out of date. On my debian system, "sudo apt-get install git-review" was sufficient to install a version of git review which is adequate for all my needs (I have never noticed any of the "known issues" you mention). And "git review -s" is a one-step way to set up the proper remotes and etc and leave you ready to use it. I am in the habit of typing "git review -u" since I noticed that sometimes it doesn't update its remotes, but I'm guessing that's more habit than necessity. None of the other steps you describe seem to be necessary. --scott
Hello,
Yeah that was merely a rant about the state of git-review back when we switched from svn to git. I spent countless hours getting folks to set it up properly :(
The Debian/Ubuntu packages nowadays provides sufficiently recent versions and indeed apt-get install is probably the easiest way to get it installed.
I am diverging, but I run it from HEAD which is something like:
git clone ssh://review.openstack.org:29418/openstack-infra/git-review.git cd git-review pip install --user --develop .
export PATH=$PATH:~/.local/bin
So whenever I checkout a new commit, the command points to the new code base :-)
YMMV
On 2015-11-13, Purodha Blissenbach purodha@blissenbach.org wrote:
Hi,
git clone ssh://review.openstack.org:29418/openstack-infra/git-review.git
fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists.
Greetings -- Purodha
You can use
git clone https://review.openstack.org/openstack-infra/git-review.git
if you don't have an account on review.openstack.org with your SSH key
Saper
On Thu, Nov 12, 2015 at 1:10 AM, Antoine Musso hashar+wmf@free.fr wrote:
On that last point, git-review 1.26 comes with a new option 'usepushurl' which makes git-review reuse the origin repo and just set the push url to the ssh:// url. The 'gerrit' remote will no more be needed.
Ie in your ~/.gitconfig :
[gitreview] usepushurl = 1
It's not really new, on older versions you needed to set the name with the defaultremote parameter. (It's even included in the tutorial https://www.mediawiki.org/wiki/Gerrit/Tutorial#Configuring_git-review, although I am not sure that's a good idea.) The problem is that the same setting cannot be used on vagrant, which needs an anonymous origin for automated (ie. passwordless) updates and an authenticated gerrit remote for pushes (T59680 https://phabricator.wikimedia.org/T59680); and vagrant-based and other checkouts behaving differently will confuse the hell out of beginners. I would rather stick with cscott's recommendation to just run git review -u all the time.
More importantly, I'm not sure it's worth to spend a lot of time on improving our gerrit documentation now that we are supposedly a few months away from ditching gerrit completely.
Le 13/11/2015 07:04, Gergo Tisza a écrit :
On Thu, Nov 12, 2015 at 1:10 AM, Antoine Musso hashar+wmf@free.fr wrote:
On that last point, git-review 1.26 comes with a new option 'usepushurl' which makes git-review reuse the origin repo and just set the push url to the ssh:// url. The 'gerrit' remote will no more be needed.
Ie in your ~/.gitconfig :
[gitreview] usepushurl = 1
It's not really new, on older versions you needed to set the name with the defaultremote parameter. (It's even included in the tutorial https://www.mediawiki.org/wiki/Gerrit/Tutorial#Configuring_git-review, although I am not sure that's a good idea.) The problem is that the same setting cannot be used on vagrant, which needs an anonymous origin for automated (ie. passwordless) updates and an authenticated gerrit remote for pushes (T59680 https://phabricator.wikimedia.org/T59680); and vagrant-based and other checkouts behaving differently will confuse the hell out of beginners. I would rather stick with cscott's recommendation to just run git review -u all the time.
The defaultremote is a different system. The git remote have two URLS: one for fetching and another for pushing. When the setting is enabled git-review -s change the push URL to point to Gerrit while the fetch one is left untouched (ie: kept anonymous).
Example using GitHub to fetch but push to Gerrit:
$ git clone https://github.com/wikimedia/cdb Cloning into 'cdb'... $ git-review -s Adding a git push url to 'origin' that maps to: ^^^^^^^^ ssh://hashar@gerrit.wikimedia.org:29418/cdb.git $ git remote -v origin https://github.com/wikimedia/cdb (fetch) origin ssh://hashar@gerrit.wikimedia.org:29418/cdb.git (push) $
We fetch from GitHub:
$ git fetch --verbose
= [up to date] master -> origin/master
And push to Gerrit:
$ git push --verbose --dry-run Pushing to ssh://hashar@gerrit.wikimedia.org:29418/cdb.git To ssh://hashar@gerrit.wikimedia.org:29418/cdb.git = [up to date] master -> master Everything up-to-date
Profit \O/
More importantly, I'm not sure it's worth to spend a lot of time on improving our gerrit documentation now that we are supposedly a few months away from ditching gerrit completely.
We can still tune it a bit when it makes senses. But yeah with Differential that will be superseed even if phasing out Gerrit is more a few quarters than a few months :-(
On Tue, Nov 10, 2015 at 6:06 PM, Petr Bena benapetr@gmail.com wrote:
Now I also found this awesome guide: https://www.mediawiki.org/wiki/User:Aude/Git
Perhaps it would worth merging and putting to some central location?
This is just stuff I had to learn up how to do at some point.
Would be happy for this to be merged / reused / combined with the other guides and be somewhere easier to find. :)
Cheers, Katie
On Tue, Nov 10, 2015 at 5:58 PM, Petr Bena benapetr@gmail.com wrote:
Hello,
I would like to remind that I made this guide some time ago:
https://www.mediawiki.org/wiki/User:Petrb/Git_for_idiots
It always quite sucked and still does, but I tried to slightly rewrite it now, so it should contain more accurate information.
I would like to keep it as a super simple manual / cheat sheet for git, that is as much clear and simple as possible.
If you ever struggled with git, maybe it could help you. If you are a git expert you may want to contribute to it? The name of the guide may not be a best choice, so I might eventually move it to [[Git for dummies]] or something like that, so that it sounds a bit more friendly.
I don't know if we already have any super simple guide / cheat sheet for git, where you could find everything essential on 1 page (and it was a wiki page editable by everyone), but I think we don't. We might use this as one?
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Le 10/11/2015 17:58, Petr Bena a écrit :
Hello,
I would like to remind that I made this guide some time ago:
https://www.mediawiki.org/wiki/User:Petrb/Git_for_idiots
It always quite sucked and still does, but I tried to slightly rewrite it now, so it should contain more accurate information.
I would like to keep it as a super simple manual / cheat sheet for git, that is as much clear and simple as possible.
If you ever struggled with git, maybe it could help you. If you are a git expert you may want to contribute to it? The name of the guide may not be a best choice, so I might eventually move it to [[Git for dummies]] or something like that, so that it sounds a bit more friendly.
I don't know if we already have any super simple guide / cheat sheet for git, where you could find everything essential on 1 page (and it was a wiki page editable by everyone), but I think we don't. We might use this as one?
Hello,
I recommend to spend some time to read and understand the book "Pro Git" by Scott Chacon and Ben Straub. It is available in several format: website, pdf, epub and even a paper version. There are even translated versions.
If you only had one chapter to read, probably 90% of my git activity is covered by chapter 3: "Git Branching".
If you feel like a pro already, look at:
`git rerere` http://www.git-scm.com/book/en/v2/Git-Tools-Rerere `git reflog` http://www.git-scm.com/docs/git-reflog
wikitech-l@lists.wikimedia.org