* [StGIT PATCH 4/4] Port stg-whatchanged improvements to stg-mdiff and have the former use the latter.
From: Yann Dirson @ 2007-07-24 18:57 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20070724185535.17180.24577.stgit@gandelf.nowhere.earth>
From: Yann Dirson <yann.dirson@sagem.com>
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
contrib/stg-mdiff | 2 ++
contrib/stg-whatchanged | 10 ++++------
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/contrib/stg-mdiff b/contrib/stg-mdiff
index 61cba9e..74d7f77 100755
--- a/contrib/stg-mdiff
+++ b/contrib/stg-mdiff
@@ -46,4 +46,6 @@ case "$2" in
esac
colordiff $diffopts \
+ -I '^index [0-9a-b]*..[0-9a-b]*' \
+ -I '^@@ .* @@' \
<($cmd1 "$1") <($cmd2 "$2") | less -RFX
diff --git a/contrib/stg-whatchanged b/contrib/stg-whatchanged
index 231f4f5..afeda2c 100755
--- a/contrib/stg-whatchanged
+++ b/contrib/stg-whatchanged
@@ -25,11 +25,9 @@ fi
# in this case (unlike, eg., "pick --fold")
patchdir="$(git-rev-parse --git-dir)/patches/$(stg branch)/patches/$(stg top)"
case $(stg log | head -n1) in
- *push\(c\)*) current_cmd="stg show //top.old" ;;
- *) current_cmd="stg show" ;;
+ *push\(c\)*) former="//top.old" ;;
+ *) former="//top" ;;
esac
-colordiff "$@" \
- -I '^index [0-9a-b]*..[0-9a-b]*' \
- -I '^@@ .* @@' \
- <($current_cmd) <(stg diff -r//bottom) | less -RFX
+stg-mdiff -o "$*" \
+ $former //bottom..
^ permalink raw reply related
* Re: [PATCH] Add a 1-second sleep to git-cvsexportcommit test
From: Linus Torvalds @ 2007-07-24 19:02 UTC (permalink / raw)
To: Robin Rosenberg
Cc: Simon 'corecode' Schubert, Junio C Hamano, Jason Sewall,
git, raa.lkml
In-Reply-To: <200707241134.31950.robin.rosenberg.lists@dewire.com>
On Tue, 24 Jul 2007, Robin Rosenberg wrote:
>
> 27778 time(NULL) = 1185268822
> 27778 gettimeofday({1185268822, 953340}, NULL) = 0
>
> Here CVS sleeps. The amount varies between invocations since it
> only sleeps enough for the seconds to wrap.
>
> 27778 nanosleep({0, 46660000}, NULL) = 0
> 27778 time(NULL) = 1185268823
Btw, this is *really* dangerous and buggy.
The reason? The CPU real-time clock is very different from whatever clock
the filesystems may use.
Filesystems generally do not use the same clock as the CPU does. That's
obviously true for things like networked filesystems, but it's actually
true even for local filesystems (even on UP) because the CPU "realtime"
clock rather expensive and much too exact for them. It does all the fancy
NTP date correction etc, and it has all the complex code to actually make
sure you don't get any time jumps etc.
So you should basically assume that all filesystems will use a clock that
is *close*, but not synchronized with the real-time clock. You have NFS
issues, but even locally you'd generally expect the local filesystem to be
based on a simply clock that is updated by the timer tick, and is "close
enough" to the realtime clock that you get with gettimeofday(). But *not*
identical.
So if you sleep for one second, the filesystem times will update by one
second, but if you try to *synchronize* to exactly one second, it's not at
all certain that the *filesystem* clock will be synchronized to the same
second! Time skew is simply a fact of life.
A really obvious example of this is NFS. Anybody who thinks that the NFS
times are synchronized to the client real-time clock is just seriously
mistaken. They may be close, but they won't be identical.
So I think CVS is simply buggy here. It assumes that "filesystem time" is
the same as "CPU time", and while that sounds like an obvious assumption
to make, if you think about it for even five seconds (the NFS case above),
you realize that it's a totally *buggy* assumption.
In other words: if you want the timestamps on two files to be one second
apart, you have to sleep one second in between writing them (or you have
to set the time explicitly with "utimes()" or similar). Doing the
"optimized sleep" simply DOES NOT WORK.
So CVS is buggy. Big surprise. Film at 11.
Btw, if anybody can think of a similar scenario in git, please holler. We
shouldn't have those kinds of bugs.
So the things you generally can depend on:
- *within* a single filesystem, the clocks should be comparable (ie you
can do "stat()" on two files, and compare the date-stamps between the
files).
- the clocks should obviously be "close" to the local realtime. Time skew
is a fact of life, but if time skews by more than a big fraction of a
second, something is wrong. It's certainly still very possible (NFS
with clients not running NTP), but at least at that point a program can
validly say "badly maintained network, it's the users problem".
but depending on exact time syncronization is a really really bad idea.
Linus
^ permalink raw reply
* [PATCH] pretty-options.txt: tiny doc fix
From: Jim Meyering @ 2007-07-24 18:59 UTC (permalink / raw)
To: git
Signed-off-by: Jim Meyering <jim@meyering.net>
---
Documentation/pretty-options.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/pretty-options.txt b/Documentation/pretty-options.txt
index 746bc5b..973d8dd 100644
--- a/Documentation/pretty-options.txt
+++ b/Documentation/pretty-options.txt
@@ -1,9 +1,9 @@
--pretty[='<format>']::
- Pretty print the contents of the commit logs in a given format,
+ Pretty-print the contents of the commit logs in a given format,
where '<format>' can be one of 'oneline', 'short', 'medium',
'full', 'fuller', 'email', 'raw' and 'format:<string>'.
- When left out the format default to 'medium'.
+ When omitted, the format defaults to 'medium'.
--abbrev-commit::
Instead of showing the full 40-byte hexadecimal commit object
--
^ permalink raw reply related
* Re: [PATCH 3/3] Teach "git branch" about --new-workdir
From: Marius Storm-Olsen @ 2007-07-24 19:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Shawn O. Pearce, Julian Phillips, git
In-Reply-To: <Pine.LNX.4.64.0707241923450.14781@racer.site>
[-- Attachment #1: Type: text/plain, Size: 4238 bytes --]
>> 1) IMO, git should on Windows always do CRLF conversion, as this is what
>> Windows developers in general expect. (CRLF text-files that is, not the
>> conversion.) Meaning that
>> core.autocrlf = Windows
>
> I do not think so.
>
> core.autocrlf is only about the relationship between the working tree and
> the repository.
>
> So if you want CR/LF line endings always, just do not set that flag
> (which defaults to false).
>
> If you want LF line endings in the repo, but not necessarily in the
> working tree, set core.autocrlf to input.
>
> If you want LF line endings sometimes, but CR/LF at other times, but do
> not care if the revisions in the repository will have LF or CR/LF, do not
> set that flag.
Ok, here we fundamentally disagree.
IMO Windows user expect files to be DOS style, since all other files
are. Yes, most newer tools 'handle' Unix style files, but creating new
ones will mostly be DOS style. Some will actually wreak havoc on your
files, and start adding DOS line endings in the middle of your Unix line
ending file. I've seen it happen. So, dealing with Unix style text files
on Windows can be a problem for some people.
So, normally, when developing on Windows you'd expect DOS files, nothing
else. (Note that we're not talking about your average MinGW or Cygwin
user here, since they are known to the issues and how to tackle them)
> Git is really slowed down tremendously just by the fact that it runs on
> Windows. You should not add to that.
The auto crlf conversion is not the slow down here, and the time spent
there is negligible. I use autocrlf on all my repos on Windows, and
don't notice it. Filestat'ing on the other hand.. :-)
> IMHO in most cases -- even on Windows -- you do not want to set autocrlf
> at all. Because you do not need to store the file different from the
> version you have in the working tree.
Not true. I believe, especially at the moment, most Git users on Windows
are mostly developing code in a cross-platform manner, and therefore
care about this problem.
> The only situation where I think it makes sense, is when you have both
> Windows and Unix developers, _and_ your Windows tools sometimes produce
> CR/LF stupidly. But then I'd set it to "input".
That's ok _now_, because most of the Git user group is experienced
developer that understand the problem. I'm trying to see past that
state, and prepare Git for more 'common' usage on Windows. They'd expect
text files on Windows to be handled correctly, without any fuzz.
No tweaking of config options to make it work on Windows. No problems
with sharing repositories with Unix developers. Just work. That's not
the current state. But it could be.
> BTW no need to fuzz about binary files, which want to be in the
> object database without being converted. Our heuristics has so far
> been pretty successful in discerning binary from text files.
Yeah, I have no beef with the binary detection. It seems to work fine.
At least I haven't had a problem with it yet, and it's not what we're
discussing.
Ok, I come from the Perforce world, so here how it works there:
1) Files are stored with Unix line endings in the repository.
2) Conversion is done on Windows (and older Macs) upon checkout, if the
file is a text file.
3) It has binary file detection when you add it to the depot, so if you
and to add a DOS line ending file to the repo, you have to mark it as a
binary file manually
Git does 1) and 2) already, and with the EOL detection in the repo file,
(when you've already detected that a file has changed, so there's not
much time wasted with that) to eliminate the 'yes' in point 6) in the
original mail, should help implement 3) above well enough. It's simply,
"If it was a CRLF file before, no need to convert it to LF now", and the
problem is largely fixed. Then it's only when we want to commit a new
CRLF file that we need a way to 'turning off' the autocrlf for just
_that_ file for _that_ commit. And presto, you'd have something which
most Windows users would expect. And Git would probably be adapted on
Windows more quickly, which this is all about. :-) IMHO.
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: StGIT (or guilt) + git-svn?
From: Josef Sipek @ 2007-07-24 19:39 UTC (permalink / raw)
To: Steven Grimm; +Cc: Steven Walter, 'git'
In-Reply-To: <46A5EE4B.7020905@midwinter.com>
On Tue, Jul 24, 2007 at 08:19:23PM +0800, Steven Grimm wrote:
> Steven Walter wrote:
> >That said, I'm not sure that stgit will help you with "local versioning"
> >of files (I'm not even sure what you mean). Perhaps you can elaborate
> >on this point.
> >
>
> He wants to create some files in his git-svn clone and use git to manage
> them -- checkpointing his work in progress, backing out changes, etc.,
> without publishing those files to the svn repository. The files in
> question are not already in svn. But he does want to work on other files
> that *are* in the svn repository, and wants those changes to be
> committed back.
>
> So my assumption was that he would do something like maintain his
> local-only changes as StGIT patches that never get committed to git. His
> other changes would get committed from StGIT to git, and from there he'd
> do his normal git-svn dcommit. Or maybe git-svn dcommit followed by stg
> rebase since git-svn dcommit creates new revision IDs.
>
> In any event, now that I know it's working successfully for at least one
> person, I'll point him to stg and he can play with it a bit. Didn't want
> to lead him into a dead end. Thanks!
If I understand your scenario correctly, guilt will work just as well.
Josef 'Jeff' Sipek.
--
All science is either physics or stamp collecting.
- Ernest Rutherford
^ permalink raw reply
* Re: [PATCH] filter-branch: rewrite only refs which were not excludedbythe options
From: Johannes Schindelin @ 2007-07-24 19:52 UTC (permalink / raw)
To: Johannes Sixt; +Cc: gitster, git
In-Reply-To: <46A614CE.597C7130@eudaptics.com>
Hi,
On Tue, 24 Jul 2007, Johannes Sixt wrote:
> Johannes Schindelin wrote:
>
> > On Tue, 24 Jul 2007, Johannes Sixt wrote:
> >
> > > Johannes Schindelin wrote:
> > >
> > > > On Tue, 24 Jul 2007, Johannes Sixt wrote:
> > > >
> > > > > But there's another problem. Consider this history:
> > > > >
> > > > > ---X--o--M <- master
> > > > > \
> > > > > ...-o-...-o <- topic
> > > > >
> > > > > Then this (rather contrieved) command:
> > > > >
> > > > > $ git-filter-branch -n $n master topic --not X
> > > > >
> > > > > If $n is small enough so that M is never rewritten, then
> > > > >
> > > > > git rev-list -1 "$ref" $negatives
> > > > >
> > > > > still expands to non-empty even for 'master' (= M), which then
> > > > > incorrectly ends up in "$tempdir"/heads.
> > > >
> > > > Aaargh! Of course! Since I have to add --topo-order at the end.
> > > > Otherwise it makes no sense.
> > >
> > > No, that was no my point: In my example above, if n=1, `git rev-list -1
> > > "$ref" $negatives` evaluates to
> > >
> > > $ git rev-list -1 "master" -n 1 ^X
> > >
> > > which returns M, even though M is not going to be rewritten.
> > > --topo-order changes nothing. The problem is that the -n is a relative
> > > restriction. --since is turned into --max-age, which is absolute,
> > > therefore, the test works as expected with --since.
> >
> > So you think we have to say something like
> >
> > git rev-list "$ref" $negatives | grep "$ref" > /dev/null || continue
> >
> > ?
>
> No, doesn't help either.
>
> We are talking about a case where there is more than one positive ref.
> We need not consider the -- sub/ case - it makes things just even more
> complicated. There are two different rev ranges to be considered:
>
> # (1) candidate range to be rewritten
> $ git rev-list "$@"
>
> # (2) test if positive ref is in candidate range
> $ git rev-list $ref $negatives
Okay, but with out any subdirs,
git rev-list "$@" | grep $(git rev-parse "$ref") > /dev/null || continue
should do exactly what we want. But in that case, we could just use the
generated list ../revs to grep for the positive refs.
Darn, this _is_ getting complicated.
Ciao,
Dscho
^ permalink raw reply
* Re: when git-rebase -i fails to cherry-pick
From: Uwe Kleine-König @ 2007-07-24 20:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707240005240.14781@racer.site>
Hello Johannes,
Johannes Schindelin wrote:
> > - If a cherry-pick fails, it tells me to resolve my conflicts, 'git add
> > <paths>' and to do 'git commit -c $sha1id'.
> >
> > But it doesn't tell me, how I continue to rebase after that.
> >
> > 'git rebase -i --continue' works.
>
> Actually, even "git rebase --continue" works. And you do not really have
> to commit, either, just updating your index is fine. In fact, if you say
> "git reset --hard", it will skip the commit.
OK, thanks.
> > - If a cherry-pick of a commit to be squashed fails, the instruction to
> > do 'git commit -c $sha1id' is wrong, because then I don't get both
> > message to squash.
>
> Yes, it is a leftover from the bad old days, when this script was called
> edit-patch-series, and I was a rebase hater.
>
> In the meantime, somebody on IRC explained to me how rebase works, and
> that rebase lovers were quite annoyed not to be able to just resolve the
> conflicts and "git rebase --continue".
>
> I'd appreciate if you prepared a patch with better explanations, and also
> reviewed the man page, if it is in good shape (and does not lie about the
> current behaviour).
It's on my todo list, but not the top item for git.
In the mean-time I found another nuisance:
After doing:
tmpdir=/tmp/repo
mkdir $tmpdir
cd $tmpdir
git init
for n in one two three four; do echo $n >> file; git add file;
git commit -m $n; done
git rebase -i HEAD~3 #squash four onto two
git rebase stops (as expected) when trying to apply four, at this stage
two is already commited.
The conflicting file looks as follows:
one
two
<<<<<<< HEAD:file
=======
three
four
>>>>>>> e7fbd8f... four:file
I currently have no idea how to improve this, but I miss the information
that the commit *adds* "four" and "three" is only context.
Resolving with:
echo one > file; echo two >> file; echo four >> file;
git add file; git rebase --continue
and typing a new log (e.g. two + four) git rebase stops once more (again
as expected) when trying to apply three, OK, resolving the conflict is
easy (one, two, three, four), git add file, git rebase --continue.
Looking at the resulting log, I have the following:
zeisberg@cassiopeia:/tmp/repo$ git log --pretty=oneline
145ce01e1cf3f4cb86cd0065c0d0d5b62b399ad4 three
cd082bca636efca17409be4d871d0971237df06c two + four
b6b985977db45e314509d94282597c2ff8029d3d two
15f8cbbb5a452b075b49f3dedbeaeb66668b8025 one
So the request to squash two + four was lost.
I will look at it when I'm done with git-sendemail ...
Best regards
Uwe
--
Uwe Kleine-König
main(){char*a="main(){char*a=%c%s%c;printf(a,34,a,34%c";printf(a,34,a,34
,10);a=",10);a=%c%s%c;printf(a,34,a,34,10);}%c";printf(a,34,a,34,10);}
^ permalink raw reply
* Re: http git clone memory problem.
From: Benjamin Sergeant @ 2007-07-24 20:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <1621f9fa0707241053i23f0e3d4v4a1d50f5a4c5f9e6@mail.gmail.com>
It's pretty random actually. Sometimes it ends like this:
Getting pack ffecdbabefeb7d684650f6c920c53c384bc65b5e
which contains f6c066fe62e97e3d93d10628318fe62de667b25b
got 12192695f4e402f7385728f14496ab807caeb0b8
error: File 33da1ff3b31eee2635cb105a5b15fab3362f6af7 has bad hash
error: Unable to find 33da1ff3b31eee2635cb105a5b15fab3362f6af7 under
http://www.kernel.org/pub/scm/git/git.git
Cannot obtain needed blob 33da1ff3b31eee2635cb105a5b15fab3362f6af7
while processing commit a196f6d93a21ebac9befc4b52a2b0586471b5fa4.
with no crash.
And sometimes with
Getting index for pack ffecdbabefeb7d684650f6c920c53c384bc65b5e
*** glibc detected *** git-http-fetch: corrupted double-linked list:
0x080a4360 ***
Is there a way to reproduce the crash with this
"ffecdbabefeb7d684650f6c920c53c384bc65b5e", the pack id (the sha1) ?
Benjamin.
A strace version of the crash:
I tried valgrind once but after 30 minutes nothing happened, I could
not even see the process with ps ...
I also tried strace.
A strace version of the cannot obtain needed blob:
got 7579c7107c6b5387fe1e30a0969dcb65d22e4cbf
walk abb503d1fc5802e5de9d5b4a0cb710e87d2b1ba4
Getting alternates list for http://www.kernel.org/pub/scm/git/git.git
Getting pack list for http://www.kernel.org/pub/scm/git/git.git
Getting pack 4146ab3638605f4b364bcf90d377e22c083a3d35
which contains eb7afba88c1bb4d755d23ca3aafe6d0874b848d0
got da5044940771800d0c7f0f28f269c40297860764
got 39af6c9c8112607fb780f3361c5362f587ab629f
got e3859e2a8a4ff8b9c51e1ebe430fa5bf0fd3d261
got 1ea0f745bd0996e7f30e07f472b79ca0ed578510
got c4bb30d92e0156760d07ebcc3bb3d637aebe9606
got 81536ec1557d84897ebb8565597ef7647fc770b9
error: Unable to find 11ea73c1cc3565eeabff27ef2d3619a5fb5381fd under
http://www.kernel.org/pub/scm/git/git.git
Cannot obtain needed blob 11ea73c1cc3565eeabff27ef2d3619a5fb5381fd
while processing commit abb503d1fc5802e5de9d5b4a0cb710e87d2b1ba4.
Waiting for http://www.kernel.org/pub/scm/git/git.git/objects/29/d8eccef4b9cf30704eaa6428131d788675dad8
got c1c7267135b50ebc653e2c16a73ba3e5c454e1e8
got 2623ef30134cc3f2cf715ba302c3cfa2b3527a48
got 29d8eccef4b9cf30704eaa6428131d788675dad8
[{WIFEXITED(s) && WEXITSTATUS(s) == 1}], 0) = 20387
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
--- SIGCHLD (Child exited) @ 0 (0) ---
waitpid(-1, 0xbfd1ba08, WNOHANG) = -1 ECHILD (No child processes)
sigreturn() = ? (mask now [])
rt_sigaction(SIGINT, {0x808d1b0, [], 0}, {0x807ada0, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
stat64("/home", {st_mode=S_IFDIR|0755, st_size=360, ...}) = 0
stat64("/home/bsergean", {st_mode=S_IFDIR|0711, st_size=7480, ...}) = 0
stat64("/home/bsergean/sandbox", {st_mode=S_IFDIR|0755, st_size=528, ...}) = 0
stat64("/home/bsergean/sandbox/git", {st_mode=S_IFDIR|0755,
st_size=72, ...}) = 0
stat64("/home/bsergean/sandbox/git", {st_mode=S_IFDIR|0755,
st_size=72, ...}) = 0
chdir("/home/bsergean/sandbox") = 0
stat64("/bin/rm", {st_mode=S_IFREG|0755, st_size=36316, ...}) = 0
stat64(".", {st_mode=S_IFDIR|0755, st_size=528, ...}) = 0
stat64("/home/bsergean/git/bin/rm", 0xbfd1ce1c) = -1 ENOENT (No such
file or directory)
stat64("/home/bsergean/git/bin/rm", 0xbfd1ce1c) = -1 ENOENT (No such
file or directory)
stat64("/usr/local/Trolltech/Qt-4.3.0/bin/rm", 0xbfd1ce1c) = -1 ENOENT
(No such file or directory)
stat64("/usr/lib/ccache/bin/rm", 0xbfd1ce1c) = -1 ENOENT (No such file
or directory)
stat64("/home/bsergean/bin/rm", 0xbfd1ce1c) = -1 ENOENT (No such file
or directory)
stat64("/home/bsergean/bin/Linux/rm", 0xbfd1ce1c) = -1 ENOENT (No such
file or directory)
stat64("/usr/local/bin/rm", 0xbfd1ce1c) = -1 ENOENT (No such file or directory)
stat64("/home/bsergean/git/bin/rm", 0xbfd1ce1c) = -1 ENOENT (No such
file or directory)
stat64("/usr/local/Trolltech/Qt-4.3.0/bin/rm", 0xbfd1ce1c) = -1 ENOENT
(No such file or directory)
stat64("/usr/lib/ccache/bin/rm", 0xbfd1ce1c) = -1 ENOENT (No such file
or directory)
stat64("/home/bsergean/bin/rm", 0xbfd1ce1c) = -1 ENOENT (No such file
or directory)
stat64("/home/bsergean/bin/Linux/rm", 0xbfd1ce1c) = -1 ENOENT (No such
file or directory)
stat64("/usr/local/bin/rm", 0xbfd1ce1c) = -1 ENOENT (No such file or directory)
stat64("/usr/local/Trolltech/Qt-4.3.0/bin/rm", 0xbfd1ce1c) = -1 ENOENT
(No such file or directory)
stat64("/usr/lib/ccache/bin/rm", 0xbfd1ce1c) = -1 ENOENT (No such file
or directory)
stat64("/home/bsergean/bin/rm", 0xbfd1ce1c) = -1 ENOENT (No such file
or directory)
stat64("/home/bsergean/bin/Linux/rm", 0xbfd1ce1c) = -1 ENOENT (No such
file or directory)
stat64("/usr/local/bin/rm", 0xbfd1ce1c) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/distcc/bin/rm", 0xbfd1ce1c) = -1 ENOENT (No such file
or directory)
stat64("/usr/bin/rm", 0xbfd1ce1c) = -1 ENOENT (No such file or directory)
stat64("/bin/rm", {st_mode=S_IFREG|0755, st_size=36316, ...}) = 0
stat64("/bin/rm", {st_mode=S_IFREG|0755, st_size=36316, ...}) = 0
rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) = 0
clone(child_stack=0,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0xb7dab988) = 20388
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGINT, {0x807ada0, [], 0}, {0x808d1b0, [], 0}, 8) = 0
waitpid(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0) = 20388
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
--- SIGCHLD (Child exited) @ 0 (0) ---
waitpid(-1, 0xbfd1cb18, WNOHANG) = -1 ECHILD (No child processes)
sigreturn() = ? (mask now [])
rt_sigaction(SIGINT, {0x808d1b0, [], 0}, {0x807ada0, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
exit_group(1) = ?
Process 20362 detached
On 7/24/07, Benjamin Sergeant <bsergean@gmail.com> wrote:
> On 7/24/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Hi,
> >
> > On Tue, 24 Jul 2007, Benjamin Sergeant wrote:
> >
> > > I still have the segfault with 1.5.2.4. If I try to gdb it, it abort
> > > before I can do anything. Is there an environment variable that I can
> > > set to disable signal handling or something in git ?
> >
> > Did you gdb http-fetch?
> >
> > If not, please use "sh -x git-clone..." to find out what command line to
> > use.
> >
> > And when you have the command line, please use valgrind to find out where
> > the leak/corruption is.
> >
> > There are some flags that are automatically set/unset when compiling the
> > http transport, and it is not easy to know which flags are enabled in your
> > setup.
> >
> > But for starters, you might want to recompile http-fetch without -O2. My
> > gdb always has problems attributing the correct line, which does not
> > exactly make it easier for me to debug things. I could imagine your gdb
> > is as annoying.
> >
> > Ciao,
> > Dscho
>
> I got that, but it's not super-usefull ... I will try valgrind instead.
>
> [bsergean@marge1 sandbox]$ gdb /home/bsergean/git/bin/git-clone
> /tmp/corefiles/core.18531
> GNU gdb 6.6-1mdv2007.1 (Mandriva Linux release 2007.1)
> Copyright (C) 2006 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "i586-mandriva-linux-gnu"...
> "/home/bsergean/git/bin/git-clone": not in executable format: File
> format not recognized
> (no debugging symbols found)
> Using host libthread_db library "/lib/i686/libthread_db.so.1".
> Core was generated by `git-http-fetch -v -a -w remotes/origin/html
> cc13f556fc72f6f0670e61599363f6e3277'.
> Program terminated with signal 6, Aborted.
> #0 0xbfffe410 in __kernel_vsyscall ()
> (gdb) where
> #0 0xbfffe410 in __kernel_vsyscall ()
> #1 0xb7c78590 in ?? ()
> #2 0xb7d7aff4 in ?? ()
> #3 0xb7bd7aa0 in ?? ()
> #4 0xbf928f84 in ?? ()
> #5 0xb7c79e21 in ?? ()
> #6 0x00000006 in ?? ()
> #7 0xbf928ef8 in ?? ()
> #8 0x00000000 in ?? ()
>
>
>
>
>
> >
> >
>
^ permalink raw reply
* Re: [PATCH] Teach the --cover-letter option to format-patch
From: Peter Oberndorfer @ 2007-07-24 20:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Daniel Barkalow, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0707101819350.4047@racer.site>
On Tuesday 10 July 2007 19:20, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 10 Jul 2007, Daniel Barkalow wrote:
>
> > I think this is missing the ultra-important "extra_headers" stuff, which
> > is what makes my messages actually reach the right people. That's why
> > I'd like the code shared for generating headers (except for Subject) for
> > a rev_info between the code that does it for patch messages and the code
> > for the cover letter. I think it's also missing making [PATCH 1/N] a
> > reply to it if the series is set up as replies.
>
> Ah yes. Both issues should be relatively easy to integrate into my patch.
>
> > I like the design, in any case. I want the blurb actually stored in the
> > objects directory somehow, so that I don't have to trawl through my sent
> > email for it when I send the series again for some reason, but that's a
> > relatively straightforward extension to your code. (Read an object with
> > a hash and stick the text in instead of the ***...*** parts.)
>
> I do not understand. But then, my patch should be a good starting point.
> Go wild.
>
> Ciao,
> Dscho
Anybody working on this?
Somebody, *cough* convinced me into working on this.
I already split up the existing patch into logic parts, and will now try to read message / header
from file or a commit.
Greetings Peter
^ permalink raw reply
* Re: [PATCH] Teach the --cover-letter option to format-patch
From: Daniel Barkalow @ 2007-07-24 20:19 UTC (permalink / raw)
To: Peter Oberndorfer; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <200707242212.27837.kumbayo84@arcor.de>
On Tue, 24 Jul 2007, Peter Oberndorfer wrote:
> On Tuesday 10 July 2007 19:20, Johannes Schindelin wrote:
> > Hi,
> >
> > On Tue, 10 Jul 2007, Daniel Barkalow wrote:
> >
> > > I think this is missing the ultra-important "extra_headers" stuff, which
> > > is what makes my messages actually reach the right people. That's why
> > > I'd like the code shared for generating headers (except for Subject) for
> > > a rev_info between the code that does it for patch messages and the code
> > > for the cover letter. I think it's also missing making [PATCH 1/N] a
> > > reply to it if the series is set up as replies.
> >
> > Ah yes. Both issues should be relatively easy to integrate into my patch.
> >
> > > I like the design, in any case. I want the blurb actually stored in the
> > > objects directory somehow, so that I don't have to trawl through my sent
> > > email for it when I send the series again for some reason, but that's a
> > > relatively straightforward extension to your code. (Read an object with
> > > a hash and stick the text in instead of the ***...*** parts.)
> >
> > I do not understand. But then, my patch should be a good starting point.
> > Go wild.
> >
> > Ciao,
> > Dscho
> Anybody working on this?
> Somebody, *cough* convinced me into working on this.
> I already split up the existing patch into logic parts, and will now try to read message / header
> from file or a commit.
Last night, I was thinking about it, but I hadn't actually gotten started.
If you do it, I'd suggest using an unsigned tag for the message rather
than a commit, since it fits the design for a message in an unsigned tag
(extra information about the tagged version).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] Further changes to it.po
From: Paolo Ciarrocchi @ 2007-07-24 20:38 UTC (permalink / raw)
To: git, Johannes.Schindelin
Ciao Johannes,
With the following patch applied it.po should be in a final state.
I don't expect to apply big changes to the file.
Please apply :-)
Signed-off-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
---
po/it.po | 40 ++++++++++++++++++++--------------------
1 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/po/it.po b/po/it.po
index 5fa6596..170dd02 100644
--- a/po/it.po
+++ b/po/it.po
@@ -5,7 +5,7 @@
#, fuzzy
msgid ""
msgstr ""
-"Project-Id-Version: PACKAGE VERSION\n"
+"Project-Id-Version: git-gui\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2007-07-22 12:10+0100\n"
"PO-Revision-Date: 2007-07-22 12:10+0100\n"
@@ -33,27 +33,27 @@ msgstr ""
#: git-gui.sh:1678
msgid "Merge"
-msgstr "Incorpora"
+msgstr "Fondi (Merge)"
#: git-gui.sh:1679
msgid "Fetch"
-msgstr "Prendi"
+msgstr "Prendi (Fetch)"
#: git-gui.sh:1680 git-gui.sh:2198
msgid "Push"
-msgstr "Propaga"
+msgstr "Propaga (Push)"
#: git-gui.sh:1689
msgid "Browse Current Branch's Files"
-msgstr "Naviga nei file del ramo corrente"
+msgstr "Esplora i file del ramo corrente"
#: git-gui.sh:1698
msgid "Visualize Current Branch's History"
-msgstr "Visualizza la storia del ramo corrente"
+msgstr "Visualizza la cronologia del ramo corrente"
#: git-gui.sh:1702
msgid "Visualize All Branch History"
-msgstr "Visualizza la storia di tutti i rami"
+msgstr "Visualizza lo storico di tutti i rami"
#: git-gui.sh:1707
msgid "Database Statistics"
@@ -81,7 +81,7 @@ msgstr "Annulla"
#: git-gui.sh:1743
msgid "Redo"
-msgstr "Rifai"
+msgstr "Ripeti"
#: git-gui.sh:1747 git-gui.sh:2262
msgid "Cut"
@@ -121,27 +121,27 @@ msgstr "Cancella"
#: git-gui.sh:1791
msgid "Reset..."
-msgstr "Reimposta..."
+msgstr "Ripristina..."
#: git-gui.sh:1803 git-gui.sh:2209
msgid "New Commit"
-msgstr "Nuovo Commit"
+msgstr "Nuovo commit"
#: git-gui.sh:1811 git-gui.sh:2216
msgid "Amend Last Commit"
-msgstr "Annulla l'ultimo Commit"
+msgstr "Correggi l'ultimo commit"
#: git-gui.sh:1820 git-gui.sh:2176
msgid "Rescan"
-msgstr "Analizza"
+msgstr "Rianalizza"
#: git-gui.sh:1826
msgid "Add To Commit"
-msgstr "Aggiungi al Commit"
+msgstr "Aggiungi al commit"
#: git-gui.sh:1831
msgid "Add Existing To Commit"
-msgstr "Aggiungi esistente a Commit"
+msgstr "Aggiungi esistente al commit"
#: git-gui.sh:1837
msgid "Unstage From Commit"
@@ -174,7 +174,7 @@ msgstr ""
#: git-gui.sh:1894 git-gui.sh:1941
#, tcl-format
msgid "About %s"
-msgstr "A proposito %s"
+msgstr "Informazioni su %s"
#: git-gui.sh:1896 git-gui.sh:1902 git-gui.sh:2454
msgid "Options..."
@@ -218,11 +218,11 @@ msgstr "Annulla messaggio iniziale del commit:"
#: git-gui.sh:2231
msgid "Amended Merge Commit Message:"
-msgstr "Annulla messaggio di incorporamento:"
+msgstr "Annulla messaggio di commit:"
#: git-gui.sh:2232
msgid "Merge Commit Message:"
-msgstr "Messaggio di incorporamento"
+msgstr "Fondi messaggio di commit"
#: git-gui.sh:2233
msgid "Commit Message:"
@@ -234,7 +234,7 @@ msgstr "Copia tutto"
#: git-gui.sh:2404
msgid "Refresh"
-msgstr "Aggiorna"
+msgstr "Rinfresca"
#: git-gui.sh:2425
msgid "Apply/Reverse Hunk"
@@ -242,11 +242,11 @@ msgstr "Applica/Inverti sezione"
#: git-gui.sh:2431
msgid "Decrease Font Size"
-msgstr "Diminuisci dimensione font"
+msgstr "Diminuisci dimensione carattere"
#: git-gui.sh:2435
msgid "Increase Font Size"
-msgstr "Aumenta dimensione font"
+msgstr "Aumenta dimensione carettere"
#: git-gui.sh:2440
msgid "Show Less Context"
--
1.5.3.rc2.29.gc4640f
^ permalink raw reply related
* Re: [PATCH] some feedbacks from the Italian Free Translation Project.
From: Paolo Ciarrocchi @ 2007-07-24 20:39 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <4d8e3fd30707221533t76a92616lce924e47f031928d@mail.gmail.com>
On 7/23/07, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
> On 7/23/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> [...]
> > > > Thanks. Both of your patches applied, although I had to fix non-UTF-8
> > > > encoding. This could well be a problem on my side.
> > >
> > > Odd.
> > > Is there anything I should check in my box?
> >
> > I guess that your system is set to iso-8859-1, since even your mailer says
> > "Content-Type: ... ISO-8859-1". Also, your content is "quoted-printable".
> >
> > For the time being, I can convert your patches, but you might want to
> > consider switching to UTF-8.
Was my last patch ([PATCH] Further changes to it.po) in a better shape?
Thanks.
Regards,
--
Paolo
"Tutto cio' che merita di essere fatto,merita di essere fatto bene"
Philip Stanhope IV conte di Chesterfield
^ permalink raw reply
* [PATCH] rebase -i: fix interrupted squashing
From: Johannes Schindelin @ 2007-07-24 20:43 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: git, gitster
In-Reply-To: <20070724200510.GA27610@informatik.uni-freiburg.de>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2701 bytes --]
When a squashing merge failed, the first commit would not be replaced,
due to "git reset --soft" being called with an unmerged index.
Noticed by Uwe Kleine-König.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Tue, 24 Jul 2007, Uwe Kleine-K?nig wrote:
> Johannes Schindelin wrote:
>
> > I'd appreciate if you prepared a patch with better
> > explanations, and also reviewed the man page, if it is in good
> > shape (and does not lie about the current behaviour).
>
> It's on my todo list, but not the top item for git.
Please come around to do it.
> In the mean-time I found another nuisance:
>
> [outlines the test case provided in this patch]
It would have been a bit less work for me, if you would have used
t/trash/ instead of /tmp/, and provided a patch for t3404 for me
to work with.
Alas, the bug was squashed in 5 minutes. It took me 15 minutes to
write (and test) the test.
What a difference order can make...
git-rebase--interactive.sh | 2 +-
t/t3404-rebase-interactive.sh | 30 ++++++++++++++++++++++++++++++
2 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 93289c0..78ae51e 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -258,8 +258,8 @@ do_next () {
esac
failed=f
- pick_one -n $sha1 || failed=t
output git reset --soft HEAD^
+ pick_one -n $sha1 || failed=t
author_script=$(get_author_ident_from_commit $sha1)
echo "$author_script" > "$DOTEST"/author-script
case $failed in
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index 8206436..817f614 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -221,4 +221,34 @@ test_expect_success 'multi-squash only fires up editor once' '
test 1 = $(git show | grep ONCE | wc -l)
'
+test_expect_success 'squash works as expected' '
+ for n in one two three four
+ do
+ echo $n >> file$n &&
+ git add file$n &&
+ git commit -m $n
+ done &&
+ one=$(git rev-parse HEAD~3) &&
+ FAKE_LINES="1 squash 3 2" git rebase -i HEAD~3 &&
+ test $one = $(git rev-parse HEAD~2)
+'
+
+test_expect_success 'interrupted squash works as expected' '
+ for n in one two three four
+ do
+ echo $n >> conflict &&
+ git add conflict &&
+ git commit -m $n
+ done &&
+ one=$(git rev-parse HEAD~3) &&
+ ! FAKE_LINES="1 squash 3 2" git rebase -i HEAD~3 &&
+ (echo one; echo two; echo four) > conflict &&
+ git add conflict &&
+ ! git rebase --continue &&
+ echo resolved > conflict &&
+ git add conflict &&
+ git rebase --continue &&
+ test $one = $(git rev-parse HEAD~2)
+'
+
test_done
--
1.5.3.rc2.42.gda8d
^ permalink raw reply related
* Re: [PATCH] some feedbacks from the Italian Free Translation Project.
From: Johannes Schindelin @ 2007-07-24 20:45 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: git
In-Reply-To: <4d8e3fd30707241339s7870926dw734967d9ccd6c176@mail.gmail.com>
Hi,
On Tue, 24 Jul 2007, Paolo Ciarrocchi wrote:
> On 7/23/07, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
> > On 7/23/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > [...]
> > > > > Thanks. Both of your patches applied, although I had to fix non-UTF-8
> > > > > encoding. This could well be a problem on my side.
> > > >
> > > > Odd.
> > > > Is there anything I should check in my box?
> > >
> > > I guess that your system is set to iso-8859-1, since even your mailer says
> > > "Content-Type: ... ISO-8859-1". Also, your content is "quoted-printable".
> > >
> > > For the time being, I can convert your patches, but you might want to
> > > consider switching to UTF-8.
>
> Was my last patch ([PATCH] Further changes to it.po) in a better shape?
Heh. It said US-ASCII, since there was no special character in it ;-)
Will apply after I ran to the shop to get dinner.
Ciao,
Dscho
^ permalink raw reply
* Re: workflow question
From: Alex Riesen @ 2007-07-24 20:54 UTC (permalink / raw)
To: Julian Phillips; +Cc: Patrick Doyle, git
In-Reply-To: <Pine.LNX.4.64.0707241733370.29908@reaper.quantumfyre.co.uk>
Julian Phillips, Tue, Jul 24, 2007 18:35:15 +0200:
> On Tue, 24 Jul 2007, Patrick Doyle wrote:
>
> >>> ... and I don't commit until I've completed
> >>> the particular feature I'm working on, I can get a fairly good idea of
> >>> where I am and what I was doing last (which might be 5-7 days ago,
> >>> given high priority interrupts on other projects, summer vacations,
> >>> etc...) just by running a "git status". I see that there are 7 new
> >>> files, and 2 modified files. I know that, when I fork my branch, I
> >>> can use "git diff master" to see what's different between my branch
> >>> and the master, but then I get the diff of all of the changes as well,
> >>> which is too much information. "git diff --name-only" and "git diff
> >>> --summary" are closer, but I can't tell what's been added vs. what's
> >>> been changed. Any suggestions?
> >>
> >> "git log -p ..master", or even simpler "gitk ..master"
> >I was hoping for something less verbose than a diff or a patch file --
> >something that just listed what has changed -- I'll have to
> >investigate whether your "my_status()" macro provides the information
> >for which I was looking -- thanks for the pointer.
>
> "git log --stat ..master" perhaps?
>
yep. Or just use the same options as with diff:
$ git log -r --name-status -M -C ..master
^ permalink raw reply
* Re: workflow question
From: Alex Riesen @ 2007-07-24 20:57 UTC (permalink / raw)
To: Patrick Doyle; +Cc: git
In-Reply-To: <e2a1d0aa0707240930gb99cb0csd1ce9946d33982d@mail.gmail.com>
Patrick Doyle, Tue, Jul 24, 2007 18:30:12 +0200:
> And, as for gitk, there is something about the combination of the
> screen on my laptop, my Linux installation (FC6), my X server
> configuration, and/or me that makes the fonts totally unreadable. I
> keep meaning to follow up on that, but I'm stuck in a
> chicken-and-the-egg situation. I don't see the utility of gitk
> because I can't read the display that it produces. I don't look for
> the time to fix the display that it produces because, thus far, I
> don't see the utility of gitk. Sigh...
That's a real pity, because it is very powerful.
Try removing ~/.gitk, or look into it and try changing the font.
Here is mine, for reference:
set mainfont {Helvetica 11}
set textfont {Courier 11}
set uifont {Helvetica 9 bold}
set tabstop 8
set findmergefiles 0
set maxgraphpct 50
set maxwidth 16
set cmitmode patch
set wrapcomment none
set showneartags 1
set showlocalchanges 1
set bgcolor white
set fgcolor black
set colors {green red blue magenta darkgrey brown orange}
set diffcolors {red "#00a000" blue}
set selectbgcolor gray85
set geometry(main) 1005x850+1417+41
set geometry(topwidth) 1001
set geometry(topheight) 458
set geometry(pwsash0) "684 2"
set geometry(pwsash1) "878 2"
set geometry(botwidth) 725
set geometry(botheight) 372
set permviews {}
^ permalink raw reply
* Re: workflow question
From: J. Bruce Fields @ 2007-07-24 21:00 UTC (permalink / raw)
To: Alex Riesen; +Cc: Patrick Doyle, git
In-Reply-To: <20070724205702.GD6004@steel.home>
On Tue, Jul 24, 2007 at 10:57:02PM +0200, Alex Riesen wrote:
> Patrick Doyle, Tue, Jul 24, 2007 18:30:12 +0200:
> > And, as for gitk, there is something about the combination of the
> > screen on my laptop, my Linux installation (FC6), my X server
> > configuration, and/or me that makes the fonts totally unreadable. I
> > keep meaning to follow up on that, but I'm stuck in a
> > chicken-and-the-egg situation. I don't see the utility of gitk
> > because I can't read the display that it produces. I don't look for
> > the time to fix the display that it produces because, thus far, I
> > don't see the utility of gitk. Sigh...
>
> That's a real pity, because it is very powerful.
>
> Try removing ~/.gitk, or look into it and try changing the font.
(Also, as a quick fix, note that ctrl-- and ctrl-= will adjust the font
size down or up (respectively).)
--b.
^ permalink raw reply
* [PATCH] gitweb: More detailed error messages for snapshot format
From: Jakub Narebski @ 2007-07-24 21:00 UTC (permalink / raw)
To: git; +Cc: Matt McCutchen, Jakub Narebski
Improve error messages for snapshot format in git_snapshot:
distinguish between situation where snapshots are turned off, where
snapshot format ('sf') parameter is invalid, where given snapshot
format does not exist in %known_snapshot_formats hash, and where
gitweb was given unsupported snapshot format.
While at it, use first from all supported snapshots format as default,
if no snapshot format was provided.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 13 ++++++++++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index fdfce31..708448c 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -4317,9 +4317,16 @@ sub git_snapshot {
@supported_fmts = filter_snapshot_fmts(@supported_fmts);
my $format = $cgi->param('sf');
- unless ($format =~ m/[a-z0-9]+/
- && exists($known_snapshot_formats{$format})
- && grep($_ eq $format, @supported_fmts)) {
+ if (!@supported_fmts) {
+ die_error('403 Permission denied', "Permission denied");
+ }
+ # default to first supported snapshot format
+ $format ||= $supported_fmts[0];
+ if ($format !~ m/[a-z0-9]+/) {
+ die_error(undef, "Invalid snapshot format parameter");
+ } elsif (!exists($known_snapshot_formats{$format})) {
+ die_error(undef, "Unknown snapshot format");
+ } elsif (!grep($_ eq $format, @supported_fmts)) {
die_error(undef, "Unsupported snapshot format");
}
--
1.5.2.4
^ permalink raw reply related
* [PATCH] filter-branch: fix dash complaining about "Missing '))'"
From: René Scharfe @ 2007-07-24 21:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Git Mailing List
On e.g. Ubuntu, dash is used as /bin/sh. Unlike bash it parses
commands like
a=$((echo stuff) | wc)
as an arithmetic expression while what we want is a subshell inside
a command substitution. Resolve the ambiguity by placing a space
between the two opening parentheses.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 0ff3475..b5fa449 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -298,7 +298,7 @@ do
# Assign the boundarie(s) in the set of rewritten commits
# as the replacement commit(s).
# (This would look a bit nicer if --not --stdin worked.)
- for p in $((cd "$workdir"/../map; ls | sed "s/^/^/") |
+ for p in $( (cd "$workdir"/../map; ls | sed "s/^/^/") |
git rev-list $ref --boundary --stdin |
sed -n "s/^-//p")
do
^ permalink raw reply related
* Re: [PATCH] Further changes to it.po
From: Johannes Schindelin @ 2007-07-24 21:35 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: git
In-Reply-To: <20070724223854.35715c77@paolo-desktop>
Ciao Paolo,
On Tue, 24 Jul 2007, Paolo Ciarrocchi wrote:
> Please apply :-)
Con piacere ;-)
Ciao,
Johannes
^ permalink raw reply
* Re: rfe: bisecting with a tristate
From: Robin Rosenberg @ 2007-07-24 21:39 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sean, Jan Engelhardt, git
In-Reply-To: <Pine.LNX.4.64.0707241818450.14781@racer.site>
tisdag 24 juli 2007 skrev Johannes Schindelin:
> And why exactly do you want to make it hard on the user?
Nah, I don't want to do that. Just thinking aloud ;-)
> Imagine this history:
>
> A - B - broken - bad - C
>
> Now you bisect. It goes to "broken". You compile. Darn, does not
> compile. Why not have a "git bisect dunno", which considers only the
> _rest_ of the commits for the next bisection point? When it finally found
> the "bad" one, it has to say it broke somewhere between "B..bad".
>
> Now that would be user friendly, wouldn't it?
It would work fine.
-- robin
^ permalink raw reply
* Re: workflow question
From: Linus Torvalds @ 2007-07-24 21:38 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Alex Riesen, Patrick Doyle, git
In-Reply-To: <20070724210024.GC5040@fieldses.org>
On Tue, 24 Jul 2007, J. Bruce Fields wrote:
>
> (Also, as a quick fix, note that ctrl-- and ctrl-= will adjust the font
> size down or up (respectively).)
Side note: this can be *really* confusing on non-US keyboards.
The "=" makes sense on a US keyboard, because it's really "ctrl-+" without
the added need to press "shift".
On many non-US keyboards, there is no such arrangement of +/= on the
keyboard.
So on a Finnish keyboard, for example, the sequence to make the fonts
smaller is "ctrl--", but the sequence to make them larger is
"contr-shift-0". Which makes *no* sense what-so-ever, but the "=" sign is
"shift-0".
Oh, well. On a Finnish keyboard, "ctrl-+" would make tons of sense. I
always try it, and am frustrated when it doesn't work.
Linus
^ permalink raw reply
* Re: [PATCH] Teach git-commit about commit message templates.
From: Junio C Hamano @ 2007-07-24 21:43 UTC (permalink / raw)
To: Steven Grimm; +Cc: Johannes Schindelin, git
In-Reply-To: <46A5EA2D.1030707@midwinter.com>
Steven Grimm <koreth@midwinter.com> writes:
> Junio C Hamano wrote:
> ...
>> I am more worried about how this should interact with cases
>> where you usually do not start the log message from scratch.
>> For example, are there cases / policies where being able to use
>> templates to leave comments on merge commits are needed?
>> Squash-commits? Perhaps "apply this template but only when you
>> have hand resolved a conflicting merges"?
>>
>
> Those are all valid cases. They also happen to be ones that are not
> personally useful to me; none of the stuff in my company's commit
> template would really apply to merges. I'm happy to do it if you think
> those cases need to be handled before this can go in, but given
> there's at least one user out there who doesn't need those things, I
> wonder if this makes more sense to hold off on until someone actually
> asks for it.
> ...
> Is your hunch about the common case different than mine? Again, I can
> go address this if it'll actually be useful.
No, I am way more cunning and lazy than that. I did not have
hunch about the common case, so I just had you (and anybody else
who would join the thread) do necessary thinking and guessing
for me ;-)
^ permalink raw reply
* Re: [PATCH] gitweb: More detailed error messages for snapshot format
From: Matt McCutchen @ 2007-07-24 21:50 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <11853108372532-git-send-email-jnareb@gmail.com>
On 7/24/07, Jakub Narebski <jnareb@gmail.com> wrote:
> Improve error messages for snapshot format in git_snapshot:
> distinguish between situation where snapshots are turned off, where
> snapshot format ('sf') parameter is invalid, where given snapshot
> format does not exist in %known_snapshot_formats hash, and where
> gitweb was given unsupported snapshot format.
>
> While at it, use first from all supported snapshots format as default,
> if no snapshot format was provided.
I tested the patch and it worked properly: the errors appeared at the
appropriate times and the first supported format was used as the
default.
I also noticed that the check for an "invalid" format requires that it
contain at least one good character, not that it contain no bad
characters, which was what I originally meant. It would be nice to
fix the check, or the check could even be removed altogether since
gitweb refuses any format that isn't in %known_snapshot_formats . (I
think I was misguidedly paranoid to add it in the first place.)
^ permalink raw reply
* [PATCH] cleanup unpack-trees.c: shrink struct tree_entry_list
From: René Scharfe @ 2007-07-24 21:54 UTC (permalink / raw)
To: David Kastrup, Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <85d4ykjtuc.fsf@lola.goethe.zz>
David Kastrup schrieb:
> The definition of tree_entry_list ist the following
>
> struct tree_entry_list {
> struct tree_entry_list *next;
> unsigned directory : 1;
> unsigned executable : 1;
> unsigned symlink : 1;
> unsigned int mode;
> const char *name;
> const unsigned char *sha1;
> };
>
> but it appears to me that the only of the bit fields that is used at
> all is "directory" : all other uses revert to "mode" which directory
> presumably could do as well.
>
> Is there something I am overlooking?
A C compiler can give the definite answer: no.
--- 8< ---
Remove the two write-only fields executable and symlink from struct
tree_entry_list. Also replace usage of the field directory with
S_ISDIR checks on the mode field, and then remove this now obsolete
field, too. Noticed by David Kastrup.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
This patch slightly reduces RAM usage, but it also shrinks the code
without reducing functionality or readability, which is more
interesting.
unpack-trees.c | 12 +++---------
1 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/unpack-trees.c b/unpack-trees.c
index 7cc029e..3b32718 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -11,9 +11,6 @@
struct tree_entry_list {
struct tree_entry_list *next;
- unsigned directory : 1;
- unsigned executable : 1;
- unsigned symlink : 1;
unsigned int mode;
const char *name;
const unsigned char *sha1;
@@ -38,9 +35,6 @@ static struct tree_entry_list *create_tree_entry_list(struct tree *tree)
entry->name = one.path;
entry->sha1 = one.sha1;
entry->mode = one.mode;
- entry->directory = S_ISDIR(one.mode) != 0;
- entry->executable = (one.mode & S_IXUSR) != 0;
- entry->symlink = S_ISLNK(one.mode) != 0;
entry->next = NULL;
*list_p = entry;
@@ -141,9 +135,9 @@ static int unpack_trees_rec(struct tree_entry_list **posns, int len,
#endif
if (!first || entcmp(first, firstdir,
posns[i]->name,
- posns[i]->directory) > 0) {
+ S_ISDIR(posns[i]->mode)) > 0) {
first = posns[i]->name;
- firstdir = posns[i]->directory;
+ firstdir = S_ISDIR(posns[i]->mode);
}
}
/* No name means we're done */
@@ -177,7 +171,7 @@ static int unpack_trees_rec(struct tree_entry_list **posns, int len,
continue;
}
- if (posns[i]->directory) {
+ if (S_ISDIR(posns[i]->mode)) {
struct tree *tree = lookup_tree(posns[i]->sha1);
any_dirs = 1;
parse_tree(tree);
^ permalink raw reply related
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