* Re: Switching from CVS to GIT
From: Nguyen Thai Ngoc Duy @ 2007-10-16 2:24 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Git Mailing List, Alex Riesen, Eli Zaretskii, Andreas Ericsson,
tsuna, Johannes Schindelin
In-Reply-To: <7287AD62-3274-4B20-881C-D02E08C4B2EF@zib.de>
On 10/16/07, Steffen Prohaska <prohaska@zib.de> 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].
All zsh links in [2] are dead. I did try hard to find the legendary
zsh for Windows before giving up and porting busybox's ash instead. If
you have zsh source of the port, please send me. Thank you.
> Steffen
>
> [1] http://www.gnuarch.org/gnuarchwiki/Native_WIN32_Support
> [2] http://unxutils.sourceforge.net/
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Duy
^ permalink raw reply
* Re: How to Import a bitkeeper repo into git
From: Linus Torvalds @ 2007-10-16 1:22 UTC (permalink / raw)
To: David Brown; +Cc: Pete/Piet Delaney, VMiklos, free cycle, git
In-Reply-To: <20071016011212.GA609@old.davidb.org>
On Mon, 15 Oct 2007, David Brown wrote:
>
> On Mon, Oct 15, 2007 at 05:45:44PM -0700, Linus Torvalds wrote:
>
> > git diff -U99 | viewdiff -
>
> Do you have reference for viewdiff. I can't seem to locate it.
That was the stupid script I just posted ;)
> > [ Quite frankly, I don't understand why tools like meld and kdiff3 can't
> > just take the unified diff directly - they have *all* the logic, it should
> > be trivial to do, and very useful to view diffs for those people who like
> > that graphical bling. ]
>
> kompare can read the unified diffs. If you add enough context, the result
> is no different than the full files.
Ahh, good pointer. I had to google for it to find that it's part of the
kdesdk package, which I hadn't installed. But a simple "yum install
kdesdk" worked fine.
Much better than my stupid script ;)
Linus
^ permalink raw reply
* Re: How to Import a bitkeeper repo into git
From: David Brown @ 2007-10-16 1:13 UTC (permalink / raw)
To: Pete/Piet Delaney
Cc: Shawn O. Pearce, Linus Torvalds, VMiklos, free cycle, git
In-Reply-To: <471408B8.8080509@bluelane.com>
On Mon, Oct 15, 2007 at 05:41:28PM -0700, Pete/Piet Delaney wrote:
>Try tkdiff and then tell me you don't find it easier to read that
>the straight output from diff.
Both. Most of the time, I find the diff output easier to read. Only when
a change modifies a whole bunch of lines sprinkled around do I find the
side-by-side format easier. Even then, it is only marginal.
However, asking for a side-by-side diff viewer is probably the most common
request I've gotten from people I work with starting to use git.
David
^ permalink raw reply
* Re: How to Import a bitkeeper repo into git
From: David Brown @ 2007-10-16 1:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Pete/Piet Delaney, VMiklos, free cycle, git
In-Reply-To: <alpine.LFD.0.999.0710151711280.6887@woody.linux-foundation.org>
On Mon, Oct 15, 2007 at 05:45:44PM -0700, Linus Torvalds wrote:
> git diff -U99 | viewdiff -
Do you have reference for viewdiff. I can't seem to locate it.
>[ Quite frankly, I don't understand why tools like meld and kdiff3 can't
> just take the unified diff directly - they have *all* the logic, it
> should be trivial to do, and very useful to view diffs for those people
> who like that graphical bling. ]
kompare can read the unified diffs. If you add enough context, the result
is no different than the full files.
David
^ permalink raw reply
* Re: How to Import a bitkeeper repo into git
From: Linus Torvalds @ 2007-10-16 0:45 UTC (permalink / raw)
To: Pete/Piet Delaney; +Cc: VMiklos, free cycle, git
In-Reply-To: <4713FA4A.5090501@bluelane.com>
On Mon, 15 Oct 2007, Pete/Piet Delaney wrote:
>
> I imported the CVS repository to git and it worked great. Since all
> of our other repository are in bitkeeper the management would like to
> stick with CVS. With git apparently still being weak in the area of
> supporting difftool on different version that seems somewhat reasonable
> for the time being.
I can't see how bk's difftool could possibly have any relevance to the
"reasonable to stick with CVS" decision, but hey, I'm always surprised by
peoples inventiveness in rationalizing their decisions ;)
I don't know what difftool does that a simple
git diff -U99 | viewdiff -
wouldn't do, but in all honesty, I don't think I ever used difftool (I
found the other tools in bk much more useful - eg mergetool, renametool)
I don't actually know of any sane programs to view unified diffs, but you
can script one with little trouble. Here's a really hacky one I just came
up with:
#!/bin/sh
cat "$@" > /tmp/diff
grep '^[ -]' /tmp/diff > /tmp/orig
grep '^[ +]' /tmp/diff > /tmp/result
meld /tmp/orig /tmp/result
which fools 'meld' into showing a unified diff in a nice graphical manner.
[ Quite frankly, I don't understand why tools like meld and kdiff3 can't
just take the unified diff directly - they have *all* the logic, it
should be trivial to do, and very useful to view diffs for those people
who like that graphical bling. ]
> The folks at bitmover are converting you kernels to bk and it's
> maintaining the branch history and I'd like to do the same. So far
> they haven't help us convert the git repository to bk. Do you happen
> to know of someone else that might now how to do this in case the
> folks at bitmover can't provide the scripts to convert this git
> repository to bk?
Hmm. Converting from git to bk should not be that hard at least
conceptually, but no, I have no idea how to script it sanely and
efficiently. The obvious solutions all would want to have multiple active
heads of development open at the same time (Larry calls them "LOD's" not
branches), and would also require some way to set the result of a merge.
Neither of which I would know how to do in BK (I created a lot of merges
in BK, but I always let BK do the merging - I wouldn't know how to specify
the merge result by hand).
Linus
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Daniel Barkalow @ 2007-10-16 0:45 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Alex Riesen, Johannes.Schindelin, ae, tsuna, git, make-w32
In-Reply-To: <u7ilpjp3x.fsf@gnu.org>
Responding only to those portions where I think Windows experience and a
Windows perspective would be helpful...
On Mon, 15 Oct 2007, Eli Zaretskii wrote:
> > - no proper filename semantics (case-insensitivity and stupid rules for
> > allowed characters in filenames, like ":" in filenames in
> > cross-platform projects)
>
> There's a flag on Windows to open files case-sensitively, if you need
> that. In any case, I don't see how this can be of any real relevance
> to porting GIT. As for ":" in file names, simply don't use it, like
> you don't use white space or characters below 32 decimal: it's
> inconvenient, even if it's allowed.
I believe the hassle is that readdir doesn't necessarily report a README in
a directory which is supposed to have a README, when it has a readme
instead. I think we want O(n) comparison of sorted lists, which doesn't
work if equivalent names don't sort the same.
> > - no acceptable level of performance in filesystem and VFS (readdir,
> > stat, open and read/write are annoyingly slow)
>
> With what libraries? Native `stat' and `readdir' are quite fast.
> Perhaps you mean the ported glibc (libgw32c), where `readdir' is
> indeed painfully slow, but then you don't need to use it.
We want getting stat info, using readdir to figure out what files exist,
for 106083 files in 1603 directories with a hot cache to take under 1s;
otherwise "git status" takes a noticeable amount of time with a medium-big
project, and we want people to be able to get info on what's changed
effectively instantly. My impression is that Windows' native stat and
readdir are plenty fast for what normal Windows programs want, but we
actually expect reasonable performance on an unreasonably-big
metadata-heavy input. AFAICT, nothing but Linux is optimized for this, but
we're used to being able to find out if there's any change to a large
directory structure in practically no time. On the other hand, we really
just want to beat users' expectations for this operation, not our own
expectations, so this may only be a problem for people benchmarking
Windows git against Linux git.
> > - no real "mmap" (which kills perfomance and complicates code)
>
> You only need mmap because you are accustomed to use it on GNU/Linux.
I believe the need here is quick setup and fast access to sparse portions
of several 100M files. It's hard to beat a page fault for read speed.
We also expect to be able to make a sequence of file system operations
such that programs starting at any time see the same database as the files
containing the database get restructured. My impression is that this is
very hard or impossible with Windows, and also that it doesn't matter for
Windows users, because they'll only have one program at a time accessing
the repository. A lot of our filesystem demands are about making a wide
variety of race conditions give the same result regardless of how the race
goes, and we're just being overly careful for a Windows environment
(although not necessarily for users with a UNIX background using Windows
only because they have to).
> > - it has only one argument (limited in size) passed to started
> > programs, which means that there is no possible way to safely pass
> > file and text arguments on command line (more than one, that is)
>
> Not enough context, so I cannot talk intelligently about this. Why do
> you need interprocess communication in the first place? why not simply
> give birth to a subsidiary process and pass it a command line (which
> can be up to 32KB)?
A unixy pipeline was convenient, given what else we had already written.
It's getting converted to single tasks, but it's not a top priority for
most developers, since streaming 100M from one program to the next under
most of our environments is trivial.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: How to Import a bitkeeper repo into git
From: Pete/Piet Delaney @ 2007-10-16 0:41 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Linus Torvalds, VMiklos, free cycle, git
In-Reply-To: <20071016000359.GT27899@spearce.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Shawn O. Pearce wrote:
> Pete/Piet Delaney <pete@bluelane.com> wrote:
>> I imported the CVS repository to git and it worked great. Since all
>> of our other repository are in bitkeeper the management would like to
>> stick with CVS. With git apparently still being weak in the area of
>> supporting difftool on different version that seems somewhat reasonable
>> for the time being.
> ...
>> I was curious why the difftool paradigm hasn't been integrated into
>> the git GUIs. It's very comfortable and I think it has been used in
>> other source code control systems, for example Sun Microsystems.
>
> What's difftool? What's so great about it?
It's a side by side graphical diff. So instead of showing the difference
like diff does it takes the output from diff and shows the originals
with the diffs highlighted.
tkdiff is a good example that's easy to down load and see. So
just imagine allowing git-gui to run tkdiff of revisions you select
with the mouse.
>
> Forgive my ignorance but it has been many years since I last used
> BitKeeper and even when I did use it I didn't get into many of the
> features it offered. Its entirely possible I never learned about
> difftool.
Try downloading tkdiff. There also a X implementation,
I think it's xdiff.
>
> I've never found that I cannot get the information I need out of Git
> when I need it. Actually I've found it to be the easiest VCS to get
> data out of, beating CVS, Perforce, BitKeeper, SVN, etc. hands down.
> Of course I also know Git better than I know those tools...
Try tkdiff and then tell me you don't find it easier to read that
the straight output from diff.
- -piet
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHFAi4JICwm/rv3hoRAluCAJ9jFrA9G8aKQi1rtM2CSiNnmhlo4wCeJjk7
LONAM+lzvin021HAhQ8jKoE=
=QsE/
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] Fix compilation when NO_CURL is defined
From: Johannes Schindelin @ 2007-10-16 0:05 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, Lars Hjemli, git
In-Reply-To: <20071015234830.GA9694@spearce.org>
Hi,
On Mon, 15 Oct 2007, Shawn O. Pearce wrote:
> From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Hehe, hardly ;-)
> There were a few places which did not cope well without curl. This
> fixes all of them. We still need to link against the walker.o part
> of the library as some parts of transport.o still call into there
> even though we don't have HTTP support enabled.
>
> If compiled with NO_CURL=1 we now get the following useful error
> message:
>
> $ git-fetch http://www.example.com/git
> error: git was compiled without libcurl support.
> fatal: Don't know how to fetch from http://www.example.com/git
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> ---
>
> I think this is a better version of Dscho's original attempt at
> making NO_CURL=YesPlease actually work again with the builtin
> fetch series.
>
> Makefile | 6 +++---
> transport.c | 23 +++++++----------------
> 2 files changed, 10 insertions(+), 19 deletions(-)
Nice!
I like it.
Ciao,
Dscho
^ permalink raw reply
* Re: How to Import a bitkeeper repo into git
From: Shawn O. Pearce @ 2007-10-16 0:03 UTC (permalink / raw)
To: Pete/Piet Delaney; +Cc: Linus Torvalds, VMiklos, free cycle, git
In-Reply-To: <4713FA4A.5090501@bluelane.com>
Pete/Piet Delaney <pete@bluelane.com> wrote:
> I imported the CVS repository to git and it worked great. Since all
> of our other repository are in bitkeeper the management would like to
> stick with CVS. With git apparently still being weak in the area of
> supporting difftool on different version that seems somewhat reasonable
> for the time being.
...
> I was curious why the difftool paradigm hasn't been integrated into
> the git GUIs. It's very comfortable and I think it has been used in
> other source code control systems, for example Sun Microsystems.
What's difftool? What's so great about it?
Forgive my ignorance but it has been many years since I last used
BitKeeper and even when I did use it I didn't get into many of the
features it offered. Its entirely possible I never learned about
difftool.
I've never found that I cannot get the information I need out of Git
when I need it. Actually I've found it to be the easiest VCS to get
data out of, beating CVS, Perforce, BitKeeper, SVN, etc. hands down.
Of course I also know Git better than I know those tools...
--
Shawn.
^ permalink raw reply
* Re: How to Import a bitkeeper repo into git
From: Pete/Piet Delaney @ 2007-10-15 23:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: VMiklos, free cycle, git
In-Reply-To: <alpine.LFD.0.999.0707091049080.31544@woody.linux-foundation.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Linus Torvalds wrote:
>
> On Mon, 9 Jul 2007, VMiklos wrote:
>>> I think bk can export to CVS and then git can import from CVS.
>> i think so
>
> That's how I did my kernel history, and cvsps has a special "BK mode",
> which knows to trust the CVS timestamps more when importing from a BK CVS
> archive (since the timestamps will then be exact).
>
> That said, the quality of the result isn't stellar. The CVS export will
> obviously linearize the BK information, so you do lose things. So there's
> actually a better kernel BK->git archive around which doesn't do that, but
> that was done apparently from a custom database, so it's not reproducible.
>
> Linus
> -
We have a CVS repository that we want to import into bitkeeper. I tried
the bk import option, including with a branch bug fix, but it's
still having problems.
I imported the CVS repository to git and it worked great. Since all
of our other repository are in bitkeeper the management would like to
stick with CVS. With git apparently still being weak in the area of
supporting difftool on different version that seems somewhat reasonable
for the time being.
The folks at bitmover are converting you kernels to bk and it's
maintaining the branch history and I'd like to do the same. So far
they haven't help us convert the git repository to bk. Do you happen
to know of someone else that might now how to do this in case the
folks at bitmover can't provide the scripts to convert this git
repository to bk?
I was curious why the difftool paradigm hasn't been integrated into
the git GUIs. It's very comfortable and I think it has been used in
other source code control systems, for example Sun Microsystems.
- -piet
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHE/pKJICwm/rv3hoRAs/QAJoDL0HQDaOAI1x6UakEiVvti9tI2wCfUpGI
bfyKH+ykUK7p2AL9CSE+XXc=
=0gnp
-----END PGP SIGNATURE-----
^ permalink raw reply
* [PATCH] Fix compilation when NO_CURL is defined
From: Shawn O. Pearce @ 2007-10-15 23:48 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin, Lars Hjemli; +Cc: git
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
There were a few places which did not cope well without curl. This
fixes all of them. We still need to link against the walker.o part
of the library as some parts of transport.o still call into there
even though we don't have HTTP support enabled.
If compiled with NO_CURL=1 we now get the following useful error
message:
$ git-fetch http://www.example.com/git
error: git was compiled without libcurl support.
fatal: Don't know how to fetch from http://www.example.com/git
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
I think this is a better version of Dscho's original attempt at
making NO_CURL=YesPlease actually work again with the builtin
fetch series.
Makefile | 6 +++---
transport.c | 23 +++++++----------------
2 files changed, 10 insertions(+), 19 deletions(-)
diff --git a/Makefile b/Makefile
index 62bdac6..40f10b7 100644
--- a/Makefile
+++ b/Makefile
@@ -310,7 +310,7 @@ LIB_OBJS = \
alloc.o merge-file.o path-list.o help.o unpack-trees.o $(DIFF_OBJS) \
color.o wt-status.o archive-zip.o archive-tar.o shallow.o utf8.o \
convert.o attr.o decorate.o progress.o mailmap.o symlinks.o remote.o \
- transport.o bundle.o
+ transport.o bundle.o walker.o
BUILTIN_OBJS = \
builtin-add.o \
@@ -528,7 +528,7 @@ else
endif
BUILTIN_OBJS += builtin-http-fetch.o
EXTLIBS += $(CURL_LIBCURL)
- LIB_OBJS += http.o walker.o http-walker.o
+ LIB_OBJS += http.o http-walker.o
curl_check := $(shell (echo 070908; curl-config --vernum) | sort -r | sed -ne 2p)
ifeq "$(curl_check)" "070908"
ifndef NO_EXPAT
@@ -905,7 +905,7 @@ git-http-push$X: revision.o http.o http-push.o $(GITLIBS)
$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
$(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
-$(LIB_OBJS) $(BUILTIN_OBJS) walker.o: $(LIB_H)
+$(LIB_OBJS) $(BUILTIN_OBJS): $(LIB_H)
$(patsubst git-%$X,%.o,$(PROGRAMS)): $(LIB_H) $(wildcard */*.h)
$(DIFF_OBJS): diffcore.h
diff --git a/transport.c b/transport.c
index 6fe6ec8..46da754 100644
--- a/transport.c
+++ b/transport.c
@@ -1,7 +1,9 @@
#include "cache.h"
#include "transport.h"
#include "run-command.h"
+#ifndef NO_CURL
#include "http.h"
+#endif
#include "pkt-line.h"
#include "fetch-pack.h"
#include "walker.h"
@@ -368,6 +370,7 @@ static int disconnect_walker(struct transport *transport)
return 0;
}
+#ifndef NO_CURL
static int curl_transport_push(struct transport *transport, int refspec_nr, const char **refspec, int flags) {
const char **argv;
int argc;
@@ -400,7 +403,6 @@ static int curl_transport_push(struct transport *transport, int refspec_nr, cons
return !!err;
}
-#ifndef NO_CURL
static int missing__target(int code, int result)
{
return /* file:// URL -- do we ever use one??? */
@@ -504,21 +506,6 @@ static int fetch_objs_via_curl(struct transport *transport,
return fetch_objs_via_walker(transport, nr_objs, to_fetch);
}
-#else
-
-static struct ref *get_refs_via_curl(const struct transport *transport)
-{
- die("Cannot fetch from '%s' without curl ...", transport->url);
- return NULL;
-}
-
-static int fetch_objs_via_curl(struct transport *transport,
- int nr_objs, struct ref **to_fetch)
-{
- die("Cannot fetch from '%s' without curl ...", transport->url);
- return -1;
-}
-
#endif
struct bundle_transport_data {
@@ -733,9 +720,13 @@ struct transport *transport_get(struct remote *remote, const char *url)
} else if (!prefixcmp(url, "http://")
|| !prefixcmp(url, "https://")
|| !prefixcmp(url, "ftp://")) {
+#ifdef NO_CURL
+ error("git was compiled without libcurl support.");
+#else
ret->get_refs_list = get_refs_via_curl;
ret->fetch = fetch_objs_via_curl;
ret->push = curl_transport_push;
+#endif
ret->disconnect = disconnect_walker;
} else if (is_local(url) && is_file(url)) {
--
1.5.3.4.1155.gfe96ee
^ permalink raw reply related
* Re: Git User's Survey 2007 unfinished summary continued
From: Shawn O. Pearce @ 2007-10-15 23:20 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Steven Grimm, Reece Dunn, Linus Torvalds, Johannes Schindelin,
J. Bruce Fields, Jakub Narebski, git
In-Reply-To: <alpine.LFD.0.9999.0710141542020.19446@xanadu.home>
Nicolas Pitre <nico@cam.org> wrote:
> BTW I have patches here reworking the progress code for a more compact
> display which should mitigate this issue quite a bit.
git-gui is scraping the output of the current progress meter using
a regex and then building a graphical progress bar from that output.
Any change in how git produces the progress bar should still keep
it in a form that git-gui can regex match and scrape, preferably
without needing to know what version of git it is pulling that
output from. For example just teach git-gui to try two different
regexps, new format and if that doesn't match then try the old
(aka current) format.
--
Shawn.
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Shawn O. Pearce @ 2007-10-15 23:12 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git list
In-Reply-To: <47130B25.4010304@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> wrote:
> FWIW, I'm using the MinGW port from cmd.exe, i.e. not from a posix shell,
> on a *production* repository. gitk and git-gui work. Not all operations
> that I regularly use are available[*] via the GUIs, like git-rebase or
> non-fast-forwarding push, so the use of the command line is needed from
> time to time.
Rebase in git-gui is starting to be developed. But its still not even
close to something I can use, let alone that I would be willing to ship
to another person for testing.
Force push (non-fast-forwarding push) is in git-gui.git's master
branch now as part of the 0.9.x series. There's a new checkbox
option in the push dialog to trigger adding --force to git-push
command line.
> Unfortunately, "Fetch" does not yet work[*] from within git-gui, so you
> have to fall back to git-fetch on the command line.
>
> [*] Note the distinction between "not available" and "does not work".
What's broken? Is this that Git protocol dump showing up in
git-gui's console window thing?
Are you using the C based fetch that is in git.git's next branch,
or the shell script based one that is in master? Which Tcl/Tk
version are you using to run git-gui?
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Documentation/git-tag.txt: Document how to backdate tags
From: Michael Olson @ 2007-10-15 22:53 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20071015203523.GA4428@sigill.intra.peff.net>
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>
---
Jeff King <peff@peff.net> writes:
> 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/
Fixed; thanks.
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..5cc9da4 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 your 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
* [PATCH] cvsexportcommit: get rid of temporary directory
From: Johannes Schindelin @ 2007-10-15 22:32 UTC (permalink / raw)
To: git, hjemli, gitster
Since commit e86ad71fe5f53ae4434566bd09ea4256090e5a3a we do not use
a temporary directory in cvsexportcommit. So there is no need to set
one up.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
git-cvsexportcommit.perl | 5 -----
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index a33fa8d..6b0123c 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -30,11 +30,6 @@ if ($opt_d) {
@cvs = ('cvs');
}
-# setup a tempdir
-our ($tmpdir, $tmpdirname) = tempdir('git-cvsapplycommit-XXXXXX',
- TMPDIR => 1,
- CLEANUP => 1);
-
# resolve target commit
my $commit;
$commit = pop @ARGV;
--
1.5.3.4.1174.gcd0d6-dirty
^ permalink raw reply related
* Re: Switching from CVS to GIT
From: Mark Watts @ 2007-10-15 20:05 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0710151938300.25221@racer.site>
Hello Johannes,
> 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.
Not just git. This driver has known issues with a number of pieces of software.
The company I work with uses Delphi quite a bit and they also have Logitech
WebCams for the devs and for some reason this driver makes debugging impossible
with Delphi. I have personally experienced this. I have also heard of this
Logitech software having problems with other software too. I have not however
tracked down exactly WHY this piece of software causes so much grief, only
that it does.
-mark
^ permalink raw reply
* [PATCH] Git homepage: remove all the references to Cogito
From: Paolo Ciarrocchi @ 2007-10-15 21:38 UTC (permalink / raw)
To: pasky; +Cc: git
It sounds like a good idea to remove all the references to Cogito from the git homepage since it's not longer supported.
Changes tested with a local installation of the web server lighttpd
Signed-off-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
---
index.html | 12 +-----------
1 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/index.html b/index.html
index 340aee0..41605ed 100644
--- a/index.html
+++ b/index.html
@@ -94,7 +94,6 @@ Junio C Hamano.</p>
-->
<br /><a href="course/stgit.html">Maintaining external patches</a>
<br /><a href="course/svn.html">Git for SVN users</a>
- <br /><a href="course/cvs.html">Cogito for CVS users</a>
<br /><em>More to come soon...</em>
</tr></td>
</table></div>
@@ -286,15 +285,6 @@ a gitweb interface, at <a href="http://repo.or.cz/">http://repo.or.cz/</a>.</p>
<dl>
-<dt id="cogito">Cogito</dt>
-<dd>
-<a href="http://git.or.cz/cogito/">Cogito</a>
-is a popular version control system on top of Git.
-It aims at seamless user interface and ease of use, providing
-generally smoother user experience than the "raw" Git interface
-and indeed also many other version control systems. However, it
-also lacks many advanced capabilities of Git and is currently
-being slowly phased out.</dd>
<dt id="stgit">StGIT</dt>
<dd><a href="http://www.procode.org/stgit/">Stacked Git</a> provides
@@ -340,7 +330,7 @@ with help of a group of hackers 'round the net.
It is currently maintained by
Junio C Hamano.</p>
-<p>The user discussion and development of Git, Cogito and other tools related to Git
+<p>The user discussion and development of Git and other tools related to Git
takes place on the Git mailing list - everyone is welcome to post
bug reports, feature requests, comments and patches to
<a href="mailto:git@vger.kernel.org">git@vger.kernel.org</a>.
--
1.5.3.4.206.g58ba4
^ permalink raw reply related
* 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
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