* bug in t3700-add.sh?
From: Nguyen Thai Ngoc Duy @ 2007-08-03 20:51 UTC (permalink / raw)
To: Git Mailing List, Johannes Sixt
Hi,
Running test 17, I got this output:
* expecting success:
git rm --cached -f file symlink &&
(
echo "100644 $(git hash-object -w stage1) 1 file"
echo "100755 $(git hash-object -w stage2) 2 file"
echo "100644 $(printf $s | git hash-object -w -t blob
--stdin) 1 symlink"
echo "120000 $(printf $s | git hash-object -w -t blob
--stdin) 2 symlink"
) | git update-index --index-info &&
git config core.filemode 0 &&
git config core.symlinks 0 &&
echo new > file &&
echo new > symlink &&
git add file symlink &&
git ls-files --stage | grep "^100755 .* 0 file$" &&
git ls-files --stage | grep "^120000 .* 0 symlink$"
rm 'file'
rm 'symlink'
printf: usage: printf [-v var] format [arguments]
printf: usage: printf [-v var] format [arguments]
100755 3e757656cf36eca53338e520d134963a44f793f8 0 file
120000 3e757656cf36eca53338e520d134963a44f793f8 0 symlink
* ok 17: git add with filemode=0, symlinks=0 prefers stage 2 over stage 1
I don't know if "printf $s" was intentional because $s was empty and
caused printf to print out help usage. I have feeling that there is
something wrong here. Anyone can clarify?
Johannes Sixt CC'd as he added this code.
--
Duy
^ permalink raw reply
* Re: Git on MSys (or how to make it easy for Windows users to compile git)
From: Dmitry Kakurin @ 2007-08-03 21:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Marius Storm-Olsen, git
In-Reply-To: <Pine.LNX.4.64.0708031240450.14781@racer.site>
> With Vista fix you mean both adding the USE_MINGW_ACCESS define and
> copying cc1.exe to /bin?
Only the first one. I didn't copy cc1.exe because it could affect non-Vista users in a negative way.
- Dmitry
^ permalink raw reply
* Re: Git on MSys (or how to make it easy for Windows users to compile git)
From: Dmitry Kakurin @ 2007-08-03 21:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Marius Storm-Olsen, git
In-Reply-To: <Pine.LNX.4.64.0708031334530.14781@racer.site>
> * replace rxvt by that stupid cmd window
> Sneaky.
This was a result of my customization that I have forgot to remove.
In general cmd window is more familiar/convenient for Windows users.
IMHO, our goal here should be "as native (Windows) as possible". Cygwin fills "as close to *nix as possible" niche.
But in any case it's such a minor detail that I don't really care much.
- Dmitry
^ permalink raw reply
* Re: Git on MSys (or how to make it easy for Windows users to compile git)
From: Johannes Schindelin @ 2007-08-03 21:21 UTC (permalink / raw)
To: Mike Pape; +Cc: Marius Storm-Olsen, Dmitry Kakurin, git
In-Reply-To: <Pine.LNX.4.64.0708032027250.14781@racer.site>
Hi,
On Fri, 3 Aug 2007, Johannes Schindelin wrote:
> Okay, I am really close to initialising the repository on
>
> http://repo.or.cz/w/git/mingw/msysgit.git
Actually, that did not work out too well. It is not really a fork, so the
tags all pointed nowhere, and I could not even upload origin/devel to fix
that. So I bit the apple and initialised a new repo:
http://repo.or.cz/w/msysgit.git
This will be the official repo for this project.
All users who sent me their username are already registered there.
Ciao,
Dscho
^ permalink raw reply
* Re: bug in t3700-add.sh?
From: Junio C Hamano @ 2007-08-03 21:26 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Git Mailing List, Johannes Sixt
In-Reply-To: <fcaeb9bf0708031351g5e585a4bj849fbf2ec3720a18@mail.gmail.com>
"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
> Running test 17, I got this output:
Gaah. Those $s seem completely bogus.
diff --git a/t/t3700-add.sh b/t/t3700-add.sh
index b52fde8..a27c593 100755
--- a/t/t3700-add.sh
+++ b/t/t3700-add.sh
@@ -131,8 +131,8 @@ test_expect_success 'git add with filemode=0, symlinks=0 prefers stage 2 over st
(
echo "100644 $(git hash-object -w stage1) 1 file"
echo "100755 $(git hash-object -w stage2) 2 file"
- echo "100644 $(printf $s | git hash-object -w -t blob --stdin) 1 symlink"
- echo "120000 $(printf $s | git hash-object -w -t blob --stdin) 2 symlink"
+ echo "100644 $(echo 1 | git hash-object -w -t blob --stdin) 1 symlink"
+ echo "120000 $(echo 2 | git hash-object -w -t blob --stdin) 2 symlink"
) | git update-index --index-info &&
git config core.filemode 0 &&
git config core.symlinks 0 &&
^ permalink raw reply related
* Re: bug in t3700-add.sh?
From: Junio C Hamano @ 2007-08-03 21:29 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Git Mailing List, Johannes Sixt
In-Reply-To: <fcaeb9bf0708031351g5e585a4bj849fbf2ec3720a18@mail.gmail.com>
"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
> Running test 17, I got this output:
Gaah. Those $s seem completely bogus.
This test only cares to see if the blob type is retained (it
does "git add" to the path later to throw away the unmergedness
and data at higher stage prepared by this step), so it really
does not matter what is fed to hash-object. But it should be
hashing a file whose contents is '1' and a symlink to '2'.
diff --git a/t/t3700-add.sh b/t/t3700-add.sh
index b52fde8..213e924 100755
--- a/t/t3700-add.sh
+++ b/t/t3700-add.sh
@@ -131,8 +131,8 @@ test_expect_success 'git add with filemode=0, symlinks=0 prefers stage 2 over st
(
echo "100644 $(git hash-object -w stage1) 1 file"
echo "100755 $(git hash-object -w stage2) 2 file"
- echo "100644 $(printf $s | git hash-object -w -t blob --stdin) 1 symlink"
- echo "120000 $(printf $s | git hash-object -w -t blob --stdin) 2 symlink"
+ echo "100644 $(printf 1 | git hash-object -w -t blob --stdin) 1 symlink"
+ echo "120000 $(printf 2 | git hash-object -w -t blob --stdin) 2 symlink"
) | git update-index --index-info &&
git config core.filemode 0 &&
git config core.symlinks 0 &&
^ permalink raw reply related
* Re: Git on MSys (or how to make it easy for Windows users to compile git)
From: Johannes Schindelin @ 2007-08-03 21:32 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: Marius Storm-Olsen, git
In-Reply-To: <E3C81783E0454702B1F38D0B68CE1AC0@ntdev.corp.microsoft.com>
Hi,
On Fri, 3 Aug 2007, Dmitry Kakurin wrote:
> > * replace rxvt by that stupid cmd window
> > Sneaky.
>
> This was a result of my customization that I have forgot to remove.
> In general cmd window is more familiar/convenient for Windows users.
> IMHO, our goal here should be "as native (Windows) as possible". Cygwin fills
> "as close to *nix as possible" niche.
> But in any case it's such a minor detail that I don't really care much.
Actually, I finally saw the light and implemented your idea of the
repo.or.cz repository, containing a full copy of the darn beast.
And there, differences like this one are much easier to spot.
Besides, Marius convinced me already to include two versions.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add --show-touched option to show "diff --git" line when contents are unchanged
From: Matthieu Moy @ 2007-08-03 21:32 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Steven Grimm, Jean-Francois Veillette, git
In-Reply-To: <7vir7wmk84.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> But I'd really think that what should be done (if anything has to be done
>> at all) is to introduce a config variable which triggers the same logic in
>> git-diff as was introduced in 2b5f9a8c0cff511f2bb0833b1ee02645b79323f4.
>
> Sorry, I don't follow at all. The diff toolchain works all
> inside core without having to write a temporary index out, which
> was the issue the commit you are quoting was about.
>
> In any case, enough discussion. Here is an updated patch, which
> I _could_ be pursuaded to consider for inclusion after v1.5.3
> happens, if there are enough agreements and Acks.
To me, that patch makes sense, yes.
That said, a configuration option would probably be better than a
command-line option. The expected behavior seems to depend on user,
but not much on use-cases. So, people who like the old behavior could
set the option and forget about it, and other would not be distracted
about it.
Also, is there any particular reason not to update the index stat
information when files are found to be identical? Well, we've
discussed that quite much in this thread, but this is what status is
doing, and I still fail to see why diff shouldn't. (I can update the
patch myself if you agree it should be done. I don't know the git
codebase well, so it takes time for me, but the exercise is fun ;-) )
Side performance note: if I understand your patch correctly, you're
comparing the file content twice for actually modified changes. But
that probably doesn't matter much since the expansive thing is to load
the files and to compute the diff.
Thanks,
--
Matthieu
^ permalink raw reply
* Re: RPMs for latest release
From: Linus Torvalds @ 2007-08-03 21:36 UTC (permalink / raw)
To: rdavid274; +Cc: git
In-Reply-To: <46B38125.9060805@centurytel.net>
On Fri, 3 Aug 2007, rdavid274 wrote:
>
> Downloaded the 10 rpms necessary for a complete install however, there is NO
> single rpm that is independent of the other rpms.
>
> Every rpm that I have downloaded depends on at 1 other rpm to have been
> already installed.
>
> So, how does a newbie deal with this issue?
You should be able to do
rpm -Uvh <list-all-rpms-here>
and be all good.
In other words, if you have dependencies, you need to resolve all the
dependencies in one go by listing the packages together.
Of course, you could also just force rpm to ignore dependencies (the
"--nodeps" flag, iirc), but that's usually a bad idea - it just means that
you will be all the more likely to have a non-working setup because you
forgot some package or other, and since you told rpm to ignore it, it
won't tell you.
That said, most rpm distros tend to make things much easier for you by
letting you just run "yum", which will do all of this for you, and then
you can generally just do
yum install git
and it will download all packages and install them by dependencies.
Linus
^ permalink raw reply
* Re: [PATCH] Add --show-touched option to show "diff --git" line when contents are unchanged
From: Junio C Hamano @ 2007-08-03 21:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steven Grimm, Jean-Francois Veillette, git
In-Reply-To: <vpqps24i9sx.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> Also, is there any particular reason not to update the index stat
> information when files are found to be identical?
Very much --- diff is a read-only operation.
"git-status $args" on the other hand is a preview of "what would
happen if I say 'git-commit $args'", and in order to compute
that, you would fundamentally need to be able to write into the
object store. In a special case of giving empty $args it can be
read-only. The commit Dscho quoted earlier was to hack that
around so that "git-status" can pretend to be a read-only
operation in a repository you do not have write permission to.
^ permalink raw reply
* Re: [PATCH] Add --show-touched option to show "diff --git" line when contents are unchanged
From: Matthieu Moy @ 2007-08-03 23:01 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Steven Grimm, Jean-Francois Veillette, git
In-Reply-To: <7v1wekmgo8.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> Matthieu Moy <Matthieu.Moy@imag.fr> writes:
>
>> Also, is there any particular reason not to update the index stat
>> information when files are found to be identical?
>
> Very much --- diff is a read-only operation.
>
> "git-status $args" on the other hand is a preview of "what would
> happen if I say 'git-commit $args'", and in order to compute
> that, you would fundamentally need to be able to write into the
> object store. In a special case of giving empty $args it can be
> read-only.
Can you give an example where it _could_ not be read-only?
> The commit Dscho quoted earlier was to hack that around so that
> "git-status" can pretend to be a read-only operation in a repository
> you do not have write permission to.
I really, really, really, don't understand your argument.
There are two different concepts:
* Should git-diff be "read-only for the user"?
(i.e. external specification)
* Should git-diff be actually read-only for the filesystem?
(i.e. implementation)
"read-only for the user" is a user-interface thing. It just means that
running
$ git-diff >& /dev/null; whatever
will give the same result as
$ whatever
In another context, "cat", for example, is a read-only operation for
the user. I can run "cat whatever-file" without influencing the
behavior of subsequent operations. Now, somewhere in the kernel of my
OS, I do hope that reading this file will have side-effects (putting
the file in the cache, and why not decide to physically move the file
on disk).
Here, obviously, git-diff is a read-only operation for the user. I
don't expect git-diff to modify the behavior of subsequent commands,
but I appreciate if git-diff can improve the speed of subsequent
commands.
Now, both of us agree that git-status should not be read-only for the
filesystem, both of us agree that git-diff should be read-only for the
user, but we disagree on the two other cases.
In the same way, I expect git-status to be read-only for the user. You
say "what _would_ happen _if_ I say commit $args". But you don't
commit, the sentence is conditionnal. I don't expect any tool to have
visible side-effects when I say "what would happen if ...".
--
Matthieu
^ permalink raw reply
* Help a sed noob
From: Nguyen Thai Ngoc Duy @ 2007-08-03 23:22 UTC (permalink / raw)
To: Git Mailing List
Hi,
There is a construct like this in git-parse-remote.sh which makes
busybox ash unhappy:
sed -ne '/^URL: */{
s///p
q
}' "$GIT_DIR/remotes/$1"
It complains about "no previous regexp" while gnu sed is ok. Can
anyone explain to me what does "s///p" do? GNU Sed info page says
nothing about empty regexp. If I replace it with "s/\(.*\)/\1/p" then
I get "URL: " along with the remote path.
By the way, can we use another construct instead? It would be less
work for me ;-)
--
Duy
^ permalink raw reply
* Re: Some ideas for StGIT
From: Yann Dirson @ 2007-08-03 23:23 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Catalin Marinas, git
In-Reply-To: <1186163410.26110.55.camel@dv>
On Fri, Aug 03, 2007 at 01:50:10PM -0400, Pavel Roskin wrote:
> One is to have a command opposite to "export". It would read the files
> that "export" produces, replacing the existing patches.
This should be already possible (although I never used it), with "stg
pop -a && stg import --replace ..."
> Another approach would be to reexamine the patch after "stg refresh -es"
> and to apply it instead of the original patch. If the patch doesn't
> apply, the options would be to discard the edits or to re-launch the
> editor.
Added to wishes: https://gna.org/bugs/index.php?9674
> Next issue is that it should be possible to create a patch in one
> operation. StGIT follows quilt too closely here in requiring "new" and
> "refresh", instead of utilizing the advantage of the workflow that
> allows immediate editing of the sources without any commands.
>
> Basically, I want one command that:
>
> 1) shows user what was changed
> 2) allows user to name the patch
> 3) allows user to describe the patch
> 4) allows user to exclude files from the patch
> 5) doesn't require another command to put the changes to the patch
>
> I think the most natural approach would be to enhance "stg new".
Sure, something like this could be done. A syntax like the following
would IMHO fit in how things are done, but does not exactly address 4:
$ stg new <name> -m <msg> -s [--] <files> <to> <add>
Maybe another --exclude flag to reverse the meaning of the listed
files would be a solution, but I'm not thrilled by this idea...
> I see
> "stg new -s" is supposed to show the changes, but it's currently broken.
> This is run in a clean StGIT repository with no patches:
>
> $ stg new -s foo
Hm, I'm not sure what -s would be supposed to show here, since we're
asking for the creation of a patch, which currently always starts
empty.
Especially confusing is that if there are already applied patches, the
diff shown is the one of the previous top patch - and if there is no
applied patches, we get the exception you noticed.
I guess -s should be removed for 0.13.1.
> Another backtrace in "stg new", also run in a clean StGIT repository with no patches:
This appears to occur when there is no description file, or when it is
empty. Thanks for the report.
I also tried with "stg refresh -m ''" to see if it caused the same
problem, but it appears to have another problem instead: it does not
refresh the patch description at all.
My guess is that we should not allow empty patch description (and
maybe fill it with provided patchname). What did you want to acheieve
precisely with that command ?
> Finally, it would be great to have TLS support in the mail command.
> Mercurial has it, and looking at their mail.py, it doesn't seem to be
> much work.
Added to wishes: https://gna.org/bugs/index.php?9673
Thanks,
--
Yann
^ permalink raw reply
* [PATCH] gitweb: Fix handling of $file_name in feed generation
From: Jakub Narebski @ 2007-08-03 17:50 UTC (permalink / raw)
To: Steven Walter, git; +Cc: Robert Fitzsimons, Junio Hamano
In-Reply-To: <200708031110.55969.jnareb@gmail.com>
>From 6ef05672bb1dd1fe1ded15707164eaac36772c21 Mon Sep 17 00:00:00 2001
From: Steven Walter <stevenrwalter@gmail.com>
From: Jakub Narebski <jnareb@gmail.com>
Date: Fri, 3 Aug 2007 19:35:00 +0200
Subject: [PATCH] gitweb: Fix handling of $file_name in feed generation
The commit b6093a5c, by Robert Fitzsimons:
"gitweb: Change atom, rss actions to use parse_commits."
forgot to pass $file_name parameter to parse_commits subroutine.
If git_feed is provided a file name, it ought to show only the history
affecting that file or a directory. The title was being set
correctly, but all commits from history were being shown.
Signed-off-by: Steven Walter <stevenrwalter@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Three comments. First, authorship. Steven Walter didn't signoff his patch,
and the contents differs a bit from second chunk of his patch (see
comment below) and I have added infor about which commit introduced this
bug to the commit message. I have added my signoff, you can take this
patch as either mine or Steven authorship.
Second, I have discarded first chunk in Steven patch because it was too
intrusive. As I have said, it makes 'file_name' default argument,
unless overriden. While it made sense for 'project' parameter to be made
default parameter in href(), as almost all URLs in gitweb needed it,
more than half URLs does not need 'file_name' parameter. And some of
those URLs are present in a views which do use 'file_name'.
So if we want alternative URLs for a feed preserve 'file_name' parameter,
or we want RSS/Atom links for "file_name" kind of views, like 'tree',
'blob' or 'history' views, we should add 'file_name' parameter
explicitely, and not change href() to do it implicitely.
But as we are in stabilization (freeze) stage, I'd rather not add any new
features. This one just fixes a bug in gitweb.
Third, I'd rather not use "--full-history" for feeds. We use it in the
'history' view for backward compatibility reasons; I'd rather leave it
for extra options in the feed. But this is also for after the release.
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 498b936..4733728 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -5365,7 +5365,7 @@ sub git_feed {
# log/feed of current (HEAD) branch, log of given branch, history of file/directory
my $head = $hash || 'HEAD';
- my @commitlist = parse_commits($head, 150);
+ my @commitlist = parse_commits($head, 150, 0, undef, $file_name);
my %latest_commit;
my %latest_date;
--
1.5.2.4
^ permalink raw reply related
* Re: [PATCH] Add --show-touched option to show "diff --git" line when contents are unchanged
From: Junio C Hamano @ 2007-08-03 23:36 UTC (permalink / raw)
To: Matthieu Moy
Cc: Steven Grimm, Jean-Francois Veillette, git, Johannes Schindelin
In-Reply-To: <vpqir7wi5oc.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
>> "git-status $args" on the other hand is a preview of "what would
>> happen if I say 'git-commit $args'", and in order to compute
>> that, you would fundamentally need to be able to write into the
>> object store. In a special case of giving empty $args it can be
>> read-only.
>
> Can you give an example where it _could_ not be read-only?
Think of what "git commit -a" would have to do. It needs to
hash and deposit a new object for blobs that have been
modified. Where do those new blob object go?
> In the same way, I expect git-status to be read-only for the user. You
> say "what _would_ happen _if_ I say commit $args". But you don't
> commit, the sentence is conditionnal. I don't expect any tool to have
> visible side-effects when I say "what would happen if ...".
By running git-status the user is asking to get the overall
picture, discarding the "touched but not modified" information.
Once you _HAVE TO_ refresh the index for whatever reason, it is
better to keep the result of the effort and cycles spent for
that refresh operation for obvious performance reasons in
practice, and that is what we have now in git-status. IOW, we
are practical bunch.
Maybe in a theoretical ideal world, you might prefer to
reverting back to the stat-dirty original index to make
git-status appear a read-only operation, with continued degraded
performance. You are welcome to reimplement it that way, and
the patch should be trivial (while git-commit.sh is still a
script, at least) but that is not what we did.
^ permalink raw reply
* Re: Help a sed noob
From: Junio C Hamano @ 2007-08-03 23:38 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Git Mailing List
In-Reply-To: <fcaeb9bf0708031622w25ab6e9ev61372169cfc0bd98@mail.gmail.com>
"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
> There is a construct like this in git-parse-remote.sh which makes
> busybox ash unhappy:
>
> sed -ne '/^URL: */{
> s///p
> q
> }' "$GIT_DIR/remotes/$1"
>
> It complains about "no previous regexp" while gnu sed is ok. Can
> anyone explain to me what does "s///p" do? GNU Sed info page says
> nothing about empty regexp. If I replace it with "s/\(.*\)/\1/p" then
> I get "URL: " along with the remote path.
Traditionally empty LHS regexp means "the same as last match".
Replace it with "s/^URL: *//p" and you would be Ok.
^ permalink raw reply
* Re: Help a sed noob
From: René Scharfe @ 2007-08-03 23:40 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Git Mailing List
In-Reply-To: <fcaeb9bf0708031622w25ab6e9ev61372169cfc0bd98@mail.gmail.com>
Nguyen Thai Ngoc Duy schrieb:
> Hi,
>
> There is a construct like this in git-parse-remote.sh which makes
> busybox ash unhappy:
>
> sed -ne '/^URL: */{
> s///p
> q
> }' "$GIT_DIR/remotes/$1"
>
> It complains about "no previous regexp" while gnu sed is ok. Can
> anyone explain to me what does "s///p" do? GNU Sed info page says
> nothing about empty regexp. If I replace it with "s/\(.*\)/\1/p" then
> I get "URL: " along with the remote path.
>
> By the way, can we use another construct instead? It would be less
> work for me ;-)
You could manually add the previous regular expression, like this:
sed -ne '/^URL: */{
s/^URL: *//p
q
}' "$GIT_DIR/remotes/$1"
René
^ permalink raw reply
* Re: question about git-submodule
From: Eran Tromer @ 2007-08-03 23:01 UTC (permalink / raw)
To: Alex Riesen; +Cc: skimo, VMiklos, git
In-Reply-To: <20070715104712.GF2568@steel.home>
On 2007-07-15 06:47, Alex Riesen wrote:
> Sven Verdoolaege, Sun, Jul 15, 2007 10:39:59 +0200:
>> On Fri, Jul 13, 2007 at 11:46:30PM +0200, VMiklos wrote:
>>> i mean, first i thought that after configuring a submodule under libfoo,
>>> then a git pull will update libfoo's repo under libfoo, too. or
>>> something like that.
>> Unless I've missed something, it doesn't.
>> Some of use would like git to do just that (at least Alex Riesen,
>> Martin Waitz and myself have sent in patches to that effect),
>> but we haven't been able to convince Junio yet.
>
> Count me out. Junio convinced me instead and having tried the
> subprojects I find it really convenient: I can choose when and what
> should be updated and I can see what _can_ be updated, iff I decide
> to. Subprojects defined in such a loosely way are more flexible then
> having git-pull fetch subprojects by default. Sometimes I even want be
> _sure_ the subprojects are completely untouched (I have some critical
> parts in them).
All of the above also applies to normal files, not just submodules. So
by this logic, maybe "git pull" and "git checkout" should by default
update just the index, and require a manual "git file update" to update
the files in the working tree?
Leaving the working tree (including submodules) in an inconsistent state
right after a pull or checkout is a very strange thing to do. It means,
for example, that even simple switching between branches doesn't work in
a superproject. Consider this example (tested on next aac97aacbccd):
--------------------------------------------------
Create the subproject repo:
$ mkdir sub-to-be
$ cd sub-to-be
$ git init
$ echo AAA > foo
$ git add foo
$ git commit -m sub
$ cd ..
Create the superproject repo and clone subproject into it:
$ mkdir super
$ cd super
$ git init
$ git submodule add ../sub-to-be sub
$ git commit -m super
Update the submodule:
$ cd sub
$ echo BBB > foo
$ git add foo
$ git commit -m sub
$ cd ..
Update the supermodule:
$ git add sub
$ git commit -m super
Try to switch between versions, and fail miserably:
$ git checkout -b old HEAD^
M sub
Switched to a new branch "old"
$ git checkout master
fatal: Entry 'sub' not uptodate. Cannot merge.
--------------------------------------------------
BTW, is there any easy way to create a submodule directly inside the
supermodule's working tree, instead of cloning it as in the above example?
Eran
^ permalink raw reply
* Re: Help a sed noob
From: Nguyen Thai Ngoc Duy @ 2007-08-04 0:06 UTC (permalink / raw)
To: Junio C Hamano, René Scharfe; +Cc: Git Mailing List
In-Reply-To: <7vhcngkx38.fsf@assigned-by-dhcp.cox.net>
Great! Thank you both.
On 8/3/07, Junio C Hamano <gitster@pobox.com> wrote:
> "Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
>
> > There is a construct like this in git-parse-remote.sh which makes
> > busybox ash unhappy:
> >
> > sed -ne '/^URL: */{
> > s///p
> > q
> > }' "$GIT_DIR/remotes/$1"
> >
> > It complains about "no previous regexp" while gnu sed is ok. Can
> > anyone explain to me what does "s///p" do? GNU Sed info page says
> > nothing about empty regexp. If I replace it with "s/\(.*\)/\1/p" then
> > I get "URL: " along with the remote path.
>
> Traditionally empty LHS regexp means "the same as last match".
> Replace it with "s/^URL: *//p" and you would be Ok.
>
>
--
Duy
^ permalink raw reply
* Re: Git on MSys (or how to make it easy for Windows users to compile git)
From: Torgil Svensson @ 2007-08-04 0:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Dmitry Kakurin, Marius Storm-Olsen, git
In-Reply-To: <Pine.LNX.4.64.0708032231320.14781@racer.site>
Hi,
This is great news for win(-stuck)-users. I've tried
"msysGit-0.2.exe", a few glitches
1. Unpacking in a folder that have space in it's path gave various
errors of this type (here, msysGit is unpacked on the desktop
C:\Documents and settings\.... ) : make[1]: C:/Documents: Command not
found
2. rxvt-terminal had some freezes (echoed input but programs didn't
output anything and didn't seem to respond to ctrl-c). Had it once
during "make" and once during "ls". I't might be related to me
resizing the terminal during command execution (=I didn't see it
otherwise).
3. "gitk --all" said "Error reading commits: fatal: write failure on
stdout: Invalid argument" on start - my other msys installation
didn't. (I didn't do anything to make git dirty - i'm on master and
gitk shows no uncommited changes)
$ git --version
git version mingw.v1.5.2.4.883.g3822-dirty
4. Mouse-wheel didn't work to scroll views in gitk
=> it works with minor installation effort! I've done both MSYS and
Cygwin installs - I think this will lower the git barrier on Win
significantly. Thanks & good work all involved!
Best Regards,
//Torgil
On 8/3/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Fri, 3 Aug 2007, Dmitry Kakurin wrote:
>
> > > * replace rxvt by that stupid cmd window
> > > Sneaky.
> >
> > This was a result of my customization that I have forgot to remove.
> > In general cmd window is more familiar/convenient for Windows users.
> > IMHO, our goal here should be "as native (Windows) as possible". Cygwin fills
> > "as close to *nix as possible" niche.
> > But in any case it's such a minor detail that I don't really care much.
>
> Actually, I finally saw the light and implemented your idea of the
> repo.or.cz repository, containing a full copy of the darn beast.
>
> And there, differences like this one are much easier to spot.
>
> Besides, Marius convinced me already to include two versions.
>
> Ciao,
> Dscho
>
> -
> 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] gitweb: Fix handling of $file_name in feed generation
From: Junio C Hamano @ 2007-08-04 0:25 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Steven Walter, git, Robert Fitzsimons
In-Reply-To: <200708031950.43126.jnareb@gmail.com>
Thanks. This came in while I already tagged -rc4 and was doing
the final round of tests and packaging, so has to become the
first thing post -rc4, unfortunately.
The format of the e-mail message you sent out could use much
improvements but I'll let it pass this time.
^ permalink raw reply
* Re: Git on MSys (or how to make it easy for Windows users to compile git)
From: Johannes Schindelin @ 2007-08-04 0:26 UTC (permalink / raw)
To: Torgil Svensson; +Cc: Dmitry Kakurin, Marius Storm-Olsen, git
In-Reply-To: <e7bda7770708031716i61f80d89o8970b3236a961613@mail.gmail.com>
Hi,
On Sat, 4 Aug 2007, Torgil Svensson wrote:
> Hi,
>
> This is great news for win(-stuck)-users. I've tried
> "msysGit-0.2.exe", a few glitches
>
> 1. Unpacking in a folder that have space in it's path gave various
> errors of this type (here, msysGit is unpacked on the desktop
> C:\Documents and settings\.... ) : make[1]: C:/Documents: Command not
> found
Good point. Did you fix it? If so, where is the patch? Or even better,
what is your account on repo.or.cz so I can add it, and you can commit
your fix yourself?
> 2. rxvt-terminal had some freezes (echoed input but programs didn't
> output anything and didn't seem to respond to ctrl-c). Had it once
> during "make" and once during "ls". I't might be related to me
> resizing the terminal during command execution (=I didn't see it
> otherwise).
I did not experience those. Could you research further?
> 3. "gitk --all" said "Error reading commits: fatal: write failure on
> stdout: Invalid argument" on start - my other msys installation
> didn't. (I didn't do anything to make git dirty - i'm on master and
> gitk shows no uncommited changes)
> $ git --version
> git version mingw.v1.5.2.4.883.g3822-dirty
I did not even bother testing gitk... Any idea what is going wrong?
> 4. Mouse-wheel didn't work to scroll views in gitk
Again, no idea why. Could you please investigate?
> => it works with minor installation effort! I've done both MSYS and
> Cygwin installs - I think this will lower the git barrier on Win
> significantly. Thanks & good work all involved!
Thanks. Your feedback is much appreciated.
Ciao,
Dscho
^ permalink raw reply
* [ANNOUNCE] GIT 1.5.3-rc4
From: Junio C Hamano @ 2007-08-04 0:28 UTC (permalink / raw)
To: git
I tagged 1.5.3-rc4 and it will soon be mirrored out. This is
the last rc before the real thing, which I am hoping to happen
by mid August. Until then, I won't look at anything but
regression fixes and documentation updates. Please test this
one well.
http://www.kernel.org/pub/software/scm/git/
git-1.5.3-rc4.tar.{gz,bz2} (tarball)
git-htmldocs-1.5.3-rc4.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.3-rc4.tar.{gz,bz2} (preformatted docs)
testing/git-*-1.5.3-rc4-1.$arch.rpm (RPM)
----------------------------------------------------------------
GIT v1.5.3 Release Notes (draft)
========================
Updates since v1.5.2
--------------------
* The commit walkers other than http are officially deprecated,
but still supported for now.
* The submodule support has Porcelain layer.
* There are a handful pack-objects changes to help you cope better
with repositories with pathologically large blobs in them.
* For people who need to import from Perforce, a front-end for
fast-import is in contrib/fast-import/.
* Comes with git-gui 0.8.0.
* Comes with updated gitk.
* New commands and options.
- "git log --date=<format>" can use more formats: iso8601, rfc2822.
- The hunk header output from "git diff" family can be customized
with the attributes mechanism. See gitattributes(5) for details.
- "git stash" allows you to quickly save away your work in
progress and replay it later on an updated state.
- "git rebase" learned an "interactive" mode that let you
pick and reorder which commits to rebuild.
- "git fsck" can save its findings in $GIT_DIR/lost-found, without a
separate invocation of "git lost-found" command. The blobs stored by
lost-found are stored in plain format to allow you to grep in them.
- $GIT_WORK_TREE environment variable can be used together with
$GIT_DIR to work in a subdirectory of a working tree that is
not located at "$GIT_DIR/..".
- Giving "--file=<file>" option to "git config" is the same as
running the command with GIT_CONFIG=<file> environment.
- "git log" learned a new option "--follow", to follow
renaming history of a single file.
- "git-filter-branch" lets you rewrite the revision history of
specified branches. You can specify a number of filters to
modify the commits, files and trees.
- "git-cvsserver" learned new options (--base-path, --export-all,
--strict-paths) inspired by git-daemon.
- "git daemon --base-path-relaxed" can help migrating a repository URL
that did not use to use --base-path to use --base-path.
- "git-commit" can use "-t templatefile" option and commit.template
configuration variable to prime the commit message given to you in the
editor.
- "git-submodule" command helps you manage the projects from
the superproject that contain them.
- In addition to core.compression configuration option,
core.loosecompression and pack.compression options can
independently tweak zlib compression levels used for loose
and packed objects.
- "git-ls-tree -l" shows size of blobs pointed at by the
tree entries, similar to "/bin/ls -l".
- "git-rev-list" learned --regexp-ignore-case and
--extended-regexp options to tweak its matching logic used
for --grep fitering.
- "git-describe --contains" is a handier way to call more
obscure command "git-name-rev --tags".
- "git gc --aggressive" tells the command to spend more cycles
to optimize the repository harder.
- "git repack" learned a "window-memory" limit which
dynamically reduces the window size to stay within the
specified memory usage.
- "git repack" can be told to split resulting packs to avoid
exceeding limit specified with "--max-pack-size".
- "git fsck" gained --verbose option. This is really really
verbose but it might help you identify exact commit that is
corrupt in your repository.
- "git format-patch" learned --numbered-files option. This
may be useful for MH users.
- "git format-patch" learned format.subjectprefix configuration
variable, which serves the same purpose as "--subject-prefix"
option.
- "git tag -n -l" shows tag annotations while listing tags.
- "git cvsimport" can optionally use the separate-remote layout.
- "git blame" can be told to see through commits that change
whitespaces and indentation levels with "-w" option.
- "git send-email" can be told not to thread the messages when
sending out more than one patches.
- "git config" learned NUL terminated output format via -z to
help scripts.
- "git init -q" makes the command quieter.
* Updated behavior of existing commands.
- "gitweb" can offer multiple snapshot formats.
***NOTE*** Unfortunately, this changes the format of the
$feature{snapshot}{default} entry in the per-site
configuration file 'gitweb_config.perl'. It used to be a
three-element tuple that describe a single format; with the
new configuration item format, you only have to say the name
of the format ('tgz', 'tbz2' or 'zip'). Please update the
your configuration file accordingly.
- "git diff" (but not the plumbing level "git diff-tree") now
recursively descends into trees by default.
- The editor to use with many interactive commands can be
overridden with GIT_EDITOR environment variable, or if it
does not exist, with core.editor configuration variable. As
before, if you have neither, environment variables VISUAL
and EDITOR are consulted in this order, and then finally we
fall back on "vi".
- "git rm --cached" does not complain when removing a newly
added file from the index anymore.
- Options to "git log" to affect how --grep/--author options look for
given strings now have shorter abbreviations. -i is for ignore case,
and -E is for extended regexp.
- "git svn dcommit" retains local merge information.
- "git config" to set values also honors type flags like --bool
and --int.
- core.quotepath configuration can be used to make textual git
output to emit most of the characters in the path literally.
- "git mergetool" chooses its backend more wisely, taking
notice of its environment such as use of X, Gnome/KDE, etc.
- "gitweb" shows merge commits a lot nicer than before. The
default view uses more compact --cc format, while the UI
allows to choose normal diff with any parent.
- snapshot files "gitweb" creates from a repository at
$path/$project/.git are more useful. We use $project part
in the filename, which we used to discard.
- "git cvsimport" creates lightweight tags; there is no
interesting information we can record in an annotated tag,
and the handcrafted ones the old code created was not
properly formed anyway.
- "git-push" pretends that you immediately fetched back from
the remote by updating corresponding remote tracking
branches if you have any.
- The diffstat given after a merge (or a pull) honors the
color.diff configuration.
- "git commit --amend" is now compatible with various message source
options such as -m/-C/-c/-F.
- "git-apply --whitespace=strip" removes blank lines added at
the end of the file.
- "git-fetch" over git native protocols with "-v" option shows
connection status, and the IP address of the other end, to
help diagnosing problems.
- We used to have core.legacyheaders configuration, when
set to false, allowed git to write loose objects in a format
that mimicks the format used by objects stored in packs. It
turns out that this was not so useful. Although we will
continue to read objects written in that format, we do not
honor that configuration anymore and create loose objects in
the legacy/traditional format.
- "--find-copies-harder" option to diff family can now be
spelled as "-C -C" for brevity.
- "git-mailsplit" (hence "git-am") can read from Maildir
formatted mailboxes.
- "git-cvsserver" does not barf upon seeing "cvs login"
request.
- "pack-objects" honors "delta" attribute set in
.gitattributes. It does not attempt to deltify blobs that
come from paths with delta attribute set to false.
- "new-workdir" script (in contrib) can now be used with a
bare repository.
- "git-mergetool" learned to use gvimdiff.
- "gitview" (in contrib) has a better blame interface.
- "git log" and friends did not handle a commit log message
that is larger than 16kB; they do now.
- "--pretty=oneline" output format for "git log" and friends
deals with "malformed" commit log messages that have more
than one lines in the first paragraph better. We used to
show the first line, cutting the title at mid-sentence; we
concatenate them into a single line and treat the result as
"oneline".
- "git p4import" has been demoted to contrib status. For
a superior option, checkout the git-p4 front end to
git-fast-import (also in contrib). The man page and p4
rpm have been removed as well.
- "git mailinfo" (hence "am") now tries to see if the message
is in utf-8 first, instead of assuming iso-8859-1, if
incoming e-mail does not say what encoding it is in.
* Builds
- old-style function definitions (most notably, a function
without parameter defined with "func()", not "func(void)")
have been eradicated.
* Performance Tweaks
- git-pack-objects avoids re-deltification cost by caching
small enough delta results it creates while looking for the
best delta candidates.
- git-pack-objects learned a new heuristcs to prefer delta
that is shallower in depth over the smallest delta
possible. This improves both overall packfile access
performance and packfile density.
- diff-delta code that is used for packing has been improved
to work better on big files.
- when there are more than one pack files in the repository,
the runtime used to try finding an object always from the
newest packfile; it now tries the same packfile as we found
the object requested the last time, which exploits the
locality of references.
- verifying pack contents done by "git fsck --full" got boost
by carefully choosing the order to verify objects in them.
Fixes since v1.5.2
------------------
All of the fixes in v1.5.2 maintenance series are included in
this release, unless otherwise noted.
* Bugfixes
- "gitweb" had trouble handling non UTF-8 text with older
Encode.pm Perl module.
^ permalink raw reply
* Re: core.gitproxy and non-git protocols
From: Jakub Narebski @ 2007-08-04 0:33 UTC (permalink / raw)
To: git
In-Reply-To: <ee77f5c20708012221j4d75ff0dl8fbf16cdaf1401bd@mail.gmail.com>
[Cc: David Symonds <dsymonds@gmail.com>, gmane.comp.version-control.git]
David Symonds wrote:
> I have a situation where I'd like to push to a remote git repository
> on a machine that is a little weird to access, so I need two different
> types of ssh'ing to reach it depending on my location. That is easily
> scriptable, which is how I did it with SVN (ended up with a
> svn+voltron:// protocol), but is not currently possible with git.
See http://git.or.cz/gitwiki/GitTip, section "How to push/pull via ssh to
host behind gateway?". It describes two solutions: first, using
ProxyCommand option of ssh and netcat utility on gateway, second via ssh
tunnel set up.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: core.gitproxy and non-git protocols
From: Jakub Narebski @ 2007-08-04 0:34 UTC (permalink / raw)
To: git
In-Reply-To: <20070802053151.GH20052@spearce.org>
Shawn O. Pearce wrote:
> David Symonds <dsymonds@gmail.com> wrote:
>> It'd be great if (a) the documentation could be fixed, or (b) the
>> proxy-picking code could be at least extended to ssh:// protocols, and
>> preferrably extended to defining custom protocols.
>
> Did you try setting GIT_SSH envvar to point to a script that does
> what you need? I do this in one particular case...
GIT_SSH environmental variable is *not described* anywhere in the
documentation. Would you be so kind?
--
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