There are some baseless merge cases where git-merge-recursive will try to compare one of the branches against the empty tree. However most projects won't have the empty tree object in their object database as Git does not normally create empty tree objects. If the empty tree object is missing then the merge process will die, as it cannot load the object from the database. The error message may make the user think that their database is corrupt when its actually not. So instead we should just cre...

A lot of times the reason to switch branches is because the user starts to make a trivial change in the worktree and realizes that the change belongs to another branch. Other times it is done by mistake and making it easier to notice that mistake is a laudable goal. Your patch allows -m to override this, but that destroys one very useful feature of -m. In the above "ah, this trivial thing belongs to the other branch, so let's switch to the branch to commit only that trivial piece and come back...

Wouldn't --force be more appropriate? -

I'm not sure about this. Often after you started to code something while on 'master' you realize that work is not trivial and needs its own branch and then "checkout -b" without having to say 'master' (or HEAD) is very handy. I think requring an explicit fork-point when you are _not_ on 'master' might be a better behaviour. In other words, you allow "checkout -b" (and "branch") to default to HEAD only while on the branches marked in your configuration file: Then: [branch] a...

Under my suggestion, the new git-checkout -b (and git-branch) would: (0) proceed if there is an explicit branch point specified on the command like, just like now; (1) allow omission of branch-point if the current branch has allowbranchbydefault configuration set as in above. A new branch is created forking off of the current HEAD; (2) allow omission of branch-point if no branch has such configuration; in other words, existing repositories that do not have the a...

I'm seeing bad branches all to often with some of the folks I have to work with. They apparently have been unable to learn the new trick of either remembering what branch they are currently on and what changes it has, or to always supply the branch they want to start from with their new branch. Consequently they are cussing at Git rather often, as "this damn Git crap always does the wrong with my files". Despite it being their own fault for not thinking before doing... Of course many of thes...

So I managed to create a fairly complex set of branches which are all merged back against each other at various points in time. Two of them have 3 merge bases according to git-merge-base. Tonight I tried to merge them together, but received the following wonderful error from git-merge-recursive: fatal: unable to read source tree (4b825dc642cb6eb9a060e54bf8d69288fbee4904) For those in the know, that's the empty tree. This particular repository does not have the empty tree anywhere in it, whic...

Arrgh. I can redo the merge and try to debug it myself; maybe I can at least get enough details about what's going on to create a No, unfortunately for me (I wish I could let you debug this!). Far too many legal issues are involved. There is possible jail time on my part for sharing any of the files in there... ;-) Although Junio mentioned he recently saw something like this in git.git when he merged in your xdl_merge() code. I wonder if its the same issue. -- Shawn. -

I hit the same issue when I integrated Johannes's in-core merge; I originally used hash_sha1_file() but that results in objects that are supposed to be in the virtual parent unreadable when merging the real children. The key is to use write_sha1_file() to actually create the needed objects, and trust later prune to remove them. Replace it with write_sha1_file() and you should be fine, I think. -

I've tolerated patches in attachments, but please do not do this: This is a multi-part message in MIME format. --------------010006030902030700040300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit --------------010006030902030700040300 Content-Type: text/plain; name="0001-Add-config-example-with-respect-to-branch.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="0001-Add-config-e...

hoi :) And it could be useful to automatically generate the summary for please-pull mails or for the [0/N] patch introduction mail. --=20 Martin Waitz

Your situation sounds similiar to mine, but I don't use regular git branches much. Rather I use stacked git instead. Stgit's patches can be though of as virtual branches. Instead of creating a dozen branches I have a dozen commits managed by stgit that I can choose from (and combine) easily, creating and destroying private "branches". -- robin -

Don't be too downhearted. I am certainly looking forward to using shallow clones; but by their very nature they are going to be used on big established projects (otherwise why would one need a shallow clone?), so until those projects upgrade their servers the news will be quiet Also; it's probably going to be casual developers that find shallow clones useful, as the main developers will clone the whole repository. This might also mean that they aren't going to be around on the git mailing l...

Hi, Sorry, I was just mumbling about the fact that I would _like_ to hear back about successes and failures. If there are problems I want to fix them. So, do you actually know of people who _used_ (as opposed to "tested") shallow clones? Ciao, Dscho -

I started that out at 5000 because it was a reasonably safe threshold. Users who didn't explicitly lower this value didn't enable the feature. But it was still useful on initial pushes into a brand new repository when the project was very large. For example pushing git.git into a bare repository *sucked* before this change. Yea, 5000 is probably too high. Nice to see it drop. -- Shawn. -

Why not just fork() + exec() and read from the filedescriptor? You can up the output buffer of the forked program to something suitable, which means the OS will cache it for you until you copy it to a buffer in qgit (i.e., read from the descriptor). -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 -

You wrote: --%<--%<--%<-- Because, depending on what you do, the revision machinery is not reentrable. For example, if you filter by filename, the history is rewritten in-memory to simulate a history where just that filename was tracked, and nothing else. These changes are not cleaned up after calling the internal revision machinery. --%<--%<--%<-- When I wrote the above suggestion, I hadn't read the posts following the email where I cut this text from (where Linus said "we ...

This part should have been in the commit message, possibly without the "among others ... (examples)" and possibly with an added "This patch makes it so by letting fnurg create them through smurfing the frotz". -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 -

Thanks for the comments! Patch, incremental against the previous one, I do like the idea of anything that gets rid of the ugly find|xargs chmod. Result included below (untested). Is that what you were I'm ignoring this for now. We can add it later if someone says they've run into it. (But honestly it's partly just laziness on my part--no objection if you want to make the patch.) It's too bad about that option-name conflict. It'd be nice just to be able to do the whole thing with one c...

Of course--for some reason I didn't think of doing init-db with --bare. Thanks again. --b. From 22e5bdd9de398f29dfb11125a0921bb4529e2ab7 Mon Sep 17 00:00:00 2001 From: J. Bruce Fields <bfields@citi.umich.edu> Date: Thu, 7 Dec 2006 22:32:28 -0500 Subject: [PATCH] Documentation: simpler shared repository creation Take Johannes Schindelin's suggestion for a further simplification of the shared repository creation using git --bare init-db --shared. Also fix a mistake from the previous p...

Oops, yes, thanks! --b. -

Hi, Yes. And I should back off from my strong language: I think this git-clone the most obvious program to set branch.master.merge. It should make life easier for new Git users. Ciao, Dscho -

We could setup the branch.*.remote option for every tracking branch git-clone is fetching (and git-fetch with the wildcard refspec). And git-branch sets branch.*.remote/merge for the new branch whenever it sees that a remote is set for the branch we are I see. But I hope with my suggestion above, this can be looked up then in the branch."remotes/origin/for-public".remote option. Josef -

This is most confusing part. What merge indicate is not about refs/heads/devel should track refs/remotes/origin/devel. That is specfied in the remote config option. What merge indicate is that when in a local branch ( not the tracking one under remotes/origin) I guess we need to have a standard way of saying the branches. May be we want to document it in repo-config. local branch on which changes can be made <branch-name> local tracking branch refs/remotes/<remote-name&...

I accepted the "branch.*.merge" patch long time ago but I did not see the point of moving things into config back then, so I did not look at the design issue deeply enough to notice that this can be a source of confusion (in other words, "I wouldn't use it myself, but I've seen some people on the list wanting to have it, and the submitter must have thought about what are needed a lot more than myself" did not go so well). Once you place something like "branch.*.merge" in configuration file (eith...