* What's cooking in git.git (Jan 2012, #01; Thu, 5)
From: Junio C Hamano @ 2012-01-05 21:55 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' (proposed updates) while commits prefixed with '+' are in
'next'.
I'll be tagging 1.7.9-rc0 after merging a few topics to "master" to make
it feature complete for the upcoming release tomorrow.
Here are the repositories that have my integration branches:
With maint, master, next, pu, todo:
git://git.kernel.org/pub/scm/git/git.git
git://repo.or.cz/alt-git.git
https://code.google.com/p/git-core/
https://github.com/git/git
With only maint and master:
git://git.sourceforge.jp/gitroot/git-core/git.git
git://git-core.git.sourceforge.net/gitroot/git-core/git-core
With all the topics and integration branches:
https://github.com/gitster/git
The preformatted documentation in HTML and man format are found in:
git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
git://repo.or.cz/git-{htmldocs,manpages}.git/
https://code.google.com/p/git-{htmldocs,manpages}.git/
https://github.com/gitster/git-{htmldocs,manpages}.git/
--------------------------------------------------
[New Topics]
* ss/git-svn-prompt-sans-terminal (2012-01-04) 3 commits
- fixup! 15eaaf4
- git-svn, perl/Git.pm: extend Git::prompt helper for querying users
(merged to 'next' on 2012-01-05 at 954f125)
+ perl/Git.pm: "prompt" helper to honor GIT_ASKPASS and SSH_ASKPASS
The bottom one has been replaced with a rewrite based on comments from
Ævar. The second one needs more work, both in perl/Git.pm and prompt.c, to
give precedence to tty over SSH_ASKPASS when terminal is available.
I think it is OK to include the first one in the upcoming release, but we
may want to wait and defer both to the next cycle.
* pw/p4-view-updates (2012-01-03) 6 commits
(merged to 'next' on 2012-01-03 at c3b5872)
+ git-p4: view spec documentation
+ git-p4: rewrite view handling
+ git-p4: support single file p4 client view maps
+ git-p4: sort client views by reverse View number
+ git-p4: fix test for unsupported P4 Client Views
+ git-p4: test client view handling
Will merge to 'master' by 1.7.9 final.
Unless real git-p4 users object (I am not one of them, so I cannot really
judge), that is.
* cb/git-daemon-tests (2012-01-04) 1 commit
(merged to 'next' on 2012-01-05 at 86f3e93)
+ daemon: add tests
It stirred a related discussion on how the process termination should be
handled in the daemon, but the test queued should be OK as-is on systems
that have "pkill" (which is outside POSIX).
* jc/show-sig (2012-01-05) 6 commits
(merged to 'next' on 2012-01-05 at 5da3ae2)
+ log --show-signature: reword the common two-head merge case
+ log-tree: show mergetag in log --show-signature output
+ log-tree.c: small refactor in show_signature()
+ commit --amend -S: strip existing gpgsig headers
+ verify_signed_buffer: fix stale comment
+ Merge branch 'jc/signed-commit' and 'jc/pull-signed-tag'
(this branch uses jc/signed-commit.)
Finishing touches to the already graduated "pull signed tags" topic.
Will merge to 'master' by 1.7.9 final.
* jm/stash-diff-disambiguate (2012-01-01) 1 commit
(merged to 'next' on 2012-01-05 at 75a283b)
+ stash: Don't fail if work dir contains file named 'HEAD'
Will merge to 'master' by 1.7.9 final.
* mm/maint-gitweb-project-maxdepth (2012-01-04) 1 commit
- gitweb: accept trailing "/" in $project_list
Looked quite sensible.
Will merge to 'master' by 1.7.9 final.
* nd/shallow-clone-without-tag-following (2012-01-05) 1 commit
- Limit refs to fetch to minimum in shallow clones
Needs adjustment of t5500 at least, and possibly an option to ask for the
traditional "shallowly clone all branches" behaviour.
* jk/parse-object-cached (2012-01-05) 1 commit
- parse_object: try internal cache before reading object db
This is a bit scary change, but I do not think of a way it would break
anything that is currently working correctly.
* jn/maint-gitweb-grep-fix (2012-01-05) 2 commits
- gitweb: Harden "grep" search against filenames with ':'
- gitweb: Fix file links in "grep" search
Waiting for a confirmation from bug reporter.
--------------------------------------------------
[Graduated to "master"]
* jv/maint-config-set (2011-12-27) 1 commit
(merged to 'next' on 2011-12-27 at 551ac8f)
+ Fix an incorrect reference to --set-all.
* pw/p4-docs-and-tests (2011-12-27) 11 commits
(merged to 'next' on 2011-12-28 at 8acf26e)
+ git-p4: document and test submit options
+ git-p4: test and document --use-client-spec
+ git-p4: test --keep-path
+ git-p4: test --max-changes
+ git-p4: document and test --import-local
+ git-p4: honor --changesfile option and test
+ git-p4: document and test clone --branch
+ git-p4: test cloning with two dirs, clarify doc
+ git-p4: clone does not use --git-dir
+ git-p4: introduce asciidoc documentation
+ rename git-p4 tests
--------------------------------------------------
[Stalled]
* bw/maint-t8006-sed-incomplete-line (2012-01-03) 1 commit
- Work around sed portability issue in t8006-blame-textconv
Waiting for a clarification of the reasoning in the log message.
* nd/index-pack-no-recurse (2011-12-27) 4 commits
- fixup! 3413d4d
- index-pack: eliminate unlimited recursion in get_delta_base()
- index-pack: eliminate recursion in find_unresolved_deltas
- Eliminate recursion in setting/clearing marks in commit list
Expecting a reroll.
* jc/advise-push-default (2011-12-18) 1 commit
- push: hint to use push.default=upstream when appropriate
Peff had a good suggestion outlining an updated code structure so that
somebody new can try to dip his or her toes in the development. Any
takers?
Waiting for a reroll.
* mh/ref-api-rest (2011-12-12) 35 commits
- repack_without_ref(): call clear_packed_ref_cache()
- read_packed_refs(): keep track of the directory being worked in
- is_refname_available(): query only possibly-conflicting references
- refs: read loose references lazily
- read_loose_refs(): take a (ref_entry *) as argument
- struct ref_dir: store a reference to the enclosing ref_cache
- sort_ref_dir(): take (ref_entry *) instead of (ref_dir *)
- do_for_each_ref_in_dir*(): take (ref_entry *) instead of (ref_dir *)
- add_entry(): take (ref_entry *) instead of (ref_dir *)
- search_ref_dir(): take (ref_entry *) instead of (ref_dir *)
- find_containing_direntry(): use (ref_entry *) instead of (ref_dir *)
- add_ref(): take (ref_entry *) instead of (ref_dir *)
- read_packed_refs(): take (ref_entry *) instead of (ref_dir *)
- find_ref(): take (ref_entry *) instead of (ref_dir *)
- is_refname_available(): take (ref_entry *) instead of (ref_dir *)
- get_loose_refs(): return (ref_entry *) instead of (ref_dir *)
- get_packed_refs(): return (ref_entry *) instead of (ref_dir *)
- refs: wrap top-level ref_dirs in ref_entries
- get_ref_dir(): keep track of the current ref_dir
- do_for_each_ref(): only iterate over the subtree that was requested
- refs: sort ref_dirs lazily
- sort_ref_dir(): do not sort if already sorted
- refs: store references hierarchically
- refs.c: rename ref_array -> ref_dir
- struct ref_entry: nest the value part in a union
- check_refname_component(): return 0 for zero-length components
- free_ref_entry(): new function
- refs.c: reorder definitions more logically
- is_refname_available(): reimplement using do_for_each_ref_in_array()
- names_conflict(): simplify implementation
- names_conflict(): new function, extracted from is_refname_available()
- repack_without_ref(): reimplement using do_for_each_ref_in_array()
- do_for_each_ref_in_arrays(): new function
- do_for_each_ref_in_array(): new function
- do_for_each_ref(): correctly terminate while processesing extra_refs
The API for extra anchoring points may require rethought first; that would
hopefully make the "ref" part a lot simpler.
Waiting for a reroll.
* jc/split-blob (2011-12-01) 6 commits
. WIP (streaming chunked)
- chunked-object: fallback checkout codepaths
- bulk-checkin: support chunked-object encoding
- bulk-checkin: allow the same data to be multiply hashed
- new representation types in the packstream
- varint-in-pack: refactor varint encoding/decoding
Not ready.
At least pack-objects and fsck need to learn the new encoding for the
series to be usable locally, and then index-pack/unpack-objects needs to
learn it to be used remotely.
* jc/advise-i18n (2011-12-22) 1 commit
- i18n of multi-line advice messages
Allow localization of advice messages that tend to be longer and
multi-line formatted. For now this is deliberately limited to advise()
interface and not vreportf() in general as touching the latter has
interactions with error() that has plumbing callers whose prefix "error: "
should never be translated.
--------------------------------------------------
[Cooking]
* jh/fetch-head-update (2012-01-03) 1 commit
(merged to 'next' on 2012-01-04 at b5778e1)
+ write first for-merge ref to FETCH_HEAD first
Will merge to 'master' by 1.7.9 final.
* jc/signed-commit (2011-11-29) 5 commits
(merged to 'next' on 2011-12-21 at 8fcbf00)
+ gpg-interface: allow use of a custom GPG binary
+ pretty: %G[?GS] placeholders
+ test "commit -S" and "log --show-signature"
+ log: --show-signature
+ commit: teach --gpg-sign option
(this branch is used by jc/show-sig.)
The infrastructure this series adds is used by the finishing touches to
the earlier "pull signed tags" topic, so this will graduate to "master"
together with it when the latter matures, hopefully before 1.7.9 final.
--------------------------------------------------
[Discarded]
* ss/git-svn-askpass (2011-12-27) 5 commits
- make askpass_prompt a global prompt method for asking users
- ignore empty *_ASKPASS variables
- honour *_ASKPASS for querying username and for querying further actions like unknown certificates
- switch to central prompt method
- add central method for prompting a user using GIT_ASKPASS or SSH_ASKPASS
This has become more about "prompt without terminal", and was rerolled
into a two-patch series, which is structured a lot nicer than this
original.
^ permalink raw reply
* Re: [PATCH] parse_object: try internal cache before reading object db
From: Jeff King @ 2012-01-05 22:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, git-dev
In-Reply-To: <7vehvdn7at.fsf@alter.siamese.dyndns.org>
On Thu, Jan 05, 2012 at 01:55:22PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > The worst potential problem I could come up with is if you somehow had
> > an object whose "parsed" flag was set, but somehow didn't have its other
> > fields set (like type).
> > ...
> > So I think it is safe short of somebody doing some horrible manual
> > munging of a "struct object".
>
> Yeah, I was worried about codepaths like commit-pretty-printing might be
> mucking with the contents of commit->buffer, perhaps reencoding the text
> and then calling parse_object() to get the unmodified original back, or
> something silly like that. But the lookup_object() call at the beginning
> of the parse_object() already prevents us from doing such a thing, so we
> should be OK, I would think.
Er, without my patch there is no such lookup_object, is there?
What saves you is that the parse_*_buffer functions all do nothing when
the object.parsed flag is set, and the code I added makes sure that
object.parsed is set in the object that lookup_object returns.
So yeah, anytime you tweak the contents of commit->buffer but don't
unset the "parsed" flag, you are asking for trouble.
Here's another possible code path where the behavior is changed:
1. You set the global save_commit_buffer to 0.
2. You call parse_commit(commit) on an unparsed commit object, which
does not save the commit buffer, but does set
commit->object.parsed.
3. You call parse_object(commit->object.sha1).
a. Without my patch, we read the file contents again, do _not_
re-parse them (because we look up the existing object and notice
that its "parsed" flag is set), but we _do_ assign the buffer to
commit->buffer.
b. With my patch, we see that there is an existing object that is
already parsed, and return early. commit->buffer remains NULL.
I would argue that this doesn't matter, since "parse_commit" uses the
exact same optimization (it returns early without setting commit->buffer
if the parsed flag is set). So any program turning off
save_commit_buffer has to be ready to deal with a NULL commit->buffer in
the first place. The only exception would be a program that then tries
to fill in the commit->buffer field by manually running parse_object on
an already-parsed, buffer-less commit object. I don't think we do that.
You can verify that commit->buffer is the only place where these issues
can happen by following the logic in parse_object_buffer.
Sorry to belabor the discussion, but this is such a core piece of code,
I want to make sure the optimization isn't hurting anybody (I don't
think it is, and certainly the tests are all happy, but I think talking
through the cases is a good thing).
-Peff
^ permalink raw reply
* Re: git-subtree
From: David A. Greene @ 2012-01-05 22:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Greene, git
In-Reply-To: <7vboqino1r.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> David Greene <dag@cray.com> writes:
>
>> How does the git community want the patch presented? Right now it's one
>> monolithic thing. I understand that isn't ideal but I don't think
>> incorporating the entire GitHub master history is necessarily the best
>> idea either.
>
> It depends on the longer term vision of how the result of this submission
> will evolve and more importantly, where you fit in the piture.
This is a very fair question. I'll try to answer it as best I can. I
think it mostly jibes with your suggested possible answer.
I've been using git-subtree for about six months now and as an
enthusiastic user who wants to introduce this too into my daily
corporate work environment, I'd like to see it incorporated as an
officially-supported git tool to make that introduction easier.
So my intention is to make git-subtree an integral part of the core git
suite and take on further maintenance and development along with Avery
and the other git-subtree developers.
I have not previously been a contributor to git-subtree and don't know
the code at all but I am a quick learner. The actual git-subtree code
itself is not overwhelmingly large and strikes me as a tractable
learning project.
I approached Avery about submitting git-subtree to become part of the
core git suite. He responded positively but indicated he does not have
the cycles to do it at this time. He asked whether I could take on the
job and I agreed.
He mentioned that he'd talked to some developers at GitTogether and got
a positive reponse there. I don't know whether you were part of those
discussions. My impression is that the GitTogether discussions went
well and there was general agreement that git-subtree would be a
valuable addition to the core git suite.
I am perfectly happy to put this in contrib/ first if it eases the
introduction. I would like to move it to the subcommand area after
getting everything in tip-top shape. What I don't want is for it to
languish forever in contrib/. That means I'll need some guideline of
the changes/standards necessary to qualify it for transition from
contrib/ to an official subcommand. I expect we'll develop that as we
go along but I hope the git community has some institutional knowledge
gathered from previous experience.
I have asked Avery how he wants to do maintenance going forward. I
haven't heard back from him yet so I can't speak to whether the existing
GitHub project will continue or not. I'll pass along his thoughts when
I get them.
> Your answer might differ, of course, but the point is that we would need
> to weigh pros and cons between inclusion of it in the git repository and
> keeping it in Avery's repository and have him and his contributors
> maintain, enhance and distribute it from there, and it largely depends on
> the nature of the submission. Is it a "throw it over the wall" dump of a
> large code of unknown quality that we need to clean up first without
> knowing the vision of how "git subtree" should evolve by original author
> and/or people who have been actively developing it?
I certainly don't want this to be an "over the wall" operation. I
intend to participate in maintenance of git-subtree in the official git
repository.
So I'll go ahead and work on adding this to contrib/. Once I get a
response from Avery about his long-term vision I'll pass that along and
we can have further discussion. I may start sending patches to the
mailing list for review before hearing back from him, however.
Sound good?
-Dave
^ permalink raw reply
* Re: git-subtree
From: David A. Greene @ 2012-01-05 22:18 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: David Greene, git, Junio C Hamano
In-Reply-To: <CALkWK0k+AwCsizZFwbKKxuz0B4xLoyC4hAy3WRD=sLCq-HvvCw@mail.gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> Hi again,
>
> [+CC: Junio Hamano, our maintainer]
>
> David A. Greene wrote:
>> I've read that document. The issue is that I didn't develop the code,
>> Avery did.
>
> Not an issue as long as you have Avery's signoff.
As in a signed-off-by log entry on the commit? I did a commit -s to add
my own signed-off-by tag and added a "From:" line in accordance with the
SubmittingPatches document:
"If you are forwarding a patch from somebody else, optionally, at the
beginning of the e-mail message just before the commit message starts,
you can put a "From: " line to name that person."
I have not used signoffs before in my day-to-day git flow. How do I go
about getting one from Avery and incorporating it into the history in an
autheticated way? I'm assuming you don't want me to forge his sign-off.
:)
>> It's a lot of time to learn a completely new codebase. I was hoping
>> to submit something soon and then learn the codebase gradually during
>> maintenance/further development.
>
> We certainly don't want badly reviewed code that nobody understands
> floating around in the codebase
Certainly, I'm not trying to avoid review, just trying to figure out the
most efficient mechanics.
> so, I'd suggest sending out whatever you think is appropriate for the
> first round of reviews, and see how things shape up from there.
Fair enough. I think I will take Jeff's suggested route and see where
that goes.
>> How have completely new tools be introduced into the git mainline in the
>> past?
>
> Yes. For an example of something I was involved with but didn't
> author, see vcs-svn/.
Ok, I'll look into that. Thanks for the pointer.
-Dave
^ permalink raw reply
* Re: git-subtree
From: David A. Greene @ 2012-01-05 16:33 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: David Greene, git, Junio C Hamano
In-Reply-To: <CALkWK0k+AwCsizZFwbKKxuz0B4xLoyC4hAy3WRD=sLCq-HvvCw@mail.gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> Hi again,
>
> [+CC: Junio Hamano, our maintainer]
>
> David A. Greene wrote:
>> I've read that document. The issue is that I didn't develop the code,
>> Avery did.
>
> Not an issue as long as you have Avery's signoff.
As in a signed-off-by log entry on the commit? I did a commit -s to add
my own signed-off-by tag and added a "From:" line in accordance with the
SubmittingPatches document:
"If you are forwarding a patch from somebody else, optionally, at the
beginning of the e-mail message just before the commit message starts,
you can put a "From: " line to name that person."
I have not used signoffs before in my day-to-day git flow. How do I go
about getting one from Avery and incorporating it into the history in an
autheticated way? I'm assuming you don't want me to forge his sign-off.
:)
>> It's a lot of time to learn a
>> completely new codebase. I was hoping to submit something soon and then
>> learn the codebase gradually during maintenance/further development.
>
> We certainly don't want badly reviewed code that nobody understands
> floating around in the codebase-
Certainly, I'm not trying to avoid review, just trying to figure out the
most efficient mechanics.
> so, I'd suggest sending out whatever you think is appropriate for the
> first round of reviews, and see how things shape up from there.
Fair enough. I think I will take Jeff's suggested route and see where
that goes.
>> How have completely new tools be introduced into the git mainline in the
>> past?
>
> Yes. For an example of something I was involved with but didn't
> author, see vcs-svn/.
Ok, I'll look into that. Thanks for the pointer.
-Dave
^ permalink raw reply
* Re: git-subtree
From: David A. Greene @ 2012-01-05 16:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Greene, git
In-Reply-To: <7vboqino1r.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> David Greene <dag@cray.com> writes:
>
>> How does the git community want the patch presented? Right now it's one
>> monolithic thing. I understand that isn't ideal but I don't think
>> incorporating the entire GitHub master history is necessarily the best
>> idea either.
>
> It depends on the longer term vision of how the result of this submission
> will evolve and more importantly, where you fit in the piture.
This is a very fair question. I'll try to answer it as best I can. I
think it mostly jibes with your suggested possible answer.
I've been using git-subtree for about six months now and as an
enthusiastic user who wants to introduce this too into my daily
corporate work environment, I'd like to see it incorporated as an
officially-supported git tool to make that introduction easier.
So my intention is to make git-subtree an integral part of the core git
suite and take on further maintenance and development along with Avery
and the other git-subtree developers.
I have not previously been a contributor to git-subtree and don't know
the code at all but I am a quick learner. The actual git-subtree code
itself is not overwhelmingly large and strikes me as a tractable
learning project.
I approached Avery about submitting git-subtree to become part of the
core git suite. He responded positively but indicated he does not have
the cycles to do it at this time. He asked whether I could take on the
job and I agreed.
He mentioned that he'd talked to some developers at GitTogether and got
a positive reponse there. I don't know whether you were part of those
discussions. My impression is that the GitTogether discussions went
well and there was general agreement that git-subtree would be a
valuable addition to the core git suite.
I am perfectly happy to put this in contrib/ first if it eases the
introduction. I would like to move it to the subcommand area after
getting everything in tip-top shape. What I don't want is for it to
languish forever in contrib/. That means I'll need some guideline of
the changes/standards necessary to qualify it for transition from
contrib/ to an official subcommand. I expect we'll develop that as we
go along but I hope the git community has some institutional knowledge
gathered from previous experience.
I have asked Avery how he wants to do maintenance going forward. I
haven't heard back from him yet so I can't speak to whether the existing
GitHub project will continue or not. I'll pass along his thoughts when
I get them.
> Your answer might differ, of course, but the point is that we would need
> to weigh pros and cons between inclusion of it in the git repository and
> keeping it in Avery's repository and have him and his contributors
> maintain, enhance and distribute it from there, and it largely depends on
> the nature of the submission. Is it a "throw it over the wall" dump of a
> large code of unknown quality that we need to clean up first without
> knowing the vision of how "git subtree" should evolve by original author
> and/or people who have been actively developing it?
I certainly don't want this to be an "over the wall" operation. I
intend to participate in maintenance of git-subtree in the official git
repository.
So I'll go ahead and work on adding this to contrib/. Once I get a
response from Avery about his long-term vision I'll pass that along and
we can have further discussion. I may start sending patches to the
mailing list for review before hearing back from him, however.
Sound good?
-Dave
^ permalink raw reply
* Re: git-subtree
From: David A. Greene @ 2012-01-05 16:26 UTC (permalink / raw)
To: Jeff King; +Cc: Ramkumar Ramachandra, David Greene, git
In-Reply-To: <20120105154740.GA11475@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I think this is also somewhat different in that git-subtree has a
> multi-year history in git that we may want to keep. So it is more
I agree there may be some value in preserving this history.
> The biggest decision is whether or not to import the existing history.
I agree. I will leave that decision to the more experienced git
developers. I'm happy to work either way.
> If we want to throw away the existing history, then I think you end up
> doing the same munging as the latter option above, and then just make a
> single patch out of it instead of a merge.
Right. That's the approach I've taken for now but it's easy to switch.
There aren't that many changes.
> I don't use git-subtree, but just glancing over the repo, it looks like
> that munging is mostly:
>
> 1. git-subtree.sh stays, and gets added to git.git's top-level Makefile
Done.
> 2. the test.sh script gets adapted into t/tXXXX-subtree.sh
Done.
> 3. git-subtree.txt goes into Documentation/
Done.
> 4. The rest of the files are infrastructure that can go away, as they
> are a subset of what git.git already contains.
Done.
I have a patch that does all of the above but it is one monolithic blob.
Like I said, the changes aren't extensive so it's easy for me to change
strategies.
> I'd favor keeping the history and doing the munge-overlay thing.
Ok, that sounds fine to me. I'll do that in a private branch. What
should I send as patches to the mailing list? I'm assuming we don't
want [PATCH 235/12342], etc. sent to the list chronicling the entire
history. :)
> Although part of me wants to join the histories in a subtree so that we
> can use "git subtree" to do it (which would just be cool),
Heh. I thought about that too. :)
> I think the resulting code layout doesn't make much sense unless
> git-subtree is going to be maintained separately.
Yeah, I agree.
-Dave
^ permalink raw reply
* Re: git-subtree
From: David A. Greene @ 2012-01-05 22:16 UTC (permalink / raw)
To: Jeff King; +Cc: Ramkumar Ramachandra, David Greene, git
In-Reply-To: <20120105154740.GA11475@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I think this is also somewhat different in that git-subtree has a
> multi-year history in git that we may want to keep. So it is more
I agree there may be some value in preserving this history.
> The biggest decision is whether or not to import the existing history.
I agree. I will leave that decision to the more experienced git
developers. I'm happy to work either way.
> If we want to throw away the existing history, then I think you end up
> doing the same munging as the latter option above, and then just make a
> single patch out of it instead of a merge.
Right. That's the approach I've taken for now but it's easy to switch.
There aren't that many changes.
> I don't use git-subtree, but just glancing over the repo, it looks like
> that munging is mostly:
>
> 1. git-subtree.sh stays, and gets added to git.git's top-level Makefile
Done.
> 2. the test.sh script gets adapted into t/tXXXX-subtree.sh
Done.
> 3. git-subtree.txt goes into Documentation/
Done.
> 4. The rest of the files are infrastructure that can go away, as they
> are a subset of what git.git already contains.
Done.
I have a patch that does all of the above but it is one monolithic blob.
Like I said, the changes aren't extensive so it's easy for me to change
strategies.
> I'd favor keeping the history and doing the munge-overlay thing.
Ok, that sounds fine to me. I'll do that in a private branch. What
should I send as patches to the mailing list? I'm assuming we don't
want [PATCH 235/12342], etc. sent to the list chronicling the entire
history. :)
> Although part of me wants to join the histories in a subtree so that we
> can use "git subtree" to do it (which would just be cool),
Heh. I thought about that too. :)
> I think the resulting code layout doesn't make much sense unless
> git-subtree is going to be maintained separately.
Yeah, I agree.
-Dave
^ permalink raw reply
* Re: [PATCH] Submodules always use a relative path to gitdir
From: Jens Lehmann @ 2012-01-05 22:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Antony Male, git, iveqy
In-Reply-To: <7vhb0csa6w.fsf@alter.siamese.dyndns.org>
Am 03.01.2012 23:17, schrieb Junio C Hamano:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>
>> Not if we would implement a "if no worktree is set but we came here via
>> a gitfile, then take the directory the gitfile was found in as worktree"
>> heuristic. And that heuristic looks quite sane to me, as a gitfile can
>> only be found in a work tree, or am I missing something obvious here?
>
> Like it wouldn't work without changes to the core side?
I totally agree that when just talking about being able to move the
superproject around that approach is more invasive than just adding
a relative core.worktree setting and is just not worth the hassle.
But I was also thinking about moving the submodule around inside the
superproject. Until the gitfile was used that meant just mv'ing the
submodule and changing the path in .gitmodules accordingly. Now you
also have to adjust the core.worktree setting and maybe also the
gitfile content (if you move the submodule out of the directory level
it lived in before).
One solution I can think of is to teach "git mv" about submodules and
let it do the necessary changes to .gitmodules (which seems to be a
good idea anyways), core.worktree and the gitfile. The manipulation of
core.worktree could be obsoleted by not using that setting but instead
implementing the heuristic I described above. And if the gitfile could
be taught somehow that a path in there is relative to the superprojects
root directory, then it would never have to be changed either, restoring
the behavior we had before introducing the gitfile.
So in the long run I suspect we might have to change core git anyways
to make moving submodules easy for the user (surely "git mv" and maybe
also the setup and gitfile code). Does that make more sense?
If not I'm fine with just setting core.worktree to a relative path in
the git-submodule.sh script (like I did for the gitfile). And I'll look
into teaching "git mv" about submodules right after that.
^ permalink raw reply
* Re: [PATCH] Submodules always use a relative path to gitdir
From: Junio C Hamano @ 2012-01-06 0:11 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Antony Male, git, iveqy
In-Reply-To: <4F0629C6.9010908@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> So in the long run I suspect we might have to change core git anyways
> to make moving submodules easy for the user (surely "git mv" and maybe
> also the setup and gitfile code). Does that make more sense?
If you need to change "git mv" anyway to help moving submodule checkout,
then how gitfile points into .git/modules/ hierarchy of the superproject
becomes an implementation detail the end users should not have to care
about.
What does "if we reached thru a gitfile, then the working tree is where
you found that gitfile" really solve? The way you found that gitfile is by
traversing the directory hierarchy upwards from a subdirectory of a
working tree of a submodule, and you already know where the top of that
working tree is, no?
And the heuristics would not work if somebody goes into the $GIT_DIR/ that
governs the submodule as going upwards from there will not hit gitfile, so
we would need help from core.worktree anyway. A non-submodule setting that
uses gitfile would need to worry about core.worktree, too, so I'd rather
avoid loading more heuristics to gitfile handling unless there is a clear
advantage for doing so, which I am not really seeing here.
That is not really a "If not" below (i.e. I am not saying it is _not_ OK.
I am saying I don't know what the advantage of that approach is), but ...
> If not I'm fine with just setting core.worktree to a relative path in
> the git-submodule.sh script (like I did for the gitfile). And I'll look
> into teaching "git mv" about submodules right after that.
... teaching "git mv" may be a good move, I would think. I do think keeping
core.worktree pointing at the right directory is necessary, but I do not
see much point in making it a relative path, though.
^ permalink raw reply
* Re: git-subtree
From: David A. Greene @ 2012-01-06 1:53 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: David Greene, git, Junio C Hamano
In-Reply-To: <87sjjuyur3.fsf@smith.obbligato.org>
greened@obbligato.org (David A. Greene) writes:
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>
>> Hi again,
>>
>> [+CC: Junio Hamano, our maintainer]
>>
>> David A. Greene wrote:
>>> I've read that document. The issue is that I didn't develop the code,
>>> Avery did.
>>
>> Not an issue as long as you have Avery's signoff.
Argh. Sorry about all the duplicate replies. I got delivery bounces on
all of them. Must have been a stuck queue or something. So again,
apologies for the noise.
-Dave
^ permalink raw reply
* Re: [PATCH 1/2] daemon: add tests
From: Brian Gernhardt @ 2012-01-06 6:17 UTC (permalink / raw)
To: Clemens Buchacher
Cc: Junio C Hamano, git, Jonathan Nieder, Jeff King, Erik Faye-Lund,
Ilari Liusvaara, Nguyễn Thái Ngọc Duy
In-Reply-To: <1325692539-26748-1-git-send-email-drizzd@aon.at>
On Jan 4, 2012, at 10:55 AM, Clemens Buchacher wrote:
> On Tue, Jan 03, 2012 at 11:34:08AM -0800, Junio C Hamano wrote:
>>> + # kill git-daemon child of git
>>> + say >&3 "Stopping git daemon ..."
>>> + pkill -P "$DAEMON_PID"
>>
>> How portable is this one (I usually do not trust use of pkill anywhere)?
>
> I read that it is supposed to be more portable than skill or killall.
> But I have no way to research this. I have implemented a workaround
> using only 'ps' and 'kill' in [PATCH 3/6] avoid use of pkill.
As a data point: pkill and skill do not exist on OS X 10.7, but killall does.
~~ Brian Gernhardt
^ permalink raw reply
* [PATCH v3] Limit refs to fetch to minimum in shallow clones
From: Nguyễn Thái Ngọc Duy @ 2012-01-06 7:11 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Shawn O. Pearce,
Nguyễn Thái Ngọc Duy
In-Reply-To: <1325743516-14940-1-git-send-email-pclouds@gmail.com>
The main purpose of shallow clones is to reduce download by only
fetching objects up to a certain depth from the given refs. The number
of objects depend on how many refs to follow. So:
- Only fetch HEAD or the ref specified by --branch
- Only fetch tags that reference to downloaded objects
More tags/branches can be fetched later using git-fetch as usual.
The old behaviour can still be called with --no-single-branch
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
- add --no-single-branch so t5500 works without big changes.
- die() if we cannot find suitable branch to fetch (and suggest --no-single-branch)
- and a bit more tests to exercise new code
--branch=<tag> (or something similar) has to wait until my other
patch gets in a good shape (or gets dropped)
There may be something slightly wrong with shallow code. I expect it
to fetch only 3 objects (1 commit, 1 tree, 1 blob) with --depth=1
in my new test but it fetches 6 (one more commit).
Documentation/git-clone.txt | 12 ++++++++-
builtin/clone.c | 54 ++++++++++++++++++++++++++++++++++++++----
t/t5500-fetch-pack.sh | 34 ++++++++++++++++++++++++++-
3 files changed, 92 insertions(+), 8 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 4b8b26b..58f21d6 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -13,7 +13,8 @@ SYNOPSIS
[-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror]
[-o <name>] [-b <name>] [-u <upload-pack>] [--reference <repository>]
[--separate-git-dir <git dir>]
- [--depth <depth>] [--recursive|--recurse-submodules] [--] <repository>
+ [--depth <depth> [--[no-]single-branch]]
+ [--recursive|--recurse-submodules] [--] <repository>
[<directory>]
DESCRIPTION
@@ -179,6 +180,15 @@ objects from the source repository into a pack in the cloned repository.
with a long history, and would want to send in fixes
as patches.
+--single-branch::
+--no-single-branch::
+ These options are only valid when --depth is given.
+ `--single-branch` only fetches one branch (either HEAD or
+ specified by --branch) and tags that point to the downloaded
+ history. `--no-single-branch` fetches all branches and tags
+ like in normal clones. `--single-branch` is implied by
+ default.
+
--recursive::
--recurse-submodules::
After the clone is created, initialize all submodules within,
diff --git a/builtin/clone.c b/builtin/clone.c
index efe8b6c..3424e1c 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -37,7 +37,7 @@ static const char * const builtin_clone_usage[] = {
NULL
};
-static int option_no_checkout, option_bare, option_mirror;
+static int option_no_checkout, option_bare, option_mirror, option_single_branch = 1;
static int option_local, option_no_hardlinks, option_shared, option_recursive;
static char *option_template, *option_depth;
static char *option_origin = NULL;
@@ -48,6 +48,7 @@ static int option_verbosity;
static int option_progress;
static struct string_list option_config;
static struct string_list option_reference;
+static const char *src_ref_prefix = "refs/heads/";
static int opt_parse_reference(const struct option *opt, const char *arg, int unset)
{
@@ -92,6 +93,8 @@ static struct option builtin_clone_options[] = {
"path to git-upload-pack on the remote"),
OPT_STRING(0, "depth", &option_depth, "depth",
"create a shallow clone of that depth"),
+ OPT_BOOL(0, "single-branch", &option_single_branch,
+ "do not limit fetched refs in shallow clones"),
OPT_STRING(0, "separate-git-dir", &real_git_dir, "gitdir",
"separate git dir from working tree"),
OPT_STRING_LIST('c', "config", &option_config, "key=value",
@@ -427,9 +430,29 @@ static struct ref *wanted_peer_refs(const struct ref *refs,
struct ref *local_refs = head;
struct ref **tail = head ? &head->next : &local_refs;
- get_fetch_map(refs, refspec, &tail, 0);
- if (!option_mirror)
- get_fetch_map(refs, tag_refspec, &tail, 0);
+ if (!(option_depth && option_single_branch)) {
+ get_fetch_map(refs, refspec, &tail, 0);
+ if (!option_mirror)
+ get_fetch_map(refs, tag_refspec, &tail, 0);
+ } else {
+ struct ref *remote_head = NULL;
+
+ if (!option_branch)
+ remote_head = guess_remote_head(head, refs, 0);
+ else {
+ struct strbuf sb = STRBUF_INIT;
+ strbuf_addstr(&sb, src_ref_prefix);
+ strbuf_addstr(&sb, option_branch);
+ remote_head = find_ref_by_name(refs, sb.buf);
+ strbuf_release(&sb);
+ }
+
+ if (!remote_head)
+ die(_("Remote branch \"%s\" not found. Nothing to clone.\n"
+ "Try --no-single-branch to fetch all refs."),
+ option_branch ? option_branch : "HEAD");
+ get_fetch_map(remote_head, refspec, &tail, 0);
+ }
return local_refs;
}
@@ -448,6 +471,21 @@ static void write_remote_refs(const struct ref *local_refs)
clear_extra_refs();
}
+static void write_followtags(const struct ref *refs, const char *msg)
+{
+ const struct ref *ref;
+ for (ref = refs; ref; ref = ref->next) {
+ if (prefixcmp(ref->name, "refs/tags/"))
+ continue;
+ if (!suffixcmp(ref->name, "^{}"))
+ continue;
+ if (!has_sha1_file(ref->old_sha1))
+ continue;
+ update_ref(msg, ref->name, ref->old_sha1,
+ NULL, 0, DIE_ON_ERR);
+ }
+}
+
static int write_one_config(const char *key, const char *value, void *data)
{
return git_config_set_multivar(key, value ? value : "true", "^$", 0);
@@ -478,7 +516,6 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
struct strbuf key = STRBUF_INIT, value = STRBUF_INIT;
struct strbuf branch_top = STRBUF_INIT, reflog_msg = STRBUF_INIT;
struct transport *transport = NULL;
- char *src_ref_prefix = "refs/heads/";
int err = 0;
struct refspec *refspec;
@@ -642,9 +679,12 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
transport_set_option(transport, TRANS_OPT_KEEP, "yes");
- if (option_depth)
+ if (option_depth) {
transport_set_option(transport, TRANS_OPT_DEPTH,
option_depth);
+ transport_set_option(transport, TRANS_OPT_FOLLOWTAGS,
+ option_single_branch ? "1" : NULL);
+ }
transport_set_verbosity(transport, option_verbosity, option_progress);
@@ -663,6 +703,8 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
clear_extra_refs();
write_remote_refs(mapped_refs);
+ if (option_depth && option_single_branch)
+ write_followtags(refs, reflog_msg.buf);
remote_head = find_ref_by_name(refs, "HEAD");
remote_head_points_at =
diff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh
index bafcca7..c76a53b 100755
--- a/t/t5500-fetch-pack.sh
+++ b/t/t5500-fetch-pack.sh
@@ -115,7 +115,7 @@ pull_to_client 2nd "B" $((64*3))
pull_to_client 3rd "A" $((1*3))
test_expect_success 'clone shallow' '
- git clone --depth 2 "file://$(pwd)/." shallow
+ git clone --no-single-branch --depth 2 "file://$(pwd)/." shallow
'
test_expect_success 'clone shallow object count' '
@@ -248,4 +248,36 @@ test_expect_success 'clone shallow object count' '
grep "^count: 52" count.shallow
'
+test_expect_success 'clone shallow without --no-single-branch' '
+ git clone --depth 1 "file://$(pwd)/." shallow2
+'
+
+test_expect_success 'clone shallow object count' '
+ (
+ cd shallow2 &&
+ git count-objects -v
+ ) > count.shallow2 &&
+ grep "^in-pack: 6" count.shallow2
+'
+
+test_expect_success 'shallow clone pulling tags' '
+ git tag -a -m A TAGA1 A &&
+ git tag -a -m B TAGB1 B &&
+ git tag TAGA2 A &&
+ git tag TAGB2 B &&
+ git clone --depth 1 "file://$(pwd)/." shallow3 &&
+
+ cat >taglist.expected <<\EOF &&
+TAGB1
+TAGB2
+EOF
+ GIT_DIR=shallow3/.git git tag -l >taglist.actual &&
+ test_cmp taglist.expected taglist.actual &&
+
+ echo "in-pack: 7" > count3.expected &&
+ GIT_DIR=shallow3/.git git count-objects -v |
+ grep "^in-pack" > count3.actual &&
+ test_cmp count3.expected count3.actual
+'
+
test_done
--
1.7.3.1.256.g2539c.dirty
^ permalink raw reply related
* Why usage function exit with code 129?
From: 徐迪 @ 2012-01-06 7:15 UTC (permalink / raw)
To: Git 邮件列表
I did like this:
$ git add --foo
$ echo $?
what I got is 129, should this code being used as program terminated
due to a signal? Cause it's 128+1. According to this[1].
[1] http://tldp.org/LDP/abs/html/exitcodes.html
^ permalink raw reply
* Re: Why usage function exit with code 129?
From: Nguyen Thai Ngoc Duy @ 2012-01-06 7:22 UTC (permalink / raw)
To: 徐迪; +Cc: Git 邮件列表
In-Reply-To: <CAMocUqSbiO2XC3PUEciyV3HxgqDPW_rTW-hYH4P=C=BFCSrQMQ@mail.gmail.com>
2012/1/6 徐迪 <xudifsd@gmail.com>:
> I did like this:
> $ git add --foo
> $ echo $?
> what I got is 129, should this code being used as program terminated
> due to a signal? Cause it's 128+1. According to this[1].
usage() (in your case) always returns 129, die() 128. See 5d1a5c0
([PATCH] Better error reporting for "git status")
> [1] http://tldp.org/LDP/abs/html/exitcodes.html
No it does not mean terminated by signals.
--
Duy
^ permalink raw reply
* Re: [PATCH] clone: allow detached checkout when --branch takes a tag
From: Nguyen Thai Ngoc Duy @ 2012-01-06 7:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7h16nmpy.fsf@alter.siamese.dyndns.org>
2012/1/5 Junio C Hamano <gitster@pobox.com>:
> Also, the user is likely to want to fetch and integrate from the origin
> with his own history. How should "git pull" and "git fetch" work in the
> resulting repository? What should the remote.origin.* look like?
fetch should behave the same regardless this patch. remote.origin.*
looks exactly the same. Branch tracking is not set up so pull works
half way.
> You clone a single lineage of the history, either shallowly or fully,
> either starting at the tip of one single branch or a named tag.
>
> What is the expected use scenario of a resulting repository of this new
> feature? As this is creating a repository, not a tarball extract, you
> certainly would want the user to build further history in the resulting
> repository, and it would need a real branch at some point, preferably
> before any new commit is made. Which makes me think that the only reason
> we would use a detached HEAD would be because we cannot decide what name
> to give to that single branch and make it the responsibility of the user
> to run "git checkout -b $whatever" as the first thing.
We can still commit with detached HEAD but I guess it's not
recommended. For a quick, throwaway repository, it's probably OK.
> I think the real cause of the above is because this patch and its previous
> companion patch conflate the meaning of the "--branch" option with the
> purpose of specifying which lineage of the history to copy. The option is
> described to name the local branch that is checked out, instead of using
> the the same name the remote's primary branch. But these patches abuse the
> option to name something different at the same time---the endpoint of the
> single lineage to be copied.
>
> These two may often be the same, and use of "clone --branch=master" in
> such a case would mean that you want to name the local branch of the final
> checkout to be "master" _and_ the endpoint of the single lineage you are
> copying is also their "master".
>
> But the "tag" extension proposed with this change is different.
>
> You are specifying an endpoint of the single lineage with the option that
> is different from any of the branches at the origin, and because you used
> the "--branch" option for that purpose, you lost the way to specify the
> primary thing the option wanted to express: what the name of the resulting
> checkout should be.
>
> Perhaps something like "clone --branch=master --$endpoint=v1.7.8" that
> says "I want a clone of the repository limited to a single lineage, whose
> history ends at the commit pointed by the v1.7.8 tag, and name the local
> checkout my master branch" be more appropriate?
Branch naming is a local thing. Maybe we could get away with always
name it "master" if fetched from a tag. Branch tracking is not set up
in this case, so if they want to follow up with upstream, they have to
do some more themselves (including renaming "master" to something else
for less confusion with upstream "master"). New option is not easily
discovered, while "git branch -r master foo" is quite easy.
--
Duy
^ permalink raw reply
* Re: Odd remote: error: packfile ./objects/pack/pack-FOO.pack cannot be accessed
From: Sudarshan Wadkar @ 2012-01-06 8:01 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20120103193349.GE20926@sigill.intra.peff.net>
Peff,
Sorry for the delay in reply. Yes, it's the same pack. And if I do `ll
./object/pack/ ` on remote I can see the pack with read perms for all.
However, I observed that the pack I am getting now, is different from
that in my previous email. I am not sure what caused it to change, as
I did lot of commits/push to the remote. I tested with some test
commits to see if it is caused by a particular branch, but the pack is
still the same. Also, previously, if I would push to the remote in
succession without committing anything, I would get "Everything up to
date". But now, it seems that post-receive hook is called second time
too, and I see the "error : packfile".
Here's a shell copy paste : http://pastie.org/3136111
$ git status
# On branch 0.0.4
nothing to commit (working directory clean)
$ git push ourCloud
Total 0 (delta 0), reused 0 (delta 0)
remote: error: packfile
./objects/pack/pack-ff7bb2bee430b314648c084970f6a6877b837a58.pack
cannot be accessed
remote: HEAD is now at cff7a3a Fix mapping action from keyword search to API
remote: HEAD is now at cff7a3a Fix mapping action from keyword search to API
remote: Successfully deployed master into /var/www/html/myProj-master
remote: HEAD is now at 85534ca Test remote error packfile 2
remote: Successfully deployed 0.0.4 into /var/www/html/myProj-0.0.4
To ssh://wadkar@192.168.1.177:7185/~wadkar/repo/bare/myProj
+ 85534ca...cff7a3a master -> master (forced update)
$ git push ourCloud
Total 0 (delta 0), reused 0 (delta 0)
remote: error: packfile
./objects/pack/pack-ff7bb2bee430b314648c084970f6a6877b837a58.pack
cannot be accessed
remote: HEAD is now at cff7a3a Fix mapping action from keyword search to API
remote: HEAD is now at cff7a3a Fix mapping action from keyword search to API
remote: Successfully deployed master into /var/www/html/myProj-master
remote: HEAD is now at 85534ca Test remote error packfile 2
remote: Successfully deployed 0.0.4 into /var/www/html/myProj-0.0.4
To ssh://wadkar@192.168.1.177:7185/~wadkar/repo/bare/myProj
+ 85534ca...cff7a3a master -> master (forced update)
$ vi README.txt #make changes
$ git commit -am 'Test error packfile 3'
Test error packfile 3
1 files changed, 0 insertions(+), 2 deletions(-)
$ git push ourCloud
Counting objects: 5, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 294 bytes, done.
Total 3 (delta 2), reused 0 (delta 0)
remote: error: packfile
./objects/pack/pack-ff7bb2bee430b314648c084970f6a6877b837a58.pack
cannot be accessed
remote: HEAD is now at cff7a3a Fix mapping action from keyword search to API
remote: HEAD is now at cff7a3a Fix mapping action from keyword search to API
remote: Successfully deployed master into /var/www/html/myProj-master
remote: HEAD is now at a0e3f87 Test error packfile 3
remote: Successfully deployed 0.0.4 into /var/www/html/myProj-0.0.4
To ssh://wadkar@192.168.1.177:7185/~wadkar/repo/bare/myProj
85534ca..a0e3f87 0.0.4 -> 0.0.4
+ 85534ca...cff7a3a master -> master (forced update)
$ ssh -p 7185 wadkar@192.168.1.177
##now on remote##
$ ll repo/bare/myProj/objects/pack/
total 672
-r--r--r-- 1 wadkar wadkar 47496 Jan 2 16:52
pack-ff7bb2bee430b314648c084970f6a6877b837a58.idx
-r--r--r-- 1 wadkar wadkar 634393 Jan 2 16:52
pack-ff7bb2bee430b314648c084970f6a6877b837a58.pack
$ logout
Connection to 192.168.1.177 closed.
##back to local##
$ git push ourCloud
Total 0 (delta 0), reused 0 (delta 0)
remote: error: packfile
./objects/pack/pack-ff7bb2bee430b314648c084970f6a6877b837a58.pack
cannot be accessed
remote: HEAD is now at cff7a3a Fix mapping action from keyword search to API
remote: HEAD is now at cff7a3a Fix mapping action from keyword search to API
remote: Successfully deployed master into /var/www/html/myProj-master
remote: HEAD is now at a0e3f87 Test error packfile 3
remote: Successfully deployed 0.0.4 into /var/www/html/myProj-0.0.4
To ssh://wadkar@192.168.1.177:7185/~wadkar/repo/bare/myProj
+ a0e3f87...cff7a3a master -> master (forced update)
$ git push ourCloud
Total 0 (delta 0), reused 0 (delta 0)
remote: error: packfile
./objects/pack/pack-ff7bb2bee430b314648c084970f6a6877b837a58.pack
cannot be accessed
remote: HEAD is now at cff7a3a Fix mapping action from keyword search to API
remote: HEAD is now at cff7a3a Fix mapping action from keyword search to API
remote: Successfully deployed master into /var/www/html/myProj-master
remote: HEAD is now at a0e3f87 Test error packfile 3
remote: Successfully deployed 0.0.4 into /var/www/html/myProj-0.0.4
To ssh://wadkar@192.168.1.177:7185/~wadkar/repo/bare/myProj
+ a0e3f87...cff7a3a master -> master (forced update)
$ ssh -p 7185 wadkar@192.168.1.177
##now on remote##
$ ll repo/bare/myProj/objects/pack/
total 672
-r--r--r-- 1 wadkar wadkar 47496 Jan 2 16:52
pack-ff7bb2bee430b314648c084970f6a6877b837a58.idx
-r--r--r-- 1 wadkar wadkar 634393 Jan 2 16:52
pack-ff7bb2bee430b314648c084970f6a6877b837a58.pack
$ logout
Connection to 192.168.1.177 closed.
##back to local##
$ git checkout master
Switched to branch 'master'
$ git status
# On branch master
nothing to commit (working directory clean)
$ echo 'Foo' >> README.txt
$ git push ourCloud
Counting objects: 5, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 305 bytes, done.
Total 3 (delta 2), reused 0 (delta 0)
remote: error: packfile
./objects/pack/pack-ff7bb2bee430b314648c084970f6a6877b837a58.pack
cannot be accessed
remote: HEAD is now at b220238 Test error packfile 4 (master)
remote: HEAD is now at b220238 Test error packfile 4 (master)
remote: Successfully deployed master into /var/www/html/myProj-master
remote: HEAD is now at a0e3f87 Test error packfile 3
remote: Successfully deployed 0.0.4 into /var/www/html/myProj-0.0.4
To ssh://wadkar@192.168.1.177:7185/~wadkar/repo/bare/myProj
+ a0e3f87...b220238 master -> master (forced update)
$ ssh -p 7185 wadkar@192.168.1.177
##now on remote##
$ ll repo/bare/myProj/objects/pack/
total 672
-r--r--r-- 1 wadkar wadkar 47496 Jan 2 16:52
pack-ff7bb2bee430b314648c084970f6a6877b837a58.idx
-r--r--r-- 1 wadkar wadkar 634393 Jan 2 16:52
pack-ff7bb2bee430b314648c084970f6a6877b837a58.pack
-Sudarshan Wadkar
"Success is getting what you want. Happiness is wanting what you get."
- Dale Carnegie
"It's always our decision who we are"
- Robert Solomon in Waking Life
"The truth is the truth, so all you can do is live with it."
--Systematic Chaos
On Wed, Jan 4, 2012 at 1:03 AM, Jeff King <peff@peff.net> wrote:
> On Mon, Jan 02, 2012 at 02:48:22PM +0530, Sudarshan Wadkar wrote:
>
>> But when I push, I get this odd error from remote
>>
>> $ git push --verbose --mirror
>> ssh://wadkar@192.168.1.177:7185/~wadkar/repo/bare/myproj.git
>> Pushing to ssh://wadkar@192.168.1.177:7185/~wadkar/repo/bare/myproj.git
>> Counting objects: 5, done.
>> Delta compression using up to 4 threads.
>> Compressing objects: 100% (3/3), done.
>> Writing objects: 100% (3/3), 323 bytes, done.
>> Total 3 (delta 2), reused 0 (delta 0)
>> remote: error: packfile
>> ./objects/pack/pack-17900952dc824651db15369a341eec8d3e8f39d2.pack
>> cannot be accessed
>> remote: HEAD is now at 4d5a6f1 Investigate and report odd error
>> To ssh://wadkar@192.168.1.177:7185/~wadkar/repo/bare/myproj.git
>> d066a2f..4d5a6f1 master -> master
>
> Is it always the same pack? If so, have you tried looking in the
> objects/pack directory to make sure it's not a permissions problem?
>
> -Peff
^ permalink raw reply
* Re: Why usage function exit with code 129?
From: 徐迪 @ 2012-01-06 8:06 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Git 邮件列表
In-Reply-To: <CACsJy8Amo_9-9oCgHbwOZvTaNOV3Jj6wLCTU7nZT5LeA55=NEA@mail.gmail.com>
>> [1] http://tldp.org/LDP/abs/html/exitcodes.html
>
> No it does not mean terminated by signals.
> --
In that case, why not just use another code instead of the code that
leads misunderstanding? I mean, as far as I know, exit code between
129 and 255 are used to indicate the program terminated by signal. So
that usage function can only exit with code between 1 and 127. Am I
wrong?
^ permalink raw reply
* Re: Why usage function exit with code 129?
From: Nguyen Thai Ngoc Duy @ 2012-01-06 8:11 UTC (permalink / raw)
To: 徐迪; +Cc: Git 邮件列表
In-Reply-To: <CAMocUqSmes+x_tkP6V0OM5rQ5wDGmMm=Q2MFBPhz6Qvzz_SOTg@mail.gmail.com>
2012/1/6 徐迪 <xudifsd@gmail.com>:
>>> [1] http://tldp.org/LDP/abs/html/exitcodes.html
>>
>> No it does not mean terminated by signals.
>> --
> In that case, why not just use another code instead of the code that
> leads misunderstanding? I mean, as far as I know, exit code between
> 129 and 255 are used to indicate the program terminated by signal. So
> that usage function can only exit with code between 1 and 127. Am I
> wrong?
Because that code has been there too long (since 2005) any probably
all git commands, including plumbing ones, rely on it. Changing it now
may break existing scripts.
--
Duy
^ permalink raw reply
* Managing signed git tags and expiring keys
From: Jonathan "Duke" Leto @ 2012-01-06 8:13 UTC (permalink / raw)
To: Git Users
Howdy,
My question is about the Git workflow in a repository which has signed
tags and uses expiring keys in a chain of trust.
When the key changes, all existing tags are signed with the previous
key in the chain of trust.
Do people:
1) resign all the tags, causing people to overwrite their local tags
2) keep all versions of the keys in the chain of trust
3) something else more involved?
Is anybody doing this currently?
Thanks!
Duke
--
Jonathan "Duke" Leto <jonathan@leto.net>
Leto Labs LLC
209.691.DUKE // http://labs.leto.net
NOTE: Personal email is only checked twice a day at 10am/2pm PST,
please call/text for time-sensitive matters.
^ permalink raw reply
* Re: Why usage function exit with code 129?
From: 徐迪 @ 2012-01-06 8:18 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Git 邮件列表
In-Reply-To: <CACsJy8D8uKGhtg4zjbHsJCGmqjTwodzFmAZ5w=aUx9CdadVAfw@mail.gmail.com>
在 2012年1月6日 下午4:11，Nguyen Thai Ngoc Duy <pclouds@gmail.com> 写道：
> 2012/1/6 徐迪 <xudifsd@gmail.com>:
>>>> [1] http://tldp.org/LDP/abs/html/exitcodes.html
>>>
>>> No it does not mean terminated by signals.
>>> --
>> In that case, why not just use another code instead of the code that
>> leads misunderstanding? I mean, as far as I know, exit code between
>> 129 and 255 are used to indicate the program terminated by signal. So
>> that usage function can only exit with code between 1 and 127. Am I
>> wrong?
>
> Because that code has been there too long (since 2005) any probably
> all git commands, including plumbing ones, rely on it. Changing it now
> may break existing scripts.
> --
> Duy
Ok, that sounds logical.
^ permalink raw reply
* Re: [PATCH] clone: allow detached checkout when --branch takes a tag
From: Nguyen Thai Ngoc Duy @ 2012-01-06 11:09 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20120105141844.GA26771@sigill.intra.peff.net>
2012/1/5 Jeff King <peff@peff.net>:
>> @@ -721,6 +722,14 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
>> strbuf_release(&head);
>>
>> if (!our_head_points_at) {
>> + strbuf_addstr(&head, "refs/tags/");
>> + strbuf_addstr(&head, option_branch);
>> + our_head_points_at =
>> + find_ref_by_name(mapped_refs, head.buf);
>> + strbuf_release(&head);
>> + }
>> +
>> + if (!our_head_points_at) {
>
> Hmm. The context just above your patch that got snipped does this:
>
> strbuf_addstr(&head, src_ref_prefix);
> strbuf_addstr(&head, option_branch);
> our_head_points_at =
> find_ref_by_name(mapped_refs, head.buf);
>
> where src_ref_prefix typically is "refs/heads/", and clearly you are
> meaning to do the same thing for tags. But the use of "src_ref_prefix"
> is interesting.
>
> It is always "refs/heads/" unless we are cloning into a bare mirror, in
> which case it is "refs/". So with your patch in the non-mirror case,
> doing "--branch=foo" would try "refs/heads/foo" followed by
> "refs/tags/foo". Which makes sense. But in the mirror case, it will try
> "refs/foo" followed by "refs/tags/foo", which is kind of odd.
>
> I wonder, though, if the original code makes any sense. By using
> "refs/", I would have to say "--branch=heads/foo", which is kind of
> weird and undocumented. I think it should probably always be
> "refs/heads/", no matter if we are mirroring or not.
--branch should not be used with --mirror in my opinion. --branch
changes HEAD so it's no longer an exact mirror.
--
Duy
^ permalink raw reply
* [PATCH] Documentation: rerere.enabled overrides [ -d rr-cache ]
From: Thomas Rast @ 2012-01-06 13:08 UTC (permalink / raw)
To: git
The wording seems to suggest that you can only globally disable rerere
with the rerere.enabled setting. But the code actually consults the
config first, and even creates rr-cache for the user if needed.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Noticed while discussing rerere on IRC. "Can be disabled by setting
this option to false" is of course correct, but insinuates that
setting it to 'true' still falls back to rr-cache, which it doesn't.
git-rerere(1) does not mention the rr-cache fallback; I decided not to
touch it as it's a bit of an implementation detail. OTOH the
auto-creation of rr-cache can cause strange behavior if a user has
rerere.enabled unset and tries it once, as in
git config rerere.enabled true
git merge ...
git config --unset rerere.enabled
Documentation/config.txt | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 68cf702..04f5e19 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1783,10 +1783,10 @@ rerere.autoupdate::
rerere.enabled::
Activate recording of resolved conflicts, so that identical
- conflict hunks can be resolved automatically, should they
- be encountered again. linkgit:git-rerere[1] command is by
- default enabled if you create `rr-cache` directory under
- `$GIT_DIR`, but can be disabled by setting this option to false.
+ conflict hunks can be resolved automatically, should they be
+ encountered again. By default, linkgit:git-rerere[1] is
+ enabled if there is an `rr-cache` directory under the
+ `$GIT_DIR`.
sendemail.identity::
A configuration identity. When given, causes values in the
--
1.7.8.2.479.g7c686
^ permalink raw reply related
* [PATCH 2/3] show_ref(): remove unused "flag" and "cb_data" arguments
From: mhagger @ 2012-01-06 14:12 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Jakub Narebski, Heiko Voigt, Johan Herland,
Michael Haggerty
In-Reply-To: <1325859153-31016-1-git-send-email-mhagger@alum.mit.edu>
From: Michael Haggerty <mhagger@alum.mit.edu>
The function is not used as a callback, so it doesn't need these
arguments. Also change its return type to void.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
I suppose, though I didn't verify, that the old function signature was
a vestige of its earlier having been used as a callback function. But
it doesn't really matter; the point is that the extra arguments are
currently not needed.
builtin/receive-pack.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index 08df17e..65d129c 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -115,7 +115,7 @@ static int receive_pack_config(const char *var, const char *value, void *cb)
return git_default_config(var, value, cb);
}
-static int show_ref(const char *path, const unsigned char *sha1, int flag, void *cb_data)
+static void show_ref(const char *path, const unsigned char *sha1)
{
if (sent_capabilities)
packet_write(1, "%s %s\n", sha1_to_hex(sha1), path);
@@ -125,10 +125,9 @@ static int show_ref(const char *path, const unsigned char *sha1, int flag, void
" report-status delete-refs side-band-64k",
prefer_ofs_delta ? " ofs-delta" : "");
sent_capabilities = 1;
- return 0;
}
-static int show_ref_cb(const char *path, const unsigned char *sha1, int flag, void *cb_data)
+static int show_ref_cb(const char *path, const unsigned char *sha1, int flag, void *unused)
{
path = strip_namespace(path);
/*
@@ -141,7 +140,8 @@ static int show_ref_cb(const char *path, const unsigned char *sha1, int flag, vo
*/
if (!path)
path = ".have";
- return show_ref(path, sha1, flag, cb_data);
+ show_ref(path, sha1);
+ return 0;
}
static void add_one_alternate_sha1(const unsigned char sha1[20], void *unused)
@@ -163,7 +163,7 @@ static void write_head_info(void)
sha1_array_clear(&sa);
for_each_ref(show_ref_cb, NULL);
if (!sent_capabilities)
- show_ref("capabilities^{}", null_sha1, 0, NULL);
+ show_ref("capabilities^{}", null_sha1);
clear_extra_refs();
/* EOF */
--
1.7.8.2
^ permalink raw reply related
* [PATCH 1/3] receive-pack: move more work into write_head_info()
From: mhagger @ 2012-01-06 14:12 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Jakub Narebski, Heiko Voigt, Johan Herland,
Michael Haggerty
In-Reply-To: <1325859153-31016-1-git-send-email-mhagger@alum.mit.edu>
From: Michael Haggerty <mhagger@alum.mit.edu>
Move some more code from the calling site into write_head_info(), and
inline add_alternate_refs() there. (Some more simplification is
coming, and it is easier if all this code is in the same place.)
Move some helper functions to avoid the need for forward declarations.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
builtin/receive-pack.c | 42 ++++++++++++++++++------------------------
1 files changed, 18 insertions(+), 24 deletions(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index d2dcb7e..08df17e 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -144,12 +144,30 @@ static int show_ref_cb(const char *path, const unsigned char *sha1, int flag, vo
return show_ref(path, sha1, flag, cb_data);
}
+static void add_one_alternate_sha1(const unsigned char sha1[20], void *unused)
+{
+ add_extra_ref(".have", sha1, 0);
+}
+
+static void collect_one_alternate_ref(const struct ref *ref, void *data)
+{
+ struct sha1_array *sa = data;
+ sha1_array_append(sa, ref->old_sha1);
+}
+
static void write_head_info(void)
{
+ struct sha1_array sa = SHA1_ARRAY_INIT;
+ for_each_alternate_ref(collect_one_alternate_ref, &sa);
+ sha1_array_for_each_unique(&sa, add_one_alternate_sha1, NULL);
+ sha1_array_clear(&sa);
for_each_ref(show_ref_cb, NULL);
if (!sent_capabilities)
show_ref("capabilities^{}", null_sha1, 0, NULL);
+ clear_extra_refs();
+ /* EOF */
+ packet_flush(1);
}
struct command {
@@ -869,25 +887,6 @@ static int delete_only(struct command *commands)
return 1;
}
-static void add_one_alternate_sha1(const unsigned char sha1[20], void *unused)
-{
- add_extra_ref(".have", sha1, 0);
-}
-
-static void collect_one_alternate_ref(const struct ref *ref, void *data)
-{
- struct sha1_array *sa = data;
- sha1_array_append(sa, ref->old_sha1);
-}
-
-static void add_alternate_refs(void)
-{
- struct sha1_array sa = SHA1_ARRAY_INIT;
- for_each_alternate_ref(collect_one_alternate_ref, &sa);
- sha1_array_for_each_unique(&sa, add_one_alternate_sha1, NULL);
- sha1_array_clear(&sa);
-}
-
int cmd_receive_pack(int argc, const char **argv, const char *prefix)
{
int advertise_refs = 0;
@@ -937,12 +936,7 @@ int cmd_receive_pack(int argc, const char **argv, const char *prefix)
unpack_limit = receive_unpack_limit;
if (advertise_refs || !stateless_rpc) {
- add_alternate_refs();
write_head_info();
- clear_extra_refs();
-
- /* EOF */
- packet_flush(1);
}
if (advertise_refs)
return 0;
--
1.7.8.2
^ permalink raw reply related
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