* Re: Problem with Linus's git repository?
From: walt @ 2007-06-28 13:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.98.0706270932040.8675@woody.linux-foundation.org>
On Wed, 27 Jun 2007, Linus Torvalds wrote:
>
>
> On Wed, 27 Jun 2007, walt wrote:
> > >
> > > It's not missing, it's packed. I tend to re-pack after I make a release,
> > > and this time I did it after -rc6...
> >
> > Sometime overnight this problem disappeared. I haven't actually
> > tested this idea, but I have a hunch that your commit yesterday
> > of "Fix zero-object version-2 packs" is the reason.
>
> No, I think the reason is simply that I pushed more updates to kernel.org,
> so now the kernel git repo has an explicit and separate "master" branch
> again.
>
> What is your git version? The _real_ fix probably is to just upgrade. Are
> you using that broken(*) Debian git package by any chance?
No, every morning I pull from you and Junio and Petr Baudis using cg-update,
so I'm very much current. I notice that cg-update specifically does an
http GET on kernel/git/torvalds/linux-2.6.git/HEAD which is actually a
symlink to your refs/heads/master. Your 'master' now exists, but didn't
exist two days ago as far I could see from my end.
The kernel.org server returned a 'you don't have permission to read
kernel/git/torvalds/linux-2.6.git/HEAD on this server', not a 404.
I tried two different ftp clients which also could not see your
'master' file until yesterday.
I notice that Petr hasn't made any changes to cogito for a long
time, so maybe it needs some updating? Dunno.
--- Scanned by M+ Guardian Messaging Firewall ---
^ permalink raw reply
* Re: most commonly used git commands?
From: Johannes Sixt @ 2007-06-28 13:54 UTC (permalink / raw)
To: git; +Cc: Alex Riesen
In-Reply-To: <Pine.LNX.4.64.0706281408280.4438@racer.site>
Johannes Schindelin wrote:
> On Thu, 28 Jun 2007, Alex Riesen wrote:
> > On 6/25/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > git update-index is really not user-friendly. That is why we have "git
> > > add". It is commonly used as a porcelain _instead of_ update-index.
> >
> > which reminds me: "git-add" lacks "--chmod=[+-]x".
>
> ???
>
> Do you mean "chmod a+x blub && git add blub"?
No. It was meant as Alex said it. Windows (MinGW) doesn't understand
"chmod a+x blub".
-- Hannes
^ permalink raw reply
* Re: most commonly used git commands?
From: Johannes Sixt @ 2007-06-28 14:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Alex Riesen, git
In-Reply-To: <Pine.LNX.4.64.0706281506390.4438@racer.site>
Johannes Schindelin wrote:
>
> On Thu, 28 Jun 2007, Johannes Sixt wrote:
> > No. It was meant as Alex said it. Windows (MinGW) doesn't understand
> > "chmod a+x blub".
>
> Yes, I suspected that. But I don't see a need for it on Windows (MinGW) to
> begin with.
True for Windows-centered projects. But for cross-platform projects
--chmod=+x is needed every now and then.
AFAIAC, it's alright to fall back to update-index for those occasions,
even though they are not that rare due to a deficiency of
merge-recursive: When it merges an executable file, it loses the +x bit,
even if core.filemode=false!
-- Hannes
^ permalink raw reply
* Re: [PATCH] Avoid perl in t1300-repo-config
From: Johannes Schindelin @ 2007-06-28 14:19 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, Git Mailing List, Frank Lichtenheld
In-Reply-To: <81b0412b0706280041i535efdf0r87e552551b796044@mail.gmail.com>
Hi,
On Thu, 28 Jun 2007, Alex Riesen wrote:
> On 6/28/07, Junio C Hamano <gitster@pobox.com> wrote:
>
> > By the way, is it possible for gmail users to avoid attachments when
> > sending patches in?
>
> No. The message text is unpredictably garbled
It is not really unpredictable.
- whitespace at the end of line is stripped
- too long lines are _always_ broken (and our diffstat lines qualify for
that)
- empty lines at the end of the message are stripped (does not concern us)
- empty lines at the beginning of the message are stripped (does not
concern us either)
- encodings different from UTF-8 are a problem
Of course, the first reason already precludes diffs from being sent. Just
think of an empty line, which is in both versions (or even worse, a single
space on the line).
Ciao,
Dscho
^ permalink raw reply
* [PATCH] getenv/setenv: use constants if available
From: Matthias Lederhofer @ 2007-06-28 14:15 UTC (permalink / raw)
To: git
There were places using "GIT_DIR" instead of GIT_DIR_ENVIRONMENT and
"GIT_CONFIG" instead of CONFIG_ENVIRONMENT. This makes it easier to
find all places touching an environment variable using git grep or
similar tools.
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
---
I only found one other place where a string was used directly even
though there is a constant: GIT_REFLOG_ACTION is only defined in
git-revert.c and builtin-fetch--tool.c uses the environment variable
too. At least when searching with grep this makes no problem because
the name of the constant is the same as the string it is defined to..
---
builtin-config.c | 4 ++--
path.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin-config.c b/builtin-config.c
index 3f7cab1..7d2063c 100644
--- a/builtin-config.c
+++ b/builtin-config.c
@@ -178,14 +178,14 @@ int cmd_config(int argc, const char **argv, const char *prefix)
char *home = getenv("HOME");
if (home) {
char *user_config = xstrdup(mkpath("%s/.gitconfig", home));
- setenv("GIT_CONFIG", user_config, 1);
+ setenv(CONFIG_ENVIRONMENT, user_config, 1);
free(user_config);
} else {
die("$HOME not set");
}
}
else if (!strcmp(argv[1], "--system"))
- setenv("GIT_CONFIG", ETC_GITCONFIG, 1);
+ setenv(CONFIG_ENVIRONMENT, ETC_GITCONFIG, 1);
else if (!strcmp(argv[1], "--null") || !strcmp(argv[1], "-z")) {
term = '\0';
delim = '\n';
diff --git a/path.c b/path.c
index 6395cf2..c4ce962 100644
--- a/path.c
+++ b/path.c
@@ -252,7 +252,7 @@ char *enter_repo(char *path, int strict)
if (access("objects", X_OK) == 0 && access("refs", X_OK) == 0 &&
validate_headref("HEAD") == 0) {
- setenv("GIT_DIR", ".", 1);
+ setenv(GIT_DIR_ENVIRONMENT, ".", 1);
check_repository_format();
return path;
}
--
1.5.2.2.1398.ga4b05
^ permalink raw reply related
* Re: most commonly used git commands?
From: Johannes Schindelin @ 2007-06-28 14:07 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Alex Riesen, git
In-Reply-To: <4683BDA5.996874EF@eudaptics.com>
On Thu, 28 Jun 2007, Johannes Sixt wrote:
> Johannes Schindelin wrote:
> > On Thu, 28 Jun 2007, Alex Riesen wrote:
> > > On 6/25/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > > git update-index is really not user-friendly. That is why we have "git
> > > > add". It is commonly used as a porcelain _instead of_ update-index.
> > >
> > > which reminds me: "git-add" lacks "--chmod=[+-]x".
> >
> > ???
> >
> > Do you mean "chmod a+x blub && git add blub"?
>
> No. It was meant as Alex said it. Windows (MinGW) doesn't understand
> "chmod a+x blub".
Yes, I suspected that. But I don't see a need for it on Windows (MinGW) to
begin with.
Ciao,
Dscho
^ permalink raw reply
* Re: most commonly used git commands?
From: Johannes Schindelin @ 2007-06-28 13:08 UTC (permalink / raw)
To: Alex Riesen; +Cc: Michael S. Tsirkin, Junio C Hamano, git
In-Reply-To: <81b0412b0706280152g5cbd777y76757d9c608ea483@mail.gmail.com>
Hi,
On Thu, 28 Jun 2007, Alex Riesen wrote:
> On 6/25/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > git update-index is really not user-friendly. That is why we have "git
> > add". It is commonly used as a porcelain _instead of_ update-index.
>
> which reminds me: "git-add" lacks "--chmod=[+-]x".
???
Do you mean "chmod a+x blub && git add blub"?
Ciao,
Dscho
^ permalink raw reply
* Re: Darcs
From: Johannes Schindelin @ 2007-06-28 13:02 UTC (permalink / raw)
To: Josh Triplett; +Cc: Linus Torvalds, Bu Bacoo, git
In-Reply-To: <46830E60.2090806@freedesktop.org>
Hi,
On Wed, 27 Jun 2007, Josh Triplett wrote:
> Wow. You completely skipped the opportunity to flame Visual Source Safe
> (vss) users. :) Too easy?
It's no fun if the targets of your ridicule don't even get it.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-merge-ff: fast-forward only merge
From: Johannes Schindelin @ 2007-06-28 13:01 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: Sam Vilain, git
In-Reply-To: <20070628113346.GA4914@moooo.ath.cx>
Hi,
On Thu, 28 Jun 2007, Matthias Lederhofer wrote:
> Sam Vilain <sam.vilain@catalyst.net.nz> wrote:
> > This is primarily so that there is an easy switch to 'git-pull' to
> > be sure to fast forward only.
> > ---
> > Documentation/merge-strategies.txt | 5 +++++
> > Makefile | 2 +-
> > git-merge-ff.sh | 8 ++++++++
> > 3 files changed, 14 insertions(+), 1 deletions(-)
> > create mode 100644 git-merge-ff.sh
>
> git-merge-ff.sh should be executable, added to .gitignore and the
> strategy should be added to the available strategies.
>
> And somehow it did not work for me at all:
>
> % git merge -s ff origin/master
> git-merge.sh: needs update
> Trying really trivial in-index merge...
> Wonderful.
> In-index merge
> [..]
> % git show HEAD|grep Merge
> Merge: 117a93c... f578825...
> Merge commit 'origin/master'
To prevent something like this to happen, may I suggest adding a really
simple, small test case?
Ciao,
Dscho
^ permalink raw reply
* RE: [PATCH] git-submodule: Try harder to describe the status of a submodule
From: Medve Emilian-EMMEDVE1 @ 2007-06-28 13:01 UTC (permalink / raw)
To: git
In-Reply-To: <7v1wfwpuy2.fsf@assigned-by-dhcp.pobox.com>
Hello Junio,
Alright, let's go with your patch.
Cheers,
Emil.
This e-mail, and any associated attachments have been classified as:
--------------------------------------------------------------------
[x] Public
[ ] Freescale Semiconductor Internal Use Only
[ ] Freescale Semiconductor Confidential Proprietary
-----Original Message-----
From: Junio C Hamano [mailto:gitster@pobox.com]
Sent: Wednesday, June 27, 2007 11:25 PM
To: Medve Emilian-EMMEDVE1
Cc: git@vger.kernel.org
Subject: Re: [PATCH] git-submodule: Try harder to describe the status of
a submodule
Emil Medve <Emilian.Medve@Freescale.com> writes:
> Some repositories might not use/have annotated tags (for example
repositories created with
> git-cvsimport) or might not have tags at all and could cause
git-submodule status to fail because
> git-describe might fail.
>
> This change makes git-submodule status try harder in displaying the
status of a module by
> considering lightweight tags, subsequent tags and branches.
Why are we suddenly seeing these loooooooong lines...
> +get_revname()
> +{
> + _revname=$(git-describe --tags "$1" 2>/dev/null || git-describe
--contains "$1" 2>/dev/null)
> + if test -z "$_revname" -o "$_revname" = "undefined"
> + then
> + _revname=$(git-describe --all "$1" 2>/dev/null | cut -d
/ -f2-)
> + test -z "$_revname" && _revname=undefined
> + fi
I really do not think using --all is useful. If you do not have
a tag and the rev cannot be described, what damage does it incur?
We still say "$sha1 $path" in the output anyway, and ($revname)
is only "it makes it nicer" appendix.
> @@ -155,7 +174,7 @@ modules_list()
> say "-$sha1 $path"
> continue;
> fi
> - revname=$(unset GIT_DIR && cd "$path" && git-describe
$sha1)
> + revname=$(unset GIT_DIR && cd "$path" && get_revname
$sha1)
> if git diff-files --quiet -- "$path"
> then
> say " $sha1 $path ($revname)"
In that sense, I would prefer mine much better. If a rev is
indescribable, your version would say:
" dddddddddddddddddddddddddddddddddddddddd subdir (undefined)"
while mine would have said:
" dddddddddddddddddddddddddddddddddddddddd subdir"
^ permalink raw reply
* Re: Build git on HP/UX
From: Michal Rokos @ 2007-06-28 12:23 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: GIT
In-Reply-To: <20070628105952.GC8925@cip.informatik.uni-erlangen.de>
Hi,
I'm using it every day...
On Thursday 28 June 2007 12:59:52 Thomas Glanzmann wrote:
> Hello,
> could someone here describe what he did to build git on HP/UX?
> Some of my questions is:
>
> - What build chain did you use (gcc?)?
> - Did you use binary packages provided by whom?
On Parics I'm using gcc.
On Itanium I'm using hp stock cc (so no need to build gcc-build-chain)
I'm git-pulling it very often - co I'm compiling it from the git sources.
Michal.
--
Michal Rokos
ICQ: 36118339
Jabber: michal.rokos@gmail.com
^ permalink raw reply
* Re: [PATCH] Ignore end-of-line style when computing similarity score for rename detection
From: Johannes Schindelin @ 2007-06-28 12:41 UTC (permalink / raw)
To: Steven Grimm; +Cc: Junio C Hamano, git
In-Reply-To: <20070628060416.GA13162@midwinter.com>
Hi,
On Wed, 27 Jun 2007, Steven Grimm wrote:
> Junio rightly points out that it would be a mistake to discard \r
> characters from binary files when computing similarity scores.
Somehow I think that this should be triggered by "--ignore-space-at-eol",
_and_ be accompanied by a test case.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-merge-ff: fast-forward only merge
From: Matthias Lederhofer @ 2007-06-28 11:33 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <1182830470640-git-send-email-sam.vilain@catalyst.net.nz>
Sam Vilain <sam.vilain@catalyst.net.nz> wrote:
> This is primarily so that there is an easy switch to 'git-pull' to
> be sure to fast forward only.
> ---
> Documentation/merge-strategies.txt | 5 +++++
> Makefile | 2 +-
> git-merge-ff.sh | 8 ++++++++
> 3 files changed, 14 insertions(+), 1 deletions(-)
> create mode 100644 git-merge-ff.sh
git-merge-ff.sh should be executable, added to .gitignore and the
strategy should be added to the available strategies.
And somehow it did not work for me at all:
% git merge -s ff origin/master
git-merge.sh: needs update
Trying really trivial in-index merge...
Wonderful.
In-index merge
[..]
% git show HEAD|grep Merge
Merge: 117a93c... f578825...
Merge commit 'origin/master'
^ permalink raw reply
* Re: Build git on HP/UX
From: Thomas Glanzmann @ 2007-06-28 11:27 UTC (permalink / raw)
To: Alex Riesen; +Cc: michal.rokos, GIT
In-Reply-To: <81b0412b0706280422u54150ed9nefc4ae716ffb03c6@mail.gmail.com>
Hello,
> what did you already tried? Do you have a build log? (with either gcc or
> acc)
I tried nothing. But my next steps are to download gcc packages from
http://hpux.cs.utah.edu/ and try to compile git.
Gruesse,
Thomas
^ permalink raw reply
* Re: Build git on HP/UX
From: Alex Riesen @ 2007-06-28 11:22 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: michal.rokos, GIT
In-Reply-To: <20070628105952.GC8925@cip.informatik.uni-erlangen.de>
On 6/28/07, Thomas Glanzmann <thomas@glanzmann.de> wrote:
> Hello,
> could someone here describe what he did to build git on HP/UX?
what did you already tried? Do you have a build log? (with either gcc or acc)
^ permalink raw reply
* [PATCH] git-cvsimport: force checkout of working tree after initial import
From: Gerrit Pape @ 2007-06-28 11:12 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: 430903
When creating a brand new git repository through git-cvsimport (not
incremental import), force a checkout of HEAD of master as working tree
after successful import using the -f switch to git checkout. Otherwise
the working tree is empty, and all files are reported as 'deleted' by
git status.
This was noticed and reported by Cameron Dale through
http://bugs.debian.org/430903
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
git-cvsimport.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 69ccb88..ba23eb8 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -1007,7 +1007,7 @@ if ($orig_branch) {
if ($opt_r && $opt_o ne 'HEAD');
system('git-update-ref', 'HEAD', "$orig_branch");
unless ($opt_i) {
- system('git checkout');
+ system('git checkout -f');
die "checkout failed: $?\n" if $?;
}
}
--
1.5.2.1
^ permalink raw reply related
* Re: [PATCH] Avoid perl in t1300-repo-config
From: Alex Riesen @ 2007-06-28 11:00 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <f5vuv9$f8s$1@sea.gmane.org>
On 6/28/07, Jakub Narebski <jnareb@gmail.com> wrote:
> >> By the way, is it possible for gmail users to avoid attachments
> >> when sending patches in?
> >
> > No. The message text is unpredictably garbled
>
> If by "gmail users" you mean gmail web interface, then probably no.
> No problems with using gmail from email client or from git-send-email
> (the latter after configuring sendmail in my case).
Can't. M$ Exchange plagued
^ permalink raw reply
* Build git on HP/UX
From: Thomas Glanzmann @ 2007-06-28 10:59 UTC (permalink / raw)
To: michal.rokos, GIT
Hello,
could someone here describe what he did to build git on HP/UX?
Some of my questions is:
- What build chain did you use (gcc?)?
- Did you use binary packages provided by whom?
Thomas
^ permalink raw reply
* [PATCH] git-clone: fetch possibly detached HEAD over dumb http
From: Sven Verdoolaege @ 2007-06-28 10:52 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Louis-Noel Pouchet
git-clone supports cloning from a repo with detached HEAD,
but if this HEAD is not behind any branch tip then it
would not have been fetched over dumb http, resulting in a
fatal: Not a valid object name HEAD
Since 928c210a, this would also happen on a http repo
with a HEAD that is a symbolic link where someone has
forgotton to run update-server-info.
Signed-off-by: Sven Verdoolaege <skimo@liacs.nl>
---
git-clone.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/git-clone.sh b/git-clone.sh
index bd44ce1..cdbbc20 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -70,7 +70,8 @@ Perhaps git-update-server-info needs to be run there?"
git-http-fetch $v -a -w "$tname" "$sha1" "$1" || exit 1
done <"$clone_tmp/refs"
rm -fr "$clone_tmp"
- http_fetch "$1/HEAD" "$GIT_DIR/REMOTE_HEAD" ||
+ http_fetch "$1/HEAD" "$GIT_DIR/REMOTE_HEAD" &&
+ git-http-fetch $v -a $(cat "$GIT_DIR/REMOTE_HEAD") "$1" ||
rm -f "$GIT_DIR/REMOTE_HEAD"
}
--
1.5.2.2.585.g9cc0-dirty
^ permalink raw reply related
* Re: Bug: segfault during git-prune
From: Andy Parkins @ 2007-06-28 10:52 UTC (permalink / raw)
To: git
In-Reply-To: <200706281134.58453.andyparkins@gmail.com>
On Thursday 2007 June 28, Andy Parkins wrote:
> So, I think there are two faults: git-prune is deciding that the object is
> a blob, when it's actually a commit; and git-prune's error handling is
> broken in that case, because it's continuing with the NULL pointer returned
> by check_commit() when obj->type != OBJ_COMMIT.
I can't figure it out I'm afraid. I've done a bit of back tracing and found
the block that's generating the error; object.c:150
} else if (type == OBJ_COMMIT) {
struct commit *commit = lookup_commit(sha1);
parse_commit_buffer(commit, buffer, size);
if (!commit->buffer) {
commit->buffer = buffer;
eaten = 1;
}
obj = &commit->object;
}
Now, lookup_commit() is returning NULL because check_commit() is being called
with a struct object whose type field is not OBJ_COMMIT. Which it presumably
got from lookup_object(). gdb tells me the object returned by lookup_object()
is
{parsed = 0, used = 0, type = 3, flags = 0,
sha1 = "\"\217\200e¹0\022\0165ü\f\025L#t\207«\002ÖJ"}
Which seems to be the right hash, 228f8065b930120e35fc0c154c237487ab02d64a.
What should I do next? I don't understand why lookup_object() is returning
an object with type blob instead of with type commit, when git-cat-file says
that same object is a commit.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Bug: segfault during git-prune
From: Andy Parkins @ 2007-06-28 10:34 UTC (permalink / raw)
To: Git Mailing List
Hello,
I ran git-prune on a repository and got this:
$ git-prune
error: Object 228f8065b930120e35fc0c154c237487ab02d64a is a blob, not a commit
Segmentation fault (core dumped)
$ git-cat-file -t 228f8065b930120e35fc0c154c237487ab02d64a
commit
git-show of the object shows it looks okay. git-fsck just shows a load
of dangling objects - which isn't a surprise, that's why I was running
git-prune.
Here's the backtrace:
parse_commit_buffer (item=0x0, buffer=0x81124b8, size=421) at commit.c:292
#1 0x0808ad22 in parse_object_buffer (sha1=0x8111ac5 "\"\217\200e¹0\022\0165ü\f\025L#t\207«\002ÖJ", type=OBJ_COMMIT, size=421, buffer=0x81124b8,
eaten_p=0xafdc6c40) at object.c:152
#2 0x0808adb7 in parse_object (sha1=0x8111ac5 "\"\217\200e¹0\022\0165ü\f\025L#t\207«\002ÖJ") at object.c:187
#3 0x0808d1a2 in add_one_ref (path=0x8111aed "refs/remotes/libswscale-svn", sha1=0x8111ac5 "\"\217\200e¹0\022\0165ü\f\025L#t\207«\002ÖJ", flag=6,
cb_data=0xafdc6d40) at reachable.c:124
#4 0x0809133e in do_one_ref (base=<value optimized out>, fn=0x808d190 <add_one_ref>, trim=0, cb_data=0xafdc6d40, entry=0x8111ac0) at refs.c:478
#5 0x08092be4 in do_for_each_ref (base=0x80c8e76 "refs/", fn=0x808d190 <add_one_ref>, trim=0, cb_data=0xafdc6d40) at refs.c:545
#6 0x0808cff4 in mark_reachable_objects (revs=0xafdc6d40, mark_reflog=1) at reachable.c:188
#7 0x08071c90 in cmd_prune (argc=1, argv=0xafdc7074, prefix=0x0) at builtin-prune.c:93
#8 0x0804aa24 in handle_internal_command (argc=1, argv=0xafdc7074, envp=<value optimized out>) at git.c:348
#9 0x0804b4c9 in main (argc=1, argv=Cannot access memory at address 0xe
So, I think there are two faults: git-prune is deciding that the object is
a blob, when it's actually a commit; and git-prune's error handling is broken
in that case, because it's continuing with the NULL pointer returned by
check_commit() when obj->type != OBJ_COMMIT.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: [PATCH] Avoid perl in t1300-repo-config
From: Jakub Narebski @ 2007-06-28 9:28 UTC (permalink / raw)
To: git
In-Reply-To: <81b0412b0706280041i535efdf0r87e552551b796044@mail.gmail.com>
Alex Riesen wrote:
>> By the way, is it possible for gmail users to avoid attachments
>> when sending patches in?
>
> No. The message text is unpredictably garbled
If by "gmail users" you mean gmail web interface, then probably no.
No problems with using gmail from email client or from git-send-email
(the latter after configuring sendmail in my case).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] Avoid perl in t1300-repo-config
From: Alex Riesen @ 2007-06-28 8:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Frank Lichtenheld
In-Reply-To: <81b0412b0706280041i535efdf0r87e552551b796044@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1100 bytes --]
It fixes the test on systems where ActiveState Perl is used.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
t/t1300-repo-config.sh | 22 ++++++++++------------
1 files changed, 10 insertions(+), 12 deletions(-)
On 6/28/07, Alex Riesen <raa.lkml@gmail.com> wrote:
> On 6/28/07, Junio C Hamano <gitster@pobox.com> wrote:
> > "Alex Riesen" <raa.lkml@gmail.com> writes:
> >
> > > It fixes the test on system where ActiveState Perl is used.
> > > It is also shorter.
> > > ...
> > > -git config --null --list | perl -0ne 'chop;($key,$value)=...
> > > +git config --null --list | xargs -n1 -0 echo 'Key:' > result
> >
> > This now makes us rely on "xargs -0", which is probably much
> > less portable than Perl isn't it?
>
> Dunno. Have yet too meet a system where it doesn't work.
> That said, SUSv6 does not mention it.
>
> > Maybe postprocess "git config -z" output with "tr '[\000]' 'Q'"
> > or something so that the comparison of the result does not have
> > to worry about NULs? I dunno.
>
> Will try that.
>
So I did. Any idea as to how make the here-document
_without_ the trailing LF?
[-- Attachment #2: 0001-Avoid-perl-in-t1300-repo-config.txt --]
[-- Type: text/plain, Size: 1628 bytes --]
From 846fcfe47938ee894eb433b6f3a24ae4b6479e5b Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Wed, 27 Jun 2007 14:40:41 +0200
Subject: [PATCH] Avoid perl in t1300-repo-config
It fixes the test on system where ActiveState Perl is used.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
t/t1300-repo-config.sh | 22 ++++++++++------------
1 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 7a77bef..27486de 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -529,25 +529,23 @@ cat > .git/config <<\EOF
EOF
cat > expect <<\EOF
-Key: section.sub=section.val1
-Value: foo=bar
-Key: section.sub=section.val2
-Value: foo
-bar
-Key: section.sub=section.val3
-Value:
+section.sub=section.val1
+foo=barQsection.sub=section.val2
+foo
+barQsection.sub=section.val3
-Key: section.sub=section.val4
-Value:
-Key: section.sub=section.val5
+Qsection.sub=section.val4
+Qsection.sub=section.val5Q
EOF
-git config --null --list | perl -0ne 'chop;($key,$value)=split(/\n/,$_,2);print "Key: $key\n";print "Value: $value\n" if defined($value)' > result
+git config --null --list | tr '[\000]' 'Q' > result
+echo >>result
test_expect_success '--null --list' 'cmp result expect'
-git config --null --get-regexp 'val[0-9]' | perl -0ne 'chop;($key,$value)=split(/\n/,$_,2);print "Key: $key\n";print "Value: $value\n" if defined($value)' > result
+git config --null --get-regexp 'val[0-9]' | tr '[\000]' 'Q' > result
+echo >>result
test_expect_success '--null --get-regexp' 'cmp result expect'
--
1.5.2.2.1308.g540b6
^ permalink raw reply related
* Re: most commonly used git commands?
From: Alex Riesen @ 2007-06-28 8:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Michael S. Tsirkin, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0706250846200.4059@racer.site>
On 6/25/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> git update-index is really not user-friendly. That is why we have "git
> add". It is commonly used as a porcelain _instead of_ update-index.
which reminds me: "git-add" lacks "--chmod=[+-]x".
^ permalink raw reply
* Re: [PATCH] Ignore end-of-line style when computing similarity score for rename detection
From: Junio C Hamano @ 2007-06-28 8:16 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4683619A.F753C97E@eudaptics.com>
Johannes Sixt <J.Sixt@eudaptics.com> writes:
> Steven Grimm wrote:
>>
>> Signed-off-by: Steven Grimm <koreth@midwinter.com>
>> ---
>> Okay, let's try this again with an MUA that won't change my tabs to
>> spaces -- sorry about that.
>>
>> A couple of source files got checked into my code base with DOS-style
>> end-of-line characters. I converted them to UNIX-style (the convention
>> for this project) in my branch. Then later, I renamed a couple of them.
>>
>> Meanwhile, back in the original branch, someone else fixed a bug in one
>> of the files and checked it in, still with DOS-style line endings.
>>
>> When I merged that change into my branch, git didn't detect the rename
>> because the fact that every line has a change (the end-of-line
>> character) dropped the similarity score way too low.
>>
>> This patch teaches git to ignore end-of-line style when looking for
>> potential rename candidates. A separate question, which I expect may be
>> more controversial, is what to do with conflict markers; with this
>> patch, the entire file is still marked as in conflict if the end-of-line
>> style changes (but it's still an improvement in that we at least detect
>> the rename now.)
>
> I think that nobody would object to have a use-case description like
> this in the commit message...
Oh, yeah. 100% agreed.
^ 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