Re: Please undo "Use git-merge instead of git-resolve in
- From
Linus Torvalds <torvalds@osdl.org>
- Date
- Sep 22, 2005, 21:22 UTC
- Message-ID
- <Pine.LNX.4.58.0509221413400.2553@g5.osdl.org>
- In-Reply-To
- <E1EIWUv-0004HR-F6@jdl.com>
On Thu, 22 Sep 2005, Jon Loeliger wrote:
Show 17 quoted lines
> > > For example, you can do that with > > > > git fetch linus master:linus > > > > which says: "fetch the branch 'master' from the repository described by > > 'linus' (.git/remotes/linus) into _my_ branch 'linus'". > > Just to be clear on the overloaded use of "linus" here, > let me rewrite that: > > git fetch foo master:bar > > which says: "fetch the branch 'master' from the repository described > by 'foo' (.git/remotes/foo) into _my_ branch 'bar'". > > Right?
Right.
Show 15 quoted lines
> OK. I think I get it. The concept you are trying to beat into > my head is essentially the difference between a "complete" and > an "incomplete" specifier. If there is enough specification to > fetch and merge into a branch, you can. And there are a few > different ways to do so: > > A) git fetch rsync:..../linus-2.6.git master:origin > or > B) git fetch linus master:linus > with just the URL bits in the .git/remotes > or > C) git fetch linus > with both URL and "Pull:" clauses in .git remotes > URL: rsync:..../linus2.6.git > Pull: master:linus
Absolutely.
Note that you can also override, so let's say that you have _both_ the "URL:" and the "Pull:" line in your "remotes" file, the "pull" line is still just a default, so you could do
git fetch linus other:myother
and it would now use the URL line, but since you specified the branch by hand, it would ignore the default branch information, and instead fetch the "other" branch from the remote site into the "myother" local branch.
Show 8 quoted lines
> > Now, this is where "dirty" comes in. The merge will fail if you have > > changed any files that the merge wants to modify. So do a > > D'oh. This is what bites me. Some of those diffs that > come back to me in the linus tree are one that I originated > and sent up stream in the first place. To get those to > wash-out with the merge, I will have had to have had those > committed in my branch, right?
Yes. Then git will merge them for you automatically (if they are identical), or may ask you to fix up any merge rejects (if there are clashes).
Now, the fixing up any merges is pretty much exactly the same as under CVS - you'll get the same "<<<<" "====" ">>>>" markers.
> Otherwise they just look > like dirty files -- never mind that they are (should be) > the exact same bits coming back at me.
Right, but git doesn't know, and is too lazy to check.
I _considered_ allowing a dirty file that happened to match the end result, but I never felt it was worth the complexity. It's nasty. And if it doesn't match, you really can't merge, because it's too dangerous to overwrite the users changes (even if you use some three-way merge and leave the rejects there).
Show 10 quoted lines
> I want to return to this for one last comment: > > > You can make your .git/remotes/linus file look like this instead: > > > > URL: rsync:..../linus2.6.git > > Pull: master:linus > > So, philosophically perhaps, there are several different > reasons for having branches within a repository. One of > them is to track external repositories as indicated above.
Yes.
> But no-one (ie, no tool) currently constructs the .git/remotes > files to have that layout, right?
The "git clone" thing will construct the original "origin" file to that layout. That's fairly recent, though.
And I think "cg-branch" will do it these days - and that's very much the intent. Havign porcelain on top of git that hides this thing so that you don't have to edit configuration files by hand.
(Don't get me wrong: I think it's wonderful to have ASCII configuration files that you _can_ edit by hand, and it's the UNIX way of doing things, but I also think it's great to have front-end tools that allow doing these things without even having to understand the config file syntax etc).
Linus