Does anyone know what the equivalent of git commit -a is in gitpython?
I have tried repo.index.commit, but don't see how to add the -a option.
repo.index.add adds only new files, not existing files that have been modified. It doesn't seem to support the update function as in git add -u.
I could do something like repo.git.commit('-a'), or even
repo.git.add('-u')
repo.index.commit(comment)
But I would think the high-level interface should be capable of doing this. Am I missing something?
Thanks in advance,
Evert
You are not missing anything. GitPython acts more like plumbing, not like the porcelain that is git add -u and git commit.
Therefore it is viable and recommended to use the provided git command wrapper to get work done quickly as already demonstrated in your example (e.g. repo.git.add(update=True)).
Even though it is possible to implement anything purely in GitPython, it wouldn't perform as well or be as proven as the respective native git implementation already is.
GitPython starts to become powerful if you want to access git repository data quickly and conveniently through a relatively convenient and pythonic API. Examples include accessing branch and tag information, or querying commits in all detail.
Related
I have a codebase with several changes in it that are best split up into several commits.
In git, I would use git add -p to select the changes I wanted from each file and create a commit and pull request based on those.
I'm new to SVN and I'm wondering about the best way to achieve this? It looks like I can do file-level selection, but not changes within those files?
I'm using TortoiseSVN as my local version control tool, but I'm happy to use another tool (has to run on Windows) if there's one that will do what I want.
This is something you won't get from SVN. Separating changes in your working area into multiple commit can only have a file granularity. You can't split changes from the same file into several commits.
So I'd say you should instead give a look at how git-svn works. It allows you to use Git over an SVN repository, with some limitations. You'll use git dcommit to push to the SVN repository for example. You must use a rebasing strategy over merging too. But otherwise, you get colored diffs, stash, rebasing, proper handling of multiple branches, proper formatting of patches by default, etc.
If you already know git, this will give you more, for less annoyance.
It looks like I can do file-level selection, but not changes within those files?
This is easily possible with VisualSVN plug-in for Visual Studio 2017. The feature is called QuickCommit and it helps you partially commit selected changes in a file.
Use the Commit this Block and Commit Selection context menu commands in the Visual Studio editor.
Here is an animated screenshot:
Am working on a script based on git repository. Using ruby's git library.
Having trouble to find the feature to load the full file of a history check in. In git the content can be shown like:
git show 234h23h4j23l4j:path/to/file.java
Just need to know in ruby / git, how do I do that?
Note that this commit (234h23h4j23l4j) does not necessarily have the file I'm looking at.
Or if you know any other git library can easily do this please also recommend. We can still switch, it's not too late.
You can try something like
commit = g.gcommit('1cc8667014381') #to get reference to some commit.
and then explore the commit object you get. (I found some documentation here.)
I'm forced to work with LabVIEW source code on a Windows 7 machine and am curious what might be the best setup to handle the source code in a remote Git repository.
Currently I'm handling everythin like I would with my C projects, means Git Bash and a simple .gitignore file that excludes .aliases and .lvlps files, but think that there might be some possible improvement.
Thanks for every suggestion.
You could look for tips and ideas in the NI Community Group set up just for Git users.
https://decibel.ni.com/content/groups/git-user-group?view=blog
If you have LV professional you can get diff and merge to work using
https://github.com/joerg/LabViewGitEnv
I use this together with git bash.
Well, what answers do you expect?
If you are searching for another git client, i can recommend you TortoiseGit. Im working with Egit, but thats only for eclipse. Im sure there are a bunch of clients out there, just google it.
Other than that, Git Bash is fine. It works, why change it? Using another client won't give you any benefits other than better UI's.
I work mainly on a desktop Mac but also have a laptop Mac that I use when away from the office.
I want to access and work on my latest html, css, php and python files from either computer.
I thought Github was the way to do this but am having a problem understanding the "flow" and I've RTFM! I don't understand whether I should create a Repository on Github first, why when I try to "clone" something it doesn't magically end up on my local computer... where the nice big red button that says "sync" is...
... or whether I should just use the commandline ONLY...
So, if I start on my desktop and create new files, what are the correct steps using git or Github (?) to put those files where they can then be accessed from my laptop and then have the files on my laptop merged back into the ?Github repository so I can then access those files from my desktop.
Thank you all for your replies and answers! The git workflow, for my needs, is now clear.
The workflow presented by wadesworld is concise and was the overview I needed.
However, Michael Durrant's commandline steps filled in that workflow specifically with commandline directives - and I needed that also.
steelclaw and uDaY's answers and responses were important because I did not understand that it did not matter which repo I created first and, adding and committing locally were essential first steps in my workflow.
Specifically, steelclaw's response to one of my response questions provided the closure I needed, so I could learn more:
After initializing the repository, be sure to use 'add' and 'commit.' These will make the files an official version of the repository. After that, you need to use 'push' to upload it to the remote repository."
ilollar's resource, "Git for Ages 4 and Up" is also worthy of the click, especially for folks like me who are visual!
Thank you all so very much!!
Do you want to version control your files or just have access to the same files in both places?
It is a good idea to use version control as a developer, whether you're writing code or designing websites. But, to do so, you have to have a commitment to learning how version control systems work, since they all have some learning curve.
But, if you're not interested in that complexity and simply want to be sure you have access to the latest version of your files, then you're looking at a file syncing operation which can be much more simple.
So, which one do you want?
Edit: Based on the response, here's the model:
1) Create repository on work computer.
2) Create repository with same name on github.
3) Push to repository on github
4) At home, do a git clone to pull down the changes you pushed.
5) Now that the repository exists in both locations, you can simply do a git push before you leave work, and git pull when you get home, and vice-versa when going the other direction.
To answer the detail of your question: I'd go with Dropbox.
UbuntuOne is also good even for non Ubuntu users and of course Google drive is the (big) new player on the block.
They compare as follows:
Service Free*1 NextLevel*1 NextLevel($)*2 Features
Dropbox 2 50 $2.5O One Folder, best gui sync tools.
UbuntuOne 5 20 $4.00 Multiple directories anywhere
GDrive 5 25 $2.50 It's Google.
*1 GB
*2 Cost per month
To answer the title of your question:
If you wanted something that's more suited to programmers, I'd use git:
First, install gitx (linux readers, that's gitg) as that is by far the most popular gui for git:
For the "flow" I can also refer you to my write-up of various features at:
What are the core concepts of git, github, fork & branch. How does git compare to SVN?
Using gitx or gitg the specific flow is as follow:
1) Make some changes to files.
2) Use the tools "commit" tab to see what's changed ("unstaged"):
3) Add a file by dragging it from "unstaged" to "staged":
4) Give a commit message
5) Commit the file.
6) I then push it to the remote at the command line with $ git push remote or I use the gui by right clicking and select ing the 2nd master - see here:
.
If I'm sharing with others I'll often need to do git pull to get ands merge in others chnages) before being able to do a git push
The github part is doing init and push and clone but I'd say just read up on those tutorials more rather than an SO question. Basically though, I do:
Set up repository locally in git:
git init
git add .
git commit "Initial commit"
Set up github:
Create a github repository using github (https://help.github.com/articles/create-a-repo)and then push your local repository to it as in:
git push origin master.
If the repository already exists on github but not on your local pc, that's wheh you click the remote link and then in a terminal type git clone [paste here, e.g. ctrl-v]
If you're "starting" with github:
Make code changes
git pull - get latest version into your repository and merge in any changes
git add . Add all modified files
git commit -m "message"
git push # origin master is the default.
If, at the end of the day you decide to go with something simple like Dropbox you can use my referral link -http://db.tt/pZrz4t3k- to get a little more than the standard 2GB, Using this we both get an extra 0.5 GB, however which of all these routes to go is up to you and your needs. I use all these services (git, github, UbuntuOne, Dropbox and googleDrive, so I am not recommending one over the others -it depends on the needs).
I would recommend using DropBox or Google Drive. They will let you do EXACTLY what you are trying to achieve, they are very user friendly (and free [5 Gb I think]).
They automatically update (as long as you have an internet connection obviously)
Just make a folder, put some files in it, and you are away.
Since explaining how to use an entire VCS in one answer is an overwhelming task, I can instead point you in the direction of some very helpful resources to get you to understanding and using Git:
Pro Git - a free online book (written with Git!) with easy language on all things Git.
GitHub Help - GitHub's own help section walks you through setting up and using Git, and not just with their own apps. Very useful.
Get Started with Git - A good tutorial getting you up and running with Git.
Git For Ages 4 and Up - Fantastic video explaining the inner-workings of Git with Tinker Toys. Not best for an introduction into Git, but a great video to watch once you feel a bit more comfortable.
Git may feel complicated or strange at first, but if what you are looking for is a good version control system, it is excellent.
However, if all you're looking for is a cloud-like service to sync some files across multiple computers, like the others have mentioned, Dropbox would be the way to go.
I use Github as a "hub" of git, to share finished codes. (And Git for version control)
And Dropbox to sync files between different computers and mobile/tablet, to manage files.
http://db.tt/EuXOgGQ
They serve different purposes for me. Both are good!
Git is an advanced and rather difficult tool to use for version control. If you're feeling brave, you can try to install the command line tool, however I recommend using a graphical client, specifically SourceTree.
http://www.atlassian.com/software/sourcetree/overview
You'll need to clone your repository, or else initialize a new one. To connect to your repository, you'll need to know the URL, and possibly a username and password for your repository. You also need to provide a valid name for the repository.
To update files there are several steps: First, you need to add the changes to the directory. Source tree might do this automatically. Then you need to commit the changes. This is basically confirming changes and signing them with a comment. To upload them, you need to use push and select the correct remote repository. When you want to update your local repository, you'll need to use pull and again select the correct remote repository.
For your purposes, however, it seems like dropbox might be better, because it automatically updates and is very simple. If you don't need the advanced version control that git provides (e.g. branching, merging from many users), then it seems like it would be a better option for you.
https://www.dropbox.com/
I have a class, which is part of a code library project that was written for a particular purpose that is no longer required. So the question is what do you do with code like this? Do you simply delete it, or do you leave it in bearing in mind that future developers may come across it and not realise that they can disregard it or do you have some sort of archive system, is there a recognised "pattern" that is in use...
Delete it. You can always get it back from the version control system later. You do have version control, don't you?
As Neil said, delete it. If I'm hired to maintain your project years after you are done with it and it's still full of dead code.. I'm gonna haunt you. And not the ooooohhhhh nice kinda haunting.. but the ARRRRWWWGGGGGRRRR!!!!! annoying kind of haunting.
It depends.
If it is unused because it is obsolete, I would clean it from the current code base by deleting it. If it turns out that it is in fact needed, you can always retrieve it from source control.
If it is unused at the moment, but may be used in the near future, I would keep it in the current code base as I wouldn't expect fellow developers to browse the source control for features just in case. In other words: if you delete something that has a high chance of being used, chances are that someone will re-implement it.
If it is not used anywhere, and no longer required you should delete it to avoid confusion.
You didn't say what code you are using but in C#/VisualStudio you can use the Obsolete attribute to tell other developers not to use the code, you can set the errors argument to true, and this will break the build anywhere that the code is being used.
I would start off by tagging the out-dated code elements with the Obsolete attribute. That way you will be able to locate any code that refers to the out-dated elements, giving you a way to update those parts. When you no longer get any compiler warnings that you use obsoleted code, go ahead and delete it.
Update: OK, now I was thinking .NET and C#, but I am sure many other languages have similar features...
I try to keep my application code as little as possible. Library code should be compatible for a number of release then remove it or just mark it as deprecated.
I totally agree with Neil. Use SVN or any other version control system to keep track of your code and delete anything that is redundant. Too much commented code only makes your code hard to read, and in some cases debugging impossible.
The best option is to remove the code so you have a cleaner repository. Most of the time it is just a short term fealing you delete somehting of potential enormous value.
Counting on svn if fellow programmer need it later won't really work. Because you have to know the code existed before and then some has to scan through the svn.
If I really think I want to keep that code than I usually make an archive out of the files and add them with a description into our wiki and then I delete the code. Over the search of the wiki someone can find the code. Scan it using the archive and as the decription contains repository and revision number they can even ressurect the parts they need easily.
If it's much, reusable and/or code difficult to reproduce, I usually put it into a file called <projectname>_rubbish.<ext>. Not very elegant but I can easily ignore it and also look for it seamlessly when I do need it again.
Install GIT then:
cd <code repo>
git init .
git add .
git commit -m 'inital import for my old code'
... Refactor the code ...
git add <path/to/file/with/changes/>
git commit -m 'that feels much better... :)'
... Create an account on GitHub or setup a GitServer
git remote add origin <remote git repo>
git push origin master
And you're done... :)
Simply delete it. If it is no longer required, there is no point in keeping it.