* Issue with gitweb + tag + branch of the same name from master branch commit
@ 2009-08-20 23:30 Nicholas A. Bellinger
2009-08-21 0:19 ` Junio C Hamano
2009-08-21 22:49 ` Jakub Narebski
0 siblings, 2 replies; 4+ messages in thread
From: Nicholas A. Bellinger @ 2009-08-20 23:30 UTC (permalink / raw)
To: git; +Cc: J.H., H. Peter Anvin
Greetings git folks,
I have recently been trying to make a tag and branch of the same name
from a previous <COMMIT> on a master branch on a kernel.org tree using
the following commands:
# Create the tag:
git tag -a lio-x.y <COMMIT>
# Push the tags:
git push --tags origin
# Fetch to be sure
git fetch origin
# Make tagged branch:
git checkout -b lio-x.y <COMMIT>
# Make <NEW_COMMIT> to lio-x.y and commit
git commit frob
# Switch back to master branch
git checkout master
# Push local branch to origin
git push origin refs/heads/lio-x.y
At this point after pushing to origin, I can do a fresh clone of the
tree, and do a 'git checkout origin/lio-x.y and I see '<NEW_COMMIT>',
and the logs and blobs look as expected..
However, after checking gitweb log for branch lio-x.y on kernel.org, I
only see <COMMIT>, and not <NEW_COMMIT>, and all of the blobs in branch
lio-x.y still reference the original <COMMIT>, et al.
John Hawley has been helping to resolve the issue (I am just going to
use different tag/branch names instead), and hpa asked me to report this
as it is easy to reproduce with the gitweb version on kernel.org..
Here is a bit of the IRC log:
22:30 < nab> Hmm, I wonder if the fact that I was tagging a commit from master, and then branching using the same
commit ID to a tag of the same name as the branch..?
22:33 < warthog9> not use the same name, I think what your doing is fine just the identical naming is whats
causing the problem
22:33 < warthog9> like tag-lio-3.0
22:33 < nab> Ahhhhhh
22:33 < warthog9> and branch: lio-3.0
22:34 < warthog9> since I think somewhere in git it's got two different orders of preference for tag vs. branch
22:34 < nab> Ok, so I should just delete the branch and tags and redo with diff names..?
22:34 < warthog9> one operation is using the tag, one is using the branch and we are seeing the conflicting
results
<SNIP> warthog9 makes somechanges to git repo with gitweb issues </SNIP>
22:40 < warthog9> that *looks* right to me now?
22:40 < nab> Yep, looks correct
22:41 < warthog9> so yeah, git is getting confused
22:41 < warthog9> ok so my theory is right, it's getting confused between the tag / branch
22:41 < nab> the blob for the ./autoconfigure is correct as well..
22:42 < nab> Ok, I have no problem using different names.. :-)
22:42 < warthog9> I would got show this to the git people, it *could* just be an old bug in gitweb (ours is not
particularly up to date) but if I can replicate it here easily enough I'm guessing there's
still a bug elsewhere
Many thanks for your most valuable of time,
--nab
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Issue with gitweb + tag + branch of the same name from master branch commit
2009-08-20 23:30 Issue with gitweb + tag + branch of the same name from master branch commit Nicholas A. Bellinger
@ 2009-08-21 0:19 ` Junio C Hamano
2009-08-21 22:49 ` Jakub Narebski
1 sibling, 0 replies; 4+ messages in thread
From: Junio C Hamano @ 2009-08-21 0:19 UTC (permalink / raw)
To: Nicholas A. Bellinger; +Cc: git, J.H., H. Peter Anvin
"Nicholas A. Bellinger" <nab@linux-iscsi.org> writes:
> 22:33 < warthog9> not use the same name, I think what your doing is fine just the identical naming is whats
> causing the problem
> 22:33 < warthog9> like tag-lio-3.0
> 22:33 < nab> Ahhhhhh
> 22:33 < warthog9> and branch: lio-3.0
> 22:34 < warthog9> since I think somewhere in git it's got two different orders of preference for tag vs. branch
I do not speak for gitweb but we typically favor tags over heads. The
only place "branch name" take precedence is where the command expects to
see a name of a branch, when it can also take any arbitrary object name,
and changes behaviour. I.e. "git checkout X", when X is a branch name,
checks out the branch so that the next commit advances the tip of that
branch.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Issue with gitweb + tag + branch of the same name from master branch commit
2009-08-20 23:30 Issue with gitweb + tag + branch of the same name from master branch commit Nicholas A. Bellinger
2009-08-21 0:19 ` Junio C Hamano
@ 2009-08-21 22:49 ` Jakub Narebski
2009-08-22 20:12 ` Nicholas A. Bellinger
1 sibling, 1 reply; 4+ messages in thread
From: Jakub Narebski @ 2009-08-21 22:49 UTC (permalink / raw)
To: Nicholas A. Bellinger; +Cc: git, J.H., H. Peter Anvin
"Nicholas A. Bellinger" <nab@linux-iscsi.org> writes:
> I have recently been trying to make a tag and branch of the same name
But why? Why do you want to confuse git and yourself?
> from a previous <COMMIT> on a master branch on a kernel.org tree using
> the following commands:
>
> # Create the tag:
> git tag -a lio-x.y <COMMIT>
> # Push the tags:
> git push --tags origin
> # Fetch to be sure
> git fetch origin
> # Make tagged branch:
> git checkout -b lio-x.y <COMMIT>
> # Make <NEW_COMMIT> to lio-x.y and commit
> git commit frob
> # Switch back to master branch
> git checkout master
> # Push local branch to origin
> git push origin refs/heads/lio-x.y
>
> At this point after pushing to origin, I can do a fresh clone of the
> tree, and do a 'git checkout origin/lio-x.y and I see '<NEW_COMMIT>',
> and the logs and blobs look as expected..
>
> However, after checking gitweb log for branch lio-x.y on kernel.org, I
> only see <COMMIT>, and not <NEW_COMMIT>, and all of the blobs in branch
> lio-x.y still reference the original <COMMIT>, et al.
I guess that you meant here gitweb's 'log' / 'shortlog' view linked
from 'heads' view, don't you?
> John Hawley has been helping to resolve the issue (I am just going to
> use different tag/branch names instead), and hpa asked me to report this
> as it is easy to reproduce with the gitweb version on kernel.org..
> 22:42 < warthog9> I would got show this to the git people, it *could*
> just be an old bug in gitweb (ours is not particularly
> up to date) but if I can replicate it here easily enough
> I'm guessing there's still a bug elsewhere
This is an old and long fixed (or rather worked around) issue in
gitweb, fixed in bf901f8 (gitweb: disambiguate heads and tags withs
the same name, 2007-12-15)... well if by fixed you can consider
passing around "fully qualified" refnames, i.e. the 'shortlog' link in
'heads' view now uses 'refs/heads/frob', and not only 'frob'.
J.H., you might want to consider cherry-picking this... unless you
have done that, or independently fixed this issue.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Issue with gitweb + tag + branch of the same name from master branch commit
2009-08-21 22:49 ` Jakub Narebski
@ 2009-08-22 20:12 ` Nicholas A. Bellinger
0 siblings, 0 replies; 4+ messages in thread
From: Nicholas A. Bellinger @ 2009-08-22 20:12 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, J.H., H. Peter Anvin
Greetings Jakub,
On Fri, 2009-08-21 at 15:49 -0700, Jakub Narebski wrote:
> "Nicholas A. Bellinger" <nab@linux-iscsi.org> writes:
>
> > I have recently been trying to make a tag and branch of the same name
>
> But why? Why do you want to confuse git and yourself?
>
I stumbled the strangeness in k.o gitweb due to my inexperience with git
tagging+branch.. I absoulutely agree that it makes more sense to use
different names for these, and that is what I am doing from now on.. :-)
> > from a previous <COMMIT> on a master branch on a kernel.org tree using
> > the following commands:
> >
> > # Create the tag:
> > git tag -a lio-x.y <COMMIT>
> > # Push the tags:
> > git push --tags origin
> > # Fetch to be sure
> > git fetch origin
> > # Make tagged branch:
> > git checkout -b lio-x.y <COMMIT>
> > # Make <NEW_COMMIT> to lio-x.y and commit
> > git commit frob
> > # Switch back to master branch
> > git checkout master
> > # Push local branch to origin
> > git push origin refs/heads/lio-x.y
> >
> > At this point after pushing to origin, I can do a fresh clone of the
> > tree, and do a 'git checkout origin/lio-x.y and I see '<NEW_COMMIT>',
> > and the logs and blobs look as expected..
> >
> > However, after checking gitweb log for branch lio-x.y on kernel.org, I
> > only see <COMMIT>, and not <NEW_COMMIT>, and all of the blobs in branch
> > lio-x.y still reference the original <COMMIT>, et al.
>
> I guess that you meant here gitweb's 'log' / 'shortlog' view linked
> from 'heads' view, don't you?
That is correct..
>
> > John Hawley has been helping to resolve the issue (I am just going to
> > use different tag/branch names instead), and hpa asked me to report this
> > as it is easy to reproduce with the gitweb version on kernel.org..
>
> > 22:42 < warthog9> I would got show this to the git people, it *could*
> > just be an old bug in gitweb (ours is not particularly
> > up to date) but if I can replicate it here easily enough
> > I'm guessing there's still a bug elsewhere
>
> This is an old and long fixed (or rather worked around) issue in
> gitweb, fixed in bf901f8 (gitweb: disambiguate heads and tags withs
> the same name, 2007-12-15)... well if by fixed you can consider
> passing around "fully qualified" refnames, i.e. the 'shortlog' link in
> 'heads' view now uses 'refs/heads/frob', and not only 'frob'.
>
Cool, I am hear it has already been fixed.
--nab
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2009-08-22 20:18 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-08-20 23:30 Issue with gitweb + tag + branch of the same name from master branch commit Nicholas A. Bellinger
2009-08-21 0:19 ` Junio C Hamano
2009-08-21 22:49 ` Jakub Narebski
2009-08-22 20:12 ` Nicholas A. Bellinger
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).