Re: git-repack keeps running out of memory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/01/2015 04:58 PM, Jeff King wrote: > How many processors do you have? The window-memory is per-thread. > Try with --threads=1. Ahh, right... 8... that explains it ;) -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCgAGBQJVbPMBAAoJENRVrw2cjl5R2rkH/0qa9HerYM7Bw5qfcV3zahFz 5g/NGoW3M9IutqqLiyDzAQboj62+TzrEuM/fo7BgZrKYBsA7/4SNdJMmabaUb5Kr rtW1qfpErIHUQUY0wAxBwXX7gpihB3HTYRsZAX+7Itfae7bw8r3krj/L1Ty2nj3Y QLIm9uwijiBNpHoF9Jnl6gbklaVFbBBfdGH2uPLzoso5YdlJ0L6o4VDmeD55njjx 30cOLDwInQ4zxdGKBH1SaIXGq+2Vi1txLrzYaaEOA+NW9+Rp7J9Anqcv/IH5yyX/ y9H0yDXXP/3gPwTHvYiRTVWMjAvjxSdc4n4ZgySLBPTruW1utxjPdaTSffm2xsg= =wza7 -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Notes do not follow rebase
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 After doing a rebase -i to fix up some older commits, I noticed that notes I had associated with commits failed to follow the commit across the rebase, so the notes are now orphaned and will be pruned. Shouldn't notes be copied to the new commit during an ammend/rebase? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJVJXY7AAoJENRVrw2cjl5RUe8IAI0tGUeBUAef4xIIU/UfV5eQ VAdkUfYXCHnkjqukS/iBusyNM3PssabHmRFc+AdKGPPmbsv9JGKpj5G9hwf6Bdh+ RNDPMTlt/Ii90eu+v3uXwFHNUNf0b6kv7Tw63L0bFxGsFzu55DBm48LT/DJ9T05x Yqz5hbisKAhiVfAep2ib32f8gvC6p47CBmKVY4ii/PpOIzX/clZOQEgSPxvuHcSR cVcMGdljG+n8UqEOkkX5im0cW7pOUUht5GXWRGnBjXjtKTG64zxZnBPsPcqVJtxT q/lloKerUktJH3bJbUDU6iefBBzukQyy6tF37nbZH68bwTBlrh8CGL1BT2Eviqs= =WyFy -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gitk won't show notes?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/7/2015 10:13 AM, Michael J Gruber wrote: > Seriously: gitk knows F5 and Shift-F5 for refresh, and I think the > latter is the thorougher refreshment. Neither one makes newly added notes show up. The only way seems to be to close and restart gitk. Looks like a bug. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJVJA8KAAoJENRVrw2cjl5RrIgH/2FTWanl7IUyusBMmwR5buLP R0yVGf0xF6xzG3SmayDh9EzmhoSJDBFjbqlb8mG1pbgMQfRNKaCjnlk97WRQ5qDr X9CHImC4HODZVT/jAgCX5HsCEN62nIZBUfliQOH3PFbbAp6LG/Y/milZk3Ek+srL guFFzFsCyv88uAjDJMMM4Ub9Sg3rtKckZ2JeprNv8VDFuqvZWxRPA3G+7TYSTBdE wj73xIjyg0KVP1yAR/833TF7srDaRUnB3Z/AfDXAhekYum5TZnEZNQUh1DpiAnus dC6T8LWu14PebzmiZy+7QV3cakhlt9ZjrHW9eRBVzY7RAm8JRY1GSgbCQJ0pIQo= =EWg/ -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gitk won't show notes?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/7/2015 9:40 AM, Michael J Gruber wrote: > Phillip Susi venit, vidit, dixit 02.04.2015 21:34: >> I can't seem to get gitk to show notes, even when I give it >> --notes. Does it just not handle notes? >> >> > > Have you tried with "--show-notes"? > > It works over here even without --show-notes, by the way, but I'm > not on Windows. Are you? Yes... and this just got weird... I shutdown and restarted gitk and now they show up just fine. It seems that adding the note while gitk is already open, and hitting refresh fails to detect the note. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJVI+R5AAoJENRVrw2cjl5RtnoH/RzJRU/FWrRKc+9P2V5OmR2p bAto0W92AwQVj4jDL3ndmkgm/RivYwNGYXuRVpLXPjKc0bgKNx8a/w4slnoPiWfv HFdIRXGWiJmTLhkzTYHlFLx6uZiDcsz5MV0IW1FhVvqa+QcViTS95yZXtzMj9aj5 g6w1h8C3NU+XBQNf9mDS7a6Xwd3+TZfXQJT1CQasTlgvHefzCk0aLU8K0G09N1ld 3XRGY6cCKplEn5CUDuiMLRAiq7XVWpufV0zmT9ZV7h2ZCcY8b9yav/rQPVd5L1cF PIagJwyZ6YTR/EAGiVU6w0HZemiXHeXTMNMfv4GCRxGwINtfVzmxhnuD5IvKVZk= =b8Ql -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Why can't I stash submodule changes?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/5/2015 10:15 PM, Shane da Silva wrote: > I’m trying to wrap my head around why this is the current behavior, > as I suspect this is intentional but it seems unexpected. If anyone > can shed any light on this, I would really appreciate it! Why would you expect anything else? You have no local changes ( since you committed them already ). In other words, git status shows no uncommitted changes, so there is nothing to stash. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJVIqLsAAoJENRVrw2cjl5RFGsIAIC38/iZTQsYWfeS8mOt3DVY jrRCrbfHcjQyKWsEk2seupEV1K1OO0lPhocRE4+3T+vAz3n9Wdc+ATuXNv41vmkY r2R3VaTXimLw6NfaSxMfqEb4xL/9M0UhUS7SdEALVEApS4AySxYKWKL+RoqF0LWD JgP6DHCzOLBy8cttaQppZdfRHa34FUmeH1k7m6r/14tarwcc+a3glVqW7i3gue7z s3zhEkd+dqgab79TNj1gh86UE016UmG7yjbBTWKnNrYdTCW5IBCDqsp0We2PH1Jy 2QPckedCisroZjq0I4uAbuUCm94obiEJKclbY+Wl4sVdYb9rralBOJnPkKwRsiw= =4ekO -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
gitk won't show notes?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I can't seem to get gitk to show notes, even when I give it --notes. Does it just not handle notes? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJVHZm5AAoJENRVrw2cjl5RT0wIAJVfE2cDQODUCoOsIwhVDiMf CNeTKy1VxCgwVy8KDoYxY2hBlDIRELkcVIkN5ueNVu57LZ+1z/iBUhgr3mmzH9br z2viRjkKRlNSqP/b+HwK0+GxBIbN/FpIEyKTPe558SMcUjCkeINfxfcgYYbmY4Rv aY60j4LMQCEgltkmyDJ/kRX1I7Pr4YCfwNfoIQj3LxvCY5WL7VGn7QmM56Qh9m8P DVvTdMHBnhLOTCSa79/uAAZKJxVNE7z8YnHw1aimNXs/uwm7DYl4coxXVGDxyUfm DnEDcqtLfFst58UtLDRn7f3YawT7heeeXJ7tKUAizX3YQuTTRp9WrN12yE7Crxo= =Z23X -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Clone from shallow bundle bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04/01/2015 08:33 PM, Duy Nguyen wrote: > OK two additional options on top of what we already have: > > - save .have and add extra prerequisite SHA-1. - create a bundle > that does not hit shallow boundary in the first place, roughly > speaking it's "max depth minus one". This one does not have extra > .have or prerequisites Huh? If it is one less deep that doesn't help: the new clone will still be missing history. AFAICS, the only way to keep the new clone kosher is for it to have a .git/shallow file that identifies it as a shallow clone so that history walks stop short instead of complaining about the missing history. Thus, all that is needed is for the clone, when it notices that history is missing, is to create the shallow file instead of erroring out, telling you to fsck yourself, and rudely deleting the new clone. It is one thing to tell you that there is missing history, but quite another to delete the repository it just created due to it missing history. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCgAGBQJVHJraAAoJENRVrw2cjl5RABEH/RW+J5eFNRL80qMVSSnYI4Wb RjCb5Lb1pp4PBQtGK6yJ/7lzDYptAN6aLcpMVrGiyIIJDm7KfZ6rGvhUegn37ImH dCelZs+XHeR1dVd05Lbn9FGgB3mg873JOb5+i/hMuuudrXhNjRy6hhFGBnVulpPP lySfaPMscbSH7lzqr1zxgdu4GzRLlLPzKv1ojiWGyy97iRAsN6bRy6I1/wsddKMn hESUlv7AdTNQxu3b3NsLGS20a9QHMpKjBxBLvOYE6ftr4yyHMkxum/+BnoASY2UB h5LenKnQzRwFNGiw1BDeQESqYDXpQ4yA7lpd91gsINwgVsRqg82iSen9/fszzq0= =shT5 -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Clone from shallow bundle bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/1/2015 9:36 AM, Duy Nguyen wrote: > Thank you. I can reproduce it now. We need to plug this hole. I'd much rather it not refuse to clone so that I can end up with a proper shallow clone. At least the way it is now, when I clone the detached head, I can manually add the .git/shallow file and everything is fine. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJVG/trAAoJENRVrw2cjl5RTTIIAJkdte4gWrrOGA49CI0xivX7 1FXH3tPp/Nhd7gG3MXNfozm78DS3ZWqoU4l2SUhoE3La9UJ81T2rVo9GjcR/yXeS V0In+JyoQX3spZdtvH18qzKCFczyeUlu260EG7mQsBFgnAHsAJW3BPA6DWEPpfJS U3RPGt4S7KKy2+XJAGZJgvhvwM9vndgx161Kgwwpdocv2uWmv0AZEcMzOppZQy3y RqWSO5iY3qRwpMiRRh9YsQsuVNpXGxwPqV5oXXFLD7yaAMqCF5qdUYz8fWNQQ1+V 49RpGzMNHA60FP9BrvlHMCaJgFEvBT4nrpN4MCQgkelp8LOELX1kfuq9MWl1irA= =BmpO -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Clone from shallow bundle bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/1/2015 9:09 AM, Duy Nguyen wrote: >> Strange; it works fine for me using git 1.9.4.msysgit.1, and then >> I just get the complaints from gitk. I created the bundle with >> no prereq argument, i.e. "git bundle create shallow.bundle". Did >> you use a prereq argument? > > No, just your command plus a branch name. I tried v1.9.4.msysgit.1 > (but on linux, not windows), clone rejected too. Even stranger... when I use a branch name, the clone fails, but not when I use a detached HEAD. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJVG/LlAAoJENRVrw2cjl5RKtQH/2TTJ31PtG+3MQjlKjyMhhNZ Xl/A7QSvruDEUF8V7kdyCYlN4I3EQIelMHeG0tZPWw/qnOPMMvpMvxI2xu3na0xf L4AopC3XPFCe2kRG4EV17Nf0QAR8zx+ARGhCzf+PzLgGlFdmMsN3TZ/8Oe3yJHSZ /eu+CPvmvE0N5PeC1EnPoYJwoTcBHFFI5he736OHI5PA8WtekJPQ2SZ17pZttN0p jmZSeqoUZAe4Jeu+xfE0hYuuoVKtlkat/2GmOKrYcglyuw1+RaU31op+mKkhtGyw x8yq0LmJ+zMAtj3Ab5fqv0rRrjbNPYeO5uTT+lgHSU62QRPVclv8lkugRyotcMk= =owOK -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Clone from shallow bundle bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/1/2015 6:01 AM, Duy Nguyen wrote: > On Wed, Apr 1, 2015 at 1:31 PM, Junio C Hamano > wrote: >> The only way a bundle can record "something" "noting" that it is >> an incomplete history, while allowing it to be read by existing >> implementations of "git bundle unbundle" is to list the commits, >> behind which there is no history available in the bundle, as >> bundle's pre-requisites. I said that the addition of shallow >> repository support did not enhance "git bundle create" to do so, >> and you are saying "it just needs to put", implying that it >> currently does not. > > Alternatively, we can record SHA-1 in the shallow file as refs > whose name is always ".shallow". This way "unbundle" can recreate > the shallow file if it wants. Having this "remote" shallow file > would fit well in our fetch pipeline. It's harder to recreate > shallow file if we record prerequisite instead: if commit A is in > the shallow file, the ones in prerequisite category would be A's > parents. So we would need to go over the bundle to look for commits > whose parents are all in prerequisite list. It takes more time. Right; you can't rely only on the pre-requisets as objects in the bundle may be deltaed against them and so they can not be unpacked without them. The idea here is that all required objects ( and their delta bases ) are present, either in the bundle, or in the local repository, but if you walk the history chain you arrive at a parent pointer to an object you don't have. That point should automatically be recorded in .git/shallow. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJVG+wIAAoJENRVrw2cjl5Rj2UH/0AXyy63MDYhg0C7t4ljsb0U pHo5vZyfurO2k4vd2kiUySDhIaZ7gmhkPySbPlphzqHGtvdPtyLwkYPVgqBVv7uA fDodTsxt64MbdFN3CNk5zh5BLDs6q1+1IjscvTlsmjCQbTz+ys+Qw1QS0zS9hSWD +jGDCa1x5zETniI0wJiXSSiCF6ZtFHuEJwZp5MSj257tAidibi/a0U+AHYdFwgSf jtoUWXR2t9Xl/eN1Xkw3bjE5xQUogZYox0IuUWPvv4c4rmgxhU6SYzYftWD7Lkof vL2t+y1x1IhmgLaIoPz+/p/Dfeupivf6F8dS6cfyG++QIshPGq6ACZ49NRymcy0= =TctP -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Clone from shallow bundle bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/1/2015 5:55 AM, Duy Nguyen wrote: > On Wed, Apr 1, 2015 at 4:10 AM, Phillip Susi > wrote: >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> >> I made a shallow clone of my repo, then used git bundle create to >> pack it all into a bundle file, then cloned from that bundle. >> The initial shallow clone has a .git/shallow file that identifies >> it as a shallow clone ( and I guess keeps things from complaining >> about the missing history ), but the the repo cloned from the >> bundle does not, > > You made me worry a bit. We have checks in clone and fetch to make > sure the result is "good" (i.e. gitk should not complain, > clone/fetch should report it instead). Unfortunately I tested and > it seemed to work as expected (i.e. clone fails) > > $ LANG=C ./git clone ./shallow.bundle shallow2 Cloning into > 'shallow2'... Receiving objects: 100% (2813/2813), 5.33 MiB | 0 > bytes/s, done. Resolving deltas: 100% (250/250), done. Checking > connectivity... error: Could not read > 50a3ba22454e2989424d5de489de9c0f68fed5ec fatal: Failed to traverse > parents of commit c73a8a63134734ddf7077d09355a10a0077ed2ca fatal: > remote did not send all necessary objects Strange; it works fine for me using git 1.9.4.msysgit.1, and then I just get the complaints from gitk. I created the bundle with no prereq argument, i.e. "git bundle create shallow.bundle". Did you use a prereq argument? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJVG+pKAAoJENRVrw2cjl5RLkMH/j0IlFsf5oEsFejLqD2fxFAJ 8r7pZCtYFvFqMqLQivLCdU/aYCd/5F99VUtusH3NphJvxkmCaLyRwLyA1KR/AozQ slEXc5gmjbUg9yEBffYQ/xFPAGrizb2BblSzl6hcAZGtscLNyKvOjHttvJL+xM1+ uY0dwHcQ97m5p3DlehjLSAHolJF+waEhS6MarACZuSbi2JBTvo3OOagyt0o46sjp t5v4kfRfTYD6DTlY+VPTUC56unBaVItLDfxY5d+iHGDY2o5rhl4AFWLbCh3v6ltl OAuVs+UPKn0kV9tIQ6EBhQKf5CooCZtbr45OVGpVLPipjQFq2QqUjVWrLMEskhw= =Fem/ -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Clone from shallow bundle bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03/31/2015 06:17 PM, Junio C Hamano wrote: > Phillip Susi writes: > >> I made a shallow clone of my repo, then used git bundle create to >> pack it all into a bundle file, then cloned from that bundle. > > I think the introdution of shallow clone feature broke git bundle > create by not teaching it that its shallow boundaries are > prerequisite commits to unbundle its contents. IOW, the bundle > created from the shallow clone is broken, I would think. It seems to me that it isn't exactly broken; it just needs to put something in the bundle noting that it was built from a shallow clone, and then when cloning from the shallow bundle, the new clone needs its .git/shallow file. In other words, the bundle contains all of the objects in the shallow clone, so a new shallow clone can be correctly constructed from the bundle, it's just that the new clone doesn't *know* it too is shallow and things like git log and gitk need to stop following the history chain when they reach the shallow point rather than complain that the rest of the history is missing ( which is intentional ). For that matter, if you do create a depth limited bundle from a non shallow repository, then try to clone from it, the cloned repo should automatically become shallow rather than complain about missing history. In other words, any time you clone from a bundle, the clone process should check if the full history is in the bundle, and if not, automatically make the new repo shallow so as to avoid the error messages about the missing history. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCgAGBQJVG15kAAoJENRVrw2cjl5RnvgH/iMyN/1U2zg+ju/teVEQIMRL prvC60S9/yLxSp6RmiXpN2xuGHMkn7i2y6XpM9RQdE6ETeGaIw7UaDan3r7BPTSD +Q9DrAM0g17IGNxvmGPiJZP7j0t2e43oTA9KM8alf6icMU/mWJgQsbtc9QFVfVkd jsYevK1GR6ysrAHBAV6GxKfNw5yw3N+kTf9s2rKXWIFaArD0rcKJZVxiygMlhVSa hT4j3+n5f3n0WMDVxFzhwOaW+yrPiXF3gs1pKFX8GT5g1BtvOAEnyskSgA5nZsNB G53ncyyefinaaBqCvPSbcTLXmWLV8QuLBExc13BWXiVUD2rRNQr7u1ihbxWKyvU= =D90B -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Clone from shallow bundle bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I made a shallow clone of my repo, then used git bundle create to pack it all into a bundle file, then cloned from that bundle. The initial shallow clone has a .git/shallow file that identifies it as a shallow clone ( and I guess keeps things from complaining about the missing history ), but the the repo cloned from the bundle does not, so gitk run in that clone complains about not being able to find the objects referenced by the oldest commit in the repo. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJVGw03AAoJENRVrw2cjl5R4aQIAKxddA+eneEEchuygYwA8zFK 4O+LuEXbJ09JR196Zj535jbJ3NLre8KLX8l7gxVRFQ5FscG0+ylvawAZ2VCUrl+6 dfTXOTfzmu36GGKJ+wG7SFIIEAzjFyLk8bj5qtJgF3F3PZqkgxmBGmQskGK1Dlet VUqXL0IndMTDnb5//pFGyF2L5aPvBfXcC6pZAUBjKz4dl7MfFVXbuzCMe2TqN+l6 dPPjqANGb8MiAdhoVQ69c0uI2XH9dvmpRJTOX1Yr1IMW/AvKKM/w/A9MDKkhsab3 ccgeYDUjtUioaplnMcDwkSj4jQfQedgmIUdHeMbT0WOiKvHRArlroRVcjQS8pps= =kPAv -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
gitk and reflog
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Why does gitk -g master not work? I would expect gitk to load up the
master branch reflog and show each of the previous heads that master
has transitioned through, but it doesn't. Instead I have to run gitk
master@{1} master@{2}, etc, and then, while it shows each of the
previous heads, it doesn't label them.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBCgAGBQJVEMo4AAoJENRVrw2cjl5RVXUIAKcp7UTV6sfgquW7YJEZAXqO
KPS0kdpVwS2rJN5RNuRHEYlFPDgM7sm3gicXpEpksGQnS6CsR3fCgpQXb9GZRHgR
q/fh9E0BvLTjWzxBip7Y5Ojb+cgyAUw1/Y2Pewq9Cb3Vb+DOokh9JHKSVa/7Y/+8
7UBGMM8xc2ac0JUbYK2Jaq3Koq8uHjSg8IidzYxDrxFKxnt2ZW2ArAAIyEdSTYd6
12uGFQN+NM6ZK3I8gviGhXi+sI3FhosUDBjjCqMtgt0Wp4mRWZwxmE9rkAA0/5re
R74IxcgXnezVCeX3GrrgzsSBnPVXF+UnvZX0KqDuhMnNw+qFACXTVVOW5U+V2Jo=
=M49Q
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Import git log into a spreadsheet
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm trying to import a git log into a spreadsheet. I used a simple - --pretty=format: switch to select the fields I wanted and separate them with commas to generate a CSV file that can be imported. The message body, however, is presenting a problem. The first problem is that it contains newlines itself, which normally signal the start of a new record. It turns out that even when quoting the field, MS Excel still fails to import it properly ( good grief MS ), but openoffice calc does. The second problem is that the body itself may contain quotes. I can't figure out a good way to deal with these quotes. It seems that replacing them with a pair of quotes should make the CSV valid, but how can I replace only those quotes internal to the field without replacing the quotes that actually bracket it? Is it possible to have git log use a NULL terminator between records instead of a new line? Or is there a better way of going about this? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJU7NmpAAoJENRVrw2cjl5RWFEH/Re8o38zp+EqQxrOM7ZfypUy Ebaqf8Sa3dIs57iJINnNNsy6kTyPGCxPphdI5zbN5DVuduYKldZSMIeQ1S3sysRq SPH+E0KL1yxWEv8A0s5CKN/THvPHoUMpl0D7850LBrEmfQzyYNBE4NRBLHSPUL2w pbAaDeQQwmTigwF6J1AYdz3FlZZznVGzR6ST/Tios64G33wePzPOulF8QyXjpQJq R1QNRc9EmMz+FC1X/BwrPMX0e8YeTipjW+X/s6uMUXB6F9cln0VcNR5QOhDO1JDp avbdSwl7nQWRX244cKPfX+eujBgC8RnyrLyz74vSsn1vO8BHtSrLMQ5+1Lbymjo= =MTpF -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git rebase --skip stuck in a loop
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/13/2014 3:34 AM, Jeff King wrote: > Thanks for saving the stuck state. > > If it's possible to share the whole repo, it might be worth seeing > (then we can all just run "git rebase --continue" ourselves). If > it's too big or is confidential, just tarring up .git/rebase-apply > and making it available is probably a good first step. It's the debian parted repo, so nothing confidential. Here it is: https://drive.google.com/file/d/0ByOQJBpP4bDXXy13YlN0aE5Fcnc/edit?usp=sharing -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTmweVAAoJEI5FoCIzSKrwI84H/2Di1d5MeQpcg/I02nF7sd/f gICGclFE8MPuTnKYfpYf4/SbSnB9+Znp+9OhQA0frYIblWHWEnUzwhINrDHvqApK hCsuNGb5iHgy8ohZVGqH8B4ew8x4Ru3pwy9VYV2Wc1Z33curDIohx6qi4LCIrlaB StzWgq3h8hV+3QB5zcD9MfAfdKkz1u5bIMlT9VYofYwctYERVk2DyaAj8eKBGyWo 6dWYuZDoQfO3Hnd/uGqWbdHrPiDoSQqYPbHNWNOnX24w+IKDv2Xe9bcHro+9A+Jg PF+QXo4IS1E7CwevExe7gGKK3KdrD9SMixW7hHAbVVnpDIsvw485EL0xsZfmFJk= =ncor -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git rebase --skip stuck in a loop
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/12/2014 09:02 PM, brian m. carlson wrote: > On Thu, Jun 12, 2014 at 05:01:16PM -0400, Phillip Susi wrote: >> So nobody has any ideas on what to check for or how to debug >> this? > > I'm assuming this works in the general case, because we have tests > for it. Do you perhaps have a repository and a set of reproduction > steps we could use to try to reproduce this? > > If you can get that information, I'm interested in trying to fix > it. I don't have a set of reproduction steps, but I do still have the repo that is in this stuck state if there is any data you might want me to pull out of it ( .git/rebase-apply? ). I had spoken to another Ubuntu dev who said that he had this happen to him once too and he just did an abort and tried again and the problem went away, so it seems hard to reproduce, which is why I have preserved the problem to try and analyze it. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTmlDyAAoJEI5FoCIzSKrwN0IH/R6ny2h1XLv3Rj2Aed6C8xzU +XsiNo6RYG9++Jk3vr705CVnmWx+4lwhr7E6jW9ValdDKEYjamypeQUyqrWSokiH IajIMc4BNowGW7Eg1uRV8KQfb1P+QtmxBMwumOnOYk9zPfA9JcmlPVT6g5LrKy9N 6TMIlCMY1v0WPKZhseYYWHayP8PHF8KqSVuGIAZoPKPQdOQjNAOLW+PPbxiQKCcB PrspPx+hNk4NUUm8156BdJO+xEGQpSYIY384yo0dEfvh3QHB4z/wTv84/9APxEQO rV+67fW1psrFX+GkUolL9WFCBOeZRk3nykYJRravSOuOJKBa9laGAmiJT/EjWYI= =DONL -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git rebase --skip stuck in a loop
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 So nobody has any ideas on what to check for or how to debug this? On 6/10/2014 2:57 PM, Phillip Susi wrote: > I'm in the middle of a long rebase and have had no trouble with > git rebase --skip several times, but now it has become stuck: > > psusi@devserv:~/parted.git$ git rebase --skip Auto-merging > libparted/arch/linux.c CONFLICT (content): Merge conflict in > libparted/arch/linux.c > > When you have resolved this problem, run "git rebase --continue". > If you prefer to skip this patch, run "git rebase --skip" instead. > To check out the original branch and stop rebasing, run "git > rebase --abort". > > psusi@devserv:~/parted.git$ cat .git/rebase-merge/msgnum 17 > > Each time I try to skip, it just keeps trying to reapply this one > patch. Any ideas? > > git version 1.9.1 > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTmhUcAAoJEI5FoCIzSKrwkjgIAKOclhuJPiNoWIEv1dBr4DBC IdwG9hY8lQPCN5Pg8th5CYk3ziX7iZ8+jaHEBaUYX2yehT1deg5WfsxU0uezWphH JyHMRX4kk7l1PW3/v3bEvZ0WYe77s4GB3m9XegjKwEL8xtGi7srEPsHgWB8gnFzE hswUMbq5mw9hoIpYnxEs18F2MOfP6i4J3gTilPrmq+hZCQyZrX/IsV5lR6kDXRES j7b3cr6n2EfUeWxKrwo+tMIBdGAgpMamWlzqM7gMND/YUswv84mD3b9lXjEfjqZf GfBXJSH/z0KLDKycYrDOZlryLEnx///N6STg2WGm0oo7ehAKn6Mtgi1rR5y/aYs= =bUQV -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git rebase --skip stuck in a loop
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm in the middle of a long rebase and have had no trouble with git rebase --skip several times, but now it has become stuck: psusi@devserv:~/parted.git$ git rebase --skip Auto-merging libparted/arch/linux.c CONFLICT (content): Merge conflict in libparted/arch/linux.c When you have resolved this problem, run "git rebase --continue". If you prefer to skip this patch, run "git rebase --skip" instead. To check out the original branch and stop rebasing, run "git rebase --abort". psusi@devserv:~/parted.git$ cat .git/rebase-merge/msgnum 17 Each time I try to skip, it just keeps trying to reapply this one patch. Any ideas? git version 1.9.1 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTl1UcAAoJEI5FoCIzSKrwwHIH/38Cm19zg+37zgckLiy/3GhN 3Gmil5kX+3KkIHCxlPz3Ti3xCA5baM7tDzFdDIKcx8N/i8oALgWeAWf1Euy9Ww1K 3etIAMKzO463kmV7UbgSbLz5DpYWSaGo9WiYAC7xklhQV94w1Ainx5Lo4kRv1Wfj R9TpQgViFnW2gNJv1zw0qHLXk1/h88LlAQsBaaY6I4f/DOLhAte7rGinkTgZtjmo G/9PUMudQcehG65ITPlNLtoFsM8UHadNMLwJts/B7Yq23XNyRF50IaT8c1A/irSU mfYqdHCho3D4kq+k0u+t0Z0bj6pfvo4b0khLafrYLrWGHC5K+Z3lE63ysJ/Mdj8= =LZ9q -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Repository formats
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have seen some discussion about various changes to the format of the index and pack files over time, but can't find anything about it in the man pages. Are the different formats documented anywhere, and how to tell which format you are using? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTOsrPAAoJEI5FoCIzSKrwk2cIAIKZYz4yBoKjDUitHrSmhuMo Rb9x+A1mISnzeTon30BGacPkMUppvPI3RFQIA2VgmstrBVrT8QrKMH2Ir91gmEs4 rLW5LkhRv7OATDdMy6UIJHej+rTMUXZo22+2BVTPKsS0vbtiHC9ypOweIk911jxw PutmeBMLrc1h8eznsKGptZwxIB4bJThYIixR767XVFb53R2XTosj7gINOUsVzOM/ TFtkp3eo+TD852RZ31wNxhzukUA3O7zqdNLYpUD5zkpniGYhaKxruEPfL0Wy43dS 3cmFztoHFlIoeNesJhFNtnP7VPlfO6/D8C1PgSIPHyg7aBFoFjreQgTr6j24uvo= =yiki -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New directory lost by git am
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/5/2014 12:13 PM, Jeff King wrote: > We apply the changes to "modified" and "new" to the working tree, > but we do not stage anything in the index. I suspect this is > because our invocation of "apply --index" (which is what is doing > the real work with "--reject" here) bails before touching the > index. In theory it should be able to update the index for files > that applied cleanly and leave the other ones alone. Yikes, that's really bad. > But I have not thought hard about it, so maybe there is a good > reason not to (it is a little weird just because the resulting > index is a partial application of the patch). The "am -3" path > does what you want here, but it is much simpler: it knows it can > represent the 3-way conflict in the index. So the index represents > the complete state of the patch application at the end, including > conflicts. yes, but -3 fails if it can't find the parent blobs. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTF20HAAoJEI5FoCIzSKrwFfQIAJfPmplu7zskercvjnuZGCle ccTzK0rYtrwQn/78Vrbc6kqcrQvbvtrqUMN4/ILJ5xeaO80Gzzz8pchBPNN8khhY VBQiWUOrKzBH1vszveneva+gFUrLIWk2KI6T8lGTnYulvRVe38WRAwr/8qEClPX6 hUnYChM17WE+KTV39ezA6ww9ZAyOX7EHq87PJp5nVgBB4HkmkDmccfxYTFNB4FGg PPqun8g0Fyytd+Qrsk2M5L6NsPUXi32wIt8EWcyPwU6QrQgKbuWK7QlVkcPPzecM eHifKm8V1V0VKudm3S8jbaUDG2KnLIdMveXu/e9Hn7+YgDQh9zM1m7f+NVJDvjk= =NAe9 -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New directory lost by git am
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/5/2014 11:34 AM, Jeff King wrote: > I don't think those steps are necessary for Chris's example. When > he switches back to the master branch, git removes the subdirectory > (the file is tracked in "temp" but not "master", so we remove it > when switching branches, and then the directory is empty, so we > clean it up, too). You can verify with an extra "ls" after the > checkout but before the "am". Right. >>> * "git apply" parsed patches that add new files, generated by >>> programs other than Git, incorrectly. This is an old breakage >>> in v1.7.11. >>> >>> Does that sound like your problem? If you can I'd suggest >>> updating, ideally to the recent 1.9.0 release but if you're >>> feeling conservative try 1.8.3.4. >> >> Vaguely, except for the "other than git" part. This patch was >> generated by git-format-patch ( I didn't think apply handled >> patches that weren't ). > > I can't get Chris's script to fail on any version of git. Can you > show us an example of a patch that does not behave (or better yet, > a reproduction recipe to generate the patch with "format-patch")? AHA! It requires a conflict. There were simple conflicts in the NEWS file so I applied the patch with git am --reject and fixed up the NEWS, and ran git am --resolved. The git am --reject fails to add the new directory to the index. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTF1UOAAoJEI5FoCIzSKrwTD4H/35pUf8DFsbwPIVVQi+8I8e3 5NMHwQrHK3TPbZigVPBgVfwRCtOAxX656BPhninfhix99HWs00W5zGaFDwkymRNp 87EeU3LVcIjapqijszw9AqwBLvfm9uzXEus964hShCJVOmKBezQfl6Mvcrkn5Na1 UchJLkRzEoi6VUyUso8FH0xpL7JyjF08H19dtvXoUbrvrXYuN1Ys3UMBHXVEVdi+ 5O924lo4+psgdjGZ3HUpclYRbKO0LS5IVMCxFRw5Q+EfARJQ7NXzv/csRXIKyms7 roCQqmQnnem71GHx6SQaepnY5pKuEnmmDaqXbCOqZdpyfo1CB7SFJDq/VXrbLyw= =zS2r -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New directory lost by git am
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/5/2014 3:10 AM, Chris Packham wrote: > My example is creating a commit on the "temp" branch then applying > it to the "master" branch using git am. > >> Do a reset HEAD~1 --hard, and git clean -x -f -d before git am. >> I didn't notice the missing file myself for some time because it >> is left in the working tree, just not added to the index and >> included in the commit. >> Right... so the file is left in the directory, even though it is not checked in. A git status should show it is an unknown file, and a clean should remove it. > Regardless of reproducing the issue a quick glance at the Release > notes for 1.8.3.3 the following sticks out: > > Fixes since v1.8.3.2 > > * "git apply" parsed patches that add new files, generated by > programs other than Git, incorrectly. This is an old breakage in > v1.7.11. > > Does that sound like your problem? If you can I'd suggest > updating, ideally to the recent 1.9.0 release but if you're feeling > conservative try 1.8.3.4. Vaguely, except for the "other than git" part. This patch was generated by git-format-patch ( I didn't think apply handled patches that weren't ). -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTFzQiAAoJEI5FoCIzSKrwXEMH/iQdFdAApGnFCyLGA4l87d4M ITLtyL632gHA39KnlEqtTc6TgFjQMrV3m8s9TeR6DiEI9qGvNvnP2E4JBFORZprk RSJoCa9qMuAYOtSEtwrzbhMZpBN7hAZeJ7txP2KwZiGXoWjr4RSawjViQHhnXQEP L9QMmwjWJBwZE/eklYg8W+Ov987uribGTgOL8Wx1iMME2C88VfyCWtg1ClTz3aEh UeyAvyLxSA+YvS4xg+nUBAxXX8bFI0g53Yjf3Lt/1/EzdO67sH7CRChR67BmANWZ NBoxBqenN6/qg0rfRojOnjGTtRpAJX48dgnEHulUJrixrmqBYXAbi8dNVW8KkiM= =tzX5 -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New directory lost by git am
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03/04/2014 10:08 PM, Chris Packham wrote: > Could you provide a few more details such as your git version (git > --version) and an example of the failure. I've tried to reproduce > the problem based on the description provided but everything seems > to work as expected for me. Version 1.8.3.2. > git --version git version 1.9.0 mkdir test && cd test && git init > echo "hello world" >a.txt git add a.txt git commit -m"Initial > commit" git checkout -b temp mkdir b echo "lorem ipsum" >b/b.txt > git add b/b.txt git commit -m"Add b/b.txt" ls -R .: a.txt b > > ./b: b.txt git checkout master git format-patch temp -1 --stdout | > git am ls -R .: a.txt b > > ./b: b.txt > You are reapplying the patch while it is already applied. Do a reset HEAD~1 --hard, and git clean -x -f -d before git am. I didn't notice the missing file myself for some time because it is left in the working tree, just not added to the index and included in the commit. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTFphoAAoJEI5FoCIzSKrwx78H/iTLvtMVb2hmn2g2YDQuJWe3 nENrqlRNDF11YHpA9c7chxepcuP2CZaZjoXv45aCQG9Wx9XJyKPIbauhwqIIVUjR VYDORdtpn8u3Pf3WWyHYW+MEoupYyni4VYENVSjKnV6sLT951TuYI+4paHWat3lq /at9UkLy4d39hj2P/6M+voBbKWzblBZzP31lH6OY/Mno2zhh4eQChhsnZYPQ/Hfn REAeyB4WsLCjnPz+uEkOcWaEVVh+BwNU1UmK/tX+rzhBsaRzhDY5IIWTL9dfkD/z Af86IUSKdTjnMq7CTmVAmlxAfHXF0bgtlybrVY2Sdc8R/CqmWCz6USyKdUxgLIk= =Z3Z/ -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
New directory lost by git am
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I applied a patch with git am that adds a new source file to a new directory, and later noticed that file was missing from the commit. It seems that git am fails to add the new file/directory to the index. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTFpCjAAoJEI5FoCIzSKrw1CsH/1E/0Wgs3RtXPLqWbwVoFy+U Bc7dW7TBmb8EScC+3DedI4u9ryjZigjbsnBg1Y8V/gEtmUSmvt1e8CWTdvMLQpvx bnasL4uia/CBOg/aZkJ1iEBiHA3sUi9Es4FqoHbuGBn0bkDrA2NQvt3bCqNf6n8H PCeWx/qb8+F4niI0I8T5ASeqOHMxxSegHvlGezl6XZoGHa5SeLRrg7JtW3ZoWKCO q6GRzR6dV4FWJckfajUo34IUQNS4YA7wLpmC3PVUn3+EgF+affAEigjVWGRWdf2k cuaNu6hUAuD/2EHhCt6YP+ubV+FYiU86QOvmVifVpH1Apd29Fw4Kqnvyq2zJVC0= =hXsK -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git am and mangled subject lines
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/24/2014 3:19 PM, Junio C Hamano wrote: > Phillip Susi writes: > >> git am already ignores the "[PATCH X/Y]" prefix that >> format-patch adds. Is it possible to get it to ignore any >> additional prefix that a bug tracker mangles into the subject >> line? i.e. "bug #:"? > > I think applypatch-msg hook is your friend in a case like this. Can you point me in the direction of some documentation on this? I don't see it mentioned in the man pages for git am or mailinfo ( I would think that would be the place to have it ). -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTC6pvAAoJEI5FoCIzSKrwQpYH/iJ8RPqEoIoO+GBU2HxmCfEZ Tlo1qwbvw26ALY71/WQFtVKW+3Bh1XYpAs0rsL5tpCJw/EMgAEm1cPFASf+BHcRI NO57NBdk9we+hvUju+o6/It5e6OrYj/im+nI/AFfenRsbwPj8/S0MoMiP4jOEVkW tTSCEeC5ldR4IbxBfphbV7me79Sk8nZssXTFmWJEv80H41LdMd8ZThR4ZFCcyzUR ifAflWHN7dj3uwY0Lr+OdCRrPw3qU1LXRjKK2SHBTG1Qk4uJW3sFJKHTupAipOEQ KKQ0QP/4WQWCSjq+8El4jnnlf++KAwbbOnAVYkbeKzy/4KOxJX7pimDypJHYGp8= =LZvc -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git am and mangled subject lines
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 git am already ignores the "[PATCH X/Y]" prefix that format-patch adds. Is it possible to get it to ignore any additional prefix that a bug tracker mangles into the subject line? i.e. "bug #:"? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTC51PAAoJEI5FoCIzSKrw5YYH/R6t5fS71UAfFomsD/8HWHoI ve1tIyyruHeriOV8qttlNQGynuEXkI2IBMWJaB7jV5oK8d4OsVQZ/7Nfcxoj52SO JXDSs0MVDB2Ro2lHXRnQsaCy/TUm+ALWsNiTy0kYMTeC7Iqtri1T1l8gaG2rwRJh AGT1sgGssl9CvGFgDHJxRZ4WHSl/XrcjErZeJHz59hGIeJSeq2tJXjfNzNTHrNpw B4rcW8AxXhx+3vWPx8PSJsiVeWR1ndILXwxBsUHPuUW5SdsNBrty1L+4xrGIbxm7 qV7HVJ6BvJ4MXuTEOec3a9ACmvUTDNNMGRf2xonjXMcguojRZHjltRazsI34n8o= =sWTQ -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Filter log based on paths NOT touched
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 11/25/2013 10:13 PM, Duy Nguyen wrote: > There's a difference between "skip commits that touch anything > directory foo even if it also touches something outside of foo" and > "skip commits that _only_ touches something in foo". Not sure which > way Phillip wants here. Negative pathspec only supports the latter. > The former needs a new option in rev-list, because the logic to > consider a commit not a match if it matches a pathspec is out of > tree_entry_interesting()'s control. I'm looking for the latter. Specifically I'm trying to see what changes to the upstream code a debian package has made so I need to ignore commits that only change things in debian/. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJSlCTcAAoJEJrBOlT6nu75jUQIAJOybMyXE6lr4y4aX6od02Rn lINvPVC1Xub2E1lsofIB+N4QvZDRWlIJOIcj3GRqirzUcNBaIOUxUW4+UV7KgMQH wmImS8DdBgrkI8Sompe9B0gqd4lmB2mzTutQfOzdEZ/ZOU50935daYboK//X7zM/ vSmumJpRwNfw1BKyuxVpAQ8Ablo9yUu2cswLKJPSKyQkT9d/AJn07LE5/DKZORQN RD3r94kToftgTfsQTJbNpPujJ5nVHwVmiC44Qghdquj54l++ai5Xs2wRU3Za3i+O ts7Tn5Lrw+pFAT5Lnt0v8Yedp7fVgjRhIsNEDIVlgNuHevP/oBOXIxuLJBlCBIE= =AYYO -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Filter log based on paths NOT touched
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I can't seem to find a way to invert the meaning of a pathspec given to git log in order to find commits touching anything BUT a given path. Does such a thing exist? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSk7D5AAoJEJrBOlT6nu75myIIAMoAgihPAhDrCBpRKUHF/X8S B8vjwIg7zALajU+vrz7B/UyxKFHC54sYn0MaAA5htBXKCtd6L0tHrNa1gYbd9qT+ xgTuF7+Unwv90yFBEsoZgEwlSyaLBAVHknMiE4ecxaJrlhBqESbePNrORCwCAuPq ANrYunEETN2KNgYBkNszdEp7Ga9RcP7LWisL/pNV2k+ac7YfqGp1jsN00jLMYqvH c+8Kl154N3xgvk+pGvkKGbO3MavkmEK47lLL929g9iXeP3NkMsrxyEjhnABD9tS3 SxzYZt9G+lpH2Tv8l1/NqMafdNy5P7CEs00C4JZn1EzEcIBqMeYgUhce+WU75qc= =p2gM -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cherry-pick generates bogus conflicts on removed files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/17/2013 5:14 PM, Junio C Hamano wrote: > Correct. > > Without inspecting them, you would not know what you would be > losing by blindly resolving to removal, hence we do not > auto-resolve "one side removed, the other side changed" to a > removal. Even when I specify the "theirs" strategy? It seems like saying to unconditionally accept their changes should not generate conflicts. > That does not need to mean that we should not make it easier for > the user to say "resolve these 'one side removed, the other side > changed' paths to removal". > > "add -u" will be a way to say "Record the changes I made to my > working tree files to the index". So presumably > > rm -f those files that the other branch removed git add -u > > would be one way to do so. Of course, you can also use "git rm" > directly, i.e. > > git rm -f those files that the other branch removed I have about two dozen such files. Are you saying I have to individually remove each one? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSYTbNAAoJEJrBOlT6nu752lAH/33YymYr773UZY8ryioA7dkQ he3qjYzxWdIY2FtNFfYER1o1Q7PpeDLvq61b67IZ2htFjiK4+xgM/q+wjp3RMkXI sA2vQ9iNn8dvR+PlzR9DgOFcDD17p3Q/xbu3H/M4Nt+H3px+Yz6sjUUSOzDAzXl8 ADQe0g4KkQnY4fjx+iWbrygY5xXCaQ52693pwYvR67GijfYxIuNb4d9DpkZhyqIZ L6qjJH4FR1AZl6n5hPj0a9ZitrO8J/MjJ24oLVBfBU2h1GF5h7LoavkU02S874BZ /8fULrCYfTCMSkyOCnk2xCkhw3sbqU9vEu90npI5X1nRbZZ0ro/DPAjXCgHB40c= =EB2w -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cherry-pick generates bogus conflicts on removed files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have a commit I am trying to cherry pick that removes a number of files. It seems to generate conflicts for those files that have been modified on this branch since the common ancestor. Since they are being removed, I don't care about what changes have been made on this branch, just remove them. Even git cherry-pick -Xtheirs does not help. How can I avoid these conflicts, or accept the deletions? I tried git add -u, but that seems to take my version rather than accept the deletion, and there is no -u switch to git rm. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSYEFlAAoJEJrBOlT6nu75kSEIAMjqXl6nhfEhIMC66Zh4W/y0 MZ/+acDUNdvpCDtEpf9nPIFBQUKxdqAhUg0qYLSOvdvhQIvxkgo6nMo15MAA5Dd/ jNPZD78m0qwvNooUhFiHdqSEwob+2ntA9/VVP+LgCsRcK6BUqHs1Z3MKbe4vXPYr +/bs11daxcnHH81aXOwRcOlUZRsG+yCDQiD9qjhPyv0BCCdS9splC+R7JZy4VaYb 6GQ03G7oY0yFGV9UAOXD1OqDwVPc30tinXlCM2GaBQNc11IQzpi813nEyxTOaf3Z P5BXXH5ZzDNQS5F6Dn/VVNM6MMxVugIgGJafd4EkJiRHw4fIcUCX3/aeDoEDHlc= =uy2D -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Diff colorizer confused by dos newlines
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Of course! Thanks, now it completely makes sense. On 07/09/2013 03:41 PM, Jeff King wrote: > On Tue, Jul 09, 2013 at 02:28:32PM -0400, Phillip Susi wrote: > >> When I try to look at a color diff of a file using dos newlines, >> the output gets an odd sequence of ansi escapes and a stray >> carriage return showing up only on the + lines, but not the -. >> The normal looking - lines look like this: >> >> \r\n ( from previous line ), ansi color escape, '-', whitespace, >> text, terminating ansi escpae ( [m ), \r\n. >> >> The broken + lines look like this: >> >> \r\n ( from previous line ), ansi color sequence, '+', >> terminating ansi escape ( [m ), whitespace, ansi color sequence, >> text, terminating ansi escape, ansi color sequence, stray \r, >> terminating ansi escape, \n. > > That's intentional; the added lines go through the "whitespace > checker" to help you identify potential whitespace problems (there > is not much point showing them on lines going away, since you are > getting rid of them). > >> Any suggestions on how to resolve this? > > Try: > > git config core.whitespace cr-at-eol > > See the description of "core.whitespace" in "git help config" for > more details. > > -Peff > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJR3J5IAAoJEJrBOlT6nu757gIIAMx+w7oCXZt66z57VhZi2yl0 PmL1HKGQ9+aqerwBtcOFvQL+b8s8o0nLUg3jkHWUFLdEtTIsLSlEwyJBhCzbWQQh NzzuwtzGdoXWxj8lFf1PakLRpWg0IW0QJ6WuMltEZMvPvF4jyt3yCArS0StpZEG/ PhQoEsgg8XjgvP6KIpZDc/CoElKn0fyWf0HlLFwV+k+cCgQM+y7POnGdzGwKIM+O U5QJxWZmNFuznJHxkd+YWIsAZuHS/eH4Tz97/Abl9z30k+/4eHvD/Hd47RCTLrC1 90IiBKp9vvPWJHA+6c1WTwiTnn54CpudKstB499aaMRsvXBzXHcdD+Tkb38imwI= =WMkZ -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Diff colorizer confused by dos newlines
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 When I try to look at a color diff of a file using dos newlines, the output gets an odd sequence of ansi escapes and a stray carriage return showing up only on the + lines, but not the -. The normal looking - lines look like this: \r\n ( from previous line ), ansi color escape, '-', whitespace, text, terminating ansi escpae ( [m ), \r\n. The broken + lines look like this: \r\n ( from previous line ), ansi color sequence, '+', terminating ansi escape ( [m ), whitespace, ansi color sequence, text, terminating ansi escape, ansi color sequence, stray \r, terminating ansi escape, \n. Any suggestions on how to resolve this? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJR3FZQAAoJEJrBOlT6nu75mvIIAKVKcK2GeVNHKRBkkljqE1U5 2piftz+CO6sVZGba8DUxMdbA5tCDQrz11yzowuKXDtyr1hxhgjBoXcsN36RZhYdu gijE6qF5w/na6MdPgJ7LMizHo8xOeVGhrDr+qhM/5nD77rVumtEnGAdoEqdY+uY3 mYfHaz2dHAG3W7mOlfvycb4HhRBao64pGh5JnuyvvnZKSXkOyJozjzTEzC7tuNU8 b9qofVKnTMse7Ek6jGp64GNaxxtcQCt1J8cd2uOJtROUK2g9KgVhy2QSRFqoZ1yO zEtTD28bj7nWJubsgVyOdtx0ClxiO1RHQRqQH2/zQM6NlfntAljD15bHcPNJaKo= =g3R+ -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Enabling scissors by default?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/08/2013 05:42 PM, Junio C Hamano wrote: > It is very easy to miss misidentification of scissors line; as a > dangerous, potentially information losing option, I do not think > it should be on by default. I suppose if it only requires one instance of >8 or <8 and one -, it might be *slightly* dangerous, but if it required a slightly longer minimum line length, it would be pretty darn unlikely to get triggered by accident, and of course, is easily disabled. > Another reason (and this is the original one) why it is not > enabled is to discourage the contributors from overusing scissors > -- >8 -- line. If you always have to write too much stuff before > the proper explanation of your patch, so that the integrator has to > use -c option all the time, you are explaining your patches wrong. I often see patches being tweaked in response to feedback and resubmitted, usually with a description of what has changed since the previous version. Such descriptions don't need to be in the change log when it is finally applied and seem a perfect use of scissors. Usually such version to version descriptions are put in a cover letter, but if you are only submitting a single patch instead of an entire series, using a cover letter seems silly when you could just put the comments in one email and clearly mark them as not needing to go into the final changelog. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJQ7KriAAoJEJrBOlT6nu755UkIALIT3T5yHH5i+0HOrXLlXzQR +S2jJfFZ8Kcc+kleiEJ3uLFVGTLMpRyjJFKceOuB4/TdJFUivrYJHWJxcKmW8WzK BJKZOjt/jv9r8Qt/AB7KA45S7awfQnOWkg6KQlJa1IM0nUPbo4upgMlWar9l7vjz Hkr7geuHY4fsVUJ7R0rYPcT3pue8ywsT4a9o/ocstfXmC05IrLKQtzO4TuvfiaTb yBG+rAPKz36zfxCN5NyKExZO6v/LnCKym/PH4a6wYIeTUz1EvuaPy5lQOo6ORQ4h xbSyBRDPN4yiVgNXfSQmGKwd9XPqs6h8Z0q3X5mGZyOXurw0JFRJlJ3v8hHIvqg= =Rn7z -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Enabling scissors by default?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I was wondering why am's scissors option is not enabled by default. It seems a very handy feature, but I'm reluctant to use it when sending patches because the recipient has to notice the scissors and remember to pass --scissors to git am. Could this be made the default? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJQ7JLGAAoJEJrBOlT6nu75iDYIANFiiH50RlL9WKEfaoybeA5K ZLodBze1TcAYIx2/ad6qY+XCoq98+nVXTkv2IAleDiNlfeIhKD24UTWNCysT8p1J 5KeFfR4paxLJLJKkmSL5s3DJbyjLlJWcxD7vGku6F4k35NmY3VYR4rJ/CVv0YRrs p4nNG/EXWBo3/ngiL9QS4E65N0CfcOOjn48RQUmk1DGXSFNHP4L1KuJ4dA9cs9BC 5KmNwh5X6OOal0Lf+ezbxzvoGMwQmhBAxx3t8JQR3E22dLQlUq7stlPl5LDd+Cis XWfNk3B4NuFTum9LqWnM5TN89WCCFh4/pskdRd5ONF51G0jbuF/hBFbwU05qL/4= =Qd94 -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
recovering a corrupted git repo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have not had any issue until I ran a git fsck recently, which repored gzip and crc errors in some pack files. git fsck does not seem to repair the errors, only report them. I would like to try to rebuild my repository, without downloading any more from the origin than I have to. All of the commits I have added seem to still be intact, so I assume the corruption in somewhere in the upstream history packs. How can I correct the errors, and fetch the corrupted upstream history, while preserving my patches? So far I have exported my patches as bundles, and made a fresh clone from upstream, then pulled the bundles back in, but there must be a better way that only fetches the corrupted bits from upstream? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJQ6kS6AAoJEJrBOlT6nu75tFgIAJCI+DEWDVxddEQM5qhmz1y8 3JuqjTHp7gIXmQv6WGbEIehJrRfTBudQn+Ip2jLMwavvL16oZe+cf/uuLo393Z+T pxEcWHOtjdU/XZeQOV//R/Cfo7PY5n8wfasgFYZuFesJchInwFocTI6S5x2B9kIB dvLonoiDQwe9JqQaoAxM0OLTWe9aj0gc3c36+WUlRgRZijUhEogYQwU8aEoa+TMq s2p+tbaNYKocRAafQ4824DMnuQTWb+HJVU4uI1pH2yB964Urq9ELSX2jxeSRdlaH d+AoJ8oMdymmUwPeuyivcmQQHEGGsxxgCOuLSSHh1hcxMaytZNcEkVQ6OzuGyZk= =yUr4 -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
