* [PATCH 7/9] init: use get_git_work_tree() instead of rolling our own
From: Johannes Schindelin @ 2007-07-29 23:25 UTC (permalink / raw)
To: gitster, git, matled
In-Reply-To: <Pine.LNX.4.64.0707300016470.14781@racer.site>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
builtin-init-db.c | 48 +++++++++++-------------------------------------
1 files changed, 11 insertions(+), 37 deletions(-)
diff --git a/builtin-init-db.c b/builtin-init-db.c
index 66ddaeb..0d9b1e0 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -174,36 +174,7 @@ static void copy_templates(const char *git_dir, int len, const char *template_di
closedir(dir);
}
-/*
- * Get the full path to the working tree specified in $GIT_WORK_TREE
- * or NULL if no working tree is specified.
- */
-static const char *get_work_tree(void)
-{
- const char *git_work_tree;
- char cwd[PATH_MAX];
- static char worktree[PATH_MAX];
-
- git_work_tree = getenv(GIT_WORK_TREE_ENVIRONMENT);
- if (!git_work_tree)
- return NULL;
- if (!getcwd(cwd, sizeof(cwd)))
- die("Unable to read current working directory");
- if (chdir(git_work_tree))
- die("Cannot change directory to specified working tree '%s'",
- git_work_tree);
- if (git_work_tree[0] != '/') {
- if (!getcwd(worktree, sizeof(worktree)))
- die("Unable to read current working directory");
- git_work_tree = worktree;
- }
- if (chdir(cwd))
- die("Cannot come back to cwd");
- return git_work_tree;
-}
-
-static int create_default_files(const char *git_dir, const char *git_work_tree,
- const char *template_path)
+static int create_default_files(const char *git_dir, const char *template_path)
{
unsigned len = strlen(git_dir);
static char path[PATH_MAX];
@@ -282,16 +253,16 @@ static int create_default_files(const char *git_dir, const char *git_work_tree,
}
git_config_set("core.filemode", filemode ? "true" : "false");
- if (is_bare_repository() && !git_work_tree) {
+ if (is_bare_repository())
git_config_set("core.bare", "true");
- }
else {
+ const char *work_tree = get_git_work_tree();
git_config_set("core.bare", "false");
/* allow template config file to override the default */
if (log_all_ref_updates == -1)
git_config_set("core.logallrefupdates", "true");
- if (git_work_tree)
- git_config_set("core.worktree", git_work_tree);
+ if (work_tree != git_work_tree_cfg)
+ git_config_set("core.worktree", work_tree);
}
return reinit;
}
@@ -308,7 +279,6 @@ static const char init_db_usage[] =
int cmd_init_db(int argc, const char **argv, const char *prefix)
{
const char *git_dir;
- const char *git_work_tree;
const char *sha1_dir;
const char *template_dir = NULL;
char *path;
@@ -329,7 +299,11 @@ int cmd_init_db(int argc, const char **argv, const char *prefix)
usage(init_db_usage);
}
- git_work_tree = get_work_tree();
+ git_work_tree_cfg = xcalloc(PATH_MAX, 1);
+ if (!getcwd(git_work_tree_cfg, PATH_MAX))
+ die ("Cannot access current working directory.");
+ if (access(get_git_work_tree(), X_OK))
+ die ("Cannot access work tree '%s'", get_git_work_tree());
/*
* Set up the default .git directory contents
@@ -346,7 +320,7 @@ int cmd_init_db(int argc, const char **argv, const char *prefix)
*/
check_repository_format();
- reinit = create_default_files(git_dir, git_work_tree, template_dir);
+ reinit = create_default_files(git_dir, template_dir);
/*
* And set up the object store.
--
1.5.3.rc3.28.g1406
^ permalink raw reply related
* [PATCH 8/9] Fix t1501 for updated work-tree logic
From: Johannes Schindelin @ 2007-07-29 23:26 UTC (permalink / raw)
To: gitster, git, matled
In-Reply-To: <Pine.LNX.4.64.0707300016470.14781@racer.site>
t1501 is still a PITA to debug. But I decided not to change it, so
that it is easier to see what the differences in the logic are.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
t/t1501-worktree.sh | 24 +++++++++++++++++++-----
1 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/t/t1501-worktree.sh b/t/t1501-worktree.sh
index aadeeab..7322161 100755
--- a/t/t1501-worktree.sh
+++ b/t/t1501-worktree.sh
@@ -33,17 +33,17 @@ mv .git repo.git || exit 1
say "core.worktree = relative path"
export GIT_DIR=repo.git
-export GIT_CONFIG=$GIT_DIR/config
+export GIT_CONFIG="$(pwd)"/$GIT_DIR/config
unset GIT_WORK_TREE
git config core.worktree ../work
test_rev_parse 'outside' false false false
cd work || exit 1
export GIT_DIR=../repo.git
-export GIT_CONFIG=$GIT_DIR/config
+export GIT_CONFIG="$(pwd)"/$GIT_DIR/config
test_rev_parse 'inside' false false true ''
cd sub/dir || exit 1
export GIT_DIR=../../../repo.git
-export GIT_CONFIG=$GIT_DIR/config
+export GIT_CONFIG="$(pwd)"/$GIT_DIR/config
test_rev_parse 'subdirectory' false false true sub/dir/
cd ../../.. || exit 1
@@ -84,9 +84,23 @@ test_rev_parse 'in repo.git' false true false
cd objects || exit 1
test_rev_parse 'in repo.git/objects' false true false
cd ../work || exit 1
-test_rev_parse 'in repo.git/work' false false true ''
+test_rev_parse 'in repo.git/work' false true true ''
cd sub/dir || exit 1
-test_rev_parse 'in repo.git/sub/dir' false false true sub/dir/
+test_rev_parse 'in repo.git/sub/dir' false true true sub/dir/
cd ../../../.. || exit 1
+test_expect_success 'repo finds its work tree' '
+ (cd repo.git &&
+ : > work/sub/dir/untracked &&
+ test sub/dir/untracked = "$(git ls-files --others)")
+'
+
+test_expect_success 'repo finds its work tree from work tree, too' '
+ (cd repo.git/work/sub/dir &&
+ : > tracked &&
+ git --git-dir=../../.. add tracked &&
+ cd ../../.. &&
+ test sub/dir/tracked = "$(git ls-files)")
+'
+
test_done
--
1.5.3.rc3.28.g1406
^ permalink raw reply related
* [PATCH 9/9] Fix t1500 for sane work-tree behavior
From: Johannes Schindelin @ 2007-07-29 23:26 UTC (permalink / raw)
To: gitster, git, matled
In-Reply-To: <Pine.LNX.4.64.0707300016470.14781@racer.site>
When GIT_DIR=../.git, and no worktree is specified, it is reasonable
to assume that the repository is not bare, that the work tree is ".."
and that the prefix is the basename of the current directory.
This is the sane behavior.
t1500 tested for the old behavior, which was plain wrong. And this
patch fixes it minimally.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
t/t1500-rev-parse.sh | 20 ++++++++++----------
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/t/t1500-rev-parse.sh b/t/t1500-rev-parse.sh
index ec49966..bea40cb 100755
--- a/t/t1500-rev-parse.sh
+++ b/t/t1500-rev-parse.sh
@@ -31,9 +31,9 @@ test_rev_parse() {
test_rev_parse toplevel false false true ''
cd .git || exit 1
-test_rev_parse .git/ false true true .git/
+test_rev_parse .git/ true true false ''
cd objects || exit 1
-test_rev_parse .git/objects/ false true true .git/objects/
+test_rev_parse .git/objects/ true true false ''
cd ../.. || exit 1
mkdir -p sub/dir || exit 1
@@ -42,7 +42,7 @@ test_rev_parse subdirectory false false true sub/dir/
cd ../.. || exit 1
git config core.bare true
-test_rev_parse 'core.bare = true' true false true
+test_rev_parse 'core.bare = true' true false false
git config --unset core.bare
test_rev_parse 'core.bare undefined' false false true
@@ -50,28 +50,28 @@ test_rev_parse 'core.bare undefined' false false true
mkdir work || exit 1
cd work || exit 1
export GIT_DIR=../.git
-export GIT_CONFIG="$GIT_DIR"/config
+export GIT_CONFIG="$(pwd)"/../.git/config
git config core.bare false
-test_rev_parse 'GIT_DIR=../.git, core.bare = false' false false true ''
+test_rev_parse 'GIT_DIR=../.git, core.bare = false' false false true work/
git config core.bare true
-test_rev_parse 'GIT_DIR=../.git, core.bare = true' true false true ''
+test_rev_parse 'GIT_DIR=../.git, core.bare = true' true false false ''
git config --unset core.bare
-test_rev_parse 'GIT_DIR=../.git, core.bare undefined' false false true ''
+test_rev_parse 'GIT_DIR=../.git, core.bare undefined' false false true work/
mv ../.git ../repo.git || exit 1
export GIT_DIR=../repo.git
-export GIT_CONFIG="$GIT_DIR"/config
+export GIT_CONFIG="$(pwd)"/../repo.git/config
git config core.bare false
test_rev_parse 'GIT_DIR=../repo.git, core.bare = false' false false true ''
git config core.bare true
-test_rev_parse 'GIT_DIR=../repo.git, core.bare = true' true false true ''
+test_rev_parse 'GIT_DIR=../repo.git, core.bare = true' true false false ''
git config --unset core.bare
-test_rev_parse 'GIT_DIR=../repo.git, core.bare undefined' true false true ''
+test_rev_parse 'GIT_DIR=../repo.git, core.bare undefined' false false true ''
test_done
--
1.5.3.rc3.28.g1406
^ permalink raw reply related
* [UNWANTED PATCH] Die if core.bare = true and core.worktree is set
From: Johannes Schindelin @ 2007-07-29 23:29 UTC (permalink / raw)
To: gitster, git, matled
In-Reply-To: <Pine.LNX.4.64.0707300016470.14781@racer.site>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
This patch is just here to demonstrate how a core.bare = true /
core.worktree conflict could be caught.
Personally, I do not deem it worth the effort, as can be seen by
the lack of adjustments to t1501, which fails utterly with this
patch.
environment.c | 3 +--
setup.c | 8 ++++++--
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/environment.c b/environment.c
index 2af12fd..4c5db32 100644
--- a/environment.c
+++ b/environment.c
@@ -82,8 +82,7 @@ const char *get_git_work_tree(void)
static int initialized = 0;
if (!initialized) {
work_tree = getenv(GIT_WORK_TREE_ENVIRONMENT);
- /* core.bare = true overrides implicit and config work tree */
- if (!work_tree && is_bare_repository_cfg < 1) {
+ if (!work_tree) {
work_tree = git_work_tree_cfg;
/* make_absolute_path also normalizes the path */
if (work_tree && !is_absolute_path(work_tree))
diff --git a/setup.c b/setup.c
index 8237fe3..b0febed 100644
--- a/setup.c
+++ b/setup.c
@@ -342,13 +342,17 @@ int check_repository_format_version(const char *var, const char *value)
shared_repository = git_config_perm(var, value);
else if (strcmp(var, "core.bare") == 0) {
is_bare_repository_cfg = git_config_bool(var, value);
- if (is_bare_repository_cfg == 1)
- inside_work_tree = -1;
+ if (is_bare_repository_cfg == 1 && inside_work_tree < 0)
+ die ("Contradicting config settings for "
+ "bare and worktree");
} else if (strcmp(var, "core.worktree") == 0) {
if (git_work_tree_cfg)
free(git_work_tree_cfg);
git_work_tree_cfg = xstrdup(value);
inside_work_tree = -1;
+ if (is_bare_repository_cfg == 1)
+ die ("Contradicting config settings for "
+ "bare and worktree");
}
return 0;
}
--
1.5.3.rc3.28.g1406
^ permalink raw reply related
* Re: [Untested! proposal] git-mergetool.sh: introduce ediff option
From: David Kastrup @ 2007-07-29 23:30 UTC (permalink / raw)
To: Theodore Tso; +Cc: git
In-Reply-To: <20070729205232.GA10148@thunk.org>
Theodore Tso <tytso@mit.edu> writes:
> On Sun, Jul 29, 2007 at 03:51:34PM +0200, David Kastrup wrote:
>
> For the past two decades, I have EDITOR set to emacs, but I am not
> an ediff fan. Yes, that's anecdotal evidence, but so are your
> assertions.
Ok.
>> In ediff mode, success or failure of the merge will be discerned by
>> Emacs either having written or not written the merge buffer; no
>> attempt of interpreting the exit code is made.
>
> Sometimes resolving the merge file results in no changes. So the fact
> that ediff is buggy in that it doesn't return an exit code is a real
> problem.
Ediff starts out with a changed buffer when merging files.
git-mergetool can check for modification times (which is done on
several backends), so it can catch whether or not the ediff buffer has
been saved.
> We could possibly work around the problem saving and then checking
> the modtime --- but only if ediff actually ends up rewriting the
> file.
See above.
>> In order to bypass things like desktop files being loaded, emerge
>> mode now passes the "-q" option to Emacs. This will make it work
>> in more situations likely to occur, at the price of excluding
>> possibly harmless user customizations with the rest.
>
> But that screws over users who want their customizations, but who
> don't use the desktop package. (And I have a news flash for you;
> the desktop package is *not* include as part of emacs21. It's not
> part of Debian's emacs21 package, version 21.4.) So do not believe
> your claim that emacs's desktop package is commonly used.
Sigh.
$ dpkg -L emacs21-el|grep desktop
/usr/share/emacs/21.4/lisp/desktop.el
>> + ediff)
>> + case "${EDITOR:-${VISUAL:-emacs}}" in
>> + */emacs*|*/gnuclient*|*/xemacs*)
>> + emacs_candidate="${EDITOR:-${VISUAL:-emacs}}";;
>> + *)
>> + emacs_candidate=emacs;;
>> + esac
>> + if base_present ; then
>> + ${emacs_candidate} --eval "(ediff-merge-files-with-ancestor (pop command-line-args-left) (pop command-line-args-left) (pop command-line-args-left) nil (pop-command-line-args-left))" "$LOCAL" "$REMOTE" "$BASE" "$path"
>
> ... and this will blow up if EMACS is set to emacsclient, and emacs
> version is 21.
I am currently working on ironing this out. It is easy to check
whether emacsclient supports --eval and revert to emacs in that case.
Unfortunately, it turns out that the above also blows up with
emacsclient 22.1 (I hope to get some patches into Emacs so that this
will actually work in 22.2). So I am currently reworking this, and it
is indeed fragile stuff and quite a nuisance to get right.
> (And BTW, Debian stable and the current Ubuntu, Edgy Eft, are still
> shipping emacs21. So are a number of current major distro's. So if
> you think the vast majority of users are using emacs22, you are
> either on drugs, and have a very skewed view of what are "normal"
> emacs users.)
The current Ubuntu happens to be Feisty Fawn, and it includes
emacs-snapshot-gtk (among other options) with a workable emacsclient.
But I certainly will not ask for including a solution that would not
produce the best feasible results for all of emacs21, emacs22, and
xemacs-21.x. As I said, the patch was just provided as material for
discussion and does not yet work.
> There is a reason why git-mergetool currently hardcodes the use of
> "emacs", instead of just blindly using the value of $EDITOR or
> $VISUAL.
Which is not really nice to XEmacs users, by the way.
> So what you're doing here in your patch is completely busted. If
> you insist on using emacs_candidate, we need to run emacs --version
> and parse the output, and only using the value of EMACS or VISUAL if
> the major version number of emacs is at least 22.
It is actually more straightforward to check the exit code of
emacsclient --eval t >/dev/null 2>&1
which is basically what I do now. Even if one wanted to parse the
output of --version, emacsclient --version would be faster.
> (It would probably be a good idea to do this once and cache the
> result, so we don't have to repeatedly for each file that git
> mergetool needs to process.)
My current version of the patch already does this. However, the
startup/exit behavior is still somewhat broken though marginally
usable (getting both ediff started and the resulting buffer registered
as a server buffer without messing up ediff's window setup is the
challenge), so I am still ironing stuff out.
>> - if echo "${VISUAL:-$EDITOR}" | grep 'emacs' > /dev/null 2>&1; then
>> - merge_tool_candidates="$merge_tool_candidates emerge"
>> - fi
>> + case "${EDITOR:-${VISUAL}}" in
>> + */emacs*|*/gnuclient*|*/xemacs*)
>> + merge_tool_candidates="$merge_tool_candidates ediff"
>> + esac
>
> Changing the default from emerge to ediff is a non-starter, sorry.
> If you really want to use ediff, you can set a config parameter to
> explicitly request it.
How would you feel about preferring ediff when EDITOR is emacsclient
or gnuclient, and emerge otherwise?
Of course only once ediff will work satisfactorily with all Emacs and
XEmacs variants out there.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: merge time
From: Linus Torvalds @ 2007-07-29 23:35 UTC (permalink / raw)
To: Matthew L Foster; +Cc: git
In-Reply-To: <630183.45851.qm@web51001.mail.re2.yahoo.com>
On Sun, 29 Jul 2007, Matthew L Foster wrote:
>
> From viewing gitweb.cgi I have observed a situation where Linus creates
> a tag, say rc1, and then he later merges changes but some subset of
> those changes/commits show up in the list in time order as taking place
> _before_ the rc1 tag was made even though they were merged after.
Absolutely. This is very common indeed. It's even more common with not the
-rc1 tag, but a release.
When I cut a full release, that "opens the floodgates" for the merge
window, and a lot of people who have committed their changes (maybe
weeks or *months* before) but where the changes weren't appropriate to be
merged before the merge window, will now ask me to pull.
So you may have the situation that 2.6.22 was released, but then a few
days later I'll merge stuff that was actually committed two weeks before
the 2.6.22 release, but was not _in_ the release.
> Do I describe a real or possible phenomenon? And does this happen
> because the developer that made the subset of changes in question commit
> them to his/her local repository in time order before the rc1 tag was
> made?
Yes. I would seriously suggest you not use "gitweb" as your way to look at
the repository, because you'll never see all the interactions that way.
Cloning a git repository (not necessarily the kernel, but it needs to be
something with concurrent developement), and exploring it locally with
"gitk" or "qgit" is a _lot_ more informative. When you see the actual
history chains graphically, something that might look "odd" in gitweb
(commits that look old but weren't there a few days ago) suddenly makes
tons of sense.
> So an external repository had the change before the rc1 tag was made but
> Linus' repository didn't? But internally git on Linus' machine knows
> that the gitweb.cgi displayed time order is wrong as far as the state is
> concerned because each repository's index file keeps local track of the
> true local state [just time isn't reconcilable], or am I missing
> something(s)?
Well, there i sno "wrong" time. There are just "different" times. The only
thing git really tracks is not actually the time (that's purely for human
consumption), but the *relationship* between commits. So git really very
fundmanetally just tracks things like "commit X was the parent of commit
Y", and the time is really immaterial.
The time, to git, is not really different from authorship: it's very
important to track when something was done, but it's really purely
informational, exactly the same way the _author_ is purely informational.
It has no "meaning" for git itself.
> Is it possible for gitweb.cgi to have a new view mode that
> sorts/displays the list based on merge time for commits (the time merged
> into Linus' or whatever repository) so the above situation doesn't
> happen?
The public repositories don't even know what the merge time was for me.
That's a purely local feature, and while I can see it in my private
repository that I actually did the merge in, I don't publish that
information. It's incidental, and quite frankly, it's "wrong" to care:
because "Linus' tree" is really not even supposed to be special.
Linus
^ permalink raw reply
* Re: [PATCH] Makefile: create an install-symlinks target
From: Brian Gernhardt @ 2007-07-29 23:44 UTC (permalink / raw)
To: David Kastrup; +Cc: Junio C Hamano, git
In-Reply-To: <85bqduvo5r.fsf@lola.goethe.zz>
On Jul 29, 2007, at 6:30 PM, David Kastrup wrote:
> a) this required the installation of additional software for a simple
> task.
I would think it's preferable to have a single piece of software to
manage these links than attempt to craft a custom solution for every
package you install.
> b) if the software worked using symbolic links, it would not know at
> what level to make the links (namely create
> /usr/local/share/man/man1 and link every file from
> /opt/git/share/man/man1, but link the directory
> /usr/local/share/git-core directly to /opt/git/share/git-core).
What stow does is to create a directory for every level where
multiple packages have files or non-stow files exists. It would
create a link at /usr/local/share/git-core because nobody else uses
that directory. If there are other /usr/local/share/man/man1/*
files, it would make a link for every file in the git version.
> Since the stuff is strictly an additional convenience not impacting
> any of the existing targets, I would not have thought it terribly
> controversial.
It's additional maintenance, mostly. I don't have an objection to
it, although I also don't see a reason to include it.
> Is there a place other than the git list where one can provide patches
> that are not likely to end up in git.git?
You could make a repo at repo.or.cz, I think. Have different
branches to maintain features and rebase them on top of master
periodically. Or just any random web-page to publish raw patches.
My $0.02,
~~ Brian
^ permalink raw reply
* Re: [PATCH] gitweb: localhost placeholder parser for cloneurl file
From: Jakub Narebski @ 2007-07-29 23:57 UTC (permalink / raw)
To: git
In-Reply-To: <d68f80d90707282354l1593f2ctc0cf7a05eeb3b8e0@mail.gmail.com>
[Cc: Leandro Dorileo <ldorileo@gmail.com>, git@vger.kernel.org]
Leandro Dorileo wrote:
> From 32da24e1e18a1c5f32bfa0afdbcb6d0f2b0432f3 Mon Sep 17 00:00:00 2001
> From: Leandro Dorileo <dorileo@ossystems.com.br>
> Date: Sat, 28 Jul 2007 15:34:20 -0400
> Subject: [PATCH] gitweb: localhost placeholder parser for cloneurl file
>
> Implementation of a localhost placeholder parsing in git_get_project_url_list.
> It`s useful in cases of gitweb being hosted in a work-station (like a notebook)
> used in a local team development environment and, implementation of a git-url
> link in the git project list body like in git.kernel.org.
First, the commit message _has_ to be self explanatory, and be easily
understood _without_ email message which introduced it.
So you should clean-up the explanation about _why_ one would want to
replace #localhost#, or ++LOCALHOST++ in the cloneurls by the server
name (the same configuration, different machines; although I do not
understand why it is so hard to change configutation depending on
machine).
Second, please clean up the code. Comments below.
Third, sign-off your patches: see Documentation/SubmittingPatches
> ---
> gitweb/gitweb.perl | 21 ++++++++++++++++++---
> 1 files changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index b381692..281d823 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -1471,7 +1471,16 @@ sub git_get_project_url_list {
> my @git_project_url_list = map { chomp; $_ } <$fd>;
> close $fd;
>
> - return wantarray ? @git_project_url_list : \@git_project_url_list;
> + if(wantarray){
Style: "if (wantarray) {".
But I think you would want to do the substitution regardless of
whether git_get_project_url_list() subroutine is called in scalar
or list context. (By the way I think it might be a mistake to use
this trick: return array in the list context, return array reference
in the scalar context).
So you would put the code proposed below before
return wantarray ? @git_project_url_list : \@git_project_url_list;
> + for(my $i = 0; $i < @git_project_url_list; $i++){
> + if(index(@git_project_url_list[$i], "#localhost#") != -1){
> + @git_project_url_list[$i] =~
> s/#localhost#/server_name()/eg;
> + }
> + }
Why not simply:
@git_project_url_list = map { s/#localhost#/server_name()/eg; }
@git_project_url_list;
And didn't you meant $cgi->server_name() or just $ENV{'SERVER_NAME'}?
> + return @git_project_url_list;
> + }else{
> + return \@git_project_url_list;
> + }
Just end with what it was before:
return wantarray ? @git_project_url_list : \@git_project_url_list;
> }
> sub git_get_projects_list {
> @@ -3384,8 +3393,14 @@ sub git_project_list_body {
> $cgi->a({-href => href(project=>$pr->{'path'},
> action=>"shortlog")}, "shortlog") . " | " .
> $cgi->a({-href => href(project=>$pr->{'path'},
> action=>"log")}, "log") . " | " .
> $cgi->a({-href => href(project=>$pr->{'path'},
> action=>"tree")}, "tree") .
> - ($pr->{'forks'} ? " | " . $cgi->a({-href =>
> href(project=>$pr->{'path'}, action=>"forks")}, "forks") : '') .
> - "</td>\n" .
> + ($pr->{'forks'} ? " | " . $cgi->a({-href =>
> href(project=>$pr->{'path'}, action=>"forks")}, "forks") : '');
> +
> + my @url_list = git_get_project_url_list($pr->{'path'});
> + if(@url_list != 0){
> + print " | " . $cgi->a({-href => @url_list[0]}, "git");
> + }
Style: "if (@url_list) {" is enough.
Style: use tabs for indent, now spaces.
But this is totally independent thing, and it should be put in
separate patch. And it doesn't make much sense as first URL in
the list might not be using scheme recognized by web browser:
- it can be git:// URL.
- it can be scp style ssh:// URL: <user>@<host>:<path>
- it can be local path, without file:// prefix
> +
> + print "</td>\n" .
> "</tr>\n";
> }
> if (defined $extra) {
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Gitweb and submodules
From: Jakub Narebski @ 2007-07-30 0:09 UTC (permalink / raw)
To: Sven Verdoolaege; +Cc: git
In-Reply-To: <20070729163747.GJ31114MdfPADPa@greensroom.kotnet.org>
On Sun,29 July 2007, Sven Verdoolaege wrote:
> On Sat, Jul 28, 2007 at 10:39:28PM +0200, Jakub Narebski wrote:
>> On Sat, 28 July 2007, Sven Verdoolaege wrote:
>>> On Sat, Jul 28, 2007 at 12:29:16PM +0200, Jakub Narebski wrote:
>> I am thinking about the following sequence to search for submodule
>> objects:
>>
>> From $GIT_DIR/config:
>> submodule.$name.objects (absolute or relative to gitdir of superproject)
>> submodule.$name.gitdir (absolute or relative to gitdir of superproject)
>
> Do we really need both of these?
We need only location of object database for projects. The submodule
does not need full GIT_DIR structure, with refs, config, etc.
So no, I'm not sure if we want both. They are equivalent to setting
GIT_OBJECT_DIRECTORY and GIT_DIR for submodule, respectively.
>> submodule.$name.url (to find GIT_DIR, if it is local filesystem URL)
>>
>> If there is working directory, from .gitmodules file in top level
>> of working directory:
Or the .git/config of superproject.
>> submodule.$name.path/.git (relative to toplevel of working directory)
>
> Having a relative path for the URL in .gitmodules in a public repo
> doesn't seem very useful to me. I know it's only meant as a default
> value, but if it is a relative path, then it won't work for
> anyone cloning the superproject.
Erm, it should be relative path in .git/config (as in example in the
t/t7400-submodule-basic.sh IIRC). And this is purely local matter.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC] Git User's Survey 2007
From: Jakub Narebski @ 2007-07-30 0:21 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: git
In-Reply-To: <4d8e3fd30707290950lce19ef4g103cbb7ad1abbe23@mail.gmail.com>
Paolo Ciarrocchi wrote:
> On 7/27/07, Jakub Narebski <jnareb@gmail.com> wrote:
>> First there is a question about the form of survey. Should we use web
>> based survey, as the survey before (http://www.survey.net.nz), sending
>> emails with link to this survey, or perhaps do email based survey,
>> with email Reply-To: address put for this survey alone?
>
> I vote for the survey.net.nz approach. I think that from a user
> prospective that's the right thing to do, we can have "multiple choice
> questions" and avoid some of the more common mistakes.
I think it also better (especially that I started devising questions
with multiple-choice and single-choice answers in mind...).
>> Third, where to send survey to? I was thinking about git mailing list,
>> LKML, and mailing list for git projects found on GitProjects page on
>> GIT wiki. Do you want to add some address? Or should info about GIT
>> User's Survey 2007 be sent also to one of on-line magazines like
>> LinuxToday, or asked to put on some blog?
>
> I think that one of the mistakes I did when I sent out the first
> survey was to not contact any magazines and blog.
Any proposals? Besides LWN, NewsForge, Slashdot?
>> ----
>> About you
>>
>> 1. What country are you in?
>
> I know that lot of people will disagree with me but from a pure
> statistical prospective I'd like to add a couple of questions about
> gender and age.
>
> I understand very well that these questions will not be useful for
> making git any better but it will be interesting to have a better
> picture abut the git customer base.
I'm not sure it would add any important informatant information;
although "age" (years, or age bracket?) could be useful.
>> How you use GIT
>> 8. Which porcelains do you use?
>> (zero or more: multiple choice)
>> - core-git, cogito, StGIT, pg, guilt, other
IsiSetup
> git-gui ?
>
>> 9. Which git GUI do you use
>> (zero or more: multiple choice)
>> - gitk, git-gui, qgit, gitview, giggle, other
tig, instaweb, (h)gct, qct, KGit
I consider git-gui an UI (like qgit or tig), not a porcelain. To be
a porcelains tool need to add some SCM functionality not present in
git-core.
> How about adding a question about whether the user migrated from a
> different SCM? If so, from which SCM and why?
I have added, suggested [somewhat] by Andy Parkins, the following
set of questions:
----
Other SCMs
1. What other SCM did you use?
2. What other SCM do you use currently?
3. What other SCM do you use as a main SCM for your project
instead of git, if any? Why?
* example: Mercurial, better MS Windows support
5. What would you require from git to enable you to change,
if you use other SCM for your project?
4. Do your git repository interact with other SCM? Or what SCM
did you import from? What tool did/do you use?
* examples: CVS, import: fromcvs, interaction: git-cvsserver;
Subversion, git-svn
----
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: merge time
From: Matthew L Foster @ 2007-07-30 1:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, mfoster167
In-Reply-To: <alpine.LFD.0.999.0707291623160.3442@woody.linux-foundation.org>
--- Linus Torvalds <torvalds@linux-foundation.org> wrote:
> Well, there i sno "wrong" time. There are just "different" times. The only
> thing git really tracks is not actually the time (that's purely for human
> consumption), but the *relationship* between commits. So git really very
> fundmanetally just tracks things like "commit X was the parent of commit
> Y", and the time is really immaterial.
Is it possible for git and/or gitweb to know that commits X and Y are descendents of merge C and
use the time merge C happened locally for both instead of using the time commits X and Y were
created? It seems to me changes showing up as being made long before they really were merged is a
very serious problem verification wise but if everyone is using git then perhaps it's not as bad
as I think. What happens when security bug fix Z errantly seems to be in v2.6.22 but in reality
its not?
Thanks for the responses,
-Matt
____________________________________________________________________________________
Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center.
http://autos.yahoo.com/green_center/
^ permalink raw reply
* Re: merge time
From: david @ 2007-07-30 1:27 UTC (permalink / raw)
To: Matthew L Foster; +Cc: Linus Torvalds, git
In-Reply-To: <241612.78983.qm@web51007.mail.re2.yahoo.com>
On Sun, 29 Jul 2007, Matthew L Foster wrote:
> --- Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>> Well, there i sno "wrong" time. There are just "different" times. The only
>> thing git really tracks is not actually the time (that's purely for human
>> consumption), but the *relationship* between commits. So git really very
>> fundmanetally just tracks things like "commit X was the parent of commit
>> Y", and the time is really immaterial.
>
> Is it possible for git and/or gitweb to know that commits X and Y are descendents of merge C and
> use the time merge C happened locally for both instead of using the time commits X and Y were
> created?
git knows what's a decendent of what, but gitweb doesn't show it well.
that's why Linus suggested you look at gitk or qgit.
by the way, you probably mean that commits X and Y are parents of merge C,
not decendants.
but if git did what you wanted it would show every commit with the time of
the merge, and that wouldn't help you anyway.
> It seems to me changes showing up as being made long before they really were merged is a
> very serious problem verification wise but if everyone is using git then perhaps it's not as bad
> as I think. What happens when security bug fix Z errantly seems to be in v2.6.22 but in reality
> its not?
you don't look at the dates to see if the bugfix is in 2.6.22 you look at
the graph or ask git to tell you
remember that in git you don't have one-true-trunk of the project, you
have a mesh of interconnected points, some of which are pointed to by tags
that tell you that other people thought that they are particularly
interesting.
David Lang
> Thanks for the responses,
> -Matt
>
>
>
> ____________________________________________________________________________________
> Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center.
> http://autos.yahoo.com/green_center/
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [GUILT PATCH] guilt-help: Make guilt-cmd --help show the right man page
From: Eric Lesh @ 2007-07-30 2:11 UTC (permalink / raw)
To: Josef Sipek; +Cc: Git mailing list
Signed-off-by: Eric Lesh <eclesh@ucla.edu>
---
guilt | 8 +++++++-
guilt-help | 3 ++-
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/guilt b/guilt
index f67bfb5..6a69261 100755
--- a/guilt
+++ b/guilt
@@ -11,7 +11,13 @@ GUILT_NAME="Los"
case $1 in
-h|--h|--he|--hel|--help)
shift
- exec "guilt-help" "$@"
+ if [ -z "$@" ]; then
+ # guilt-cmd --help or guilt cmd --help
+ exec "guilt-help" `basename $0`
+ else
+ # guilt --help cmd
+ exec "guilt-help" "$@"
+ fi
exit
;;
-V|--ver|--versi|--versio|--version)
diff --git a/guilt-help b/guilt-help
index 274246b..e2340d9 100755
--- a/guilt-help
+++ b/guilt-help
@@ -14,7 +14,8 @@ case $# in
;;
1)
if [ "$1" != "guilt" ]; then
- page="guilt-$1"
+ cmd=$(echo "$1" | sed -e 's/guilt-//')
+ page="guilt-$cmd"
else
page="guilt"
fi
--
1.5.2
^ permalink raw reply related
* Re: merge time
From: Linus Torvalds @ 2007-07-30 2:29 UTC (permalink / raw)
To: Matthew L Foster; +Cc: git
In-Reply-To: <241612.78983.qm@web51007.mail.re2.yahoo.com>
On Sun, 29 Jul 2007, Matthew L Foster wrote:
>
> Is it possible for git and/or gitweb to know that commits X and Y are descendents of merge C and
> use the time merge C happened locally for both instead of using the time commits X and Y were
> created?
The data exists, but there is nothing to make "C" special. Or rather, the
two "sides" of C that got merged are 100% equivalent.
You'd probably have to read a lot of old emails (from very early in the
git process) to see the whole picture. But the fact is, in a distributed
environment, the parents to a merge C are totally equivalent.
So thus when you talk about merge new code into an old repository (and
giving those new commits the same date as the merge), that is actually
technically 100% equivalent to merging the other way around, and thus
you'd have to give all the *old* commits that new merge date too!
And yes, this does happen. It's not at all the case that I always merge
other peoples tree: quite often other people merge _my_ tree, and the end
result really is that they pulled in the changes _I_ had done.
[ Side note: we do actually try to avoid that, just because it makes the
history harder to read, and the resulting criss-cross merges, while
technically not a problem at all, can confuse people. But when I say
"try to avoid that", I mean just that: it's not a hard rule, and the
reverse merging _does_ happen, and there are good reasons for why it
happens.
So *most* of the time, the history looks like it's me merging other
peoples code, but then every once in a while, the merge is done by the
other side. And from a pure technical standpoint, the two cases are
totally equivalent, and git is very fundamentally designed to *not*
care. ]
So there is never really any way to say that one side of a merge is
special. The closest you can get is saying
- the first parent is special.
This is "see merges from the viewpoint of the merger", but as
mentioned, the person who actually did the merge isn't necessarily me,
so while this is a totally self-consistent view, it's not really the
view you are looking for.
You can get some of this view by using "git log --first-parent", which
basically follows commits preferentially using the first parent, and
thus "prefers" history as seen by whoever did the merge.
or
- the *local* repository is special (but this is a purely repository-
local viewpoint).
This is what "reflogs" give you, and what "git log -g" shows. It shows
the history not as it pertains to parenthood, but as the tip-of-tree
has changed in *that* repository.
but neither of those are really "sensible" (the first one will give
*wildly* different results if the repository is ever "switched around"
because it's not merged by a single person, and the second one is a purely
local thing and has no meaning for anybody else.
The fact is, distributed history isn't one-dimensional. You *cannot*
linearize it as some one-dimensional time. Impossible. Any system that
tries is broken. Fundamentally.
Linus
^ permalink raw reply
* Re: merge time
From: Matthew L Foster @ 2007-07-30 2:28 UTC (permalink / raw)
To: git, david; +Cc: mfoster167
> but if git did what you wanted it would show every commit with the time of
> the merge, and that wouldn't help you anyway.
Actually that is exactly what I want. I want to know what local time change X and Y (and all
changes) were merged locally.
-Matt
____________________________________________________________________________________
Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online.
http://smallbusiness.yahoo.com/webhosting
^ permalink raw reply
* Re: merge time
From: Matthew L Foster @ 2007-07-30 2:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.999.0707291914451.3442@woody.linux-foundation.org>
--- Linus Torvalds <torvalds@linux-foundation.org> wrote:
> The fact is, distributed history isn't one-dimensional. You *cannot*
> linearize it as some one-dimensional time. Impossible. Any system that
> tries is broken.
I don't want distributed history, I want what local time changes were merged locally. That is why
I described a separate view for this feature, this feature request is not meant to replace how
time is currently not being used. :)
-Matt
____________________________________________________________________________________
Pinpoint customers who are looking for what you sell.
http://searchmarketing.yahoo.com/
^ permalink raw reply
* Re: merge time
From: Linus Torvalds @ 2007-07-30 3:06 UTC (permalink / raw)
To: Matthew L Foster; +Cc: git
In-Reply-To: <498048.62681.qm@web51002.mail.re2.yahoo.com>
On Sun, 29 Jul 2007, Matthew L Foster wrote:
>
> --- Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> > The fact is, distributed history isn't one-dimensional. You *cannot*
> > linearize it as some one-dimensional time. Impossible. Any system that
> > tries is broken.
>
> I don't want distributed history, I want what local time changes were
> merged locally.
The point is, there is no "locally".
Do you mean locally on my machine? That's actually *different* from the
locally on the public machines, and no, I wouldn't give you that
information anyway (since that information would include the mistakes that
I fixed up ;)
And in fact, even on the public machines, the "locally" would be different
depending on things like mirroring delays, although that is currently
hidden by the fact that kernel.org uses rsync for mirroring rather than
using git natively.
So in theory, we could pick one particular public kernel.org machine, and
use the times as _that_ machine sees it, but the fact is, that isn't how
git works. No normal git command will ever show you such a senseless
ordering.
I suspect that the closest you could get to what you want would be to
actually run git-cvsserver on kernel.org to export the git data as "CVS"
data, and then you could use a CVS client that gets a linearized model of
history. That is, afaik, the only way to give you what you want.
And quite frankly, I'd never ask the kernel.org maintainers to do
something that perverse. You could ask them, and maybe they would do so
out of some really perverse self-destructive death-wish, but quite
frankly, you'd probably be better off setting up such a git->CVS gateway
on some local machine yourself.
Linus
^ permalink raw reply
* Re: merge time
From: Linus Torvalds @ 2007-07-30 3:09 UTC (permalink / raw)
To: Matthew L Foster; +Cc: git, david
In-Reply-To: <686661.84825.qm@web51011.mail.re2.yahoo.com>
On Sun, 29 Jul 2007, Matthew L Foster wrote:
>
> > but if git did what you wanted it would show every commit with the time of
> > the merge, and that wouldn't help you anyway.
>
> Actually that is exactly what I want. I want to know what local time change X and Y (and all
> changes) were merged locally.
You misunderstand. It would do so both for the newly merged commits *and*
for the old commits. Because _you_ think the "new" commits got merged, but
it's logically exactly equivalent to saying that the *old* commits got
merged.
So now *every* single commit would get the timestamp of the merge.
See? It would be pointless.
Linus
^ permalink raw reply
* Re: merge time
From: Linus Torvalds @ 2007-07-30 3:16 UTC (permalink / raw)
To: Matthew L Foster; +Cc: git
In-Reply-To: <alpine.LFD.0.999.0707292000190.4161@woody.linux-foundation.org>
On Sun, 29 Jul 2007, Linus Torvalds wrote:
>
> So in theory, we could pick one particular public kernel.org machine, and
> use the times as _that_ machine sees it, but the fact is, that isn't how
> git works. No normal git command will ever show you such a senseless
> ordering.
So to be constructive, and just tell you what the *sensible* ordering is:
- get a kernel git clone
- do "git pull" to update it.
- do
gitk ORIG_HEAD..
to show what the new stuff is after each update, or do something like
gitk v2.6.23-rc1..
to show what is new after -rc1 (or "gitk @{2.days.ago}.." to see what
is new in _your_ tree in the last two days or whatever).
No commit dates anywhere. Just commit relationships and your *local* views
of time.
(Sure, gitk will show you the commit dates too, but they aren't important,
since they have no meaning as to whether a commit got merged into
2.6.23-rc1 or not).
Linus
^ permalink raw reply
* Re: [RFC] Git User's Survey 2007
From: Shawn O. Pearce @ 2007-07-30 3:35 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Paolo Ciarrocchi, git
In-Reply-To: <200707300221.23511.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> wrote:
> Paolo Ciarrocchi wrote:
> > git-gui ?
> >
> >> 9. Which git GUI do you use
> >> (zero or more: multiple choice)
> >> - gitk, git-gui, qgit, gitview, giggle, other
> tig, instaweb, (h)gct, qct, KGit
>
> I consider git-gui an UI (like qgit or tig), not a porcelain. To be
> a porcelains tool need to add some SCM functionality not present in
> git-core.
Odd. I consider git-gui to be a porcelain, just as I consider
tig and qgit to also be porcelain. Though I think git-gui is more
of a porcelain than the others, as it tries to rely *less* on the
core porcelain and just on the plumbing. I don't always succeed,
but I'm heading in that direction.
To me a porcelain is any tool that layers over the plumbing and makes
it easier for the end-user to operate it. Early git only had things
like read-tree/write-tree/commit-tree. Tying that all up into a neat
"Commit" command for the end-user is the job of porcelain.
Anyway. Just so long as git-gui is included in the survey. I'm
interested in seeing how many people use it, because I know it has
a pretty decently sized userbase. Which is probably going to grow
in the future with the i18n work going on.
Do we have any questions in the survey about the user's native
language? About their desire to have git translated into their
native language? Folks are now working on translating git-gui,
and that work will be in git-gui 0.9.x, if not 0.8.1/2. So it may
be nice to know what languages our users are interested in.
--
Shawn.
^ permalink raw reply
* Re: git-gui blame: show previous commit
From: Shawn O. Pearce @ 2007-07-30 3:43 UTC (permalink / raw)
To: Florian Weimer; +Cc: Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.64.0707291238230.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Sun, 29 Jul 2007, Florian Weimer wrote:
>
> > How can I view the previous commit touching a specific line, so that I
> > can see what was there before? For instance, the change could be
> > whitespace-only, so that I want to dig deeper.
>
> If you want to ignore whitespace changes, try the option "-w" to "git
> blame". I have no idea if "git-gui blame" can use that option, but it
> should not be hard for you to find out, and provide a patch if it does
> not yet.
gitgui-0.7.4-35-ga840566 is a change from Junio to enable the
-w flag to git-blame if the underlying git is 1.5.3 or later.
So you'd need a pretty recent git-gui and a 1.5.3-rc0 or later
git binary underneath of it to get -w enabled in blame. But it is
there for the original line annotation pass (the second blame pass
but first column displayed).
I keep meaning to add a "Show parent commit" in the context menu
of the blame viewer, but I haven't gotten around to it yet.
It has been requested a few times, just hasn't been done yet.
Maybe someone who wants it will submit a patch. ;-)
In really recent git-gui (gitgui-0.7.5-76-g8e891fa and later) you
can browse any revision you want, so you could copy the commit SHA-1
from the lower pane and paste it in as "$sha1^" into the revision
expression field of the browse dialog, navigate to the file and
open the blame viewer. That is really annoying, and doesn't jump
you to the correct lines automatically. But it is possible to view
the parent.
--
Shawn.
^ permalink raw reply
* Re: [GUILT PATCH 1/4] get_series: Remove comments from end of series lines
From: Josef Sipek @ 2007-07-30 3:54 UTC (permalink / raw)
To: Eric Lesh; +Cc: jsipek, git
In-Reply-To: <11856954183111-git-send-email-eclesh@ucla.edu>
On Sun, Jul 29, 2007 at 12:50:15AM -0700, Eric Lesh wrote:
...
> diff --git a/guilt b/guilt
> index f67bfb5..774909e 100755
> --- a/guilt
> +++ b/guilt
> @@ -178,7 +178,8 @@ get_series()
> # - whitespace only
> # - optional whitespace followed by '#' followed by more
> # optional whitespace
> - grep -ve '^[[:space:]]*\(#.*\)*$' "$series"
> + # also remove comments from end of lines
> + grep -ve '^[[:space:]]*\(#.*\)*$' < "$series" | sed -e 's/[[:space:]]*#.*$//'
I'd be tempted to replace the whole thing with one sed script...something
like (not tested):
"
/^[[:space:]]*#/ ! {
s/[[:space:]]*#.*$//
p
}
"
Regardless of the other 3 patches, this one makes sense to include.
Josef 'Jeff' Sipek.
--
Once you have their hardware. Never give it back.
(The First Rule of Hardware Acquisition)
^ permalink raw reply
* Re: [GUILT PATCH 0/4] Add guards to guilt
From: Josef Sipek @ 2007-07-30 3:54 UTC (permalink / raw)
To: Eric Lesh; +Cc: jsipek, git
In-Reply-To: <118569541814-git-send-email-eclesh@ucla.edu>
On Sun, Jul 29, 2007 at 12:50:14AM -0700, Eric Lesh wrote:
>
> This series adds Mercurial Queues-like guards to guilt. It allows you
> to assign guards to related patches in the series file to selectively
> push patches.
Neat. I actually never looked into guards, but you forced me to :) Very
interesting concept. I think it would be worth it having such functionality
in guilt.
I know I've been bad about forcing even myself to write new regression
tests. Your patches modify things significantly enough, that I'd like to see
some regression tests cases to make sure that user's data is not eaten
(e.g., a bug in the guard setting code could blow away the series file =>
very bad).
> This introduces the command `get_guarded_series`, which just lists
> patches that are to be applied based on the guards. It also makes
> eidx=`wc -l < $applied`
> inaccurate if you're using it as an index into get_series.
The index-based patch finding is a bit nasty anyway.
> If you change guards on a patch or select a different guard while
> patches are applied, some commands might get confused. guilt pop -a will fix
> everything though. Usually, it's best to pop -a before fiddling with
> guards anyway.
Is this a problem with other projects' implementations of guards as well?
Perhaps printing a warning if a new guard is set when there are applied
patches would be in order?
> This is an RFC, but I have tested it and things seem to be working
> well.
Great!
I'm going to reply to each of the patches separately with any comments.
Josef 'Jeff' Sipek.
--
Penguin : Linux version 2.4.20-46.9.legacysmp on an i386 machine (2778.72 BogoMips).
^ permalink raw reply
* Re: merge time
From: Matthew L Foster @ 2007-07-30 3:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.999.0707292000190.4161@woody.linux-foundation.org>
--- Linus Torvalds <torvalds@linux-foundation.org> wrote:
> The point is, there is no "locally".
>
> Do you mean locally on my machine? That's actually *different* from the
> locally on the public machines, and no, I wouldn't give you that
> information anyway (since that information would include the mistakes that
> I fixed up ;)
Ok that explains it. How about locally on gitX.kernel.org [would have to be real git repository]?
I'd want gitweb.cgi running on my local repository to use the local time of local merges to ensure
the problem I described at the start of this thread doesn't happen. Git reset --hard can be used
to fix mistakes and that wouldn't show?
> And in fact, even on the public machines, the "locally" would be different
> depending on things like mirroring delays
Yes, it should be different, everyone's local commit/merge order is not the same.
> So in theory, we could pick one particular public kernel.org machine, and
> use the times as _that_ machine sees it, but the fact is, that isn't how
> git works. No normal git command will ever show you such a senseless
> ordering.
Is local commit order really senseless? Using local commit order and/or the local time of local
merges would solve the problem I mentioned in the start of this thread? I don't think this info
has to be exported to CVS, a web interface to git and/or git itself should be able to tell us what
local time order and/or what local commit order merges were made in.
-Matt
____________________________________________________________________________________
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more.
http://mobile.yahoo.com/go?refer=1GNXIC
^ permalink raw reply
* Re: [GUILT PATCH 2/4] guilt-guard: Assign guards to patches in series
From: Josef Sipek @ 2007-07-30 4:06 UTC (permalink / raw)
To: Eric Lesh; +Cc: jsipek, git
In-Reply-To: <11856954181497-git-send-email-eclesh@ucla.edu>
On Sun, Jul 29, 2007 at 12:50:16AM -0700, Eric Lesh wrote:
> guilt-guard will assign guards to a patch. They work so that:
>
> * Patches with no guards are always pushed.
>
> * Patches with positive guards (i.e. +foo) are pushed *only if* the
> guard is selected.
>
> * Patches with negative guards (i.e. -foo) are pushed *unless* the
> guard is selected.
>
> Signed-off-by: Eric Lesh <eclesh@ucla.edu>
> ---
> Documentation/guilt-guards.txt | 40 +++++++++++++++++++++++++
> guilt | 58 ++++++++++++++++++++++++++++++++++++
> guilt-guards | 63 ++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 161 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/guilt-guards.txt
> create mode 100755 guilt-guards
>
> diff --git a/Documentation/guilt-guards.txt b/Documentation/guilt-guards.txt
> new file mode 100644
> index 0000000..f5ac537
> --- /dev/null
> +++ b/Documentation/guilt-guards.txt
> @@ -0,0 +1,40 @@
> +guilt-guards(1)
> +===============
> +
> +NAME
> +----
> +guilt-guards - Assign guards to patches
> +
> +SYNOPSIS
> +--------
> +include::usage-guilt-guards.txt[]
> +
> +DESCRIPTION
> +-----------
> +Assign guards to the specified patch, or to the patch on top of the
> +stack if no patch is given on the command line.
> +
> +An unguarded patch is always pushed.
> +
> +A positive guard begins with a +. A patch with a positive guard is
> +pushed *only if* the guard is selected.
> +
> +A negative guard begins with a -. A patch with a negative guard is
> +always pushed, *unless* the guard is selected.
> +
> +OPTIONS
> +-------
> +-l|--list::
> + List all patches and their guards
> +-n|--none::
> + Remove all guards from a patch
> +
> +Author
> +------
> +Written by Eric Lesh <eclesh@ucla.edu>
> +
> +Documentation
> +-------------
> +Documentation by Eric Lesh <eclesh@ucla.edu>
> +
> +include::footer.txt[]
> diff --git a/guilt b/guilt
> index 774909e..b2767ea 100755
> --- a/guilt
> +++ b/guilt
> @@ -182,6 +182,64 @@ get_series()
> grep -ve '^[[:space:]]*\(#.*\)*$' < "$series" | sed -e 's/[[:space:]]*#.*$//'
> }
>
> +get_guarded_series()
> +{
> + get_series | while read p
> + do
> + [ -z `check_guards $p` ] && echo "$p"
Having check_guards return 0 or 1 makes things cleaner:
check_guards "$p" && echo "$p"
> + done
> +}
> +
> +# usage: check_guards <patch>
> +# Returns t if the patch should be skipped
> +check_guards()
> +{
> + get_guards "$1" | while read guard
> + do
> + pos=`echo $guard | grep -e "^+"`
> + guard=`echo $guard | sed -e 's/[+-]//'`
> + if [ $pos ]; then
> + # Push +guard *only if* guard selected
> + push=`grep -e "^$guard\$" "$guards_file" > /dev/null; echo $?`
> + [ $push -ne 0 ] && echo t
[ $push -ne 0 ] && return 1
> + else
> + # Push -guard *unless* guard selected
> + push=`grep -e "^$guard\$" "$guards_file" > /dev/null; echo $?`
> + [ $push -eq 0 ] && echo t
ditto
> + fi
> + done
return 0
> +}
> +
> +# usage: get_guards <patch>
> +get_guards()
> +{
> + grep -e "^$1[[:space:]]*#" < "$series" | sed -e "s/^$1 //" -e 's/#[^+-]*//g'
> +}
> +
> +# usage: set_guards <patch> <guards>
I'd try to make it clearer that multiple guards can be specified.
> +set_guards()
> +{
> + p="$1"
> + shift
> + for x in "$@"; do
> + if [ -z $(echo "$x" | grep -e "^[+-]") ]; then
Is that the only restriction on the guard name?
> + echo "'$x' is not a valid guard name"
> + else
> + sed -i -e "s/^\($p[[:space:]]*.*\)$/\1 #$x/" "$series"
> + fi
> + done
> +}
> +
> +# usage: unset_guards <patch> <guards>
ditto.
> +unset_guards()
> +{
> + p="$1"
> + shift
> + for x in "$@"; do
> + sed -i -e "/^$p[[:space:]]/s/ #$x//" "$series"
> + done
> +}
> +
> # usage: do_make_header <hash>
> do_make_header()
> {
> diff --git a/guilt-guards b/guilt-guards
> new file mode 100755
> index 0000000..71df4f8
> --- /dev/null
> +++ b/guilt-guards
> @@ -0,0 +1,63 @@
> +#!/bin/sh
> +#
> +# Copyright (c) Eric Lesh, 2007
> +#
> +
> +USAGE="[-l|--list] [-n|--none] [<patchname>] [+<guard>] [-<guard>]"
Since -l and -n are mutually exclusive, shouldn't it be something like:
[-l|--list|-n|--none|[<patchname>] [(+|-)guard...]]
> +. guilt
> +
> +print_guards()
> +{
> + guards=`get_guards "$1"`
> + echo "$1: $guards"
> +}
> +
> +if [ "$1" == "-l" ] || [ "$1" == "--list" ]; then
> + get_series | while read patch; do
> + print_guards "$patch"
> + done
> + exit 0
> +elif [ "$1" == "-n" ] || [ "$1" == "--none" ]; then
> + patch="$2"
> + if [ -z "$patch" ]; then
> + patch=`get_top`
> + fi
> + unset_guards "$patch" `get_guards "$patch"`
> + exit 0
> +fi
> +
> +case $# in
> + 0)
> + if [ ! -s "$applied" ]; then
> + die "No patches applied."
> + fi
> + print_guards `get_top`
> + ;;
> + 1)
> + if [ -z $(echo $1 | grep -e '^[+-]') ]; then
> + if [ -z $(get_series | grep -e "^$1\$") ]; then
> + die "Patch $1 does not exist"
> + else
> + print_guards "$1"
> + fi
> + else
> + p=`get_top`
> + unset_guards "$p" `get_guards "$p"`
> + set_guards "$p" "$1"
> + fi
> + ;;
> + *)
> + if [ -z $(echo $1 | grep -e '^[+-]') ]; then
> + if [ -z $(get_series | grep -e "^$1\$") ]; then
> + die "Patch $1 does not exist"
> + else
> + patch="$1"
> + fi
> + shift
> + else
> + patch=`get_top`
> + fi
> + unset_guards "$patch" `get_guards "$patch"`
> + set_guards "$patch" "$@"
> + ;;
> +esac
> --
> 1.5.2
--
Note 96.3% of all statistics are fiction.
^ 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