Is there any API in libgit2 which supports git's --cc (compact combined) option? - libgit2

Is there any API in libgit2 which supports git-diff-tree "--cc" option ?
I want to know if a merge is clean or not (without merge conflict). Comparing patches from git_patch_from_diff() between two parents can differ sometime even if there is no change seen from git log -p --cc --merges <commit>.
When showing merge conflicts, git show defaults to this “compact combined” option, which displays only conflicts. That’s why most merge commits are empty.

Related

Git: merge two working copies without committing

I have a clone for server development and another for client development. Both material will eventually make it into the same branch, but I want to synchronize them and I want it to perform a merge as though I had commit pushed and pulled, but I want to do it without that.
I'm able to make a patch with this script I wrote:
git diff --cached
git diff
on the server, but applying that to the client is much harder.
I've tried the Unix patch command, for some reason, it keeps asking me what files to patch, like I can't find them. (Yes, they're there) I've tried
git apply -3 patch.patch
but that gives a lot of errors like "with conflicts" (without making any changes) and "does not match index". It doesn't even seem to be trying to patch the other half of the files.
Stashing, then applying the patch, and then popping from the stash doesn't work, because unstashing refuses to do merges.
It looks like doing it without the pulling isn't going to work--I haven't found a way to do it conveniently and safely. However, my problem with committing is that I didn't want to spam the git log with garbage like:
Sync'ing to client
Sync'ing back to server
Oops! Sync'ing something I forgot to the server again!
etc.
But I can avoid all this by committing, then pulling from the remote repos. In the end, I wouldn't have to push those commits, since I would use reset to remove them all from the local repo and then, with all my changes in the working directory, do a proper commit and push it.
Gotachas
They are many.
It's commonly known that you shouldn't reset your local repo if something has already pulled from it. This is probably from the obvious confusion that results when one repo delete commits that another repo believes were there. For that reason it's important that the same reset is performed on both repos before they start sharing code again.
If after you've done your commits that you later want to reset, then pull/merge, you could make things very difficult for yourself. There should be a way to manage it, but I haven't yet figured it out. One idea is to reset, stash, pull, merge, and commit again. Another involves revert with the -n option.
Instructions
The following example assumes you have 2 clones; one called "client" and the other "server".
Following https://help.github.com/articles/adding-a-remote, setup your client's and server's repo on each others' systems to they can pull from each other.
When you want to sync, just commit on the donor system, then instead of pulling from the origin, pull from a remote. Say the client wanted a commit from the server. On the client:: git pull myserver-repo mybranch.
Merge and conflict-resolve as necessary.
Loop back to 2 as many times as is necessary.
After several iterations of 2-4, you arrive at the point when you are ready to push your changes to the server. Go to whichever local repo has all the changes you want pushed, then run git log. Find the commit before the first commit you did in 2. Copy its hash to the clipboard.
Then git reset: git reset <hash you copied in 5>.
You should then see all the commits you don't want disappear from the log and all the changes therein in your working directory. Commit and push.
It's important that you do a cleanup on the repo from which you didn't perform 5-7. So if you pushed from your server repo, you need to perform the same reset operation on your client, then dispense with the changes as you see fit. My preferred method is git stash save "delete_me".

Getting a sequence of diffs between revisions with mercurial

I want to see a sequence of diffs between consecutive (non-identical) revisions of the same file in a mercurial repository. I can obviously do that by parsing the result of hg log, extracting the changesets, then reading those two lines at a time and issuing hg diff -r $first_changset -r $second_changeset in a loop.
But - is there a more straightforward/elegant/graphical way of achieving the same?
Note: Not annotate though - at least not what it does by default. I want to be able to see all changes of the same changeset bunched together.
The quickest way to do this is with hg export, e.g.:
hg export -r reva:revb
This will actually give you an importable patch, but the extra meta information is often helpful.
The most general solution with the most configurable output is hg log with templates, e.g.:
hg log -r reva:revb -T '{diff()}\n'
The diff() template function takes optional arguments to specify include and exclude patterns. See hg help templates for details.
Note that this also works with -G and will draw a dependency graph alongside the diffs. Even when the graph is linear, this can help in finding the beginning and end of a diff. Obviously, you can also add further information to the template, such as revision number, hash, commit message, and author.
Normally, hg diff -c is intended for showing the diffs made by a revision, but unfortunately that does not work when you have multiple revisions.

Possible to branch in Perforce without creating a new folder?

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

bazaar pull special usage

I have local folder that is branch from formal_versions.
My workflow is:
Mkae changes and than commit them
The integrator merge them in his local branch.
The integrator push its local branch to formal_versions
I use pull to make my local branch identical to formal_versions
This is working fine.
However what should I do in the following scenario:
After pull from formal_versions , I compile the code. As a result , some workspace and obj file are changed (I.E date and time of compilation) and of cource , bazaar explorer inform me on modified files
I again want to make my branch mirror of formal version. What should I do?
A. Why using pull again says that "nothing to pull" even if
I use --overwrite switch ? it is suppose to make my local branch as mirror of the pulled branch...
B. Is my only option is to use revert working tree?
It is generally considered best practice (as well as good for one's sanity) not to version files that are the result of the build process. Executables, shared libraries, and even source files generated from by a 4GL are examples. You can ignore files by using bzr ignore <pattern>, for example bzr ignore *.exe. If the files are already versioned, you will also have to remove them using bzr remove.
bzr pull says there is nothing to pull because the formal version has had no new commits since your last pull.
If you must version the files in question, bzr revert is the only way I know of when bzr pull does not find new revisions. If there had been new revisions in the formal branch, the files should be updated (and will potentially be reported as conflicts).

Is there a way of finding out what a bazaar update would do

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.