* Re: [PATCH] diff: add ruby funcname pattern
From: Jeff King @ 2008-08-01 14:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Giuseppe Bilotta, git
In-Reply-To: <7v4p65tadh.fsf@gitster.siamese.dyndns.org>
On Fri, Aug 01, 2008 at 01:20:10AM -0700, Junio C Hamano wrote:
> Thanks again for the patch. Somewhere I heard that there are 10 Rubyista
> git users for every non Rubyista git user, so I am sure somebody would
> comment on your patch in a day or two. Perhaps we might even get Python
> and Perl hunk patterns (although I suspect Perl people are happy with the
> default one we stole from GNU diff) to go with it ;-).
I keep a lot of Perl in git, and yes, I am quite happy with the default
regex.
-Peff
^ permalink raw reply
* Re: git help broken
From: Miklos Vajna @ 2008-08-01 14:41 UTC (permalink / raw)
To: Christian Couder; +Cc: Johannes Schindelin, Kevin Ballard, Git Mailing List
In-Reply-To: <200808010628.52875.chriscool@tuxfamily.org>
[-- Attachment #1: Type: text/plain, Size: 392 bytes --]
On Fri, Aug 01, 2008 at 06:28:52AM +0200, Christian Couder <chriscool@tuxfamily.org> wrote:
> I didn't realize that the function "is_git_command" would not work
> for "help".
Is there any reason why help is not a builtin? I think that would solve
the problem.
I'm willing to do such a patch, I just asked in case that would be
no-go for some - for me - unknown reason.
Thanks.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git rev-parse --verify HEAD: fatal: Needed a single revision
From: Miklos Vajna @ 2008-08-01 14:35 UTC (permalink / raw)
To: Arkadiusz Miskiewicz; +Cc: git
In-Reply-To: <g6ul10$rr9$1@ger.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 840 bytes --]
On Fri, Aug 01, 2008 at 11:29:04AM +0200, Arkadiusz Miskiewicz <arekm@pld-linux.org> wrote:
> How to reproduce:
> get http://carme.pld-linux.org/~arekm/rpm5.tar.bz2
> unpack
> cd rpm5
> git cvsimport -v -d :pserver:anonymous@rpm5.org:/cvs rpm
I did:
git cvsimport -v -d :pserver:anonymous@rpm5.org:/cvs -o master -C rpm rpm
first time it bailed out with an error, sadly I don't exactly remember,
but it was different to your error. Then I ran it again (of course
without rm -rf rpm) and it finished properly. The cvs checkout and git
HEAD differs only in one file (python/Makefile.in is removed in cvs, but
not in git).
I put it out to http://vmiklos.hu/gitweb/?p=rpm.git, if you are
interested.
> I'm using:
> $ git --version
> git version 1.5.6.4
$ git --version
git version 1.6.0.rc0.14.g95f8.dirty
Not sure if it matters or not.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] clone: Add an option to set up a mirror
From: Miklos Vajna @ 2008-08-01 14:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <alpine.DEB.1.00.0808011600170.9611@pacific.mpi-cbg.de.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 452 bytes --]
On Fri, Aug 01, 2008 at 04:00:45PM +0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> The command line
>
> $ git clone --mirror $URL
>
> is now a short-hand for
>
> $ git clone --bare $URL
> $ (cd $(basename $URL) && git remote add --mirror origin $URL)
Funny, someone asked exactly this on #git yesterday (IIRC), but we ended
up using clone & remote, since I didn't find clone --mirror in the man.
;-)
Thanks!
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] clone --bare: Add ".git" suffix to the directory name to clone into
From: Marcus Griep @ 2008-08-01 14:01 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0808011601200.9611@pacific.mpi-cbg.de.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 2213 bytes --]
Does this patch forgo adding a ".git" suffix if one is already present?
Marcus
Johannes Schindelin wrote:
> We have a tradition that bare repositories live in directories ending
> in ".git". To make this more a convention than just a tradition, teach
> "git clone --bare" to add a ".git" suffix to the directory name.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>
> This patch is only conceptionally dependent on patch 1/2.
>
> builtin-clone.c | 10 ++++++++--
> t/t5601-clone.sh | 7 +++++++
> 2 files changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/builtin-clone.c b/builtin-clone.c
> index a45179c..82f5b67 100644
> --- a/builtin-clone.c
> +++ b/builtin-clone.c
> @@ -95,7 +95,7 @@ static char *get_repo_path(const char *repo, int *is_bundle)
> return NULL;
> }
>
> -static char *guess_dir_name(const char *repo, int is_bundle)
> +static char *guess_dir_name(const char *repo, int is_bundle, int is_bare)
> {
> const char *end = repo + strlen(repo), *start;
>
> @@ -131,6 +131,12 @@ static char *guess_dir_name(const char *repo, int is_bundle)
> end -= 4;
> }
>
> + if (is_bare) {
> + char *result = xmalloc(end - start + 5);
> + sprintf(result, "%.*s.git", (int)(end - start), start);
> + return result;
> + }
> +
> return xstrndup(start, end - start);
> }
>
> @@ -388,7 +394,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
> if (argc == 2)
> dir = xstrdup(argv[1]);
> else
> - dir = guess_dir_name(repo_name, is_bundle);
> + dir = guess_dir_name(repo_name, is_bundle, option_bare);
>
> if (!stat(dir, &buf))
> die("destination directory '%s' already exists.", dir);
> diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh
> index 4b2533f..e0a68ab 100755
> --- a/t/t5601-clone.sh
> +++ b/t/t5601-clone.sh
> @@ -80,4 +80,11 @@ test_expect_success 'clone --mirror' '
>
> '
>
> +test_expect_success 'clone --bare names the local repository <name>.git' '
> +
> + git clone --bare src &&
> + test -d src.git
> +
> +'
> +
> test_done
--
Marcus Griep
GPG Key ID: 0x5E968152
——
http://www.boohaunt.net
את.ψο´
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* [PATCH 2/2] clone --bare: Add ".git" suffix to the directory name to clone into
From: Johannes Schindelin @ 2008-08-01 14:01 UTC (permalink / raw)
To: git, gitster
In-Reply-To: <alpine.DEB.1.00.0808011600170.9611@pacific.mpi-cbg.de.mpi-cbg.de>
We have a tradition that bare repositories live in directories ending
in ".git". To make this more a convention than just a tradition, teach
"git clone --bare" to add a ".git" suffix to the directory name.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
This patch is only conceptionally dependent on patch 1/2.
builtin-clone.c | 10 ++++++++--
t/t5601-clone.sh | 7 +++++++
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/builtin-clone.c b/builtin-clone.c
index a45179c..82f5b67 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -95,7 +95,7 @@ static char *get_repo_path(const char *repo, int *is_bundle)
return NULL;
}
-static char *guess_dir_name(const char *repo, int is_bundle)
+static char *guess_dir_name(const char *repo, int is_bundle, int is_bare)
{
const char *end = repo + strlen(repo), *start;
@@ -131,6 +131,12 @@ static char *guess_dir_name(const char *repo, int is_bundle)
end -= 4;
}
+ if (is_bare) {
+ char *result = xmalloc(end - start + 5);
+ sprintf(result, "%.*s.git", (int)(end - start), start);
+ return result;
+ }
+
return xstrndup(start, end - start);
}
@@ -388,7 +394,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
if (argc == 2)
dir = xstrdup(argv[1]);
else
- dir = guess_dir_name(repo_name, is_bundle);
+ dir = guess_dir_name(repo_name, is_bundle, option_bare);
if (!stat(dir, &buf))
die("destination directory '%s' already exists.", dir);
diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh
index 4b2533f..e0a68ab 100755
--- a/t/t5601-clone.sh
+++ b/t/t5601-clone.sh
@@ -80,4 +80,11 @@ test_expect_success 'clone --mirror' '
'
+test_expect_success 'clone --bare names the local repository <name>.git' '
+
+ git clone --bare src &&
+ test -d src.git
+
+'
+
test_done
--
1.6.0.rc1.46.g279e5
^ permalink raw reply related
* [PATCH 1/2] clone: Add an option to set up a mirror
From: Johannes Schindelin @ 2008-08-01 14:00 UTC (permalink / raw)
To: git, gitster
The command line
$ git clone --mirror $URL
is now a short-hand for
$ git clone --bare $URL
$ (cd $(basename $URL) && git remote add --mirror origin $URL)
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Documentation/git-clone.txt | 5 ++++-
builtin-clone.c | 9 ++++++++-
t/t5601-clone.sh | 10 ++++++++++
3 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 26fd1b1..0e14e73 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -10,7 +10,7 @@ SYNOPSIS
--------
[verse]
'git clone' [--template=<template_directory>]
- [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare]
+ [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror]
[-o <name>] [-u <upload-pack>] [--reference <repository>]
[--depth <depth>] [--] <repository> [<directory>]
@@ -106,6 +106,9 @@ then the cloned repository will become corrupt.
used, neither remote-tracking branches nor the related
configuration variables are created.
+--mirror::
+ Set up a mirror of the remote repository. This implies --bare.
+
--origin <name>::
-o <name>::
Instead of using the remote name 'origin' to keep track
diff --git a/builtin-clone.c b/builtin-clone.c
index e086a40..a45179c 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -33,7 +33,7 @@ static const char * const builtin_clone_usage[] = {
NULL
};
-static int option_quiet, option_no_checkout, option_bare;
+static int option_quiet, option_no_checkout, option_bare, option_mirror;
static int option_local, option_no_hardlinks, option_shared;
static char *option_template, *option_reference, *option_depth;
static char *option_origin = NULL;
@@ -45,6 +45,8 @@ static struct option builtin_clone_options[] = {
"don't create a checkout"),
OPT_BOOLEAN(0, "bare", &option_bare, "create a bare repository"),
OPT_BOOLEAN(0, "naked", &option_bare, "create a bare repository"),
+ OPT_BOOLEAN(0, "mirror", &option_mirror,
+ "create a mirror repository (implies bare)"),
OPT_BOOLEAN('l', "local", &option_local,
"to clone from a local repository"),
OPT_BOOLEAN(0, "no-hardlinks", &option_no_hardlinks,
@@ -359,6 +361,9 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
if (option_no_hardlinks)
use_local_hardlinks = 0;
+ if (option_mirror)
+ option_bare = 1;
+
if (option_bare) {
if (option_origin)
die("--bare and --origin %s options are incompatible.",
@@ -446,7 +451,9 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
} else {
snprintf(branch_top, sizeof(branch_top),
"refs/remotes/%s/", option_origin);
+ }
+ if (option_mirror || !option_bare) {
/* Configure the remote */
snprintf(key, sizeof(key), "remote.%s.url", option_origin);
git_config_set(key, repo);
diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh
index d785b3d..4b2533f 100755
--- a/t/t5601-clone.sh
+++ b/t/t5601-clone.sh
@@ -70,4 +70,14 @@ test_expect_success 'clone creates intermediate directories for bare repo' '
'
+test_expect_success 'clone --mirror' '
+
+ git clone --mirror src mirror &&
+ test -f mirror/HEAD &&
+ test ! -f mirror/file &&
+ FETCH="$(cd mirror && git config remote.origin.fetch)" &&
+ test "+refs/heads/*:refs/heads/*" = "$FETCH"
+
+'
+
test_done
--
1.6.0.rc1.46.g279e5
^ permalink raw reply related
* Re: [PATCH] git-svn now work with crlf convertion enabled.
From: Dmitry Potapov @ 2008-08-01 12:36 UTC (permalink / raw)
To: Alexander Litvinov; +Cc: Junio C Hamano, git, Eric Wong
In-Reply-To: <200808011811.06984.litvinov2004@gmail.com>
On Fri, Aug 1, 2008 at 3:11 PM, Alexander Litvinov
<litvinov2004@gmail.com> wrote:
>> To being able to synchronize efficiently in both ways, you need to store
>> files exactly as they were received from SVN then there will be no
>> problem with applying binary delta patch. All CRLF conversion should be
>> done on checkout and checkin from/to Git repository.
>
> Sorry I have lost the mind flow here.
>
> 1. We 'fetch' files from svn as is. Yes, we know that svn use delta to rebuild
> original file.
> 2. We commit file to git. Right here we use git-hash-object. As I understand
> we _have_ to do convertion CRLF->LF here.
No, you should do any conversion here. There are two reasons for that:
1. If you do then you will not be able to apply binary patches later.
2. You do not really need it if the SVN repository has correct eol settings,
because all files that have svn:eol-style set to either 'native' or 'LF'
will have LF. Those that do not have svn:eol-style or have it to another
value should not be subject to CRLF conversion at all.
So, I believe all files received from SVN should be stored as is. Import is
not about creating new commits, it is about getting history from another
repository as it is.
> 3. In some days we will checkout file from git and wil do LF->CRLF convertion.
It is done only for files that do not have CRLF already.
>
> I thought this is a right workflow.
> - We could store original file too at step 2 somwhow to be able to use delta
> at step 1.
> - We can't skip convertion at step 2. Overwise git will store files with CRLF.
It is okay for Git to store CRLF, because you want to treat them as
binary files. If you want them being treated as text, you should change
svn:eol-style to 'native' for those files in SVN and then new versions
of these files will have the right ending. It is how SVN client works.
The only problem is how to synchronize the SVN view which files are binary
and which are text and what Git thinks about them.
Dmitry
^ permalink raw reply
* Re: Filtering mode changes
From: Santi Béjar @ 2008-08-01 12:32 UTC (permalink / raw)
To: Stefan Naewe; +Cc: git
In-Reply-To: <loom.20080801T111754-982@post.gmane.org>
On Fri, Aug 1, 2008 at 13:25, Stefan Naewe <stefan.naewe+git@gmail.com> wrote:
> Hi there.
>
> Here's my story:
>
> - I did some minor modifications to a repo that I want to 'give back'.
> - I worked on my own branch (of course).
> - I was stupid to edit the files (that live on a linux box) through a windows
> network share.
Then, you should set core.fileMode to false.
> - When I created diffs (using 'git format-patch') to send send 'upstream', I
> noticed that the edited files got their executable bit set (old mode 100644 ->
> new mode 100755)
You can just edit the patches and remove the "old/new mode" lines.
> - I created another commit to undo the mode changes.
You can use "git rebase -i" and edit (or squash) the revision before
generating the patch.
Santi
^ permalink raw reply
* [PATCH] gitweb: action in path with use_pathinfo
From: Giuseppe Bilotta @ 2008-08-01 12:23 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Giuseppe Bilotta
When using path info, reduce the number of CGI parameters by embedding
the action in the path. The typicial cgiweb path is thus
$project/$action/$hash_base:$file_name or $project/$action/$hash
This is mostly backwards compatible with the old-style gitweb paths,
except when $project/$branch was used to access a branch whose name
matches a gitweb action.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
I've been thinking a long time about the best way to get rid of most
CGI parameters when using path info, and I think that the attached
patch solves the problem pretty well, since it makes most simple
(one-paramater) actions accessible as plain paths.
The only weak point I see in my approach is with -replay=>1. Since in
our case there are no CGI parameters to be replayed, I use the
corresponding variables. An alternative, safer method would probably
be to store the various request parameters in a separate hash,
obtained by merging the CGI data with the one extracted from the
request path. I didn't follow the latter route because the simpler
approach implemented in this patch seems to work without problems.
gitweb/gitweb.perl | 111 ++++++++++++++++++++++++++++++++++------------------
1 files changed, 73 insertions(+), 38 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index aa8c27c..d4ed401 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -512,6 +512,37 @@ if (defined $searchtext) {
$search_regexp = $search_use_regexp ? $searchtext : quotemeta $searchtext;
}
+# dispatch
+my %actions = (
+ "blame" => \&git_blame,
+ "blobdiff" => \&git_blobdiff,
+ "blobdiff_plain" => \&git_blobdiff_plain,
+ "blob" => \&git_blob,
+ "blob_plain" => \&git_blob_plain,
+ "commitdiff" => \&git_commitdiff,
+ "commitdiff_plain" => \&git_commitdiff_plain,
+ "commit" => \&git_commit,
+ "forks" => \&git_forks,
+ "heads" => \&git_heads,
+ "history" => \&git_history,
+ "log" => \&git_log,
+ "rss" => \&git_rss,
+ "atom" => \&git_atom,
+ "search" => \&git_search,
+ "search_help" => \&git_search_help,
+ "shortlog" => \&git_shortlog,
+ "summary" => \&git_summary,
+ "tag" => \&git_tag,
+ "tags" => \&git_tags,
+ "tree" => \&git_tree,
+ "snapshot" => \&git_snapshot,
+ "object" => \&git_object,
+ # those below don't need $project
+ "opml" => \&git_opml,
+ "project_list" => \&git_project_list,
+ "project_index" => \&git_project_index,
+);
+
# now read PATH_INFO and use it as alternative to parameters
sub evaluate_path_info {
return if defined $project;
@@ -536,6 +568,16 @@ sub evaluate_path_info {
# do not change any parameters if an action is given using the query string
return if $action;
$path_info =~ s,^\Q$project\E/*,,;
+
+ # next comes the action
+ $action = $path_info;
+ $action =~ s,/.*$,,;
+ if (exists $actions{$action}) {
+ $path_info =~ s,^\Q$action\E/*,,;
+ } else {
+ $action = undef;
+ }
+
my ($refname, $pathname) = split(/:/, $path_info, 2);
if (defined $pathname) {
# we got "project.git/branch:filename" or "project.git/branch:dir/"
@@ -549,10 +591,12 @@ sub evaluate_path_info {
}
$hash_base ||= validate_refname($refname);
$file_name ||= validate_pathname($pathname);
+ $hash ||= git_get_hash_by_path($hash_base, $file_name);
} elsif (defined $refname) {
# we got "project.git/branch"
- $action ||= "shortlog";
- $hash ||= validate_refname($refname);
+ $action ||= "shortlog";
+ $hash ||= validate_refname($refname);
+ $hash_base ||= validate_refname($refname);
}
}
evaluate_path_info();
@@ -561,37 +605,6 @@ evaluate_path_info();
our $git_dir;
$git_dir = "$projectroot/$project" if $project;
-# dispatch
-my %actions = (
- "blame" => \&git_blame,
- "blobdiff" => \&git_blobdiff,
- "blobdiff_plain" => \&git_blobdiff_plain,
- "blob" => \&git_blob,
- "blob_plain" => \&git_blob_plain,
- "commitdiff" => \&git_commitdiff,
- "commitdiff_plain" => \&git_commitdiff_plain,
- "commit" => \&git_commit,
- "forks" => \&git_forks,
- "heads" => \&git_heads,
- "history" => \&git_history,
- "log" => \&git_log,
- "rss" => \&git_rss,
- "atom" => \&git_atom,
- "search" => \&git_search,
- "search_help" => \&git_search_help,
- "shortlog" => \&git_shortlog,
- "summary" => \&git_summary,
- "tag" => \&git_tag,
- "tags" => \&git_tags,
- "tree" => \&git_tree,
- "snapshot" => \&git_snapshot,
- "object" => \&git_object,
- # those below don't need $project
- "opml" => \&git_opml,
- "project_list" => \&git_project_list,
- "project_index" => \&git_project_index,
-);
-
if (!defined $action) {
if (defined $hash) {
$action = git_get_type($hash);
@@ -649,8 +661,13 @@ sub href (%) {
if ($params{-replay}) {
while (my ($name, $symbol) = each %mapping) {
if (!exists $params{$name}) {
- # to allow for multivalued params we use arrayref form
- $params{$name} = [ $cgi->param($symbol) ];
+ if ($cgi->param($symbol)) {
+ # to allow for multivalued params we use arrayref form
+ $params{$name} = [ $cgi->param($symbol) ];
+ } else {
+ no strict 'refs';
+ $params{$name} = $$name if $$name;
+ }
}
}
}
@@ -661,10 +678,28 @@ sub href (%) {
$href .= "/".esc_url($params{'project'}) if defined $params{'project'};
delete $params{'project'};
- # Summary just uses the project path URL
- if (defined $params{'action'} && $params{'action'} eq 'summary') {
+ # Summary just uses the project path URL, any other action come next
+ # in the URL
+ if (defined $params{'action'}) {
+ $href .= "/".esc_url($params{'action'}) unless $params{'action'} eq 'summary';
delete $params{'action'};
}
+
+ # next, we put either hash_base:file_name or hash
+ if (defined $params{'hash_base'}) {
+ $href .= "/".esc_url($params{'hash_base'});
+ if (defined $params{'file_name'}) {
+ $href .= ":".esc_url($params{'file_name'});
+ delete $params{'hash'} if $params{'hash'} eq git_get_hash_by_path($params{'hash_base'},$params{'file_name'});
+ delete $params{'file_name'};
+ } else {
+ delete $params{'hash'} if $params{'hash'} eq $params{'hash_base'};
+ }
+ delete $params{'hash_base'};
+ } elsif (defined $params{'hash'}) {
+ $href .= "/".esc_url($params{'hash'});
+ delete $params{'hash'};
+ }
}
# now encode the parameters explicitly
--
1.5.6.3
^ permalink raw reply related
* Re: Filtering mode changes
From: Matt Pearson @ 2008-08-01 12:23 UTC (permalink / raw)
To: Stefan Naewe; +Cc: git
In-Reply-To: <loom.20080801T111754-982@post.gmane.org>
On Fri, Aug 1, 2008 at 7:25 AM, Stefan Naewe <stefan.naewe+git@gmail.com> wrote:
> Hi there.
>
> Here's my story:
>
> - I did some minor modifications to a repo that I want to 'give back'.
> - I worked on my own branch (of course).
> - I was stupid to edit the files (that live on a linux box) through a windows
> network share.
> - When I created diffs (using 'git format-patch') to send send 'upstream', I
> noticed that the edited files got their executable bit set (old mode 100644 ->
> new mode 100755)
> - I created another commit to undo the mode changes.
>
> My question:
>
> Is there a way to create clean diffs (between master and my branch) that don't
> contain the 'double mode change' (from 644 to 755 to 644) ?
>
You probably want to use 'git rebase -i master' and the 'squash'
command to combine the changes into one. If multiple commits messed up
the permissions, use the 'edit' command and the rebase will stop after
the specified commits, allowing you to fix things up, then do 'git
commit --amend'. Use 'git rebase --continue' to continue fixing the
patches.
^ permalink raw reply
* Is there any hope (format-patch)??
From: Matti Kaasinen @ 2008-08-01 12:05 UTC (permalink / raw)
To: git
Hi!
Is there any hope with following procedure:
I took reporitory from linux git:
# git clone
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
For getting patches to make recent version from v2.6.26-rc3 I executed:
# git format-patch -o patchdir v2.6.26-rc3..origin
This produced 9486 patches, two of which were empty. They both appeared
to have two references in git.kernel.org archive so that newer ones were
empy.
Then I checked out v2.6.26-rc3 to a new branch and patched it with
at91patch/maxim.org.za that was produced against v2.6.26-rc3. That
worked out without complaints.
Then I ran:
#git quiltimport --patches patchdir
I suppose, it was the fourth patch of 9486 that failed. Fail did not
come from any of those parts patched with at91 patch. Is this anything
that should work? at91 patch fails if I try it right-away over the HEAD
branch.
cheers,
Matti Kaasinen
^ permalink raw reply
* Re: Merging submodules
From: Santi Béjar @ 2008-08-01 11:34 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: Petr Baudis, Brian Gernhardt, Git List, Lars Noschinski
In-Reply-To: <20080801123523.33c37e08@pc09.procura.nl>
On Fri, Aug 1, 2008 at 12:35, H.Merijn Brand <h.m.brand@xs4all.nl> wrote:
>
> After we join/merge these into the super-project, we're going to remove
> the sup-repos, so all new commits will be made in the super-repo.
If you'll remove the subrepos, the best thing would be to rewrite the
history on those subrepos just moving all the path to the
corresponding subfolder (with git-filter-branch, and you have exactly
what you need at the end of the example section in the manpage). And
then just do a normal merge. Or, even, you could try to create a
project with everything there in the correct order and location, I
don't know if git-filter-branch or git-fast-import/export (you have
some examples in git.git in contrib/fast-import) can do it, but if you
get it, please, post it here because it can be useful for others).
Santi
^ permalink raw reply
* Re: [PATCH] git-svn now work with crlf convertion enabled.
From: Alexander Litvinov @ 2008-08-01 11:27 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Junio C Hamano, git, Eric Wong
In-Reply-To: <37fcd2780808010044m424f8d8en67a4e50363238e4d@mail.gmail.com>
> git-svn uses git hash-object --stdin-paths, which means that it reads
> filenames from the standard input, so one optional parameter cannot
> help here.
We could add some parameter ti git-hash-object to tell that we will pass two
lines per each file: real file name and proposed file name in workdir.
In this case git-hash-object will be able to do proper convertion.
The main proble is the tracking original file from svn. Propably we could use
some special dir in worktree to store original file. Or we could make special
branch to track that files and second one to store converted files.
^ permalink raw reply
* Filtering mode changes
From: Stefan Naewe @ 2008-08-01 11:25 UTC (permalink / raw)
To: git
Hi there.
Here's my story:
- I did some minor modifications to a repo that I want to 'give back'.
- I worked on my own branch (of course).
- I was stupid to edit the files (that live on a linux box) through a windows
network share.
- When I created diffs (using 'git format-patch') to send send 'upstream', I
noticed that the edited files got their executable bit set (old mode 100644 ->
new mode 100755)
- I created another commit to undo the mode changes.
My question:
Is there a way to create clean diffs (between master and my branch) that don't
contain the 'double mode change' (from 644 to 755 to 644) ?
TIA
Stefan
^ permalink raw reply
* [PATCH] builtin-name-rev: refactor stdin handling to its own function
From: Pieter de Bie @ 2008-08-01 11:16 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin, Shawn O. Pearce,
Git Mailinglist
Cc: Pieter de Bie
In-Reply-To: <alpine.DEB.1.00.0808011256330.9611@pacific.mpi-cbg.de.mpi-cbg.de>
Signed-off-by: Pieter de Bie <pdebie@ai.rug.nl>
---
On 1 aug 2008, at 09:23, Junio C Hamano wrote:
>Is it just me to find that this part is getting indented too deeply to be
>readable?
How about something like this then?
builtin-name-rev.c | 93 ++++++++++++++++++++++++++++------------------------
1 files changed, 50 insertions(+), 43 deletions(-)
diff --git a/builtin-name-rev.c b/builtin-name-rev.c
index 0536af4..057172d 100644
--- a/builtin-name-rev.c
+++ b/builtin-name-rev.c
@@ -176,6 +176,52 @@ static char const * const name_rev_usage[] = {
NULL
};
+static void handle_stdin_line(char *p_start, int name_only)
+{
+ int forty = 0;
+ char *p;
+ for (p = p_start; *p; p++) {
+#define ishex(x) (isdigit((x)) || ((x) >= 'a' && (x) <= 'f'))
+ if (!ishex(*p))
+ forty = 0;
+ else if (++forty == 40 && !ishex(*(p+1))) {
+ unsigned char sha1[40];
+ const char *name = NULL;
+ char c = *(p+1);
+
+ forty = 0;
+
+ *(p+1) = 0;
+ if (!get_sha1(p - 39, sha1)) {
+ struct object *o =
+ lookup_object(sha1);
+ if (o)
+ name = get_rev_name(o);
+ }
+ *(p+1) = c;
+
+ if (!name)
+ continue;
+
+ if (name_only) {
+ fwrite(p_start, p - p_start + 1 - 40,
+ 1, stdout);sssss
+ printf(name);
+ }
+ else {
+ fwrite(p_start, p - p_start + 1, 1, stdout);
+ printf(" (%s)", name);
+ }
+ p_start = p + 1;
+ }
+ }
+
+ /* flush */
+ if (p != p_start)
+ fwrite(p_start, p - p_start, 1, stdout);
+
+}
+
int cmd_name_rev(int argc, const char **argv, const char *prefix)
{
struct object_array revs = { 0, 0, NULL };
@@ -234,53 +280,14 @@ int cmd_name_rev(int argc, const char **argv, const char *prefix)
if (transform_stdin) {
char buffer[2048];
- char *p, *p_start;
+ char *p_start;
while (!feof(stdin)) {
- int forty = 0;
- p = fgets(buffer, sizeof(buffer), stdin);
- if (!p)
+ p_start = fgets(buffer, sizeof(buffer), stdin);
+ if (!p_start)
break;
- for (p_start = p; *p; p++) {
-#define ishex(x) (isdigit((x)) || ((x) >= 'a' && (x) <= 'f'))
- if (!ishex(*p))
- forty = 0;
- else if (++forty == 40 &&
- !ishex(*(p+1))) {
- unsigned char sha1[40];
- const char *name = NULL;
- char c = *(p+1);
-
- forty = 0;
-
- *(p+1) = 0;
- if (!get_sha1(p - 39, sha1)) {
- struct object *o =
- lookup_object(sha1);
- if (o)
- name = get_rev_name(o);
- }
- *(p+1) = c;
-
- if (!name)
- continue;
-
- if (data.name_only) {
- fwrite(p_start, p - p_start + 1 - 40, 1, stdout);
- printf(name);
- }
- else {
- fwrite(p_start, p - p_start + 1, 1, stdout);
- printf(" (%s)", name);
- }
- p_start = p + 1;
- }
- }
-
- /* flush */
- if (p_start != p)
- fwrite(p_start, p - p_start, 1, stdout);
+ handle_stdin_line(p_start, data.name_only);
}
} else if (all) {
int i, max;
--
1.6.0.rc1.214.g5f0bd
^ permalink raw reply related
* Re: [PATCH] git-svn now work with crlf convertion enabled.
From: Alexander Litvinov @ 2008-08-01 11:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Dmitry Potapov, git, Eric Wong
In-Reply-To: <7vbq0dtawp.fsf@gitster.siamese.dyndns.org>
> To being able to synchronize efficiently in both ways, you need to store
> files exactly as they were received from SVN then there will be no
> problem with applying binary delta patch. All CRLF conversion should be
> done on checkout and checkin from/to Git repository.
Sorry I have lost the mind flow here.
1. We 'fetch' files from svn as is. Yes, we know that svn use delta to rebuild
original file.
2. We commit file to git. Right here we use git-hash-object. As I understand
we _have_ to do convertion CRLF->LF here.
3. In some days we will checkout file from git and wil do LF->CRLF convertion.
I thought this is a right workflow.
- We could store original file too at step 2 somwhow to be able to use delta
at step 1.
- We can't skip convertion at step 2. Overwise git will store files with CRLF.
Am I wrong ?
^ permalink raw reply
* Re: markdown 2 man, was Re: Git Community Book
From: Abdelrazak Younes @ 2008-08-01 11:06 UTC (permalink / raw)
To: Dmitry Potapov
Cc: Jan Krüger, git, Johannes Schindelin, Julian Phillips,
Scott Chacon, Petr Baudis
In-Reply-To: <37fcd2780808010345l755b83a5gff8a5aa350016ad5@mail.gmail.com>
Hi Dimitry,
Dmitry Potapov wrote:
> On Fri, Aug 1, 2008 at 11:50 AM, Abdelrazak Younes <younes@lyx.org>
> wrote:
> > AsciiDoc is indeed excellent if you want to write in a plain text
> > editor. But LyX is easier to use and more porwerful :-)
>
> What is really powerful is TeX. As to LyX, it is leaky abstraction
> over it. I have never been able to use without ending up saying, it
> is so much easier and much more powerful to use Latex than trying to
> do the same with LyX. Of course, LyX looks much better nowadays than
> used to be, so I decided to give it another try, and here is my
> fifteen minutes experience with it.
I was afraid this thread will turn into a pro and con of LyX versus
plain LateX :-)
> First, I tried to open FAQ.lyx that you attached to your previous
> email, and here is what I see:
...
> Now, I see, that your FAQ was created with LyX 1.6.0svn, which is not
> released yet. So, I hope that this issue will be correctly before it
> will be released.
Of course. Sorry, as I use the pre-release I didn't think that about
that. FYI, we will release one last version of 1.5.x that is able to
read 1.6 format. 1.6 will is of course able to read all previous format.
> Otherwise, anyone opening document with 1.6.0 will make it
> unaccessible to users of previous versions.
>
> Then I tried to use Formatted reference and everything looks okay
> until I tried to generate DVI file, where I was welcome but the
> following error: === Paragraph ended before \@prettyref was
> complete. ===
>
> What is \@prettyref? What is wrong with my paragraph? Actually, my
> paragraph is fine, it is just when you use Formatted reference, you
> should know that it is implemented using prettyref TeX package, which
> requires three letter prefix in name of each label. Why did not LyX
> warn me about that? BTW, is really prettyref is the best package for
> this job anyway? I remember some TeX experts recommended some other
> packages for references.
Aha, yes you're right. LyX will automatically insert those three letters
(eg. 'cha' for chapter). This is the reason why I never came across this
bug. We'll try to fix that, thanks!
>
> Finally, I still have not figured out how to the same what AsciiDoc
> does: Chapter #, $CHAPTER_NAME It does not look like that LyX can
> produce references in this format.
You can choose among a number of document class. If you want the
"Chapter" prefixing, choose the 'Book' document class. The default,
document class is 'Article', for with you don't have level 1 sections.
> The I tried to insert some verbatim text, and I cannot find the
> standard way to do that in LyX.
There are at least two:
- The LyX-code environment
- The listing inset
The listing inset supports a number of languages so you'll be able to
have syntax highlighting and cloring for your language of choice.
> Sure, I can press CTRL-L and type in
> TeX: \begin{verbatim} # git itself (approx. 10MB download): $ git
> clone git://git.kernel.org/pub/scm/git/git.git # the linux kernel
> (approx. 150MB download): $ git clone
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> \end{verbatim}
>
> but I don't think that having a lot TeX code is going to help us
> with having good formatted HTML version.
No, either LyX-code (To choose from the Layout combo box) or preferable
the Listing inset (Menu Insert -> Program Listing). Of course, all these
action have keyboard shortcuts.
>
> BTW, it is really annoying to see TeX code displayed in proportional
> fonts and formatted with full adjustment. For instance, the last
> line was displayed like this:
>
> $ git
> clone
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Yes I know, this will be better in 1.6 due out this month in principle.
> Another rather surprising experience for those who got used to HTML:
> Left-click on a reference produces its properties, while the right
> click means to go to the label, and once you jump on it, there is no
> way to jump back (at least, I was not able to find how to do that).
There is one 'Ctrl-0' but this is more or less hidden feature. 1.6 will
have context menu so all the above actions will be a lot more consistant
and easier.
> Well, I wrote all above only because I hope that LyX will continue
> to improve. It looks much better now than before.
Thanks for the comments :-)
> Yet, I will rather
> stay with plain text editors for now. Some of them are much more
> powerful than Notepad :)
It's a matter of choice. I have to confess that I don't use plain text
editor anymore because I am so used to LyX keybindings.
Thanks,
Abdel.
^ permalink raw reply
* Re: [PATCH] git-name-rev: allow --name-only in combination with --stdin
From: Johannes Schindelin @ 2008-08-01 10:57 UTC (permalink / raw)
To: Junio C Hamano, spearce; +Cc: Pieter de Bie, Git Mailinglist
In-Reply-To: <7vtze5td00.fsf@gitster.siamese.dyndns.org>
Hi,
On Fri, 1 Aug 2008, Junio C Hamano wrote:
> Pieter de Bie <pdebie@ai.rug.nl> writes:
>
> > Signed-off-by: Pieter de Bie <pdebie@ai.rug.nl>
> > ---
> >
> > Or was there a specific reason not to allow this?
>
> I'll let Dscho answer that one.
... who let's Shawn answer that one.
> > diff --git a/builtin-name-rev.c b/builtin-name-rev.c
> > index 85612c4..0536af4 100644
> > --- a/builtin-name-rev.c
> > +++ b/builtin-name-rev.c
> > @@ -266,8 +266,14 @@ int cmd_name_rev(int argc, const char **argv, const char *prefix)
> > if (!name)
> > continue;
> >
> > - fwrite(p_start, p - p_start + 1, 1, stdout);
> > - printf(" (%s)", name);
> > + if (data.name_only) {
> > + fwrite(p_start, p - p_start + 1 - 40, 1, stdout);
> > + printf(name);
> > + }
> > + else {
> > + fwrite(p_start, p - p_start + 1, 1, stdout);
> > + printf(" (%s)", name);
> > + }
> > p_start = p + 1;
> > }
> > }
>
> Is it just me to find that this part is getting indented too deeply to be
> readable?
No.
Ciao,
Dscho
^ permalink raw reply
* Re: markdown 2 man, was Re: Git Community Book
From: Dmitry Potapov @ 2008-08-01 10:45 UTC (permalink / raw)
To: Abdelrazak Younes
Cc: Jan Krüger, git, Johannes Schindelin, Julian Phillips,
Scott Chacon, Petr Baudis
In-Reply-To: <4892C042.20302@lyx.org>
On Fri, Aug 1, 2008 at 11:50 AM, Abdelrazak Younes <younes@lyx.org> wrote:
>
> AsciiDoc is indeed excellent if you want to write in a plain text editor.
> But LyX is easier to use and more porwerful :-)
What is really powerful is TeX. As to LyX, it is leaky abstraction over it.
I have never been able to use without ending up saying, it is so much easier
and much more powerful to use Latex than trying to do the same with LyX. Of
course, LyX looks much better nowadays than used to be, so I decided to give
it another try, and here is my fifteen minutes experience with it.
First, I tried to open FAQ.lyx that you attached to your previous email, and
here is what I see:
===
/tmp/FAW.lix is from a different version of LyX, but the lex2lex script failed
to covert it.
===
This is result was received with two LyX versions that I tried:
LyX Version 1.4.3 (21/09/2006)
LyX 1.5.5 (Sun, May 11, 2008)
Now, I see, that your FAQ was created with LyX 1.6.0svn, which is not released
yet. So, I hope that this issue will be correctly before it will be released.
Otherwise, anyone opening document with 1.6.0 will make it unaccessible to users
of previous versions.
Then I tried to use Formatted reference and everything looks okay until I tried
to generate DVI file, where I was welcome but the following error:
===
Paragraph ended before \@prettyref was complete.
===
What is \@prettyref? What is wrong with my paragraph? Actually, my paragraph is
fine, it is just when you use Formatted reference, you should know that it is
implemented using prettyref TeX package, which requires three letter prefix in
name of each label. Why did not LyX warn me about that? BTW, is really prettyref
is the best package for this job anyway? I remember some TeX experts recommended
some other packages for references.
Finally, I still have not figured out how to the same what AsciiDoc does:
Chapter #, $CHAPTER_NAME
It does not look like that LyX can produce references in this format.
The I tried to insert some verbatim text, and I cannot find the standard way
to do that in LyX. Sure, I can press CTRL-L and type in TeX:
\begin{verbatim}
# git itself (approx. 10MB download):
$ git clone git://git.kernel.org/pub/scm/git/git.git
# the linux kernel (approx. 150MB download):
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
\end{verbatim}
but I don't think that having a lot TeX code is going to help us with
having good formatted HTML version.
BTW, it is really annoying to see TeX code displayed in proportional
fonts and formatted with full adjustment. For instance, the last line
was displayed like this:
$ git clone
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Another rather surprising experience for those who got used to HTML:
Left-click on a reference produces its properties, while the right
click means to go to the label, and once you jump on it, there is
no way to jump back (at least, I was not able to find how to do that).
Well, I wrote all above only because I hope that LyX will continue to
improve. It looks much better now than before. Yet, I will rather stay
with plain text editors for now. Some of them are much more powerful
than Notepad :)
Dmitry
^ permalink raw reply
* Re: Merging submodules
From: H.Merijn Brand @ 2008-08-01 10:35 UTC (permalink / raw)
To: Santi Béjar; +Cc: Petr Baudis, Brian Gernhardt, Git List, Lars Noschinski
In-Reply-To: <8aa486160808010252j540a28cdw6e48027396da5248@mail.gmail.com>
On Fri, 1 Aug 2008 11:52:08 +0200, "Santi Béjar" <sbejar@gmail.com>
wrote:
> On Fri, Aug 1, 2008 at 09:04, H.Merijn Brand <h.m.brand@xs4all.nl> wrote:
> >
> > Almost perfect now.
> >
> > 4gl/new 121 > git-ls-files | grep fnc_declare
> > include/fnc_declare.h
> > 4gl/new 122 > git-show d971ec91a3dbc9f1f27a96e4f9b95366babd036c
> > commit d971ec91a3dbc9f1f27a96e4f9b95366babd036c
> > Author: H.M. Brand <merijn@a5.(none)>
> > Date: Tue Jul 29 16:45:43 2008 +0200
> >
> > Backward comp functie voor PV indicatie
> >
> > diff --git a/fnc_declare.h b/fnc_declare.h
> > index acd686c..25d9a73 100644
> > --- a/fnc_declare.h
> > +++ b/fnc_declare.h
> > @@ -136,6 +136,11 @@ eaf_N Indicaties ($x1);
> > :
> >
> > all the diffs are still showing as if they were against the folder they
> > were originally committed in. Is that correct? I would now have expected
> > something like
>
> It is correct for old commits, when you look at an old commit it
> doesn't know that later it is merge in a subfolder. For new commits it
> depends on how you made them, in the modules and doing a subtree merge
> or directly in the "superproject".
After we join/merge these into the super-project, we're going to remove
the sup-repos, so all new commits will be made in the super-repo.
What I'm a bit worried about is that if people are looking for a change
in "include/inih001.h", they will not be able to find the commits on
that path, as the old commits have stored it without the path element.
Will that be a problem, or is git/gitk clever enough to still find
commits to both?
--
H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
^ permalink raw reply
* Re: markdown 2 man, was Re: Git Community Book
From: Abdelrazak Younes @ 2008-08-01 10:19 UTC (permalink / raw)
To: Thomas Rast
Cc: Junio C Hamano, Stephan Beyer, git, Johannes Schindelin,
Julian Phillips, Scott Chacon, Petr Baudis
In-Reply-To: <200808011146.29883.trast@student.ethz.ch>
Thomas Rast wrote:
> You wrote:
>
>> Junio C Hamano wrote:
>>
>>> How greppable and "log -p"-able is the documentation written in LyX?
>>>
>> LyX format is plain text, loosely based on LateX. Here's attached a
>> sample .lyx file FYI. We have one tag per line and a maximum of 80 char
>> per line so that the format is easily parsable. Advanced users often use
>> unix tools (grep, sed, etc) to modify the .lyx file manually.
>>
>
> Is it just me or is the format very hard to read? For example, line
> 492ff spells a list of quoted items as
>
Right, quote is a special case in lyx format because we have to take
care of locale differences. So, as you guessed, quotes are not really
written with the ascii quote character. But the format is not that hard
in general. If needed, I could modify this special case so that it's
easier to read though.
Don't get me wrong, I don't pretend that LyX is easy to read for the
untrained eyes, it is not. But simple modifications like Junio's example
is definitely possible. For non simple text insertion, it is better to
launch LyX and to type the modification within LyX. But maybe this is a
showstopper for you, and so is maybe our treatment of quotes. In which
case I'll stop arguying :-)
Abdel.
^ permalink raw reply
* Re: StGit: kha/{stable,safe,experimental} updated
From: Karl Hasselström @ 2008-08-01 10:22 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, Samuel Tardieu
In-Reply-To: <b0943d9e0807270144n359e5bd3ye3e91c52b8fa7beb@mail.gmail.com>
On 2008-07-27 09:44:31 +0100, Catalin Marinas wrote:
> 2008/7/25 Karl Hasselström <kha@treskal.com>:
>
> > The big update since last time is support (in kha/experimental) for
> > hidden patches in the new-infrastructure commands and stack log.
>
> I'll have a look at the new stack log format (my main worry) this
> week but the other patches look OK.
Heh. It's _always_ your main worry. But rightly so, since mistakes
could be costly. Thanks for spending time on this with me.
I made one change apart from adding the hidden patches: use the same
tree for both the full and simplified logs. It's no more costly to
write, and made the parsing substantially simpler.
> I merged the safe and stable branches.
Thanks.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Git vs Monotone
From: David Kastrup @ 2008-08-01 9:57 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LFD.1.10.0807311244240.3277@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Thu, 31 Jul 2008, Craig L. Ching wrote:
>>
>> It's possible he's doing that, but it's also possible he just isn't that
>> familiar with git.
>
> Possible. But it really sounded like he didn't even try. Because quite
> frankly, if he had even bothered to _try_, he wouldn't have gotten the
> numbers he got.
>
> The fact is, even without "-s", a local clone will do hardlinks for the
> database.
That means that git takes up less disk space. It does not mean that it
looks like it.
If you do a df before and afterwards, you'll notice (but that does not
seem reliable as other changed might happen in the file system). If you
do "du" into the individual clones, you won't notice it.
It is quite plausible that he might have tried it, but misinterpreted
the results.
It is a similar situation with size estimates when sparse files are
involved: they may take up less space than what it looks like.
--
David Kastrup
^ permalink raw reply
* Re: Merging submodules
From: Santi Béjar @ 2008-08-01 9:52 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: Petr Baudis, Brian Gernhardt, Git List, Lars Noschinski
In-Reply-To: <20080801090422.55c6a45f@pc09.procura.nl>
On Fri, Aug 1, 2008 at 09:04, H.Merijn Brand <h.m.brand@xs4all.nl> wrote:
>
> Almost perfect now.
>
> 4gl/new 121 > git-ls-files | grep fnc_declare
> include/fnc_declare.h
> 4gl/new 122 > git-show d971ec91a3dbc9f1f27a96e4f9b95366babd036c
> commit d971ec91a3dbc9f1f27a96e4f9b95366babd036c
> Author: H.M. Brand <merijn@a5.(none)>
> Date: Tue Jul 29 16:45:43 2008 +0200
>
> Backward comp functie voor PV indicatie
>
> diff --git a/fnc_declare.h b/fnc_declare.h
> index acd686c..25d9a73 100644
> --- a/fnc_declare.h
> +++ b/fnc_declare.h
> @@ -136,6 +136,11 @@ eaf_N Indicaties ($x1);
> eaf_N pv_datum ($x1, $x2, $x3);
> #endif
>
> +#ifndef PV_INDICATIE
> +#define PV_INDICATIE
> +eaf_S pv_indicatie ($x1);
> +#endif
> +
> #undef eaf_B
> #undef eaf_N
> #undef eaf_S
> 4gl/new 123 >
>
> all the diffs are still showing as if they were against the folder they
> were originally committed in. Is that correct? I would now have expected
> something like
It is correct for old commits, when you look at an old commit it
doesn't know that later it is merge in a subfolder. For new commits it
depends on how you made them, in the modules and doing a subtree merge
or directly in the "superproject".
Santi
>
> commit d971ec91a3dbc9f1f27a96e4f9b95366babd036c
> Author: H.M. Brand <merijn@a5.(none)>
> Date: Tue Jul 29 16:45:43 2008 +0200
>
> Backward comp functie voor PV indicatie
>
> diff --git a/include/fnc_declare.h b/include/fnc_declare.h
> index acd686c..25d9a73 100644
> --- a/include/fnc_declare.h
> +++ b/include/fnc_declare.h
> @@ -136,6 +136,11 @@ eaf_N Indicaties ($x1);
> eaf_N pv_datum ($x1, $x2, $x3);
> #endif
>
> +#ifndef PV_INDICATIE
> +#define PV_INDICATIE
> +eaf_S pv_indicatie ($x1);
> +#endif
> +
> #undef eaf_B
> #undef eaf_N
> #undef eaf_S
>
> --
> H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/
> using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
> 11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin.
> http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
> http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
>
^ 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