* New Now you have chance to do it Revel in
From: Hillary @ 2006-06-25 3:27 UTC (permalink / raw)
To: glenda
Dear client.
Have more success with women and impress them with your power and stamina in bed
You are just a couple of clicks away from our great prices and handy shipment
World’s greatest brands produce these goods in top class labs with latest technologies.
Take a look: http://www.sluggishcl.com
The quality is realt high and the prices are the cheapest on the market!
^ permalink raw reply
* Re: [PATCH 0/7] Rework diff options
From: Junio C Hamano @ 2006-06-25 3:48 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: git, Johannes Schindelin
In-Reply-To: <20060624201843.a5b4f7b9.tihirvon@gmail.com>
Timo Hirvonen <tihirvon@gmail.com> writes:
> This patch series cleans up diff output format options.
>
> This makes it possible to use any combination of --raw, -p, --stat and
> --summary options and they work as you would expect.
>
> These patches passed all test and are for the next branch. Patches 6 and
> 7 are optional.
Thanks, very nicely done. Tentatively placed all of them in
"pu"; the first "clean-up" is in "master".
Here are a few problems I have seen:
- "git show --stat HEAD" gives '---' marker as Johannes and you
have already discussed (I do not mind this that much though);
- "--cc" seems to be quite broken. "git show v1.0.0" nor "git
diff-tree --pretty --cc v1.0.0" does not give the log
message, and gives something quite confused instead. I think
it is showing "-m -p" followed by "--cc".
We may find more minor breakages, in addition to these, but I am
reasonably sure we should be able to fix them in-tree.
^ permalink raw reply
* Re: [RFC] git-fetch - repack in the background after fetching
From: Linus Torvalds @ 2006-06-25 3:53 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git, junkio
In-Reply-To: <11511486003924-git-send-email-martin@catalyst.net.nz>
On Sat, 24 Jun 2006, Martin Langhoff wrote:
>
> Check whether we have a large set of unpacked objects and repack
> after the fetch, but don't for the user to wait for us. Conditional
> on core.autorepack =! no.
I don't think this is safe.
It's also done stupidly.
Instead of askign how many unpacked objects we have with the (expensive)
git-rev-list, why not just do
ls "$GIT_DIR/objects/00" | wc -l
which is pretty much guaranteed to be faster and easier.
However, the more worrisome thing about background repacking is that while
it should be safe against normal users, if you have two _repacks_ at the
same time, they can decide to remove each others packs. Yeah, yeah, that's
pretty damn unlikely, but hey, "pretty damn unlikely" is not "impossible".
Also, I think you'd want to repack with "-l", in case the thing is set up
with an alternate object directory.
Linus
^ permalink raw reply
* Re: PPC SHA-1 Updates in "pu"
From: Junio C Hamano @ 2006-06-25 3:57 UTC (permalink / raw)
To: Petr Baudis; +Cc: Linus Torvalds, git
In-Reply-To: <20060625012435.GZ21864@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
>> - RPM target -- we probably acquired a new build-dependency in
>> which case the .spec file needs to be updated;
>
> Well, perl is currently not listed even as a runtime dependency,
> so does it really need to be listed as a build dependency?
Really? I think rpmbuild is getting anything that matches "^use "
and listing the perl modules as dependencies.
>> - Make sure Git.xs builds and installed result works fine on
>> all platforms we care about, including Cygwin and other
>> non-Linux boxes.
>
> Unfortunately I don't have access to a lot of those. :-(
I don't either. That's why I would want to place something
low-impact on "next" to ask help from the users.
>> I'd even suggest we revert the changes to git-fmt-merge-msg to
>> keep it working for now, until the above worries are resolved.
>> Otherwise we cannot have it in "next" safely (and I REALLY _do_
>> want to have Git.pm infrastructure in "next" soonish).
>
> Yes, that sounds reasonable.
>
>> We can start using Git.xs and friends in some _new_ ancillary
>> programs, once we solve building and installing problems for
>> everybody. That way it would help us gain portability and
>> confidence without disrupting existing users.
>
> Well, I don't think it's very likely that Git.pm per se would be buggy
> on a certain specific platform - it should either work as well as
> everywhere else or not build at all, in which case you have disrupted
> the existing users anyway. :-) (But without disrupting anyone we won't
> get any bugreports and never get it fixed.)
>
> Perhaps other converted perl scripts can linger at least on the pu
> branch?
My preference is to keep your other conversion in "later"
mailbox, not even in "pu", to keep them from distracting me.
I'd like to have something low-impact (e.g. "git-mv" which I do
not use and I do not think Linus uses) along with the perl/
directory and build procedure in "next" soonish to make sure at
least things build and correctly install for everybody
(compiling and linking alone would not count as "correctly
install" while we have something like INSTALLSITEARCH gotcha).
After we are reasonably confident about the whole .xs stuff we
can revert the revert of git-fmt-merge-msg.
^ permalink raw reply
* Re: [PATCH 1/3] rebase: allow --merge option to handle patches merged upstream
From: Eric Wong @ 2006-06-25 4:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0606250401490.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Sat, 24 Jun 2006, Eric Wong wrote:
>
> > + if test -n "`git-diff-index HEAD`"
>
> This is not a sufficient test if the patch was already merged to upstream.
> For example, you can have two patches which touched the same file, and one
> of them was applied to upstream, the other not. The test fails to see
> that. Or am I missing something?
This is just to tell if there's anything worth committing after a merge
is complete. If not, then it assumes it's been a) merged upstream or b)
empty in the first place (very unlikely).
--
Eric Wong
^ permalink raw reply
* Re: [PATCH 1/7] Git.pm: Introduce ident() and ident_person() methods
From: Junio C Hamano @ 2006-06-25 5:25 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060625015751.GB21864@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
>> diff --git a/git-send-email.perl b/git-send-email.perl
>> index e794e44..79e82f5 100755
>> --- a/git-send-email.perl
>> +++ b/git-send-email.perl
>
> BTW, please tell me if you want to redo the patches without any script
> updates (and how large portion of the patches to resend; my stg stack
> now has 28 patches and I'm finally using it for some real workload!)
> - given that the plan is to have the converted scripts only in pu
> (or entirely outside your tree) but full-fledged Git.pm in tree.
I'd avoid asking you to resend, but give me some time to see how
the series looks like first.
^ permalink raw reply
* Re: [PATCH] Rename safe_strncpy() to strlcpy().
From: Junio C Hamano @ 2006-06-25 5:29 UTC (permalink / raw)
To: Peter Eriksen; +Cc: git
In-Reply-To: <20060624140124.GA1323@ebar092.ebar.dtu.dk>
"Peter Eriksen" <s022018@student.dtu.dk> writes:
> This cleans up the use of safe_strncpy() even more. Since it has the
> same semantics as strlcpy() use this name instead.
> ---
>
> I've introduced a NO_STRLCPY variable in the Makefile. What do
> you think about this?
No strong preference -- I can go with either name. But people
with more BSD exposure than I am are probably used to see this
function as strlcpy(), so if that is the case let's use this
patch.
Thanks.
^ permalink raw reply
* Re: [PATCH] git-commit: filter out log message lines only when editor was run.
From: Marco Costalba @ 2006-06-25 7:08 UTC (permalink / raw)
To: Yann Dirson; +Cc: junkio, GIT list
In-Reply-To: <20060624094217.GB7851@nowhere.earth>
On 6/24/06, Yann Dirson <ydirson@altern.org> wrote:
> Junio wrote:
> > I agree with this in principle but we would need to make sure
> > that our own scripts do not expect that the message is cleaned
> > up when feeding a commit log message via stdin, -m or -F, and if
> > they do fix them before applying this patch.
>
> The only tools in git.git I could identify as using git-commit rather
> than commit-tree are:
>
> git-revert.sh: OK
> git-rebase.sh: only uses -C
>
> cogito, stgit, and pg also use commit-tree. Only qgit seems to be
> using git-commit, and probably makes use of this (mis)feature.
>
Yes, qgit uses git-commit, but issue is different.
qgit uses the output of git status as a 'default text' used in the
commit dialog. When commit button is pressed, after some message
editing by the user, the comment lines are stripped _before_ to save
the content of commit message in a temporary file to be used by
git-commit with -F option.
The comment stripping is done by this code:
msg = textEditMsg->text();
msg.remove(QRegExp("\\n\\s*#[^\\n]*")); // strip comments
msg.replace(QRegExp("[ \\t\\r\\f\\v]+\\n"), "\n"); // strip line trailing cruft
msg = msg.stripWhiteSpace();
as you see it rely on the '#' character.
So conclusions are:
1) It's ok to let git-comit do not strip comment lines, it's already
done by qgit.
2) Please don't change git status output to use another symbol to mark
comment lines because it will break line stripping code.
Marco
^ permalink raw reply
* Re: [PATCH] git-commit: filter out log message lines only when editor was run.
From: Yann Dirson @ 2006-06-25 7:21 UTC (permalink / raw)
To: Marco Costalba; +Cc: junkio, GIT list
In-Reply-To: <e5bfff550606250008k702acfadm8860e9b672bced56@mail.gmail.com>
On Sun, Jun 25, 2006 at 09:08:02AM +0200, Marco Costalba wrote:
> 1) It's ok to let git-comit do not strip comment lines, it's already
> done by qgit.
That's great news :)
> 2) Please don't change git status output to use another symbol to mark
> comment lines because it will break line stripping code.
If it ever gets changed, it should anyway IMHO be made a parameter. A
strategy could be to make it customizable first, advertize this loudly
so tools adapt themselves to force the prefix to what suits them best,
and then eventually change the default in a major release.
Best regards,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: [PATCH] cvsimport: setup indexes correctly for ancestors and incremental imports
From: Petr Baudis @ 2006-06-25 8:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Martin Langhoff, git
In-Reply-To: <7v64iqq6ab.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sun, Jun 25, 2006 at 05:10:36AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Please please please do not use --- between the cover letter and
> commit message body if you choose to do the cover letter first.
Oops, I suspect that I'm a huge offender in this regard in that case.
Can I format my patch mails so that they look like natural replies _and_
you can still apply them easily?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: [RFC] git-fetch - repack in the background after fetching
From: Johannes Schindelin @ 2006-06-25 9:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Martin Langhoff, git, junkio
In-Reply-To: <Pine.LNX.4.64.0606242049500.3747@g5.osdl.org>
Hi,
On Sat, 24 Jun 2006, Linus Torvalds wrote:
> However, the more worrisome thing about background repacking is that while
> it should be safe against normal users, if you have two _repacks_ at the
> same time, they can decide to remove each others packs. Yeah, yeah, that's
> pretty damn unlikely, but hey, "pretty damn unlikely" is not "impossible".
Why not introduce a lock file for repack?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] cvsimport: setup indexes correctly for ancestors and incremental imports
From: Johannes Schindelin @ 2006-06-25 9:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64iqq6ab.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sat, 24 Jun 2006, Junio C Hamano wrote:
> Please please please do not use --- between the cover letter and commit
> message body if you choose to do the cover letter first.
Sorry. Will not happen again.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] cvsimport: setup indexes correctly for ancestors and incremental imports
From: Junio C Hamano @ 2006-06-25 9:27 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, Martin Langhoff, git
In-Reply-To: <20060625085359.GC21864@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Dear diary, on Sun, Jun 25, 2006 at 05:10:36AM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
>> Please please please do not use --- between the cover letter and
>> commit message body if you choose to do the cover letter first.
>
> Oops, I suspect that I'm a huge offender in this regard in that case.
> Can I format my patch mails so that they look like natural replies _and_
> you can still apply them easily?
It's not a big deal.
I do it with scissors mark "-- >8 --" because I can use "git-am"
while still in GNUS with '|' (gnus-summary-pipe-output) on the
message, and immediately after that I can amend the commit with
"git-commit --amend" to remove everything up to the scissors
mark.
If you have --- then I have to save the message in a separate
file with 'C-o' (gnus-summary-save-article-mail), open the file
and remove up to that first --- in the editor, and then run
git-am on the file.
Only when the cover letter is short, I'd prefer Linus style,
which places cover letter material after the --- and the
diffstat, although that makes the message like top-posting.
^ permalink raw reply
* Re: [PATCH 7/7] Convert git-annotate to use Git.pm
From: Ryan Anderson @ 2006-06-25 9:27 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20060625015434.29906.23422.stgit@machine.or.cz>
On Sun, Jun 25, 2006 at 03:54:34AM +0200, Petr Baudis wrote:
> -sub open_pipe {
> - if ($^O eq '##INSERT_ACTIVESTATE_STRING_HERE##') {
> - return open_pipe_activestate(@_);
> - } else {
> - return open_pipe_normal(@_);
> - }
> -}
> -
> -sub open_pipe_activestate {
> - tie *fh, "Git::ActiveStatePipe", @_;
> - return *fh;
> -}
> -
> -sub open_pipe_normal {
> - my (@execlist) = @_;
> -
> - my $pid = open my $kid, "-|";
> - defined $pid or die "Cannot fork: $!";
> -
> - unless ($pid) {
> - exec @execlist;
> - die "Cannot exec @execlist: $!";
> - }
> -
> - return $kid;
> -}
I don't see that Git.pm provides the compatibility functionality we have
stubbed out, here.
(It clearly has never been used, because there hasn't been a patch to
set the actual ActiveState string there.. 'MSWin32', btw.)
I suspect that the other scripts, that have more users, will see
regression complaints when the qx() calls get replaced by calls to
open(my $fh, "-|"), indirectly, in Git.pm
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: PPC SHA-1 Updates in "pu"
From: Petr Baudis @ 2006-06-25 9:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vfyhtopjm.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sun, Jun 25, 2006 at 05:57:33AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@suse.cz> writes:
>
> >> - RPM target -- we probably acquired a new build-dependency in
> >> which case the .spec file needs to be updated;
> >
> > Well, perl is currently not listed even as a runtime dependency,
> > so does it really need to be listed as a build dependency?
>
> Really? I think rpmbuild is getting anything that matches "^use "
> and listing the perl modules as dependencies.
I had on my mind to depend only on modules that are part of the default
Perl distribution, since installing them from CPAN is a bother if you
are installing Git to your home directory. That is why we bundle Error.
All the modules we depend on should come bundled with Perl since 5.8.1.
Now, I'm not sure what our "cutoff" point is, and even if it is
something like 5.6.0 whether we can just require users of Perl older
than 5.8.1 (which should be only some rare and obscure systems anyway)
to install the modules from CPAN.
If not, we can just get rid of Scalar::Util and XSLoader and we should
be clean; XSLoader should be easy, Scalar::Util somewhat more messy
since we will have to get Error.pm own .xs as well.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: [PATCH 7/7] Convert git-annotate to use Git.pm
From: Petr Baudis @ 2006-06-25 9:36 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Junio C Hamano, git
In-Reply-To: <20060625092719.GH3154@h4x0r5.com>
Dear diary, on Sun, Jun 25, 2006 at 11:27:23AM CEST, I got a letter
where Ryan Anderson <ryan@michonline.com> said that...
> I don't see that Git.pm provides the compatibility functionality we have
> stubbed out, here.
Please see [PATCH 2/7] Git.pm: Try to support ActiveState output pipe.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* What's in git.git
From: Junio C Hamano @ 2006-06-25 9:37 UTC (permalink / raw)
To: git
No v1.4.1-rc2 this weekend, as I am expecting a visitor today
and will mostly be offline. But we got a dozen or so good fixes
and cleanups in "master" so far.
In "next", we have the following being cooked. I expect most of
them to be in v1.4.1-rc2 sometime next week. Please report
breakage on any of these if you see one.
- "git rebase --merge" updates by Eric Wong.
- "git diff -b -w" by Johannes.
- "git cvsimport" multi-branch fixes by Martin and Johannes.
- "git diff --color" can be controlled from $GIT_DIR/config.
- "git merge --squash"; this may not be strictly needed as it
can be emulated with repeated use of "cherry-pick -n" but it
might be handy in some workflows.
In "pu", I have queued other bigger changes. I do not think
most of them are v1.4.1 material yet.
- "git format-patch --ignore-already-merged" fixes by
Johannes; I am hoping to have this in v1.4.1.
- Perl scripts clean-up and Git.xs by Pasky with a few fixes by
me; in my mailbox there are several other patches in this
series not in "pu" that primarily makes more scripts to use
the new Perl infrastructure. My feeling is that the series
needs to be proven to have a sound infrastructure (building,
testing and installation) on a bit wider platforms before
starting to consider them for inclusion in "next". We may be
able to have the basics from this series in v1.4.1, but am
still uneasy to convert any important scripts to use this,
even in "next", at this moment. Not just yet.
- built-in "git am" by Lukas; it fails some tests which is not
a good sign, and as I said in a separate message a few days
ago, I think it is not worth going this route for something
high-level as "am", so probably the next round I'd drop the
last patch from the topic. The patch to clean up cmd_apply()
might be worth keeping and merging in "next", depending on
how the Git.xs effort goes, though.
- "git diff" option clean-ups by Timo Hirvonen; this is moving
things in a good direction but as with any intrusive cleanups
still has some rough edges. I am hoping we can round them
off soon to merge it in "next".
- A new PPC SHA-1 implementation by linux@horizon.com; Linus
showed that this does not make much difference in real life
from performance point of view. If it has other benefits
(such as code size -- which I do not know how it fares), I am
willing to merge it as it seems to be correct and does not
seem to introduce regressions. But I am not a PPC user so
somebody needs to push my back on this one.
----------------------------------------------------------------
* The 'master' branch has these since the last announcement.
Jeff King:
git-commit: allow -e option anywhere on command line
Johannes Schindelin:
patch-id: take "commit" prefix as well as "diff-tree" prefix
apply: replace NO_ACCURATE_DIFF with --inaccurate-eof runtime flag.
Junio C Hamano:
Makefile: do not recompile main programs when libraries have changed.
usage: minimum type fix.
git-pull: abort when fmt-merge-msg fails.
diff --color: use reset sequence when we mean reset.
repo-config: fix printing of bool
Linus Torvalds:
Tweak diff colors
Martin Langhoff:
git-repack -- respect -q and be quiet
Matthias Kestenholz:
add GIT-CFLAGS to .gitignore
Peter Eriksen:
Rename safe_strncpy() to strlcpy().
Petr Baudis:
Customizable error handlers
Timo Hirvonen:
git-merge: Don't use -p when outputting summary
Clean up diff.c
Yann Dirson:
git-commit: filter out log message lines only when editor was run.
* The 'next' branch, in addition, has these.
Eric Wong:
rebase: allow --merge option to handle patches merged upstream
rebase: cleanup rebasing with --merge
rebase: allow --skip to work with --merge
Johannes Schindelin:
Teach diff about -b and -w flags
cvsimport: always set $ENV{GIT_INDEX_FILE} to $index{$branch}
Junio C Hamano:
Makefile: add framework to verify and bench sha1 implementations.
git-merge --squash
test-sha1: test hashing large buffer
diff --color: use $GIT_DIR/config
Martin Langhoff:
cvsimport: setup indexes correctly for ancestors and incremental imports
* The 'pu' branch, in addition, has these (this fails the tests).
Johannes Schindelin:
add diff_flush_patch_id() to calculate the patch id
format-patch: introduce "--ignore-if-in-upstream"
Junio C Hamano:
Perl interface: add build-time configuration to allow building with -fPIC
Perl interface: make testsuite work again.
perl: fix make clean
Git.pm: tentative fix to test the freshly built Git.pm
Lukas Sandström:
Make it possible to call cmd_apply multiple times
Make git-am a builtin
Petr Baudis:
Introduce Git.pm (v4)
Git.pm: Implement Git::exec_path()
Git.pm: Call external commands using execv_git_cmd()
Git.pm: Implement Git::version()
Add Error.pm to the distribution
Git.pm: Better error handling
Git.pm: Handle failed commands' output
Git.pm: Enhance the command_pipe() mechanism
Git.pm: Implement options for the command interface
Git.pm: Add support for subdirectories inside of working copies
Convert git-mv to use Git.pm
Git.pm: assorted build related fixes.
Timo Hirvonen:
Merge with_raw, with_stat and summary variables to output_format
Make --raw option available for all diff commands
Set default diff output format after parsing command line
DIFF_FORMAT_RAW is not default anymore
--name-only, --name-status, --check and -s are mutually exclusive
Remove awkward compatibility warts
Unknown (linux@horizon.com):
A better-scheduled PPC SHA-1 implementation.
^ permalink raw reply
* Re: PPC SHA-1 Updates in "pu"
From: Johannes Schindelin @ 2006-06-25 10:07 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <20060625093444.GD21864@pasky.or.cz>
Hi,
On Sun, 25 Jun 2006, Petr Baudis wrote:
> All the modules we depend on should come bundled with Perl since 5.8.1.
> Now, I'm not sure what our "cutoff" point is, and even if it is
> something like 5.6.0 whether we can just require users of Perl older
> than 5.8.1 (which should be only some rare and obscure systems anyway)
> to install the modules from CPAN.
NO! It is _wrong_ to require users to upgrade, when a little more work on
our side would fix it. Requiring users to upgrade is a proactive way to
get rid of new users.
And old ones. If you would require me to upgrade to Perl 5.8.1, I would
rather stop upgrading git. Hell, something I really like about git: I just
download the tar.gz, unpack it, and type make install. And usually that
Just Works. (Except MinGW32, but I have already managed to see a nice
"git-log -p" with it.)
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Repack should try to prevent itself from running twice, concurrently.
From: Ryan Anderson @ 2006-06-25 10:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Ryan Anderson
In-Reply-To: <7vy7vmormn.fsf@assigned-by-dhcp.cox.net>
Signed-off-by: Ryan Anderson <ryan@michonline.com>
---
git-repack.sh | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/git-repack.sh b/git-repack.sh
index eb75c8c..20f9b55 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -24,6 +24,15 @@ do
shift
done
+if [ -f $GIT_DIR/repack.lock ]
+then
+ echo "Existing repack job appears to be running."
+ echo "Remove $GIT_DIR/repack.lock if this is not the case."
+ exit 1
+else
+ echo $$ > $GIT_DIR/repack.lock
+fi
+
rm -f .tmp-pack-*
PACKDIR="$GIT_OBJECT_DIRECTORY/pack"
@@ -83,3 +92,5 @@ case "$no_update_info" in
t) : ;;
*) git-update-server-info ;;
esac
+
+rm $GIT_DIR/repack.lock
--
1.4.1.rc1.gacb70
^ permalink raw reply related
* New web frontend: gitarella
From: Johannes Schindelin @ 2006-06-25 10:13 UTC (permalink / raw)
To: git, flameeyes
Hi,
just to inform you I saw gitarella announced on freshmeat. It is inspired
by gitweb, but written in Ruby.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Repack should try to prevent itself from running twice, concurrently.
From: Johannes Schindelin @ 2006-06-25 10:17 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Junio C Hamano, git
In-Reply-To: <11512302144123-git-send-email-ryan@michonline.com>
Hi,
On Sun, 25 Jun 2006, Ryan Anderson wrote:
> +if [ -f $GIT_DIR/repack.lock ]
> +then
> + echo "Existing repack job appears to be running."
> + echo "Remove $GIT_DIR/repack.lock if this is not the case."
> + exit 1
> +else
> + echo $$ > $GIT_DIR/repack.lock
> +fi
It is not like it is being an atomic operation, but then, we are not going
to call repack multiple times a second. I'd say it is sufficient.
Ciao,
Dscho
^ permalink raw reply
* Re: PPC SHA-1 Updates in "pu"
From: Petr Baudis @ 2006-06-25 10:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.63.0606251202320.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
Dear diary, on Sun, Jun 25, 2006 at 12:07:21PM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> On Sun, 25 Jun 2006, Petr Baudis wrote:
>
> > All the modules we depend on should come bundled with Perl since 5.8.1.
> > Now, I'm not sure what our "cutoff" point is, and even if it is
> > something like 5.6.0 whether we can just require users of Perl older
> > than 5.8.1 (which should be only some rare and obscure systems anyway)
> > to install the modules from CPAN.
>
> NO! It is _wrong_ to require users to upgrade, when a little more work on
> our side would fix it. Requiring users to upgrade is a proactive way to
> get rid of new users.
>
> And old ones. If you would require me to upgrade to Perl 5.8.1, I would
> rather stop upgrading git.
please read it again - I'm not requiring you to upgrade to Perl 5.8.1.
I'm just saying that if you have Perl older than 5.8.1, you might need
to install some extra modules from CPAN.
Now, if that's not acceptable either that's fine by me and I can
adapt, I just need to know at which point we _will_ require you to
upgrade or install extra modules.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: [RFC] GIT user survey
From: Paolo Ciarrocchi @ 2006-06-25 10:47 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Git Mailing List
In-Reply-To: <46a038f90606241642q1467d577q329412f4ad09da34@mail.gmail.com>
On 6/25/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> Paolo,
>
> I've seen in the irc logs that you were wondering whether we could a
> web-based survey tool. Perhaps I can setup Moodle with an
> easy-to-fillout survey. Interested?
Yes, that would be really fantastic!!
Here is the latest version of the survey, including the comments I
received so far:
About you
1. What country are you in?
2. What is your preferred language?
3. What's your gender?
Getting started with GIT
1. How did you hear about GIT?
2. Did you find GIT easy to learn?
3. What helped you most in learning to use it?
How you use GIT
1. Do you use GIT for work, unpaid projects, or both?
2. How do you obtain GIT? Source tarball, binary package, or
pull the main repository?
3. What platforms (hardware, OS, version) do you use GIT on?
4. How many people do you collaborate with using GIT?
5. How big are the repositories that you work on? (e.g. how many
files, how much disk space)
6. How many different projects do you manage using GIT?
7. Which porcelains do you use?
What you think of GIT
1. Overall, how happy are you with GIT?
2. How does GIT compare to other SCM tools you have used?
3. What do you like about using GIT?
4. What would you most like to see improved about GIT?
(features, bugs, plugins, documentation, ...)
5. If you want to see GIT more widely used, what do you
think we could do to make this happen?
Documentation
1. Do you use the GIT wiki? If yes, do you find it useful?
2. Do you find GIT's online help useful?
3. What is your favourite user documentation for any software
projects or products you have used?
4. What could be improved on the GIT homepage?
Getting help, staying in touch
1. Have you tried to get GIT help from other people?
* If yes, did you get these problems resolved quickly and to
your liking?
2. Do you subscribe to the mailing list?
* If yes, do you find it useful, and traffic levels OK?
3. Do you use the IRC channel (#git on irc.freenode.net)?
* If no, did you know that all of the core developers use
IRC, and that there's almost 24-hour help available?
Open forum
1. What other comments or suggestions do you have that are not
covered by the questions above?
Ciao,
--
Paolo
http://paolociarrocchi.googlepages.com
http://picasaweb.google.com/paolo.ciarrocchi
^ permalink raw reply
* Re: PPC SHA-1 Updates in "pu"
From: Junio C Hamano @ 2006-06-25 10:48 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, Johannes Schindelin, Linus Torvalds, Randal L. Schwartz
In-Reply-To: <20060625102037.GI29364@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
>> And old ones. If you would require me to upgrade to Perl 5.8.1, I would
>> rather stop upgrading git.
>
> please read it again - I'm not requiring you to upgrade to Perl 5.8.1.
> I'm just saying that if you have Perl older than 5.8.1, you might need
> to install some extra modules from CPAN.
>
> Now, if that's not acceptable either that's fine by me and I can
> adapt, I just need to know at which point we _will_ require you to
> upgrade or install extra modules.
I vaguely recall that last time we discussed the minimum Perl
version requirement somebody perhaps Merlyn said 5.6 is old
enough but in some corporate settings people may still be stuck
with 5.004.
Tentatively let's say our cut-off point is somewhere around 5.6.
If we can get away without relying on extra from CPAN that would
be great. Otherwise as long as the modules from CPAN we end up
depending on are all compatible with the cut-off version of Perl
that would be acceptable. We might even try to be nicer and
carry a straight copy of what we require from CPAN in compat/
just like we have subprocess.py there (modulo licensing worries
if any, of course).
Johannes, Linus and the list, would that be a good enough
guideline?
^ permalink raw reply
* Re: New web frontend: gitarella
From: Marco Costalba @ 2006-06-25 10:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, flameeyes
In-Reply-To: <Pine.LNX.4.63.0606251211490.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On 6/25/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> just to inform you I saw gitarella announced on freshmeat. It is inspired
> by gitweb, but written in Ruby.
>
It's amazing to see in how many different ways a lot of people try to
find an (almost the same) solution for (almost) the same problem. IMHO
this is one of the main differences between developing for fun and as
a day job.
Welcome abroad gitarella.
Marco
P.S: BTW gitarella, pronounced with the 'gi' like in 'giant' it means
"little trip" in Italian.
^ 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