I wonder what the difference is between
bzr checkout ./MyProject MyProject.dev
# later followed by a
cd MyProject.dev
bzr pull ../MyProject
and
bzr get ./MyProject MyProject.dev
# later followed by
cd MyProject.dev
bzr pull
As far I can tell the only difference is:
bzr get sets the pull location.
bzr checkout doesn't set the pull
location, so it must be specified
the first time you pull.
Are there other differences?
In the case of bzr checkout you should not use bzr pull, but should use bzr update instead.
bzr get is alias of bzr branch which is roughly equivalent of git clone.
bzr get creates a branch, whereas bzr checkout creates a checkout. With a checkout, any revisions you commit to MyProject.dev will also be committed to MyProject.
For more detail, see the checkout tutorial.
This is one of the way cool features of Bazaar that doesn't get enough press: the ability for people to work the way that makes them comfortable, even on the same shared repository.
Have some git or other DVCS devotees? Fine. Have them use bzr branch.
Have some old-school svn guys who just can't wrap their heads around all the branching and merging? "Wait...I have to create a branch, do commits, then merge my branch, then push my branch? How stupid, I just want to commit!" Fine. Have them work with bzr checkout.
This type of flexibility is what draws me to Bazaar, despite the fact that git is wildly more popular and faster.
Basically you have the option of not being tied to the branch you got the code from: if you want a standalone copy use bzr get, if you want to be automatically bound to the original branch: use bzr checkout.
If you change your mind later and want it to behave more like SVN, you can do a bzr bind and any commits you make will automatically be committed to the parent branch.
Related
I've already deleted a local branch without deleting its upstream branch on a GitHub.
Is there a way to delete the remote branch in a GitAhead?
In Sourcetree you just right click on the remote branch and choose delete.
Unfortunately no, GitAhead doesn't have an easy way to push a delete except for the little convenience checkmark when you delete the local branch. You would have to resort to the command line or doing it on your remote host.
This is a major design flaw in Git (in my opinion). The branching concept in mercurial is much more sane (no detached heads, named branches, no ability to delete branches - at least not if it was published once).
think about it: it is a versioning control system. What you want is to preserve and document development history. Someone has created and published a branch for purpose. So even if git allows manipulation of the repository much more than mercurial (and here most abilities are disabled by default!), just do not use it. leave the branch! Its OK. Its the way it should be. Anyway, as git is lean here, its just a pointer (not a real named branch like in hg), it does not take much space.
I tried svn2git to test a migration from svn to git, like this:
svn2git https://my-svn.net/project/ --username $USERNAME
I execute this command where git is installed. I perform this in /home/myuser/svn2git/. After some waiting the execution of the commands end:
...
A src/xx
A src/xx
A src/xx
A src/xx
I do not see the repository getting downloaded to the location where i am running this command from. After the command runs fine, If i commit and push to GIT i do not see anything getting committed. I see .git folder getting created and on the display with verbose i can see all my history.
Can anyone tell me what is incorrect here?
For a one-time migration git-svn is not the right tool for conversions of repositories or parts of a repository. It is a great tool if you want to use Git as frontend for an existing SVN server, but for one-time conversions you should not use git-svn, but svn2git which is much more suited for this use-case.
There are plenty tools called svn2git, the probably best one is the KDE one from https://github.com/svn-all-fast-export/svn2git. I strongly recommend using that svn2git tool. It is the best I know available out there and it is very flexible in what you can do with its rules files.
The svn2git tool you used (the nirvdrum one) is based on git-svn and just tries to work around some of the quirks and drawbacks. In thus that svn2git tool suffers from most of the same drawbacks.
You will be easily able to configure svn2gits rule file to produce the result you want from your current SVN layout, including any complex histories that might exist and including producing several Git repos out of one SVN repo or combining different SVN repos into one Git repo cleanly in one run if you like and also excluding any paths or branches or tags you don't to have migrated, though I'm always crying a little if someone discards code history which is precious.
If you are not 100% about the history of your repository, svneverever from http://blog.hartwork.org/?p=763 is a great tool to investigate the history of an SVN repository when migrating it to Git.
Even though git-svn or the nirvdrum svn2git is easier to start with, here are some further reasons why using the KDE svn2git instead of git-svn is superior, besides its flexibility:
the history is rebuilt much better and cleaner by svn2git (if the correct one is used), this is especially the case for more complex histories with branches and merges and so on
the tags are real tags and not branches in Git
you can generate annotated tags instead of lightweight tags
with git-svn the tags contain an extra empty commit which also makes them not part of the branches, so a normal fetch will not get them until you give --tags to the command as by default only tags pointing to fetched branches are fetched also. With the proper svn2git tags are where they belong
if you changed layout in SVN you can easily configure this with svn2git, with git-svn you will loose history eventually
with svn2git you can also split one SVN repository into multiple Git repositories easily
or combine multiple SVN repositories in the same SVN root into one Git repository easily
the conversion is a gazillion times faster with the correct svn2git than with git-svn
You see, there are many reasons why git-svn is worse and the KDE svn2git is superior. :-)
I've used Git on and off, but we're making an effort to commit to it, so I'm needing some guidance.
I'm using JointsWP as my base for our WordPress themes. What I want to do is to clone a copy JointsWP, so I can pull updates from them, but not to push my own changes back to them. That I have no problem with, where I'm running into issues, is when I want to backup each theme we create as a separate repo on Github, to have a backup, and so we can share them as needed. When I clone the original JointsWP repo, I can't seem to figure out how to push change to my own new repo. I thought that a fork would be my answer, but I'm only allowed one fork of the original repo, and pulling updates to a fork makes it feel like that's not what they intended. I considered making a fork and branching off of my fork of the repo for each theme we're creating, but that's not really what branching is meant for.
I'm totally open to suggestions, I'd love to get my workflow right, and it's totally possible I'm thinking about this the wrong way. In summary, all I want is to make multiple WordPress themes, based on the JointsWP boilerplate theme, and be able to update those themes as the original JointsWP theme is updated.
Thanks!
I don't think that a whole new repo is what you're looking for.
I believe that a separate branch would be a simple solution to your problem.
create a new branch using
git checkout -b new_theme
And then you can have many branches in the same project. Then you can easily checkout each branch as needed using
git checkout new_theme or git checkout old_theme
Here, have a look Git basic branching
At https://github.com/yourusername/yourreponame/graphs you can find some nice graphs showing commits over time. However the information is only for the master branch.
How do I see the same information for a branch other than master, or see a graphs taking account commits across all branches?
If this is not possible, how can I at least see how many line of code have been committed under a particular branch via the GitHub web GUI?
Is any of this possible?
I just stumble on this as well. You can actually see the graphs for other branches than the Master branch.
On Github in your repo - choose settings.
In settings - change your default branch to whatever branch you would like to see the graphs for.
The help of Github: Viewing contributions :
Whenever you commit to a project's default branch (or the gh-pages branch), open an issue, or propose a Pull Request, we count that as a contribution.
So:
default branch
gh-pages branch
open an issue
pull request
only these will be counted.
As #Mikael 's answer, you can change the default branch in repo's settings.
Another help of Github: Which contributions are counted?
For commit:
Your commit contributions are only counted when they are created on or merged into the default branch or gh-pages branch of a non-fork repository.
I also want github to count all the commits, not specified branch :(
From what I can see, those graphs are for master only: I only committed on the branch gitlist recently, and my commit activity only shows those for master.
Unless you rebase your branch on top of a new repo you would create specifically for that kind of inspection, said branch activity won't be visible until it is merged back in master.
After reading the builtin help, it seems to me that both commads can be used for modifying the workspace to match a certain revision. But I don't understand the differences between update and checkout. Please include some trivial workflows in your answer which show when update/checkout are appropriate.
First major difference is that if you have a remote url set, update will pull first latest artifacts from the remote repository.
Another difference is that if you have uncomitted changes, checkout will not run (unless you force it), whereas update will retain your changes and reapply them. With update you can therefore integrate changes from other users before committing.
So:
Update is what you need when you collaborate on a project, in order to prevent forks.
Checkout lets you deploy a particular version.