* Re: git pull w/o checkout?
From: Kumar Gala @ 2006-06-22 13:15 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20060622131344.GA7168@coredump.intra.peff.net>
On Jun 22, 2006, at 8:13 AM, Jeff King wrote:
> On Thu, Jun 22, 2006 at 08:10:10AM -0500, Kumar Gala wrote:
>
>>> git-fetch?
>> Its the first half, still need to resolve FETCH_HEAD, HEAD, etc..
>
> Can you elaborate on what you're trying to accomplish?
A local mirror of a git tree. I can do the clone easy enough, its
trying to figure out the updates after the fact that is the issue.
- k
^ permalink raw reply
* Re: git pull w/o checkout?
From: Kumar Gala @ 2006-06-22 13:13 UTC (permalink / raw)
To: Matthias Kestenholz; +Cc: git
In-Reply-To: <20060622131129.GB5134@spinlock.ch>
On Jun 22, 2006, at 8:11 AM, Matthias Kestenholz wrote:
> * Kumar Gala (galak@kernel.crashing.org) wrote:
>> I trying to see if there is a way to get the effect of a git-pull w/o
>> getting the checked out files.
>>
>> Any ideas?
>
> Do you want to fetch remote changes without merging them into your
> working tree? If you, "git fetch" is your friend.
that's what I want, however fetch isn't updating any refs/ as far as
I can tell.
> By the way, pull does the equivalent of a fetch and a subsequent
> merge.
right, its the merge that seems to be doing the checkout.
- k
^ permalink raw reply
* Re: git pull w/o checkout?
From: Jeff King @ 2006-06-22 13:13 UTC (permalink / raw)
To: Kumar Gala; +Cc: git
In-Reply-To: <E333ADD9-1096-4137-9D72-D58A8E2A5582@kernel.crashing.org>
On Thu, Jun 22, 2006 at 08:10:10AM -0500, Kumar Gala wrote:
> >git-fetch?
> Its the first half, still need to resolve FETCH_HEAD, HEAD, etc..
Can you elaborate on what you're trying to accomplish?
-Peff
^ permalink raw reply
* Re: [PATCH] Pass -DDEFAULT_GIT_TEMPLATE_DIR only where actually used.
From: Petr Baudis @ 2006-06-22 13:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Yakov Lerner, git
In-Reply-To: <7vwtb9veqv.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Thu, Jun 22, 2006 at 09:19:52AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> For that matter, I do not think tracking prefix_SQ makes much
> sense since what matters are bindir, gitexecdir and template_dir
> which are already covered, and prefix is merely a convenience to
> set these three (four, counting GIT_PYTHON_DIR; we probably
> should add it to TRACK_CFLAGS).
$(prefix) will be passed to perl/Makefile.PL.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: git pull w/o checkout?
From: Matthias Kestenholz @ 2006-06-22 13:11 UTC (permalink / raw)
To: Kumar Gala; +Cc: git
In-Reply-To: <E65F8DB5-677B-4C7B-A4EC-5F6FB76D6E9A@kernel.crashing.org>
* Kumar Gala (galak@kernel.crashing.org) wrote:
> I trying to see if there is a way to get the effect of a git-pull w/o
> getting the checked out files.
>
> Any ideas?
Do you want to fetch remote changes without merging them into your
working tree? If you, "git fetch" is your friend.
By the way, pull does the equivalent of a fetch and a subsequent
merge.
Matthias
^ permalink raw reply
* Re: git pull w/o checkout?
From: Kumar Gala @ 2006-06-22 13:10 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20060622130523.GA6893@coredump.intra.peff.net>
On Jun 22, 2006, at 8:05 AM, Jeff King wrote:
> On Thu, Jun 22, 2006 at 07:51:56AM -0500, Kumar Gala wrote:
>
>> I trying to see if there is a way to get the effect of a git-pull w/o
>> getting the checked out files.
>
> git-fetch?
Its the first half, still need to resolve FETCH_HEAD, HEAD, etc..
- k
^ permalink raw reply
* Re: git pull w/o checkout?
From: Jeff King @ 2006-06-22 13:05 UTC (permalink / raw)
To: Kumar Gala; +Cc: git
In-Reply-To: <E65F8DB5-677B-4C7B-A4EC-5F6FB76D6E9A@kernel.crashing.org>
On Thu, Jun 22, 2006 at 07:51:56AM -0500, Kumar Gala wrote:
> I trying to see if there is a way to get the effect of a git-pull w/o
> getting the checked out files.
git-fetch?
-Peff
^ permalink raw reply
* git pull w/o checkout?
From: Kumar Gala @ 2006-06-22 12:51 UTC (permalink / raw)
To: git
I trying to see if there is a way to get the effect of a git-pull w/o
getting the checked out files.
Any ideas?
thanks
- kumar
^ permalink raw reply
* Tracking CVS
From: Jon Smirl @ 2006-06-22 12:41 UTC (permalink / raw)
To: git
I'm tracking cvs using this sequence.
cvs update
cg rm -a
cg commit
cg add -r .
cg commit
Is there a way to avoid the two commits? If you do the add with out
the intervening commit it just adds the files back.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Incremental CVS update
From: Jon Smirl @ 2006-06-22 12:26 UTC (permalink / raw)
To: Keith Packard, git
cvsps keeps it's incremental status in ~/.cvps/*. parsecvs might want
to keep it's status in the .git repository and use tags to locate it.
You could even have a utility to show when and what was imported. By
keeping everything in git it doesn't matter who runs the incremental
update commands.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] rebase --merge: fix for rebasing more than 7 commits.
From: Eric Wong @ 2006-06-22 11:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsh1tvt1.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> > * I wanted to raise my confidence level in the new rebase --merge
> > code, so I did a little exercise which resulted in finding this
> > buglet.
> >...
> > So the exercise went like this:
> >...
> > With this fix, the above works beautifully. I am reasonably
> > happy with this shiny new toy. Good job, Eric! and thanks.
:) Thanks for the extra QA and fix.
> By the way, I do not quite understand the reasoning behind not
> moving the head being rebased until the finalization phase.
That's because my original patch that only used git-merge, which didn't
let me manually commit with all the information from a previous commit.
> Also I think --skip would be straightforward. What you look at
> in call_merge() is the current HEAD, the commit being rebased
> and its direct parent (actually what you are interested in are
> trees of these commits and not ancestry chains among them -- if
> we can tell git-merge-recursive not to try its own "recursive"
> merge base finding but just use what we give it as the base, I
> could sleep better. I think the current code could misbehave in
> funnier ancestry graph if we allow it to pick merge base on its
> own), so skipping is just a matter of, eh, skipping the commit.
Another consequence of relying on plain git-merge in my original
patch. --skip should be very doable now that we can specify
the correct base. I'll look into it more when I'm more awake.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] gitweb: whitespace cleanup around '='
From: Junio C Hamano @ 2006-06-22 10:20 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e7doc6$sg7$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano wrote:
>
>> I remember discussing things with Timo and was putting it on
>> hold since I knew you were also actively futzing on gitweb.
>
> So when I apply someone else patches should I reply to the post
> with patch I have applied with
>
> Acked-by: Jakub Narebski <jnareb@gmial.com>
>
> to notify of that fact?
Acked-by does not mean you've applied it to your tree, and even
if it did, it is unfair to expect me to remember that fact when
I review your patch later. In this particular case, a note in
the patch to say it depends on such and such that _I_ do not
seem to have yet would have been more appropriate.
Acked-by would also be helpful when a de-facto owner of the code
wants to push acceptance of others' patches, but that is
independent from stating what a patch's prerequisites are.
Anyhow, I've reviewed Timo's patch (which made sense to me too),
and your whitespace fixes and pushed out the result, which
hopefully will be propagating to the mirrors soon. Overall, I
would say that the clean-up on gitweb so far is reasonably
straightforward. I have been running "next" version of gitweb
on my private machine and haven't found regression.
I'll go to bed now. Thanks for the patches.
^ permalink raw reply
* Re: [PATCH] gitweb: whitespace cleanup around '='
From: Santi Béjar @ 2006-06-22 10:19 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e7dp9m$v48$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano wrote:
>
>> Jakub Narebski <jnareb@gmail.com> writes:
>
>>> I'm very sorry, I forgot that I applied Timo Hirvonen patch
>>>
>>> "[PATCH] gitweb: Start search from HEAD"
>>> Message-ID: <20060620152515.23e59396.tihirvon@gmail.com>
>>
>> But I think what you have is this one instead:
>>
>> Message-ID: <20060620164105.7276a45f.tihirvon@gmail.com>
>
> Is the 'note' extension to commit header implemented yet? It it is,then it
> would be nice if git-am recorded original email message-ids in the note
> header. Usually it is of no interest to user, so it should be hidden by
> default.
I put it at the end of the commit message, like the Signed-of-by
lines. And, yes, it would be nice if git-am would add it (--message-id
flag?). If more people is interested I'll try to send a patch.
Santi
^ permalink raw reply
* Re: [RFC] gitweb wishlist and TODO list
From: Dennis Stosberg @ 2006-06-22 10:00 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e7bhlf$5j2$1@sea.gmane.org>
Jakub Narebski wrote:
> So now you have extra git redirector being spawned, instead of extra shell
> being spawned.
Most of the commands that Gitweb uses are built-ins, so there
shouldn't be any extra overhead by calling "git command" instead of
"git-command". If I haven't missed one, git-annotate is the only one
which is not a built-in.
Regards,
Dennis
^ permalink raw reply
* Re: [PATCH] gitweb: whitespace cleanup around '='
From: Jakub Narebski @ 2006-06-22 9:52 UTC (permalink / raw)
To: git
In-Reply-To: <7vodwlsfek.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>> I'm very sorry, I forgot that I applied Timo Hirvonen patch
>>
>> "[PATCH] gitweb: Start search from HEAD"
>> Message-ID: <20060620152515.23e59396.tihirvon@gmail.com>
>
> But I think what you have is this one instead:
>
> Message-ID: <20060620164105.7276a45f.tihirvon@gmail.com>
Is the 'note' extension to commit header implemented yet? It it is,then it
would be nice if git-am recorded original email message-ids in the note
header. Usually it is of no interest to user, so it should be hidden by
default.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] gitweb: whitespace cleanup around '='
From: Jakub Narebski @ 2006-06-22 9:37 UTC (permalink / raw)
To: git
In-Reply-To: <7vodwlsfek.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> I remember discussing things with Timo and was putting it on
> hold since I knew you were also actively futzing on gitweb.
So when I apply someone else patches should I reply to the post
with patch I have applied with
Acked-by: Jakub Narebski <jnareb@gmial.com>
to notify of that fact?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] gitweb: whitespace cleanup around '='
From: Junio C Hamano @ 2006-06-22 9:33 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e7dh1c$61n$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano wrote:
>
>> I thought we were both reasonably sure that we are now in
>> sync... I could apply it by hand but once I start doing that
>> I'm afraid we will never converge.
>>
>> It's quite frustrating.
>
> I'm very sorry, I forgot that I applied Timo Hirvonen patch
>
> "[PATCH] gitweb: Start search from HEAD"
> (<20060620152515.23e59396.tihirvon@gmail.com>)
> http://permalink.gmane.org/gmane.comp.version-control.git/22197>
>
> on top of 'next'.
I remember discussing things with Timo and was putting it on
hold since I knew you were also actively futzing on gitweb.
But I think what you have is this one instead:
Message-ID: <20060620164105.7276a45f.tihirvon@gmail.com>
I applied it in jn/gitweb topic and then applied your whitespace
fixes on top of the result, after discarding the whitespace
cleanup I sent out earlier. So let's make sure we are resync'ed
and continue from here. I'll push out the updated "next"
soonish.
^ permalink raw reply
* Re: [RFC] gitweb wishlist and TODO list
From: Junio C Hamano @ 2006-06-22 9:14 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e7dm8g$mc9$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Jakub Narebski wrote:
>
>> I am planning on copying features from xmms2's gitweb version
>> to git's gitweb, and introducing new ones.
>
>> * Refactor generation of navigation bar. There are at least two
>> implementations of that. With hash dispatch it would be easy to
>> list all possibilities.
>
> Actually I think that whole gitweb.cgi needs refactoring, badly. Generation
> of navigation bar is only one, admittedly worst, example of code
> duplication.
Yes. I liked what xmms2 folks did to the navbar exactly for
that reason. We would be better off to first clean up what we
currently have before starting to build too much on it.
^ permalink raw reply
* Re: [PATCH] Pass -DDEFAULT_GIT_TEMPLATE_DIR only where actually used.
From: Junio C Hamano @ 2006-06-22 9:04 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: iler.ml, git
In-Reply-To: <20060622104901.f3543f07.tihirvon@gmail.com>
Timo Hirvonen <tihirvon@gmail.com> writes:
> Junio C Hamano <junkio@cox.net> wrote:
>
>> By the way, I really started hating that we have $(GIT_VERSION)
>> in $(TRACK_CFLAGS). Since the version string is tied to the
>> HEAD commit object name, having it in $(TRACK_CFLAGS) means that
>> every time I switch branches, make a new commit on top of the
>> current branch, or checkout-compile-and-then-make-local-change
>> sequence would force pretty much everything to be rebuilt.
>...
>> For that matter, I do not think tracking prefix_SQ makes much
>> sense since what matters are bindir, gitexecdir and template_dir
>> which are already covered, and prefix is merely a convenience to
>> set these three (four, counting GIT_PYTHON_DIR; we probably
>> should add it to TRACK_CFLAGS).
>
> Yes, only ALL_CFLAGS, bindir, gitexecdir, template_dir and
> GIT_PYTHON_DIR should be in TRACK_CFLAGS.
Exactly my thinking. Let's do it like this, then.
-- >8 --
Makefile: do not force unneeded recompilation upon GIT_VERSION changes
---
diff --git a/Makefile b/Makefile
index 55a84d4..d45f3dc 100644
--- a/Makefile
+++ b/Makefile
@@ -612,7 +612,7 @@ tags:
find . -name '*.[hcS]' -print | xargs ctags -a
### Detect prefix changes
-TRACK_CFLAGS = $(subst ','\'',$(ALL_CFLAGS)):$(GIT_VERSION):\
+TRACK_CFLAGS = $(subst ','\'',$(ALL_CFLAGS)):$(GIT_PYTHON_DIR_SQ):\
$(bindir_SQ):$(gitexecdir_SQ):$(template_dir_SQ):$(prefix_SQ)
GIT-CFLAGS: .FORCE-GIT-CFLAGS
^ permalink raw reply related
* Re: [PATCH] [RFC] Introduce Git.pm
From: Junio C Hamano @ 2006-06-22 9:01 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060622003546.17760.23089.stgit@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> This patch introduces a very basic and barebone Git.pm module
> with a sketch of how the generic interface would look like;
In addition to my previous comments...
> + my $version = Git::generic_oneval('version');
> + my $lastrev = $repo->generic_oneval('rev-list', '--all');
> +...
> +=item generic_oneline ( COMMAND [, ARGUMENTS... ] )
> +...
> +sub generic_oneline {
> + my $fh = generic(@_);
> + my $line = <$fh>;
> + close $fh;
> + chomp $line;
> + return $line;
> +}
Let's have a cleaned up version of Git.pm, Makefile changes and
changes to git-fmt-merge-msg.perl that shows how to use the
module. Being in-tree would help people to view, use and
comment on it.
^ permalink raw reply
* Re: [RFC] gitweb wishlist and TODO list
From: Jakub Narebski @ 2006-06-22 9:01 UTC (permalink / raw)
To: git
In-Reply-To: <e79921$u0e$1@sea.gmane.org>
Jakub Narebski wrote:
> I am planning on copying features from xmms2's gitweb version
> to git's gitweb, and introducing new ones.
> * Refactor generation of navigation bar. There are at least two
> implementations of that. With hash dispatch it would be easy to
> list all possibilities.
Actually I think that whole gitweb.cgi needs refactoring, badly. Generation
of navigation bar is only one, admittedly worst, example of code
duplication.
Another gitweb feature I can think of:
* Add information about from which repository and which branch in the
remote repository given branch (head) came from. Should support both
$GIT_DIR/branches and $GIT_DIR/remotes format, and be easy extendable
to support branch/repo/remotes configuration in config.
I think it would be best to show this info (as it is variable long length,
and optional) as the last column of heads listing. Or would be better to
just add link with the remote name as text?
Is git://host.xz/path/to/repo.git#branch correct branch URI?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] rebase --merge: fix for rebasing more than 7 commits.
From: Junio C Hamano @ 2006-06-22 8:54 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <7vy7vptw8p.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> * I wanted to raise my confidence level in the new rebase --merge
> code, so I did a little exercise which resulted in finding this
> buglet.
>...
> So the exercise went like this:
>...
> With this fix, the above works beautifully. I am reasonably
> happy with this shiny new toy. Good job, Eric! and thanks.
By the way, I do not quite understand the reasoning behind not
moving the head being rebased until the finalization phase.
Also I think --skip would be straightforward. What you look at
in call_merge() is the current HEAD, the commit being rebased
and its direct parent (actually what you are interested in are
trees of these commits and not ancestry chains among them -- if
we can tell git-merge-recursive not to try its own "recursive"
merge base finding but just use what we give it as the base, I
could sleep better. I think the current code could misbehave in
funnier ancestry graph if we allow it to pick merge base on its
own), so skipping is just a matter of, eh, skipping the commit.
^ permalink raw reply
* [PATCH] rebase --merge: fix for rebasing more than 7 commits.
From: Junio C Hamano @ 2006-06-22 8:44 UTC (permalink / raw)
To: Eric Wong; +Cc: git
Instead of using 4-digit numbers to name commits being rebased,
just use "cmt.$msgnum" string, with $msgnum as a decimal number
without leading zero padding. This makes it possible to rebase
more than 9999 commits, but of more practical importance is that
the earlier code used "printf" to format already formatted
$msgnum and barfed when it counted up to 0008. In other words,
the old code was incapable of rebasing more than 7 commits, and
this fixes that problem.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* I wanted to raise my confidence level in the new rebase --merge
code, so I did a little exercise which resulted in finding this
buglet.
I did not have "read/write-tree --prefix" on the "master"
branch, when I received the patch series that begins with
"Make git-write-tree a builtin" from Lukas. Now, my policy
is to avoid starting a new topic based on "next" (because it
would make later pulling in the topic into "master" without
all the other uncooked stuff in "next" impossible), but the
series was based on "next" (which was actually nice, since
write-tree between "master" and "next" were somewhat diverged
back then), and I couldn't easily rebase Lukas's patch series
on top of "master" because we did not have "rebase --merge"
option. Now I can with the updated "rebase".
So the exercise went like this:
(1) Start from a clone of git.git, with "master" at 8c278ab
(where the "master" was before "read/write-tree --prefix"
was merged), and "ls/am" at ab195e1 (what applying
Lukas's series on top of "next" would have produced).
Use "reset --hard" as needed.
(2) "git rebase --merge --onto master ls/am~9" (ls/am~8 being
the first one of the series). This fails with a merge
conflict on builtin-write-tree.c (the "rebase --merge"
code did the right thing with the renamed path). Fix it
up and also fix builtin.h (signature of write_tree()
needs to be changed to drop prefix).
It was very helpful to view:
git diff :3:builtin-write-tree.c builtin-write-tree.c
during the hand resolution of the conflicts; it lets me
see what Lukas did, so I can adjust the patch by removing
parts that are specific to "next" and not applicable to
"master".
(3) "git update-index builtin-write-tree.c builtin.h" and then
"git rebase --continue". The bug manifests itself during
the finalization step, which this commit fixes.
With this fix, the above works beautifully. I am reasonably
happy with this shiny new toy. Good job, Eric! and thanks.
git-rebase.sh | 23 ++++++++++-------------
1 files changed, 10 insertions(+), 13 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index b9ce112..9159477 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -67,16 +67,16 @@ continue_merge () {
prev_head=`git-rev-parse HEAD^0`
# save the resulting commit so we can read-tree on it later
- echo "$prev_head" > "$dotest/`printf %0${prec}d $msgnum`.result"
+ echo "$prev_head" > "$dotest/cmt.$msgnum.result"
echo "$prev_head" > "$dotest/prev_head"
# onto the next patch:
msgnum=$(($msgnum + 1))
- printf "%0${prec}d" "$msgnum" > "$dotest/msgnum"
+ echo "$msgnum" >"$dotest/msgnum"
}
call_merge () {
- cmt="$(cat $dotest/`printf %0${prec}d $1`)"
+ cmt="$(cat $dotest/cmt.$1)"
echo "$cmt" > "$dotest/current"
git-merge-$strategy "$cmt^" -- HEAD "$cmt"
rv=$?
@@ -108,15 +108,12 @@ finish_rb_merge () {
end="`cat $dotest/end`"
while test "$msgnum" -le "$end"
do
- msgnum=`printf "%0${prec}d" "$msgnum"`
- printf "%0${prec}d" "$msgnum" > "$dotest/msgnum"
-
- git-read-tree `cat "$dotest/$msgnum.result"`
+ git-read-tree `cat "$dotest/cmt.$msgnum.result"`
git-checkout-index -q -f -u -a
- git-commit -C "`cat $dotest/$msgnum`"
+ git-commit -C "`cat $dotest/cmt.$msgnum`"
- echo "Committed $msgnum"
- echo ' '`git-rev-list --pretty=oneline -1 HEAD | \
+ printf "Committed %0${prec}d" $msgnum
+ echo ' '`git-rev-list --pretty=oneline -1 HEAD | \
sed 's/^[a-f0-9]\+ //'`
msgnum=$(($msgnum + 1))
done
@@ -322,11 +319,11 @@ for cmt in `git-rev-list --no-merges "$u
| perl -e 'print reverse <>'`
do
msgnum=$(($msgnum + 1))
- echo "$cmt" > "$dotest/`printf "%0${prec}d" $msgnum`"
+ echo "$cmt" > "$dotest/cmt.$msgnum"
done
-printf "%0${prec}d" 1 > "$dotest/msgnum"
-printf "%0${prec}d" "$msgnum" > "$dotest/end"
+echo 1 >"$dotest/msgnum"
+echo $msgnum >"$dotest/end"
end=$msgnum
msgnum=1
--
1.4.0.gfba6
^ permalink raw reply related
* [PATCH] git-svn: fix commit --edit flag when using SVN:: libraries
From: Eric Wong @ 2006-06-22 8:22 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Eric Wong
Trying to open an interactive editor in the console while stdout is
being piped to the parent process doesn't work out very well.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/git-svn.perl | 14 ++++++++------
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/contrib/git-svn/git-svn.perl b/contrib/git-svn/git-svn.perl
index 7e7f2f0..08c3010 100755
--- a/contrib/git-svn/git-svn.perl
+++ b/contrib/git-svn/git-svn.perl
@@ -479,17 +479,18 @@ sub commit_lib {
my @lock = $SVN::Core::VERSION ge '1.2.0' ? (undef, 0) : ();
my $commit_msg = "$GIT_SVN_DIR/.svn-commit.tmp.$$";
+ if (defined $LC_ALL) {
+ $ENV{LC_ALL} = $LC_ALL;
+ } else {
+ delete $ENV{LC_ALL};
+ }
foreach my $c (@revs) {
+ my $log_msg = get_commit_message($c, $commit_msg);
+
# fork for each commit because there's a memory leak I
# can't track down... (it's probably in the SVN code)
defined(my $pid = open my $fh, '-|') or croak $!;
if (!$pid) {
- if (defined $LC_ALL) {
- $ENV{LC_ALL} = $LC_ALL;
- } else {
- delete $ENV{LC_ALL};
- }
- my $log_msg = get_commit_message($c, $commit_msg);
my $ed = SVN::Git::Editor->new(
{ r => $r_last,
ra => $SVN,
@@ -535,6 +536,7 @@ sub commit_lib {
($r_last, $cmt_last) = ($r_new, $cmt_new);
}
}
+ $ENV{LC_ALL} = 'C';
unlink $commit_msg;
}
--
1.4.0.g937a
^ permalink raw reply related
* Re: [PATCH] [RFC] Introduce Git.pm
From: Jakub Narebski @ 2006-06-22 8:07 UTC (permalink / raw)
To: git
In-Reply-To: <20060622003546.17760.23089.stgit@machine.or.cz>
Petr Baudis wrote:
> Most desirable now is proper error reporting, generic_in() for feeding
> input to Git commands and the repository() constructor doing some poking
> with git-rev-parse to get the git directory and subdirectory prefix.
> Those three are basically the prerequisities for converting git-mv.
I think that repository() constructor (to be converted in the 'new'
constructor I guess) should take 'binbin => "/usr/bin"' argument
optionally, to find where git binary is. 'libexecdir' can be also
supported, or one can get it from 'git --exec-path' and save.
> Currently Git.pm just wraps up exec()s of Git commands, but even that
> is not trivial to get right and various Git perl scripts do it in
> various inconsistent ways.
It would be nice to have also wrapers to reading files from git
repository, ate least some generic read_file/readdir.
For example it might be faster to list branches and/or tags by directly
reading $GIT_DIR/refs directory than using 'git branch' or 'git tag -l'.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ 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