I want to merge from master (current branch) to branch1.
To do this, using TortoiseGit, as far as I could search, I need to switch to branch1 and merge from master.
Is it possible to do it using TortoiseGit without switching branch?
Currently this isn't possible in TortoiseGit.
... merging always takes place within a working tree. If you want to merge changes into a branch, you have to have a working tree for that branch checked out, ...
from: https://tortoisegit.org/docs/tortoisegit/tgit-dug-merge.html
Related
I am trying to understand about branches and tags with TortoiseGit.
I have read a few good tutorials and have managed to create a branch and I can commit changes to that branch and push to BitBucket. And in the tutorial it shows me how to later merge to the master root.
But I don't quite understand the concept of tags. I know how to create tags. But it is getting it all to work.
What I had in my head was that I create a branch XYZ. But this branch is associated with tag 1.2.3 (a version). I thought that I could tie a set of commits (or the whole branch) to a version number. Then when it is merged later I still know what version those changes were for. Can't work it out.
I tried the "Include Tags" when pushing but that created the tag but seems to have applied it to the whole repository.
Am I going about this wrong?
Can someone please share a code snippet that shows how I can pick out commits on only ONE branch using the JGit API.
If I use RevWalk, I get the entire tree, including sub-branches that have been merged into the specified branch.
How can I get JUST the commits on the specified branch without picking up parent commits of branches that may have been merged into the specified branch?
What may also help is to find out what branch a certain commit is sitting on.
Adding some more info:
How can I get all commits along the develop branch?
So based on the image above, I need SHAs:
2a34
b468
785c
but NOT:
731a
cbdb
Thanks!
In order to traverse the history of a Git repository, starting at a certain branch, you can use the LogCommand as described here: JGit: How to get all commits of a branch? (Without changes to the working directory ...)
The command's addFilter() method can be used to install a RevFilter to exclude certain commits.
Is it possible to create branches in Perforce in a similar style to Git? I.e. without creating a new folder.
I would prefer for my client to manage the branches transparently whilst I work against a single copy of the directory tree on disk.
It seems awfully wasteful for the client to create an exact copy of the entire tree if you're only modifying say a couple of files. I much prefer Git's workflow in this regard.
If it's not possible using straight Perforce I'm happy to move to GitSwarm.
For info I'm running Perforce version 2015.1/1233444.
Possible yes, but with the centralized version of the system it involves a bit of 'magic'. Basically, the branch part doesn't need to involve the client at all anymore. Take a peek at p4 populate. That'll create another folder on the server, but won't do anything locally. Then you can edit your client workspace to map the branched files instead of the trunk files, and it'll just re-sync over top the files on your disk.
Now, having said that, if you wanted to take a look at our DVCS version of working, then you can just do "p4 switch -c " and it'll create a new branch locally, switch your workspace over to it (shelving any open current work in the process) and away you go.
My original answer was deleted because I thought a link was a better idea than repeating content. My mistake.
At any rate, I believe the DVCS features in Perforce Helix supply exactly the sort of thing you're after. In a blog I wrote in the subject (link here for reference) I explained how to create a new in-place branch with a single command:
p4 switch -c newBranchName
That will create a new branch with the name "newBranchName" and save any existing work in progress by default. To discover on which branch you're working you can use the switch command with the list argument as follows:
p4 switch -l
That would show you output like this, the asterisk showing that you're now working on the newBranchName branch.
newBranchName *
main
You can switch back and forth as you like, changing contexts as needed as often as you like. Your work in progress will continue to be saved on each branch in progress. When you're ready to merge your work back to main and push it back to the server, you can use the following sequence of commands:
p4 switch main
p4 merge --from newBranchName
p4 resolve –as
The first command switches back to the main branch, the second merges your work from the newly created branch into main, and the third resolves any potential conflicts automatically. If there are any conflicts that can't automatically be merged, then you can use the usual commands to walk through the resolution process.
Alternately, if you prefer to stick with Git, you can use that directly with our Helix Versioning Engine through our Git Fusion technology or use Git directly with our new GitSwarm technology. That is a pretty amazing option (in my opinion) as it makes it possible to mirror content automatically and bidirectionally between GitSwarm and the back end server. That way you get all the features of Git with GitSwarm (which itself is based on GitLab) and all the goodies from the rest of Helix.
Hope that helps!
If you use streams (Perforce's "managed" version of a branch, as opposed to doing completely ad hoc inter-file branching with arbitrary paths), it's pretty simple. As P4Gabe said, "switch -c" is a one-shot option on a local server.
On a shared server it's only a little more complicated because you have to do the "populate" explicitly (this is to keep naive users from accidentally branching lots of files lots of times on a shared server), but it's still only a few steps and it's something that you as an advanced user could script easily:
p4 stream -P (current stream) -t development (new stream name)
p4 populate -r -S (new stream name)
p4 switch (new stream name)
The equivalent is possible using ad hoc ("classic") branches as well if you have a good understanding of how client views work -- use populate to create the new branch, modify your client view to map the new branch into the namespace currently occupied by the old branch, and sync.
This blog post on what exactly "p4 switch" does might help if you're trying to engineer your own solution that's similar-to-but-not-quite the "switch" command: https://www.perforce.com/blog/150428/p4-switch-switching-it
Is it possible to create a branch of a bzr repository that selects omits certain changes? For example, let's say my repository is at revision 354, and I want to branch it, but I don't want to include the changes that were done in revision 247.
Note that I plan to merge in the changes from revision 247 at some point in the future. So I don't want to just make changes to the code that undo what revision 247 did, otherwise there will be a conflict later when I try to do the merge.
Is this type of selective branching possible with bzr?
I think you're looking to Reverse Cherrypick. This will let you remove a single revision from a branch.
no.
A revision always guarantees all of it's parent revisions.
I don't think you will have too many conflicts if you first undo and commit that revision and then later re-apply it.
If you are unsure branch into a temp directory and try it out.
Is theere a way of finding out what changes a bzr update will do without actually doing it.
Specifially I would like to have a bit of warning if there is going to be a conflict.
Not directly that I'm aware of, that's what bzr revert is for. However, there is a common way to structure your local branches to help. I use one local branch that mirrors the central branch, then I branch off of that for my work. When I'm ready to "check in," I update my local mirror branch, which always succeeds without conflicts because I haven't changed my working copy of that branch. Then I merge my feature branch into my local mirror branch, then push my local mirror branch to the central repository.
The advantage of this setup in your case is you could use bzr merge --preview or bzr diff to see the changes if you don't want to actually try the merge. I personally prefer just to revert the merge until the conflicts are fixed either upstream or in my local feature branch.