* Re: Switching from CVS to GIT
From: Eli Zaretskii @ 2007-10-15 21:08 UTC (permalink / raw)
To: git; +Cc: raa.lkml, Johannes.Schindelin, git, ae, tsuna
In-Reply-To: <4713C81F.A75FEFC2@dessent.net>
> Date: Mon, 15 Oct 2007 13:05:51 -0700
> From: Brian Dessent <brian@dessent.net>
> CC: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
> git@vger.kernel.org, Eli Zaretskii <eliz@gnu.org>, ae@op5.se,
> tsuna@lrde.epita.fr
>
> I don't know of
> any ports of bash that aren't MSYS or Cygwin based. However I do think
> there's a native port of zsh out there by the GnuWin32 project, which
> when renamed as just "/bin/sh" might be suitable, but only if these
> scripts don't use bash-isms. I have not tried this zsh myself and
> speed/compatibility wise I'm not sure it's up to snuff.
I think you mean Amol's zsh (there's no GnuWin32 port of zsh AFAIK).
Amol's zsh is what I use, but it has a few annoying bugs, even after I
fixed some, that prevent it from running a typical configure script,
for example.
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Eli Zaretskii @ 2007-10-15 21:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: raa.lkml, brian, git, ae, tsuna
In-Reply-To: <Pine.LNX.4.64.0710152057580.25221@racer.site>
> Date: Mon, 15 Oct 2007 20:58:26 +0100 (BST)
> From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> cc: Alex Riesen <raa.lkml@gmail.com>, brian@dessent.net, git@vger.kernel.org,
> ae@op5.se, tsuna@lrde.epita.fr
>
> On Mon, 15 Oct 2007, Eli Zaretskii wrote:
>
> > > From: Alex Riesen <raa.lkml@gmail.com>
> >
> > > For instance, I avoid starting the test suite on my XP workstation at
> > > work: it locks up hard every time.
> >
> > Sounds like a bug to me.
>
> To me, too. Alas, it works on W2k, so where is the bug?
I'm not smart enough to know without debugging it. W2K and WXP have
different system libraries and somewhat different memory layouts. A
bug can get away on one, but not on the other.
^ permalink raw reply
* Re: [PATCH 0/7] Bisect dunno
From: Geert Bosch @ 2007-10-15 20:33 UTC (permalink / raw)
To: David Symonds
Cc: Wincent Colaiuta, Johan Herland, git, Marius Storm-Olsen,
David Kastrup, Christian Couder, René Scharfe ,
Junio Hamano, Johannes Schindelin
In-Reply-To: <ee77f5c20710150453g1220d968k9a23f2b8329a67db@mail.gmail.com>
On Oct 15, 2007, at 13:53, David Symonds wrote:
> That's also why I suggested "skip"; you might not be able to test a
> particular commit, but you might also not *want* to test a particular
> commit for some reason.
Skip seems a great choice: it directly expresses the wish to
not consider a certain commit. The reason is unimportant.
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Johannes Schindelin @ 2007-10-15 20:46 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Git Mailing List, Alex Riesen, Eli Zaretskii, Andreas Ericsson,
tsuna
In-Reply-To: <7287AD62-3274-4B20-881C-D02E08C4B2EF@zib.de>
Hi,
On Mon, 15 Oct 2007, Steffen Prohaska wrote:
> On Oct 15, 2007, at 10:19 PM, Johannes Schindelin wrote:
>
> > There is a port of BusyBox' dash, which is nearing completion. Once
> > Nguyen says it is ready enough, we will try to integrate it into
> > msysGit.
>
> Gnuarch [1] recommends zsh from the unxutils project [2].
I have the slight suspicion that we will somehow have problems with
/etc/gitconfig, /share/git-gui/ and friends, should we try to use zsh. At
least with gitbox, we can hack a "/" translation for scripts.
Ciao,
Dscho
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Steffen Prohaska @ 2007-10-15 20:43 UTC (permalink / raw)
To: Git Mailing List
Cc: Alex Riesen, Eli Zaretskii, Andreas Ericsson, tsuna,
Johannes Schindelin
In-Reply-To: <Pine.LNX.4.64.0710152117290.25221@racer.site>
On Oct 15, 2007, at 10:19 PM, Johannes Schindelin wrote:
>> I think you may be stuck on the shell though -- I don't know of any
>> ports of bash that aren't MSYS or Cygwin based. However I do think
>> there's a native port of zsh out there by the GnuWin32 project, which
>> when renamed as just "/bin/sh" might be suitable, but only if these
>> scripts don't use bash-isms. I have not tried this zsh myself and
>> speed/compatibility wise I'm not sure it's up to snuff.
I can't find zsh on the GnuWin32 project page.
> There is a port of BusyBox' dash, which is nearing completion. Once
> Nguyen says it is ready enough, we will try to integrate it into
> msysGit.
Gnuarch [1] recommends zsh from the unxutils project [2].
Steffen
[1] http://www.gnuarch.org/gnuarchwiki/Native_WIN32_Support
[2] http://unxutils.sourceforge.net/
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Johannes Schindelin @ 2007-10-15 20:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Alex Riesen, Eli Zaretskii, ae, tsuna
In-Reply-To: <alpine.LFD.0.999.0710151321560.6887@woody.linux-foundation.org>
Hi,
On Mon, 15 Oct 2007, Linus Torvalds wrote:
> On Mon, 15 Oct 2007, Johannes Schindelin wrote:
> >
> > Bash we can fix in the long run (this goes under the keyword
> > "builtinification" on the git list)
>
> I thought busybox was being used for the core commands? Is ash not
> complete/usable enough (with all the fixes git has had for broken
> shells) to be used?
No, not yet. The problem is not so much ash, as Nguyen, who said that
gitbox is not there yet.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Documentation/git-tag.txt: Document how to backdate tags
From: Jeff King @ 2007-10-15 20:35 UTC (permalink / raw)
To: Michael Olson; +Cc: Junio C Hamano, git
In-Reply-To: <87lka4cllp.fsf@hariken.mwolson.org>
On Mon, Oct 15, 2007 at 01:51:30PM -0400, Michael Olson wrote:
> +On Backdating Tags
> +~~~~~~~~~~~~~~~~~~
> +
> +If you have imported some changes from another VCS and would like
> +to add tags for major releases of you work, it is useful to be able
s/you/your/
-Peff
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Linus Torvalds @ 2007-10-15 20:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Alex Riesen, Eli Zaretskii, ae, tsuna
In-Reply-To: <Pine.LNX.4.64.0710152026260.25221@racer.site>
On Mon, 15 Oct 2007, Johannes Schindelin wrote:
>
> Bash we can fix in the long run (this goes under the keyword
> "builtinification" on the git list)
I thought busybox was being used for the core commands? Is ash not
complete/usable enough (with all the fixes git has had for broken shells)
to be used?
I do agree that perl looks unavoidable, but I thought the windows port
already avoided at least bash. Not true?
(or is it just that even with ash, you end up hitting all the same issues
with cygwin/msys?)
Linus
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Johannes Schindelin @ 2007-10-15 20:19 UTC (permalink / raw)
To: git; +Cc: Alex Riesen, Eli Zaretskii, ae, tsuna
In-Reply-To: <4713C81F.A75FEFC2@dessent.net>
Hi,
On Mon, 15 Oct 2007, Brian Dessent wrote:
> Well, instead of using an MSYS build of Perl there's always ActiveState
> Perl.
No, but thanks no. You haven't been around long enough on this list to
count the issues, but it is known that ActiveState Perl is close to
Malbolge.
> I think you may be stuck on the shell though -- I don't know of any
> ports of bash that aren't MSYS or Cygwin based. However I do think
> there's a native port of zsh out there by the GnuWin32 project, which
> when renamed as just "/bin/sh" might be suitable, but only if these
> scripts don't use bash-isms. I have not tried this zsh myself and
> speed/compatibility wise I'm not sure it's up to snuff.
There is a port of BusyBox' dash, which is nearing completion. Once
Nguyen says it is ready enough, we will try to integrate it into msysGit.
Ciao,
Dscho
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Brian Dessent @ 2007-10-15 20:05 UTC (permalink / raw)
To: Alex Riesen; +Cc: Johannes Schindelin, git, Eli Zaretskii, ae, tsuna
In-Reply-To: <20071015194214.GC15541@steel.home>
Alex Riesen wrote:
> Hmm... Could the allocation of large contiguous blocks also lock the
> system hard? For instance, I avoid starting the test suite on my XP
> workstation at work: it locks up hard every time. W2k works.
> The system has nothing unusual in it. Well, it has an antivirus
> program (which hopefully stopped working after a series of crashes,
> which is just as well), an NVidia card with native driver (which is
> broken in its own usual ways). Maybe that's enough
In terms of the MSYS/Cygwin style of fork emulation, large memory
allocations shouldn't pose any real problem, but they will be slow as
the fork emulation has to manually replicate the state of the parent in
the child and this means copying memory extents. (Yes, horribly ugly,
no doubt about it, but it allows for porting.)
This emulation code is sensitive enough that the Cygwin list has begun
to maintain a list of software whose hooks/interference can cause Cygwin
apps to fail: <http://cygwin.com/ml/cygwin-talk/2007-q3/msg00174.html>.
Since MSYS is derived from the same code I see no reason why the list
wouldn't also implicate potential problems with binaries linked to the
MSYS runtime.
Johannes Schindelin wrote:
> We never had the problem in git itself, since we never used fork() on
> Windows. The problem lies in our usage of bash and perl.
>
> Bash we can fix in the long run (this goes under the keyword
> "builtinification" on the git list), but I do not see our reliance on Perl
> going away, not for git {send-email,cvsimport,cvsexportcommit,svn}.
> These are not too common operations, so common users will be able to do
> without them.
>
> However, if you rely on the CVS/SVN connectors, or send-email, and in any
> case in the short run, you better run Git on Windows only when that funny
> Logitech driver is disabled ;-)
Well, instead of using an MSYS build of Perl there's always ActiveState
Perl. I think you may be stuck on the shell though -- I don't know of
any ports of bash that aren't MSYS or Cygwin based. However I do think
there's a native port of zsh out there by the GnuWin32 project, which
when renamed as just "/bin/sh" might be suitable, but only if these
scripts don't use bash-isms. I have not tried this zsh myself and
speed/compatibility wise I'm not sure it's up to snuff.
Brian
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Johannes Schindelin @ 2007-10-15 19:58 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Alex Riesen, brian, git, ae, tsuna
In-Reply-To: <u1wbwjh10.fsf@gnu.org>
Hi,
On Mon, 15 Oct 2007, Eli Zaretskii wrote:
> > From: Alex Riesen <raa.lkml@gmail.com>
>
> > For instance, I avoid starting the test suite on my XP workstation at
> > work: it locks up hard every time.
>
> Sounds like a bug to me.
To me, too. Alas, it works on W2k, so where is the bug?
Ciao,
Dscho
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Eli Zaretskii @ 2007-10-15 19:48 UTC (permalink / raw)
To: Alex Riesen; +Cc: brian, Johannes.Schindelin, git, ae, tsuna
In-Reply-To: <20071015194214.GC15541@steel.home>
> Date: Mon, 15 Oct 2007 21:42:14 +0200
> From: Alex Riesen <raa.lkml@gmail.com>
> Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>, git@vger.kernel.org,
> Eli Zaretskii <eliz@gnu.org>, ae@op5.se, tsuna@lrde.epita.fr
>
> Hmm... Could the allocation of large contiguous blocks also lock the
> system hard?
No, not on XP.
> For instance, I avoid starting the test suite on my XP
> workstation at work: it locks up hard every time.
Sounds like a bug to me.
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Alex Riesen @ 2007-10-15 19:42 UTC (permalink / raw)
To: Brian Dessent; +Cc: Johannes Schindelin, git, Eli Zaretskii, ae, tsuna
In-Reply-To: <4713BA89.633B86F2@dessent.net>
Brian Dessent, Mon, Oct 15, 2007 21:07:53 +0200:
> Johannes Schindelin wrote:
> > My bigger concerns are the performance and stability. For example, I had
> > a very annoying problem on one of the machines I am testing msysGit on.
> > The problem was _only_ fixable by deactivating component of Logitech's
> > WebCam driver! Now, if a user-installable 3rd party program can make my
> > regular git crash, I am scared what more it can do.
>
> That is because the MSYS runtime is based on an old version of Cygwin,
> and it uses the same dirty tricks to emulate fork. These tricks rely on
> having a repeatably consistent memory layout for a process each time it
> is started, and when third party tools add hooks that affect the load
> order or otherwise screw with the layout, the fork emulation fails.
> This is also why it is sometimes necessary to assign unique base
> addresses to all libraries (rebaseall) in order to get fork emulation
> working again.
Hmm... Could the allocation of large contiguous blocks also lock the
system hard? For instance, I avoid starting the test suite on my XP
workstation at work: it locks up hard every time. W2k works.
The system has nothing unusual in it. Well, it has an antivirus
program (which hopefully stopped working after a series of crashes,
which is just as well), an NVidia card with native driver (which is
broken in its own usual ways). Maybe that's enough
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Alex Riesen @ 2007-10-15 19:34 UTC (permalink / raw)
To: Dave Korn; +Cc: 'Johannes Schindelin', ae, git, make-w32
In-Reply-To: <030301c80f58$d37b9710$2e08a8c0@CAM.ARTIMI.COM>
Dave Korn, Mon, Oct 15, 2007 20:25:55 +0200:
> On 15 October 2007 18:49, Alex Riesen wrote:
>
> > Johannes Schindelin, Mon, Oct 15, 2007 10:44:12 +0200:
> >> On Mon, 15 Oct 2007, Eli Zaretskii wrote:
> >>> Can you show a test case where this penalty is clearly visible? I'm
> >>> curious to see the numbers. TIA
> > ...
> >> Now, that is my _personal_ decision. If _you_ have no problem with
> >> Windows, just stick with it. (I always thought this goes without saying,
> >> but Windows users tend to be very religious about this issue, thinking
> >> just because I hate Windows that I want to make them switch. Hahaha, no.)
> >
> > They tend to be so exactly because they know how pathetic they are.
> > They just want to have something where they don't suck and do
> > everything to find it. And fail. Then they resort to graphics and
> > user-friendly interface.
>
> Translation: "I feel that I am superior to other people. This post has no
> content apart from me shooting my mouth off in an attempt to prove how much
> cleverer I am than anyone else. However apart from my self-love I have no
> contribution to make to the discussion."
It is interpretation, not translation. Wrong, too.
> This isn't slashdot. A computer is just a tool, and it's really *you* who
> are being pathetic, because you confuse a choice of mass-manufactured consumer
it is not a "choice". It is an accident. Like in "caused by careless driving".
> product with a statement about personal identity. Loyalty to your favourite
> brand is a game of one-upmanship suitable only for kids. You need to grow up.
Yep. Will do.
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Alex Riesen @ 2007-10-15 19:30 UTC (permalink / raw)
To: David Kastrup; +Cc: Michael Gebetsroither, git, make-w32
In-Reply-To: <85ejfwi3gr.fsf@lola.goethe.zz>
David Kastrup, Mon, Oct 15, 2007 21:26:44 +0200:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
> > Michael Gebetsroither, Mon, Oct 15, 2007 02:46:11 +0200:
> >> > - it is the only OS in the world with multi-root (/a/b/c and /a/b/c
> >> > can be not the same, depending on what current "drive" is) and
> >> > multi-cwd, which hasn't had formed itself into a problem yet, but
> >> > surely will
> >>
> >> Thats true for linux too.
> >> /a/b/c and /a/b/c can be 2 totally different files depending on the vfs
> >> namespace you are one.
> >
> > No it is not. A process will always see the same filesystem object
> > under the same path at the any given time (IOW, you can't have many
> > namespaces active at the same time).
>
> dak@lola:/home/tmp/emacs$ mkdir -p /tmp/a/b
> dak@lola:/home/tmp/emacs$ cd /tmp/a/b
> dak@lola:/tmp/a/b$ sudo mount --bind /usr /tmp/a
Well don't do that in your repos (unless need that for something).
It is not like someone creates a distribution which does it
automagically all the time and you're forced to use that distribution.
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Johannes Schindelin @ 2007-10-15 19:27 UTC (permalink / raw)
To: git; +Cc: Alex Riesen, Eli Zaretskii, ae, tsuna
In-Reply-To: <4713BA89.633B86F2@dessent.net>
Hi,
On Mon, 15 Oct 2007, Brian Dessent wrote:
> Johannes Schindelin wrote:
>
> > My bigger concerns are the performance and stability. For example, I
> > had a very annoying problem on one of the machines I am testing
> > msysGit on. The problem was _only_ fixable by deactivating component
> > of Logitech's WebCam driver! Now, if a user-installable 3rd party
> > program can make my regular git crash, I am scared what more it can
> > do.
>
> That is because the MSYS runtime is based on an old version of Cygwin,
> and it uses the same dirty tricks to emulate fork. These tricks rely on
> having a repeatably consistent memory layout for a process each time it
> is started, and when third party tools add hooks that affect the load
> order or otherwise screw with the layout, the fork emulation fails. This
> is also why it is sometimes necessary to assign unique base addresses to
> all libraries (rebaseall) in order to get fork emulation working again.
Ah, thanks for the explanation! (I knew that this thread still had
something useful in it ;-)
> So yes, it is unfortunate that some system tools can drastically affect
> the ability of Cygwin and MSYS to function, but it's what we live with
> to have fork/exec emulation. I see that there is work afoot to abstract
> process creation so that hopefully this won't be as much a concern in
> the near future.
We never had the problem in git itself, since we never used fork() on
Windows. The problem lies in our usage of bash and perl.
Bash we can fix in the long run (this goes under the keyword
"builtinification" on the git list), but I do not see our reliance on Perl
going away, not for git {send-email,cvsimport,cvsexportcommit,svn}.
These are not too common operations, so common users will be able to do
without them.
However, if you rely on the CVS/SVN connectors, or send-email, and in any
case in the short run, you better run Git on Windows only when that funny
Logitech driver is disabled ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: Switching from CVS to GIT
From: David Kastrup @ 2007-10-15 19:26 UTC (permalink / raw)
To: Alex Riesen; +Cc: Michael Gebetsroither, make-w32, git
In-Reply-To: <20071015173832.GB2966@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> Michael Gebetsroither, Mon, Oct 15, 2007 02:46:11 +0200:
>> > - it is the only OS in the world with multi-root (/a/b/c and /a/b/c
>> > can be not the same, depending on what current "drive" is) and
>> > multi-cwd, which hasn't had formed itself into a problem yet, but
>> > surely will
>>
>> Thats true for linux too.
>> /a/b/c and /a/b/c can be 2 totally different files depending on the vfs
>> namespace you are one.
>
> No it is not. A process will always see the same filesystem object
> under the same path at the any given time (IOW, you can't have many
> namespaces active at the same time).
dak@lola:/home/tmp/emacs$ mkdir -p /tmp/a/b
dak@lola:/home/tmp/emacs$ cd /tmp/a/b
dak@lola:/tmp/a/b$ sudo mount --bind /usr /tmp/a
Password:
dak@lola:/tmp/a/b$ command pwd
/tmp/a/b
dak@lola:/tmp/a/b$ ls -l
total 0
dak@lola:/tmp/a/b$ ls -l /tmp/a/b
ls: /tmp/a/b: No such file or directory
dak@lola:/tmp/a/b$
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Brian Dessent @ 2007-10-15 19:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Alex Riesen, Eli Zaretskii, ae, tsuna
In-Reply-To: <Pine.LNX.4.64.0710151938300.25221@racer.site>
Johannes Schindelin wrote:
> No, it is not equivalent. For example, you can still see the file. For
> example, you cannot reuse the filename for another file. And -- the
> killer -- you cannot remove the directory which contains the file.
Fair enough. You can move it to another directory in order to delete
the containing directory -- this is what Cygwin does to placate posix
apps that expect this to work.
> But really, we have workarounds in place to make this a non-issue.
Ok.
> My bigger concerns are the performance and stability. For example, I had
> a very annoying problem on one of the machines I am testing msysGit on.
> The problem was _only_ fixable by deactivating component of Logitech's
> WebCam driver! Now, if a user-installable 3rd party program can make my
> regular git crash, I am scared what more it can do.
That is because the MSYS runtime is based on an old version of Cygwin,
and it uses the same dirty tricks to emulate fork. These tricks rely on
having a repeatably consistent memory layout for a process each time it
is started, and when third party tools add hooks that affect the load
order or otherwise screw with the layout, the fork emulation fails.
This is also why it is sometimes necessary to assign unique base
addresses to all libraries (rebaseall) in order to get fork emulation
working again.
So yes, it is unfortunate that some system tools can drastically affect
the ability of Cygwin and MSYS to function, but it's what we live with
to have fork/exec emulation. I see that there is work afoot to abstract
process creation so that hopefully this won't be as much a concern in
the near future.
Brian
^ permalink raw reply
* [PATCH] Documentation/git-tag.txt: Document how to backdate tags
From: Michael Olson @ 2007-10-15 17:51 UTC (permalink / raw)
To: Junio C Hamano, git
In-Reply-To: <7vd4w0iqd5.fsf@gitster.siamese.dyndns.org>
Added a new section beneath "On Automatic following" called "On
Backdating Tags". This includes an explanation of when to use this
method, a brief explanation of the kind of date that can be used in
GIT_AUTHOR_DATE, and an example invocation of git-tag using a custom
setting of GIT_AUTHOR_DATE.
Signed-off-by: Michael W. Olson <mwolson@gnu.org>
---
[Resending, this time without trying to send through Gmane and munge
Reply-To.]
Junio C Hamano <gitster@pobox.com> writes:
> Michael Olson <mwolson@gnu.org> writes:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> Wouldn't it be easier to create the tag with the desired
>>> timestamp from the beginning, by exporting GIT_COMMITTER_DATE?
>>
>> Ah, I didn't know about that environment variable.
>>
>> Would it be possible to mention that option on the git-tag manpage?
>
> Surely, I am kind of surprised if it weren't, but apparently you
> did not find it. Please make it so.
Documentation/git-tag.txt | 21 +++++++++++++++++++++
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index 990ae4f..2966aa2 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -214,6 +214,27 @@ having tracking branches. Again, the heuristic to automatically
follow such tags is a good thing.
+On Backdating Tags
+~~~~~~~~~~~~~~~~~~
+
+If you have imported some changes from another VCS and would like
+to add tags for major releases of you work, it is useful to be able
+to specify the date to embed inside of the tag object. The data in
+the tag object affects, for example, the ordering of tags in the
+gitweb interface.
+
+To set the date used in future tag objects, set the environment
+variable GIT_AUTHOR_DATE to one or more of the date and time. The
+date and time can be specified in a number of ways; the most common
+is "YYYY-MM-DD HH:MM".
+
+An example follows.
+
+------------
+$ GIT_AUTHOR_DATE="2006-10-02 10:31" git tag -s v1.0.1
+------------
+
+
Author
------
Written by Linus Torvalds <torvalds@osdl.org>,
--
1.5.3.4
^ permalink raw reply related
* Re: Switching from CVS to GIT
From: Johannes Schindelin @ 2007-10-15 18:44 UTC (permalink / raw)
To: git; +Cc: Alex Riesen, Eli Zaretskii, ae, tsuna
In-Reply-To: <4713B367.52CEC7E2@dessent.net>
Hi,
[excluding make-w32 list as per explicit request]
On Mon, 15 Oct 2007, Brian Dessent wrote:
> Alex Riesen wrote:
>
> > He misunderstood. It is not what you meant. You cannot remove the open
> > file. What he talks about is removing the file after it is _closed_.
> > Junk.
>
> I did not misunderstand. The semantics are equivalent to the POSIX
> case: you end up with a handle to an open file that is exclusive to that
> process (it cannot be opened by any other process, even root) and that
> is automatically reclaimed by the filesystem when all open handles are
> closed, without any explicit action by the user. It's not "unlinking an
> open file", no, but it's the same result.
No, it is not equivalent. For example, you can still see the file. For
example, you cannot reuse the filename for another file. And -- the
killer -- you cannot remove the directory which contains the file.
But really, we have workarounds in place to make this a non-issue.
My bigger concerns are the performance and stability. For example, I had
a very annoying problem on one of the machines I am testing msysGit on.
The problem was _only_ fixable by deactivating component of Logitech's
WebCam driver! Now, if a user-installable 3rd party program can make my
regular git crash, I am scared what more it can do.
Ciao,
Dscho
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Brian Dessent @ 2007-10-15 18:37 UTC (permalink / raw)
To: Alex Riesen; +Cc: Johannes Schindelin, git, Eli Zaretskii, ae, tsuna, make-w32
In-Reply-To: <20071015175606.GE2966@steel.home>
Alex Riesen wrote:
> He misunderstood. It is not what you meant. You cannot remove the open
> file. What he talks about is removing the file after it is _closed_.
> Junk.
I did not misunderstand. The semantics are equivalent to the POSIX
case: you end up with a handle to an open file that is exclusive to that
process (it cannot be opened by any other process, even root) and that
is automatically reclaimed by the filesystem when all open handles are
closed, without any explicit action by the user. It's not "unlinking an
open file", no, but it's the same result.
Brian
^ permalink raw reply
* RE: Switching from CVS to GIT
From: Johannes Schindelin @ 2007-10-15 18:34 UTC (permalink / raw)
To: Dave Korn; +Cc: 'Alex Riesen', ae, git, make-w32
In-Reply-To: <030301c80f58$d37b9710$2e08a8c0@CAM.ARTIMI.COM>
Hi,
On Mon, 15 Oct 2007, Dave Korn wrote:
> On 15 October 2007 18:49, Alex Riesen wrote:
>
> > Johannes Schindelin, Mon, Oct 15, 2007 10:44:12 +0200:
> >> On Mon, 15 Oct 2007, Eli Zaretskii wrote:
> >>> Can you show a test case where this penalty is clearly visible? I'm
> >>> curious to see the numbers. TIA
> > ...
> >> Now, that is my _personal_ decision. If _you_ have no problem with
> >> Windows, just stick with it. (I always thought this goes without saying,
> >> but Windows users tend to be very religious about this issue, thinking
> >> just because I hate Windows that I want to make them switch. Hahaha, no.)
> >
> > They tend to be so exactly because they know how pathetic they are.
> > They just want to have something where they don't suck and do
> > everything to find it. And fail. Then they resort to graphics and
> > user-friendly interface.
>
> Translation: "I feel that I am superior to other people. This post
> has no content apart from me shooting my mouth off in an attempt to
> prove how much cleverer I am than anyone else. However apart from my
> self-love I have no contribution to make to the discussion."
>
> This isn't slashdot. A computer is just a tool, and it's really *you*
> who are being pathetic, because you confuse a choice of
> mass-manufactured consumer product with a statement about personal
> identity. Loyalty to your favourite brand is a game of one-upmanship
> suitable only for kids. You need to grow up.
I sense a classical Stockholm Syndrome here ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Paul Smith @ 2007-10-15 18:29 UTC (permalink / raw)
To: Eli Zaretskii
Cc: raa.lkml, prohaska, make-w32, Johannes.Schindelin, ae,
Johannes Sixt, git
In-Reply-To: <E1IhPCo-0004ZO-N9@fencepost.gnu.org>
OK, enough. I am extremely grateful for the porting and maintenance
efforts of the GNU make porting team (since I have no Windows--or Amiga,
or OS/2, or OpenVMS--systems to maintain these ports myself) and I'm not
going to choose a tool unless it supports their environment and helps
them to work more efficiently (or at least no less efficiently). I'm
not interested in getting into a pissing match over which operating
system is better or worse, and I'm certainly not interested in unfounded
inferences as to the character and quality of my porting team based on
the operating system they are using.
For those who have provided details and pointers regarding the state of
GIT on Windows, thank you very much for your help: it's been very useful
and Eli and others sound like they have enough information to be getting
on with for now. If you'd like to discuss some Windows porting issues
further there are a number of extremely knowledgeable Windows / FLOSS
programmers on the make-w32@gnu.org list--although they are generally
very busy.
If what you're interested in is self-congratulatory back-slapping over
the superiority of Linux/POSIX, please keep that on the GIT mailing
list, or else an advocacy forum somewhere.
I'm setting followups to the GIT list.
Cheers all!
--
-------------------------------------------------------------------------------
Paul D. Smith <psmith@gnu.org> Find some GNU make tips at:
http://www.gnu.org http://make.mad-scientist.us
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
^ permalink raw reply
* RE: Switching from CVS to GIT
From: Dave Korn @ 2007-10-15 18:25 UTC (permalink / raw)
To: 'Alex Riesen', 'Johannes Schindelin'; +Cc: ae, git, make-w32
In-Reply-To: <20071015174922.GC2966@steel.home>
On 15 October 2007 18:49, Alex Riesen wrote:
> Johannes Schindelin, Mon, Oct 15, 2007 10:44:12 +0200:
>> On Mon, 15 Oct 2007, Eli Zaretskii wrote:
>>> Can you show a test case where this penalty is clearly visible? I'm
>>> curious to see the numbers. TIA
> ...
>> Now, that is my _personal_ decision. If _you_ have no problem with
>> Windows, just stick with it. (I always thought this goes without saying,
>> but Windows users tend to be very religious about this issue, thinking
>> just because I hate Windows that I want to make them switch. Hahaha, no.)
>
> They tend to be so exactly because they know how pathetic they are.
> They just want to have something where they don't suck and do
> everything to find it. And fail. Then they resort to graphics and
> user-friendly interface.
Translation: "I feel that I am superior to other people. This post has no
content apart from me shooting my mouth off in an attempt to prove how much
cleverer I am than anyone else. However apart from my self-love I have no
contribution to make to the discussion."
This isn't slashdot. A computer is just a tool, and it's really *you* who
are being pathetic, because you confuse a choice of mass-manufactured consumer
product with a statement about personal identity. Loyalty to your favourite
brand is a game of one-upmanship suitable only for kids. You need to grow up.
cheers,
DaveK
--
Can't think of a witty .sigline today....
^ permalink raw reply
* [PATCH] git-rebase--interactive.sh: Quote arguments to test
From: Michael W. Olson @ 2007-10-15 17:48 UTC (permalink / raw)
To: git
If /bin/sh is /bin/dash, then the script will display an error if
$parent_sha1 is undefined. This patch works fixes the issue by
quoting both arguments to `test'. Arguments composed solely of
variable expansions should always be quoted, unless we know for
certain that the contents are defined.
Signed-off-by: Michael W. Olson <mwolson@gnu.org>
---
Resending, this time directly to the mailing list instead of via Gmane.
git-rebase--interactive.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 050140d..8a03062 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -110,7 +110,7 @@ pick_one () {
parent_sha1=$(git rev-parse --verify $sha1^) ||
die "Could not get the parent of $sha1"
current_sha1=$(git rev-parse --verify HEAD)
- if test $no_ff$current_sha1 = $parent_sha1; then
+ if test "$no_ff$current_sha1" = "$parent_sha1"; then
output git reset --hard $sha1
test "a$1" = a-n && output git reset --soft $current_sha1
sha1=$(git rev-parse --short $sha1)
--
1.5.3.4
^ 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