* Re: Question about "git commit -a"
From: David Soria @ 2007-10-04 22:34 UTC (permalink / raw)
To: git
In-Reply-To: <4d8e3fd30710040838t48bb590erbd90a8c4a1c6e932@mail.gmail.com>
Am Thu, 04 Oct 2007 17:38:25 +0200 schrieb Paolo Ciarrocchi:
> Hi all,
> I was just wondering why git commit doesn't default to "-a" (yes, it's
> another question that came up during a chat with a mercurial user) and
> I didn't find an answer to that.
in fact i do just a git-config alias.commit 'commit -a' in my repository
^ permalink raw reply
* [PATCH] git-reflog: document --verbose
From: Michele Ballabio @ 2007-10-04 12:26 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
---
Documentation/git-reflog.txt | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-reflog.txt b/Documentation/git-reflog.txt
index 5180f68..5c7316c 100644
--- a/Documentation/git-reflog.txt
+++ b/Documentation/git-reflog.txt
@@ -16,7 +16,7 @@ The command takes various subcommands, and different options
depending on the subcommand:
[verse]
-git reflog expire [--dry-run] [--stale-fix]
+git reflog expire [--dry-run] [--stale-fix] [--verbose]
[--expire=<time>] [--expire-unreachable=<time>] [--all] <refs>...
git reflog [show] [log-options]
@@ -68,6 +68,9 @@ them.
--all::
Instead of listing <refs> explicitly, prune all refs.
+--verbose::
+ Print extra information on screen.
+
Author
------
Written by Junio C Hamano <junkio@cox.net>
--
1.5.3.4
^ permalink raw reply related
* [PATCH] git-archive: document --exec
From: Michele Ballabio @ 2007-10-04 22:41 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
---
Documentation/git-archive.txt | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt
index e1e2d60..7cbd1c7 100644
--- a/Documentation/git-archive.txt
+++ b/Documentation/git-archive.txt
@@ -10,7 +10,8 @@ SYNOPSIS
--------
[verse]
'git-archive' --format=<fmt> [--list] [--prefix=<prefix>/] [<extra>]
- [--remote=<repo>] <tree-ish> [path...]
+ [--remote=<repo> [--exec=<git-upload-archive>]] <tree-ish>
+ [path...]
DESCRIPTION
-----------
@@ -52,6 +53,10 @@ OPTIONS
Instead of making a tar archive from local repository,
retrieve a tar archive from a remote repository.
+--exec=<git-upload-archive>::
+ Used with --remote to specify the path to the
+ git-upload-archive executable on the remote side.
+
<tree-ish>::
The tree or commit to produce an archive for.
--
1.5.3.4
^ permalink raw reply related
* Re: WIP: asciidoc replacement
From: Martin Langhoff @ 2007-10-04 22:49 UTC (permalink / raw)
To: David Kastrup
Cc: Junio C Hamano, Wincent Colaiuta, Johannes Schindelin, git,
msysgit
In-Reply-To: <85tzp6oavq.fsf@lola.goethe.zz>
On 10/5/07, David Kastrup <dak@gnu.org> wrote:
> "Martin Langhoff" <martin.langhoff@gmail.com> writes:
>
> > With AsciiDoc we've managed to avoid the arcane format, but we are
> > still laden with a horrid toolchain.
>
> Let's put this somewhat into perspective: the toolchain is horrid with
> regard to the complexity and documentation
Exactly. I'm not complaining about asciidoc itself. But the toolchain
is very fragile, and not crossplatform. Git compiles and works on many
unixen, win32, and some embedded posixy OSs if IIRC.
OTOH asciidoc can be pretty hard to get going even on modern
linuxen.The asciidoc toolchain doesn't even work on Debian Sarge,
which isn't *that* old, while I'm pretty sure git itself can be built
and used on older linuxen. That's where a good old regex-insanity
Perl-based parser beats anything else: no dependencies, works
everywhere.
In that sense, this is close to being a rehash of the "let's use
autoconf" argument...
cheers
martin
^ permalink raw reply
* Re: Question about "git commit -a"
From: Alex Riesen @ 2007-10-04 23:03 UTC (permalink / raw)
To: David Soria; +Cc: git
In-Reply-To: <fe3pp3$8p1$1@sea.gmane.org>
David Soria, Fri, Oct 05, 2007 00:34:11 +0200:
> Am Thu, 04 Oct 2007 17:38:25 +0200 schrieb Paolo Ciarrocchi:
>
> > Hi all,
> > I was just wondering why git commit doesn't default to "-a" (yes, it's
> > another question that came up during a chat with a mercurial user) and
> > I didn't find an answer to that.
>
>
> in fact i do just a git-config alias.commit 'commit -a' in my repository
>
Either you have a specially modified git (the alias expansion code) or
you just said not exactly truth. You can't alias the git commands (see
git.c's main).
^ permalink raw reply
* Re: Question about "git commit -a"
From: Johannes Schindelin @ 2007-10-04 23:19 UTC (permalink / raw)
To: David Soria; +Cc: git
In-Reply-To: <fe3pp3$8p1$1@sea.gmane.org>
Hi,
On Thu, 4 Oct 2007, David Soria wrote:
> Am Thu, 04 Oct 2007 17:38:25 +0200 schrieb Paolo Ciarrocchi:
>
> > Hi all,
> > I was just wondering why git commit doesn't default to "-a" (yes, it's
> > another question that came up during a chat with a mercurial user) and
> > I didn't find an answer to that.
>
>
> in fact i do just a git-config alias.commit 'commit -a' in my repository
Which will not work, because we do not allow overriding of
programs/builtins by aliases.
This has technical reasons and cannot be fixed.
Ciao,
Dscho
^ permalink raw reply
* [PATCH 1/2] git-gc: allow --prune to be specified with --auto
From: Steven Grimm @ 2007-10-05 0:12 UTC (permalink / raw)
To: git
This will run git-prune only if there are still lots of loose objects
after the repack finishes. Obviously the caveats about pruning not being
a safe operation to run concurrently with other git commands still apply.
Signed-off-by: Steven Grimm <koreth@midwinter.com>
---
Documentation/git-gc.txt | 4 +++-
builtin-gc.c | 18 +++++++++++++-----
2 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
index b9d5660..60731e9 100644
--- a/Documentation/git-gc.txt
+++ b/Documentation/git-gc.txt
@@ -33,7 +33,9 @@ OPTIONS
done by default. Pass this option if you want it, and only
when you know nobody else is creating new objects in the
repository at the same time (e.g. never use this option
- in a cron script).
+ in a cron script). If used with the `--auto` option,
+ pruning will only be done if there are many loose objects
+ in the repository after gitlink:git-repack[1] is finished.
--aggressive::
Usually 'git-gc' runs very quickly while providing good disk
diff --git a/builtin-gc.c b/builtin-gc.c
index 23ad2b6..b65cacc 100644
--- a/builtin-gc.c
+++ b/builtin-gc.c
@@ -208,7 +208,6 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
/*
* Auto-gc should be least intrusive as possible.
*/
- prune = 0;
if (!need_to_gc())
return 0;
}
@@ -222,15 +221,24 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
if (run_command_v_opt(argv_repack, RUN_GIT_CMD))
return error(FAILED_RUN, argv_repack[0]);
+ if (auto_gc) {
+ if (too_many_loose_objects()) {
+ if (! prune) {
+ warning("There are too many unreachable loose "
+ "objects; run 'git gc --prune' to "
+ "remove them.");
+ }
+ // else we will run the prune next
+ } else {
+ prune = 0;
+ }
+ }
+
if (prune && run_command_v_opt(argv_prune, RUN_GIT_CMD))
return error(FAILED_RUN, argv_prune[0]);
if (run_command_v_opt(argv_rerere, RUN_GIT_CMD))
return error(FAILED_RUN, argv_rerere[0]);
- if (auto_gc && too_many_loose_objects())
- warning("There are too many unreachable loose objects; "
- "run 'git prune' to remove them.");
-
return 0;
}
--
1.5.3.4.203.gcc61a
^ permalink raw reply related
* [PATCH 2/2] Run garbage collection with loose object pruning after svn dcommit
From: Steven Grimm @ 2007-10-05 0:15 UTC (permalink / raw)
To: git
git-svn dcommit, by virtue of rewriting history to insert svn revision IDs,
leaves old commits dangling. Since dcommit is already unsafe to run
concurrently with other git commands, no additional risk is introduced
by making it prune those old objects as needed.
Signed-off-by: Steven Grimm <koreth@midwinter.com>
---
This is in response to a colleague who complained that, after I
installed the latest git release, he was getting lots of "too many
unreachable loose objects" errors from the new "git gc --auto" run.
Those objects turned out to be dangling commits from a year's worth of
git-svn usage, since every git-svn commit will abandon at least one
existing commit in order to rewrite it with the svn version data.
git-svn.perl | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 777e436..be62ee1 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -441,6 +441,12 @@ sub cmd_dcommit {
}
command_noisy(@finish, $gs->refname);
$last_rev = $cmt_rev;
+
+ # rebase will have made the just-committed revisions
+ # unreachable; over time that can build up lots of
+ # loose objects in the repo. prune is unsafe to run
+ # concurrently but so is dcommit.
+ command_noisy(qw/gc --auto --prune/);
}
}
}
--
1.5.3.4.203.gcc61a
^ permalink raw reply related
* Many gits are offline this week
From: Shawn O. Pearce @ 2007-10-05 1:04 UTC (permalink / raw)
To: git
Dscho and I will be (at least mostly) offline for the next four
days as we travel to San Jose for the 2007 Google Summer of Code
Mentor Summit.
We also just received word from Junio that he is also likely to be
offline this next week. Junio has some business that needs his
immediate attention, so he won't be his usual attentive self on
the mailing list.
With three gits offline for at least the next few days perhaps
someone would be willing to step up and collect patches so that Junio
has a reasonable place to pick up from when he can get back online?
--
Shawn.
^ permalink raw reply
* Re: Many gits are offline this week
From: Randal L. Schwartz @ 2007-10-05 1:27 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20071005010448.GQ2137@spearce.org>
>>>>> "Shawn" == Shawn O Pearce <spearce@spearce.org> writes:
Shawn> Dscho and I will be (at least mostly) offline for the next four
Shawn> days as we travel to San Jose for the 2007 Google Summer of Code
Shawn> Mentor Summit.
Oddly enough, I'm giving my "Intro to Git" talk at Google HQ on
12 october. Too bad you're just going to miss that. :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary (long)
From: Shawn O. Pearce @ 2007-10-05 1:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0710041712120.4174@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Thu, 4 Oct 2007, Jakub Narebski wrote:
> > 26. Which porcelains do you use?
> >
> > Multiple answers (one can use more than one porcelain).
> >
> > Answer (multiple choice) | Count
...
> > other | 14
...
> > Those 14 "other" answers make me wish to have provided "if other,
> > what it was?" (sub)question; actually not only for this question.
>
> git-gui, of course. I consider it porcelain, because it uses core-git as
> backend.
I tried to get git-gui into this list as a choice as I really do
consider it porcelain but Jakub thought it wasn't and wanted to
have a specific category for GUIs. Whatever. Its probably all
git-gui and qgit users that picked other here. Probably in about
the same ratio too, so 8 git-gui's and 6 qgit's.
For the most part git-gui tries to only ever invoke plumbing. I
break that rule in only three places:
- git-merge: I'm lazy and didn't have time yet to rewrite this
properly using Tcl. I already do about half of the
work anyway (e.g. merge base testing, fast-forward
detection, message formatting).
- git-fetch: Now that this is in C I'm going to call it plumbing
even if nobody else does. Especially for say HTTP
as git-fetch process does all of the HTTP requests
directly. I won't reimplement it in Tcl, it would
be slower and suck more. So git-gui won't be calling
git-fetch-pack anytime soon.
- git push: Same as the above reason for git-fetch.
IMHO, porcelain is anything that only invokes plumbing. Seats
however can sit above porcelain to make the position slightly
more comfortable. :-)
> In the same vein, I should consider gitk porcelain now, since it has
> rebase capabilities. I will not, and I am not very happy that this viewer
> got a non-view-only capability, instead of git-gui, where that feature
> should have belonged (as suggested by at least one answer to a later
> question in the survey -- not by me).
I agree. I actually never use the modification features of gitk.
They are so hidden that most users don't even know they are there.
Of course that's just as hidden as the hunk selection in git-gui
is so I shouldn't be complaining.
I'm seriously looking at implementing those modification features
into git-gui and will probably start work on some of that during
the trip. I got plenty of time in a sealed tube at 30,000 feet
to kill. More time than I got battery packs for the laptop. :-\
I think the first thing to implement is cherry-pick and revert as
those are easy and co-workers have been asking about them. That way
you can then rebase using cherry-pick and the Mark I wetware loop.
Then we need a cool graph thing that you can drag the nodes around
on to create a visual `rebase -i`.
--
Shawn.
^ permalink raw reply
* Re: Many gits are offline this week
From: Johannes Schindelin @ 2007-10-05 1:36 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Shawn O. Pearce, git
In-Reply-To: <863awq5p1y.fsf@blue.stonehenge.com>
Hi,
On Thu, 4 Oct 2007, Randal L. Schwartz wrote:
> >>>>> "Shawn" == Shawn O Pearce <spearce@spearce.org> writes:
>
> Shawn> Dscho and I will be (at least mostly) offline for the next four
> Shawn> days as we travel to San Jose for the 2007 Google Summer of Code
> Shawn> Mentor Summit.
>
> Oddly enough, I'm giving my "Intro to Git" talk at Google HQ on
> 12 october. Too bad you're just going to miss that. :)
We will not. I'll watch the YouTube video a hundred times.
Ciao,
Dscho
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary (long)
From: Shawn O. Pearce @ 2007-10-05 1:42 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Benoit SIGOURE, git
In-Reply-To: <8fe92b430710040759r5777264aj5ecb09e0252fef9a@mail.gmail.com>
Jakub Narebski <jnareb@gmail.com> wrote:
> On 10/4/07, Benoit SIGOURE <tsuna@lrde.epita.fr> wrote:
> > On Oct 4, 2007, at 11:12 AM, Jakub Narebski wrote:
> > > Note that Git is GPLv2, and it will probably stay that forever, so you
> > > are _free_ to start a commercial support scheme for Git, but others
> > > are free not to choose it. This question is to get to know if there is
> > > sufficient demand for commercial Git support for it to be viable.
> >
> > Once again (AFAIR this was already raised during one of the previous
> > summary) what's the link between GPLv2 and commercial support? You
> > seem to imply that because Git won't move to GPLv3, it's a good thing
> > for potential paid support, or something. I don't quite see how
> > GPLvX comes into play with commercial support. I'm not a license
> > expert though.
>
> The only link between GPL and commercial support is that GPL does not
> prohibit commercial support (like noncommercial-free licenses for example),
> and that having commercial support doesn't mean that license would change
> to proprietary (it cannot).
Right. There has been some discussion in the past about forming
"The Git Company".
When this survey question was first posed there was some concern that
Git might move to a commerical license of some sort and perhaps not
be GPLvX anymore. That concern is a non-issue; the copyrights for
Git are held by over 300 people, many of whom are kernel hackers and
strong believers in the value of GPLv2. I'm not a kernel hacker,
but I also believe strongly in the value of the GPLv2 license.
You won't see me agreeing to move code I wrote to a non-GPL license
anytime soon. Most (if not all!) of Git's authors feel the same way.
There's several reasons why forming "The Git Company" might help
the overall Git cause, and this question was a feeler to see if
the community was interested in acquiring support through it. Many
other open source projects seem to get some benefit from having a
company loosely affiliated with them, not the least of which are
things like:
- some of the developers can focus more time on the project and
still keep food on the table;
- there are people focused on advertising/marketing the project
and its benfits to potential end-users;
- companies that feel warm-and-fuzzy by having a phone number they
can call for help are more likely to want to use the project
for critical services;
- companies that want training or short-term consulting services
know who they can contact for expertise.
and the list goes on. The problem with said company is it costs
money to keep the lights on and employees fed; money which obviously
cannot be extorted from users through arcane licensing agreements.
:-)
--
Shawn.
^ permalink raw reply
* Re: Many gits are offline this week
From: Johannes Schindelin @ 2007-10-05 1:43 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20071005010448.GQ2137@spearce.org>
Hi,
On Thu, 4 Oct 2007, Shawn O. Pearce wrote:
> Dscho and I will be (at least mostly) offline for the next four days as
> we travel to San Jose for the 2007 Google Summer of Code Mentor Summit.
While at it, we thought that we'd have a little git-together on Sunday, a
few hours before we're (or at least I'm) sober again from Saturday night.
So everybody who is in the area of San Jose: Sunday is Talk Like A Git
Day.
Sadly, Junio is not able to attend, but I will hoist a drink or three to
him.
Ciao,
Dscho
^ permalink raw reply
* Re: Many gits are offline this week
From: Shawn O. Pearce @ 2007-10-05 1:43 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <863awq5p1y.fsf@blue.stonehenge.com>
"Randal L. Schwartz" <merlyn@stonehenge.com> wrote:
> >>>>> "Shawn" == Shawn O Pearce <spearce@spearce.org> writes:
>
> Shawn> Dscho and I will be (at least mostly) offline for the next four
> Shawn> days as we travel to San Jose for the 2007 Google Summer of Code
> Shawn> Mentor Summit.
>
> Oddly enough, I'm giving my "Intro to Git" talk at Google HQ on
> 12 october. Too bad you're just going to miss that. :)
Yea, seeing as how I've never had the chance to see you give a
talk I am quite disappointed by the poor timing. I'll just have
to catch the talk on Google Video. And shout questions at my wall
to see if you can answer them.
--
Shawn.
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary (long)
From: David Tweed @ 2007-10-05 1:48 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, Jakub Narebski, git
In-Reply-To: <20071005012726.GR2137@spearce.org>
On 10/5/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Thu, 4 Oct 2007, Jakub Narebski wrote:
> > > 26. Which porcelains do you use?
> > >
> > > Multiple answers (one can use more than one porcelain).
> > >
> > > Answer (multiple choice) | Count
> ...
> > > other | 14
FWIW, I answered other there because I use my chronoversion
hacky-scripts (in addition to doing some other fine-level work with at
the low level git command line). Obviously it's not a general purpose
porcelain and it's "deliberately not using" normal development
practice because I do lots of loosely related speculative research
rather than working on a well-defined "product". I was initially
confused by what the index does (particularly since in those days it
was often referred to as a cache) and so wrote the whole routines
using low-level commands; if I was to do it again I'd have my script
just call "git add" and then using the vanilla "git commit".
--
cheers, dave tweed__________________________
david.tweed@gmail.com
Rm 124, School of Systems Engineering, University of Reading.
"we had no idea that when we added templates we were adding a Turing-
complete compile-time language." -- C++ standardisation committee
^ permalink raw reply
* Re: Many gits are offline this week
From: alan @ 2007-10-05 1:59 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Shawn O. Pearce, git
In-Reply-To: <863awq5p1y.fsf@blue.stonehenge.com>
On Thu, 4 Oct 2007, Randal L. Schwartz wrote:
>>>>>> "Shawn" == Shawn O Pearce <spearce@spearce.org> writes:
>
> Shawn> Dscho and I will be (at least mostly) offline for the next four
> Shawn> days as we travel to San Jose for the 2007 Google Summer of Code
> Shawn> Mentor Summit.
>
> Oddly enough, I'm giving my "Intro to Git" talk at Google HQ on
> 12 october. Too bad you're just going to miss that. :)
Are you going to have the same heckler as the Advanced Topics meeting? ]:>
--
Never trust a queue structure designed by a cryptographer.
^ permalink raw reply
* [PATCH] setup/rev-parse: allow HEAD to be spelled 'head'
From: Sam Vilain @ 2007-10-05 3:09 UTC (permalink / raw)
To: git; +Cc: Sam Vilain
If the repository got mangled by FAT capitalization rules, then a ref
such as "HEAD" will become "head" once it is back on a non-FAT FS.
Check for this condition in resolve_refs and in the setup code.
Suggested-by: Francois Marier <francois@debian.org>
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
---
This should probably help people putting their git repos on
FAT USB sticks.
refs.c | 28 ++++++++++++++++++++++++----
setup.c | 7 +++++--
2 files changed, 29 insertions(+), 6 deletions(-)
diff --git a/refs.c b/refs.c
index 09a2c87..89ffb15 100644
--- a/refs.c
+++ b/refs.c
@@ -400,10 +400,30 @@ const char *resolve_ref(const char *ref, unsigned char *sha1, int reading, int *
}
list = list->next;
}
- if (reading || errno != ENOENT)
- return NULL;
- hashclr(sha1);
- return ref;
+ if (reading || errno != ENOENT) {
+ /*
+ * Hack for FAT-mangled ref filenames
+ */
+ if (strlen(ref) <= 8) {
+ char lc_name[9];
+ char* i;
+ strncpy(&lc_name, ref, 9);
+ for (i = lc_name; *i; i++) {
+ *i = tolower(*i);
+ }
+ path = git_path("%s", lc_name);
+ if (lstat(path, &st) < 0) {
+ return NULL;
+ }
+ }
+ else {
+ return NULL;
+ }
+ }
+ else {
+ hashclr(sha1);
+ return ref;
+ }
}
/* Follow "normalized" - ie "refs/.." symlinks by hand */
diff --git a/setup.c b/setup.c
index 06004f1..284d7b9 100644
--- a/setup.c
+++ b/setup.c
@@ -168,8 +168,11 @@ static int is_git_directory(const char *suspect)
return 0;
strcpy(path + len, "/HEAD");
- if (validate_headref(path))
- return 0;
+ if (validate_headref(path)) {
+ strcpy(path + len, "/head");
+ if (validate_headref(path))
+ return 0;
+ }
return 1;
}
--
1.5.3.2.3.g2f2dcc-dirty
^ permalink raw reply related
* The 3rd msysGit Herald
From: Johannes Schindelin @ 2007-10-05 3:13 UTC (permalink / raw)
To: git, msysgit
[-- Attachment #1: Type: TEXT/PLAIN, Size: 6130 bytes --]
Good morning git land!
This hour of the tiger in Scotland is as good an occasion as any to issue
the third episode of the msysGit Herald, the not-quite-biweekly news letter
to keep you informed about msysGit, the effort to bring one of the most
powerful Source Code Management systems to the poor souls stuck with
Windows.
These are the covered topics:
Umlauts in the path name
Compiling Perl from scratch!
Including the 'html' branch as a submodule
The language wars, this time: no .NET in msysGit
Inno installer
Where is HOME?
Umlauts in the path name
========================
Another issue cropped up the other day; MSys cannot handle path names with
umlauts alright. For example, if you try to remove a checkout of git.git
(which unnecessarily contains an umlaut in a test for gitweb) with MSys'
"rm", it will fail. It will say that it removed the file "Märchen", but
the file is still there.
We will see if at some point in future, we will be able to compile MSys
from within msysGit, and maybe we will be able to fix this issue.
For now, please try to avoid spaces in the installation path of msysGit!
Compiling Perl from scratch!
============================
Somehow I lured Simon Sasburg into trying to get Perl compiling inside
msysGit. I already had compiled it, using the "official" method,
downloading dmake and stuff, and the result was a commit with a recipe
how to compile it from scratch (e887f810 in the "full" branch).
However, this was a MinGW Perl, not a MSys Perl. Remember: the main
difference (usage-wise) is that MSys has a fake "/" directory. So
wherever you install it, it will be able to find /etc/bla. And the
perl I built cannot use that, and therefore does not find essential
parts of git, making it useless for our purposes.
Simon jumped through the hoops and got some additional packages from
mingw.org installed, and was nice enough to put that into a branch
in msysgit.git: msysperl. When checking that branch out, you will
have a /perl directory with two scripts: one to download perl and
apply some patches, and another to build perl.
Including the 'html' branch as a submodule
==========================================
Steffen Prohaska, who was very interested in msysGit right from the start,
has joined the msysGit team. He realised that the help was not working,
and created a new submodule containing the html pages, along with some
patches to allow opening these pages, even when msysGit (or GitMe or
WinGit) was installed to a path containing spaces.
So all of you, seeking help in WinGit, look forward to the release 0.3
of WinGit, which will include some.
The language wars, this time: no .NET in msysGit
================================================
We realised pretty soon that some convenient parts which are present in
every Unix system are simply lacking in Windows.
It begins with the missing C compiler, which is so untrivial to set up
that there was a demand for msysGit. But it certainly does not end
there.
For example, the effort to compile Perl from scratch (see above) is
necessary so that we have the chance to compile the modules missing
for git-svn support.
In the midst of these efforts, a tool was checked in that allows you
to call an arbitrary diff viewer, by setting three environment
variables.
Of course, you could do that with a simple shell script, but it seems
some people are so uncomfortable with the shell that they have to
write a program to do the same.
The big problem with this program, though, is that it was written
using .NET 2.0.
I already had many complaints how many dependencies msysGit has, and
was actively working on reducing the size of the WinGit installer
by leaving out non-essential parts; and there was even talk about
making a WinGit installer that does not even install Perl.
So I was not happy with the situation, and moved the commits out of
our 'devel' branch into the branch 'dmitry/dotnet-gitdiff'.
In the wake of this cleanup, Steffen Prohaska proposed that all new
changes should first be committed to topic branches, and only move them
into 'devel' once another developer has seen them.
For a short time I was even thinking about asking all developers to
just fork msysgit.git, and work in their repositories, but for the
moment, it seems that we're okay with Steffen's proposal.
However, everyone who disagrees with me is (of course) free to fork
msysgit.git; repo.or.cz makes that trivial.
Inno installer
==============
Sebastian Schubert, a colleague of Steffen, was so disgusted with my
beautiful 7-Zip/Tk based installer that he decided to work on an Inno
based one.
Now, we already have a script to make an installer using NSIS (see the
"nsis-installer" branch of msysgit.git), but my biggest concern was
always to avoid installing other software than msysGit to build the
installers. And as far as I can tell, NSIS is not really small.
Sebastian has promised that Inno would be small enough, so I guess
we'll just wait and see...
If it finds the unilateral love of the msysGit team members, version
0.3 of the WinGit installer will already be based on Sebastian's work.
Where is HOME?
==============
While working on the Inno setup, Sebastian suggested installing an
Explorer extension so that you can "Start Git Shell here" in the
Explorer. Apparently a component of Inno makes it easy to add such a
small Explorer extension.
Unless you do a "cd $HOME" in /etc/profile, which we do. So, when
calling the shell (which has to be a login shell) we want to stay
where we are, but we do not (this was requested in Issue 51 in our
issue tracker).
In the following discussions, it appeared that not everybody is
happy that Windows, Cygwin and MSys all have different home
directories.
I proposed changing the HOME in MSys to the Windows home, also known
as %USERPROFILE%. This would help new users, as well as uninstalling
(since the repositories would be outside of the installation directory),
but it would also involve changing existing setups, and we're close to
700 downloads for WinGit, and double that for msysGit.
This issue is not resolved yet.
^ permalink raw reply
* Re: [PATCH] setup/rev-parse: allow HEAD to be spelled 'head'
From: Johannes Schindelin @ 2007-10-05 3:16 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <1191553750-25562-1-git-send-email-sam.vilain@catalyst.net.nz>
Hi,
On Fri, 5 Oct 2007, Sam Vilain wrote:
> If the repository got mangled by FAT capitalization rules, then a ref
> such as "HEAD" will become "head" once it is back on a non-FAT FS.
Can we have that optionally, please? I.e. triggered by something like
"core.caseChallengedFS = true"?
Ciao,
Dscho
^ permalink raw reply
* Re: A few usability question about git diff --cached
From: David Tweed @ 2007-10-05 5:22 UTC (permalink / raw)
To: Matthieu Moy
Cc: Johannes Schindelin, Junio C Hamano, Miklos Vajna,
Paolo Ciarrocchi, Git Mailing List
In-Reply-To: <vpqtzp7ndn3.fsf@bauges.imag.fr>
On 10/4/07, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> It makes more sense to me.
>
> For me, a "cache" is a fast-access copy of something, that I can
> rebuild at any time. Cache should be only a matter of performance, if
> the "cache" for an application changes its functionality, it means the
> cache has been too optimistic. Git's index is not that, "git add"
> means "add this to the index", which itself means "put that in the
> list of things to commit", and not "get a copy of that to work faster
> with it".
Just to say this interpretation is also the natural interpretation I
have for the term "cached", and it confused me no end when I was first
learning about git that the index was referred to as a cache. To be
fair, git the documentation was in flux at that time and it's now
referred too as a cache in very few places now.
An example of the kind of thing I have to think carefully about even
now, Junio said in a different mail:
"--cached means work only on the "cached information in index."
If I understand correctly, the term "cached information in index" is
more correctly "stored information in index" (or perhaps more
technically "staged information in index") since there may be
information in there which isn't a cache because it's no longer
present anywhere else (ie, not in a commit yet but also changed in the
working tree).
It's not a big thing, but the usage of cached in git still quite confuses me.
--
cheers, dave tweed__________________________
david.tweed@gmail.com
Rm 124, School of Systems Engineering, University of Reading.
"we had no idea that when we added templates we were adding a Turing-
complete compile-time language." -- C++ standardisation committee
^ permalink raw reply
* Re: A few usability question about git diff --cached
From: Miles Bader @ 2007-10-05 5:59 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Paolo Ciarrocchi, Git Mailing List
In-Reply-To: <5ACC5CA7-8314-4035-94EC-190138A25EBD@wincent.com>
Wincent Colaiuta <win@wincent.com> writes:
> You're probably right that the option name is confusing, I guess
> changing it to "--index" would be a good idea, continuing to support
> "--cached" but marking it as deprecated before finally removing it at
> some point in the future.
Personally all I want is a short-option alias for --cached!
Hopefully something easily type-able (not uppercase)...
-Miles
--
Americans are broad-minded people. They'll accept the fact that a person can
be an alcoholic, a dope fiend, a wife beater, and even a newspaperman, but if a
man doesn't drive, there is something wrong with him. -- Art Buchwald
^ permalink raw reply
* Re: Question about "git commit -a"
From: Miles Bader @ 2007-10-05 6:04 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Paolo Ciarrocchi
In-Reply-To: <200710042225.13670.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> Now I cherry pick hunks together in coherent groups
>
> git add -i
Ooooohhhhh,.....
Boy I didn't know about add -i... that looks, really, really, really
useful...
Thanks,
-miles
--
Run away! Run away!
^ permalink raw reply
* Re: size_t vs "unsigned long"
From: Kyle Moffett @ 2007-10-05 6:27 UTC (permalink / raw)
To: Florian Weimer; +Cc: Pierre Habouzit, Junio C Hamano, git
In-Reply-To: <877im3khj0.fsf@mid.deneb.enyo.de>
On Oct 03, 2007, at 17:36:03, Florian Weimer wrote:
> * Pierre Habouzit:
>> Well, afaict, on every linux archs I know of, unsigned longs and
>> size_t are the same.
>
> IIRC, 64-bit Windows uses 64-bit points (duh) and hence a 64-bit
> size_t, but still has got 32-bit longs. Documentation is a bit
> sparse on this matter (because you are supposed to use LONG, DWORD
> and friends anyway).
For reference, Linux is always an LP32 (long-and-pointer-are-32-bit)
or LP64 (long-and-pointer-are-64-bit) platform. On the other hand,
for crappy backwards-compat reasons, Windows is either LP32 or LLP64
(long-long-and-pointer-are-64-bit). I think most of the remaining
UNIXes fall into the LP32/LP64 category, the LLP64 platforms are
fairly rare (thankfully).
Cheers,
Kyle Moffett
^ permalink raw reply
* Re: A few usability question about git diff --cached
From: Matthieu Moy @ 2007-10-05 6:40 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Johannes Schindelin, Junio C Hamano, Miklos Vajna,
Paolo Ciarrocchi, Git Mailing List
In-Reply-To: <20071004161935.GC17487@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
>> The stat-information, and sha1sum are actually a cache, but they don't
>> have to be user-visible, except for speed.
>
> That's a big exception.--b.
Speed _is_ important, of course. But the user only benefits from
speed, he doesn't have to manipulate it explicitely. I may be
repeating myself, but "diff --cached" doesn't mean "diff using the
stat-cache", it means "diff using the cached _content_", which is
really unrelated from the stat-cache.
Mercurial also has fast diff (perhaps a bit slower that git, but same
order of magnitude), and has no user-visible index.
--
Matthieu
^ 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