* [guilt] Bug with guilt patchbomb
From: Thomas Petazzoni @ 2008-09-09 8:12 UTC (permalink / raw)
To: jsipek; +Cc: git
Hi,
I'm using guilt 0.28-1 (Ubuntu package) and git-core 1.5.4.3-1ubuntu2.
When I use guilt patchbomb, I get some scary output from git-rev-list:
Enter all the Cc: email addresses (separated by space):
usage: git-rev-list [OPTION] <commit-id>... [ -- paths... ]
limiting output:
--max-count=nr
--max-age=epoch
--min-age=epoch
--sparse
--no-merges
--remove-empty
--all
--stdin
--quiet
ordering output:
--topo-order
--date-order
formatting output:
--parents
--objects | --objects-edge
--unpacked
--header | --pretty
--abbrev=nr | --no-abbrev
--abbrev-commit
--left-right
special purpose:
--bisect
--bisect-vars
--bisect-all
/usr/bin/guilt-patchbomb: 98: Bad substitution
Proceed with patchbomb (this is the last chance to abort)? [y/N]
Sincerly,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Re: Commit templates are not readable after 'make install'
From: Junio C Hamano @ 2008-09-10 7:23 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Anatol Pomozov, git
In-Reply-To: <48C76A88.2050109@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
>> diff --git c/templates/Makefile w/templates/Makefile
>> index 0722a92..a12c6e2 100644
>> --- c/templates/Makefile
>> +++ w/templates/Makefile
>> @@ -31,9 +31,11 @@ boilerplates.made : $(bpsrc)
>> dir=`expr "$$dst" : '\(.*\)/'` && \
>> mkdir -p blt/$$dir && \
>> case "$$boilerplate" in \
>> - *--) ;; \
>> - *) cp -p $$boilerplate blt/$$dst ;; \
>> - esac || exit; \
>> + *--) continue;; \
>> + esac && \
>> + cp $$boilerplate blt/$$dst && \
>> + if test -x "blt/$$dst"; then rx=rx; else rx=r; fi && \
>> + chmod a+$$rx "blt/$$dst" || exit; \
>> done && \
>> date >$@
>
> Since only hooks need to be executable, how about this instead:
Hmm. I tried to avoid hardcoding "it so happens that currently the only
executables are hooks".
> diff --git a/templates/Makefile b/templates/Makefile
> index 0722a92..80cd000 100644
> --- a/templates/Makefile
> +++ b/templates/Makefile
> @@ -32,7 +32,12 @@ boilerplates.made : $(bpsrc)
> mkdir -p blt/$$dir && \
> case "$$boilerplate" in \
> *--) ;; \
> - *) cp -p $$boilerplate blt/$$dst ;; \
> + hooks--*) \
> + cp -p "$$boilerplate" "blt/$$dst" && \
> + chmod a+rx "blt/$$dst";; \
> + *) \
> + cp -p "$$boilerplate" "blt/$$dst" && \
> + chmod a+r "blt/$$dst";; \
> esac || exit; \
> done && \
> date >$@
^ permalink raw reply
* Re: [PATCH v2] Git.pm: Use File::Temp->tempfile instead of ->new
From: Tom G. Christensen @ 2008-09-10 7:16 UTC (permalink / raw)
To: Marcus Griep
Cc: Git Mailing List, Eric Wong, Junio C Hamano, Abhijit Menon-Sen
In-Reply-To: <48C6B886.7020108@griep.us>
Marcus Griep wrote:
> Tom G. Christensen wrote:
>> The testsuite now passes t9100-git-svn-basic.sh and instead fails at
>> t9108-git-svn-glob.sh but this appears to be unrelated to the File::Temp
>> issue.
>>
>> --- expect.three 2008-09-09 07:34:39.000000000 +0000
>> +++ stderr.three 2008-09-09 07:34:42.000000000 +0000
>> @@ -1,2 +1,3 @@
>> +Parentheses missing around "my" list at
>> /home/tgc/projects/git/t/../git-svn line 4429.
>> Only one set of wildcard directories (e.g. '*' or '*/*/*') is
>> supported: 'branches/*/t/*'
>>
>> * FAIL 3: test disallow multi-globs
>
> It's probably another back-portability issue (It's not failing in my testsuite).
> However, I think that I know the offending line. Can you give me the text of
> your line 4429 in git-svn and I'll submit a separate patch to fix that back
> portability issue.
>
git-svn:4429:
pipe my $rfd, my $wfd or return;
I know next to nothing about perl but I put () around my, my and then
the test passes.
However it now fails in t9700/test.pl:
t9700 $ ./test.pl -i -v
ok 1 - use Git;
Bareword "STDERR" not allowed while "strict subs" in use at ./test.pl
line 38.
Execution of ./test.pl aborted due to compilation errors.
1..1
# Looks like your test died just after 1.
Brandon Casey already posted a patch for this that also fixes the use of
File::Temp->New in t9700/test.pl:
http://article.gmane.org/gmane.comp.version-control.git/92791
Applying it allowed a full a run of the testsuite to complete without error.
'/bin/sh' ./aggregate-results.sh test-results/t*-*
fixed 1
success 3709
failed 0
broken 2
total 3712
-tgc
^ permalink raw reply
* git-p4: redirecting p4 error messages
From: dhruva @ 2008-09-10 7:14 UTC (permalink / raw)
To: GIT SCM; +Cc: Simon Hausmann
Hi,
In our environment, there are lot of client side hooks in p4. They give lot of verbose information that clutters the useful output of git-p4. I have therefore added an option to redirect p4 stderr to anywhere (file or /dev/null or stdout) optionally. Would that be useful?
Since I am actively working on git-p4, I would like to know what features the git-p4 user community would like to have. That will give me more ideas and I can chip in and implement them.
-dhruva
Unlimited freedom, unlimited storage. Get it now, on http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html/
^ permalink raw reply
* Re: rsync vs. git-push/pull ? (+kudus)
From: Matthieu Moy @ 2008-09-10 7:05 UTC (permalink / raw)
To: Ramagudi Naziir; +Cc: git
In-Reply-To: <dfb262380809062311i3fffb900m5d73f5396b403dbe@mail.gmail.com>
"Ramagudi Naziir" <naziirr@gmail.com> writes:
> Hi all,
>
> I have several local git repositories on my machine. I'm the only
> user, and use them only locally. Now, sometimes when I need to work
> remotely, I just rsync my repositories to my laptop, and keep working
> there. When I finish (few hours, days or sometimes weeks later), I
> just rsync everything back to my local git repositories on my main
> workstation, and continue working there.
>
> Now I was wondering whether it's OK or whether there are bad
Clearly, it's more risky to use rsync: git knows which repository is
ahead of the other, knows it has to do a merge in case the two
diverged, ... but if you really know what you're doing, this should be
OK.
Technically, there's at least one case which can be problematic if you
"rsync" without "--delete": packed references. For example, the tip of
the master branch is normally stored in .git/refs/heads/master, but
after packing, git removes this file, and puts all the references in
.git/packed-refs (so it's just 1 file, eats less inodes, less
round-trips for HTTP fetch, ...). Then, if .git/refs/heads/master is
re-created, it takes precedence over .git/packed-refs. So if you
"git gc" locally, and then "rsync remote/ local/", you'll end up with
an old .git/refs/heads/master that overrides the new .git/packed-refs,
and git will behave as if you went backwards in history.
Easily fixable, but I've been hit by this once and took time to
understand what was happening ;-).
--
Matthieu
^ permalink raw reply
* Re: rsync vs. git-push/pull ? (+kudus)
From: Ramagudi Naziir @ 2008-09-10 6:35 UTC (permalink / raw)
To: David Brown; +Cc: git
In-Reply-To: <20080907073821.GA28289@linode.davidb.org>
Hi David,
On Sun, Sep 7, 2008 at 10:38 AM, David Brown <git@davidb.org> wrote:
> On Sun, Sep 07, 2008 at 09:11:47AM +0300, Ramagudi Naziir wrote:
>
>> I really prefer rsync to git-push/pull since it is much more easier -
>> It's one command that syncs my whole working folder, including the git
>> repositories..
>
> I used to do this quite a bit until after a few times I forgot to sync
> before changing things. I solved this by creating a bare repo I could
> push/pull from, and pushing one of them to it, then fetching and
> merging in the other.
can you please elaborate on this technique ? I don't really get it.
You mean you have an empty git repository somewhere, with which you
are synchronizing all other repositories ?
>
> After getting more familiar with git, I now use git with push/pull for
> pretty much anything I want synchronized. It nicely keeps track of
> what I've done, whereas it is easier with rsync, or even unison, to
> forget to do the sync.
so you have myriad of git repositories ? and you push/pull all of them
every time you move to another station ? I also have a lot of git
repositories, even for stuff other than source code projects.
thank you
naziir
>
> David
>
^ permalink raw reply
* Re: Commit templates are not readable after 'make install'
From: Johannes Sixt @ 2008-09-10 6:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Anatol Pomozov, git
In-Reply-To: <7vprnd5b07.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> Fix permission bits on sources checked out with an overtight umask
>
> Two patches 9907721 (templates/Makefile: don't depend on local umask
> setting, 2008-02-28) and 96cda0b (templates/Makefile: install is
> unnecessary, just use mkdir -p, 2008-08-21) tried to prevent an overtight
> umask the builder/installer might have from screwing over the installation
> procedure, but we forgot there was another source of trouble. If the
> person who checked out the source tree had an overtight umask, it will
> leak out to the built products, which is propagated to the installation
> destination.
>
> templates/Makefile | 8 +++++---
> 1 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git c/templates/Makefile w/templates/Makefile
> index 0722a92..a12c6e2 100644
> --- c/templates/Makefile
> +++ w/templates/Makefile
> @@ -31,9 +31,11 @@ boilerplates.made : $(bpsrc)
> dir=`expr "$$dst" : '\(.*\)/'` && \
> mkdir -p blt/$$dir && \
> case "$$boilerplate" in \
> - *--) ;; \
> - *) cp -p $$boilerplate blt/$$dst ;; \
> - esac || exit; \
> + *--) continue;; \
> + esac && \
> + cp $$boilerplate blt/$$dst && \
> + if test -x "blt/$$dst"; then rx=rx; else rx=r; fi && \
> + chmod a+$$rx "blt/$$dst" || exit; \
> done && \
> date >$@
Since only hooks need to be executable, how about this instead:
diff --git a/templates/Makefile b/templates/Makefile
index 0722a92..80cd000 100644
--- a/templates/Makefile
+++ b/templates/Makefile
@@ -32,7 +32,12 @@ boilerplates.made : $(bpsrc)
mkdir -p blt/$$dir && \
case "$$boilerplate" in \
*--) ;; \
- *) cp -p $$boilerplate blt/$$dst ;; \
+ hooks--*) \
+ cp -p "$$boilerplate" "blt/$$dst" && \
+ chmod a+rx "blt/$$dst";; \
+ *) \
+ cp -p "$$boilerplate" "blt/$$dst" && \
+ chmod a+r "blt/$$dst";; \
esac || exit; \
done && \
date >$@
^ permalink raw reply related
* Re: rsync vs. git-push/pull ? (+kudus)
From: Ramagudi Naziir @ 2008-09-10 6:31 UTC (permalink / raw)
To: david; +Cc: git
In-Reply-To: <alpine.DEB.1.10.0809062326000.8096@asgard.lang.hm>
Hi David,
On Sun, Sep 7, 2008 at 9:27 AM, <david@lang.hm> wrote:
> On Sun, 7 Sep 2008, Ramagudi Naziir wrote:
>
>> Hi all,
>>
>> I have several local git repositories on my machine. I'm the only
>> user, and use them only locally. Now, sometimes when I need to work
>> remotely, I just rsync my repositories to my laptop, and keep working
>> there. When I finish (few hours, days or sometimes weeks later), I
>> just rsync everything back to my local git repositories on my main
>> workstation, and continue working there.
>>
>> Now I was wondering whether it's OK or whether there are bad
>> implication I might not think of working this way. For example, maybe
>> some of these little git files are named differently on each machine,
>> and rsyncing them back and forth makes me piling a lot of clutter (in
>> that case maybe git-gc will clean up everything). Or maybe something
>> else horrid is going on and I really should just use git-push or pull.
>
> the git files are names by their content so you don't need to worry about
> them being named differently
But can I end up having a lot of clutter ? e.g. if these files change,
then rsync will copy the new files, and the old ones will still be
kept, piling up like crud. is this correct ? is it problematic ? will
git-gc fix it ?
^ permalink raw reply
* Re: [PATCH] Rename dynamic memory allocation functions to their "x" version
From: Dotan Barak @ 2008-09-10 6:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vprnczlkx.fsf@gitster.siamese.dyndns.org>
On Wed, Sep 10, 2008 at 7:11 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Dotan Barak <dotanba@gmail.com> writes:
>
>> In places that the standard malloc/strdup is used without checking
>> if the allocation was successful, I replaced it to xmalloc/xstrdup
>> which check the memory allocation result.
>>
>> Signed-off-by: Dotan Barak <dotanba@gmail.com>
>
> Looks good. Will apply, but I'd retitle it (it is not "rename").
>
Yes, you are right, i guess "replace" is better ...
Next time..
;)
Dotan
> Thanks.
>
>
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Stephen R. van den Berg @ 2008-09-10 5:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jakub Narebski, git
In-Reply-To: <alpine.LFD.1.10.0809091722010.3384@nehalem.linux-foundation.org>
Linus Torvalds wrote:
>On Wed, 10 Sep 2008, Stephen R. van den Berg wrote:
>> As you might have noticed, the actual process of pulling/fetching
>> explicitly does *not* pull in the objects being pointed to.
>.. which makes them _local_ data, which in turn means that they should not
>be in the object database at all.
>IOW, i you want this for local reasons, you should use a local database,
>like the index or the reflogs (and I don't mean "like the index" in the
>sense that it would look _anything_ like that file, but in the sense that
>it's a purely local thing and doesn't show up in the object database).
But then how would someone who clones the repository get at the information?
The information is essential to understand backports between the various
stable branches.
The origin links describe the evolving state of a patch (i.e. just like
regular commits/parents store snapshots of the whole tree, the origin
links store snapshots of a patch as it evolves through time).
--
Sincerely,
Stephen R. van den Berg.
"Am I paying for this abuse or is it extra?"
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Stephen R. van den Berg @ 2008-09-10 5:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Jakub Narebski, git
In-Reply-To: <7vej3s223f.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
>"Stephen R. van den Berg" <srb@cuci.nl> writes:
>> Junio C Hamano wrote:
>>>As for "by the way ... was used to make this commit": this is git. So how
>>>you arrived at the tree state you record in a commit *does not matter*.
>> The typical use case for the origin links is in a project with several
>> long-lived branches which use cherry-picks to backport amongst them.
>> There is no real other way to solve this case, except for some rather
>> kludgy stuff in the free-form commit message which doesn't mesh well
>> with rebase/filter-branch/stgit etc.
>> As to "does not matter": then why does git store parent links?
>The parent links describe *where* you came from, not *how*.
>And if you think the difference is just "semantics", then you haven't
>grokked the first lesson I gave in this thread. "parents" record the
>reference points against which you make "this resulting commit suits the
>purpose of my branch better than any histories leading to these commits".
The last question of mine was/is a rethorical one.
Consider the typical use case I describe above. The developer usually
has just created a commit in the developmentbranch, tested it, and deems
the patch worthwhile enough to backport it to the latest stable branch.
So he cherry picks the from the development branch to the latest stable
branch.
Then tests it, and decides to backport it to the older stable branch,
so he cherry-picks it again, and commits it there too. The is repeated
in rapid succession on three older stable branches as well.
Basically that means that for the patch itself, there is a path in
history to follow as well. I.e. the patch itself evolves over time.
Now, when another developer makes an additional change to this patch
in one of the stable versions, it is very helpful to actually be able to
have git tell you where the original patch came from and to follow back
the chain upward. It allows you to forward/backward port the new change
more easily.
Basically, the normal parent links allow you to follow evolving
snapshots of the complete source-tree, whereas the origin links allow
you to follow evolving snapshots of a patch.
As it happens, the shortest way to describe a patch in git is by
specifying two commits of which the difference is exactly your patch.
--
Sincerely,
Stephen R. van den Berg.
"Am I paying for this abuse or is it extra?"
^ permalink raw reply
* Re: PATCH: git-p4 optional handling of RCS keywords
From: Junio C Hamano @ 2008-09-10 5:35 UTC (permalink / raw)
To: dhruva; +Cc: Simon Hausmann, GIT SCM, Jing Xue
In-Reply-To: <201191.94038.qm@web95010.mail.in2.yahoo.com>
dhruva <dhruva@ymail.com> writes:
> @@ -975,10 +978,11 @@ class P4Sync(Command):
> sys.stderr.write("p4 print fails with: %s\n" % repr(stat))
> continue
>
> - if stat['type'] in ('text+ko', 'unicode+ko', 'binary+ko'):
> - text = re.sub(r'(?i)\$(Id|Header):[^$]*\$',r'$\1$', text)
> - elif stat['type'] in ('text+k', 'ktext', 'kxtext', 'unicode+k', 'binary+k'):
> - text = re.sub(r'\$(Id|Header|Author|Date|DateTime|Change|File|Revision):[^$]*\$',r'$\1$', text)
> + if kwstrip:
> + if stat['type'] in ('text+ko', 'unicode+ko', 'binary+ko'):
> + text = re.sub(r'(?i)\$(Id|Header):[^$]*\$',r'$\1$', text)
> + elif stat['type'] in ('text+k', 'ktext', 'kxtext', 'unicode+k', 'binary+k'):
> + text = re.sub(r'\$(Id|Header|Author|Date|DateTime|Change|File|Revision):[^$]*\$',r'$\1$', text)
A style tip.
It makes it easier to convince others that you didn't screw up in the
conversion if you cascade the code this way instead:
- if stat['type'] in ('text+ko', 'unicode+ko', 'binary+ko'):
+ if not kwstrip:
+ pass
+ elif stat['type'] in ('text+ko', 'unicode+ko', 'binary+ko'):
text = re.sub(r'(?i)\$(Id|Header):[^$]*\$',r'$\1$', text)
elif stat['type'] in ('text+k', 'ktext', 'kxtext', 'unicode+k', 'binary+k'):
text = re.sub(r'\$(Id|Header|Author|Date|DateTime|Change|...
This technique not just only makes the patch smaller and easier to review,
it also makes the result less deeply nested and easier to read as well.
^ permalink raw reply
* Fw: PATCH: git-p4 optional handling of RCS keywords [was: Re: git-p4 and keyword expansion]
From: dhruva @ 2008-09-10 5:20 UTC (permalink / raw)
To: GIT SCM
For some reason, my mail did not go through the git mailing list, I am resending. Please excuse if it is a duplicate!
----- Forwarded Message ----
> From: dhruva <dhruva@ymail.com>
> To: Simon Hausmann <simon@lst.de>
> Cc: GIT SCM <git@vger.kernel.org>; Jing Xue <jingxue@digizenstudio.com>
> Sent: Wednesday, 10 September, 2008 10:48:23 AM
> Subject: Re: PATCH: git-p4 optional handling of RCS keywords [was: Re: git-p4 and keyword expansion]
>
> My earlier patch has an error... (I have almost always stumbled on first patch!)
>
> here is the fixed one:
>
> diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
> index 2216cac..c67b2e5 100755
> --- a/contrib/fast-import/git-p4
> +++ b/contrib/fast-import/git-p4
> @@ -16,6 +16,9 @@ from sets import Set;
>
> verbose = False
>
> +# Handling of RCS keyowrds. To ensure backward compatibility, the default
> +# is to strip keywords. Default behavior is controlled here
> +kwstrip = True
>
> def p4_build_cmd(cmd):
> """Build a suitable p4 command line.
> @@ -975,10 +978,11 @@ class P4Sync(Command):
> sys.stderr.write("p4 print fails with: %s\n" % repr(stat))
> continue
>
> - if stat['type'] in ('text+ko', 'unicode+ko', 'binary+ko'):
> - text = re.sub(r'(?i)\$(Id|Header):[^$]*\$',r'$\1$', text)
> - elif stat['type'] in ('text+k', 'ktext', 'kxtext', 'unicode+k',
> 'binary+k'):
> - text =
> re.sub(r'\$(Id|Header|Author|Date|DateTime|Change|File|Revision):[^$]*\$',r'$\1$',
> text)
> + if kwstrip:
> + if stat['type'] in ('text+ko', 'unicode+ko', 'binary+ko'):
> + text = re.sub(r'(?i)\$(Id|Header):[^$]*\$',r'$\1$', text)
> + elif stat['type'] in ('text+k', 'ktext', 'kxtext', 'unicode+k',
> 'binary+k'):
> + text =
> re.sub(r'\$(Id|Header|Author|Date|DateTime|Change|File|Revision):[^$]*\$',r'$\1$',
> text)
>
> contents[stat['depotFile']] = text
>
> @@ -1850,6 +1854,16 @@ def main():
> (cmd, args) = parser.parse_args(sys.argv[2:], cmd);
> global verbose
> verbose = cmd.verbose
> +
> + global kwstrip
> + kwval = gitConfig("git-p4.kwstrip")
> + if len(kwval) > 0:
> + kwval = kwval.lower();
> + if "false" == kwval:
> + kwstrip = False
> + elif "true" == kwval:
> + kwstrip = True
> +
> if cmd.needsGit:
> if cmd.gitdir == None:
> cmd.gitdir = os.path.abspath(".git")
>
>
>
> -dhruva
>
>
> ----- Original Message ----
> > From: dhruva
> > To: Simon Hausmann
> > Cc: GIT SCM ; Jing Xue
> > Sent: Wednesday, 10 September, 2008 10:43:26 AM
> > Subject: PATCH: git-p4 optional handling of RCS keywords [was: Re: git-p4 and
> keyword expansion]
> >
> > Hello,
> > I would like to submit my first patch to the git community.
> >
> > I have introduced a new configuration option to 'git-p4' "kwstrip". If
> enabled,
> > the RCS keywords gets unexpanded like it is done with out the patch and
> > disabling it explicitly retains the RCS keywords as in the original p4 source.
>
> > The default (in the absence) is 'false' to ensure backward compatibility. To
> > override, you can put the following lines in your '.gitconfig' file..
> >
> > [git-p4]
> > kwstrip = false
> >
> >
> >
> > The patch to git-p4 (based on origin/next branch):
> >
> > diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
> > index 2216cac..ad37d0b 100755
> > --- a/contrib/fast-import/git-p4
> > +++ b/contrib/fast-import/git-p4
> > @@ -16,6 +16,9 @@ from sets import Set;
> >
> > verbose = False
> >
> > +# Handling of RCS keyowrds. To ensure backward compatibility, the default
> > +# is to strip keywords. Default behavior is controlled here
> > +kwstrip = True
> >
> > def p4_build_cmd(cmd):
> > """Build a suitable p4 command line.
> > @@ -975,10 +978,11 @@ class P4Sync(Command):
> > sys.stderr.write("p4 print fails with: %s\n" % repr(stat))
> > continue
> >
> > - if stat['type'] in ('text+ko', 'unicode+ko', 'binary+ko'):
> > - text = re.sub(r'(?i)\$(Id|Header):[^$]*\$',r'$\1$', text)
> > - elif stat['type'] in ('text+k', 'ktext', 'kxtext', 'unicode+k',
> > 'binary+k'):
> > - text =
> >
> re.sub(r'\$(Id|Header|Author|Date|DateTime|Change|File|Revision):[^$]*\$',r'$\1$',
>
> > text)
> > + if kwstrip:
> > + if stat['type'] in ('text+ko', 'unicode+ko', 'binary+ko'):
> > + text = re.sub(r'(?i)\$(Id|Header):[^$]*\$',r'$\1$', text)
> > + elif stat['type'] in ('text+k', 'ktext', 'kxtext',
> 'unicode+k',
> > 'binary+k'):
> > + text =
> >
> re.sub(r'\$(Id|Header|Author|Date|DateTime|Change|File|Revision):[^$]*\$',r'$\1$',
>
> > text)
> >
> > contents[stat['depotFile']] = text
> >
> > @@ -1850,6 +1854,16 @@ def main():
> > (cmd, args) = parser..parse_args(sys..argv[2:], cmd);
> > global verbose
> > verbose = cmd.verbose
> > +
> > + global kwstrip
> > + kwval = gitConfig("git-p4.kwstrip")
> > + if len(kwval) > 0:
> > + kwval = kwval.lower();
> > + if "false" == kwval:
> > + kwstrip = False
> > + else if "true" == kwval:
> > + kwstrip = True
> > +
> > if cmd.needsGit:
> > if cmd.gitdir == None:
> > cmd.gitdir = os.path.abspath(".git")
> >
> >
> >
> > ----- Original Message ----
> > > From: Jing Xue
> > > To: dhruva
> > > Cc: GIT SCM
> > > Sent: Tuesday, 9 September, 2008 11:08:48 PM
> > > Subject: Re: git-p4 and keyword expansion
> > >
> > > On Tue, Sep 09, 2008 at 04:44:11PM +0530, dhruva wrote:
> > > > Hello,
> > >
> > > Hi,
> > >
> > > > I feel the configuration must be set the first time only, when you
> > > > clone using 'git-p4 clone'. Altering it in between will be very
> > > > confusing!
> > > > Ideally, the setting must be transferred when the git repo
> > > > (cloned from git-p4) is cloned using standard git. Is it something
> > > > possible (well, I am new to git and am exploring. Any extra
> > > > information would help).
> > > >
> > > > My proposal is as follows:
> > > > 1. Add an extra command line argument to 'git-p4 clone' to either
> > > > enable/disable keyword expansion
> > > > 2. Store that information under the .git folder in a file that is
> > > > copied when someone clones that repo
> > > > 3. Use the stored information in future 'git-p4 sync/rebase'
> > >
> > > Any way to make it optional would be welcome by me.
> >
> > Done
> >
> >
> > > If you do come up with a "formal" patch, you might want to
> > > explicitly add Simon Hausmann to the To list, for he's the git-p4
> > > author.
> >
> > Done
> >
> > -dhruva
> >
> >
> >
> > Add more friends to your messenger and enjoy! Go to
> > http://in.messenger.yahoo.com/invite/
> >
> > --
> > 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
>
>
>
> Unlimited freedom, unlimited storage. Get it now, on
> http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html/
Unlimited freedom, unlimited storage. Get it now, on http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html/
^ permalink raw reply
* PATCH: git-p4 optional handling of RCS keywords [was: Re: git-p4 and keyword expansion]
From: dhruva @ 2008-09-10 5:13 UTC (permalink / raw)
To: Simon Hausmann; +Cc: GIT SCM, Jing Xue
Hello,
I would like to submit my first patch to the git community.
I have introduced a new configuration option to 'git-p4' "kwstrip". If enabled, the RCS keywords gets unexpanded like it is done with out the patch and disabling it explicitly retains the RCS keywords as in the original p4 source. The default (in the absence) is 'false' to ensure backward compatibility. To override, you can put the following lines in your '.gitconfig' file..
[git-p4]
kwstrip = false
The patch to git-p4 (based on origin/next branch):
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 2216cac..ad37d0b 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -16,6 +16,9 @@ from sets import Set;
verbose = False
+# Handling of RCS keyowrds. To ensure backward compatibility, the default
+# is to strip keywords. Default behavior is controlled here
+kwstrip = True
def p4_build_cmd(cmd):
"""Build a suitable p4 command line.
@@ -975,10 +978,11 @@ class P4Sync(Command):
sys.stderr.write("p4 print fails with: %s\n" % repr(stat))
continue
- if stat['type'] in ('text+ko', 'unicode+ko', 'binary+ko'):
- text = re.sub(r'(?i)\$(Id|Header):[^$]*\$',r'$\1$', text)
- elif stat['type'] in ('text+k', 'ktext', 'kxtext', 'unicode+k', 'binary+k'):
- text = re.sub(r'\$(Id|Header|Author|Date|DateTime|Change|File|Revision):[^$]*\$',r'$\1$', text)
+ if kwstrip:
+ if stat['type'] in ('text+ko', 'unicode+ko', 'binary+ko'):
+ text = re.sub(r'(?i)\$(Id|Header):[^$]*\$',r'$\1$', text)
+ elif stat['type'] in ('text+k', 'ktext', 'kxtext', 'unicode+k', 'binary+k'):
+ text = re.sub(r'\$(Id|Header|Author|Date|DateTime|Change|File|Revision):[^$]*\$',r'$\1$', text)
contents[stat['depotFile']] = text
@@ -1850,6 +1854,16 @@ def main():
(cmd, args) = parser.parse_args(sys..argv[2:], cmd);
global verbose
verbose = cmd.verbose
+
+ global kwstrip
+ kwval = gitConfig("git-p4.kwstrip")
+ if len(kwval) > 0:
+ kwval = kwval.lower();
+ if "false" == kwval:
+ kwstrip = False
+ else if "true" == kwval:
+ kwstrip = True
+
if cmd.needsGit:
if cmd.gitdir == None:
cmd.gitdir = os.path.abspath(".git")
----- Original Message ----
> From: Jing Xue <jingxue@digizenstudio.com>
> To: dhruva <dhruva@ymail.com>
> Cc: GIT SCM <git@vger.kernel.org>
> Sent: Tuesday, 9 September, 2008 11:08:48 PM
> Subject: Re: git-p4 and keyword expansion
>
> On Tue, Sep 09, 2008 at 04:44:11PM +0530, dhruva wrote:
> > Hello,
>
> Hi,
>
> > I feel the configuration must be set the first time only, when you
> > clone using 'git-p4 clone'. Altering it in between will be very
> > confusing!
> > Ideally, the setting must be transferred when the git repo
> > (cloned from git-p4) is cloned using standard git. Is it something
> > possible (well, I am new to git and am exploring. Any extra
> > information would help).
> >
> > My proposal is as follows:
> > 1. Add an extra command line argument to 'git-p4 clone' to either
> > enable/disable keyword expansion
> > 2. Store that information under the .git folder in a file that is
> > copied when someone clones that repo
> > 3. Use the stored information in future 'git-p4 sync/rebase'
>
> Any way to make it optional would be welcome by me.
Done
> If you do come up with a "formal" patch, you might want to
> explicitly add Simon Hausmann to the To list, for he's the git-p4
> author.
Done
-dhruva
Add more friends to your messenger and enjoy! Go to http://in.messenger.yahoo.com/invite/
^ permalink raw reply related
* Re: [PATCH 6/6] t9400, t9401: use "git cvsserver" without dash
From: Junio C Hamano @ 2008-09-10 4:13 UTC (permalink / raw)
To: Jeff King; +Cc: Nanako Shiraishi, git
In-Reply-To: <20080909215635.GA4226@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Sep 09, 2008 at 02:38:31PM -0700, Junio C Hamano wrote:
>
>> My eyes are getting dry after looking at these s/git-/git / patches, so
>> please do not get offended if I leave these in my Inbox unread for a few
>> days.
>
> I did the same "look for conversion that should _not_ have occurred"
> check for these patches, and all look sane with two exceptions:
>
> - the cvsserver stuff that you mentioned
>
> - patch 4/6 changes the commit log message in a few cases for some "git
> svn" tests; presumably nothing is caring about the commit id's
> generated here, but I don't actually have svn installed to run the
> tests to be sure
Thanks. Will make sure I run these tests (I do not know offhand which svn
tests I am skipping).
^ permalink raw reply
* Re: [PATCH] Rename dynamic memory allocation functions to their "x" version
From: Junio C Hamano @ 2008-09-10 4:11 UTC (permalink / raw)
To: Dotan Barak; +Cc: git
In-Reply-To: <200809092157.10185.dotanba@gmail.com>
Dotan Barak <dotanba@gmail.com> writes:
> In places that the standard malloc/strdup is used without checking
> if the allocation was successful, I replaced it to xmalloc/xstrdup
> which check the memory allocation result.
>
> Signed-off-by: Dotan Barak <dotanba@gmail.com>
Looks good. Will apply, but I'd retitle it (it is not "rename").
Thanks.
^ permalink raw reply
* Re: [PATCH v2] Git.pm: Use File::Temp->tempfile instead of ->new
From: Junio C Hamano @ 2008-09-10 3:53 UTC (permalink / raw)
To: Eric Wong
Cc: Marcus Griep, Git Mailing List, Tom G. Christensen,
Abhijit Menon-Sen
In-Reply-To: <20080909015338.GA15974@yp-box.dyndns.org>
Eric Wong <normalperson@yhbt.net> writes:
> Marcus Griep <marcus@griep.us> wrote:
>> Perl 5.8.0 ships with File::Temp 0.13, which does not have the new()
>> interface introduced in 0.14, as pointed out by Tom G. Christensen.
>>
>> This modifies Git.pm to use the more established tempfile() interface
>> and updates 'git svn' to match.
>>
>> Signed-off-by: Marcus Griep <marcus@griep.us>
>> ---
>>
>> This patch v2 cleans up a few code items, corrects a misspelling,
>> and ensures that the temp file gets unlinked when we exit, now
>> that we are requesting the filename. Otherwise, the previous
>> comments stand:
>>
>> Per the earlier patch versions by Abhijit Menon-Sen and Tom G. Christensen.
>> Both of you may want to run a test and add your 'Tested-by' to the thread
>> if everything works out before Eric Wong adds his 'Acked-by'.
>
> Thanks Marcus, this works for me.
> (Perl 5.10.0, so no compatibility issues).
>
> <bikeshed>
> Can we rename temp_fname() to temp_path(), though? "fname"
> just doesn't look right in the API to me...
> </bikeshed>
Ok, so will you take the patch with bikeshed fixes and feed the result to
me with a pull-request, or shall I do that myself? I do not mind doing
this either way --- just trying to avoid duplicated work.
This is a 'maint' material, right?
^ permalink raw reply
* Re: git apply vs. renamed files index mismatch
From: Junio C Hamano @ 2008-09-10 3:31 UTC (permalink / raw)
To: avorontsov; +Cc: Scott Wood, Becky Bruce, linuxppc-dev, git
In-Reply-To: <20080909151446.GA10395@oksana.dev.rtsoft.ru>
Anton Vorontsov <avorontsov@ru.mvista.com> writes:
> On Tue, Sep 09, 2008 at 07:45:19AM -0700, Junio C Hamano wrote:
> ...
>> ... It's an interesting idea from git person's point of
>> view (i.e. "would be fun to implement"), but I doubt it would be useful in
>> practice, because:
>>
>> (1) You often do not have the identically matching preimage;
>>
>> (2) More importantly, it is not unusual for people to *edit* the patch in
>> their MUA (think of typofixes), after getting it out of git.
>
> Not for rename patches...
a. Why not? Even if your patch is (totally uninteresting) pure rename, it
is natural to review the patch before you send out, and it also is
natural to get tempted to fix typoes, just for a straight normal patch.
b. If you can expect good behaviour out of people, by declaring "Not for
rename patches" as your guarantee, what's the point of this discussion?
> As for implementing, isn't this as simple as this pseudo code:
>
> if (index_deleted_file == index_new_file)
> if (deleted_file != new_file)
> printk("warning\n");
>
> In the git-apply?
Implementation is easy (I said "would be fun to code", didn't I? --- by the
way, how did you match "index_deleted_file" with "index_new_file"?).
My point was that it would not be reliable enough to be useful in
practice.
^ permalink raw reply
* git-clone: path or ssh problem with git-upload-pack in 1.6.0?
From: Paul Johnston @ 2008-09-10 2:29 UTC (permalink / raw)
To: git
I'm having trouble with git-clone and I'm wondering if there's
something I'm doing wrong or something wrong with git. Probably the
former, hopefully someone can set me straight.
I'm an admittedly novice git user. I'm trying to clone a repository
over ssh. The host machine 'imac' is my mac osx 10.4 with git 1.6.0
installed from a macports package. This installs into /opt/local/bin.
I also cloned git from HEAD and 'make; make install'ed into ~/bin,
this is the version shown below. Either way, these are
nonstandard/non-system-wide installation locations, and it requires
that my shell PATH reflect this, obviously.
----------------------------------------------
# About my installation
imac:~ paul$ which git
/Users/paul/bin/git
imac:~ paul$ git --version
git version 1.6.0.1.285.g1070
imac:~ paul$ ls /opt/local/bin/git*
/opt/local/bin/git
/opt/local/bin/git-upload-archive /opt/local/bin/gitk
/opt/local/bin/git-receive-pack /opt/local/bin/git-upload-pack
imac:~ paul$ ls ~/bin/git*
/Users/paul/bin/git /Users/paul/bin/git-shell
/Users/paul/bin/git-upload-pack
/Users/paul/bin/git-receive-pack /Users/paul/bin/git-upload-archive
# Make a simple reposirtory /tmp/test/.git
imac:~ paul$ cd /tmp
imac:/tmp paul$ mkdir test; cd test; echo 'Hello World' > README; git
init; git add README; git commit -a -m'Initial import'; cd ..
Initialized empty Git repository in /private/tmp/test/.git/
Created initial commit 49c10e6: Initial import
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 README
# OK, this fails expectedly
imac:/tmp paul$ cd ~
imac:~ paul$ git clone ssh://localhost/tmp/test/.git
Initialized empty Git repository in /Users/paul/test/.git/
Password:
bash: line 1: git-upload-pack: command not found
fatal: The remote end hung up unexpectedly
# This has been killing me... Have tried numerous variants of the
same with similar results...
imac:~ paul$ git clone --upload-pack /opt/local/bin/git-upload-pack
ssh://localhost/tmp/test/.git
Initialized empty Git repository in /Users/paul/test/.git/
Password:
remote: fatal: exec pack-objects failed.
error: git-upload-pack: git-pack-objects died with error.
fatal: git-upload-pack: aborting due to possible repository corruption
on the remote side.
remote: aborting due to possible repository corruption on the remote side.
fatal: early EOF
fatal: index-pack failed
# Fix it with symlinks in /usr/bin
imac:~ paul$ cd /usr/bin/
imac:/usr/bin paul$ sudo ln -s /opt/local/bin/git* .
imac:/usr/bin paul$ ls -al git*
lrwxr-xr-x 1 root wheel 18 Sep 9 19:18 git -> /opt/local/bin/git
lrwxr-xr-x 1 root wheel 31 Sep 9 19:18 git-receive-pack ->
/opt/local/bin/git-receive-pack
lrwxr-xr-x 1 root wheel 33 Sep 9 19:18 git-upload-archive ->
/opt/local/bin/git-upload-archive
lrwxr-xr-x 1 root wheel 30 Sep 9 19:18 git-upload-pack ->
/opt/local/bin/git-upload-pack
lrwxr-xr-x 1 root wheel 19 Sep 9 19:18 gitk -> /opt/local/bin/gitk
# And now git-clone works as expected...
imac:/usr/bin paul$ cd
imac:~ paul$ git clone ssh://localhost/tmp/test/.git
Initialized empty Git repository in /Users/paul/test/.git/
Password:
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (3/3), done.
imac:~ paul$ find test/
test/
test//.git
{ file listing removed for brevity... }
test//README
-------------------------------------------
OK, great, now it works. I suspect I'm not using the --upload-pack
option correctly or my ssh installation is suboptimal, but as I could
find no existing documentation on the subject, I am posting this
message. Any thoughts?
Paul Johnston
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Junio C Hamano @ 2008-09-10 1:59 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: Jeff King, Jakub Narebski, git
In-Reply-To: <20080910001316.GF7459@cuci.nl>
"Stephen R. van den Berg" <srb@cuci.nl> writes:
> Junio C Hamano wrote:
>>As for "by the way ... was used to make this commit": this is git. So how
>>you arrived at the tree state you record in a commit *does not matter*.
>
> The typical use case for the origin links is in a project with several
> long-lived branches which use cherry-picks to backport amongst them.
> There is no real other way to solve this case, except for some rather
> kludgy stuff in the free-form commit message which doesn't mesh well
> with rebase/filter-branch/stgit etc.
>
> As to "does not matter": then why does git store parent links?
The parent links describe *where* you came from, not *how*.
And if you think the difference is just "semantics", then you haven't
grokked the first lesson I gave in this thread. "parents" record the
reference points against which you make "this resulting commit suits the
purpose of my branch better than any histories leading to these commits".
^ permalink raw reply
* Re: [PATCH] Start conforming code to "git subcmd" style part 2
From: Junio C Hamano @ 2008-09-10 1:43 UTC (permalink / raw)
To: Heikki Orsila; +Cc: git, Jakub Narebski, Christian Couder, Andreas Ericsson
In-Reply-To: <20080909102830.GA9856@zakalwe.fi>
Heikki Orsila <heikki.orsila@iki.fi> writes:
> User notifications are presented as 'git cmd', and code comments
> are presented as '"cmd"' or 'git's cmd', rather than 'git-cmd'.
>
> Signed-off-by: Heikki Orsila <heikki.orsila@iki.fi>
All changes here look good to me. Also "git grep -e git-" on the affected
files I do not see any leftover that should have been converted.
Thanks.
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Linus Torvalds @ 2008-09-10 0:23 UTC (permalink / raw)
To: Stephen R. van den Berg; +Cc: Jakub Narebski, git
In-Reply-To: <20080909235848.GE7459@cuci.nl>
On Wed, 10 Sep 2008, Stephen R. van den Berg wrote:
>
> As you might have noticed, the actual process of pulling/fetching
> explicitly does *not* pull in the objects being pointed to.
.. which makes them _local_ data, which in turn means that they should not
be in the object database at all.
IOW, i you want this for local reasons, you should use a local database,
like the index or the reflogs (and I don't mean "like the index" in the
sense that it would look _anything_ like that file, but in the sense that
it's a purely local thing and doesn't show up in the object database).
Linus
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Stephen R. van den Berg @ 2008-09-10 0:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Jakub Narebski, git
In-Reply-To: <7vljy159v7.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
>As for "by the way ... was used to make this commit": this is git. So how
>you arrived at the tree state you record in a commit *does not matter*.
The typical use case for the origin links is in a project with several
long-lived branches which use cherry-picks to backport amongst them.
There is no real other way to solve this case, except for some rather
kludgy stuff in the free-form commit message which doesn't mesh well
with rebase/filter-branch/stgit etc.
As to "does not matter": then why does git store parent links?
>To my ears, it rhymes rather well with a famous quote from $gmane/217:
> You're freezing your (crappy) algorithm at tree creation time, and
> basically making it pointless to ever create something better later,
> because even if hardware and software improves, you've codified that
> "we have to have crappy information".
I tried to accomodate this approach by overloading the parent link and
then making git more intelligent to figure out if it is a cherry-pick or
not. That was deemed undesirable, so using the origin links is the next
best thing (IMHO).
>good idea, nor this time around it is that much different from what the
>previous "prior" link discussion tried to do.
It is well-defined this time, and doesn't bleed across fetch/pull.
--
Sincerely,
Stephen R. van den Berg.
"Be spontaneous!"
^ permalink raw reply
* Re: [PATCH] t7501: always use test_cmp instead of diff
From: Junio C Hamano @ 2008-09-10 0:02 UTC (permalink / raw)
To: Jeff King; +Cc: Miklos Vajna, git
In-Reply-To: <20080909235414.GA4768@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, Sep 10, 2008 at 01:41:06AM +0200, Miklos Vajna wrote:
>
>> test_expect_success \
>> 'validate git-rev-list output.' \
>> - 'diff current expected'
>> + 'test_cmp current expected'
>
> We seem to use the convention of
>
> test_cmp <expected> <actual>
>
> elsewhere, rather than
>
> test_cmp <actual> <expected>
>
> as you have here. Most noticeably, that means the diff will show
> deviations from expected, rather "what should be done to make this as
> expected".
Yes, please. I am glad to see somebody noticed it (I've been fixing these
whenever I touched vicinity of the ones that had comparisons swapped).
^ permalink raw reply
* Re: [RFC] origin link for cherry-pick and revert
From: Jakub Narebski @ 2008-09-09 23:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Stephen R. van den Berg, git
In-Reply-To: <alpine.LFD.1.10.0809091631250.3117@nehalem.linux-foundation.org>
Linus Torvalds wrote:
> On Tue, 9 Sep 2008, Stephen R. van den Berg wrote:
>> Jakub Narebski wrote:
>>>"Stephen R. van den Berg" <srb@cuci.nl> writes:
>>>> The definition of the origin field reads as follows:
>>
>>>> - There can be an arbitrary number of origin fields per commit.
>>>> Typically there is going to be at most one origin field per commit.
>>
>>> I understand that multiple origin fields occur if you do a squash
>>> merge, or if you cherry-pick multiple commits into single commit.
>>> For example:
>>> $ git cherry-pick -n <a1>
>>> $ git cherry-pick <a2>
>>> $ git commit --amend #; to correct commit message
>>
>> Correct.
>
> Quite frankly, recording the origins for _any_ of the above sounds like a
> horribly mistake.
Actually the above is _not_ a good example for using 'origin', and why
using 'origin'; just a bit convoluted example of multiple 'origin'
headers.
> All those operations are commonly used (along with "git rebase -i") to
> clean up history in order to show a nicer version.
>
> The whole point of "origin" seems to be to _destroy_ that.
If I understand correctly the point is to record those 'origin' headers
for git-revert (when 'origin'-ed commit is somewhere in the history),
and for git-cherry-pick from other long lived branch and thus require
additional option to git-cherry-pick to record 'origin' (denoting that
you this is "true" cherry-pick, and not reordering of commits and
cleaning up a history, better done with interactive rebase).
/me is playing advocatus diaboli here, 'cause I'm not that convinced
to necessity of this feature.
--
Jakub Narebski
Poland
^ 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