Related
There's this difficult rebase that keeps stumbling on conflicts every other commit. In order to be able to resolve some confusing conflicts, I must sometimes --abort and check out the master branch to see what exactly is there (unconfounded by conflict markup, stuff rebased so far, or git's "ours" vs. "theirs" hell). Whenever I do this, I must subsequently re-resolve all conflicts up to that point. This makes the rebase effectively O(n^2).
Is there a better way?
(Note: it absolutely must be a rebase, this requirement is a given. Merging is out of the question).
First, the new (Git 2.30) new merge strategy: ORT ("Ostensibly Recursive's Twin") will be slightly faster.
But the all process would still be not O(n).
Second, do use the git worktree command in order to checkout master in a separate folder (without making a separate clone).
That way, you don't have to abort the merge in progress, and can compare with a copy of your working tree, on master branch.
So I started using github today.
Basically, there are two of us (programmers) who will work on a single project with a PIC microcontroller. I have experimented a bit and read a couple of stuff and terms such as branches, commit, master, etc..
So let's say I just have one main.c file containing 4 lines.
This one is our master file. There are two of us developing at the same time. Now we make two branches out of this master (so basically a snapshot of this current code). The two branches are "branch1" and "branch2", with me making changes using branch1 and my partner using branch2.
I inserted a line "dummy = 0" between line2 and line3 while my partner insert "dummy = 0" between line3 and line4. So at the end of the day, I will commit my changes to branch1, pull a request to merge my changes to master.
Now, how does my partner do to make his changes to the new master file (after I committed mine)? Note that we started off from the same master file.
Thanks
What we did so far: We haven't tried making edits at the same time yet. What we did for now was that I asked him to make edits on branch2, then try to pull a request so that I can approve it so that his edits from branch 2 carries out to the master. My problem lies in the fact that we would most likely start from the same master code each day and so every change being made each hour would not carry on to the other one's copy
Git is a versioning system working on incremental differences.
In your scenario, you have 3 branches: master, branch1, branch2. You are both working on the same file in the two dev branches (not master).
Once you pushed your edits with a commit on branch1, your partner won't see anything in branch2: they are divergent paths.
What your partner has to do, is to merge your latest commit into branch2. In this way, the two divergent paths have met, and became one again. If you'll continue on branch1, rinse and repeat the process.
Since you stated that you both added lines in the same file, expect conflicts: "merging" means start from the file as it was back then (at the beginning of branch2), then replay all edits that were done in each commit, in that order. When you'll have to put together the edits of both branches, probably this will conflict. Say for instance that you added dummy = 0 on line 4. Your partner did it as well, but wrote dummy = 1 on line 4. Git doesn't decide for you, you'll have to resolve the conflict and decide which one to keep.
Note that I haven't mentioned master. I'll refer you to gitflow for that, is a little bit too broad of an argument for a single question.
I have created a view under X branch. checked in the files successfully. But while merging the files I gave incorrect command and my files were merged into Y branch which is obsolete. How is it possible? It means I can merge files even to an Obsolete branch? Kindly clarify.
If only the branch type is locked obsolete, that wouldn't prevent the branch (instance of a branch type) to be modified.
You can check the lock status with:
cleartool lslock <branch_name>#/vobs/avob
Or, for the brtype:
cleartool lslock brtype:<branch_name>#/vobs/avob
As Ian W points out in the comments:
If you are using UCM, there's a lock on the project and a locks on the streams. Pretty sure it's the lock on stream you want to have in place.
True: a lock on the UCM stream would lock the associated non-UCM branch.
Quick question on Mercurial. Suppose my colleague and I both have an up to date copy of trunk. We both make changes, then we both push/pull the changes from each other.
I am guessing Mercurial keeps the changes in order based on the date of the commit (since there is no incrementing revision, just a GUID). So what happens if my computer's date is one day behind and I commit half a day after my colleague. Would my change show up half a day before my colleague's?
#Martijn has your correct answer, but it doesn't seem to be clicking. If this makes anything clear pick his:
The commit times on Mercurial changesets have absolutely nothing to do with how they're merged, interleaved, or combined
Mercurial, and other DVCs, do all history tracking based entirely on the DAG (Directed Acyclic Graph), which means:
the only piece of metadata that matters is the parent or parents of a changeset
Before you commit you can see what the parent of your changeset is going to be by typing hg parents and once you commit you can see it in the hg log.
In your examples if you've pulled your colleague's changesets and updated your working directory to reflect them (hg pull ; hg update) then his or her changeset will be the parent of your changeset. If you haven't pulled/updated to reflect his or her changeset then both of your changesets will have the same parent -- they'll be siblings -- when when they're merged neither will take precedence over the other in any way.
The ordering when you do a hg log is determined by the order in which the changeset arrived in your local repository, and can differ from repo to repo depending on where they've pulled from first -- that's why you can't use the integer numbers shown next to changesets for cross-repo operations -- only the hash is global.
In short the date is never consulted in normal operations and is purely metadata with no more relevance than the author or commit description.
Indeed, your changesets are timestamped (internally stored as seconds-since-the-UNIX-epoch and a timezone offset), and when displaying changeset, they are ordered by timestamp and your changesets will be displayed in the incorrect place as their timestamps are be incorrect. See https://www.mercurial-scm.org/wiki/ChangeSet
This is not really that much of a problem though; timestamps have no bearing on how your changes are merged with those of your colleague. Only the changeset IDs matter here and when merging a common ancestor is used. It'll follow the graph of your changesets down looking for a changeset ID that your colleague also has and then merges your and his changes from the on forward. See https://www.mercurial-scm.org/wiki/Merge
So, merges are not affected, only the display of changesets, where your changesets will be sorted into the wrong location. It'll confuse you and your colleague, but your changes themselves are safe.
The order of changesets is not affected by the timestamp in the changesets. The order is determined solely by the order in which the changesets were created in your local repository.
Mercurial has an append-only architecture so when you pull from another repository, the changesets you pull in are placed after your own changesets, regardless of the timestamps in the new changesets.
The revision numbers (the local integer counter) is just a counter: each new changeset gets the next available revision number. The simple range operator in Mercurial works directly on revisions numbers, and so X:Y means "give me changesets with revision numbers from X to Y (inclusive)". This is not so useful when the revision numbers are based only on the order in which changesets were created or pulled into a repository.
Use X::Y instead, that gives you changesets that are descendants of X and ancestors of Y, i.e., it follows the branches in the history.
This question is rather agnostic than related to a certain version control program.
Assume there is a source code tree under certain distributed version control. Let's call it A.
At some point somebody else clones it and gets its own copy. Let's call it B.
I'll call A and B branches, even if some version control tools have different definitions for branches (some might call A and B repositories).
Let's assume that branch A is the "main" branch. In the context of distributed version control this only means that branch A is modified much more actively and the owner of branch B periodically syncs (pulls) new updates from branch A.
Let's consider that a certain source file in branch B contains a class (again, it's also language agnostic). The owner of branch B considers that some class methods are more appropriate and groups them together by moving them inside the class body. Functionally nothing has changed - this is a very trivial refactoring of the code. But the change gets reflected in diffs. Now, assuming that this change from branch B will never get merged into branch A, the owner of branch B will always get this difference when pulling from branch A and merging into his own workspace. Even if there's only one such trivial change, the owner of branch B needs to resolve conflicts every time when pulling from branch A. As long as branches A and B are modified independently, more and more conflicts like this appear. What is the workaround for this situation? Which workflow should the owner of branch B follow to minimize the effort for periodically syncing with branch A?
The owner of branch B should have discussed the change with the owner of branch A. They should have decided that either the change was worth making, in which case it should have been committed to the trunk (A) or it wasn't, in which case it should have never been made. VCS is not a substitute for communication between developers.
Dev B should ask Dev A to pull from him.
The situation is not avoidable if two branches diverge and never converge. Its similar to a fork in a project - Its very difficult to merge two different forks.
Dev B should either un-refactor, or else add some meaningful functionality that has enough momentum to warrant merging back into A. Otherwise tell him "Them's the breaks".
To go to an extreme example, he could decide that he doesn't like C and decide to re-write everything as Pascal, line by line, using the same variable names, class names, etc.. To the point that the only difference is the language. So what would you tell him then, when he insists that there aren't any changes, so there should be no diff?
One workaround is to have a fancy diff wrapper around code comparison that will intelligently ignore certain very specific diffs.
On a simple level it's usually implemented via gdiff, on fancier, with custom diff code.
However, I must say that such a situation is really a bad thing and it's much better to merge the changes back into A; by for example submitting a patch to A's maintainers owners