* Re: GIT on MinGW problem
From: Junio C Hamano @ 2007-05-12 1:17 UTC (permalink / raw)
To: Aaron Gray; +Cc: Git Mailing List
In-Reply-To: <1dbc01c79432$b4400a80$0200a8c0@AMD2500>
"Aaron Gray" <angray@beeb.net> writes:
> Hello,
>
> I have installed the git-1.5.1-1.mingw.exe from
> http://lilypond.org/git/binaries/mingw/.
>
> On typing 'git' I get a message box saying :-
>
> The procedure entry point libiconv could not be located in the
> dynamic link library libiconv-2.dll.
>
> I cannot seem to find libiconv-2.dll anywhere either.
>
> Hope you can help.
>
> Many thanks in advance,
>
> Aaron
Even myself (who does not have anything to do with Windows
machines) remembers seeing this exact thing in the past 12
hours:
article.gmane.org/gmane.comp.version-control.git/46962
Please check the archive before asking. Thanks.
^ permalink raw reply
* GIT on MinGW problem
From: Aaron Gray @ 2007-05-12 1:13 UTC (permalink / raw)
To: Git Mailing List
Hello,
I have installed the git-1.5.1-1.mingw.exe from
http://lilypond.org/git/binaries/mingw/.
On typing 'git' I get a message box saying :-
The procedure entry point libiconv could not be located in the
dynamic link library libiconv-2.dll.
I cannot seem to find libiconv-2.dll anywhere either.
Hope you can help.
Many thanks in advance,
Aaron
^ permalink raw reply
* [PATCH] Document subproject feature
From: Amos Waterland @ 2007-05-12 0:58 UTC (permalink / raw)
To: git
Add a section to the user manual about the new subproject support.
Show how to make a subproject.
Signed-off-by: Amos Waterland <apw@us.ibm.com>
---
user-manual.txt | 35 ++++++++++++++++++++++++++++++++++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 13db969..27d601f 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1,4 +1,4 @@
-Git User's Manual (for version 1.5.1 or newer)
+Git User's Manual (for version 1.5.2 or newer)
______________________________________________
This manual is designed to be readable by someone with basic unix
@@ -1406,6 +1406,39 @@ just performs a "fast forward"; the head of the current branch is moved
forward to point at the head of the merged-in branch, without any new
commits being created.
+[[subprojects]]
+Subprojects
+-----------
+
+Some large development efforts, such as embedded Linux distributions,
+are composed of a set of large projects, each with its own development
+team, but all of which are combined to produce the project as a whole.
+For example, there might be a firmware project, a hypervisor project,
+a kernel project, and a userspace project. Note that while each
+project is conceptually independent, there are many cases in which a
+change to the hypervisor necessitates a change to the kernel, for
+example.
+
+In this case it is nice to be able to reason about the state of the
+entire project, but also not inconvenience each development team with
+checking out a gigantic repository that represents the entire project.
+Git provides subproject support for this case, which is similar to CVS
+modules or the hg forest extension.
+
+Here is an example of creating a subproject inside an existing project:
+
+-------------------------------------------------
+$ mkdir subproject
+$ cd subproject
+$ git init
+$ touch Makefile
+$ git add Makefile
+$ git commit -m "Create subproject."
+$ cd ..
+$ git add subproject
+$ git commit -m "Add subproject."
+-------------------------------------------------
+
[[fixing-mistakes]]
Fixing mistakes
---------------
^ permalink raw reply related
* Re: [PATCH] gitweb: Avoid "Use of uninitialized value" errors (written to logs)
From: Junio C Hamano @ 2007-05-12 1:06 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200705120135.30150.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Try to avoid "Use of uninitialized value ..." errors, due to bad
> revision, incorrect filename, wrong object id, bad file etc. (wrong
> value of 'h', 'hb', 'f', etc. parameters). This avoids polluting web
> server errors log.
>
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
> ---
> This is a bit of "bandaid" patch, as if possible the callers should
> be corrected, and should check if there is something to pass along.
If the bad values come from the end user (via the browser), I
suspect that should be checked and rejected far earlier than
this sub on the output path is called. Are there code that
internally needs to pass bogus values to this function?
@@ -594,6 +594,9 @@ sub esc_html ($;%) {
my $str = shift;
my %opts = @_;
+ # empty or undefined
+ return $str unless $str;
+
I think this is wrong, as the callers of esc_html typically
concatenate the return value with other strings. If $str could
be undef, the caller would end up getting the warning when doing
the concatenation, so you did not solve anything.
$str could be '0' (literal string constant whose length is 1 and
has character *zero* in it), in which case you return it intact.
It is safe only because esc_html('0') is '0' itself; use of
"unless $str" here is a very bad style.
A more straightforward way obviously is:
if (!defined $str) {
return '';
}
@@ -1059,6 +1062,7 @@ sub git_get_hash_by_path {
or die_error(undef, "Open git-ls-tree failed");
my $line = <$fd>;
close $fd or return undef;
+ $line or return undef;
#'100644 blob 0fa3f3a66fb6a137f6ec2c19351ed4d807070ffa panic.c'
$line =~ m/^([0-9]+) (.+) ([0-9a-fA-F]{40})\t/;
I think this one means well but not quite to my taste; path may
be given by the end user and we need to run ls-tree to find out
if that path exists or not here. $line would be undefined if
path does not exist, so...
if (!defined $line) {
return undef;
}
Note that it is very unlikely that $line consists of single '0'
here, so "$line or ..." would probably not break in practice.
My preference to use defined is more style and discipline thing.
@@ -1377,7 +1381,7 @@ sub parse_commit_text {
pop @commit_lines; # Remove '\0'
my $header = shift @commit_lines;
- if (!($header =~ m/^[0-9a-fA-F]{40}/)) {
+ if (!defined $header || $header !~ m/^[0-9a-fA-F]{40}/) {
return;
}
($co{'id'}, my @parents) = split ' ', $header;
I would prefer checking the length of @commit_linse before
blindly shifting it out.
if (!@commit_lines) {
return;
}
my $header = shift @commit_lines;
...
I am Ok with "return if (!@commit_lines);" if you feel it is
more Perl-ish.
One final note.
If you think using postfix "Statement Modifiers" somehow makes
your program look more Perl-ish, I think you should reconsider.
IMHO, coding more carefully to distinguish undef and other forms
of falsehood where the difference matters would make your code
look much more Perl-ish.
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: Jakub Narebski @ 2007-05-12 1:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkfu98nn.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> -'git-add' [-n] [-v] [-f] [--interactive | -i] [-u] [--] <file>...
>> +'git-add' [-n] [-v] [-f] (-u [[--] <file>...] | [--] <file>...)
>
> I do not think this is correct; does -u take optionally path and
> when path is ambiguous you can add -- to disambiguate?
[...]
With *current* implementation you should take previous patch,
amended, with the following synopsis:
-'git-add' [-n] [-v] [-f] [--interactive | -i] [-u] [--] <file>...
+'git-add' [-n] [-v] [-f] (-u | [--] <file>...)
+'git-add' (--interactive | -i)
> Of course, I would prefer a patch to allow use of paths with -u
> even more, but that is what I already said ;-).
The following synopsis is for such case:
-'git-add' [-n] [-v] [-f] [--interactive | -i] [-u] [--] <file>...
+'git-add' [-n] [-v] [-f] (-u [[--] <file>...] | [--] <file>...)
+'git-add' (--interactive | -i)
This is for "-u take optionally path and when path is ambiguous you can
add -- to disambiguate", for example if you have '--interactive' file.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: Junio C Hamano @ 2007-05-12 0:40 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200705120106.53624.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> -'git-add' [-n] [-v] [-f] [--interactive | -i] [-u] [--] <file>...
> +'git-add' [-n] [-v] [-f] (-u [[--] <file>...] | [--] <file>...)
I do not think this is correct; does -u take optionally path and
when path is ambiguous you can add -- to disambiguate?
Honestly, I would rather not sprinkle synopsis with too many
nested parentheses and brackets, which only makes it harder to
see without giving a clear "this combines with that but is not
compatible with the other" information. Adding comment to the
section that begins with "-u::" that says "... commit -a; this
option does not take any paths parameters." would be cleaner,
and easier to understand.
Of course, I would prefer a patch to allow use of paths with -u
even more, but that is what I already said ;-).
^ permalink raw reply
* Re: git rebase chokes on directory -> symlink -> directory
From: H. Peter Anvin @ 2007-05-12 0:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, Git Mailing List
In-Reply-To: <7vps569904.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
>
>> Mine stops already at the directory -> symlink checkin (the above is the
>> symlink -> directory one), but your trick of using "git checkout" as a
>> trick to resolve things helped for both... eventually :-/
>
> I've tried to redo your rebase using:
>
> apply: do not get confused by symlinks in the middle
>
> patch on top of 'master'. It successfully run through the end.
>
> So I think I can declare victory for now ;-).
>
YAY! Huge thanks!
-hpa
^ permalink raw reply
* Re: git rebase chokes on directory -> symlink -> directory
From: Junio C Hamano @ 2007-05-12 0:32 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Alex Riesen, Git Mailing List
In-Reply-To: <46413565.3090503@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> Mine stops already at the directory -> symlink checkin (the above is the
> symlink -> directory one), but your trick of using "git checkout" as a
> trick to resolve things helped for both... eventually :-/
I've tried to redo your rebase using:
apply: do not get confused by symlinks in the middle
patch on top of 'master'. It successfully run through the end.
After rebasing f1bb07af ("rebase-1" in your repository) on to
a989705 (near the tip of Linus), I did
git diff --stat --summary a989705...f1bb07af
git diff --stat --summary a989705...HEAD
(that is, "show me the change since the merge base") and the
results from these two diffs match exactly.
So I think I can declare victory for now ;-).
However.
I usually have "[apply] whitespace = strip" in my ~/.gitconfig,
but during this verification run, I disabled it to keep rebase
from falling back to 3-way merge using merge-recursive. If I
turn it on, rebase still fails and I strongly suspect "rebase
-m" would fail the same way, although I haven't tried it (it
takes too much time).
I'll be somewhat busy this weekend, so I would welcome anybody
else beating me to fixing the problem in merge-recursive.
^ permalink raw reply
* [PATCH] gitweb: Avoid "Use of uninitialized value" errors (written to logs)
From: Jakub Narebski @ 2007-05-11 23:35 UTC (permalink / raw)
To: git
Try to avoid "Use of uninitialized value ..." errors, due to bad
revision, incorrect filename, wrong object id, bad file etc. (wrong
value of 'h', 'hb', 'f', etc. parameters). This avoids polluting web
server errors log.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This is a bit of "bandaid" patch, as if possible the callers should
be corrected, and should check if there is something to pass along.
gitweb/gitweb.perl | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 21864c6..afa0056 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -594,6 +594,9 @@ sub esc_html ($;%) {
my $str = shift;
my %opts = @_;
+ # empty or undefined
+ return $str unless $str;
+
$str = decode_utf8($str);
$str = $cgi->escapeHTML($str);
if ($opts{'-nbsp'}) {
@@ -1059,6 +1062,7 @@ sub git_get_hash_by_path {
or die_error(undef, "Open git-ls-tree failed");
my $line = <$fd>;
close $fd or return undef;
+ $line or return undef;
#'100644 blob 0fa3f3a66fb6a137f6ec2c19351ed4d807070ffa panic.c'
$line =~ m/^([0-9]+) (.+) ([0-9a-fA-F]{40})\t/;
@@ -1377,7 +1381,7 @@ sub parse_commit_text {
pop @commit_lines; # Remove '\0'
my $header = shift @commit_lines;
- if (!($header =~ m/^[0-9a-fA-F]{40}/)) {
+ if (!defined $header || $header !~ m/^[0-9a-fA-F]{40}/) {
return;
}
($co{'id'}, my @parents) = split ' ', $header;
--
1.5.1.3
^ permalink raw reply related
* Re: [PATCH] git-commit: Reformat log messages provided on commandline
From: Jakub Narebski @ 2007-05-12 0:25 UTC (permalink / raw)
To: git
In-Reply-To: <7vsla5pkug.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> This is slightly related, but I have been wondering about the
> interaction with "single-liner summary, empty line and then the
> rest" convention and various commands in the log family.
>
> Currently, --pretty=oneline and --pretty=email (hence format-patch)
> take and use only the first line. I think we could change it to:
>
> - take the first paragraph, where the definition of the first
> paragraph is "skip all blank lines from the beginning, and
> then grab everything up to the next empty line".
>
> - replace all line breaks with a whitespace.
[...]
> If we were to do this, Subject: line would most likely use
> RFC2822 line folding at the places where line breaks were in the
> original, but that goes without saying.
>
> What do people think?
I agree that it is a good idea. This would e.g. help projects which are
imported from other SCM, which does not have "single-liner summary, empty
line and then the rest" convention of formatting commit messages.
BTW. does rebase work correctly for commits which do not use above
convention?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: Jakub Narebski @ 2007-05-11 23:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7irfcns1.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>> On Fri, 11 May 2007, Junio C Hamano wrote:
>>> Jakub Narebski <jnareb@gmail.com> writes:
>>>
>>>> In the new version of git I *think* you can use "git add -u path/"
>>>
>>> I know you meant well, but next time could you please check the
>>> fact before speaking?
>>
>>> if (i < argc)
>>> die("-u and explicit paths are incompatible");
>>
>>> The list is getting more and more cluttered recently, perhaps
>>> which is a good sign that more new people are actually using
>>> git. Let's try to keep the signal quality of the messages on
>>> the list high.
>>
>> I'm sorry I haven't checked this before writing, especially that
>> information in the synopsis contradict a bit the information in
>> the `-u' option description:
>> ...
>> -u::
>> Update all files that git already knows about. This is what
>> "git commit -a" does in preparation for making a commit.
>
> What does "git commit -a" do? Does it take paths?
I was mislead by synopsis, which reads:
'git-add' [-n] [-v] [-f] [--interactive | -i] [-u] [--] <file>...
It looks from it like -u is _not_ incompatibile with explicit paths;
moreover it looks like explicit path is _required_.
>> I think however that "git add -u dir/" could be quite useful; it is
>> not needed to have `-u' and explicit paths incompatibile.
>
> I tend to agree, and I think that change should not be too
> difficult.
So do you want to accept my patch for git-add documentation for now,
or rather the replacement patch below? Well, best with the patch that
changes -u to be able to work with explicit codepath...
> Also it might make sense to have "git commit" use it in the
> "git-commit --only $paths" codepath. I dunno.
Didn't you mean "git commit --include $paths" codepath? IIRC --only
codepath deals with temporary index...
-- >8 --
From: Jakub Narebski <jnareb@gmail.com>
Date: Sat, 12 May 2007 01:05:01 +0200
Subject: [PATCH] Documentation: Correct synopsis for git-add command
Change SYNOPISIS section of Documentation/git-add.txt to mark it
explicitely that -u option does not need explicit paths, and that
"add --interactive does not take any parameters".
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Documentation/git-add.txt | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index ea27018..3c6d431 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -7,7 +7,8 @@ git-add - Add file contents to the changeset to be committed next
SYNOPSIS
--------
-'git-add' [-n] [-v] [-f] [--interactive | -i] [-u] [--] <file>...
+'git-add' [-n] [-v] [-f] (-u [[--] <file>...] | [--] <file>...)
+'git-add' (--interactive | -i)
DESCRIPTION
-----------
--
1.5.1.3
^ permalink raw reply related
* Re: Build Failure: GIT-GUI-VARS
From: Jeff King @ 2007-05-12 0:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brian Gernhardt, Git Mailing List
In-Reply-To: <7v3b23cmm5.fsf@assigned-by-dhcp.cox.net>
On Fri, May 11, 2007 at 10:10:26AM -0700, Junio C Hamano wrote:
> I have not been very sympathetic to config.mak from the
> beginning, although people seem to want it. As I try to arrange
> variable overrides to be passed from the command line anyway,
> I've not used config.mak myself.
>
> [...]
>
> (3) The volunteer cooks up an improved Makefile, using
> config.mak "non-stock" testers have.
I wonder if we would be better served by moving these sorts of
build-time configuration decisions into the actual make dependency
tree. E.g., something like:
openssl.lib: mklib-openssl.sh conf-openssl
sh mklib-openssl.sh <conf-ssl >openssl.lib
program: main.o openssl.lib:
cc -o "$@" main.o `cat openssl.lib`
where conf-openssl specifies the user's preference (either actual
library paths, "auto" for autodetection, or "none" not to use it at
all), and mklib-openssl is a script that converts that into the command
line options for the link.
You can of course do the same with creating a .h file to choose an
implementation (you just make a file that #define's the correct thing).
The nice thing about this approach is that:
1. You move configuration cruft out of the Makefile, making it much
easier to read. Instead, you have a series of very small and
obvious shell scripts.
2. The dependency chain is actually correct. If I edit conf-openssl,
then that should trigger a re-link for everything which compiles
against it.
You can also use this for portability fixes:
program: main.o strcasestr.o
cc -o "$@" main.o strcasestr.o
strcasestr.o choose try_strcasestr.c compat/strcasestr.c
sh choose try_strcasestr.c compat/strcasestr.c
where choose is a script that compiles and runs some test program and
uses the result to choose a source file to become strcasestr.c. Thus you
_always_ link against strcasestr.o, it's just that sometimes there's an
implementation of strcasestr in it (if required by the platform) and
sometimes it's empty (or an alternate implementation, etc).
I have used this technique many times, and would be happy to be involved
in changing the Makefile. However, it's going to be quite a large
change, and I recognize that this style is not familiar to most people,
so obviously that should be taken into account.
-Peff
^ permalink raw reply
* [PATCH] t9400: Use the repository config and nothing else.
From: Junio Hamano @ 2007-05-11 23:35 UTC (permalink / raw)
To: junkio; +Cc: git
git-cvsserver has a bug in its configuration file output parser
that makes it choke if the configuration has these:
[diff]
color = auto
[diff.color]
whitespace = blue reverse
This needs to be fixed, but thanks to that bug, a separate bug
in t9400 test script was discovered. The test discarded
GIT_CONFIG instead of pointing at the proper one to be used in
the exoprted repository. This allowed user's .gitconfig and (if
exists) systemwide /etc/gitconfig to affect the outcome of the
test, which is a big no-no.
The patch fixes the problem in the test. Fixing the
git-cvsserver's configuration parser is left as an exercise to
motivated volunteers ;-)
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* I think the fix to git-cvsserver should be straightforward.
Instead of parsing two or three level names in a hierarchical
hash around ll.187-192 for *all* config items, it should just
parse gitcvs related ones only, as that are the only ones
that the script cares about.
t/t9400-git-cvsserver-server.sh | 15 ++++++++-------
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/t/t9400-git-cvsserver-server.sh b/t/t9400-git-cvsserver-server.sh
index f137b30..b136a97 100755
--- a/t/t9400-git-cvsserver-server.sh
+++ b/t/t9400-git-cvsserver-server.sh
@@ -26,6 +26,7 @@ perl -e 'use DBI; use DBD::SQLite' >/dev/null 2>&1 || {
unset GIT_DIR GIT_CONFIG
WORKDIR=$(pwd)
SERVERDIR=$(pwd)/gitcvs.git
+git_config=$SERVERDIR/config
CVSROOT=":fork:$SERVERDIR"
CVSWORK=$(pwd)/cvswork
CVS_SERVER=git-cvsserver
@@ -43,7 +44,7 @@ echo >empty &&
# note that cvs doesn't accept absolute pathnames
# as argument to co -d
test_expect_success 'basic checkout' \
- 'cvs -Q co -d cvswork master &&
+ 'GIT_CONFIG="$git_config" cvs -Q co -d cvswork master &&
test "$(echo $(grep -v ^D cvswork/CVS/Entries|cut -d/ -f2,3,5))" = "empty/1.1/"'
test_expect_success 'cvs update (create new file)' \
@@ -52,7 +53,7 @@ test_expect_success 'cvs update (create new file)' \
git commit -q -m "Add testfile1" &&
git push gitcvs.git >/dev/null &&
cd cvswork &&
- cvs -Q update &&
+ GIT_CONFIG="$git_config" cvs -Q update &&
test "$(echo $(grep testfile1 CVS/Entries|cut -d/ -f2,3,5))" = "testfile1/1.1/" &&
diff -q testfile1 ../testfile1'
@@ -63,7 +64,7 @@ test_expect_success 'cvs update (update existing file)' \
git commit -q -m "Append to testfile1" &&
git push gitcvs.git >/dev/null &&
cd cvswork &&
- cvs -Q update &&
+ GIT_CONFIG="$git_config" cvs -Q update &&
test "$(echo $(grep testfile1 CVS/Entries|cut -d/ -f2,3,5))" = "testfile1/1.2/" &&
diff -q testfile1 ../testfile1'
@@ -76,7 +77,7 @@ test_expect_failure "cvs update w/o -d doesn't create subdir (TODO)" \
git commit -q -m "Single Subdirectory" &&
git push gitcvs.git >/dev/null &&
cd cvswork &&
- cvs -Q update &&
+ GIT_CONFIG="$git_config" cvs -Q update &&
test ! -d test'
cd "$WORKDIR"
@@ -89,7 +90,7 @@ test_expect_success 'cvs update (subdirectories)' \
git commit -q -m "deep sub directory structure" &&
git push gitcvs.git >/dev/null &&
cd cvswork &&
- cvs -Q update -d &&
+ GIT_CONFIG="$git_config" cvs -Q update -d &&
(for dir in A A/B A/B/C A/D E; do
filename="file_in_$(echo $dir|sed -e "s#/# #g")" &&
if test "$(echo $(grep -v ^D $dir/CVS/Entries|cut -d/ -f2,3,5))" = "$filename/1.1/" &&
@@ -107,7 +108,7 @@ test_expect_success 'cvs update (delete file)' \
git commit -q -m "Remove testfile1" &&
git push gitcvs.git >/dev/null &&
cd cvswork &&
- cvs -Q update &&
+ GIT_CONFIG="$git_config" cvs -Q update &&
test -z "$(grep testfile1 CVS/Entries)" &&
test ! -f testfile1'
@@ -118,7 +119,7 @@ test_expect_success 'cvs update (re-add deleted file)' \
git commit -q -m "Re-Add testfile1" &&
git push gitcvs.git >/dev/null &&
cd cvswork &&
- cvs -Q update &&
+ GIT_CONFIG="$git_config" cvs -Q update &&
test "$(echo $(grep testfile1 CVS/Entries|cut -d/ -f2,3,5))" = "testfile1/1.4/" &&
diff -q testfile1 ../testfile1'
^ permalink raw reply related
* -mm git tree
From: J. Bruce Fields @ 2007-05-11 23:05 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: Git Mailing List, linux-kernel
The git tree at
git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git
could be set up in a simpler way:
$ git ls-remote git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git
fc4b5be9e651d3e71b54541e0315fc82211b42b5 refs/heads/option_export
59a1fe35614c3c937a4e8cb6e4a45f1d05544d9d refs/heads/v2.6.13-mm1
e3602088f81f66655ec6c62320d5c56839ffc02b refs/heads/v2.6.13-mm2
...
05230bd16821e2ec80321d72e97e7a2b1a07c6f2 refs/tags/master
...
5e1302f173f63c5c57c5de8b44152c30ae2a72c4 refs/tags/v2.6.13-mm1
59a1fe35614c3c937a4e8cb6e4a45f1d05544d9d refs/tags/v2.6.13-mm1^{}
a06c5a7b36cfb30345a9476cbaff02955483c4ca refs/tags/v2.6.13-mm2
e3602088f81f66655ec6c62320d5c56839ffc02b refs/tags/v2.6.13-mm2^{}
...
Would it be possible to remove the branches that exist for each
individual version, and to change the "master" tag to a branch?
Since git gives tag names priority over head names, fetching the above
tag makes "master" refer to it instead of any local branch named
"master".
(I get particularly bizarre behavior with current git; after:
git remote add mm git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git
git fetch mm
when I check out "master", it sets HEAD to refs/heads/master, but the
index and working tree to refs/tags/master.)
I think it may have been set up this way with the idea that a branch
should only ever move "forward" in history, whereas tags could move
around freely.
But that's not really right--for something like -mm that's continually
rewritten and rebased, it makes sense to have a "master" branch that
skips around. The default git-remote setup on recent git is prepared to
deal with this.
And having a repository with 101 branches and counting, none of which
every change, is awkward--if nothing else it makes the output of
"git-branch -r" a little hard to read.
--b.
^ permalink raw reply
* Re: Using StGIT for tweaking already-committed stuff
From: Karl Hasselström @ 2007-05-11 22:43 UTC (permalink / raw)
To: Yann Dirson
Cc: Petr Baudis, Carl Worth, J. Bruce Fields, Linus Torvalds,
Johannes Sixt, catalin.marinas, git
In-Reply-To: <20070511204016.GH19253@nan92-1-81-57-214-146.fbx.proxad.net>
On 2007-05-11 22:40:17 +0200, Yann Dirson wrote:
> On Fri, May 11, 2007 at 12:23:47AM +0200, Karl Hasselström wrote:
>
> > But you can kind of do it today. Just commit with git (my favorite
> > here is the emacs modes) and "stg assimilate"!
>
> Well, that's arguably a non-orthodox way of doing things, I like the
> idea your "stg new" patch much better :)
It's only unothodox if you expect git and stgit to not always mix so
well. But if we have the ambition that they should interoperate as
near to seamlessly as we can make them, this kind of workflow becomes
very natural.
It shouldn't be necessary with a manual "assimilate" step. If stgit
finds that there are unadorned git commits on top of the patch stack,
it should do the assimilation automatically. With that in place, "stg
new" and "stg refresh" would be nearly superfluous, since git-commit
with and without --amend does the same thing -- the only thing they
won't do is give the user the option of manually choosing the patch
name.
I believe this sort of integration is the way to go. It'll be
beneficial for git users who want to occasionally use some stgit to
rebase their patch series, since they'll not have to learn more than
two or three new commands in addition to the git they already know.
Heavy stgit users will benefit from having the much larger git
community maintaining a large subset of the porcelain they use,
instead of having to duplicate the effort and always lag behind.
This is no binary choice, of course. One could certainly imagine a
compromise where stgit becomes much easier to mix with git than today,
but still retains the current command set.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* cvsps patches
From: Yann Dirson @ 2007-05-11 22:39 UTC (permalink / raw)
To: GIT list
Here is an update on cvsps patches.
* The repository has just been moved to repo.or.cz, since uploading to
the old one was a PITA
Gitweb and pull instructions at http://repo.or.cz/w/cvsps-yd.git
* A handful of new patches have been sent to me since the last update.
Since I don't have much time to allocate to this, I have added those
to the to-check branch. I'd be glad to have feedback on them :)
- Fix buffer overflow in cvsps if a log message line is longer than BUFSIZ
- Fix parsing of pserver URL in open_ctx_pserver()
- Initial support for CVS branch aliases.
OTOH, I probably missed some posted to this list, I may find some
time to dig for them - but if you'd like to see them in the repo,
better send them directly to me.
* I also noticed some time ago another cvsps repo at freedesktop, but
did not look at it too close for now.
http://gitweb.freedesktop.org/?p=freedesktop/cvsps.git;a=summary
Best regards,
--
Yann.
^ permalink raw reply
* Re: kernel cherry UN-picking?
From: Junio C Hamano @ 2007-05-11 22:11 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Git Mailing List, Linus Torvalds, Andrew Morton
In-Reply-To: <7vbqgr9fn9.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Suppose you have something like this (you may have more than one
> such merge but the principle is the same):
>
> U---o---o---o---M---x---o---o---o---T
> /
> Linville o---o
>
> Up to 'U' you have already sent upstream and no need for
> resending. 'M' is merge with Linville tree. 'x' is the bad
> one, and 'o' are good ones. 'T' is the tip of your net driver
> branch.
>
> First find out 'x'. Then
>
> git format-patch -o ./outdir x..T
>
> would format everything starting from (but excluding) 'x' up to
> 'T'.
>
> Then
>
> git reset --hard x^
> git am ./outdir/*.patch
>
> would rebuild:
>
> U---o---o---o---M---x---o'--o'--o'--T'
> /
> Linville o---o
Correction. This would rebuild:
U---o---o---o---M-------o'--o'--o'--T'
/
Linville o---o
as if 'x' did not happen.
^ permalink raw reply
* Re: kernel cherry UN-picking?
From: Junio C Hamano @ 2007-05-11 22:09 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Git Mailing List, Linus Torvalds, Andrew Morton
In-Reply-To: <7vhcqj9g8r.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Jeff Garzik <jeff@garzik.org> writes:
>
>> So, I merge the next batch of net driver patches. After I merge a PPP
>> patch, deep in the pile-o-patches, Andrew says "I shouldn't have sent
>> that to you, don't apply it" ;-)
>>
>> Right now, my process for reversing this damage is to start over:
>> create a new branch, manually double-click the mouse on each commit in
>> the "damaged" branch, and git-cherrypick it. Very, very time
>> consuming when you have more than a couple commits.
>
> Do the commits on the branch being rebuilt form a single strand
> of pearls without any merges? If that is the case, what I would
> do is:
>
> git heckout thatbranch
> git format-patch -o ./+outdir linus
> rm ./+outdir/0XXX-that-unwanted-patch.patch
> git reset --hard linus
> git am ./+outdir/????-*.patch
Ok, you answered that your branch involves a merge from Linville
tree.
You would need to segment things then.
Suppose you have something like this (you may have more than one
such merge but the principle is the same):
U---o---o---o---M---x---o---o---o---T
/
Linville o---o
Up to 'U' you have already sent upstream and no need for
resending. 'M' is merge with Linville tree. 'x' is the bad
one, and 'o' are good ones. 'T' is the tip of your net driver
branch.
First find out 'x'. Then
git format-patch -o ./outdir x..T
would format everything starting from (but excluding) 'x' up to
'T'.
Then
git reset --hard x^
git am ./outdir/*.patch
would rebuild:
U---o---o---o---M---x---o'--o'--o'--T'
/
Linville o---o
A variant that needs "segmenting" is if the bad one is before
the merge, like this:
U---o---x---b---M---o---o---o---o---T
/
Linville o---a
First you need to note 'a' (tip of Linville you pulled) and 'b'
(tip of you before you pulled from Linville). Then:
git format-patch -o ./outdir-1 x..b
git format-patch -o ./outdir-2 M..T
git reset --hard x^
git am ./outdir-1/*.patch
would give you this:
U---o-------b'
Linville o---a
and leave you at b (rebased not to contain the bad one). Then
you redo the Linville merge:
U---o-------b'--M'
/
Linville o---a
And finally apply the rest:
git am ./outdir-2/*.patch
to arrive at:
U---o-------b'--M'--o'--o'--o'--o'--T'
/
Linville o---a
^ permalink raw reply
* Re: Anyone running GIT on native Windows
From: Han-Wen Nienhuys @ 2007-05-11 22:08 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Marco Costalba
In-Reply-To: <200705112207.02206.J.Sixt@eudaptics.com>
2007/5/11, Johannes Sixt <J.Sixt@eudaptics.com>:
> >
> > Can you be more specific? Which files required this?
>
> git.exe, for example, hence, at least all builtins.
>
> > It is entirely coincidental that another DLL from another package
> > works, and it's a bug in our packaging.
>
> Why should this not work? The diffutils package I mentioned is from MinGW.
Because libintl.dll is actually generated in the cross-compile (as
part of the LilyPond), and might be a different version than the one
you randomly downloaded.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: kernel cherry UN-picking?
From: Jeff Garzik @ 2007-05-11 21:56 UTC (permalink / raw)
To: Andrew Morton; +Cc: Git Mailing List, Linus Torvalds
In-Reply-To: <20070511145509.09f3c354.akpm@linux-foundation.org>
Andrew Morton wrote:
> On Fri, 11 May 2007 17:31:14 -0400
> Jeff Garzik <jeff@garzik.org> wrote:
>
>> So, I merge the next batch of net driver patches. After I merge a PPP
>> patch, deep in the pile-o-patches, Andrew says "I shouldn't have sent
>> that to you, don't apply it" ;-)
>
> I'm bad.
You're just an example. This is a problem guaranteed to appear...
>> Right now, my process for reversing this damage is to start over:
>> create a new branch, manually double-click the mouse on each commit in
>> the "damaged" branch, and git-cherrypick it. Very, very time consuming
>> when you have more than a couple commits.
>>
>> Is there a better way?
>> Is there any way to say "cherrypick all commits except <these>"?
>
> Let me refactor your question more usefully. What we want is quilt-export
> and quilt-import. And I really mean that: commands called git-quilt-export
> and git-quilt-import.
>
> coz then, your problem becomes
>
> git-quilt-export
> <delete one line from the series file>
> git-quilt-import
Doesn't work when I've pulled git trees from Linville...
Jeff
^ permalink raw reply
* Re: kernel cherry UN-picking?
From: Junio C Hamano @ 2007-05-11 21:56 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Git Mailing List, Linus Torvalds, Andrew Morton
In-Reply-To: <4644E0A2.90008@garzik.org>
Jeff Garzik <jeff@garzik.org> writes:
> So, I merge the next batch of net driver patches. After I merge a PPP
> patch, deep in the pile-o-patches, Andrew says "I shouldn't have sent
> that to you, don't apply it" ;-)
>
> Right now, my process for reversing this damage is to start over:
> create a new branch, manually double-click the mouse on each commit in
> the "damaged" branch, and git-cherrypick it. Very, very time
> consuming when you have more than a couple commits.
Do the commits on the branch being rebuilt form a single strand
of pearls without any merges? If that is the case, what I would
do is:
git heckout thatbranch
git format-patch -o ./+outdir linus
rm ./+outdir/0XXX-that-unwanted-patch.patch
git reset --hard linus
git am ./+outdir/????-*.patch
^ permalink raw reply
* Re: kernel cherry UN-picking?
From: Andrew Morton @ 2007-05-11 21:55 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Git Mailing List, Linus Torvalds
In-Reply-To: <4644E0A2.90008@garzik.org>
On Fri, 11 May 2007 17:31:14 -0400
Jeff Garzik <jeff@garzik.org> wrote:
> So, I merge the next batch of net driver patches. After I merge a PPP
> patch, deep in the pile-o-patches, Andrew says "I shouldn't have sent
> that to you, don't apply it" ;-)
I'm bad.
> Right now, my process for reversing this damage is to start over:
> create a new branch, manually double-click the mouse on each commit in
> the "damaged" branch, and git-cherrypick it. Very, very time consuming
> when you have more than a couple commits.
>
> Is there a better way?
> Is there any way to say "cherrypick all commits except <these>"?
Let me refactor your question more usefully. What we want is quilt-export
and quilt-import. And I really mean that: commands called git-quilt-export
and git-quilt-import.
coz then, your problem becomes
git-quilt-export
<delete one line from the series file>
git-quilt-import
Because git-quilt-export and git-quilt-import would be useful for lots of
other things.
^ permalink raw reply
* kernel cherry UN-picking?
From: Jeff Garzik @ 2007-05-11 21:31 UTC (permalink / raw)
To: Git Mailing List; +Cc: Linus Torvalds, Andrew Morton
So, I merge the next batch of net driver patches. After I merge a PPP
patch, deep in the pile-o-patches, Andrew says "I shouldn't have sent
that to you, don't apply it" ;-)
Right now, my process for reversing this damage is to start over:
create a new branch, manually double-click the mouse on each commit in
the "damaged" branch, and git-cherrypick it. Very, very time consuming
when you have more than a couple commits.
Is there a better way?
Is there any way to say "cherrypick all commits except <these>"?
Jeff
^ permalink raw reply
* Re: [PATCH] Allow fetching references from any namespace
From: Junio C Hamano @ 2007-05-11 20:54 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20070511203522.GA2741@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> not only from the three defined: heads, tags and remotes.
>
> Noticed when I tried to fetch the references created by git-p4-import.bat:
> they are placed into separate namespace (refs/p4import/, to avoid showing
> them in git-branch output). As canon_refs_list_for_fetch always prepended
> refs/heads/ it was impossible, and annoying: it worked before. Normally,
> the p4import references are useless anywhere but in the directory managed
> by perforce, but in this special case the cloned directory was supposed
> to be a backup, including the p4import branch: it keeps information about
> where the imported perforce state came from.
Have no objection to the patch itself, but mind pointing out
where we broke it (I suspect it is around 1.5.0)?
^ permalink raw reply
* Re: StGit: Notice: no parent remote declared for stack
From: Yann Dirson @ 2007-05-11 20:47 UTC (permalink / raw)
To: Rajkumar S; +Cc: git
In-Reply-To: <64de5c8b0704192220j6f5f9493md91a33f537ebb25@mail.gmail.com>
Sorry for the late answer - this mail has been stagnating in my
"postponed folder".
On Fri, Apr 20, 2007 at 10:50:49AM +0530, Rajkumar S wrote:
> I am following another git repository with StGit. In the remote
> repository I am following RELENG_1_2 branch.
>
> I created the StGit repository using stg clone and then changed to
> RELENG_1_2 branch and did a stg init and edited the
> git/remotes/origin to
>
> URL: /usr/local/upstream/.git
> Pull: refs/heads/RELENG_1_2:refs/heads/RELENG_1_2
You are not using git 1.5, are you ? 1.5 uses the new separate-remote
layout, which should setup something similar for you.
>
> When I do an stg pull I get the following error:
>
> Notice: no parent remote declared for stack "RELENG_1_2", defaulting
> to "origin". Consider setting "branch.RELENG_1_2.remote" and
> "branch.RELENG_1_2.merge" with "git repo-config".
>
> What should I set branch.RELENG_1_2.remote and branch.RELENG_1_2.merge
> to ?
It will tell git-pull from which remote repository and branch to pull.
In your case, the default remote "origin", is correct, but stgit (and
git) cannot guess the branch to merge from.
> a sample command would be very helpful as I am not very much upto
> speed with git repo-config
If you have cloned this repo to work on it, I suppose what you want is
a patch stack that branches off the remote RELENG_1_2 branch.
git-clone will have already mirrored it locally to
remotes/origin/RELENG_1_2, so you don't need to edit the remote
definition to add it under refs/heads.
Here is an example, the conf for my main stgit branch, forked off
Catalin's master branch. Note that "branch.master.merge" refers to
the head in the remote repository, not to where it is stored locally.
Also note that branch.master.stgit.pull-policy is only honored by the
development version of stgit (ie. not 1.12.x).
[remote "origin"]
url = http://homepage.ntlworld.com/cmarinas/stgit.git
fetch = refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
[branch "master.stgit"]
pull-policy = fetch-rebase
Best regards,
--
Yann.
^ 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