* Re: [PATCHv4 08/12] Teach the notes lookup code to parse notes trees with various fanout schemes
From: Johan Herland @ 2009-08-27 23:03 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Shawn O. Pearce, Johannes.Schindelin, trast,
tavestbo, git, chriscool
In-Reply-To: <7vy6p5ncz0.fsf@alter.siamese.dyndns.org>
On Thursday 27 August 2009, Junio C Hamano wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> > Yea, it was me. I still think it might be a useful idea, since
> > it allows you better density of loading notes when parsing the
> > recent commits. In theory the last 256 commits can easly be in
> > each of the 2/ fanout buckets, making 2/38 pointless for reducing
> > the search space. Commit date on the other hand can probably force
> > all of them into the same bucket, making it easy to have the last
> > 256 commits in cache, from a single bucket.
> >
> > But I thought you shot it down, by saying that we also wanted to
> > support notes on blobs. I happen to see no value in a note on
> > a blob, a blob alone doesn't make much sense without at least an
> > annotated tag or commit to provide it some named context, and the
> > latter two have dates.
>
> Yeah, and in this thread everybody seems to be talking about commits so I
> think it is fine to limit notes only to commits.
Agreed. I'm starting to come around to the idea of storing them in subtrees
based on commit dates. For one, you don't have multiple notes for one commit
in the same notes tree. Also, the common-case access pattern seems tempting.
Dscho: Were there other problems with the date-based approach other than not
supporting notes on trees and blobs?
If not, I'll start preparing another series with the date-based approach.
Thanks for the input, guys. :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH] upload-pack: add a trigger for post-upload-pack hook
From: Robin H. Johnson @ 2009-08-27 22:56 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
In-Reply-To: <7vy6p69j6a.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 547 bytes --]
On Wed, Aug 26, 2009 at 05:47:41PM -0700, Junio C Hamano wrote:
> After upload-pack successfully finishes its operation, post-upload-pack
> hook can be called for logging purposes.
+1 from me.
I'm actually going to scrap my previous pre-upload-pack hook and rebase
it off this, because I see a lot of commonality (I was passing in
have/want via stdin too).
--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[-- Attachment #2: Type: application/pgp-signature, Size: 330 bytes --]
^ permalink raw reply
* Re: [PATCHv4 10/12] notes.c: Implement simple memory pooling of leaf nodes
From: Johan Herland @ 2009-08-27 22:43 UTC (permalink / raw)
To: Alex Riesen
Cc: git, gitster, Johannes.Schindelin, trast, tavestbo, git,
chriscool, spearce
In-Reply-To: <200908271149.11003.johan@herland.net>
On Thursday 27 August 2009, Johan Herland wrote:
> On Thursday 27 August 2009, Alex Riesen wrote:
> > On Thu, Aug 27, 2009 at 03:43, Johan Herland<johan@herland.net> wrote:
> > > When allocating a new memory pool, the older pool is leaked, but this
> > > is no worse than the current situation, where (pretty much) all
> > > leaf_nodes are leaked anyway.
> >
> > Could you return the unused nodes back into the mempool?
> > By making the pool a preallocated list, perhaps?
>
> Yes, maintaining a free-list is certainly possible. However, the number
> of free()d leaf_nodes is relatively small (only subtree entries are
> free()d after unpacking them into the tree structure), so I'm not sure it
> pays off, runtime-wise.
I played around with the free-list idea, but it cost more than the memory
pooling code saved in the first place. I'm leaning towards dropping the
whole memory pooling idea, as the small run-time improvement is probably not
worth the added complexity. We'll see. I'll re-evaluate once I've refactored
the code according to the other threads of this discussion.
> > And then it is trivial to provide a deallocation function for the
> > mempool, which something really concerned about the memleak can call
> > (like when or if libgit get more usable in an application context).
>
> Yes, I plan to provide a free_notes() function that free()s all the
> memory associated with the notes data structure. This would of course
> keep references to all the mempools, and deallocate them (along with all
> the int_nodes).
This still stands, of course. Should be part of the next iteration.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: finding unmerged branches
From: Björn Steinbrink @ 2009-08-27 22:35 UTC (permalink / raw)
To: Joey Hess; +Cc: git
In-Reply-To: <20090827220241.GA1413@gnu.kitenet.net>
On 2009.08.27 18:02:41 -0400, Joey Hess wrote:
> My situation is this: My project has a lot of remotes with
> lots of branches; about 250 branches in total. I want to
> figure out which of these branches to look at to consider
> merging.
>
> So, I reach for git branch -a --no-merged master; that's what
> its man page says its for. But this still finds 120 branches,
> and a lot of them are not things I want to look at. Many of
> them are copies of some of my own branches.
>
> What I really want is a way to find remote branches that
> are not merged with any of my local branches (or any origin
> branches). A slow and stupid implementation of that is in the
> attached git-unmerged script, and it weeds the branch list
> down to 68 branches, which are mostly really ones I might
> want to look at.
>
> So, three questions:
>
> * Is this situation somewhat common, or an I doing something wrong?
> (Assuming that I have a good reason to want to look at remote
> branches rather than waiting to get merge requests.)
> * Is there a better way to accomplish this than a slow perl script that
> runs git branch -r --merged foreach of my branches?
Hm, not sure if I'd call it "better", but probably at least a bit
faster. You could create a "fake" merge to combine all the branches.
git branch -r --no-merged $(
: | git commit-tree HEAD^{tree} $(
git for-each-ref --format='-p %(refname)' \
refs/heads/ \
refs/remotes/origin
)
)
Björn
^ permalink raw reply
* Re: Question regarding git fetch
From: Avery Pennarun @ 2009-08-27 22:24 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Björn Steinbrink, Tom Lambda, git
In-Reply-To: <20090827221631.GA7058@coredump.intra.peff.net>
On Thu, Aug 27, 2009 at 10:16 PM, Jeff King<peff@peff.net> wrote:
> On Thu, Aug 27, 2009 at 10:12:50PM +0000, Avery Pennarun wrote:
>> After all, if I *really* care about the prior state of the remote, I
>> can just make it a remote branch. And if (as often happens) I just
>
> Do you mean "local branch" here?
Yes.
>> want to know what's new in that ref since last time I merged, it's
>> simply
>>
>> git log master..origin/master
>>
>> This works even if master has extra commits vs. origin/master, since
>> the double-dot invokes git-merge-base.
>
> Well, ".." doesn't use git-merge-base. But yes, I actually do this,
> except I do:
>
> gitk master...origin/master
Sorry, not my day for accuracy, it seems. I use both, and I should
have remembered that the triple-dot is the one that worries about the
merge-base.
Have fun,
Avery
^ permalink raw reply
* Re: finding unmerged branches
From: Avery Pennarun @ 2009-08-27 22:22 UTC (permalink / raw)
To: Joey Hess; +Cc: git
In-Reply-To: <20090827220241.GA1413@gnu.kitenet.net>
On Thu, Aug 27, 2009 at 10:02 PM, Joey Hess<joey@kitenet.net> wrote:
> What I really want is a way to find remote branches that
> are not merged with any of my local branches (or any origin
> branches). A slow and stupid implementation of that is in the
> attached git-unmerged script, and it weeds the branch list
> down to 68 branches, which are mostly really ones I might
> want to look at.
How about:
gitk $(git for-each-ref --format='%(refname)' 'refs/remotes/'; git
for-each-ref --format='^%(refname)' 'refs/heads/')
You could also replace 'gitk' with 'git log', and mess with the
--pretty=format:whatever parameter.
Have fun,
Avery
^ permalink raw reply
* Re: Using git to track my PhD thesis, couple of questions
From: demerphq @ 2009-08-27 22:21 UTC (permalink / raw)
To: seanh; +Cc: git
In-Reply-To: <20090827203402.GC7168@kisimul>
2009/8/27 seanh <seanh.nospam@gmail.com>:
> 2. They don't want to look at the latex source but the PDFs built from
> it, which they're going to annotate with their comments. So I need an
> easy way for them to get the PDF of each commit from gitweb without
> having to checkout the repo and build it themselves. Normally I
> wouldn't commit the PDF files into the repo because they're compiled
> files not source files, but it seems that just building a PDF and
> committing it along with each commit to trunk would be by far the
> easiest way to achieve this. But will git store the PDFs efficiently, or
> will the repo start to get really big?
As you can generate the PDF's from the latex then just hack gitweb to
let them download it from there.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: Question regarding git fetch
From: Jeff King @ 2009-08-27 22:16 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Junio C Hamano, Björn Steinbrink, Tom Lambda, git
In-Reply-To: <32541b130908271512h255834adl5a606054f6ab20e4@mail.gmail.com>
On Thu, Aug 27, 2009 at 10:12:50PM +0000, Avery Pennarun wrote:
> > I'm still screwed. The issue is that you consider your configured
> > refspec destinations to be precious, and not merely a cache for what's
> > happening on the remote side.
>
> Is the "precious remote ref" concept perhaps an imaginary one?
Maybe. I certainly don't use it. But I am trying to consider corner
cases where somebody who _isn't_ me is going to get screwed by a
change we make.
> After all, if I *really* care about the prior state of the remote, I
> can just make it a remote branch. And if (as often happens) I just
Do you mean "local branch" here?
> want to know what's new in that ref since last time I merged, it's
> simply
>
> git log master..origin/master
>
> This works even if master has extra commits vs. origin/master, since
> the double-dot invokes git-merge-base.
Well, ".." doesn't use git-merge-base. But yes, I actually do this,
except I do:
gitk master...origin/master
-Peff
^ permalink raw reply
* Re: Question regarding git fetch
From: Avery Pennarun @ 2009-08-27 22:12 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Björn Steinbrink, Tom Lambda, git
In-Reply-To: <20090827215007.GA6231@coredump.intra.peff.net>
On Thu, Aug 27, 2009 at 9:50 PM, Jeff King<peff@peff.net> wrote:
> I don't think the colon is the issue. Consider the same situation, but I
> say:
>
> # but today let's demo it first
> $ git fetch origin master
> $ git checkout -b demo FETCH_HEAD
>
> I'm still screwed. The issue is that you consider your configured
> refspec destinations to be precious, and not merely a cache for what's
> happening on the remote side.
Is the "precious remote ref" concept perhaps an imaginary one?
After all, if I *really* care about the prior state of the remote, I
can just make it a remote branch. And if (as often happens) I just
want to know what's new in that ref since last time I merged, it's
simply
git log master..origin/master
This works even if master has extra commits vs. origin/master, since
the double-dot invokes git-merge-base.
I think this might be a much more common than the case where people
actually want to see "what's changed since last time I checked what's
changed." At least, the latter question has never been very
interesting to me, or if it is, it's easy for me to tell by eye.
Avery
^ permalink raw reply
* finding unmerged branches
From: Joey Hess @ 2009-08-27 22:02 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1143 bytes --]
My situation is this: My project has a lot of remotes with
lots of branches; about 250 branches in total. I want to
figure out which of these branches to look at to consider
merging.
So, I reach for git branch -a --no-merged master; that's what
its man page says its for. But this still finds 120 branches,
and a lot of them are not things I want to look at. Many of
them are copies of some of my own branches.
What I really want is a way to find remote branches that
are not merged with any of my local branches (or any origin
branches). A slow and stupid implementation of that is in the
attached git-unmerged script, and it weeds the branch list
down to 68 branches, which are mostly really ones I might
want to look at.
So, three questions:
* Is this situation somewhat common, or an I doing something wrong?
(Assuming that I have a good reason to want to look at remote
branches rather than waiting to get merge requests.)
* Is there a better way to accomplish this than a slow perl script that
runs git branch -r --merged foreach of my branches?
* Should git have something builtin to handle this case better?
--
see shy jo
[-- Attachment #2: git-unmerged --]
[-- Type: text/plain, Size: 582 bytes --]
#!/usr/bin/perl
my @remote_branches = split ' ', `git branch -r | awk '{print $1}'`;
# have to filter out the "* "
my @local_branches = split ' ', `git branch | sed 's/^..//'`;
my @origin_branches = grep /^origin\//, @remote_branches;
my %unmerged = (map { $_ => 1 } @remote_branches),
(map { $_ => 0 } @local_branches, @origin_branches);
foreach my $branch (@local_branches, @origin_branches) {
map { $unmerged{$_}=0 } split ' ', `git branch -r --merged "$branch" | awk '{print $1}'`
}
foreach my $branch (sort keys %unmerged) {
print "$branch\n" if $unmerged{$branch};
}
^ permalink raw reply
* Re: Question regarding git fetch
From: Jeff King @ 2009-08-27 21:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Avery Pennarun, Björn Steinbrink, Tom Lambda, git
In-Reply-To: <20090827215007.GA6231@coredump.intra.peff.net>
On Thu, Aug 27, 2009 at 05:50:07PM -0400, Jeff King wrote:
> > I think this is a good example that any change results from this
> > discussion should apply _only_ to cases where command line refspecs lack
> > colon (i.e. used to mean "do not store this anywhere but in FETCH_HEAD").
>
> I don't think the colon is the issue. Consider the same situation, but I
> say:
>
> # but today let's demo it first
> $ git fetch origin master
> $ git checkout -b demo FETCH_HEAD
>
> I'm still screwed. The issue is that you consider your configured
> refspec destinations to be precious, and not merely a cache for what's
> happening on the remote side.
Which, btw, led me to consider whether there are heuristics for deciding
when a fetch refspec means one thing and not the other. I don't think
there are reliable ones (probably the default configured
refs/remotes/$remotename/* would not yield false positives, but I think
limiting to that would yield false negatives). So maybe this is
something that should be configurable, disabled by default for now, and
maybe enabled by default in the future (v1.7.0?).
-Peff
^ permalink raw reply
* Re: [PATCHv4 08/12] Teach the notes lookup code to parse notes trees with various fanout schemes
From: Junio C Hamano @ 2009-08-27 21:50 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Junio C Hamano, Johan Herland, git, Johannes.Schindelin, trast,
tavestbo, git, chriscool
In-Reply-To: <20090827212710.GV1033@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Yea, it was me. I still think it might be a useful idea, since
> it allows you better density of loading notes when parsing the
> recent commits. In theory the last 256 commits can easly be in
> each of the 2/ fanout buckets, making 2/38 pointless for reducing
> the search space. Commit date on the other hand can probably force
> all of them into the same bucket, making it easy to have the last
> 256 commits in cache, from a single bucket.
>
> But I thought you shot it down, by saying that we also wanted to
> support notes on blobs. I happen to see no value in a note on
> a blob, a blob alone doesn't make much sense without at least an
> annotated tag or commit to provide it some named context, and the
> latter two have dates.
Yeah, and in this thread everybody seems to be talking about commits so I
think it is fine to limit notes only to commits.
^ permalink raw reply
* Re: Question regarding git fetch
From: Jeff King @ 2009-08-27 21:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Avery Pennarun, Björn Steinbrink, Tom Lambda, git
In-Reply-To: <7v7hwpors9.fsf@alter.siamese.dyndns.org>
On Thu, Aug 27, 2009 at 02:44:54PM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > # we usually fetch the remote's master straight into our production
> > # branch for deployment
> > $ git config remote.origin.fetch refs/heads/master:refs/heads/production
> >
> > # but today let's demo it first
> > $ git fetch origin master:demo
>
> I think this is a good example that any change results from this
> discussion should apply _only_ to cases where command line refspecs lack
> colon (i.e. used to mean "do not store this anywhere but in FETCH_HEAD").
I don't think the colon is the issue. Consider the same situation, but I
say:
# but today let's demo it first
$ git fetch origin master
$ git checkout -b demo FETCH_HEAD
I'm still screwed. The issue is that you consider your configured
refspec destinations to be precious, and not merely a cache for what's
happening on the remote side.
-Peff
^ permalink raw reply
* Re: [PATCH jh/cvs-helper 0/2] Fix building when python is not available
From: Junio C Hamano @ 2009-08-27 21:46 UTC (permalink / raw)
To: Johan Herland; +Cc: Brandon Casey, git
In-Reply-To: <200908271857.47035.johan@herland.net>
Johan Herland <johan@herland.net> writes:
> Thanks. Both are
>
> Acked-by: Johan Herland <johan@herland.net>
>
> I'll fold these into the next iteration of jh/cvs-helper.
Thanks, both. Then I'll ignore this thread and simply wait for the next
round from you.
^ permalink raw reply
* Re: Question regarding git fetch
From: Junio C Hamano @ 2009-08-27 21:44 UTC (permalink / raw)
To: Jeff King; +Cc: Avery Pennarun, Björn Steinbrink, Tom Lambda, git
In-Reply-To: <20090827213426.GD4399@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> # we usually fetch the remote's master straight into our production
> # branch for deployment
> $ git config remote.origin.fetch refs/heads/master:refs/heads/production
>
> # but today let's demo it first
> $ git fetch origin master:demo
I think this is a good example that any change results from this
discussion should apply _only_ to cases where command line refspecs lack
colon (i.e. used to mean "do not store this anywhere but in FETCH_HEAD").
^ permalink raw reply
* Re: Question regarding git fetch
From: Jeff King @ 2009-08-27 21:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Avery Pennarun, Tom Lambda, git
In-Reply-To: <7viqg9q7gx.fsf@alter.siamese.dyndns.org>
On Thu, Aug 27, 2009 at 02:20:46PM -0700, Junio C Hamano wrote:
> I think it is reasonable, in 1.7.0, to change "git fetch" with command
> line refspacs that lack colon (i.e. saying "fetch this ref" without saying
> "and store it here") so that it updates remote tracking refs if and only
> if an appropriate remote.$remote.fetch is configured to do so. E.g. when
> I fetch from Eric for git-svn updates with
>
> $ git pull git-svn master
>
> because I do have
>
> [remote "git-svn"]
> url = git://yhbt.net/git-svn
> fetch = +refs/heads/*:refs/remotes/git-svn/*
Does the colon really matter? That is, should
$ git fetch git-svn master
store a tracking ref, but
$ git fetch git-svn master:foo
not? In both cases, git has learned during the course of an operation
what the new value of the tracking ref could be, so why not store it?
The obstacle I see is that somebody may be using configured refspecs as
something other than a tracking ref. That is, they care about _when_
those refs on the RHS of the refspec are updated, and are not treating
them just as a cache of what the remote side has.
> On the other hand, if my refspecs for "git svn" _were_ like this:
>
> [remote "git-svn"]
> url = git://yhbt.net/git-svn
> fetch = +refs/heads/master:refs/remotes/git-svn/master
>
> then I would _not_ want this:
>
> $ git fetch git-svn dev
>
> to create a new tracking branch refs/remotes/git-svn/dev.
Of course not. It's not in your configured refspec, so you have
requested no such tracking ref. I think we would have to limit ourselves
to how the tracking refs are defined in the refspecs. Otherwise how
would we know to put the tracking ref in refs/remotes/git-svn and not
some other place?
So I think it is a simple matter of applying the configured refspecs
with information we happen to have gotten during the course of a
somewhat-related operation.
-Peff
^ permalink raw reply
* Re: Using git to track my PhD thesis, couple of questions
From: Junio C Hamano @ 2009-08-27 21:38 UTC (permalink / raw)
To: seanh; +Cc: git
In-Reply-To: <20090827203402.GC7168@kisimul>
seanh <seanh.nospam@gmail.com> writes:
> I'm planning to use git to track my PhD thesis as I work on it and to
> let my supervisors track it. I've setup a git repository and a gitweb
> instance showing it. There are a couple of specific requirements.
>
> 1. My supervisors don't want to see all the little commits that I make
> day by day. So I'll commit to a dev branch, then whenever I've made
> significant progress will merge it into a trunk branch. I want the trunk
> branch to get all the changes but as one big commit, not inherit all the
> little commits like a normal merge would do. I think this is a `git
> merge --squash`. Btw the help for that command ends quite brilliantly:
> "(or more in case of an octopus)".
>
> 2. They don't want to look at the latex source but the PDFs built from
> it, which they're going to annotate with their comments. So I need an
> easy way for them to get the PDF of each commit from gitweb without
> having to checkout the repo and build it themselves. Normally I
> wouldn't commit the PDF files into the repo because they're compiled
> files not source files, but it seems that just building a PDF and
> committing it along with each commit to trunk would be by far the
> easiest way to achieve this. But will git store the PDFs efficiently, or
> will the repo start to get really big?
What I would do if I were you (and I did something similar recently while
working on my book) is something like this:
* Keep your source in git. Do not worry about the commit granularity.
Commit as often as you think makes sense.
* Have a Makefile to build pdf if you have not done so.
* Dedicate a separate directory, for review pupose. Have a separate git
repository there. If you choose to use an untracked subdirectory
'publish' of your source work tree (you do not have to), you would do
something like this:
$ mkdir publish
$ (cd publish && git init)
Arrange things so that "git push" in that repository will propagate its
contents to the public repository your advisors will look at.
* Have a 'publish' target in your Makefile, which would roughly do:
#!/bin/sh
make pdf &&
cp paper.pdf publish/. &&
this=$(git rev-parse HEAD) &&
prev=$(cd publish &&
git show -s | sed -ne 's/^ *Changes up to: \(.*\)$/\1/p'
) &&
{
echo "Changes up to: $this"
echo
case "$prev" in
'') # initial round
git shortlog ;;
?*)
git shortlog $prev.. ;;
esac
} >publish/log &&
cd publish &&
git add paper.pdf &&
git commit -F log &&
git push
* Then when you want to submit the current status for review (perhaps you
would want this to happen at the end of each day, or every other day,
or whatever), type
$ make publish
The idea is:
(1) If your source material is not interesting to your advisors at all,
there is no point showing, let alone the commit granularity of your
work; and
(2) If your advisors want to see PDF and PDF only, then give them that,
but as you correctly said, that is a cruft from your source's point
of view, so do not mix them together.
^ permalink raw reply
* Re: Question regarding git fetch
From: Jeff King @ 2009-08-27 21:34 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Björn Steinbrink, Tom Lambda, git
In-Reply-To: <20090827204835.GC4399@coredump.intra.peff.net>
On Thu, Aug 27, 2009 at 04:48:35PM -0400, Jeff King wrote:
> And this matching is not really any different than what the fetch code
> does when applying the refspec to what the remote offers. So I don't
> think it should be any significant new code; it's just a matter of
> activating that matching and updating the local tracking refs based on
> what we actually fetched, instead of what the remote advertised.
Sure enough, here is a really simple proof of concept. This is the first
time I have really looked into the fetch code, so I hope I'm not totally
breaking something else. :)
Basically it works like this. Both "git fetch remote" and "git fetch
remote refspec" work by making a "ref map" via get_ref_map. This is a
list of refs, with some refs having a "peer ref" that points to the
local counterpart. Those without a peer are just stored in FETCH_HEAD.
The function works by starting with a list of possible remote refs, and
then applying the refspecs to it.
Calling fetch without explicit refspecs means we will create the map
using the configured refspecs. Calling with commandline refspecs means
we will use those. So what this patch does is to first apply the
commandline refspecs to narrow the list, and then apply the configured
refspecs on top of that to make a new list, and then concatenate the
lists.
So you will end up with "two" refs to fetch, which just happen to match
the same source. One will go to FETCH_HEAD, and one will go to the
tracking ref. I.e.:
$ git remote add origin ~/compile/git
$ git fetch origin next
From /home/peff/compile/git
* branch next -> FETCH_HEAD
* [new branch] next -> origin/next
And it should work the same if you supply a more interesting refspec,
too:
$ git fetch -v origin next:foo
From /home/peff/compile/git
* [new branch] next -> foo
= [up to date] next -> origin/next
or even a wildcard:
$ git fetch -v origin refs/heads/*:refs/foo/*
From /home/peff/compile/git
* [new branch] master -> refs/foo/master
* [new branch] next -> refs/foo/next
* [new branch] master -> origin/master
= [up to date] next -> origin/next
I haven't thought long enough to be convinced there aren't any bad side
effects, though. I guess if you had non-traditional configured refspecs,
you might be surprised to see them applied in this case. Something like:
# we usually fetch the remote's master straight into our production
# branch for deployment
$ git config remote.origin.fetch refs/heads/master:refs/heads/production
# but today let's demo it first
$ git fetch origin master:demo
I don't know if people are actually using refspecs in that way. But we
do need to consider that this is a potentially destructive change.
Anyway, here is the patch.
---
diff --git a/builtin-fetch.c b/builtin-fetch.c
index 817dd6b..d9e44c7 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -119,6 +119,9 @@ static struct ref *get_ref_map(struct transport *transport,
const struct ref *remote_refs = transport_get_remote_refs(transport);
if (ref_count || tags == TAGS_SET) {
+ struct ref *tracking_refs = NULL;
+ struct ref **tracking_tail = &tracking_refs;
+
for (i = 0; i < ref_count; i++) {
get_fetch_map(remote_refs, &refs[i], &tail, 0);
if (refs[i].dst && refs[i].dst[0])
@@ -129,6 +132,12 @@ static struct ref *get_ref_map(struct transport *transport,
rm->merge = 1;
if (tags == TAGS_SET)
get_fetch_map(remote_refs, tag_refspec, &tail, 0);
+
+ for (i = 0; i < transport->remote->fetch_refspec_nr; i++)
+ get_fetch_map(ref_map, &transport->remote->fetch[i],
+ &tracking_tail, 0);
+ *tail = tracking_refs;
+ tail = tracking_tail;
} else {
/* Use the defaults */
struct remote *remote = transport->remote;
^ permalink raw reply related
* Re: [PATCHv4 08/12] Teach the notes lookup code to parse notes trees with various fanout schemes
From: Shawn O. Pearce @ 2009-08-27 21:27 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johan Herland, git, Johannes.Schindelin, trast, tavestbo, git,
chriscool
In-Reply-To: <7vtyztq8nv.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Johan Herland <johan@herland.net> writes:
> > 2. Simply decide on a constant 2/2/36 fanout.
>
> I thought it was Gitney who suggested to use a top-level fan-out based on
> the committer-date. If you typically have already parsed the commit when
> you want to look up notes objects for it, it won't have extra overhead,
> and when looking at only recent history it will only need to access a
> small subset of trees. I thought it was a neat idea (except that the
> question becomes what the granularity of the top level fan-out should
> be---one a day? one a month?---the optimum would depend on commit
> density). Was that idea shot down for some reason?
Yea, it was me. I still think it might be a useful idea, since
it allows you better density of loading notes when parsing the
recent commits. In theory the last 256 commits can easly be in
each of the 2/ fanout buckets, making 2/38 pointless for reducing
the search space. Commit date on the other hand can probably force
all of them into the same bucket, making it easy to have the last
256 commits in cache, from a single bucket.
But I thought you shot it down, by saying that we also wanted to
support notes on blobs. I happen to see no value in a note on
a blob, a blob alone doesn't make much sense without at least an
annotated tag or commit to provide it some named context, and the
latter two have dates.
--
Shawn.
^ permalink raw reply
* Re: Question regarding git fetch
From: Junio C Hamano @ 2009-08-27 21:20 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Tom Lambda, git
In-Reply-To: <32541b130908270836m50553ccatddf4c870eec54ddb@mail.gmail.com>
Avery Pennarun <apenwarr@gmail.com> writes:
> On Thu, Aug 27, 2009 at 3:30 PM, Tom Lambda<tom.lambda@gmail.com> wrote:
>> What was a little bit surprising to me is that running "git fetch central
>> master" does not update refs/remotes/central/master but simply updates
>> FETCH_HEAD.
>
> I've often wanted this myself, especially when doing things like "git
> pull origin master". However, I know the current behaviour is also
> useful sometimes, and changing it would introduce an unexpected side
> effect. Git currently promises that your refs/remotes/* branches will
> never be updated unless you explicitly request it, even if you're
> fetching, merging, and pulling other stuff. This means you can write
> scripts to do complicated things without triggering unexpected
> user-visible side effects.
I think it is reasonable, in 1.7.0, to change "git fetch" with command
line refspacs that lack colon (i.e. saying "fetch this ref" without saying
"and store it here") so that it updates remote tracking refs if and only
if an appropriate remote.$remote.fetch is configured to do so. E.g. when
I fetch from Eric for git-svn updates with
$ git pull git-svn master
because I do have
[remote "git-svn"]
url = git://yhbt.net/git-svn
fetch = +refs/heads/*:refs/remotes/git-svn/*
defined, it is Ok to update refs/remotes/git-svn/master (but not others).
On the other hand, if my refspecs for "git svn" _were_ like this:
[remote "git-svn"]
url = git://yhbt.net/git-svn
fetch = +refs/heads/master:refs/remotes/git-svn/master
then I would _not_ want this:
$ git fetch git-svn dev
to create a new tracking branch refs/remotes/git-svn/dev.
It used to be that the only way to check the progress of other people
were to do this:
$ git fetch git-svn master
$ git log git-svn/master..FETCH_HEAD
But these days, even if we changed the "git fetch" semantics, we can still
rely on reflogs to do the equivalent with:
$ git fetch git-svn
$ git log git-svn/master@{1}..git-svn/master
In other words, I think the "feature" that an explicit "fetch but do not
store this time" request to prevent "git fetch" from updating the tracking
branches outlived its usefulness.
^ permalink raw reply
* Re: Git woes
From: Alex Riesen @ 2009-08-27 21:14 UTC (permalink / raw)
To: Nico Weber; +Cc: git
In-Reply-To: <ca36ec440908271406t214fee11hed2c5e6da0e5ac0@mail.gmail.com>
On Thu, Aug 27, 2009 at 23:06, Nico Weber<thakis@chromium.org> wrote:
> Hi git list,
>
> Alex Riesen asked me to forward this to this list.
>
Thank you! It is appreciated.
>
> If it happens again, I'll post a dtrace to this list.
>
Yes, this would be very useful.
^ permalink raw reply
* Re: Git woes
From: Nico Weber @ 2009-08-27 21:06 UTC (permalink / raw)
To: Alex Riesen, git
In-Reply-To: <f4f35435-79b7-46c2-8c2d-2d4c4deb68c4@s15g2000yqs.googlegroups.com>
Hi git list,
Alex Riesen asked me to forward this to this list.
On Thu, Aug 27, 2009 at 1:52 PM, Alex Riesen<raa.lkml@gmail.com> wrote:
> On Aug 27, 7:42 am, Nico Weber <tha...@chromium.org> wrote:
>> Trying to pull:
>>
>> thakis-macbookpro:~/src/chrome-git/src thakis$ git pull
>> remote: Counting objects: 1859, done.
>> remote: Compressing objects: 100% (1267/1267), done.
>> remote: Total 1393 (delta 1087), reused 195 (delta 107)
>> Receiving objects: 100% (1393/1393), 2.57 MiB | 781 KiB/s, done.
>> fatal: cannot pread pack file: No such file or directory
>> fatal: index-pack failed
>
> You're on MacOSX, right? What version of git are you running?
> Where do you pull from? (So it can be reproduced)
>
> If you can provide this information, then maybe send it to the
> Git mailing list (git@vger.kernel.org, no subscription required),
> or at least back to me? Maybe you can strace (is it possible
> on MacOSX?) the "git pull" (because pread never returns
> ENOENT) and attach the trace as well?
>
> Sorry for asking you off-list, but I noticed your problem
> really accidentally (by browsing the list's archives), and
> not sure I am prepared to deal with the list's traffic.
>
Yes, I'm on OS X 10.5.8.
I'm pulling from git://git.chromium.org/chromium.git. This worked fine
for the last month or so, I had the problem for the first time
yesterday evening.
$ git --version
git version 1.6.0.2
Sadly, I fixed the problem accidentally by running something like
rm -rf .git/svn/
git svn fetch; git merge trunk
git merge refs/remotes/origin/trunk
git checkout -f HEAD
git pull
(if that looks like I don't know what I'm doing, you're right)
If it happens again, I'll post a dtrace to this list.
Nico
^ permalink raw reply
* Re: [PATCHv4 08/12] Teach the notes lookup code to parse notes trees with various fanout schemes
From: Junio C Hamano @ 2009-08-27 20:58 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Johan Herland, git, trast, tavestbo, git, chriscool, spearce
In-Reply-To: <alpine.DEB.1.00.0908271243120.7562@intel-tinevez-2-302>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> I half-agree, the code should decide which fanout scheme to use, but
> _only_ when producing new notes.
>
> I imagine that it could merge the existing notes, and try to make sure
> that there are no more blobs in a given subtree than a certain threshold;
> if that threshold is reached, it could fan-out using 2-digit subtrees,
> merging what needs merging (by concatenation) along the way.
>
> The natural precedence of shallower paths/longer basenames should cope
> well with that (i.e. prefer to show abcd/... over ab/cd/...).
Oh, if the plan for merging the trees is such that it takes care of
"multiple notes pointing at the same commit" issues like you outline, then
I can see it would work nicely.
At that point, fan-out would become merely an implementation detail,
something the end user never needs to worry about, just like what base
object is chosen to represent another object in a packfile.
^ permalink raw reply
* Re: [PATCHv4 08/12] Teach the notes lookup code to parse notes trees with various fanout schemes
From: Junio C Hamano @ 2009-08-27 20:55 UTC (permalink / raw)
To: Johan Herland
Cc: git, Johannes.Schindelin, trast, tavestbo, git, chriscool,
spearce
In-Reply-To: <200908271135.31794.johan@herland.net>
Johan Herland <johan@herland.net> writes:
> 2. Simply decide on a constant 2/2/36 fanout. For the case with < 256K
> notes, this is somewhat wasteful, but not prohibitively expensive. For the
> case with > 64M notes, performance will start to degrade. The big advantage
> with this approach is that when this is hardcoded into the notes code, we
> have regained the property that notes for a given commit have exactly _one_
> unique position in the notes tree across all installations (enabling us to
> fall back on the regular merge strategy).
I thought it was Gitney who suggested to use a top-level fan-out based on
the committer-date. If you typically have already parsed the commit when
you want to look up notes objects for it, it won't have extra overhead,
and when looking at only recent history it will only need to access a
small subset of trees. I thought it was a neat idea (except that the
question becomes what the granularity of the top level fan-out should
be---one a day? one a month?---the optimum would depend on commit
density). Was that idea shot down for some reason?
^ permalink raw reply
* Re: Using git to track my PhD thesis, couple of questions
From: Matthieu Moy @ 2009-08-27 20:55 UTC (permalink / raw)
To: seanh; +Cc: git
In-Reply-To: <20090827203402.GC7168@kisimul>
seanh <seanh.nospam@gmail.com> writes:
> I'm planning to use git to track my PhD thesis as I work on it and to
> let my supervisors track it. I've setup a git repository and a gitweb
> instance showing it. There are a couple of specific requirements.
>
> 1. My supervisors don't want to see all the little commits that I make
> day by day.
I'm not sure I understand why you want that. From what you say, your
supervisors won't be looking at the LaTeX source, so they won't read
the diffs for the commits. Instead, they will be looking at regular
snapshots in PDF. So, how is that disturbing to keep the intermediate
commits ?
> So I'll commit to a dev branch, then whenever I've made
> significant progress will merge it into a trunk branch. I want the trunk
> branch to get all the changes but as one big commit, not inherit all the
> little commits like a normal merge would do. I think this is a `git
> merge --squash`.
It is, but this also means _you_ will somehow lose your intermediate
commits. Well, you may not really lose them, but after a merge
--squash, you have two options to continue working: work on top of the
squashed commit (and then your ancestry doesn't contain the small
ones), or work on top of your previous branches (and then, you don't
have a proper merge tracking, and you'll get spurious conflicts if you
try another merge --squash).
> 2. They don't want to look at the latex source but the PDFs built from
> it, which they're going to annotate with their comments. So I need an
> easy way for them to get the PDF of each commit from gitweb without
> having to checkout the repo and build it themselves.
Well, they never need a PDF other than the latest version, will they?
Then, you don't need Git to send them your PDFs, just upload the PDFs
somewhere where your supervisors can grab them periodically, and
you're done.
The issue is when they start modifying the LaTeX files: then you have
to think of merging, and you'd better do that with a revision control
system.
I also used a revision control system to write my Ph.D (Git was born
after I started writting, so it wasn't Git yet), and my reviewing
system has been all the more simple: when a chapter is done, send an
email with the PDF attached, and "Hi, chapter $n is done, can you have
a look?". That just works.
> Normally I wouldn't commit the PDF files into the repo because
> they're compiled files not source files, but it seems that just
> building a PDF and committing it along with each commit to trunk
> would be by far the easiest way to achieve this. But will git store
> the PDFs efficiently, or will the repo start to get really big?
Git will do delta-compression as it can, but I don't think PDFs will
delta-compress very well, so your repository may grow rather quickly,
yes. If possible, commit the PDFs on a separate branch so that you can
easily keep your clean history small in disk space, and discard the
PDFs if needed.
--
Matthieu
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox