For the git-svn in master using the delta fetcher; there's no additional overhead to fetch properties. I want to ditch the old non-delta fetching code (it's only a mild performance benefit when using local repositories) if I could get do_switch() working correctly. -- Eric Wong -

No. The merging part actually is the easiest, because everything about what to merge with what is already decided in "git pull" 's fetch phase: * git fetch leaves the branches fetched _and_ what to merge of them in .git/FETCH_HEAD. Example for "git pull" it git.git's master(shorted): de51fa... branch 'master' of git://.../git/git 49ed2b... not-for-merge branch 'maint' of git://.../git/git b772ef... not-for-merge branch 'next' of git://.../git/git Which means: Already in the fetch phase,...

In other words, I am all for fixing this. Although it may not hurt too much if we just redefine the meaning of it to name the local tracking branch, using a different name "branch.*.defaultmerge" is safer and would not break existing repositories. -

Hmm... that's true; actually, I did not thought about people which do not want to have any tracking branches (again!). So [remote "repo"] url = ... fetch = branch1 fetch = branch2 [branch "mybranch1"] remote = repo merge = branch1 actually looks fine, and is the only possible way. But still, this does not work. You have to specify merge = refs/heads/branch1 That's confusing (perhaps I can come up with a patch to allow "branch1" alone). So probably the best way is to w...

Liu Yubao writes: > Yes, you are very right. > > $ git ls-files |tr A-Z a-z | sort | uniq -c |grep -v "1 " > 2 include/linux/netfilter/xt_connmark.h > 2 include/linux/netfilter/xt_dscp.h > 2 include/linux/netfilter/xt_mark.h > 2 include/linux/netfilter_ipv4/ipt_connmark.h > 2 include/linux/netfilter_ipv4/ipt_dscp.h > 2 include/linux/netfilter_ipv4/ipt_ecn.h > 2 include/linux/netfilter_ipv4/ipt_mark.h > 2 ...

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 -

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. -

So the library approach sounds like the best? Of course in this case the producer git-rev-list and the receiver use the same address space. In the case of a temporary file data is first copied to OS disk cache buffers and then again to userspace, in qgit address space. But the real pain is that the temporary file is always flushed to disk after 4-5 seconds from creation, also if under heavy read/write activity. This is a problem for big repos. I really don't know how to workaround this useless...

Hi, Could somebody remind me why different processes are needed? I thought that the revision machinery should be used directly, by linking to libgit.a... Ciao, Dscho -

Hi, Yes. The reset thingie is already in place: clear_commit_marks(). It would have to be enhanced a little, though: 1) the function rewrite_parents(), should add another flag, HALFORPHANED, and 2) clear_commit_marks() should unset the "parsed" flag of the commits for which HALFORPHANED is reset. -- snip -- diff --git a/commit.c b/commit.c index d5103cd..fd225c8 100644 --- a/commit.c +++ b/commit.c @@ -431,6 +431,10 @@ void clear_commit_marks(struct commit *commit, unsigned int ...

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 -

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 -

Thanks. Will queue for both maint and master. -

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...

Hi, I think there is something else wrong. If you have three merge bases, I do not see how you could get into that particular code path. Any possibility for me to have a private look at your repo? Ciao, Dscho -

Hi, can you send me at least the output of $ git-rev-list --parents branch1 branch2 preferrably packed? There is nothing you can do legally wrong, since you are not sending any data, only metadata. Ciao, Dscho -

I have recently observed a rather large number of users who forget to specify the base revision when they start a new branch with git-checkout -b. Many of these users are shocked many hours and commits later when their prior branch is now also part of the new branch. Nasty words about Git usually follow the discovery. This introduces a new config option: checkout.requireSourceBranch, which the user can set to make git-checkout -b require them to supply not only the new branch name but also the in...

Are you suggesting that we change "git-checkout -b" to by default require the source branch, but the user can restore the original behavior by setting the above per-branch configuration option? I'm OK with that version too. Most of these users want to be required to enter the source branch, and their topic branches (which are always their current branches btw) are so transient they won't bother with a per-branch setting. So they get what they want: the tool reminding them to select their source...

That makes the default behavior more complicated to explain. Is there really sufficient evidence that this a serious problem? --b. -

Well, it's true that "git branch" is the first thing I type whenever I sit down, just to remember where I am.... But my main complaint is just that I wouldn't want to see the behavior of defaulting to HEAD--behavior which is simple, easy to explain, and shared by most other git commands--by something significantly more complicated. That's more a complaint about Junio's suggestion than yours, though. --b. -