{"thread":{"id":"15326","subject":"Medium term dreams","startedAt":"2008-09-01T23:19:47Z","lastAt":"2008-09-04T05:33:09Z","messageCount":12,"participants":["Junio C Hamano","Jeff King","Petr Baudis","Johannes Sixt","Mike Hommey"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"89460","messageId":"7vsksjsbcc.fsf@gitster.siamese.dyndns.org","threadId":"15326","inReplyTo":null,"subject":"Medium term dreams","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-09-01T23:19:47Z","receivedAt":"2008-09-01T23:19:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Perhaps because it is also Linus's brainchild, git development has not\ngenerally advanced by intelligent design but by organic evolution.  We\nhave worked without setting any grand, long term visions, but primarily\nby gathering the fruits of individual developers' work to scratch their\nown itches.  While I do not see that as a problem at all, it sometimes\nmay help to write down some medium to long term wishes to review what we\nhaven't done (and we should) in a perspective.\n\nThis is such a wishlist, not a grand intelligent design in any way.\n\n1. Pathspecs\n\nThere is a longstanding inconsistency in pathspec limiting done by\nvarious families of commands.  We should unify them.\n\n * The pathspec limiter that originates from \"git diff-tree\" and shared\n   with \"git log\" is the most limited.  It only allows you to specify\n   leading paths and limits by leading substring match (anchored at\n   directory boundaries '/'); no globbing is supported.\n\n * The pathspec limiter used by \"git ls-files -- $path\" and shared by\n   \"git checkout [treeish] -- $path\" is more flexible.  In addition to\n   the leading directory match above, it does allow globbing.\n\n   This unfortunately has at least two different implementations.  The\n   one ls-files and checkout uses is in dir.c; grep uses a different\n   implementation that is more advanced and better suited for a caller\n   that can benefit from being able to skip a whole subdirectory.\n\n   The limiter used by for-each-ref is also of this kind; it has its own\n   implementation (I do not think it is worth using the same code with\n   other codepaths for this particular one, but I am mentioning it for\n   completeness).\n\nMy gut feeling is that we should build a superset of these three\nimplementations, starting from the one used in grep and adding the\nfeature it lacks from the dir.c one (namely, the ability to mark which\npathspec had actually matched anything, so that the caller can say \"you\ngave me this pathspec but it did not match any --- typo?\"), and make\nthe existing three pathspec limiter functions thin wrappers to it.\n\nThis will change semantics in that \"git diff HEAD '*.c'\" will now show\ndifferences to all C files, not just the path with three-letter\nfilename, asterisk-dot-C.  I do not think that deserves to be called\n\"breaking backward compatibility\"; it is 99% pure feature enhancement,\nthat hurts insane people who have filenames with shell metacharacters in\nthem.\n \n2. Submodules\n\nEventually, I'd like to remove gitk-git/ and git-gui/ directories, and use\nthe submodule mechanism to bind them at modules/{gitk,git-gui}.  So far we\nhave refrained from doing this, primarily because a repository that uses\nsubmodules cannot be cloned by very old versions (before 1.5.2) of git,\nand in principle, git.git's repository itself should be conservative\n(e.g. I did not use packed refs in public repositories where I can\nconfigure for a long time, since HTTP clients did not understand them).\n\nBecause this change (not the change to the software itself, but the\nrepository that houses the software, i.e. \"git.git\") would be conceptually\na big jump, the release that has these two directories as submodules might\nneed to be called 2.0.0.  Now a big release is over, and hopefully in a\nyear or so, everybody would be using at least 1.6.0.\n\nI've pushed a sample repository that future git.git might look like to:\n\n    http://repo.or.cz/w/git/split-submodule.git/\n\nWe may however need to polish the software side of submodule support so\nthat the development inside such a repository goes smoothly.  I think the\ncurrent submodule support is already good enough to get this started.\nNamely:\n\n * I do not think it is a problem at all that many operations such as\n   checkout/diff/fetch/push/bisect do not recurse into submodules, at\n   least for the purpose of binding gitk/git-gui to git.git.\n\n * I do think the current design of the submodule system is very well\n   suited for git.git's future use of submodules for gitk/git-gui. If\n   somebody builds with \"make NO_TCLTK\", he most likely won't even want\n   to \"git submodule init/update\" these two submodules.\n\n * I do not think switching branches across that magic commit, commits\n   before which have gitk as a subdirectory and commits after which have\n   gitk as a submodule, is a huge problem with the current software, even\n   though after switching from new to old there will be leftover, unused\n   modules/ directory.\n\nHowever, there still are some issues that the Porcelain level submodule\nsupport could address to make things better.  For example, if we do not\nmove gitk-git => modules/gitk as I outlined above, switching across the\nmagic commit would become an issue, especially switching from new to old\nwould either lose the submodule repository, or refuse to switch because\ndoing so would lose the submodule repository.\n\nWe should support the usage to replace an existing subdirectory (possibly\nbut not necessarily merged with subtree strategy) with a submodule.  To do\nthis sanely, one solution we may want to consider is to keep the real\nrepository for each submodule somewhere in the superproject's $GIT_DIR/,\nand use the \"gitfile\" to point at it from the submodule's working tree,\nand \"git submodule init\" should be updated to use such a layout by\ndefault.  Then checking out 1.6.0 when you have a clean checkout of 2.0.0\ntree will not have to lose the submodule repository (we can notice that\ngitk-gui is clean, remove the whole subdirectory and check out the copy\nfrom 1.6.0).\n\nI already know about some breakages around use of relative path in\n\"gitfile\" that needs to be addressed to implement above; there may be\nsome other issues around that code, but that level of detail is outside\nthe scope of this message.\n\nThere may be some other issues I haven't thought about (submodules area\nhas never been my bailiwick). and my feeling is that I most likely will\nnot the primary person who would be doing the polishing of submodule\nPorcelain.  But I think the release date of 2.0.0 will be at least one\nyear after we solve these issues, and when everybody is running such a\nversion.\n"},{"id":"89463","messageId":"20080902000037.GA11869@coredump.intra.peff.net","threadId":"15326","inReplyTo":"7vsksjsbcc.fsf@gitster.siamese.dyndns.org","subject":"pack count on repo.or.cz [was \"Medium term dreams\"]","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-09-02T00:00:37Z","receivedAt":"2008-09-02T00:00:37Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Sep 01, 2008 at 04:19:47PM -0700, Junio C Hamano wrote:\n\n> I've pushed a sample repository that future git.git might look like to:\n> \n>     http://repo.or.cz/w/git/split-submodule.git/\n\nHoly pack count, Batman! On a whim, I cloned this via http (by switching\n/w/ to /r/). It took 7m13s. Cloning by git://, for comparison, took\n1m31s. I pulled down 82 separate packs (and curiously, 277 separate .idx\nfiles).\n\nI know it is nice to keep the packs somewhat split for dumb transport\nusers (since they otherwise have to pull down the whole thing), but I\nthink it is coming here at the cost of first-time cloners (and yes,\nobviously I should have used --reference to an existing git clone; but\nfor many that will not be an option).\n\nIt looks like the gc.autopacklimit defaults to 50, which would have\nhelped this. Pasky, is repo.or.cz not gc-ing? Or gc-ing with different\nparameters? Or is this an artifact of the forking infrastructure (i.e.,\nthese packs are actually split across multiple modules)?\n\n-Peff\n"},{"id":"89466","messageId":"20080902010410.GI10360@machine.or.cz","threadId":"15326","inReplyTo":"20080902000037.GA11869@coredump.intra.peff.net","subject":"Re: pack count on repo.or.cz [was \"Medium term dreams\"]","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-09-02T01:04:10Z","receivedAt":"2008-09-02T01:04:10Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Mon, Sep 01, 2008 at 08:00:37PM -0400, Jeff King wrote:\n> It looks like the gc.autopacklimit defaults to 50, which would have\n> helped this. Pasky, is repo.or.cz not gc-ing? Or gc-ing with different\n> parameters? Or is this an artifact of the forking infrastructure (i.e.,\n> these packs are actually split across multiple modules)?\n\nUnfortunately, I'm not aware how to decreate the packs count with\ncurrent Git without losing _any_ objects. So yes, you could say that\nthis is an artifact of the forking infrastructure - we just can't afford\nto lose objects.\n\nI've been meaning to look into this for few... years now, but there is\nalways too many more important things to do. If anyone wants to help\nout, you're welcome to! :-)\n\nMaybe I should just give up on the whole alternates idea. Unless the\nreferenced object store is practically static, it just does not seem\nas a feasible thing to do with Git at all, and disk space is cheap.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nThe next generation of interesting software will be done\non the Macintosh, not the IBM PC.  -- Bill Gates\n"},{"id":"89467","messageId":"20080902011433.GA12682@coredump.intra.peff.net","threadId":"15326","inReplyTo":"20080902010410.GI10360@machine.or.cz","subject":"Re: pack count on repo.or.cz [was \"Medium term dreams\"]","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-09-02T01:14:33Z","receivedAt":"2008-09-02T01:14:33Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Sep 02, 2008 at 03:04:10AM +0200, Petr Baudis wrote:\n\n> Unfortunately, I'm not aware how to decreate the packs count with\n> current Git without losing _any_ objects. So yes, you could say that\n> this is an artifact of the forking infrastructure - we just can't afford\n> to lose objects.\n\nHmm, I thought that was the point of adding the \"-A\" flag to git-repack.\n\nThough an even simpler solution, since you control all of the repos, is\nto just temporarily add references from the \"parent\" of the fork to\nevery ref of every forked child. Then do the repack in the parent, which\nshould then contain all of the objects for all of the children, delete\nthe temporary references, and prune in the children (who should see most\nof their objects now in the parent).\n\nThe only downside I can think of is that anyone grabbing the parent's\npacks via dumb transport will grab a few unnecessary objects for the\nforks. But presumably they are not all that big, being forks (i.e.,\nthere will only be a few commits, and they will be delta'd anyway).\n\n-Peff\n"},{"id":"89471","messageId":"7vod37s4hz.fsf@gitster.siamese.dyndns.org","threadId":"15326","inReplyTo":"20080902011433.GA12682@coredump.intra.peff.net","subject":"Re: pack count on repo.or.cz","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-09-02T01:47:36Z","receivedAt":"2008-09-02T01:47:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> Though an even simpler solution, since you control all of the repos, is\n> to just temporarily add references from the \"parent\" of the fork to\n> every ref of every forked child. Then do the repack in the parent, which\n> should then contain all of the objects for all of the children, delete\n> the temporary references, and prune in the children (who should see most\n> of their objects now in the parent).\n\nHmm, I am slightly worried about doing so might defeat the whole point of\nmaking the sample repository a separate one from git.git hosted there.\n\nThe reason it is not a branch in git.git is because I did not want to\ncontaminate the official git.git repository with commit objects in tree\nobjects (aka gitlinks); it would deny access to clients older than 1.5.2.\n"},{"id":"89472","messageId":"20080902015637.GA14765@coredump.intra.peff.net","threadId":"15326","inReplyTo":"7vod37s4hz.fsf@gitster.siamese.dyndns.org","subject":"Re: pack count on repo.or.cz","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-09-02T01:56:37Z","receivedAt":"2008-09-02T01:56:37Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Sep 01, 2008 at 06:47:36PM -0700, Junio C Hamano wrote:\n\n> Hmm, I am slightly worried about doing so might defeat the whole point of\n> making the sample repository a separate one from git.git hosted there.\n> \n> The reason it is not a branch in git.git is because I did not want to\n> contaminate the official git.git repository with commit objects in tree\n> objects (aka gitlinks); it would deny access to clients older than 1.5.2.\n\nHrm. I had assumed they wouldn't be a problem because nothing actually\n_referenced_ them, but I suppose it would break git-fsck on such\nsystems.\n\nAnyway, I think \"git repack -A\" is a better solution (and presumably\nthere is some magic on the pruning end to make sure forks do the right\nthing with loose objects).\n\n-Peff\n"},{"id":"89498","messageId":"20080902111531.GL10360@machine.or.cz","threadId":"15326","inReplyTo":"20080902011433.GA12682@coredump.intra.peff.net","subject":"Re: pack count on repo.or.cz [was \"Medium term dreams\"]","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-09-02T11:15:31Z","receivedAt":"2008-09-02T11:15:31Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Mon, Sep 01, 2008 at 09:14:33PM -0400, Jeff King wrote:\n> On Tue, Sep 02, 2008 at 03:04:10AM +0200, Petr Baudis wrote:\n> \n> > Unfortunately, I'm not aware how to decreate the packs count with\n> > current Git without losing _any_ objects. So yes, you could say that\n> > this is an artifact of the forking infrastructure - we just can't afford\n> > to lose objects.\n> \n> Hmm, I thought that was the point of adding the \"-A\" flag to git-repack.\n\nOk, I did\n\n\tgit repack -A -d\n\nin repo.or.cz's git.git. What next? I have brand-new\n\n\t-rw-rw-r-- 1 root root  1314056 2008-09-02 13:07 pack-d19ca8b0cfd0e3357c475a3e96ce55b9f7195667.idx\n\t-rw-rw-r-- 1 root root 17344999 2008-09-02 13:07 pack-d19ca8b0cfd0e3357c475a3e96ce55b9f7195667.pack\n\nbut all the old packs too; git repack didn't delete anything,\ngit prune-packed seems to have no effect either.\n\n> Though an even simpler solution, since you control all of the repos, is\n> to just temporarily add references from the \"parent\" of the fork to\n> every ref of every forked child. Then do the repack in the parent, which\n> should then contain all of the objects for all of the children, delete\n> the temporary references, and prune in the children (who should see most\n> of their objects now in the parent).\n\nSo not just refs but also alternates? What if someone accesses the\nreposiory at that moment? I would also need to make the symlinks quite\ndensely to avoid refs/forkee/-induced loops.\n\nI might as well just use a common repository for all the forks then. But\nthis does not scale at all for dumb transports, does it?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nThe next generation of interesting software will be done\non the Macintosh, not the IBM PC.  -- Bill Gates\n"},{"id":"89499","messageId":"20080902115424.GA11303@coredump.intra.peff.net","threadId":"15326","inReplyTo":"20080902111531.GL10360@machine.or.cz","subject":"Re: pack count on repo.or.cz [was \"Medium term dreams\"]","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-09-02T11:54:24Z","receivedAt":"2008-09-02T11:54:24Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Sep 02, 2008 at 01:15:31PM +0200, Petr Baudis wrote:\n\n> > Hmm, I thought that was the point of adding the \"-A\" flag to git-repack.\n> \n> Ok, I did\n> \n> \tgit repack -A -d\n> \n> in repo.or.cz's git.git. What next? I have brand-new\n>\n> \t-rw-rw-r-- 1 root root  1314056 2008-09-02 13:07 pack-d19ca8b0cfd0e3357c475a3e96ce55b9f7195667.idx\n> \t-rw-rw-r-- 1 root root 17344999 2008-09-02 13:07 pack-d19ca8b0cfd0e3357c475a3e96ce55b9f7195667.pack\n> \n> but all the old packs too; git repack didn't delete anything,\n> git prune-packed seems to have no effect either.\n\nHmm. Certainly the new pack is as expected. And you may also have some\nnew loose objects. It's easier to see what's going on with:\n\n  mkdir repo && cd repo\n  git init\n  git config core.logallrefupdates false\n  echo content >file && git add file && git commit -m one\n  echo changes >>file && git commit -a -m two\n  git repack -a -d\n\nat this point we have the one pack:\n\n  $ find .git/objects -type f\n  .git/objects/pack/pack-ba174ac1cf22ba99a92878c562483321baa93d38.pack\n  .git/objects/pack/pack-ba174ac1cf22ba99a92878c562483321baa93d38.idx\n  .git/objects/info/packs\n\nand then we lose the reference and pack again:\n\n  git reset --hard HEAD^\n  git repack -A -d\n\nand now we have our single-commit pack, with a few loose objects from\nthe other commit:\n\n  $ find .git/objects -type f\n  .git/objects/13/cb02d81aac9cedca2700fb56aeddeb984dc57b\n  .git/objects/78/a66295f2d04f2dd4ea90b4b99a6de73ea4ac12\n  .git/objects/fe/79de90b5f7d6d4b23dc858f861834e2a76af7b\n  .git/objects/info/packs\n  .git/objects/pack/pack-c9a76fe2b061890a18396b70ec3d6a638383046e.idx\n  .git/objects/pack/pack-c9a76fe2b061890a18396b70ec3d6a638383046e.pack\n\nSo did you check for loose objects? That is what you should get if there\nwere any objects that would have been lost. If there aren't any new\nloose objects, then there were no objects that would be lost.\n\nAs to why the other packs weren't pruned, I don't know. In my example,\nyou can see that the pruning happens as we expect. So either there is a\nbug in git-prune-packed, or there is something we're not realizing.\n\n> So not just refs but also alternates? What if someone accesses the\n> reposiory at that moment? I would also need to make the symlinks quite\n> densely to avoid refs/forkee/-induced loops.\n\nI think you could probably do it safely with a symlink farm (and I sort\nof assumed you were doing something like that already for pruning, but\nperhaps you are just not pruning at all).\n\n> I might as well just use a common repository for all the forks then. But\n> this does not scale at all for dumb transports, does it?\n\nIt depends how different the forks are. :) But I think it is better if\nwe can avoid that.\n\n-Peff\n"},{"id":"89502","messageId":"20080902130801.GN10360@machine.or.cz","threadId":"15326","inReplyTo":"20080902115424.GA11303@coredump.intra.peff.net","subject":"Re: pack count on repo.or.cz [was \"Medium term dreams\"]","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-09-02T13:08:01Z","receivedAt":"2008-09-02T13:08:01Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Tue, Sep 02, 2008 at 07:54:24AM -0400, Jeff King wrote:\n> So did you check for loose objects? That is what you should get if there\n> were any objects that would have been lost. If there aren't any new\n> loose objects, then there were no objects that would be lost.\n\nBefore:\n\nrover:/srv/git/git.git# l objects~/??/* | wc -l\n3343\nrover:/srv/git/git.git# l objects~/pack/* | wc -l\n750\n\nAfter:\n\nrover:/srv/git/git.git# l objects/??/* | wc -l\n2920\nrover:/srv/git/git.git# l objects/pack/* | wc -l\n590\n\n> As to why the other packs weren't pruned, I don't know. In my example,\n> you can see that the pruning happens as we expect. So either there is a\n> bug in git-prune-packed, or there is something we're not realizing.\n\nWell, that's my question here. :-)\n\nIf you're still interested in looking into this further, you can wget -r\nor rsync over the git.git repository from repo.or.cz.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nThe next generation of interesting software will be done\non the Macintosh, not the IBM PC.  -- Bill Gates\n"},{"id":"89503","messageId":"48BD446C.6020403@viscovery.net","threadId":"15326","inReplyTo":"20080902130801.GN10360@machine.or.cz","subject":"Re: pack count on repo.or.cz [was \"Medium term dreams\"]","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2008-09-02T13:49:32Z","receivedAt":"2008-09-02T13:49:32Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Petr Baudis schrieb:\n>> As to why the other packs weren't pruned, I don't know. In my example,\n>> you can see that the pruning happens as we expect. So either there is a\n>> bug in git-prune-packed, or there is something we're not realizing.\n> \n> Well, that's my question here. :-)\n\nDoes removing all the *.keep files help? ;)\n\n-- Hannes\n"},{"id":"89614","messageId":"20080903100828.GS10360@machine.or.cz","threadId":"15326","inReplyTo":"48BD446C.6020403@viscovery.net","subject":"Re: pack count on repo.or.cz [was \"Medium term dreams\"]","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-09-03T10:08:28Z","receivedAt":"2008-09-03T10:08:28Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Tue, Sep 02, 2008 at 03:49:32PM +0200, Johannes Sixt wrote:\n> Petr Baudis schrieb:\n> >> As to why the other packs weren't pruned, I don't know. In my example,\n> >> you can see that the pruning happens as we expect. So either there is a\n> >> bug in git-prune-packed, or there is something we're not realizing.\n> > \n> > Well, that's my question here. :-)\n> \n> Does removing all the *.keep files help? ;)\n\nHaha, good catch - thanks! :-) I wonder where they came from, though I\nhazily remember some curious behaviour of older Git versions wrt. .keep\nfiles and they seem all to be of old date. Now I have a single nice pack\nand fsck of all the forks still passes fine.\n\nThanks all, I will adopt this for all projects.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nThe next generation of interesting software will be done\non the Macintosh, not the IBM PC.  -- Bill Gates\n"},{"id":"89728","messageId":"20080904053309.GA16412@glandium.org","threadId":"15326","inReplyTo":"7vsksjsbcc.fsf@gitster.siamese.dyndns.org","subject":"Re: Medium term dreams","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2008-09-04T05:33:09Z","receivedAt":"2008-09-04T05:33:09Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Mon, Sep 01, 2008 at 04:19:47PM -0700, Junio C Hamano wrote:\n> Perhaps because it is also Linus's brainchild, git development has not\n> generally advanced by intelligent design but by organic evolution.  We\n> have worked without setting any grand, long term visions, but primarily\n> by gathering the fruits of individual developers' work to scratch their\n> own itches.  While I do not see that as a problem at all, it sometimes\n> may help to write down some medium to long term wishes to review what we\n> haven't done (and we should) in a perspective.\n> \n> This is such a wishlist, not a grand intelligent design in any way.\n> \n> 1. Pathspecs\n> 2. Submodules\n\nI'd add these two:\n\n- Handle cvs/svn/whatever remotes as standard remotes.\n\nI don't see why these remotes should have a different workflow, and why\nthere couldn't be hooks to do whatever is required to pull/push from\nthese remotes when git pull/push'ing. This might not be easy to implement,\nbut I think it is a worthwhile goal.\n\n- Git-aware mergetool\n\nThere are various merge scenarios where using standard tools such as\nthose supported by current git-mergetool is not very helpful, and where\nsome basic git awareness might help the user resolve conflicts in more\nnatural ways.\n\nMike\n"}]}