* Re: [git-svn PATCH] Add --no-rebase option to git-svn dcommit
From: Eric Wong @ 2007-05-04 8:04 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Junio C Hamano, git
In-Reply-To: <20070504075908.GB17526@muzzle>
Eric Wong <normalperson@yhbt.net> wrote:
> Karl Hasselström <kha@treskal.com> wrote:
> > git-svn dcommit exports commits to Subversion, then imports them back
> > to git again, and last but not least rebases or resets HEAD to the
> > last of the new commits. I guess this rebasing is convenient when
> > using just git, but when the commits to be exported are managed by
> > StGIT, it's really annoying. So add an option to disable this
> > behavior. And document it, too!
>
> Cool, I've been planning to add this myself, too.
>
> Acked-by: Eric Wong <normalperson@yhbt.net>
>
> > Signed-off-by: Karl Hasselström <kha@treskal.com>
> > ---
> >
> > Arguably, the switch should be --rebase instead, and default to not
> > rebase. But that would change the existing behavior, and possibly make
> > dcommit less convenient to use for at least the person who implemented
> > the existing behavior. Opinions?
Erm, sorry, I skipped over this part. No. I like rebase being the
default behavior.
> > Documentation/git-svn.txt | 3 +++
> > git-svn.perl | 33 ++++++++++++++++++---------------
> > 2 files changed, 21 insertions(+), 15 deletions(-)
> >
> > diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
> > index 62d7ef8..fcdeeaa 100644
> > --- a/Documentation/git-svn.txt
> > +++ b/Documentation/git-svn.txt
> > @@ -125,6 +125,9 @@ and have no uncommitted changes.
> > alternative to HEAD.
> > This is advantageous over 'set-tree' (below) because it produces
> > cleaner, more linear history.
> > ++
> > +--no-rebase;;
> > + After committing, do not rebase or reset.
> > --
> >
> > 'log'::
> > diff --git a/git-svn.perl b/git-svn.perl
> > index 6657e10..3c4f490 100755
> > --- a/git-svn.perl
> > +++ b/git-svn.perl
> > @@ -55,7 +55,7 @@ $sha1_short = qr/[a-f\d]{4,40}/;
> > my ($_stdin, $_help, $_edit,
> > $_message, $_file,
> > $_template, $_shared,
> > - $_version, $_fetch_all,
> > + $_version, $_fetch_all, $_no_rebase,
> > $_merge, $_strategy, $_dry_run, $_local,
> > $_prefix, $_no_checkout, $_verbose);
> > $Git::SVN::_follow_parent = 1;
> > @@ -114,6 +114,7 @@ my %cmd = (
> > 'verbose|v' => \$_verbose,
> > 'dry-run|n' => \$_dry_run,
> > 'fetch-all|all' => \$_fetch_all,
> > + 'no-rebase' => \$_no_rebase,
> > %cmt_opts, %fc_opts } ],
> > 'set-tree' => [ \&cmd_set_tree,
> > "Set an SVN repository to a git tree-ish",
> > @@ -413,21 +414,23 @@ sub cmd_dcommit {
> > return;
> > }
> > $_fetch_all ? $gs->fetch_all : $gs->fetch;
> > - # we always want to rebase against the current HEAD, not any
> > - # head that was passed to us
> > - my @diff = command('diff-tree', 'HEAD', $gs->refname, '--');
> > - my @finish;
> > - if (@diff) {
> > - @finish = rebase_cmd();
> > - print STDERR "W: HEAD and ", $gs->refname, " differ, ",
> > - "using @finish:\n", "@diff";
> > - } else {
> > - print "No changes between current HEAD and ",
> > - $gs->refname, "\nResetting to the latest ",
> > - $gs->refname, "\n";
> > - @finish = qw/reset --mixed/;
> > + unless ($_no_rebase) {
> > + # we always want to rebase against the current HEAD, not any
> > + # head that was passed to us
> > + my @diff = command('diff-tree', 'HEAD', $gs->refname, '--');
> > + my @finish;
> > + if (@diff) {
> > + @finish = rebase_cmd();
> > + print STDERR "W: HEAD and ", $gs->refname, " differ, ",
> > + "using @finish:\n", "@diff";
> > + } else {
> > + print "No changes between current HEAD and ",
> > + $gs->refname, "\nResetting to the latest ",
> > + $gs->refname, "\n";
> > + @finish = qw/reset --mixed/;
> > + }
> > + command_noisy(@finish, $gs->refname);
> > }
> > - command_noisy(@finish, $gs->refname);
> > }
> >
> > sub cmd_find_rev {
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] Support ent:relative_path
From: Junio C Hamano @ 2007-05-04 8:21 UTC (permalink / raw)
To: Dana How; +Cc: Git Mailing List
In-Reply-To: <56b7f5510705040022x2e4903d3hbe4ac1ee1a2e096f@mail.gmail.com>
I do not think it is wrong per-se, to want to make this hold true:
A=$(git rev-parse :somedir/file)
B=$(cd somedir && git rev-parse :file)
test "$A" = "$B"
One thing I am reasonably certain however is that this should
NOT be conditional to a config setting. Doing so would force
scripts that take (or compute) path and commit and concatenate
them to make "${commit}:${path}" to name a blob (or tree) to
first inspect the current setting of core.relativepaths and undo
what the new code does by prefixing/subtracting the prefix
string depending on the config.
In other words, having that config is not really helping scripts
or compatibility.
I think the choices are:
(1) we say it was a mistake that we did not make it relative to
the current directory when we introduced the X:<path>
syntax (X could be empty or :[0-3]: for index, or a commit
or tree object name), and change the semantics in a future
major release for everybody, apologizing for potentially
breaking existing scripts; or
(2) keep the current behaviour as is, and come up with a
different syntax to use relative; or
(3) do nothing.
My preference is (2), (3) and then (1), but I do not have
offhand a suggestion for a good metacharacter we could use.
^ permalink raw reply
* Re: [PATCH] Support ent:relative_path
From: Alex Riesen @ 2007-05-04 8:20 UTC (permalink / raw)
To: Dana How; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <463ADE51.2030108@gmail.com>
On 5/4/07, Dana How <danahow@gmail.com> wrote:
> + if (!strcmp(var, "core.relativepaths")) {
> + assume_relative_paths = git_config_bool(var, value);
> + return 0;
> + }
Maybe we should use relative path always, unconditionally.
^ permalink raw reply
* [StGIT PATCH] Test "stg rebase" after "stg commit"
From: Karl Hasselström @ 2007-05-04 8:13 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, Yann Dirson
Two new tests for "stg rebase":
1. Try to rebase to a commit that is ahead of HEAD. This should
work, and does.
2. Try to commit a patch, and then rebase. This doesn't work,
because "stg rebase" aborts if orig-base != base, and "stg
commit" doesn't update orig-base. (It does work if "stg rebase"
is given the --force flag.)
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
(2) shows a bug in "stg rebase"'s safety logic. I'm not sure how to
fix it, because I don't know how it's supposed to work in the first
place. (An obvious fix would be to update it whenever the base
changes, but that'll take some work, and I'm not convinced it can't be
done with les work. Yes, I'm lazy.) Yann, could you explain?
t/t2200-rebase.sh | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/t/t2200-rebase.sh b/t/t2200-rebase.sh
index 52462dd..b48e513 100755
--- a/t/t2200-rebase.sh
+++ b/t/t2200-rebase.sh
@@ -30,4 +30,20 @@ test_expect_success \
test `stg id base@stack` = `git rev-parse master~1`
'
+test_expect_success \
+ 'Rebase to next commit' \
+ '
+ stg rebase master &&
+ test $(stg id base@stack) = $(git rev-parse master)
+ '
+
+test_expect_success \
+ 'Commit the patch and rebase again' \
+ '
+ stg commit &&
+ git tag committed-here &&
+ stg rebase master &&
+ test $(stg id base@stack) = $(git rev-parse master)
+ '
+
test_done
^ permalink raw reply related
* Re: [git-svn PATCH] Fix markup in git-svn man page
From: Eric Wong @ 2007-05-04 8:06 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Junio C Hamano, git
In-Reply-To: <20070504070003.9117.75385.stgit@yoghurt>
Karl Hasselström <kha@treskal.com> wrote:
> Some of the existing markup was just plain broken, and some subcommand
> options weren't indented properly.
>
> Signed-off-by: Karl Hasselström <kha@treskal.com>
> ---
>
> I poked at the markup with a stick until it rendered well (as both man
> and html), but I really don't know much about asciidoc markup, so some
> sanity-checking by a third party is probably a good idea.
I don't know much about it, either. They take way too long for me to
build, so I've mostly just guessed the syntax based on the existing
documentation and let other people fix it for me :)
--
Eric Wong
^ permalink raw reply
* Re: [git-svn PATCH] Add --no-rebase option to git-svn dcommit
From: Eric Wong @ 2007-05-04 7:59 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Junio C Hamano, git
In-Reply-To: <20070503054749.20115.53805.stgit@yoghurt>
Karl Hasselström <kha@treskal.com> wrote:
> git-svn dcommit exports commits to Subversion, then imports them back
> to git again, and last but not least rebases or resets HEAD to the
> last of the new commits. I guess this rebasing is convenient when
> using just git, but when the commits to be exported are managed by
> StGIT, it's really annoying. So add an option to disable this
> behavior. And document it, too!
Cool, I've been planning to add this myself, too.
Acked-by: Eric Wong <normalperson@yhbt.net>
> Signed-off-by: Karl Hasselström <kha@treskal.com>
> ---
>
> Arguably, the switch should be --rebase instead, and default to not
> rebase. But that would change the existing behavior, and possibly make
> dcommit less convenient to use for at least the person who implemented
> the existing behavior. Opinions?
>
> Documentation/git-svn.txt | 3 +++
> git-svn.perl | 33 ++++++++++++++++++---------------
> 2 files changed, 21 insertions(+), 15 deletions(-)
>
> diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
> index 62d7ef8..fcdeeaa 100644
> --- a/Documentation/git-svn.txt
> +++ b/Documentation/git-svn.txt
> @@ -125,6 +125,9 @@ and have no uncommitted changes.
> alternative to HEAD.
> This is advantageous over 'set-tree' (below) because it produces
> cleaner, more linear history.
> ++
> +--no-rebase;;
> + After committing, do not rebase or reset.
> --
>
> 'log'::
> diff --git a/git-svn.perl b/git-svn.perl
> index 6657e10..3c4f490 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -55,7 +55,7 @@ $sha1_short = qr/[a-f\d]{4,40}/;
> my ($_stdin, $_help, $_edit,
> $_message, $_file,
> $_template, $_shared,
> - $_version, $_fetch_all,
> + $_version, $_fetch_all, $_no_rebase,
> $_merge, $_strategy, $_dry_run, $_local,
> $_prefix, $_no_checkout, $_verbose);
> $Git::SVN::_follow_parent = 1;
> @@ -114,6 +114,7 @@ my %cmd = (
> 'verbose|v' => \$_verbose,
> 'dry-run|n' => \$_dry_run,
> 'fetch-all|all' => \$_fetch_all,
> + 'no-rebase' => \$_no_rebase,
> %cmt_opts, %fc_opts } ],
> 'set-tree' => [ \&cmd_set_tree,
> "Set an SVN repository to a git tree-ish",
> @@ -413,21 +414,23 @@ sub cmd_dcommit {
> return;
> }
> $_fetch_all ? $gs->fetch_all : $gs->fetch;
> - # we always want to rebase against the current HEAD, not any
> - # head that was passed to us
> - my @diff = command('diff-tree', 'HEAD', $gs->refname, '--');
> - my @finish;
> - if (@diff) {
> - @finish = rebase_cmd();
> - print STDERR "W: HEAD and ", $gs->refname, " differ, ",
> - "using @finish:\n", "@diff";
> - } else {
> - print "No changes between current HEAD and ",
> - $gs->refname, "\nResetting to the latest ",
> - $gs->refname, "\n";
> - @finish = qw/reset --mixed/;
> + unless ($_no_rebase) {
> + # we always want to rebase against the current HEAD, not any
> + # head that was passed to us
> + my @diff = command('diff-tree', 'HEAD', $gs->refname, '--');
> + my @finish;
> + if (@diff) {
> + @finish = rebase_cmd();
> + print STDERR "W: HEAD and ", $gs->refname, " differ, ",
> + "using @finish:\n", "@diff";
> + } else {
> + print "No changes between current HEAD and ",
> + $gs->refname, "\nResetting to the latest ",
> + $gs->refname, "\n";
> + @finish = qw/reset --mixed/;
> + }
> + command_noisy(@finish, $gs->refname);
> }
> - command_noisy(@finish, $gs->refname);
> }
>
> sub cmd_find_rev {
>
--
Eric Wong
^ permalink raw reply
* [PATCH v2] Support ent:relative_path
From: Dana How @ 2007-05-04 7:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, danahow
Most commands accept relative paths, but this is
not true of arguments in ent:path format. This
patch makes all 3 of the following git-show commands
work in the git source tree (not just the first):
% cd xdiff
% git-show v1.5.2-rc0:xdiff/xemit.h
% git-show v1.5.2-rc0:./xemit.h
% git-config --bool core.relativepaths yes
% git-show v1.5.2-rc0:xemit.h
Signed-off-by: Dana L. How <danahow@gmail.com>
---
cache.h | 2 ++
config.c | 5 +++++
environment.c | 1 +
setup.c | 5 ++++-
sha1_name.c | 29 ++++++++++++++++++++++++++---
5 files changed, 38 insertions(+), 4 deletions(-)
diff --git a/cache.h b/cache.h
index 8e76152..fc3fcb1 100644
--- a/cache.h
+++ b/cache.h
@@ -215,6 +215,7 @@ extern char *get_graft_file(void);
#define ALTERNATE_DB_ENVIRONMENT "GIT_ALTERNATE_OBJECT_DIRECTORIES"
+extern const char *prefix_to_cwd;
extern const char **get_pathspec(const char *prefix, const char **pathspec);
extern const char *setup_git_directory_gently(int *);
extern const char *setup_git_directory(void);
@@ -276,6 +277,7 @@ extern int delete_ref(const char *, const unsigned char *sha1);
extern int use_legacy_headers;
extern int trust_executable_bit;
extern int has_symlinks;
+extern int assume_relative_paths;
extern int assume_unchanged;
extern int prefer_symlink_refs;
extern int log_all_ref_updates;
diff --git a/config.c b/config.c
index 70d1055..7525965 100644
--- a/config.c
+++ b/config.c
@@ -279,6 +279,11 @@ int git_default_config(const char *var, const char *value)
return 0;
}
+ if (!strcmp(var, "core.relativepaths")) {
+ assume_relative_paths = git_config_bool(var, value);
+ return 0;
+ }
+
if (!strcmp(var, "core.ignorestat")) {
assume_unchanged = git_config_bool(var, value);
return 0;
diff --git a/environment.c b/environment.c
index 2231659..f1b867d 100644
--- a/environment.c
+++ b/environment.c
@@ -14,6 +14,7 @@ char git_default_name[MAX_GITNAME];
int use_legacy_headers = 1;
int trust_executable_bit = 1;
int has_symlinks = 1;
+int assume_relative_paths;
int assume_unchanged;
int prefer_symlink_refs;
int is_bare_repository_cfg = -1; /* unspecified */
diff --git a/setup.c b/setup.c
index a45ea83..46ae6e3 100644
--- a/setup.c
+++ b/setup.c
@@ -1,5 +1,7 @@
#include "cache.h"
+const char *prefix_to_cwd;
+
const char *prefix_path(const char *prefix, int len, const char *path)
{
const char *orig = path;
@@ -252,7 +254,8 @@ const char *setup_git_directory_gently(int *nongit_ok)
cwd[len++] = '/';
cwd[len] = 0;
inside_git_dir = !prefixcmp(cwd + offset, ".git/");
- return cwd + offset;
+ prefix_to_cwd = cwd + offset;
+ return prefix_to_cwd;
}
int git_config_perm(const char *var, const char *value)
diff --git a/sha1_name.c b/sha1_name.c
index 55f25a2..d276767 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -592,6 +592,26 @@ static int handle_one_ref(const char *path,
return 0;
}
+static void prepend_prefix(const char **cp, int *namelen)
+{
+ static char fullpath[PATH_MAX];
+ if (*namelen > 2 && !memcmp(*cp, "./", 2)) {
+ *cp += 2;
+ *namelen -= 2;
+ } else
+ if (!assume_relative_paths)
+ return;
+ if (!prefix_to_cwd)
+ return;
+
+ *namelen += strlen(prefix_to_cwd);
+ if (*namelen >= PATH_MAX)
+ die("path too long");
+ strcpy(fullpath, prefix_to_cwd);
+ strcat(fullpath, *cp);
+ *cp = fullpath;
+}
+
/*
* This interprets names like ':/Initial revision of "git"' by searching
* through history and returning the first commit whose message starts
@@ -681,6 +701,7 @@ int get_sha1_with_mode(const char *name, unsigned char *sha1, unsigned *mode)
read_cache();
if (active_nr < 0)
return -1;
+ prepend_prefix(&cp, &namelen);
pos = cache_name_pos(cp, namelen);
if (pos < 0)
pos = -pos - 1;
@@ -708,9 +729,11 @@ int get_sha1_with_mode(const char *name, unsigned char *sha1, unsigned *mode)
}
if (*cp == ':') {
unsigned char tree_sha1[20];
- if (!get_sha1_1(name, cp-name, tree_sha1))
- return get_tree_entry(tree_sha1, cp+1, sha1,
- mode);
+ if (!get_sha1_1(name, cp - name, tree_sha1)) {
+ namelen -= ++cp - name;
+ prepend_prefix(&cp, &namelen);
+ return get_tree_entry(tree_sha1, cp, sha1, mode);
+ }
}
return ret;
}
--
1.5.2.rc0.787.g0014
^ permalink raw reply related
* Re: [PATCH] Support ent:relative_path
From: Dana How @ 2007-05-04 7:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, danahow
In-Reply-To: <463ADE51.2030108@gmail.com>
Yikes... the if's in prepend_prefix() need to be re-arranged.
Dana
On 5/4/07, Dana How <danahow@gmail.com> wrote:
>
> Most commands accept relative paths, but this is
> not true of arguments in ent:path format. This
> patch makes all 3 of the following git-show commands
> work in the git source tree (not just the first):
> % cd xdiff
> % git-show v1.5.2-rc0:xdiff/xemit.h
> % git-show v1.5.2-rc0:./xemit.h
> % git-config --bool core.relativepaths yes
> % git-show v1.5.2-rc0:xemit.h
>
> Signed-off-by: Dana L. How <danahow@gmail.com>
> ---
> cache.h | 2 ++
> config.c | 5 +++++
> environment.c | 1 +
> setup.c | 5 ++++-
> sha1_name.c | 27 ++++++++++++++++++++++++---
> 5 files changed, 36 insertions(+), 4 deletions(-)
>
> diff --git a/cache.h b/cache.h
> index 8e76152..fc3fcb1 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -215,6 +215,7 @@ extern char *get_graft_file(void);
>
> #define ALTERNATE_DB_ENVIRONMENT "GIT_ALTERNATE_OBJECT_DIRECTORIES"
>
> +extern const char *prefix_to_cwd;
> extern const char **get_pathspec(const char *prefix, const char **pathspec);
> extern const char *setup_git_directory_gently(int *);
> extern const char *setup_git_directory(void);
> @@ -276,6 +277,7 @@ extern int delete_ref(const char *, const unsigned char *sha1);
> extern int use_legacy_headers;
> extern int trust_executable_bit;
> extern int has_symlinks;
> +extern int assume_relative_paths;
> extern int assume_unchanged;
> extern int prefer_symlink_refs;
> extern int log_all_ref_updates;
> diff --git a/config.c b/config.c
> index 70d1055..7525965 100644
> --- a/config.c
> +++ b/config.c
> @@ -279,6 +279,11 @@ int git_default_config(const char *var, const char *value)
> return 0;
> }
>
> + if (!strcmp(var, "core.relativepaths")) {
> + assume_relative_paths = git_config_bool(var, value);
> + return 0;
> + }
> +
> if (!strcmp(var, "core.ignorestat")) {
> assume_unchanged = git_config_bool(var, value);
> return 0;
> diff --git a/environment.c b/environment.c
> index 2231659..f1b867d 100644
> --- a/environment.c
> +++ b/environment.c
> @@ -14,6 +14,7 @@ char git_default_name[MAX_GITNAME];
> int use_legacy_headers = 1;
> int trust_executable_bit = 1;
> int has_symlinks = 1;
> +int assume_relative_paths;
> int assume_unchanged;
> int prefer_symlink_refs;
> int is_bare_repository_cfg = -1; /* unspecified */
> diff --git a/setup.c b/setup.c
> index a45ea83..46ae6e3 100644
> --- a/setup.c
> +++ b/setup.c
> @@ -1,5 +1,7 @@
> #include "cache.h"
>
> +const char *prefix_to_cwd;
> +
> const char *prefix_path(const char *prefix, int len, const char *path)
> {
> const char *orig = path;
> @@ -252,7 +254,8 @@ const char *setup_git_directory_gently(int *nongit_ok)
> cwd[len++] = '/';
> cwd[len] = 0;
> inside_git_dir = !prefixcmp(cwd + offset, ".git/");
> - return cwd + offset;
> + prefix_to_cwd = cwd + offset;
> + return prefix_to_cwd;
> }
>
> int git_config_perm(const char *var, const char *value)
> diff --git a/sha1_name.c b/sha1_name.c
> index 55f25a2..0b9e92c 100644
> --- a/sha1_name.c
> +++ b/sha1_name.c
> @@ -592,6 +592,24 @@ static int handle_one_ref(const char *path,
> return 0;
> }
>
> +static void prepend_prefix(const char **cp, int *namelen)
> +{
> + static char fullpath[PATH_MAX];
> + if (*namelen > 2 && !memcmp(*cp, "./", 2)) {
> + *cp += 2;
> + *namelen -= 2;
> + } else
> + if (!assume_relative_paths || !prefix_to_cwd)
> + return;
> +
> + *namelen += strlen(prefix_to_cwd);
> + if (*namelen >= PATH_MAX)
> + die("path too long");
> + strcpy(fullpath, prefix_to_cwd);
> + strcat(fullpath, *cp);
> + *cp = fullpath;
> +}
> +
> /*
> * This interprets names like ':/Initial revision of "git"' by searching
> * through history and returning the first commit whose message starts
> @@ -681,6 +699,7 @@ int get_sha1_with_mode(const char *name, unsigned char *sha1, unsigned *mode)
> read_cache();
> if (active_nr < 0)
> return -1;
> + prepend_prefix(&cp, &namelen);
> pos = cache_name_pos(cp, namelen);
> if (pos < 0)
> pos = -pos - 1;
> @@ -708,9 +727,11 @@ int get_sha1_with_mode(const char *name, unsigned char *sha1, unsigned *mode)
> }
> if (*cp == ':') {
> unsigned char tree_sha1[20];
> - if (!get_sha1_1(name, cp-name, tree_sha1))
> - return get_tree_entry(tree_sha1, cp+1, sha1,
> - mode);
> + if (!get_sha1_1(name, cp - name, tree_sha1)) {
> + namelen -= ++cp - name;
> + prepend_prefix(&cp, &namelen);
> + return get_tree_entry(tree_sha1, cp, sha1, mode);
> + }
> }
> return ret;
> }
> --
> 1.5.2.rc0.787.g0014
>
>
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* [RFC?] Telling git about more complex relationships between commits (Was: Re: FFmpeg considering GIT)
From: Johan Herland @ 2007-05-04 7:21 UTC (permalink / raw)
To: git
In-Reply-To: <200705040242.46156.jnareb@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4036 bytes --]
On Friday 04 May 2007, Jakub Narebski wrote:
> Besides I think it would be better to teach blame to ignore reversion
> commits (for example based on first line of commit message) than to
> mess with the history.
I'm starting to see a pattern where people would like to tell git about
more complicated relationships between commits, so that git can make
more intelligent decisions when doing merge, blame, pickaxe, etc.
Adding these relationships as part of the commit message seems like a
really stupid idea because git suddenly has to make sense of something
it has never parsed before, thus making all future and former git
commit messages a potential target for pattern (mis)matching by git.
Also, we seem to forget that we already have the perfect place to put
such information: The header fields preceding the commit message.
I therefore propose adding header field names to commit objects that
illustrate the relationships people want to tell git about. Examples
include:
1. "Reverts": Mark a commit as reverting another commit. This could be
used by git-log to cancel out pairs of commits, resulting in a cleaner
view of history. It can help blame/annotate. There are probably other
tools that can benefit from this information also.
2. "Cherry-Pick": When cherry-picking a commit onto another branch, you
should be able to tell git which commit you are cherry-picking
(git-cherry-pick would of course do this automatically). This could
enable git to make smarter decisions when merging the two branches: If
the cherry-picked commit would cause a conflict with the original
commit, git can either skip it (since it knows that one version of this
patch is already present), or it can at least present the conflict to
the user with some more context than what is available today. Not to
mention how this information could be used by blame/annotate.
3. "Rebased-From": This one can be filled in automatically by
git-rebase, but when I think about it, it may be too similar
to "Cherry-Pick" to warrant a separate field.
4. "Rebased-To": When doing a rebase like the following:
A---B---C---D---E <--- branch
(Hmm. C is broken. Rebase D and E onto B)
A---B---C---D---E
\
\--D'--E' <--- branch
git-rebase could now add a dummy commit F* to E with "Rebased-To:
{Commit ID of D'}", thus making:
A---B---C---D---E---F*..
\ ,............: (yes, this is a poorly drawn meta-arrow)
\ v
\--D'--E' <--- branch
This would make it easier for git to do the Right Thing when someone
following the old branch tries to pull after the rebase.
5. Heck, while we're at it, move "Signed-off-by" into the header fields,
where git can make more use of it.
6. Finally, allow people to add custom header fields prefixed by "X-"
(like in HTTP), and make it easy for them to extend git tools to use
these custom fields in various ways. If some of them end up being
really useful, we can import them into git (and lose the "X-" prefix).
Now, in order to let people specify these fields we probably want to
make these fields names settable from the command line. It should also
be possible to use a template when doing the commit message in an
editor. Something like:
==========
Optional headers fields (fill in if applicable)
Cherry-Pick: ________
Reverts: ________
Signed-Off-By: ________
Your commit message goes here:
________________________________
==========
Of course, git would have to verify/sanitize these fields when input, so
they probably need some type information associated with them.
Furthermore we might want to think about the possibility of allowing
annotations to previous commits, in order to allow these fields to be
set after the commit has happened, but that's a topic for a
whole 'nother discussion.
Have fun!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] Support ent:relative_path
From: Dana How @ 2007-05-04 7:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, danahow
Most commands accept relative paths, but this is
not true of arguments in ent:path format. This
patch makes all 3 of the following git-show commands
work in the git source tree (not just the first):
% cd xdiff
% git-show v1.5.2-rc0:xdiff/xemit.h
% git-show v1.5.2-rc0:./xemit.h
% git-config --bool core.relativepaths yes
% git-show v1.5.2-rc0:xemit.h
Signed-off-by: Dana L. How <danahow@gmail.com>
---
cache.h | 2 ++
config.c | 5 +++++
environment.c | 1 +
setup.c | 5 ++++-
sha1_name.c | 27 ++++++++++++++++++++++++---
5 files changed, 36 insertions(+), 4 deletions(-)
diff --git a/cache.h b/cache.h
index 8e76152..fc3fcb1 100644
--- a/cache.h
+++ b/cache.h
@@ -215,6 +215,7 @@ extern char *get_graft_file(void);
#define ALTERNATE_DB_ENVIRONMENT "GIT_ALTERNATE_OBJECT_DIRECTORIES"
+extern const char *prefix_to_cwd;
extern const char **get_pathspec(const char *prefix, const char **pathspec);
extern const char *setup_git_directory_gently(int *);
extern const char *setup_git_directory(void);
@@ -276,6 +277,7 @@ extern int delete_ref(const char *, const unsigned char *sha1);
extern int use_legacy_headers;
extern int trust_executable_bit;
extern int has_symlinks;
+extern int assume_relative_paths;
extern int assume_unchanged;
extern int prefer_symlink_refs;
extern int log_all_ref_updates;
diff --git a/config.c b/config.c
index 70d1055..7525965 100644
--- a/config.c
+++ b/config.c
@@ -279,6 +279,11 @@ int git_default_config(const char *var, const char *value)
return 0;
}
+ if (!strcmp(var, "core.relativepaths")) {
+ assume_relative_paths = git_config_bool(var, value);
+ return 0;
+ }
+
if (!strcmp(var, "core.ignorestat")) {
assume_unchanged = git_config_bool(var, value);
return 0;
diff --git a/environment.c b/environment.c
index 2231659..f1b867d 100644
--- a/environment.c
+++ b/environment.c
@@ -14,6 +14,7 @@ char git_default_name[MAX_GITNAME];
int use_legacy_headers = 1;
int trust_executable_bit = 1;
int has_symlinks = 1;
+int assume_relative_paths;
int assume_unchanged;
int prefer_symlink_refs;
int is_bare_repository_cfg = -1; /* unspecified */
diff --git a/setup.c b/setup.c
index a45ea83..46ae6e3 100644
--- a/setup.c
+++ b/setup.c
@@ -1,5 +1,7 @@
#include "cache.h"
+const char *prefix_to_cwd;
+
const char *prefix_path(const char *prefix, int len, const char *path)
{
const char *orig = path;
@@ -252,7 +254,8 @@ const char *setup_git_directory_gently(int *nongit_ok)
cwd[len++] = '/';
cwd[len] = 0;
inside_git_dir = !prefixcmp(cwd + offset, ".git/");
- return cwd + offset;
+ prefix_to_cwd = cwd + offset;
+ return prefix_to_cwd;
}
int git_config_perm(const char *var, const char *value)
diff --git a/sha1_name.c b/sha1_name.c
index 55f25a2..0b9e92c 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -592,6 +592,24 @@ static int handle_one_ref(const char *path,
return 0;
}
+static void prepend_prefix(const char **cp, int *namelen)
+{
+ static char fullpath[PATH_MAX];
+ if (*namelen > 2 && !memcmp(*cp, "./", 2)) {
+ *cp += 2;
+ *namelen -= 2;
+ } else
+ if (!assume_relative_paths || !prefix_to_cwd)
+ return;
+
+ *namelen += strlen(prefix_to_cwd);
+ if (*namelen >= PATH_MAX)
+ die("path too long");
+ strcpy(fullpath, prefix_to_cwd);
+ strcat(fullpath, *cp);
+ *cp = fullpath;
+}
+
/*
* This interprets names like ':/Initial revision of "git"' by searching
* through history and returning the first commit whose message starts
@@ -681,6 +699,7 @@ int get_sha1_with_mode(const char *name, unsigned char *sha1, unsigned *mode)
read_cache();
if (active_nr < 0)
return -1;
+ prepend_prefix(&cp, &namelen);
pos = cache_name_pos(cp, namelen);
if (pos < 0)
pos = -pos - 1;
@@ -708,9 +727,11 @@ int get_sha1_with_mode(const char *name, unsigned char *sha1, unsigned *mode)
}
if (*cp == ':') {
unsigned char tree_sha1[20];
- if (!get_sha1_1(name, cp-name, tree_sha1))
- return get_tree_entry(tree_sha1, cp+1, sha1,
- mode);
+ if (!get_sha1_1(name, cp - name, tree_sha1)) {
+ namelen -= ++cp - name;
+ prepend_prefix(&cp, &namelen);
+ return get_tree_entry(tree_sha1, cp, sha1, mode);
+ }
}
return ret;
}
--
1.5.2.rc0.787.g0014
^ permalink raw reply related
* [git-svn PATCH] Fix markup in git-svn man page
From: Karl Hasselström @ 2007-05-04 7:03 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, git
Some of the existing markup was just plain broken, and some subcommand
options weren't indented properly.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
I poked at the markup with a stick until it rendered well (as both man
and html), but I really don't know much about asciidoc markup, so some
sanity-checking by a third party is probably a good idea.
Documentation/git-svn.txt | 32 +++++++++++++-------------------
1 files changed, 13 insertions(+), 19 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index fcdeeaa..c0d7d95 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -38,32 +38,30 @@ COMMANDS
argument. Normally this command initializes the current
directory.
--T<trunk_subdir>::
---trunk=<trunk_subdir>::
--t<tags_subdir>::
---tags=<tags_subdir>::
--b<branches_subdir>::
---branches=<branches_subdir>::
+-T<trunk_subdir>;;
+--trunk=<trunk_subdir>;;
+-t<tags_subdir>;;
+--tags=<tags_subdir>;;
+-b<branches_subdir>;;
+--branches=<branches_subdir>;;
These are optional command-line options for init. Each of
these flags can point to a relative repository path
(--tags=project/tags') or a full url
(--tags=https://foo.org/project/tags)
-
---no-metadata::
+--no-metadata;;
Set the 'noMetadata' option in the [svn-remote] config.
---use-svm-props::
+--use-svm-props;;
Set the 'useSvmProps' option in the [svn-remote] config.
---use-svnsync-props::
+--use-svnsync-props;;
Set the 'useSvnsyncProps' option in the [svn-remote] config.
---rewrite-root=<URL>::
+--rewrite-root=<URL>;;
Set the 'rewriteRoot' option in the [svn-remote] config.
---username=<USER>::
+--username=<USER>;;
For transports that SVN handles authentication for (http,
https, and plain svn), specify the username. For other
transports (eg svn+ssh://), you must include the username in
the URL, eg svn+ssh://foo@svn.bar.com/project
-
---prefix=<prefix>::
+--prefix=<prefix>;;
This allows one to specify a prefix which is prepended
to the names of remotes if trunk/branches/tags are
specified. The prefix does not automatically include a
@@ -73,7 +71,6 @@ COMMANDS
repository.
'fetch'::
-
Fetch unfetched revisions from the Subversion remote we are
tracking. The name of the [svn-remote "..."] section in the
.git/config file may be specified as an optional command-line
@@ -104,14 +101,11 @@ accepts. However '--fetch-all' only fetches from the current
Like 'git-rebase'; this requires that the working tree be clean
and have no uncommitted changes.
-+
---
+
-l;;
--local;;
Do not fetch remotely; only run 'git-rebase' against the
last fetched commit from the upstream SVN.
---
-+
'dcommit'::
Commit each diff from a specified head directly to the SVN
^ permalink raw reply related
* Re: [RFD/PATCH] Implement pack.compression and pack-objects --compression=N
From: Dana How @ 2007-05-04 7:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, danahow
In-Reply-To: <7vejlxxho1.fsf@assigned-by-dhcp.cox.net>
On 5/3/07, Junio C Hamano <junkio@cox.net> wrote:
> "Dana How" <danahow@gmail.com> writes:
> > So for a 25% increase in blob size I get 33% less elapsed time
> > in git-add, all by changing core.compression from -1 to 1.
> > I'll definitely take that improvement. [For the compressible files
> > we typically have, using 0 is a bad idea: the CPU "advantage"
> > is swamped out by the time to write a much larger file.]
> The above number is about loose objects, right?
Correct.
> > Since I don't care [to the same degree] about the responsiveness of
> > packing, I'd rather pack with -1 or better to keep packs small.
> I see. You are saying that the fact that core.compression is
> used also for packing makes the variable less useful.
Exactly.
> I agree that it would make sense to have at least the pack and
> core compression independent. I am not sure if we would also
> want to make the pack compression tweakable depending on the
> purpose of the packing (network transfer vs .git/objects/pack/).
The final 12-line hunk in the patch implements --pack-compression=N.
To be blunt, I'm not sure *I* need it. Perhaps a high-use web-accessible
public repository would be interested in repacking off-line with 9, and
creating packs for each puller using -1 to reduce CPU load. In the latter
case, due to builtin-pack-objects.c:write_object():to_reuse==1,
much of the transferred data would still be at the better compression
but without again paying the CPU cost. Shall I remove it?
BTW, I'm now in the habit of browsing Git's Gitweb at git.or.cz and notice
"pu" has --max-pack-size. You may want to upgrade to the last 5-patch
version in which --max-pack-size no longer forces --no-reuse-delta at
Shawn's request, among other clean-ups.
Thanks,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* Re: [RFC] Optimize diff-delta.c
From: Martin Koegler @ 2007-05-04 6:40 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
On 2007-05-01 16:05:24, Nicolas Pitre wrote:
> > On Tue, 1 May 2007, Martin Koegler wrote:
> Right. I think it would be a good idea to extend the delta format as
> well to allow for larger offsets in pack v4.
Is git://repo.or.cz/git/fastimport.git#sp/pack4 the current version of
pack v4 efforts?
> > The delta index has approximately the same size in memory as the
> > uncompressed blob ((blob size)/16*(sizeof(index_entry)).
>
> One thing that could be done with really large blobs is to create a
> sparser index, i.e. have a larger step than 16. Because the delta match
> loop scans backward after a match the sparse index shouldn't affect
> compression that much on large blobs and the index could be
> significantly smaller.
In the long term, I think, that the delta generation code needs to get
tunable.
I would add a init_delta function for reading the configuration
options. In create_delta and create_delta_index, different delta
heuristics can be selected based on the blob size and the
configuration options. As patch_delta is not affected by this, it
should be easy to integrate new stragegies.
> > I tried to speed up the delta generation by searching for a common
> > prefix, as my blobs are mostly append only. I tested it with about
> > less than 1000 big blobs. The time for finding the deltas decreased
> > from 17 to 14 minutes cpu time.
>
> I'm surprised that your patch makes so much of a difference. Normally
> the first window should always match in the case you're trying to
> optimize and the current code should already perform more or less the
> same as your common prefix match does.
A block is limited to 64k. If the file has some hundred MBs, it has to
match many blocks.
My patch can process everything except the few last thousand lines by
doing a memcmp.
Additionally, nearly every line starts with the same, longer than 16
byte prefix. So its likely, that many blocks map to the same hash
value.
> Ah, no, actually what your patch does is a pessimisation of the matching
> code by not considering other and possibly better matches elsewhere in
> the reference buffer whenever there is a match at the beginning of both
> buffers. I don't think this is a good idea in general.
For small files, I agree with you.
> What you should try instead if you want to make the process faster is to
> lower the treshold used to consider a match sufficiently large to stop
> searching. That has the potential for even faster processing as the
> "optimization" would then be effective throughout the buffer and not
> only at the beginning.
>
[...]
>
> You could experiment with that value to determine the best speed vs size
> compromize.
I will do some experiments.
mfg Martin Kögler
PS: Sorry for break threading, as you did not CC me.
^ permalink raw reply
* Re: [RFD/PATCH] Implement pack.compression and pack-objects --compression=N
From: Junio C Hamano @ 2007-05-04 5:49 UTC (permalink / raw)
To: Dana How; +Cc: Git Mailing List
In-Reply-To: <56b7f5510705021551q2d48f1e5i3f4a5c2f9891368a@mail.gmail.com>
"Dana How" <danahow@gmail.com> writes:
> So for a 25% increase in blob size I get 33% less elapsed time
> in git-add, all by changing core.compression from -1 to 1.
> I'll definitely take that improvement. [For the compressible files
> we typically have, using 0 is a bad idea: the CPU "advantage"
> is swamped out by the time to write a much larger file.]
The above number is about loose objects, right?
> Since I don't care [to the same degree] about the responsiveness of
> packing, I'd rather pack with -1 or better to keep packs small.
I see. You are saying that the fact that core.compression is
used also for packing makes the variable less useful.
I agree that it would make sense to have at least the pack and
core compression independent. I am not sure if we would also
want to make the pack compression tweakable depending on the
purpose of the packing (network transfer vs .git/objects/pack/).
> (And inflation time seems independent of compression setting.)
True.
^ permalink raw reply
* Re: using stgit/guilt for public branches
From: Michael S. Tsirkin @ 2007-05-04 5:20 UTC (permalink / raw)
To: Yann Dirson
Cc: Robin Rosenberg, Josef Sipek, Michael S. Tsirkin, Junio C Hamano,
Catalin Marinas, git, Josef 'Jeff' Sipek
In-Reply-To: <20070503205836.GA19253@nan92-1-81-57-214-146.fbx.proxad.net>
> Quoting Yann Dirson <ydirson@altern.org>:
> Subject: Re: using stgit/guilt for public branches
>
> On Wed, Apr 25, 2007 at 11:37:05PM +0200, Robin Rosenberg wrote:
> > onsdag 25 april 2007 skrev Josef Sipek:
> > > On Wed, Apr 25, 2007 at 03:20:49PM +0300, Michael S. Tsirkin wrote:
> > [...]
> > > > I am concerned that publishing a git branch managed by stg/guilt
> > > > would present problems: it seems that every time patches are re-ordered,
> > > > a patch is re-written or removed, or we update from upstream,
> > > > everyone who pulls the tree branch will have a hard-to-resolve conflict.
> > > >
> > > > Is that really a problem? If so, would it be possible to work around this
> > > > somehow?
> > >
> > > I thought about this problem a while back when I was trying to decide how to
> > > manage the Unionfs git repository. I came to the conclusion, that there was
> > > no clean way of doing this (at least not using guilt - I can't really speak
> > > for stgit, as I don't know how it does things exactly).
> >
> > StGit has the same problem. Publishing such a branch is only for viewing if
> > you want to publish the tip, like the pu branch in the Git repo. You shouldn't
> > merge from pu either.
>
> You are right, in that what can be done with such branches is limited.
> BUT you can safely "stg branch --create" off any remote stgit stack.
> Then you can "stg rebase origin/master" to port your stack to the new
> tip of the remote stack.
OK.
What happens if someone clones the repo, then reorders patches,
drops some of them, adds new patches in the middle of the stack?
--
MST
^ permalink raw reply
* Re: [PATCH] Make xstrndup common
From: Junio C Hamano @ 2007-05-04 5:20 UTC (permalink / raw)
To: Alex Riesen; +Cc: Daniel Barkalow, git, Junio C Hamano
In-Reply-To: <81b0412b0705030206u3a6b8a46qfd98ccf597d3c96e@mail.gmail.com>
"Alex Riesen" <raa.lkml@gmail.com> writes:
> I'd suggest using platform-optimized memchr:
True. On some architectures, strnlen() is a single instruction.
^ permalink raw reply
* Problem with git-svn
From: John Wiegley @ 2007-05-03 23:10 UTC (permalink / raw)
To: git
Hello,
I've been using git-svn for a couple of weeks now quite happily.
Then the other day I decided to start using "git-clone -l ..." in
order to create a few concurrent topic branches. I then moved to my
canonical repository and did a "pull" from many of these topic branches.
So now I have a master git repository that reflects all of my
accumulated work. I want to reflect this up to my subversion
repository. However, it seems that doing all of that cloning and
pulling has screwed up git-svn's tracking. I get this error now when
I try to dcommit:
Unable to extract revision information from commit
865da18a70e8e93b1776864c73581198028e1190~1
The refid it's complaining about represents a pull of three changes
from one of those topic branches:
commit 865da18a70e8e93b1776864c73581198028e1190
Merge: 42b0b95... f25fcef...
Author: John Wiegley <johnw@newartisans.com>
Date: Thu May 3 00:17:17 2007 -0600
Merge branch 'master' of /Users/johnw/src/ledger/master/
The refids that this refers to are also in my log, all with version
information and log comments.
How do I get git-svn past this point? I can't find any command that
will make it functional again. The last time this happened I just
wiped my git repository and rebuilt it from scratch; but since people
are tracking my git repository now, I'd rather now have to reset all
of my refids (not to mention the sheer amount of time that it takes).
Thank you,
John
^ permalink raw reply
* Re: [PATCH] Try 2: Allow PERL_PATH="/usr/bin/env perl"
From: Bryan Larsen @ 2007-05-04 3:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7k5xvt4.fsf@assigned-by-dhcp.cox.net>
>
> Are they any other issues on MacOS? For example, gitweb.cgi is
> built by replacing the shebang with $(PERL_PATH); I presume that
> you already are successfully working around the whitespace in
> the pathname with your "env perl" on MacOS?
>
I haven't used gitweb.cgi. All the tests run, including the
git-send-email test. (t4200 patch was sent a couple of days ago). I
know there are several people using git very successfully from MacPorts.
The biggest problem in OS X has been that the BSD versions of standard
programs such as xargs and sed are used instead of the GNU versions.
There are currently no problems of that sort.
cheers,
Bryan
^ permalink raw reply
* Re: git-fast-export hg mutt (24M vs 184M)
From: Nicolas Pitre @ 2007-05-04 1:11 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Shawn O. Pearce, Thomas Glanzmann, GIT
In-Reply-To: <20070503222946.GH3260@artemis>
On Fri, 4 May 2007, Pierre Habouzit wrote:
> On Thu, May 03, 2007 at 05:18:24PM -0400, Shawn O. Pearce wrote:
> > Pierre Habouzit <madcoder@debian.org> wrote:
> > > On Thu, May 03, 2007 at 09:17:16PM +0200, Thomas Glanzmann wrote:
> > > > Hello,
> > > > git-repack -a -d -f got it down to 19M. I missed the -f parameter
> > > > before. Sorry for the noise.
> > >
> > > You may want to use git gc that does that (and a bit more) for you.
> >
> > Actually, in this case, no.
> >
> > git-gc by default doesn't use the -f option. -f to git-repack
> > means "no reuse deltas". That particular feature of git-repack is
> > basically required to be used after running git-fast-import with
> > anything sizeable.
>
> okay, so why git fast-import does not let some note somewhere (to be
> picked by git gc later) "a fast-import has been run, use -f for next
> repack if you want best compression" ?
Nah.
The conversion script should do it itself directly after it is done with
fast-import.
Nicolas
^ permalink raw reply
* Re: [tools-dev] Re: Git benchmarks at OpenOffice.org wiki
From: Jakub Narebski @ 2007-05-04 0:48 UTC (permalink / raw)
To: Jan Holesovsky; +Cc: dev, git
In-Reply-To: <200705031351.40548.kendy@suse.cz>
On Thu, May 02, 2007, Jan Holesovsky wrote:
> On Thursday 03 May 2007 01:30, Jakub Narebski wrote:
>>> We should better split the OOo sources; it's a process that already
>>> started [UNO runtime environment vs. OOo without URE], and I proposed
>>> some more changes already.
>>
>> In my opinion each submodule should be able to compile and test by
>> itself. You can go X.Org route with splitting sources into modules...
>
> Indeed, this is the case of URE - it is supposed to run by separately & be
> used even by other projects than OOo.
>
>> or you can make use of the new submodules support (currently plumbing
>> level, i.e. low level commands), aka. gitlinks.
>
> And this would be interesting for the translations, I guess...
>
>> The submodules support makes it possible to split sources into
>> independent modules (parts), which can be developed independently,
>> and which you can download (clone, fetch) or not, while making it
>> possible to bind it all together into one superproject.
By the way, even without submodule support, which for now is plumbing
level only, it would be possible to pull separate subprojects into main
project, like git repository does now with gitk repository, and with
git-gui repository. The latter is merged putting git-gui files in separate
directory in git.git repository, via using 'subtree' merge strategy.
Submodules / subprojects are something similar to Subversion svn:externals
done right.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Try 2: Allow PERL_PATH="/usr/bin/env perl"
From: Junio C Hamano @ 2007-05-04 0:43 UTC (permalink / raw)
To: Bryan Larsen; +Cc: git
In-Reply-To: <463A71D7.5060506@larsen.st>
Bryan Larsen <bryan@larsen.st> writes:
> Maybe PERL_PATH should be renamed PERL_SHEBANG or something. Because
> if you pass in something that doesn't work on a shebang line (longer
> than 32 characters, say), it just won't work.
I think I see what problem you are trying to solve better now.
Probably more relevant example on MacOS would be whitespace in
the pathname.
I think using the bare $(PERL_PATH) in perl/Makefile is a
reasonable solution.
Are they any other issues on MacOS? For example, gitweb.cgi is
built by replacing the shebang with $(PERL_PATH); I presume that
you already are successfully working around the whitespace in
the pathname with your "env perl" on MacOS?
^ permalink raw reply
* Re: FFmpeg considering GIT
From: Jakub Narebski @ 2007-05-04 0:42 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, Panagiotis Issaris
In-Reply-To: <20070503010312.GF4489@pasky.or.cz>
Petr Baudis wrote:
> On Thu, May 03, 2007 at 01:48:26AM CEST, Jakub Narebski wrote:
>> About removing a commit: assume that you have the following history
>> The problem exists _only_ if somebody based his/her work on commit
>> C or its descendant, i.e. original D, E commits. He/she would have
>> to rebase his/her work on top of _changed_ (moved) commits D' and E'.
>
> "_Only_"?
>
> I think it's just totally unsustainable to do this history rewriting in
> an "upstream" git repository. You will get horridly confused, then
> frustrated and then just move from software development to beekeeping.
Perhaps I should have said: "There always would be problems if somebody
based his/her work on commit C or its descendant..."
But there are some times when you can rewrite history without bad
consequences.
You can without any problems rewrite _unpublished_ commits; if one for
example pushes to public repo once per day, or few times a week,
there is time to remove a commit, or amend a commit, or change commit
deeper in a history. Or even use StGIT to manage patches, and change
their sequence, add patch in the midle of patch series, split or join
patches, all that working on creating 'a perfect patch [series]'.
You can rewrite a branch which never would be published, like feature
branches in git.git repository (which are visible only via 'pu' -- proposed
updates branch, which is meant to have history rewritten). Or you can
announce that given branch might be rewritten, and not to base any work
on it (well, you can, but you always should rebase before sending).
Because there always are, and always will be problems if somebody would
base work on series including now removed commit, even if SCM need not
to rewrite history to remove a commit [*1*]. And with history rewriting
even more so, for example accidental inclusion of removed commit.
Besides I think it would be better to teach blame to ignore reversion
commits (for example based on first line of commit message) than to mess
with the history. Note also that git has more tools for forensic analysis
than git-blame; blame / annotate was added later because people are used
to it (and it is I think better than any other, because it can detect
moving and copying code blocks). The primary examining tools are history
browsing limited to specified pathspec, and pickaxe i.e. searching for
commits which changed given line.
Footnotes:
----------
[1] Git began as content adressed filesystem, where each object is named
by its contents (or rather cryptographics hash function of contents).
This results in hash (object id) of commit identifying whole lineage
of it, and makes signing specified commit (using signed tag)
identifying / signing whole history.
--
Jakub Narebski
ShadeHawk on #git
Poland
^ permalink raw reply
* Re: [PATCH] Try 2: Allow PERL_PATH="/usr/bin/env perl"
From: Andrew Ruder @ 2007-05-04 0:03 UTC (permalink / raw)
To: git
In-Reply-To: <7vfy6dzf25.fsf@assigned-by-dhcp.cox.net>
On Thu, May 03, 2007 at 04:02:26PM -0700, Junio C Hamano wrote:
> I do not get this whole business. Why would you even want to
> support that to begin with?
The biggest problem being that on macs it is typical to have two copies
of perl installed (/usr/bin/perl and /opt/local/bin/perl with
DarwinPorts or otherwise). It'd be nice to have a way to tell git
makefiles to put #!/usr/bin/env perl at the top so it just pulls
what is first in the path rather than having to hardcode it to either
/opt/local/bin/perl or /usr/bin/perl.
Say you are packaging a mac os x package of git. Now for the user to
run something like git-svn they'd need the svn bindings obviously, but
of course, some people install them against their system perl, lots of
people install them against their darwinports or otherwise, and it'd be
really nice to just have those various perl scripts use whatever the
person has set up (going by what they have first in their path).
- Andy
--
Andrew Ruder <andy@aeruder.net>
http://www.aeruder.net
^ permalink raw reply
* Submitting patches to the User's Manual.
From: Johan Herland @ 2007-05-03 22:36 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 339 bytes --]
I'm currently reading the Git User's Manual (
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html ), and
I have a couple of changes I'd like to suggest. Where can I find the
authoritative repo I should clone and base my patches on?
Have fun!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Try 2: Allow PERL_PATH="/usr/bin/env perl"
From: Bryan Larsen @ 2007-05-03 23:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfy6dzf25.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Bryan Larsen <bryan@larsen.st> writes:
>
>> The perl scripts start with "#!/usr/bin/perl". There is a mechanism
>> PERL_PATH in the Makefile to change this, but it currently doesn't work
>> with PERL_PATH="/usr/bin/env perl".
>
> I do not get this whole business. Why would you even want to
> support that to begin with?
>
> The purpose of PERL_PATH is for you to tell git the path you
> have your Perl at. It is not about supplying a small shell
> script that lets "env" to figure it out.
>
Maybe PERL_PATH should be renamed PERL_SHEBANG or something. Because if
you pass in something that doesn't work on a shebang line (longer than
32 characters, say), it just won't work.
I was under the impression that "#!/usr/bin/env perl" was the "right"
way to invoke perl. But I'm not doing this because I want to do the
"right" thing. I'm doing this because it makes this scenario work:
$ sudo port install git-core
installing openssl...
installing openssh...
installing curl...
installing expat...
$ ...
$ git-send-email ...
$ ...
$ sudo port install git-svn
installing apr...
installing subversion...
installing perl...
installing p5-svn-simple...
git-core works fine with stock perl, and we don't want to install extra
megabytes of unneeded stuff if it really isn't needed.
Certainly there are other ways of making this work. But they're all
uglier than doing the "right" thing of "/usr/bin/env perl".
cheers,
Bryan
P.S.
On Linux, "#!/usr/bin/env perl -w" doesn't work. On OS X it works fine.
^ 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