Problem Following file history through sub-tree import
Having difficulty understanding how to invoke 'git log' to track the history of a file that was imported into a different location through a subtree merge. I had thought just '--follow' was needed, but I don't seem to be getting any results with that. Example below. Thanks! ~Andrew git --version git version 2.9.0 cd /tmp mkdir subtree_test cd subtree_test git init touch foo git add foo git commit -m "initial" git remote add git_src https://github.com/git/git git fetch git_src git merge --allow-unrelated-histories -s ours --no-commit git_src/master git read-tree --prefix=git_src -u git_src/master git commit -m "import git as subtree" cd git_src git log pager.c commit 22e7b2600b54f25314c399d45b1ea45d2427c754 Merge: 8df5087 ab7797d Author: Andrew Crabtree Date: Wed Jun 22 08:58:04 2016 -0700 import git as subtree git log --follow pager.c # nothing gitk pager.c * # only shows merge commit 22e7b git gui blame pager.c & # shows history as expected git log HEAD^2 -- pager.c commit c3b1e8d85133e2a19d372b7c166d5b49fcbbfef2 Merge: 595bfef 708b8cc Author: Junio C Hamano Date: Wed Feb 24 13:26:01 2016 -0800 Merge branch 'jc/am-i-v-fix' The "v(iew)" subcommand of the interactive "git am -i" command was broken in 2.6.0 timeframe when the command was rewritten in C. * jc/am-i-v-fix: am -i: fix "v"iew pager: factor out a helper to prepare a child process to run the pager pager: lose a separate argv[] commit 3e3a4a41b0dac564c0302ced4ccc423d0d39bc21 Author: Junio C Hamano Date: Tue Feb 16 14:34:44 2016 -0800 -- 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
Plumbing version of 'git branch --contains' ?
I need to get a list of refs that can reach a certain SHA in in a script. git branch --contains SHA would be great (runs in ~2 seconds), but not my preferred option for scripting. I tried for br in $(git for-each-ref --format='%(refname:short)' refs/heads/) do git merge-base --is-ancestor $1 ${br} if [ $? -eq 0 ] then echo "${br}" fi done Which gives me perfect output, but takes 82 seconds to run in my environment. Is there an alternative I'm missing to give me the run time performance of 'git branch --contains' but with stable output suitable for parsing? Thanks in advance, -Andrew -- 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: Performance Issues with Git Rebase
Ah gotcha. That makes sense. Default behavior is to do a patch-id check on all of them which is exactly what you would normally want to happen, and suppressing that speeds things up considerably at the risk of attempting to re-apply an already existing patch. Thanks much for the explanation. Perhaps I'll add a progress indicator since my organization will be doing a significant number of these types of rebases in the near future. Regards, -Andrew > -Original Message- > From: Junio C Hamano [mailto:gits...@pobox.com] > Sent: Monday, October 13, 2014 10:26 AM > To: Crabtree, Andrew > Cc: git@vger.kernel.org > Subject: Re: Performance Issues with Git Rebase > > "Crabtree, Andrew" writes: > > > I'm getting the same output with both the triple and double dot for my > > specific case, but I have no idea if that change makes sense for all > > cases or not. Any guidance? > > The difference only matters if any of your 4 patches have been sent > to your upstream and accepted and appear among the 4665 changes they > have. > > The --cherry-pick option is about cross checking the combinations of > 4 x 4665 and filter out matching ones (if any). > -- 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
Performance Issues with Git Rebase
I have what appears to be a fairly straightforward rebase operation and I can't figure out why it seems to effectively hang 'git rebase'. I have a handful of commits that I made last summer and haven't touched since. I'm trying to rebase them against latest on upstream. git status On branch git_enhancements Your branch and 'origin/smb' have diverged, and have 4 and 4665 different commits each, respectively. (use "git pull" to merge the remote branch into yours) If at this moment I type "git rebase" it will print out First, rewinding head to replay your work on top of it... And then nothing will happen for approximately 30 minutes, and then it will complete. If I instead type "git rebase --onto @{u} HEAD~4" it completes immediately. I've narrowed it down to this line in git-rebase--am (approx. line 65) git format-patch -k --stdout --full-index --cherry-pick --right-only \ --src-prefix=a/ --dst-prefix=b/ --no-renames --no-cover-letter \ "$revisions" ${restrict_revision+^$restrict_revision} \ >"$GIT_DIR/rebased-patches" Which is turned into this in my particular case git format-patch -k --stdout --full-index --cherry-pick --right-only --src-prefix=a/ --dst-prefix=b/ --no-renames --no-cover-letter 451da4975b25797fe54cd11e4796bbd3ee0911ce...ea3cf673d0e76504738bf130d48148d5b96cc406 If I time just that command I get real 32m10.324s user 26m21.296s sys 0m28.994s If I change the triple do to a double dot I get real 0m4.276s user 0m0.096s sys 0m0.022s Which is much more in line with how long I think the command should take. The triple dot is coming from just earlier in the file here if test -z "$rebase_root" # this is now equivalent to ! -z "$upstream" then revisions=$upstream...$orig_head else revisions=$onto...$orig_head fi which seems to have been in place for 2+ years. I'm getting the same output with both the triple and double dot for my specific case, but I have no idea if that change makes sense for all cases or not. Any guidance? Thanks much, -Andrew -- 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
Problem with Git rev-list output
I'm seeing some oddity in one of my repositories where the root commit is being output in 'rev-list' even when I pass in a reference that should exclude it from being output. I've attempted to reproduce the issue in a test environment but so far have failed at that. Problem details below as best as I can capture them. Seeing the issue with versions of git from 1.7 to 2.1. Thanks, -Andrew The root commit is here me@myvm:/pnb/software/userrepos/cache/t4_ghs.git (BARE:titan4_v14_a)$ git cat-file -p 848de9c422c01c1f724d5c3f615bec476911f59f tree 5be87811b44f560159d9bb6a10a9fe9bd59147b9 author Migration Script 1318778853 -0700 committer Gustavo Mora Corrales 1318778853 -0700 Initial synchronization commit me@myvm:/pnb/software/userrepos/cache/t4_ghs.git (BARE:titan4_v14_a)$ git --version git version 2.1.0.rc2.3.g67de23d me@myvm:/pnb/software/userrepos/cache/t4_ghs.git (BARE:titan4_v14_a)$ git merge-base WALLE-J-14-60-GIT_07-DEC-2011 samrom_t4a 848de9c422c01c1f724d5c3f615bec476911f59f me@myvm:/pnb/software/userrepos/cache/t4_ghs.git (BARE:titan4_v14_a)$ git rev-list 848de9c422c01c1f724d5c3f615bec476911f59f 848de9c422c01c1f724d5c3f615bec476911f59f me@myvm:/pnb/software/userrepos/cache/t4_ghs.git (BARE:titan4_v14_a)$ git rev-list WALLE-J-14-60-GIT_07-DEC-2011 | wc -l 2132 me@myvm:/pnb/software/userrepos/cache/t4_ghs.git (BARE:titan4_v14_a)$ git rev-list samrom_t4a | wc -l 316 me@myvm:/pnb/software/userrepos/cache/t4_ghs.git (BARE:titan4_v14_a)$ git rev-list WALLE-J-14-60-GIT_07-DEC-2011 samrom_t4a | wc -l 2447 # commit is reachable from both references as expected me@myvm:/pnb/software/userrepos/cache/t4_ghs.git (BARE:titan4_v14_a)$ git rev-list WALLE-J-14-60-GIT_07-DEC-2011 | grep 848de9c422c01c1f724d5c3f615bec476911f59f 848de9c422c01c1f724d5c3f615bec476911f59f me@myvm:/pnb/software/userrepos/cache/t4_ghs.git (BARE:titan4_v14_a)$ git rev-list samrom_t4a | grep 848de9c422c01c1f724d5c3f615bec476911f59f 848de9c422c01c1f724d5c3f615bec476911f59f # Here -I would have expected --preceding the SHA with -boundary specified me@myvm:/pnb/software/userrepos/cache/t4_ghs.git (BARE:titan4_v14_a)$ git rev-list --boundary WALLE-J-14-60-GIT_07-DEC-2011 samrom_t4a | grep 848de9c422c01c1f724d5c3f615bec476911f59f 848de9c422c01c1f724d5c3f615bec476911f59f # here I don't expect the SHA to show up with either command line. me@myvm:/pnb/software/userrepos/cache/t4_ghs.git (BARE:titan4_v14_a)$ git rev-list WALLE-J-14-60-GIT_07-DEC-2011 ^samrom_t4a | grep 848de9c422c01c1f724d5c3f615bec476911f59f 848de9c422c01c1f724d5c3f615bec476911f59f me@myvm:/pnb/software/userrepos/cache/t4_ghs.git (BARE:titan4_v14_a)$ git rev-list samrom_t4a ^WALLE-J-14-60-GIT_07-DEC-2011 | grep 848de9c422c01c1f724d5c3f615bec476911f59f me@myvm:/pnb/software/userrepos/cache/t4_ghs.git (BARE:titan4_v14_a)$ -- 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