* Re: [PATCH] Fix git-instaweb breakage on MacOS X due to the limited sed functionality
From: Charles Bailey @ 2007-12-19 11:53 UTC (permalink / raw)
To: git
In-Reply-To: <20071219114823.GA28273@hashpling.org>
git-instaweb relied on a pipe in a sed script, but this is not supported
by MacOS X sed when using BREs. git-instaweb relies on a working perl
in any case, and perl re are more consistent between platforms, so
replace sed invocation with an equivalent perl invocation.
Also, fix the documented -b "" to work without giving a spurious 'command
not found' error.
Signed-off-by: Charles Bailey <charles@hashpling.org>
---
Makefile | 1 +
git-instaweb.sh | 15 +++++++++------
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/Makefile b/Makefile
index 617e5f5..d6d3d65 100644
--- a/Makefile
+++ b/Makefile
@@ -880,6 +880,7 @@ git-instaweb: git-instaweb.sh gitweb/gitweb.cgi gitweb/gitweb.css
-e '/@@GITWEB_CGI@@/d' \
-e '/@@GITWEB_CSS@@/r gitweb/gitweb.css' \
-e '/@@GITWEB_CSS@@/d' \
+ -e 's|@@PERL@@|$(PERL_PATH_SQ)|g' \
$@.sh > $@+ && \
chmod +x $@+ && \
mv $@+ $@
diff --git a/git-instaweb.sh b/git-instaweb.sh
index 42d8d7f..9f86709 100755
--- a/git-instaweb.sh
+++ b/git-instaweb.sh
@@ -3,6 +3,7 @@
# Copyright (c) 2006 Eric Wong
#
+PERL='@@PERL@@'
OPTIONS_KEEPDASHDASH=
OPTIONS_SPEC="\
git-instaweb [options] (--start | --stop | --restart)
@@ -232,16 +233,18 @@ EOF
}
script='
-s#^\(my\|our\) $projectroot =.*#\1 $projectroot = "'$(dirname "$fqgitdir")'";#
-s#\(my\|our\) $gitbin =.*#\1 $gitbin = "'$GIT_EXEC_PATH'";#
-s#\(my\|our\) $projects_list =.*#\1 $projects_list = $projectroot;#
-s#\(my\|our\) $git_temp =.*#\1 $git_temp = "'$fqgitdir/gitweb/tmp'";#'
+s#^(my|our) \$projectroot =.*#$1 \$projectroot = "'$(dirname "$fqgitdir")'";#;
+s#(my|our) \$gitbin =.*#$1 \$gitbin = "'$GIT_EXEC_PATH'";#;
+s#(my|our) \$projects_list =.*#$1 \$projects_list = \$projectroot;#;
+s#(my|our) \$git_temp =.*#$1 \$git_temp = "'$fqgitdir/gitweb/tmp'";#;'
gitweb_cgi () {
cat > "$1.tmp" <<\EOFGITWEB
@@GITWEB_CGI@@
EOFGITWEB
- sed "$script" "$1.tmp" > "$1"
+ # The generated scripts assume that perl is /usr/bin/perl
+ # so the assumption here should be no more harmful
+ "$PERL" -p -e "$script" "$1.tmp" > "$1"
chmod +x "$1"
rm -f "$1.tmp"
}
@@ -273,4 +276,4 @@ esac
start_httpd
url=http://127.0.0.1:$port
-"$browser" $url || echo $url
+test -n "$browser" && "$browser" $url || echo $url
--
1.5.4.rc0
^ permalink raw reply related
* Re: [PATCH] Fix git-instaweb breakage on MacOS X due to the limited sed functionality
From: Wincent Colaiuta @ 2007-12-19 11:55 UTC (permalink / raw)
To: Charles Bailey; +Cc: git
In-Reply-To: <20071219114823.GA28273@hashpling.org>
El 19/12/2007, a las 12:48, Charles Bailey escribió:
> On Wed, Dec 19, 2007 at 12:43:12PM +0100, Wincent Colaiuta wrote:
>> El 19/12/2007, a las 12:36, Charles Bailey escribió:
>>
>>> I agree completely, but all the generated scripts output hard coded
>>> paths so it would seem inconsistent not to qualify the path in this
>>> case too.
>>
>> It's not hard-coded, it's dynamic. Witness:
>
> It's *output* hardcoded, it's dynamic during script generation.
Ah, ok. Seems like we were working with different definitions of "hard-
coded". When I said "hard-coded" I meant "determined by you and not
overrideable by the user doing the build without hand-editing the
source file".
> A raw 'perl' in a shell script is dynamic during script run.
Sure, and seeing as you're only doing a simple find/replace any
version of perl installed on the path is probably fine.
But if you are going to provide an absolute path then you should at
least make it user-configurable like all the other perl paths.
Cheers,
Wincent
^ permalink raw reply
* Re: git-stash: RFC: Adopt the default behavior to other commands
From: Johannes Schindelin @ 2007-12-19 12:01 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Wincent Colaiuta, Git Mailing List
In-Reply-To: <46a038f90712182346t5309448egebfd3726f4d493c5@mail.gmail.com>
Hi,
On Wed, 19 Dec 2007, Martin Langhoff wrote:
> On Dec 19, 2007 8:33 PM, Wincent Colaiuta <win@wincent.com> wrote:
> > El 19/12/2007, a las 0:41, Martin Langhoff escribi?:
> >
> > > On Dec 19, 2007 4:42 AM, J?rg Sommer <joerg@alea.gnuu.de> wrote:
> > >> I vote for stash print the list, because I dropped in the pitfall.
> > >
> > > I've dropped there myself, and work with a large team where we are
> > > both fans of stash, and scarred by it. Any newcomer to git that
> > > "discovers" stash gets hit by it a dozen times, this is completely
> > > unnecesary.
> >
> > I may be missing something here, but what's the danger here? An
>
> Surprise. Your working directory has *just* changed under your feet.
> Maybe you have an editor with further unsaved changes that is about to
> act confused whether you undo the stash or not.
The funny thing: why do you call stash with unsaved changes anyway? I
mean, come on, even if you were planning to see the usage of stash (which
you would get with -h), you undoubtedly wanted to either stash or unstash
some changes. Otherwise you would not _need_ to see the usage to begin
with.
> > unexpected stash is incredibly easy to revert, unless I'm missing
>
> Once you know about it, yes it is. Once you know about the reflog, you
> can sing and dance and never be worried. But for starting users, it's
> a dangerous command.
No.
Reflogs have nothing to do with it.
If you want to stash changes, you _got_ to know how to unstash those
changes. Otherwise "git reset --hard" would have been your friend.
And so, I cannot help but believe that all users of stash -- even the new
ones -- know about the fundamental concept of stashing/unstashing, and
therefore it is more something like this:
$ git stash
[no usage? What the heck... Oh, it stashed the changes. I did
not want to stash them just yet. Okay:]
$ git unstash
No such command
[Oh, maybe I should have read the man page. Oh, well, the usage
should do...]
$ git stash -h
...
Yes, if you start "git stash" blindly, believing that it does what "git
stash -h" does, you will be bitten by it once.
But as I said, you will be bitten by a plenty commands if you are not
familiar with the concept that "-h" shows the synopsis, "--help" the man
page, and that there is a default action where possible.
But stash really is about things like
$ git stash
$ git pull
$ git stash apply
I do not _want_ to see the stash list in _most_ cases, because I do not
stash away million dirty changes.
And that workflow was what "git stash" was designed for.
> > And nobody commented on the idea I posted earlier which seems to
> > address the concerns about newbies not knowing what "git stash" with
> > no params does:
>
> I agree with making stash more verbose -- if the unlucky new user is
> paying close attention, they'll have instructions on to how to get out
> of trouble. But I agree more with making it "just verbose, no action"
> by default. There are two strong hints:
>
> - all other state-changing commands take parameters
What about "git commit", "git reset", "git fetch"? These definitely
change state of the repository.
> - quite a few people in this list have gotten burned with it
Okay, let's have a little calculation: IIRC 3 people (let's make it 10, to
be conservative) have said that they had this problem. I must assume that
all other people did not have the problem, or at least saw why the default
action of "git stash" is what it is.
That said, if you _have_ to have the default changed, then I'll probably
implement a "git push" and "git pop" alias here, so that I cannot get
annoyed by stash's "new and improved" behaviour.
Ciao,
Dscho
^ permalink raw reply
* Re: git-stash: RFC: Adopt the default behavior to other commands
From: Wincent Colaiuta @ 2007-12-19 12:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Martin Langhoff, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0712191150240.23902@racer.site>
El 19/12/2007, a las 13:01, Johannes Schindelin escribió:
> But stash really is about things like
>
> $ git stash
> $ git pull
> $ git stash apply
>
> I do not _want_ to see the stash list in _most_ cases, because I do
> not
> stash away million dirty changes.
>
> And that workflow was what "git stash" was designed for.
+1.
Wincent
^ permalink raw reply
* Re: git with custom diff for commits
From: Johannes Schindelin @ 2007-12-19 12:09 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Gerald Gutierrez, 'Junio C Hamano', git
In-Reply-To: <vpqtzmfvz1d.fsf@bauges.imag.fr>
Hi,
On Wed, 19 Dec 2007, Matthieu Moy wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> Here's what the git-commit manpage on kernel.org says: "git-commit -
> >> Record changes to the repository".
> >
> > Yes. Changes, as in "take this _file_ instead". Not "edit this file,
> > remove those lines, add these here, etc.".
>
> That said, I think the wording of the man page could be better.
> Perhaps "Record new snapshot to the repository" or "Record current
> state of the working tree to the repository".
How about "record a new revision"?
Ciao,
Dscho
^ permalink raw reply
* Re: kha/safe and kha/experimental updated
From: Karl Hasselström @ 2007-12-19 12:10 UTC (permalink / raw)
To: Catalin Marinas; +Cc: David Kågedal, git
In-Reply-To: <b0943d9e0712190340p23341dd8lb9ebbbce9b29cb8e@mail.gmail.com>
On 2007-12-19 11:40:41 +0000, Catalin Marinas wrote:
> On 19/12/2007, Karl Hasselström <kha@treskal.com> wrote:
>
> > On 2007-12-19 10:09:40 +0000, Catalin Marinas wrote:
> >
> > > For the 'status --reset', I'll keep it if we have a separate
> > > 'resolved' command.
> >
> > ?
>
> It needs to call the resolved_all to remove checked-out stages if
> stgit.keeporig == 'yes'.
Ah, right.
> Maybe it could also do some sanity check if HEAD != top. With 'git
> reset --hard', people might easily add an argument and break the
> whole stack.
True.
> > Hmm? Have we started to use more porcelain lately?
>
> I think Yann was complaining about using git-show since it looks
> more like a porcelain command.
We should probably use cat-file or something instead.
> > It wouldn't keep being the latest git version, though.
>
> Yes, but at least initially it should be pretty recent.
:-)
> > I don't use interactive merging at all. What I wanted was to get
> > rid of StGit's own interactive merging.
>
> I use it quite often and I even invoke it automatically
> (stgit.autoimerge). I'll push some patches tonight together with
> most of your safe branch and we can alter them afterwards.
Jolly good! My stack was getting unwieldy ...
> > So you want StGit to do two things: patch stacks, and fix some git
> > UI warts. Hey, I can live with that. :-) But I firmly believe that
> > the wart fixing parts of StGit should be (1) optional, so that the
> > same job can easily be done with just git; and (2) as thin as
> > possible, to make them easy to explain in terms of git, and cheap
> > to maintain.
>
> Unless you need the keeporig functionality, you can now always use
> plain git for solving merges, add/rm/cp, 'reset --hard' etc.
Yes, with David's conflict series.
> At some point, we could make it safe for 'git rebase' but I think we
> need the DAG patches.
I wouldn't resurrect the DAG patches for this; I'd just invoke "stg
repair" automatically when we detect that top != HEAD.
But I think that for "git rebase", we'd want to teach "repair" to
detect that the patches' commits have been changed, rather than just
marking them unapplied.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: git with custom diff for commits
From: Matthieu Moy @ 2007-12-19 12:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Gerald Gutierrez, 'Junio C Hamano', git
In-Reply-To: <Pine.LNX.4.64.0712191209140.23902@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Wed, 19 Dec 2007, Matthieu Moy wrote:
>
>> That said, I think the wording of the man page could be better.
>> Perhaps "Record new snapshot to the repository" or "Record current
>> state of the working tree to the repository".
>
> How about "record a new revision"?
Sounds good, yes.
--
Matthieu
^ permalink raw reply
* Re: [PATCH 2/2] Catch and handle git-commit failures in git-rebase --interactive
From: Johannes Schindelin @ 2007-12-19 12:21 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20071219064500.GB8915@spearce.org>
Hi,
On Wed, 19 Dec 2007, Shawn O. Pearce wrote:
> This has also bitten me a few times. :-\
Sorry to hear that. Both patches look sensible to me.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Fix git-instaweb breakage on MacOS X due to the limited sed functionality
From: Charles Bailey @ 2007-12-19 12:23 UTC (permalink / raw)
To: git
In-Reply-To: <20071219115319.GA29184@hashpling.org>
Now that I think about it, this replacement patch has invalidated the
original comment to some extent. A replacement patch follows, with a
more consistent comment.
Charles.
^ permalink raw reply
* [PATCH] Fix git-instaweb breakage on MacOS X due to the limited sed functionality
From: Charles Bailey @ 2007-12-19 12:25 UTC (permalink / raw)
To: git
In-Reply-To: <20071219122308.GA32088@hashpling.org>
git-instaweb relied on a pipe in a sed script, but this is not supported
by MacOS X sed when using BREs. git-instaweb relies on a working perl
in any case, and perl re are more consistent between platforms, so
replace sed invocation with an equivalent perl invocation.
Also, fix the documented -b "" to work without giving a spurious 'command
not found' error.
Signed-off-by: Charles Bailey <charles@hashpling.org>
---
Makefile | 1 +
git-instaweb.sh | 15 +++++++++------
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/Makefile b/Makefile
index 617e5f5..d6d3d65 100644
--- a/Makefile
+++ b/Makefile
@@ -880,6 +880,7 @@ git-instaweb: git-instaweb.sh gitweb/gitweb.cgi gitweb/gitweb.css
-e '/@@GITWEB_CGI@@/d' \
-e '/@@GITWEB_CSS@@/r gitweb/gitweb.css' \
-e '/@@GITWEB_CSS@@/d' \
+ -e 's|@@PERL@@|$(PERL_PATH_SQ)|g' \
$@.sh > $@+ && \
chmod +x $@+ && \
mv $@+ $@
diff --git a/git-instaweb.sh b/git-instaweb.sh
index 42d8d7f..ad0723c 100755
--- a/git-instaweb.sh
+++ b/git-instaweb.sh
@@ -3,6 +3,7 @@
# Copyright (c) 2006 Eric Wong
#
+PERL='@@PERL@@'
OPTIONS_KEEPDASHDASH=
OPTIONS_SPEC="\
git-instaweb [options] (--start | --stop | --restart)
@@ -232,16 +233,18 @@ EOF
}
script='
-s#^\(my\|our\) $projectroot =.*#\1 $projectroot = "'$(dirname "$fqgitdir")'";#
-s#\(my\|our\) $gitbin =.*#\1 $gitbin = "'$GIT_EXEC_PATH'";#
-s#\(my\|our\) $projects_list =.*#\1 $projects_list = $projectroot;#
-s#\(my\|our\) $git_temp =.*#\1 $git_temp = "'$fqgitdir/gitweb/tmp'";#'
+s#^(my|our) \$projectroot =.*#$1 \$projectroot = "'$(dirname "$fqgitdir")'";#;
+s#(my|our) \$gitbin =.*#$1 \$gitbin = "'$GIT_EXEC_PATH'";#;
+s#(my|our) \$projects_list =.*#$1 \$projects_list = \$projectroot;#;
+s#(my|our) \$git_temp =.*#$1 \$git_temp = "'$fqgitdir/gitweb/tmp'";#;'
gitweb_cgi () {
cat > "$1.tmp" <<\EOFGITWEB
@@GITWEB_CGI@@
EOFGITWEB
- sed "$script" "$1.tmp" > "$1"
+ # Use the configured full path to perl to match the generated
+ # scripts' 'hashpling' line
+ "$PERL" -p -e "$script" "$1.tmp" > "$1"
chmod +x "$1"
rm -f "$1.tmp"
}
@@ -273,4 +276,4 @@ esac
start_httpd
url=http://127.0.0.1:$port
-"$browser" $url || echo $url
+test -n "$browser" && "$browser" $url || echo $url
--
1.5.4.rc0
--
Charles Bailey
http://ccgi.hashpling.plus.com/blog/
^ permalink raw reply related
* [PATCH v0] sha1_name: grok <revision>:./<relative-path>
From: Johannes Schindelin @ 2007-12-19 13:40 UTC (permalink / raw)
To: Dana How; +Cc: Linus Torvalds, Alex Riesen, Jakub Narebski, git
In-Reply-To: <56b7f5510712181752s7ecebca9m32794c635cba9fd@mail.gmail.com>
When you are in a deeply-nested directory structure, and just want
to reference a blob in a past revision, it can be pretty slow to
type out "HEAD~29:/bla/blub/.../that-file".
This patch makes "HEAD~29:./that-file" substitute the current prefix
for "./". If there is not working directory, the prefix is empty.
Note that this patch does not handle "../", and neither do I plan to.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Tue, 18 Dec 2007, Dana How wrote:
> On Dec 18, 2007 5:16 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> > On Tue, 18 Dec 2007, Dana How wrote:
> >
> > > The cases we are talking about are all subtrees of the
> > > working tree. There is a useful cwd suffix.
> >
> > No.
> >
> > The cases we're talking of are *not* subtrees of the working
> > tree.
> >
> > The SHA1 of a commit may well be a totally disjoint tree. Try
> > it in the git repository with something like
>
> Agreed, but note you wrote *may*.
Okay, this is a proposed patch. It leaves the existing
"HEAD:<path>" handling alone, and only touches "HEAD:./<path>",
which would have been invalid anyway (except if you hacked your
objects database to include a tree named ".").
Note: this patch is not meant for application directly. It should
be split into get_current_prefix() as one patch, and the
sha1_name.c stuff as the second. (Not only to boost my ohloh
statistics, but because they are logically two separate things.)
Note, too: this is a quick and little-bit-dirty patch, not well
tested. Particularly, I was unable to trigger the "No <path> in
<rev>" error path, so I am not confident that this handling is
correct.
Note also: in contrast to Alex' approach, this will not only work
for git-show, but for all callers of get_sha1().
cache.h | 1 +
setup.c | 16 +++++++++++++---
sha1_name.c | 17 ++++++++++++++---
3 files changed, 28 insertions(+), 6 deletions(-)
diff --git a/cache.h b/cache.h
index 39331c2..83a2c31 100644
--- a/cache.h
+++ b/cache.h
@@ -225,6 +225,7 @@ extern char *get_index_file(void);
extern char *get_graft_file(void);
extern int set_git_dir(const char *path);
extern const char *get_git_work_tree(void);
+extern const char *get_current_prefix(void);
#define ALTERNATE_DB_ENVIRONMENT "GIT_ALTERNATE_OBJECT_DIRECTORIES"
diff --git a/setup.c b/setup.c
index b59dbe7..fb9b680 100644
--- a/setup.c
+++ b/setup.c
@@ -3,6 +3,12 @@
static int inside_git_dir = -1;
static int inside_work_tree = -1;
+static const char *current_prefix;
+
+const char *get_current_prefix()
+{
+ return current_prefix;
+}
const char *prefix_path(const char *prefix, int len, const char *path)
{
@@ -267,6 +273,7 @@ const char *setup_git_directory_gently(int *nongit_ok)
/* config may override worktree */
if (check_repository_format_gently(nongit_ok))
return NULL;
+ current_prefix = retval;
return retval;
}
if (check_repository_format_gently(nongit_ok))
@@ -279,7 +286,8 @@ const char *setup_git_directory_gently(int *nongit_ok)
if (chdir(work_tree_env) < 0)
die ("Could not chdir to %s", work_tree_env);
strcat(buffer, "/");
- return retval;
+ current_prefix = retval;
+ return current_prefix;
}
if (nongit_ok) {
*nongit_ok = 1;
@@ -339,7 +347,8 @@ const char *setup_git_directory_gently(int *nongit_ok)
offset++;
cwd[len++] = '/';
cwd[len] = 0;
- return cwd + offset;
+ current_prefix = cwd + offset;
+ return current_prefix;
}
int git_config_perm(const char *var, const char *value)
@@ -396,7 +405,8 @@ const char *setup_git_directory(void)
if (retval && chdir(retval))
die ("Could not jump back into original cwd");
rel = get_relative_cwd(buffer, PATH_MAX, get_git_work_tree());
- return rel && *rel ? strcat(rel, "/") : NULL;
+ current_prefix = rel && *rel ? strcat(rel, "/") : NULL;
+ return current_prefix;
}
return retval;
diff --git a/sha1_name.c b/sha1_name.c
index 13e1164..6f61d26 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -712,9 +712,20 @@ 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)) {
+ const char *prefix;
+ if (!prefixcmp(cp + 1, "./") &&
+ (prefix = get_current_prefix())) {
+ unsigned char subtree_sha1[20];
+ if (get_tree_entry(tree_sha1, prefix,
+ subtree_sha1, mode))
+ return error("No '%s' in '%.*s'",
+ prefix, cp-name, name);
+ memcpy(tree_sha1, subtree_sha1, 20);
+ cp += 2;
+ }
+ return get_tree_entry(tree_sha1, cp+1, sha1, mode);
+ }
}
return ret;
}
--
1.5.4.rc0.72.g536e9
^ permalink raw reply related
* Re: [PATCH 4/5] atmel_serial: Split the interrupt handler
From: Haavard Skinnemoen @ 2007-12-19 14:07 UTC (permalink / raw)
To: git
Cc: Chip Coldwell, linux, kernel, linux-kernel, linux-arm-kernel,
Bohmer, Andrew Victor
In-Reply-To: <20071219124008.4945e592@dhcp-252-066.norway.atmel.com>
On Wed, 19 Dec 2007 12:40:08 +0100
Haavard Skinnemoen <hskinnemoen@atmel.com> wrote:
> Btw, the funny thing is that, looking at my shell history, I think I
> actually did the right thing when committing your patches:
>
> git commit -s --author 'Remy Bohmer <linux@bohmer.net>'
> git commit -s --author 'Chip Coldwell <coldwell@frank.harvard.edu>'
>
> But for some reason only your names stuck, not your e-mail addresses...
It just happened again. Seems like if git-rebase hits a conflict, and I
just do "git-rebase --continue" after resolving it (and updating the
index), the original author's name is used, but not his e-mail address.
Looks like a bug in git-rebase...?
Haavard
^ permalink raw reply
* Re: bug with .gitattributes diff and embedded NUL
From: Eric Blake @ 2007-12-19 14:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vve6vw5kg.fsf@gitster.siamese.dyndns.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
According to Junio C Hamano on 12/18/2007 11:40 PM:
> Eric Blake <ebb9@byu.net> writes:
>
>> Looking closer at .dotest/0001, the diff is indeed invalid, containing the
>> single line
>
> That dataflow loses NUL. Fixing
> rebase not to reuse the e-mailed patch dataflow is on my to-do list, but
> has been slipping.
>
> I think you can use "rebase -m" to work this issue around.
Indeed, after learning about git-rebase -m and git-mergetool, adding the
merge option alongside the diff option for the file in question, and
teaching emacs that it should use emerge-diff-options "-a" so that it can
handle embedded NUL, I was finally able to use git-mergetool to do a sane
merge of the differences in the mostly-text file. Thanks!
But it raised some additional issues:
Is there a way to specify custom merge tools, rather than the current
hard-coded list valid for merge.tool? For example, what if I prefer
emacs' ediff driver over its emerge driver?
Using merge.tool of emerge leaves junk around when the merge is aborted.
Before I edited emacs' emerge-diff-options, the subsidiary diff3 was
failing because it treated the file to merge as binary even though git was
trying to treat it as text. As a result, emerge left behind all of its
command-line argument files (file.{BASE,LOCAL,REMOTE}.pid), and git did
not clean any of them up.
- --
Don't work too hard, make some time for fun as well!
Eric Blake ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHaShk84KuGfSFAYARAkDtAJ0XhhhbeJZJS6td3/aeOlxd7iuoawCgiVY6
3s+aMxRO1vjKf/EqncKW2jE=
=GrcF
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] Re-re-re-fix common tail optimization
From: Charles Bailey @ 2007-12-19 14:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Linus Torvalds, git
In-Reply-To: <7v3au2joo2.fsf_-_@gitster.siamese.dyndns.org>
On Sun, Dec 16, 2007 at 01:49:17PM -0800, Junio C Hamano wrote:
>
> Kind'a embarrassing that both of us cannot get this right without so
> many rounds, isn't it?
>
> -- >8 --
> Subject: [PATCH] Re-re-re-fix common tail optimization
>
> We need to be extra careful recovering the removed common section, so
> that we do not break context nor the changed incomplete line (i.e. the
> last line that does not end with LF).
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Just to add to the woe on this one, this test breaks on MacOS X due to
the pattern length limitations of the default sed on that platform.
Interested in a patch?
Charles.
^ permalink raw reply
* Re: [PATCH] Re-re-re-fix common tail optimization
From: Jeff King @ 2007-12-19 14:27 UTC (permalink / raw)
To: Charles Bailey; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <20071219141845.GA2146@hashpling.org>
On Wed, Dec 19, 2007 at 02:18:45PM +0000, Charles Bailey wrote:
> Just to add to the woe on this one, this test breaks on MacOS X due to
> the pattern length limitations of the default sed on that platform.
>
> Interested in a patch?
Somebody beat you to it. :) Can you confirm that the fix in
<1198007158-27576-1-git-send-email-win@wincent.com>
works for you?
-Peff
^ permalink raw reply
* Serious bug with pretty format strings & empty bodies?
From: Jonathan del Strother @ 2007-12-19 14:32 UTC (permalink / raw)
To: git
I'm struggling to come up with a minimal test case that confirms this,
but I seem to be hitting a bug in the pretty string formatter when
trying to print bodies of commits that don't have bodies.
For example, on a private repository, I'm trying to print the subject
& body of a commit. This particular commit doesn't actually have a
body, so I'm expecting to see this output :
=================
commit 18d2480ab689b483ef1ebbdb3f7420904049ba0b
Try to flush log files before terminating the app
=================
However, when I actually run the command, I get gibberish in place of %b :
=================
$ git rev-list -1- --pretty=format:"%s%n%b"
18d2480ab689b483ef1ebbdb3f7420904049ba0b
commit 18d2480ab689b483ef1ebbdb3f7420904049ba0b
Try to flush log files before terminating the app
tree 57bc7cf30a10aee96251852125cf30fd2c81d7aa
parent 04c833865828538315fcdf6e187da077869ce444
author Jonathan del Strother <jon.delStrother@bestbefore.tv> 1197901755 +0000
committer Jonathan del Strother <jon.delStrother@bestbefore.tv> 1197901755 +0000
Check that ThreadWorker's work method actually returns a value with
method signatures
=================
So here you can see that the full details of a different commit is
appearing in place of the requested commit's (empty) body. Rerunning
the rev-list produces the same output - the same string appears in
place of %b every time, but it's different for each commit. Often you
only get a small fragment of another commit's message, rather than the
full commit as seen above.
When I use --pretty=full, it works fine.
This appears in quite a few places in my repository's history.
Repacking the repo semi-fixes it - I still get junk bodies, but not
quite so many.
It doesn't always happen when a commit message body is empty, but I've
never seen it happen where the message body has something in.
This happens with both git 1.5.3.7 and 1.5.4.rc0.1162.g3bfea, though
the output is slightly different - the former has a number of
<unknown> markers in it. This is on OS X 10.5.1
Any suggestions?
Cheers,
Jon
^ permalink raw reply
* Re: [PATCH] Use pathexpand to preparse the relative pathnames in blob references
From: Jeff King @ 2007-12-19 14:37 UTC (permalink / raw)
To: Alex Riesen
Cc: Jakub Narebski, git, Junio C Hamano, Johannes Schindelin,
Linus Torvalds
In-Reply-To: <20071218205253.GF2875@steel.home>
On Tue, Dec 18, 2007 at 09:52:53PM +0100, Alex Riesen wrote:
> This, OTOH, is a bit intrusive and changes the current behaviour a bit
> too far. git-show cannot use the absolute pathnames in blob locators
> at all now, which I consider bad. An obvious way to use rev:/path is
> blocked by Johannes' get_sha1_oneline. It would have worked, though.
IMO, this is backwards. The default should be absolute naming (after
all, you have already rooted it at a tree by saying HEAD:), and you
should treat '.' as a short-hand for "my current prefix". IOW, this
works as before:
cd t && git show HEAD:t/test-lib.sh
but this would now work:
cd t && git show HEAD:./test-lib.sh
and of course supporting '..' could be added, as well.
This works under the assumption that you don't have tree entries of '.'
or '..'; I don't think the data structure enforces any such assumption,
but I doubt you could easily create such a tree without hacking the git
tools (and you would have to be insane to do so anyway).
-Peff
PS I didn't just think of this...I'm pretty sure this discussion came up
sometime in the past year and somebody more clever than I thought of it.
^ permalink raw reply
* Re: [PATCH] Re-re-re-fix common tail optimization
From: Charles Bailey @ 2007-12-19 14:37 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <20071219142715.GB14187@coredump.intra.peff.net>
On Wed, Dec 19, 2007 at 09:27:15AM -0500, Jeff King wrote:
> On Wed, Dec 19, 2007 at 02:18:45PM +0000, Charles Bailey wrote:
>
> > Just to add to the woe on this one, this test breaks on MacOS X due to
> > the pattern length limitations of the default sed on that platform.
> >
> > Interested in a patch?
>
> Somebody beat you to it. :) Can you confirm that the fix in
>
> <1198007158-27576-1-git-send-email-win@wincent.com>
>
> works for you?
>
> -Peff
Ooh, the excitement, I've never had the opportunity to "git am"
before.
Yes, I can confirm. It works for me.
For reference I had the following, which is fewer lines but not
inherently better in any other way.
Charles.
diff --git a/t/t4024-diff-optimize-common.sh b/t/t4024-diff-optimize-common.sh
index 20fe87b..ffb2c8f 100755
--- a/t/t4024-diff-optimize-common.sh
+++ b/t/t4024-diff-optimize-common.sh
@@ -7,8 +7,9 @@ test_description='common tail optimization'
z=zzzzzzzz ;# 8
z="$z$z$z$z$z$z$z$z" ;# 64
z="$z$z$z$z$z$z$z$z" ;# 512
-z="$z$z$z$z" ;# 2048
-z2047=$(expr "$z" : '.\(.*\)') ; #2047
+z="$z$z" ;# 1024
+z1023=$(expr "$z" : '.\(.*\)') ; #1023
+z2047=$z$z1023
test_expect_success setup '
@@ -35,8 +36,8 @@ diff --git a/file-a b/file-a
--- a/file-a
+++ b/file-a
@@ -1 +1 @@
--aZ
-+AZ
+-aZZz
++AZZz
diff --git a/file-b b/file-b
--- a/file-b
+++ b/file-b
@@ -47,9 +48,9 @@ diff --git a/file-c b/file-c
--- a/file-c
+++ b/file-c
@@ -1 +1 @@
--cZ
+-cZZz
\ No newline at end of file
-+CZ
++CZZz
\ No newline at end of file
diff --git a/file-d b/file-d
--- a/file-d
@@ -61,7 +62,7 @@ EOF
test_expect_success 'diff -U0' '
- git diff -U0 | sed -e "/^index/d" -e "s/$z2047/Z/g" >actual &&
+ git diff -U0 | sed -e "/^index/d" -e "s/$z1023/Z/g" >actual &&
diff -u expect actual
'
--
1.5.3.7.11.ga3d7
^ permalink raw reply related
* Re: kha/safe and kha/experimental updated
From: Catalin Marinas @ 2007-12-19 14:59 UTC (permalink / raw)
To: Karl Hasselström; +Cc: David Kågedal, git
In-Reply-To: <20071218052115.GA13422@diana.vm.bytemark.co.uk>
On 18/12/2007, Karl Hasselström <kha@treskal.com> wrote:
> git://repo.or.cz/stgit/kha.git safe
[...]
> Ask git about unmerged files
This patch wrongly assumes that there is a stage 2 entry in the index.
Test t1202-push-undo.sh fails because a file is added, differently, in
both master and patch but it doesn't exist in ancestor (no stage 2).
Using stage 3 doesn't fix it either because a patch might remove a
file.
I fixed it by using a set to get the unique names.
--
Catalin
^ permalink raw reply
* Re: [PATCH v0] sha1_name: grok <revision>:./<relative-path>
From: Jeff King @ 2007-12-19 15:05 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Dana How, Linus Torvalds, Alex Riesen, Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0712191334460.23902@racer.site>
On Wed, Dec 19, 2007 at 01:40:27PM +0000, Johannes Schindelin wrote:
> When you are in a deeply-nested directory structure, and just want
> to reference a blob in a past revision, it can be pretty slow to
> type out "HEAD~29:/bla/blub/.../that-file".
>
> This patch makes "HEAD~29:./that-file" substitute the current prefix
> for "./". If there is not working directory, the prefix is empty.
>
> Note that this patch does not handle "../", and neither do I plan to.
I think this is definitely the right approach. Here's a (possibly
insane) alternative. Revert the change in get_sha1_with_mode and detect
"./" in get_tree_entry:
diff --git a/tree-walk.c b/tree-walk.c
index 8d4b673..fc54354 100644
--- a/tree-walk.c
+++ b/tree-walk.c
@@ -191,6 +191,7 @@ int get_tree_entry(const unsigned char *tree_sha1, const char *name, unsigned ch
unsigned long size;
struct tree_desc t;
unsigned char root[20];
+ const char *prefix;
tree = read_object_with_reference(tree_sha1, tree_type, &size, root);
if (!tree)
@@ -202,7 +203,11 @@ int get_tree_entry(const unsigned char *tree_sha1, const char *name, unsigned ch
}
init_tree_desc(&t, tree, size);
- retval = find_tree_entry(&t, name, sha1, mode);
+ if (!prefixcmp(name, "./") && (prefix = get_current_prefix()))
+ retval = find_tree_entry(&t, mkpath("%s%s", prefix, name + 2),
+ sha1, mode);
+ else
+ retval = find_tree_entry(&t, name, sha1, mode);
free(tree);
return retval;
}
This means that the directory '.' becomes a token replacement for "my
current path" in tree paths. So if you are in "foo/bar", and you are
looking at a distance commit where the same content was in
"baz/foo/bar", you can do:
git show distant:baz/./file
This is probably insane because:
- this is a fairly unlikely use case
- get_tree_entry gets called in a lot of places, and I have no idea if
there will be some crazy fallouts.
So it is probably not worth pursuing, but maybe somebody else can think
of a good use.
-Peff
^ permalink raw reply related
* Re: kha/safe and kha/experimental updated
From: Catalin Marinas @ 2007-12-19 15:38 UTC (permalink / raw)
To: Karl Hasselström; +Cc: David Kågedal, git
In-Reply-To: <b0943d9e0712180809l4d2d01b8j32ab2a410885cc5e@mail.gmail.com>
On 18/12/2007, Catalin Marinas <catalin.marinas@gmail.com> wrote:
> On 18/12/2007, Karl Hasselström <kha@treskal.com> wrote:
> > Fix "stg resolved" to work with new conflict representation
>
> For some reason, the interactive resolving keeps invoking the merger.
> I'll have a look.
I found the problem. git.ls_files() now returns all three stages if
there was a conflict and the file list got longer. I added a set to
remove the duplicates.
--
Catalin
^ permalink raw reply
* Re: kha/safe and kha/experimental updated
From: David Kågedal @ 2007-12-19 15:39 UTC (permalink / raw)
To: Karl Hasselström, Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0712190659p6c4cb557jae5b21aa68de029d@mail.gmail.com>
"Catalin Marinas" <catalin.marinas@gmail.com> writes:
> On 18/12/2007, Karl Hasselström <kha@treskal.com> wrote:
>> git://repo.or.cz/stgit/kha.git safe
> [...]
>> Ask git about unmerged files
>
> This patch wrongly assumes that there is a stage 2 entry in the index.
> Test t1202-push-undo.sh fails because a file is added, differently, in
> both master and patch but it doesn't exist in ancestor (no stage 2).
> Using stage 3 doesn't fix it either because a patch might remove a
> file.
>
> I fixed it by using a set to get the unique names.
That sounds reasonable.
--
David Kågedal
^ permalink raw reply
* Re: [PATCH] clone: fix options '-o' and '--origin' to be recognised again
From: Jeff King @ 2007-12-19 15:43 UTC (permalink / raw)
To: Junio C Hamano
Cc: Marco Roeland, git, Pierre Habouzit, Kristian Høgsberg
In-Reply-To: <20071219091515.GA20707@fiberbit.xs4all.nl>
On Wed, Dec 19, 2007 at 10:15:15AM +0100, Marco Roeland wrote:
> This is a regression in 'next', introduced on Nov 4th by commit 94362599
> "Migrate git-clone to use git-rev-parse --parseopt". Added Kristian as
> he works on the builtin version; perhaps nice for a test case (!).
Here is a test case that catches this regression. It can perhaps be
expanded by Kristian to test other options, but is probably worth adding
now as a basic sanity check.
I put the test in 5702. There seems to be a '5600' clone test, as well,
which perhaps should be in the 57?? series.
-- >8 --
test "git clone -o"
This tests a recently fixed regression in which "git clone
-o" didn't work at all.
Signed-off-by: Jeff King <peff@peff.net>
---
t/t5702-clone-options.sh | 22 ++++++++++++++++++++++
1 files changed, 22 insertions(+), 0 deletions(-)
create mode 100755 t/t5702-clone-options.sh
diff --git a/t/t5702-clone-options.sh b/t/t5702-clone-options.sh
new file mode 100755
index 0000000..328e4d9
--- /dev/null
+++ b/t/t5702-clone-options.sh
@@ -0,0 +1,22 @@
+#!/bin/sh
+
+test_description='basic clone options'
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+
+ mkdir parent &&
+ (cd parent && git init &&
+ echo one >file && git add file &&
+ git commit -m one)
+
+'
+
+test_expect_success 'clone -o' '
+
+ git clone -o foo parent clone-o &&
+ (cd clone-o && git rev-parse --verify refs/remotes/foo/master)
+
+'
+
+test_done
--
1.5.4.rc0.1162.gaa83ae
^ permalink raw reply related
* Re: kha/safe and kha/experimental updated
From: Jakub Narebski @ 2007-12-19 16:23 UTC (permalink / raw)
To: Karl Hasselström
Cc: Catalin Marinas, David Kågedal, git, Theodore Ts'o
In-Reply-To: <20071219114021.GB5565@diana.vm.bytemark.co.uk>
Karl Hasselström wrote:
> On 2007-12-19 11:44:57 +0100, Jakub Narebski wrote:
>> On Wed, 19 Dec 2007, Karl Hasselström wrote:
>>> On 2007-12-18 08:39:52 -0800, Jakub Narebski wrote:
>>>
>>>> I also would like to have this command kept (and shown in 'stg
>>>> help'!). Contrary to 'git add' it can check and add to index /
>>>> update index only for files with conflict; we have -r
>>>> (ancestor|current|patched) to choose one side, and we could add
>>>> --check to check if there are no conflict markers with files
>>>> (useful with -a/--all).
>>>
>>> This too sounds like stuff that could profitably be added to "git
>>> add". Except for the ancestor/current/patched words, it is not
>>> specific to patch stacks, so the implementation should be in git
>>> and not in stg.
>>
>> No it cannot, at least the '-r (ancestor|current|patched)' part for
>> resetting file to given version, even if we change the wording to
>> ancestor, ours and theirs. The git-add command is about adding
>> contents, which updates index, which almost as a intended
>> side-effect clears merge state, i.e. stages; and not about resetting
>> to stage.
>
> git checkout-index --stage=1|2|3 <filename>
>
> does what you want. But "git cat-file" knows this handy syntax for
> getting at particular index stages:
>
> :stage:<filename>
I always forget which stage is which. It would be nice if
git-checkout-index implemented human-friendly names, just like
git-diff-files has --base, --ours, --theirs, i.e. if it would be
possible to write
git checkout-index --stage=base|ours|theirs <filename>
and perhaps even
:base|ours|theirs:<filename>.
(but there is a problem with files containing ':'...).
> It would be very convenient to be able to do
>
> git checkout :stage:<filename>
>
> but it doesn't seem to work currently. Does anyone know the "best" way
> of manually checking out a particular index stage in git?
It's a pity it doesn't work. Or if not this, then perhaps
git checkout --stage=ours -- <filename>
>> Besides with "stg resolved" you can update index _only_ for files
>> which were in the conflict, also for -a/--all, and not all the files
>> not only those which were in the conflict like "git add -u" does.
>
> This sounds like a straightforward addition to "git add".
>
>> "stg resolved --check" could happily ignore things that only look
>> like conflict markers, but must have been intended, because they are
>> in files not in conflict.
>
> git knows about conflicting files too.
>
>> Unless you are talking about adding "resolve"/"resolved" command to
>> git-core, as a porcelain wrapper around git-update-index, like "git
>> add"...
>
> Yes, that's what I want. You and others like what "stg resolved" does,
> but I don't want it in StGit because it's a generic git enhancement
> that has nothing to with patch stacks. People who don't use StGit
> would presumably like it as well.
You mean adding another option to git-add, similar to '-u' option, but
updating only the files which were (are) in merge conflict;
'-c'/'-r'/'-s' perhaps? This would be replacement for
"stg resolved --all", wouldn't it (and with filename replacement for
"stg resolved <filename>", of course)?
P.S. Sidenote: it would be nice if git-mergetool was updated to
understand StGIT style interactive 2-way and 3-way merge configuration,
and not offer only limited choice of pre-defined interactive merge tools
(although pre-defined are nice, too).
--
Jakub Narebski
Poland
^ permalink raw reply
* git-svn and migration
From: Nigel Magnay @ 2007-12-19 16:50 UTC (permalink / raw)
To: git
In-Reply-To: <320075ff0712190849u2c40cc46pf01fa2a75f557482@mail.gmail.com>
Hi there!
I've been playing around with git for a while, read the guides to
git-svn and have been successfully using it on my own to track an
upstream svn repository.
Eventually, I'd like us all to switch to git, throw out the svn
server, and replace it with a git repository that can be pushed to,
where commits that pass tests get merged into the master.
But - that's not going to happen overnight. The most likely next steps
are going to be something like migrating a couple of other developers
onto git to test the water, but in the interim most people will still
be on svn.
Has anyone got any tips as I'm sure it's a path trodden before? I've
seen examples of keeping a read-only svn, but that's not really what
I'm after. I'm considering whether to have a central git repo
regularly pull from svn so that it's up to date, and having us
possibly push to svn (or git if it's not merged to trunk) as an
interim step..
Nigel
^ 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