* Re: [PATCH] rebase-i-p: delay saving current-commit to REWRITTEN if squashing
From: Jeff King @ 2008-10-22 19:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stephen Haberman, git
In-Reply-To: <7v4p34v42e.fsf@gitster.siamese.dyndns.org>
On Wed, Oct 22, 2008 at 12:10:33PM -0700, Junio C Hamano wrote:
> >> + if [ "$fast_forward" == "t" ]
> > This one even fails on my Linux box. :) "==" is a bash-ism.
>
> Thanks.
You're very welcome, and sorry for not saving you a little time by
writing my complaint in patch form in the first place.
-Peff
^ permalink raw reply
* Re: [ANNOUCNE] repo - The Multiple Git Repository Tool
From: Junio C Hamano @ 2008-10-22 19:14 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20081022154245.GT14786@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Google developed two tools, repo and Gerrit, and open sourced them
> under the Apache License:
>
> http://android.git.kernel.org/?p=tools/repo.git
> http://android.git.kernel.org/?p=tools/gerrit.git
>
> git://android.git.kernel.org/tools/repo.git
> git://android.git.kernel.org/tools/gerrit.git
Heh, very nice, with a very shallow history ;-)
^ permalink raw reply
* Re: [PATCH v2] builtin-blame: Reencode commit messages according to git-log rules.
From: Jeff King @ 2008-10-22 19:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alexander Gavrilov, git
In-Reply-To: <7vd4hsv46z.fsf@gitster.siamese.dyndns.org>
On Wed, Oct 22, 2008 at 12:07:48PM -0700, Junio C Hamano wrote:
> Yuck. Solaris 8 /usr/bin/grep does not even grok "-e", so we cannot do a
> more obvious:
>
> grep -e "^author " -e "^summary "
Yep. I already introduced one use of egrep for a similar case in
8753941 (tests: grep portability fixes).
> Do people build with NO_EXTERNAL_GREP on older Solaris?
Yep. See:
http://repo.or.cz/w/git/gitbuild.git?a=blob;f=jk/solaris/config.mak;hb=platform
for the gory details (boy, I wish we had nice PATH_INFO-based gitweb
URLs...).
> git-submodule.sh uses grep "-e" to look for two patterns and I suspect
> older Solaris would have the same issue.
Yes, that code will break on Solaris. Most of my portability fixes have
been in direct response to tests, so I guess we are not testing
git-submodule very well.
-Peff
^ permalink raw reply
* Re: [PATCH] rebase-i-p: delay saving current-commit to REWRITTEN if squashing
From: Junio C Hamano @ 2008-10-22 19:10 UTC (permalink / raw)
To: Jeff King; +Cc: Stephen Haberman, gitster, git
In-Reply-To: <20081022125149.GA17092@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, Oct 15, 2008 at 02:44:36AM -0500, Stephen Haberman wrote:
>
>> + if [ "$fast_forward" == "t" ]
>
> This one even fails on my Linux box. :) "==" is a bash-ism.
Thanks.
-- >8 --
Subject: [PATCH] git-rebase--interactive.sh: comparision with == is bashism
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-rebase--interactive.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index a563dea..0cae3be 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -170,7 +170,7 @@ pick_one_preserving_merges () {
if test -f "$DOTEST"/current-commit
then
- if [ "$fast_forward" == "t" ]
+ if test "$fast_forward" = t
then
cat "$DOTEST"/current-commit | while read current_commit
do
--
1.6.0.3.723.g757e
^ permalink raw reply related
* Re: [PATCH v2] builtin-blame: Reencode commit messages according to git-log rules.
From: Junio C Hamano @ 2008-10-22 19:07 UTC (permalink / raw)
To: Jeff King; +Cc: Alexander Gavrilov, git
In-Reply-To: <20081022082016.GA18473@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, Oct 22, 2008 at 12:55:57AM +0400, Alexander Gavrilov wrote:
>
>> +test_expect_success \
>> + 'blame respects i18n.commitencoding' '
>> + git blame --incremental file | \
>> + grep "^\(author\|summary\) " > actual &&
>> + test_cmp actual expected
>
> Even though it is POSIX, using backslashed grouping in 'grep' isn't
> portable. It fails at least on Solaris 8, and you have to do:
>
> egrep "^(author|summary) "
>
> instead. Of course, I can't get your test to pass even with that change,
> but I think that is just a broken iconv on Solaris.
Yuck. Solaris 8 /usr/bin/grep does not even grok "-e", so we cannot do a
more obvious:
grep -e "^author " -e "^summary "
Do people build with NO_EXTERNAL_GREP on older Solaris?
git-submodule.sh uses grep "-e" to look for two patterns and I suspect
older Solaris would have the same issue.
^ permalink raw reply
* Re: [PATCH] git-svn: don't escape tilde ('~') for http(s) URLs
From: Junio C Hamano @ 2008-10-22 18:53 UTC (permalink / raw)
To: Eric Wong; +Cc: Björn Steinbrink, git, jsogo
In-Reply-To: <20081022081653.GC14966@untitled>
Eric Wong <normalperson@yhbt.net> writes:
> Junio C Hamano <gitster@pobox.com> wrote:
>
> Help with looking at what SVN does and writing testcases would
> definitely be appreciated on this matter. Or perhaps this can be done
> at GitTogether :)
I'm not sure it would be a good use of time at GitTogether to do something
whose spec is pretty much self-evident (essentially for this one it boils
down to "define what are the 'funny' bytes, and list the protocols
supported by svn, and come up with paths with funny bytes in it and
see what libsvn-perl gives to the underlying svn library, and what the svn
library does over the wire"). Ongoiong "fix start-up sequence around
worktree area" might be a better fit; I dunno.
>> The patch may make a path with '~' work, but it (neither in the patch text
>> nor in the commit log message) does not have much to give readers enough
>> confidence that the code after the patch is the _final_ one, as opposed to
>> being just a band-aid for a single symptom that happened to have been
>> discovered this time.
>
> This is definitely a band-aid fix until I or somebody else takes the
> time to figure out:
>
> 1. exactly which characters need to be escaped
> 2. for which protocols those characters need to be escaped
> 3. which part(s) of the URI they need to be escaped for
> (repository root vs SVN path)
> 4. which versions of SVN needs more (or less) escaping rules
>
> (I vote for somebody else, especially for #4 :)
Item 3. above disturbs me. Do you mean that in:
https://sucs.org/~welshbyte/svn/backuptool/trunk/foo~bar.txt
the two tildes might have to be sent to libsvn-perl differently?
Even if that is the case, I am inclined suggest taking the patch in the
meantime as an interim workaround, with the understanding that we know the
patch improves the situation for the tilde before welshbyte and even
though we do not know if the patch regresses for the latter one between
foo and bar, it would be much rarer to have tilde in such places.
Care to come up with an updated log message?
^ permalink raw reply
* Re: git archive
From: kenneth johansson @ 2008-10-22 18:45 UTC (permalink / raw)
To: git
In-Reply-To: <20081022130829.GC2015@riemann.deskinm.fdns.net>
On Wed, 22 Oct 2008 09:08:29 -0400, Deskin Miller wrote:
> On Wed, Oct 22, 2008 at 08:42:01AM +0000, kenneth johansson wrote:
>> I was going to make a tar of the latest stable linux kernel. Done it
>> before but now I got a strange problem.
>>
>> >git archive --format=tar v2.6.27.2
>> fatal: Not a valid object name
>
> I had the same thing happen to me, while trying to make an archive of
> Git. Were you perchance working in a bare repository, as I was? I spent
> some time looking at it and I think git archive sets up the environment
> in the wrong order, though of course I never finished a patch so I'm
> going from memory:
Yes it was a bare repository.
>
> After looking at the code again, I think the issue is that git_config is
> called in builtin-archive.c:cmd_archive before setup_git_directory is
> called in archive.c:write_archive. The former ends up setting GIT_DIR
> to be '.git' even if you're in a bare repository. My coding skills
> weren't up to fixing it easily; moving setup_git_directory before
> git_config in builtin-archive caused last test of t5000 to fail:
> GIT_DIR=some/nonexistent/path git archive --list should still display
> the archive formats.
if I do
GIT_DIR=. git archive --format=tar v2.6.27.2
it does work so it looks like you are on the right track.
^ permalink raw reply
* Re: error: packfile while git fsck
From: Nicolas Pitre @ 2008-10-22 17:35 UTC (permalink / raw)
To: Nicolas Ferre; +Cc: git
In-Reply-To: <48FF4521.5070303@atmel.com>
On Wed, 22 Oct 2008, Nicolas Ferre wrote:
> Nicolas Pitre :
> > On Wed, 22 Oct 2008, Nicolas Ferre wrote:
> >
> > > Hi all,
> > > (please cc me on response)
> > >
> > > I am facing error during git status & git fsck on my tree.
> > > This tree is cloned from various linux kernel trees.
> > >
> > > Here are a sample of the error I see :
> > >
> > > $ git fsck
> > > error: packfile
> > > .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack does
> > > not
> > > match index
> > > error: packfile
> > > .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack
> > > cannot be
> > > accessed
> > [...]
> >
> > What git version?
>
> $ git --version
> git version 1.5.3.7
OK. Since this is not bleeding edge, it is pretty unlikely that the
corruption is due to git itself. Furthermore, the git packs are always
read only once they've been created, meaning that if they weren't
corrupted at some point then something outside of git caused the
corruption. You really should consider the possible causes for that
(dying disk, pilot error, etc).
As to recovery... That really depends if you have personal work
committed to your repository. If not then the easiest solution is
simply to recreate it by refetching from upstream. If you have
personal work in there then you could try to fetch your work branch into
the newly created repository. The latest git version could help with
the extraction of non-corrupted objects out of a bad pack, but if the
objects you are interested in are themselves corrupted then your only
hope is to have a copy of those objects somewhere else.
Nicolas
^ permalink raw reply
* Re: linux-next: stackprotector tree build failure
From: Johannes Schindelin @ 2008-10-22 17:41 UTC (permalink / raw)
To: Ingo Molnar
Cc: Stephen Rothwell, Thomas Gleixner, H. Peter Anvin, linux-next,
Junio C Hamano, git
In-Reply-To: <20081022083139.GA4369@elte.hu>
Hi,
On Wed, 22 Oct 2008, Ingo Molnar wrote:
>
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > On Wed, 22 Oct 2008 09:29:23 +0200 Ingo Molnar <mingo@elte.hu> wrote:
> > >
> > > I've Cc:-ed Junio and the Git list as a general FYI - but it must be
> > > frustrating to get such a bugreport, because i have no reproducer.
> > >
> > > git-rerere sometimes seems to be picking up the wrong resolution. VERY
> > > rarely.
> > >
> > > It seems random and content dependent. Once it happened to
> > > arch/x86/kernel/traps_32.c and now to kernel/fork.c. Along the ~170
> > > successful resolutions i have in my tree right now. And i do many
> > > conflict resolutions every day - and it happened only once every 6
> > > months or so.
> > >
> > > (the arch/x86/kernel/traps_32.c one happened regularly, that's why i
> > > thought it's content sha1 dependent, and not some corruption.)
> > >
> > > Next time it happens i'll be on the watchout and will save the complete
> > > tree.
> >
> > I think rerere matches preimages on the SHA1 of the conflict (or its
> > reverse), so sufficiently similar pieces of code will match. I would
> > expect things like ext2/3/4 to be candidates. Did the traps_32.c one
> > match one for traps_64.c?
> >
> > I may be mistaken, but I once followed the code in rerere to try to
> > figure out how to fix a resolution.
>
> the traps_32.c one was that git-rerere put in a traps_64.c end result.
> So i ended up with a 32-bit kernel that tried to build a 64-bit piece of
> code - fireworks. That condition persisted - i had to fix it up manually
> all the time i integrated that portion of the tree. That too was i think
> centered around a header file chunk - perhaps the #include section of
> traps_32.c and traps_64.c was similar enough in that section?
I think it might be in order to explain how git-rerere works internally:
- in case of a conflicts, the files' conflicts are written into the
rr-cache _per file_.
First, the human readable stuff after the "<<<", "|||" and ">>>" lines
is removed.
Then, the "||| ... ===" part is removed, too (in effect turning the
diff3-style conflicts into an RCS merge-style conflicts).
The result is recorded as "preimage". The conflict is identified by the
SHA-1 of _just_ the conflicts (including the "<<<", "===" and ">>>"
lines).
After all the conflicted files have been handled, a list is written to
the file "MERGE_RR" containing the SHA-1s of the conflicts together with
the file names.
- when committing, the files whose conflicts were resolved are recorded
verbatim in the file "postimage".
Now, when rerere is called again and there are conflicted files, again the
files' conflicts are identified by their SHA-1. If a resolution exists, a
3-way merge is performed with the recorded preimage (the
original file with conflict lines) as base, the postimage (the originally
resolved file) and the current file with conflict lines.
The idea being: the diff between the recorded preimage and postimage gives
the resolution that you want, and the diff between the recorded preimage
and the current file with conflict lines gives you the changes that
happened to the file in-between.
So I think that you might hit the unfortunate case where two files
happened to have the same conflicts, but you needed to resolve them one
way for one file, and another way for the other file.
Ciao,
Dscho
^ permalink raw reply
* Re: [irq/urgent]: created 3786fc7: "irq: make variable static"
From: Johannes Schindelin @ 2008-10-22 17:04 UTC (permalink / raw)
To: Jeff King; +Cc: Jakub Narebski, Ingo Molnar, git
In-Reply-To: <20081022132148.GA17393@coredump.intra.peff.net>
Hi,
On Wed, 22 Oct 2008, Jeff King wrote:
> On Wed, Oct 22, 2008 at 03:50:52AM -0700, Jakub Narebski wrote:
>
> > About printing either forward (git-describe, e.g.
> > v1.6.0.2-590-g67f6062) or backward (git-name-rev, e.g.
> > tags/v1.6.0-rc2~8): you can use git-name-rev in filter mode (git log
> > ... | git name-rev --stdin), or "git log --decorate", or '%d' in
> > --pretty format specifier (this is very new thing).
>
> The "--decorate" and "%d" code just decorates branch _tips_. My
> impression is that he wanted to see the branch mentioned even if the
> commit was not at the tip. It would be possible to extend this to print
> name-rev output, but it would be computationally and memory-intensive, I
> suspect.
FWIW I tried to do this "on-the-fly", but that did not bode well with
things like
git log --decorate=any --no-walk master $(git rev-parse master~10)
If you're interested in code:
http://thread.gmane.org/gmane.comp.version-control.git/52123/focus=52126
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Implement git remote mv
From: Brandon Casey @ 2008-10-22 16:52 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, git
In-Reply-To: <1224634994-1664-1-git-send-email-vmiklos@frugalware.org>
Miklos Vajna wrote:
> +static int mv(int argc, const char **argv)
> +{
> + struct option options[] = {
> + OPT_END()
> + };
> + struct remote *oldremote, *newremote;
> + struct strbuf buf = STRBUF_INIT, buf2 = STRBUF_INIT;
> + struct string_list remote_branches = { NULL, 0, 0, 0 };
> + struct rename_info rename = { argv[1], argv[2], &remote_branches };
I think some non-c99 compilers would have issues with this run-time
initialization from function arguments. Plus, what if argv doesn't have
3 elements? I see you have a check for that below...
> + int i;
> +
> + if (argc != 3)
> + usage_with_options(builtin_remote_usage, options);
-brandon
^ permalink raw reply
* Terminology question: "tracking" branches
From: Björn Steinbrink @ 2008-10-22 16:13 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Marc Branchaud, Peter Harris, git
In-Reply-To: <48FF3FEE.8020209@drmicha.warpmail.net>
On 2008.10.22 16:59:58 +0200, Michael J Gruber wrote:
> - a remote branch (a branch in your local repo which is a copy of a
> branch in a remote repo; stored under refs/remotes, never to be modified
> locally)
> - a (remote) tracking branch (a local branch which is set up to pull
> from a remote branch by default)
(Remote) tracking branches are actually what you called remote branches,
at least according to the git glossary. But I wonder, what is the right
term for a branch that has the --track setup for pull?
On #git I usually fall back to some variation of "a branch that is
configured for 'git pull'" or something similarly verbose (and maybe
that's even partially wrong/inaccurate/incomplete?). And I always try to
stick to saying "remote tracking branch" and not just "tracking branch"
(as the glossary does) to avoid confusion as best as I can. But that
feels quite suboptimal.
So, is there some term that describes a local branch that has been
configured for "git pull"?
Thanks,
Björn
^ permalink raw reply
* Re: [PATCH] rebase-i-p: delay saving current-commit to REWRITTEN if squashing
From: Fredrik Skolmli @ 2008-10-22 15:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, Stephen Haberman, gitster, git
In-Reply-To: <alpine.DEB.1.00.0810221721370.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On Wed, Oct 22, 2008 at 05:21:53PM +0200, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 22 Oct 2008, Jeff King wrote:
>
> > On Wed, Oct 15, 2008 at 02:44:36AM -0500, Stephen Haberman wrote:
> >
> > > + if [ "$fast_forward" == "t" ]
> >
> > This one even fails on my Linux box. :) "==" is a bash-ism.
>
> Did we not also prefer "test" to "["?
We did.
Documentation/CodingGuidelines, line 51:
- We prefer "test" over "[ ... ]".
--
Kind regards,
Fredrik Skolmli
^ permalink raw reply
* [ANNOUCNE] repo - The Multiple Git Repository Tool
From: Shawn O. Pearce @ 2008-10-22 15:42 UTC (permalink / raw)
To: git
My "bundle related secret project" was released yesterday by Google
as part of the Android open source release event. (I've mentioned
it before on-list in the context of a modified "git status" output.)
Google developed two tools, repo and Gerrit, and open sourced them
under the Apache License:
http://android.git.kernel.org/?p=tools/repo.git
http://android.git.kernel.org/?p=tools/gerrit.git
git://android.git.kernel.org/tools/repo.git
git://android.git.kernel.org/tools/gerrit.git
repo is a Python application to bind together Git repositories,
something like "git submodule", except it can track a project's
branch rather than a specific Git commit. repo is also able to
natively import a tarball or zip file and use it to initialize a
repository from an upstream source, then apply git based changes
on top of that tarball. In other words, repo is (more or less)
built to manage an OS distribution, in Git.
Gerrit is a web based code review system, forked off the open
sourced Rietveld code review system. Gerrit runs on the highly
scaleable Google App Engine platform, but probably could be ported
to an open-source MySQL or PostgreSQL backend if people really
wanted to do that.
You can read some more of how Android has applied these tools to
its development process here:
http://source.android.com/download
http://source.android.com/submit-patches/workflow
http://source.android.com/download/using-repo
Although the current tool documentation is only on the Android
site, both the repo and Gerrit tools are not specific to Android
and are designed to be applied to any project that wants to use a
similar process.
repo and Gerrit are actually developed with themselves. You can
use repo to fetch repo:
curl http://android.git.kernel.org/repo >~/bin/repo
chomd a+x ~/bin/repo
mkdir myrepo
cd myrepo
repo init -u git://android.git.kernel.org/tools/manifest.git
repo sync
The "git status" output I was talking about before is the "repo
status" subcommand, e.g.:
$ echo '# test' >>repo/repo ; # modify a tracked file
$ repo status
project repo/ (*** NO BRANCH ***)
-m repo
--
Shawn.
^ permalink raw reply
* Re: error: packfile while git fsck
From: Nicolas Ferre @ 2008-10-22 15:22 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <alpine.LFD.2.00.0810221049340.26244@xanadu.home>
Nicolas Pitre :
> On Wed, 22 Oct 2008, Nicolas Ferre wrote:
>
>> Hi all,
>> (please cc me on response)
>>
>> I am facing error during git status & git fsck on my tree.
>> This tree is cloned from various linux kernel trees.
>>
>> Here are a sample of the error I see :
>>
>> $ git fsck
>> error: packfile
>> .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack does not
>> match index
>> error: packfile
>> .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack cannot be
>> accessed
> [...]
>
> What git version?
$ git --version
git version 1.5.3.7
Kind regards,
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH] rebase-i-p: delay saving current-commit to REWRITTEN if squashing
From: Johannes Schindelin @ 2008-10-22 15:21 UTC (permalink / raw)
To: Jeff King; +Cc: Stephen Haberman, gitster, git
In-Reply-To: <20081022125149.GA17092@coredump.intra.peff.net>
Hi,
On Wed, 22 Oct 2008, Jeff King wrote:
> On Wed, Oct 15, 2008 at 02:44:36AM -0500, Stephen Haberman wrote:
>
> > + if [ "$fast_forward" == "t" ]
>
> This one even fails on my Linux box. :) "==" is a bash-ism.
Did we not also prefer "test" to "["?
Ciao,
Dscho
^ permalink raw reply
* Re: Start git svn clone at specific revision for cloning subprojects in large svn repositories?
From: Michael J Gruber @ 2008-10-22 15:08 UTC (permalink / raw)
To: Jeff Kowalczyk; +Cc: git
In-Reply-To: <pan.2008.10.22.15.00.21.403423@yahoo.com>
Jeff Kowalczyk venit, vidit, dixit 10/22/08 17:00:
> I would like to git svn clone subprojects from a large community
> subversion repository (plone collective).
>
> The repository is currently at 74K commits, but subprojects of interest
> are typically much more recent, and their initial import revision is known.
>
> I would like to avoid a) unnecessary traffic to the svn server and b)
> the very long delay in git svn cloning these subprojects.
>
> Is there a way to specfiy a starting revision to git svn clone?
Your friendly man page provider says:
-r <ARG>, --revision <ARG>
Used with the fetch command.
This allows revision ranges for partial/cauterized history to
be supported. $NUMBER, $NUMBER1:$NUMBER2 (numeric
ranges), $NUMBER:HEAD, and BASE:$NUMBER are all supported.
This can allow you to make partial mirrors when running
fetch; but is generally not recommended because history
will be skipped and lost.
Usage of "Scroll Down" is strongly advised when viewing git help svn ;)
Michael
P.S.: It works nicely, don't mind the warning in the man page if you
know the start rev for sure.
^ permalink raw reply
* Re: Start git svn clone at specific revision for cloning subprojects in large svn repositories?
From: Jacob Helwig @ 2008-10-22 15:07 UTC (permalink / raw)
To: Jeff Kowalczyk; +Cc: git
In-Reply-To: <pan.2008.10.22.15.00.21.403423@yahoo.com>
On Wed, Oct 22, 2008 at 08:00, Jeff Kowalczyk <jtk@yahoo.com> wrote:
> I would like to git svn clone subprojects from a large community
> subversion repository (plone collective).
>
> The repository is currently at 74K commits, but subprojects of interest
> are typically much more recent, and their initial import revision is known.
>
> I would like to avoid a) unnecessary traffic to the svn server and b)
> the very long delay in git svn cloning these subprojects.
>
> Is there a way to specfiy a starting revision to git svn clone?
>
> Thanks.
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Try git svn init, then git svn fetch --revision <revision#>:HEAD.
This is what I use for some of our larger projects at work.
^ permalink raw reply
* Start git svn clone at specific revision for cloning subprojects in large svn repositories?
From: Jeff Kowalczyk @ 2008-10-22 15:00 UTC (permalink / raw)
To: git
I would like to git svn clone subprojects from a large community
subversion repository (plone collective).
The repository is currently at 74K commits, but subprojects of interest
are typically much more recent, and their initial import revision is known.
I would like to avoid a) unnecessary traffic to the svn server and b)
the very long delay in git svn cloning these subprojects.
Is there a way to specfiy a starting revision to git svn clone?
Thanks.
^ permalink raw reply
* Re: Working with remotes; cloning remote references
From: Michael J Gruber @ 2008-10-22 14:59 UTC (permalink / raw)
To: Marc Branchaud; +Cc: Peter Harris, git
In-Reply-To: <48FDF28A.9060606@xiplink.com>
Marc Branchaud venit, vidit, dixit 10/21/08 17:17:
> I believe git lets you track the origin's _branches_ not the origin's
> _remotes_. I don't think --mirror does what I'm looking for, because
> (side effects aside) it only deals with branches, not remotes.
>
> I find myself getting confused, and I think it's because the files in
> .git/refs/remotes/ are indeed tracking branches on remote repositories.
> So I think our conversation gets a bit circular because our ideas of a
> "remote" differ.
Yes, I think there are multiple uses:
- a remote repository (referenced to by an URL)
- a remote config (as created by git remote add)
- a remote branch (a branch in your local repo which is a copy of a
branch in a remote repo; stored under refs/remotes, never to be modified
locally)
- a (remote) tracking branch (a local branch which is set up to pull
from a remote branch by default)
Only the first of these 4 is something resides "remotely". Of course,
"remote URL" could be a path on the local file system or even ".".
> "git remote add" does two things (maybe more?): It adds a [remote]
> section to the .git/config file, and it adds a branch reference in
> .git/refs/remotes/.
Yes.
> I think what I'd like is for the clone to be able
> to obtain both these things from the origin. The reason I think it's
> useful is that it would let the clone pull directly from the origin's
> remote repositories, without having to directly specify the remote
> repository's URL and branch name.
>
> Fundamentally, I'm looking to do exactly
>
> clone/$ git pull -s subtree /path/to/ThingOne master
>
> i.e. pull stuff from one of main's remotes directly into the clone. But
> I want to replace the "/path/to/ThingOne master" part with something
> that means "use whatever URL and branch name was defined in the origin
> for this remote".
>
> My questions are: Am I right in thinking this is desirable?
I've got the strong impression you desire it...
Seriously, it seems desirable in cases where the remote URL changes
frequently; say, because the upstream maintainer (maintainer of
ThingOne) gets hit by a bus frequently, or walks the wrong streets in LA
at the wrong time of the day. (I guess my seriousness ended with the
";".) Clones would follow those changes transparently then (if that
feature existed).
> Is there
> already some way to do this?
None that I know of.
> If not, is it something worth
> implementing? (I'm happy to roll up my own sleeves here...)
First you should decide whether it is worth for you. Comments on the
list tend to kick in once people see a proposed implementation. A viable
strategy could be, mimicking git submodule behaviour in part:
- Implement "git remote export reponame" which takes an existing remote
config from .git/config, writes it to .gitremotes and checks in (or
better: stages for commit) the file .gitremotes [you would use this on main]
- Implement "git remote import" which reads the file .gitremotes and
adds remote config to .git/config. [you would use this on clones]
- Change "git remote update" to take updates to .gitremotes into account
before doing its usual routine (perhaps based on a config with default
off, or a command line option, or better both)
Downside is that .gitremotes is tracked would show up as a file in the
repo, but I can't come up with a better way which is as simple as the
above. .gitremotes could be stored in a specially named branch, though.
> I hope that clarifies things. Sorry for taking so long to get here!
Don't worry. I take partial blame ;)
And thanks for trying to match up your workflow with git.
Cheers,
Michael
^ permalink raw reply
* Re: [PATCH] rehabilitate 'git index-pack' inside the object store
From: Nguyen Thai Ngoc Duy @ 2008-10-22 14:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nicolas Pitre, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0810211856090.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On 10/22/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> So I propose this change in semantics:
>
> - setup_git_directory_gently(): rename to discover_git_directory(),
> and avoid any chdir() at all.
> - setup_git_directory(): keep the semantics that it chdir()s to the
> worktree, or to the git directory for bare repositories.
>
> Using _gently() even for RUN_SETUP builtins should solve the long standing
> pager problem, too.
Also, from [1] may be only set default git_dir in setup_git_env()
after setup_git_directory() has been called and before
setup_work_tree() is called (if any)? If not, die().
[1] http://article.gmane.org/gmane.comp.version-control.git/98849
--
Duy
^ permalink raw reply
* Re: error: packfile while git fsck
From: Nicolas Pitre @ 2008-10-22 14:52 UTC (permalink / raw)
To: Nicolas Ferre; +Cc: git
In-Reply-To: <48FF337F.3050505@atmel.com>
On Wed, 22 Oct 2008, Nicolas Ferre wrote:
> Hi all,
> (please cc me on response)
>
> I am facing error during git status & git fsck on my tree.
> This tree is cloned from various linux kernel trees.
>
> Here are a sample of the error I see :
>
> $ git fsck
> error: packfile
> .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack does not
> match index
> error: packfile
> .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack cannot be
> accessed
[...]
What git version?
> Did I do something wrong (merging files while fetching) ?
Unlikely.
Nicolas
^ permalink raw reply
* error: packfile while git fsck
From: Nicolas Ferre @ 2008-10-22 14:06 UTC (permalink / raw)
To: git
Hi all,
(please cc me on response)
I am facing error during git status & git fsck on my tree.
This tree is cloned from various linux kernel trees.
Here are a sample of the error I see :
$ git fsck
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack does not match index
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack cannot be accessed
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack does not match index
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack cannot be accessed
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack does not match index
[..]
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack cannot be accessed
dangling blob fe130d58453393f15e0db82bca18f35998689a87
dangling commit 2515ddc6db8eb49a79f0fe5e67ff09ac7c81eab4
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack does not match index
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack cannot be accessed
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack does not match index
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack cannot be accessed
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack does not match index
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack cannot be accessed
dangling commit 6bb7a935489dab20802dde6c2cb7d8582f4849bf
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack does not match index
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack cannot be accessed
dangling commit 4aba41ea8bdc1b475861f5e5c1649ab20251090c
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack does not match index
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack cannot be accessed
[..]
$ git verify-pack .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack
pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack
nferre@bendor:linux-2.6-arm > git verify-pack .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack
error: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack does not match index
fatal: packfile .git/objects/pack/pack-2ab31ad1f8cb69d091a56fe936634e4796606d49.pack cannot be accessed
What can I do to recover my git archive ?
Did I do something wrong (merging files while fetching) ?
Is it related to a known issue (I cannot figure out if it is
after some googling) ?
Thanks for your help. Regards,
--
Nicolas Ferre
^ permalink raw reply
* Re: Does a `git pull' write to the origin repository in any way?
From: Brett Ryan @ 2008-10-22 14:27 UTC (permalink / raw)
To: Marc Weber, git
In-Reply-To: <20081022132517.GM3988@gmx.de>
Thanks Marc. I agree the dev cycle is a little strange, though we're
still using a 4GL environment (Progress) from the 70's where all the
developers have no prior experience to version control except for
renaming files to ${name}.yyyymmdd.
My apologies for being a little light headed I've only been using git
for about a week now, currently I'm the main merger for CVS and
looking for an alternative. First impressions of `git' to me are
fantastic and it seems to fit right, what I need to do is figure out a
good dev cycle that my peers can use as they're all used to working
int he same directory and just simply yelling out to each other "I'm
about to edit file {x}", making me cringe each time.
Anyway Marc your answer was all I'm after, it could have been
something I goofed, just needed clarification that a pull wasn't going
to touch the rep that the pull is pulling from.
Thanks,
-Brett
On Thu, Oct 23, 2008 at 12:25 AM, Marc Weber <marco-oweber@gmx.de> wrote:
> On Wed, Oct 22, 2008 at 08:00:11PM +1100, Brett Ryan wrote:
>> Greetings, the reason I ask this question is because my pattern of
>> development is to create local source git repositories on my home
>> directory, then pull them to the central location. I found myself
>> getting the error `unable to create temporary sha1 filename
>> .git/objects/11: File exists' which after investigation found that
>> there were paths in `.git/objects/' owned by root which is who I use
>> to do the pull from my home directory using sudo.
> Aeh.. about which repo are you talking here? I guess it's not the one
> owned by root because otherwise this would be normal..
>
> Hi Brett, I'm not sure where the problem comes form. But I feel your dev
> cycle is kind of wired.
> If you can login as root using ssh you can also do it the "normal" (?)
> way:
>
> # user dir
> git remote add root_repo ssh://root@localhost/path-to-root-repo
> git pull root_repo # then resolve conflicts if any
> git push root_repo # update the root repo
>
> This way you always have conflicts in your local repo and never on the
> root one which is preferable (IMHO)..
>
> git-fetch doesn't list a way to access another repo by "su(do)" which
> might be the best way here ? This could be convinient because you
> would'nt have to setup an extra group to access the same repo as root
> and user (?)
>
> You're right that git pull *should not* modify any files from the repo
> its pulling from.. But I don't know enough about git internals to say
> more about this. All I know is that git clone might have created some
> hardlinks.. But I'm not sure how this interfers with file permissions.
>
> I hope someone else can give a more accurate reply.
>
> Marc Weber
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] rehabilitate 'git index-pack' inside the object store
From: Nguyen Thai Ngoc Duy @ 2008-10-22 14:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nicolas Pitre, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0810211856090.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On 10/22/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> So I propose this change in semantics:
>
> - setup_git_directory_gently(): rename to discover_git_directory(),
> and avoid any chdir() at all.
> - setup_git_directory(): keep the semantics that it chdir()s to the
> worktree, or to the git directory for bare repositories.
>
> Using _gently() even for RUN_SETUP builtins should solve the long standing
> pager problem, too.
One more thing: "git foo -h" with RUN_SETUP won't run if repository is
not found. Maybe just drop RUN_SETUP and let subcommands call
setup_git_directory()
--
Duy
^ 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