Problem Following file history through sub-tree import

[Crabtree, Andrew]

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' ?

[Crabtree, Andrew]

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

[Crabtree, Andrew]

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 andrew.crabt...@hp.com 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

[Crabtree, Andrew]

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

[Crabtree, Andrew]

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 migrat...@gaia.rose.hp.com 1318778853 -0700
committer Gustavo Mora Corrales gustavo.mora.corra...@hp.com 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