* [PATCH] cleanup unpack-trees.c: shrink struct tree_entry_list
From: René Scharfe @ 2007-07-24 21:54 UTC (permalink / raw)
To: David Kastrup, Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <85d4ykjtuc.fsf@lola.goethe.zz>
David Kastrup schrieb:
> The definition of tree_entry_list ist the following
>
> struct tree_entry_list {
> struct tree_entry_list *next;
> unsigned directory : 1;
> unsigned executable : 1;
> unsigned symlink : 1;
> unsigned int mode;
> const char *name;
> const unsigned char *sha1;
> };
>
> but it appears to me that the only of the bit fields that is used at
> all is "directory" : all other uses revert to "mode" which directory
> presumably could do as well.
>
> Is there something I am overlooking?
A C compiler can give the definite answer: no.
--- 8< ---
Remove the two write-only fields executable and symlink from struct
tree_entry_list. Also replace usage of the field directory with
S_ISDIR checks on the mode field, and then remove this now obsolete
field, too. Noticed by David Kastrup.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
This patch slightly reduces RAM usage, but it also shrinks the code
without reducing functionality or readability, which is more
interesting.
unpack-trees.c | 12 +++---------
1 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/unpack-trees.c b/unpack-trees.c
index 7cc029e..3b32718 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -11,9 +11,6 @@
struct tree_entry_list {
struct tree_entry_list *next;
- unsigned directory : 1;
- unsigned executable : 1;
- unsigned symlink : 1;
unsigned int mode;
const char *name;
const unsigned char *sha1;
@@ -38,9 +35,6 @@ static struct tree_entry_list *create_tree_entry_list(struct tree *tree)
entry->name = one.path;
entry->sha1 = one.sha1;
entry->mode = one.mode;
- entry->directory = S_ISDIR(one.mode) != 0;
- entry->executable = (one.mode & S_IXUSR) != 0;
- entry->symlink = S_ISLNK(one.mode) != 0;
entry->next = NULL;
*list_p = entry;
@@ -141,9 +135,9 @@ static int unpack_trees_rec(struct tree_entry_list **posns, int len,
#endif
if (!first || entcmp(first, firstdir,
posns[i]->name,
- posns[i]->directory) > 0) {
+ S_ISDIR(posns[i]->mode)) > 0) {
first = posns[i]->name;
- firstdir = posns[i]->directory;
+ firstdir = S_ISDIR(posns[i]->mode);
}
}
/* No name means we're done */
@@ -177,7 +171,7 @@ static int unpack_trees_rec(struct tree_entry_list **posns, int len,
continue;
}
- if (posns[i]->directory) {
+ if (S_ISDIR(posns[i]->mode)) {
struct tree *tree = lookup_tree(posns[i]->sha1);
any_dirs = 1;
parse_tree(tree);
^ permalink raw reply related
* Re: [PATCH] filter-branch: fix dash complaining about "Missing '))'"
From: Johannes Schindelin @ 2007-07-24 22:22 UTC (permalink / raw)
To: René Scharfe; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <46A66F39.20507@lsrfire.ath.cx>
Hi,
On Tue, 24 Jul 2007, Ren? Scharfe wrote:
> On e.g. Ubuntu, dash is used as /bin/sh. Unlike bash it parses
> commands like
>
> a=$((echo stuff) | wc)
>
> as an arithmetic expression while what we want is a subshell inside
> a command substitution.
Ah, well. I think I should switch to Ubuntu, to suffer the same...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add a 1-second sleep to git-cvsexportcommit test
From: Robin Rosenberg @ 2007-07-24 22:56 UTC (permalink / raw)
To: Linus Torvalds
Cc: Simon 'corecode' Schubert, Junio C Hamano, Jason Sewall,
git, raa.lkml
In-Reply-To: <alpine.LFD.0.999.0707241144490.3607@woody.linux-foundation.org>
tisdag 24 juli 2007 skrev Linus Torvalds:
>
> On Tue, 24 Jul 2007, Robin Rosenberg wrote:
> >
> > 27778 time(NULL) = 1185268822
> > 27778 gettimeofday({1185268822, 953340}, NULL) = 0
> >
> > Here CVS sleeps. The amount varies between invocations since it
> > only sleeps enough for the seconds to wrap.
> >
> > 27778 nanosleep({0, 46660000}, NULL) = 0
> > 27778 time(NULL) = 1185268823
>
> Btw, this is *really* dangerous and buggy.
>
> The reason? The CPU real-time clock is very different from whatever clock
> the filesystems may use.
>
> Filesystems generally do not use the same clock as the CPU does. That's
> obviously true for things like networked filesystems, but it's actually
> true even for local filesystems (even on UP) because the CPU "realtime"
> clock rather expensive and much too exact for them. It does all the fancy
> NTP date correction etc, and it has all the complex code to actually make
> sure you don't get any time jumps etc.
Having our mind enlightened, I propose this or nothing as a workaround. Since
cvsexportcommit is really a CVS workaround we might work around some bugs
in CVS itself while we're at it.
-- robin
From: Robin Rosenberg <robin.rosenberg@dewire.com>
Date: Wed, 25 Jul 2007 00:53:24 +0200
Subject: [PATCH] Sleep in git-cvsexportcommit
If git cvsexportcommit is executed fast enough in sequence, the CVS
timestamps could end up being the same. CVS tries to fix this
by sleeping until the CPU clock changes seconds. Unfortunately,
the CPU clock and the file system clock are not necessarily the same, so
the timestamps could be the same anyway. When that happens CVS may not
recognize changed files and cvs will forget to commit some files.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
git-cvsexportcommit.perl | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index d6ae99b..f6366be 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -277,6 +277,11 @@ if ($opt_c) {
# clean up
unlink(".cvsexportcommit.diff");
+# CVS version 1.11.x and 1.12.x sleeps the wrong way to ensure the timestamp
+# used by CVS and the one set by subsequence file modifications are different.
+# If they are not different CVS will not detect changes.
+sleep(1);
+
sub usage {
print STDERR <<END;
Usage: GIT_DIR=/path/to/.git ${\basename $0} [-h] [-p] [-v] [-c] [-f] [-m msgprefix] [ parent ] commit
--
1.5.2.3
^ permalink raw reply related
* Re: git proxy issue
From: Johannes Schindelin @ 2007-07-24 23:07 UTC (permalink / raw)
To: Aubrey Li; +Cc: Junio C Hamano, git
In-Reply-To: <6d6a94c50707152055m4a8e24b8v7dc90101316e6b88@mail.gmail.com>
Hi,
On Mon, 16 Jul 2007, Aubrey Li wrote:
> On 7/16/07, Junio C Hamano <gitster@pobox.com> wrote:
> > "Aubrey Li" <aubreylee@gmail.com> writes:
> >
> > > From which release version git proxy is supported?
> >
> > v0.99.9k (Nov 25 2005) is the first tagged release (the patch
> > itself was from Nov 4 2005).
> >
> >
> oh, so how to config it?
Look into Documentation/git-config.txt. (Or "man git-config", if the man
pages are installed.)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/3] Teach "git branch" about --new-workdir
From: Alex Riesen @ 2007-07-24 23:15 UTC (permalink / raw)
To: Marius Storm-Olsen
Cc: Johannes Schindelin, Junio C Hamano, Shawn O. Pearce,
Julian Phillips, git
In-Reply-To: <46A654A6.5070802@trolltech.com>
Marius Storm-Olsen, Tue, Jul 24, 2007 21:36:06 +0200:
> IMO Windows user expect files to be DOS style, since all other files
> are. Yes, most newer tools 'handle' Unix style files, but creating new
> ones will mostly be DOS style. Some will actually wreak havoc on your
> files, and start adding DOS line endings in the middle of your Unix line
> ending file. I've seen it happen. So, dealing with Unix style text files
> on Windows can be a problem for some people.
I have to stay with Windows, but I'd absolute hate having their stupid
line-ending by default. As will my project supervisor, and he gets
changes from something like 300 developers. You will definitely get
their votes against changing the default
> > Git is really slowed down tremendously just by the fact that it runs on
> > Windows. You should not add to that.
>
> The auto crlf conversion is not the slow down here, and the time spent
> there is negligible. I use autocrlf on all my repos on Windows, and
> don't notice it. Filestat'ing on the other hand.. :-)
Of course you wont notice it: you're already on Windows.
> > IMHO in most cases -- even on Windows -- you do not want to set autocrlf
> > at all. Because you do not need to store the file different from the
> > version you have in the working tree.
>
> Not true. I believe, especially at the moment, most Git users on Windows
> are mostly developing code in a cross-platform manner, and therefore
> care about this problem.
Yes. They solve it by working fulltime in \n-lineending. Avoiding that
stupid Visual Studio and Notepad helps too.
> > The only situation where I think it makes sense, is when you have both
> > Windows and Unix developers, _and_ your Windows tools sometimes produce
> > CR/LF stupidly. But then I'd set it to "input".
>
> That's ok _now_, because most of the Git user group is experienced
> developer that understand the problem. I'm trying to see past that
> state, and prepare Git for more 'common' usage on Windows. They'd expect
> text files on Windows to be handled correctly, without any fuzz.
Just make the windows installer to setup templates for CR/LF depending
on checkbox "[ ] I am Windows idiot, standard issue".
> No tweaking of config options to make it work on Windows. No problems
> with sharing repositories with Unix developers. Just work. That's not
> the current state. But it could be.
It is for me. It will not be that with your suggested default.
> Ok, I come from the Perforce world, so here how it works there:
> 1) Files are stored with Unix line endings in the repository.
> 2) Conversion is done on Windows (and older Macs) upon checkout, if the
> file is a text file.
> 3) It has binary file detection when you add it to the depot, so if you
> and to add a DOS line ending file to the repo, you have to mark it as a
> binary file manually
You always setup the lineending conversion in perforce. For each and
every client. There is no default. I just don't see what to learn from
them (if there ever was something to learn from).
> ... And Git would probably be adapted on
> Windows more quickly, which this is all about. :-) IMHO.
It is hardly worth it. Git already has to put up with ugly workarounds
just because of the stupidities coming from that windows. It has had
seldom any benefit from supporting this !@#$ing awkward platform.
^ permalink raw reply
* [PATCH (amend)] gitweb: More detailed error messages for snapshot format
From: Jakub Narebski @ 2007-07-24 23:19 UTC (permalink / raw)
To: Matt McCutchen; +Cc: git
In-Reply-To: <3bbc18d20707241450y48ef0485i2809c632ac2e643@mail.gmail.com>
Improve error messages for snapshot format in git_snapshot:
distinguish between situation where snapshots are turned off, where
snapshot format ('sf') parameter is invalid, where given snapshot
format does not exist in %known_snapshot_formats hash, and where
gitweb was given unsupported snapshot format.
While at it, use first from all supported snapshots format as default,
if no snapshot format was provided.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Matt McCutchen wrote:
> On 7/24/07, Jakub Narebski <jnareb@gmail.com> wrote:
> > Improve error messages for snapshot format in git_snapshot:
> > distinguish between situation where snapshots are turned off, where
> > snapshot format ('sf') parameter is invalid,
[...]
> I also noticed that the check for an "invalid" format requires that it
> contain at least one good character, not that it contain no bad
> characters, which was what I originally meant. It would be nice to
> fix the check, or the check could even be removed altogether since
> gitweb refuses any format that isn't in %known_snapshot_formats . (I
> think I was misguidedly paranoid to add it in the first place.)
This fixes the check (although perhaps the check should be removed).
gitweb/gitweb.perl | 13 ++++++++++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index fdfce31..0acd0ca 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -4317,9 +4317,16 @@ sub git_snapshot {
@supported_fmts = filter_snapshot_fmts(@supported_fmts);
my $format = $cgi->param('sf');
- unless ($format =~ m/[a-z0-9]+/
- && exists($known_snapshot_formats{$format})
- && grep($_ eq $format, @supported_fmts)) {
+ if (!@supported_fmts) {
+ die_error('403 Permission denied', "Permission denied");
+ }
+ # default to first supported snapshot format
+ $format ||= $supported_fmts[0];
+ if ($format !~ m/^[a-z0-9]+$/) {
+ die_error(undef, "Invalid snapshot format parameter");
+ } elsif (!exists($known_snapshot_formats{$format})) {
+ die_error(undef, "Unknown snapshot format");
+ } elsif (!grep($_ eq $format, @supported_fmts)) {
die_error(undef, "Unsupported snapshot format");
}
--
1.5.2.4
^ permalink raw reply related
* Re: [PATCH] Add a 1-second sleep to git-cvsexportcommit test
From: Linus Torvalds @ 2007-07-24 23:19 UTC (permalink / raw)
To: Robin Rosenberg
Cc: Simon 'corecode' Schubert, Junio C Hamano, Jason Sewall,
git, raa.lkml
In-Reply-To: <200707250056.20880.robin.rosenberg.lists@dewire.com>
On Wed, 25 Jul 2007, Robin Rosenberg wrote:
>
> Having our mind enlightened, I propose this or nothing as a workaround. Since
> cvsexportcommit is really a CVS workaround we might work around some bugs
> in CVS itself while we're at it.
Side note: I think the reason it came up now is that with CONFIG_NO_HZ the
Linux filesystem clock will easily be off by half a second even for local
filesystems.
With CONFIG_NO_HZ, we don't update the time as religiously, and as a
result, people who look at the low-resolution time (like filesystems) will
get a noticeable skew.
Quite frankly, that's a Linux kernel bug, and we'll fix it. But it doesn't
really invalidate the argument: applications really shouldn't depend on
the "filesystem time" being in sync with the "CPU time", and it may be
that the kernel bug was the one that ended up exposing this mis-feature of
CVS.
Normally, Linux (and probably most other systems) will keep the local
filesystems synchronized to within at least one clock-tick of the
real-time clock, so the clock skew between filesystems and CPU is at most
in the "few millisecond" range.
That's also the kind of range that NTP will largely guarantee, so
generally, in most circumstances, while you cannot (and shouldn't) expect
filesystem times to be "accurate", in most good situations you'll never
see skews over a few milliseconds.
(But on the other hand, search for "kerberos" and "time skew" on google,
and you see discussions about allowing five *minutes* of skew etc, so
clearly the model of "everybody runs NTP" isn't exactly all of it ;)
So I suspect that the CVS code is (a) buggy and (b) hard to show the bug
actually triggering on a well-maintained machine, and that it may well be
the case that the only reason it shows up as a bug now is that Jason is
running a recent kernel with CONFIG_NO_HZ. I have no idea what the default
Fedora 7 kernel does.
Linus
^ permalink raw reply
* Re: StGIT (or guilt) + git-svn?
From: Steven Walter @ 2007-07-24 23:48 UTC (permalink / raw)
To: Steven Grimm; +Cc: Steven Walter, 'git'
In-Reply-To: <46A5EE4B.7020905@midwinter.com>
On Tue, Jul 24, 2007 at 08:19:23PM +0800, Steven Grimm wrote:
> He wants to create some files in his git-svn clone and use git to manage
> them -- checkpointing his work in progress, backing out changes, etc.,
> without publishing those files to the svn repository. The files in
> question are not already in svn. But he does want to work on other files
> that *are* in the svn repository, and wants those changes to be
> committed back.
>
> So my assumption was that he would do something like maintain his
> local-only changes as StGIT patches that never get committed to git. His
> other changes would get committed from StGIT to git, and from there he'd
> do his normal git-svn dcommit. Or maybe git-svn dcommit followed by stg
> rebase since git-svn dcommit creates new revision IDs.
You certainly could do local versioning this way, but it isn't how I
accomplish the same thing. I keep another branch on top of my "public"
svn commits for local stuff. If I always run git-svn dcommit from the
public branch, the local changes will stay local. After committing, I
just have to rebase the local branch on onto git-svn.
--
-Steven Walter <stevenrwalter@gmail.com>
"A human being should be able to change a diaper, plan an invasion,
butcher a hog, conn a ship, design a building, write a sonnet, balance
accounts, build a wall, set a bone, comfort the dying, take orders,
give orders, cooperate, act alone, solve equations, analyze a new
problem, pitch manure, program a computer, cook a tasty meal, fight
efficiently, die gallantly. Specialization is for insects."
-Robert Heinlein
^ permalink raw reply
* submodule init problem
From: Ricky Nite @ 2007-07-25 0:09 UTC (permalink / raw)
To: git
Hello,
I encountered this message in "git submodule init":
"No url found for submodule path '<submodule>' in .gitmodules"
But when I look at .gitmodules, the <submodule> url is there.
Subsequently, I cannot do "git submodule update"
Here's the full log:
rnite@linuskarl:~/git_dev/myproj$ ~/bin/git --version
git version 1.5.3.rc2.g11308
rnite@linuskarl:~/git_dev$ mkdir flash
rnite@linuskarl:~/git_dev$ mkdir flashboard
rnite@linuskarl :~/git_dev$ cd flash
rnite@linuskarl:~/git_dev/flash$ echo "foo" > flash.v
rnite@linuskarl:~/git_dev/flash$ ~/bin/git init
Initialized empty Git repository in .git/
rnite@linuskarl:~/git_dev/flash$ ~/bin/git add flash.v
rnite@linuskarl:~/git_dev/flash$ ~/bin/git commit -a -m "initial
commit of flash module"
Created initial commit c19874e: initial commit of flash module
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 flash.v
rnite@linuskarl:~/git_dev/flash$ cd ../flashboard
rnite@linuskarl:~/git_dev/flashboard$ echo "foo" > flashboard.v
rnite@linuskarl:~/git_dev/flashboard$ ~/bin/git init
Initialized empty Git repository in .git/
rnite@linuskarl:~/git_dev/flashboard$ ~/bin/git add flashboard.v
rnite@linuskarl:~/git_dev/flashboard$ ~/bin/git commit -a -m "initial
commit of flashboard module"
Created initial commit 45dff87: initial commit of flashboard module
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 flashboard.v
rnite@linuskarl:~/git_dev/flashboard$ cd ..
rnite@linuskarl :~/git_dev$ mkdir myproj
rnite@linuskarl:~/git_dev$ cd myproj
rnite@linuskarl:~/git_dev/myproj$ ~/bin/git init
Initialized empty Git repository in .git/
rnite@linuskarl:~/git_dev/myproj$ ~/bin/git submodule add ~/git_dev/flash
Initialized empty Git repository in /home/rnite/git_dev/myproj/flash/.git/
remote: Generating pack...
remote: Done counting 3 objects.
Deltifying 3 objects...
100% (3/3) done
Total 3 (delta 0), reused 0remote: (delta 0)
Indexing 3 objects...
100% (3/3) done
rnite@linuskarl:~/git_dev/myproj$ ~/bin/git submodule add ~/git_dev/flashboard
Initialized empty Git repository in /home/rnite/git_dev/myproj/flashboard/.git/
remote: Generating pack...
remote: Done counting 3 objects.
Deltifying 3 objects...
100% (3/3) done
Total 3 (delta 0), reused 0remote: (delta 0)
Indexing 3 objects...
100% (3/3) done
rnite@linuskarl:~/git_dev/myproj$ ~/bin/git submodule init
No url found for submodule path 'flash' in .gitmodules
rnite@linuskarl:~/git_dev/myproj$ cat .gitmodules
[submodule "flash"]
path = flash
url = /home/rnite/git_dev/flash/.git
[submodule "flashboard"]
path = flashboard
url = /home/rnite/git_dev/flashboard/.git
I can add more submodules, but the message stays the same after "git
submodule init" and I cannot do "git submodule update"
help,
RickyN
^ permalink raw reply
* Re: [PATCH 3/3] Teach "git branch" about --new-workdir
From: Jakub Narebski @ 2007-07-25 0:09 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0707241252040.28577@reaper.quantumfyre.co.uk>
Julian Phillips wrote:
> On Tue, 24 Jul 2007, Marius Storm-Olsen wrote:
>
>>> I do not know this is an appropriate itch to scratch for a Windows
>>> developer to begin with. The new-workdir setting *is* about
>>> symlinked .git/ metainfo space. If somebody wants to work on a
>>> filesystem without symlink, he should not be using new-workdir but
>>> something else. E.g. GIT_DIR + GIT_WORK_TREE, or perhaps GIT_DIR +
>>> core.worktree comes to mind.
>>
>> That's is definitely an option, though it seems to me that its more like
>> giving up than a finding a proper solution. In any case, it would result in
>> two completely different workflows on systems with and without symlink
>> support. I work on both, and would like my workflow to be consistent. Of
>> course I could easily add my own scripts on top to achieve this, but then
>> we're going back into h4x0r land and not making Git more 'available'.
>>
>> The new-workdir feature doesn't *have* to be about symlinked .git/ metainfo
>> space, but could also be about symref'ed .git/ metainfo.
>> (A discussion was done in 2005s "Getting rid of symlinks in .git?", but the
>> conclusion was that it would slow it down too much? *ponder*)
>
> Symref'ed isn't really the right term ... we're not talking about refs
> here. You would have to basically implement symlinks _inside_ git ...
>
> New-workdir really _is_ all about symlinks. It already exists as a
> contrib feature - and moving it into core is (as I understand it) really
> just moving it, not redesigning.
>
> If you were going to avoid symlinks, then probably the cleanest way would
> be to have an explict way to point at the actual repo - rather than making
> the working look like a repo if you squint hard enough. Which sounds
> rather like it would be an extension to GIT_DIR + GIT_WORK_TREE. I
> haven't looked at it, but it shouldn't be too hard to have a mechanism
> that automatically does GIT_DIR=<there> GIT_WORK_TREE==<here> when the
> appropriate setup is in place? Though you would have to get it into all
> the appropriate places ...
I think it could be best solved by having in "worktree" .git/config with
core.gitdir which functions like lower layer in UnionFS like manner. It
means that if git cannot find a file or directory in .git, then it tries
to find it in core.gitdir.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: submodule init problem
From: Ricky Nite @ 2007-07-25 0:30 UTC (permalink / raw)
To: git
In-Reply-To: <d4b731510707241709pcad0a4bj85b71892cd2de84c@mail.gmail.com>
This problem doesn't seem to occur if I rename my submodules (but I
really don't want to):
rnite@linuskarl:~/git_dev$ mkdir moduleA
rnite@linuskarl:~/git_dev$ mkdir moduleB
rnite@linuskarl:~/git_dev$ cd moduleA
rnite@linuskarl:~/git_dev/moduleA$ echo "foo" > moduleAtop.v
rnite@linuskarl:~/git_dev/moduleA$ ~/bin/git init
Initialized empty Git repository in .git/
rnite@linuskarl:~/git_dev/moduleA$ ~/bin/git add moduleAtop
rnite@linuskarl:~/git_dev/moduleA$ ~/bin/git commit -a -m"imitial commit"
Created initial commit f8bc70b: imitial commit
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 moduleAtop.v
rnite@linuskarl:~/git_dev/moduleA$ cd ../moduleB
rnite@linuskarl:~/git_dev/moduleB$ echo "foo" > moduleBtop.v
rnite@linuskarl:~/git_dev/moduleB$ ~/bin/git init
Initialized empty Git repository in .git/
rnite@linuskarl:~/git_dev/moduleB$ ~/bin/git add moduleBtop.v
rnite@linuskarl:~/git_dev/moduleB$ ~/bin/git commit -a -m"imitial commit"
Created initial commit da426f3: imitial commit
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 moduleBtop.v
rnite@linuskarl:~/git_dev/moduleB$ cd ..
rnite@linuskarl:~/git_dev$ mkdir myproj2
rnite@linuskarl:~/git_dev$ cd myproj2
rnite@linuskarl:~/git_dev/myproj2$ ~/bin/git init
Initialized empty Git repository in .git/
rnite@linuskarl:~/git_dev/myproj2$ ~/bin/git submodule add ~/git_dev/moduleA
Initialized empty Git repository in /home/rnite/git_dev/myproj2/moduleA/.git/
remote: Generating pack...
remote: Done counting 3 objects.
Deltifying 3 objects...
100% (3/3) done
Total 3 (delta 0), reused 0remote: (delta 0)
Indexing 3 objects...
100% (3/3) done
rnite@linuskarl:~/git_dev/myproj2$ ~/bin/git submodule add ~/git_dev/moduleB
Initialized empty Git repository in /home/rnite/git_dev/myproj2/moduleB/.git/
remote: Generating pack...
remote: Done counting 3 objects.
Deltifying 3 objects...
100% (3/3) done
Total 3 (delta 0), reused 0remote: (delta 0)
Indexing 3 objects...
100% (3/3) done
rnite@linuskarl:~/git_dev/myproj2$ ~/bin/git submodule init
Submodule 'moduleA' (/home/rnite/git_dev/moduleA/.git) registered for
path 'moduleA'
Submodule 'moduleB' (/home/rnite/git_dev/moduleB/.git) registered for
path 'moduleB'
help,
RickyN
On 7/25/07, Ricky Nite <ricky.nite@gmail.com> wrote:
> Hello,
>
> I encountered this message in "git submodule init":
> "No url found for submodule path '<submodule>' in .gitmodules"
>
> But when I look at .gitmodules, the <submodule> url is there.
> Subsequently, I cannot do "git submodule update"
>
> Here's the full log:
> rnite@linuskarl:~/git_dev/myproj$ ~/bin/git --version
> git version 1.5.3.rc2.g11308
> rnite@linuskarl:~/git_dev$ mkdir flash
> rnite@linuskarl:~/git_dev$ mkdir flashboard
> rnite@linuskarl :~/git_dev$ cd flash
> rnite@linuskarl:~/git_dev/flash$ echo "foo" > flash.v
> rnite@linuskarl:~/git_dev/flash$ ~/bin/git init
> Initialized empty Git repository in .git/
> rnite@linuskarl:~/git_dev/flash$ ~/bin/git add flash.v
> rnite@linuskarl:~/git_dev/flash$ ~/bin/git commit -a -m "initial
> commit of flash module"
> Created initial commit c19874e: initial commit of flash module
> 1 files changed, 1 insertions(+), 0 deletions(-)
> create mode 100644 flash.v
> rnite@linuskarl:~/git_dev/flash$ cd ../flashboard
> rnite@linuskarl:~/git_dev/flashboard$ echo "foo" > flashboard.v
> rnite@linuskarl:~/git_dev/flashboard$ ~/bin/git init
> Initialized empty Git repository in .git/
> rnite@linuskarl:~/git_dev/flashboard$ ~/bin/git add flashboard.v
> rnite@linuskarl:~/git_dev/flashboard$ ~/bin/git commit -a -m "initial
> commit of flashboard module"
> Created initial commit 45dff87: initial commit of flashboard module
> 1 files changed, 1 insertions(+), 0 deletions(-)
> create mode 100644 flashboard.v
> rnite@linuskarl:~/git_dev/flashboard$ cd ..
> rnite@linuskarl :~/git_dev$ mkdir myproj
> rnite@linuskarl:~/git_dev$ cd myproj
> rnite@linuskarl:~/git_dev/myproj$ ~/bin/git init
> Initialized empty Git repository in .git/
> rnite@linuskarl:~/git_dev/myproj$ ~/bin/git submodule add ~/git_dev/flash
> Initialized empty Git repository in /home/rnite/git_dev/myproj/flash/.git/
> remote: Generating pack...
> remote: Done counting 3 objects.
> Deltifying 3 objects...
> 100% (3/3) done
> Total 3 (delta 0), reused 0remote: (delta 0)
> Indexing 3 objects...
> 100% (3/3) done
> rnite@linuskarl:~/git_dev/myproj$ ~/bin/git submodule add ~/git_dev/flashboard
> Initialized empty Git repository in /home/rnite/git_dev/myproj/flashboard/.git/
> remote: Generating pack...
> remote: Done counting 3 objects.
> Deltifying 3 objects...
> 100% (3/3) done
> Total 3 (delta 0), reused 0remote: (delta 0)
> Indexing 3 objects...
> 100% (3/3) done
> rnite@linuskarl:~/git_dev/myproj$ ~/bin/git submodule init
> No url found for submodule path 'flash' in .gitmodules
> rnite@linuskarl:~/git_dev/myproj$ cat .gitmodules
> [submodule "flash"]
> path = flash
> url = /home/rnite/git_dev/flash/.git
> [submodule "flashboard"]
> path = flashboard
> url = /home/rnite/git_dev/flashboard/.git
>
> I can add more submodules, but the message stays the same after "git
> submodule init" and I cannot do "git submodule update"
>
> help,
> RickyN
>
^ permalink raw reply
* Re: submodule init problem
From: Junio C Hamano @ 2007-07-25 1:49 UTC (permalink / raw)
To: Lars Hjemli, Sven Verdoolaege; +Cc: git, Ricky Nite
In-Reply-To: <d4b731510707241730u45755c0dwfde5e0b14b14f1da@mail.gmail.com>
"Ricky Nite" <ricky.nite@gmail.com> writes:
> This problem doesn't seem to occur if I rename my submodules (but I
> really don't want to):
>
> rnite@linuskarl:~/git_dev$ mkdir moduleA
> rnite@linuskarl:~/git_dev$ mkdir moduleB
> ...
> rnite@linuskarl:~/git_dev/myproj2$ ~/bin/git submodule init
> Submodule 'moduleA' (/home/rnite/git_dev/moduleA/.git) registered for
> path 'moduleA'
> Submodule 'moduleB' (/home/rnite/git_dev/moduleB/.git) registered for
> path 'moduleB'
>
> help,
> RickyN
>
> On 7/25/07, Ricky Nite <ricky.nite@gmail.com> wrote:
>> Hello,
>>
>> I encountered this message in "git submodule init":
>> "No url found for submodule path '<submodule>' in .gitmodules"
>>
>> But when I look at .gitmodules, the <submodule> url is there.
>> Subsequently, I cannot do "git submodule update"
>>
>> Here's the full log:
>> rnite@linuskarl:~/git_dev/myproj$ ~/bin/git --version
>> git version 1.5.3.rc2.g11308
>> rnite@linuskarl:~/git_dev$ mkdir flash
>> rnite@linuskarl:~/git_dev$ mkdir flashboard
Ok, this appears it most likely to be related to the fact that
one is a prefix of the other in problematic case.
Lars, Sven?
^ permalink raw reply
* Git User's Survey 2007
From: Jakub Narebski @ 2007-07-25 1:58 UTC (permalink / raw)
To: git
It was little more than year ago since Git User's Survey
http://marc.info/?l=git&m=115116592330648&w=2
http://git.or.cz/gitwiki/GitSurvey
I do wonder what has changed since then... ?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Add --show-size to git log to print message size
From: Junio C Hamano @ 2007-07-25 4:03 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550707140952hb60735bi95a4f03636c4aa99@mail.gmail.com>
I've been re-reviewing recent patches, and this is one of them.
However, I am wondering if this is an intended behaviour...
: git.git master; ./git-log --log-size --abbrev-commit --pretty=oneline \
ko/master..master
9d468ac... log size 47
Add --log-size to git log to print message size
ca193cf... log size 40
git am: skip pine's internal folder data
d1cc130... log size 48
Teach git-commit about commit message templates.
af66366... log size 41
Teach approxidate() to understand "never"
7b69b87... log size 64
git log -g: Complain, but do not fail, when no reflogs are there
2d8ae40... log size 49
send-email: Update regex parsing for pine aliases
f836f1a... log size 40
cvsexportcommit: avoid racy CVS problem.
1843d8d... log size 53
cleanup unpack-trees.c: shrink struct tree_entry_list
24d0063... log size 56
filter-branch: fix dash complaining about "Missing '))'"
3473e7d... log size 56
gitweb: More detailed error messages for snapshot format
93c22ee... log size 47
git.el: Support for incremental status updates.
^ permalink raw reply
* Re: StGIT (or guilt) + git-svn?
From: Steven Grimm @ 2007-07-25 6:35 UTC (permalink / raw)
To: Steven Walter; +Cc: 'git'
In-Reply-To: <20070724234817.GA29700@dervierte>
Steven Walter wrote:
> You certainly could do local versioning this way, but it isn't how I
> accomplish the same thing. I keep another branch on top of my "public"
> svn commits for local stuff. If I always run git-svn dcommit from the
> public branch, the local changes will stay local. After committing, I
> just have to rebase the local branch on onto git-svn.
Do you mix your public and private commits on the private branch, then
cherry-pick some of them over to the public branch before running
dcommit? Or do you have some other workflow?
That was actually my first suggestion to him, but he pointed out (and I
had to agree) that that would mean he's always just one mistake away
from publishing his local changes. All it takes is getting interrupted
for a moment and mistakenly thinking he already switched to the public
branch. He wants some less human-error-prone way to tell the system that
a particular change and/or a particular file is not intended for
publication, and for the system to just honor that without further human
intervention.
Actually, one could argue that the above isn't a git-svn issue at all.
You could reasonably want the same thing from git-push too (and even
from pull, though that'd be trickier.) I guess it'd take the form of
marking a commit as local-only, and having the system automatically
rebase all the local-only commits on top of the public ones.
Maybe a wrapper than maintains a pair of underlying git branches for
each user-visible branch would work. If you have a branch "foo" with
some public and some private changes (private ones in lower case here):
A---B---C---D---e---f---g foo
^ foo-public
Now if you commit a new private revision, it's like normal:
A---B---C---D---e---f---g---h foo
^ foo-public
But if you commit a new public revision, we do something like
git commit
git checkout foo-public
git cherry-pick foo
git checkout foo
git rebase foo-public
to get
A---B---C---D---H---e---f---g foo
^ foo-public
Then, when it comes time to do the push / dcommit, we always switch to
the foo-public branch first. We push / dcommit, then checkout foo and
rebase it on foo-public again (since svn dcommit will leave foo-public
pointing at a different revision.)
This seems like it should work in the context of git-svn with its
mostly-linear history. Not sure if it'd fall flat on its face in the
presence of lots of branching and merging.
I also suspect I've more or less just described StGIT and this would be
a big waste of time to reinvent from scratch.
-Steve
^ permalink raw reply
* [PATCH] t9200: Be careful when checking CVS/Entries
From: Junio C Hamano @ 2007-07-25 6:39 UTC (permalink / raw)
To: git; +Cc: Robin Rosenberg
CVS/Entries file can contain a line with a single D to say "this
directory does not have any subdirectories". Do not get
confused with such an entry. In the tests, we are only
interested in the tracked files, so we should only look at the
lines that begin with a '/'.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* I haven't figured out why, but sometimes CVS leaves such a
'D' line in a directory without a subdirectory, which really
screws up the comparison.
Moreover, test $(echo $(sort ... | ...)) = "e x p e c t e d"
was simply too ugly to read.
t/t9200-git-cvsexportcommit.sh | 64 ++++++++++++++++++++++++---------------
1 files changed, 39 insertions(+), 25 deletions(-)
diff --git a/t/t9200-git-cvsexportcommit.sh b/t/t9200-git-cvsexportcommit.sh
index 4efa0c9..910c584 100755
--- a/t/t9200-git-cvsexportcommit.sh
+++ b/t/t9200-git-cvsexportcommit.sh
@@ -28,6 +28,18 @@ git add empty &&
git commit -q -a -m "Initial" 2>/dev/null ||
exit 1
+check_entries () {
+ # $1 == directory, $2 == expected
+ grep '^/' "$1/CVS/Entries" | sort | cut -d/ -f2,3,5 >actual
+ if test -z "$2"
+ then
+ >expected
+ else
+ printf '%s\n' "$2" | tr '|' '\012' >expected
+ fi
+ diff -u expected actual
+}
+
test_expect_success \
'New file' \
'mkdir A B C D E F &&
@@ -43,10 +55,10 @@ test_expect_success \
id=$(git rev-list --max-count=1 HEAD) &&
(cd "$CVSWORK" &&
git cvsexportcommit -c $id &&
- test "$(echo $(sort A/CVS/Entries|cut -d/ -f2,3,5))" = "newfile1.txt/1.1/" &&
- test "$(echo $(sort B/CVS/Entries|cut -d/ -f2,3,5))" = "newfile2.txt/1.1/" &&
- test "$(echo $(sort C/CVS/Entries|cut -d/ -f2,3,5))" = "newfile3.png/1.1/-kb" &&
- test "$(echo $(sort D/CVS/Entries|cut -d/ -f2,3,5))" = "newfile4.png/1.1/-kb" &&
+ check_entries A "newfile1.txt/1.1/" &&
+ check_entries B "newfile2.txt/1.1/" &&
+ check_entries C "newfile3.png/1.1/-kb" &&
+ check_entries D "newfile4.png/1.1/-kb" &&
diff A/newfile1.txt ../A/newfile1.txt &&
diff B/newfile2.txt ../B/newfile2.txt &&
diff C/newfile3.png ../C/newfile3.png &&
@@ -67,12 +79,12 @@ test_expect_success \
id=$(git rev-list --max-count=1 HEAD) &&
(cd "$CVSWORK" &&
git cvsexportcommit -c $id &&
- test "$(echo $(sort A/CVS/Entries|cut -d/ -f2,3,5))" = "newfile1.txt/1.2/" &&
- test "$(echo $(sort B/CVS/Entries|cut -d/ -f2,3,5))" = "" &&
- test "$(echo $(sort C/CVS/Entries|cut -d/ -f2,3,5))" = "" &&
- test "$(echo $(sort D/CVS/Entries|cut -d/ -f2,3,5))" = "newfile4.png/1.2/-kb" &&
- test "$(echo $(sort E/CVS/Entries|cut -d/ -f2,3,5))" = "newfile5.txt/1.1/" &&
- test "$(echo $(sort F/CVS/Entries|cut -d/ -f2,3,5))" = "newfile6.png/1.1/-kb" &&
+ check_entries A "newfile1.txt/1.2/" &&
+ check_entries B "" &&
+ check_entries C "" &&
+ check_entries D "newfile4.png/1.2/-kb" &&
+ check_entries E "newfile5.txt/1.1/" &&
+ check_entries F "newfile6.png/1.1/-kb" &&
diff A/newfile1.txt ../A/newfile1.txt &&
diff D/newfile4.png ../D/newfile4.png &&
diff E/newfile5.txt ../E/newfile5.txt &&
@@ -115,12 +127,12 @@ test_expect_success \
id=$(git rev-list --max-count=1 HEAD) &&
(cd "$CVSWORK" &&
git cvsexportcommit -c $id &&
- test "$(echo $(sort A/CVS/Entries|cut -d/ -f2,3,5))" = "newfile1.txt/1.2/" &&
- test "$(echo $(sort B/CVS/Entries|cut -d/ -f2,3,5))" = "" &&
- test "$(echo $(sort C/CVS/Entries|cut -d/ -f2,3,5))" = "" &&
- test "$(echo $(sort D/CVS/Entries|cut -d/ -f2,3,5))" = "" &&
- test "$(echo $(sort E/CVS/Entries|cut -d/ -f2,3,5))" = "newfile5.txt/1.1/" &&
- test "$(echo $(sort F/CVS/Entries|cut -d/ -f2,3,5))" = "newfile6.png/1.1/-kb" &&
+ check_entries A "newfile1.txt/1.2/" &&
+ check_entries B "" &&
+ check_entries C "" &&
+ check_entries D "" &&
+ check_entries E "newfile5.txt/1.1/" &&
+ check_entries F "newfile6.png/1.1/-kb" &&
diff A/newfile1.txt ../A/newfile1.txt &&
diff E/newfile5.txt ../E/newfile5.txt &&
diff F/newfile6.png ../F/newfile6.png
@@ -133,12 +145,12 @@ test_expect_success \
id=$(git rev-list --max-count=1 HEAD) &&
(cd "$CVSWORK" &&
git cvsexportcommit -c $id &&
- test "$(echo $(sort A/CVS/Entries|cut -d/ -f2,3,5))" = "" &&
- test "$(echo $(sort B/CVS/Entries|cut -d/ -f2,3,5))" = "" &&
- test "$(echo $(sort C/CVS/Entries|cut -d/ -f2,3,5))" = "" &&
- test "$(echo $(sort D/CVS/Entries|cut -d/ -f2,3,5))" = "" &&
- test "$(echo $(sort E/CVS/Entries|cut -d/ -f2,3,5))" = "newfile5.txt/1.1/" &&
- test "$(echo $(sort F/CVS/Entries|cut -d/ -f2,3,5))" = "newfile6.png/1.1/-kb" &&
+ check_entries A "" &&
+ check_entries B "" &&
+ check_entries C "" &&
+ check_entries D "" &&
+ check_entries E "newfile5.txt/1.1/" &&
+ check_entries F "newfile6.png/1.1/-kb" &&
diff E/newfile5.txt ../E/newfile5.txt &&
diff F/newfile6.png ../F/newfile6.png
)'
@@ -154,7 +166,7 @@ test_expect_success \
id=$(git rev-list --max-count=1 HEAD) &&
(cd "$CVSWORK" &&
git-cvsexportcommit -c $id &&
- test "$(echo $(sort "G g/CVS/Entries"|cut -d/ -f2,3,5))" = "with spaces.png/1.1/-kb with spaces.txt/1.1/"
+ check_entries "G g" "with spaces.png/1.1/-kb|with spaces.txt/1.1/"
)'
test_expect_success \
@@ -166,7 +178,7 @@ test_expect_success \
id=$(git rev-list --max-count=1 HEAD) &&
(cd "$CVSWORK" &&
git-cvsexportcommit -c $id
- test "$(echo $(sort "G g/CVS/Entries"|cut -d/ -f2,3,5))" = "with spaces.png/1.2/-kb with spaces.txt/1.2/"
+ check_entries "G g" "with spaces.png/1.2/-kb|with spaces.txt/1.2/"
)'
# Some filesystems mangle pathnames with UTF-8 characters --
@@ -191,7 +203,9 @@ test_expect_success \
id=$(git rev-list --max-count=1 HEAD) &&
(cd "$CVSWORK" &&
git-cvsexportcommit -v -c $id &&
- test "$(echo $(sort Å/goo/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/å/ä/ö/CVS/Entries|cut -d/ -f2,3,5))" = "gårdetsågårdet.png/1.1/-kb gårdetsågårdet.txt/1.1/"
+ check_entries \
+ "Å/goo/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/å/ä/ö" \
+ "gårdetsågårdet.png/1.1/-kb|gårdetsågårdet.txt/1.1/"
)'
fi
--
1.5.3.rc3
^ permalink raw reply related
* Re: [PATCH] Teach git-commit about commit message templates.
From: Steven Grimm @ 2007-07-25 6:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7v3azdh400.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> No, I am way more cunning and lazy than that. I did not have
> hunch about the common case, so I just had you (and anybody else
> who would join the thread) do necessary thinking and guessing
> for me ;-)
>
Ah, good. So it sounds like what I've got is at least an okay first cut
from a functionality point of view. Dscho (or anyone else), any
objections to the code in v2 of my patch? I believe I addressed all the
feedback from v1.
-Steve
^ permalink raw reply
* Re: [PATCH 3/3] Teach "git branch" about --new-workdir
From: Marius Storm-Olsen @ 2007-07-25 6:47 UTC (permalink / raw)
To: Alex Riesen
Cc: Johannes Schindelin, Junio C Hamano, Shawn O. Pearce,
Julian Phillips, git
In-Reply-To: <20070724231529.GA29156@steel.home>
[-- Attachment #1: Type: text/plain, Size: 6757 bytes --]
Alex Riesen said the following on 25.07.2007 01:15:
> Marius Storm-Olsen, Tue, Jul 24, 2007 21:36:06 +0200:
>> IMO Windows user expect files to be DOS style, since all other files
>> are. Yes, most newer tools 'handle' Unix style files, but creating new
>> ones will mostly be DOS style. Some will actually wreak havoc on your
>> files, and start adding DOS line endings in the middle of your Unix line
>> ending file. I've seen it happen. So, dealing with Unix style text files
>> on Windows can be a problem for some people.
>
> I have to stay with Windows, but I'd absolute hate having their stupid
> line-ending by default. As will my project supervisor, and he gets
> changes from something like 300 developers. You will definitely get
> their votes against changing the default
Ok, so maybe not changing the default.
Though it's weird behavior for _most_ Windows developers out there, I
agree that the current Windows Git population would mostly prefer the
Unix line endings. And I can see how someone who's working on Windows
and handling a lot of patches from other developers of multiple OSs
also wanting the non-platform-standard Unix line-endings.
I still would argue that it's not the norm. Currently yes, in the
foreseeable future, I doubt it.
>>> Git is really slowed down tremendously just by the fact that it runs on
>>> Windows. You should not add to that.
>> The auto crlf conversion is not the slow down here, and the time spent
>> there is negligible. I use autocrlf on all my repos on Windows, and
>> don't notice it. Filestat'ing on the other hand.. :-)
>
> Of course you wont notice it: you're already on Windows.
Come on, when did a search and replace in a normal size source file
take any time? It's really not an argument for not doing CRLF
conversion on a platform that creates CRLF files by default!
If you want files to be stored in the repo with Unix line-endings,
which I expect most people would want, to share it with other
non-Windows developers, you _have_ to do it. (No, not the MSys/Cygwin
users)
>>> IMHO in most cases -- even on Windows -- you do not want to set autocrlf
>>> at all. Because you do not need to store the file different from the
>>> version you have in the working tree.
>> Not true. I believe, especially at the moment, most Git users on Windows
>> are mostly developing code in a cross-platform manner, and therefore
>> care about this problem.
>
> Yes. They solve it by working fulltime in \n-lineending. Avoiding that
> stupid Visual Studio and Notepad helps too.
Huh? You just removed more than 3 _million_[1] potential users.. (Some
say 8 million [2]) Is that a good argument? Why should developers on
Windows avoid using Windows tools? Because they're 'idiots'? (ref
further down in your reply)
Anyways, even if a tool on Windows _handles_ LF line-endings perfectly
fine, most of these tools still create CR/LF files when you create a
new text file.
(No, again not the MSys or LF-configured Cygwin vim/emacs/<insert your
favorite unix editor here>. But the native editors which handles both
formats. There's plenty of those too.)
>>> The only situation where I think it makes sense, is when you have both
>>> Windows and Unix developers, _and_ your Windows tools sometimes produce
>>> CR/LF stupidly. But then I'd set it to "input".
>> That's ok _now_, because most of the Git user group is experienced
>> developer that understand the problem. I'm trying to see past that
>> state, and prepare Git for more 'common' usage on Windows. They'd expect
>> text files on Windows to be handled correctly, without any fuzz.
>
> Just make the windows installer to setup templates for CR/LF depending
> on checkbox "[ ] I am Windows idiot, standard issue".
Mmm, ok. If I'm an idiot just for using Windows, I guess the battle is
lost already.
>> No tweaking of config options to make it work on Windows. No problems
>> with sharing repositories with Unix developers. Just work. That's not
>> the current state. But it could be.
>
> It is for me. It will not be that with your suggested default.
Then I wouldn't put you in the normal Windows developer category, but
rather the one which is dependent on MSys or Cygwin, and live in
bash/zsh on Windows. I would argue that most of those 3/8 million VS
users are not in the same category as you.
But sure, I don't mind having to set core.autocrlf=true when I
configure Git, but then I would like that mode to work without the
extra hassle. (Most people don't want to change already incorporated
options, which is fully understandable)
>> Ok, I come from the Perforce world, so here how it works there:
>> 1) Files are stored with Unix line endings in the repository.
>> 2) Conversion is done on Windows (and older Macs) upon checkout, if the
>> file is a text file.
>> 3) It has binary file detection when you add it to the depot, so if you
>> and to add a DOS line ending file to the repo, you have to mark it as a
>> binary file manually
>
> You always setup the lineending conversion in perforce. For each and
> every client. There is no default. I just don't see what to learn from
> them (if there ever was something to learn from).
No you don't. You _can_, but the default when you create a 'client
spec' is the platform specific line endings. Only 'Unix' users working
on Windows really take the trouble of changing the line endings to
they work with their MSys or Cygwin enviroments.
>> ... And Git would probably be adapted on
>> Windows more quickly, which this is all about. :-) IMHO.
>
> It is hardly worth it. Git already has to put up with ugly workarounds
> just because of the stupidities coming from that windows. It has had
> seldom any benefit from supporting this !@#$ing awkward platform.
Well, I guess with this opinion there really no point in me trying to
prove a point. If all Windows users are 'idiots' on a '!@#$ing
awkward' platform, I'm probably just an 'idiot' trying to help out.
I hope it's not the general opinion of the Git team that Windows users
should just bugger off..
Now, personally I don't have a problem with all this line ending
stuff. I work on Windows and Unix on a daily basis, addicted to MSys
and Cygwin for performing my daily tasks, and use tools which handles
LF and CR/LF interchangeably without any problems. So, the current
state of Git works for me. I'm just trying to help figuring out what
we can do to make the tool even more platform agnostic, and work as
expected.
[1] http://msdn.microsoft.com/vsip
[2] http://www.regdeveloper.co.uk/2007/06/09/vs_shell_eclipse/
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* [PATCH] git-p4: Fix p4 user cache population on Windows.
From: Simon Hausmann @ 2007-07-25 7:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
Fall back to USERPROFILE if HOME isn't set.
Signed-off-by: Simon Hausmann <shausman@trolltech.com>
Signed-off-by: Marius Storm-Olsen <marius@trolltech.com>
---
contrib/fast-import/git-p4 | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index e3404ca..1f5a56e 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -901,7 +901,8 @@ class P4Sync(Command):
% (labelDetails["label"], change))
def getUserCacheFilename(self):
- return os.environ["HOME"] + "/.gitp4-usercache.txt"
+ home = os.environ.get("HOME", os.environ.get("USERPROFILE"))
+ return home + "/.gitp4-usercache.txt"
def getUserMapFromPerforceServer(self):
if self.userMapFromPerforceServer:
--
1.5.3.rc0.63.gc956
^ permalink raw reply related
* Re: [PATCH] Add a 1-second sleep to git-cvsexportcommit test
From: Andy Parkins @ 2007-07-25 7:35 UTC (permalink / raw)
To: git
Cc: Linus Torvalds, Robin Rosenberg,
Simon 'corecode' Schubert, Junio C Hamano, Jason Sewall,
raa.lkml
In-Reply-To: <alpine.LFD.0.999.0707241144490.3607@woody.linux-foundation.org>
On Tuesday 2007 July 24, Linus Torvalds wrote:
> So if you sleep for one second, the filesystem times will update by one
> second, but if you try to *synchronize* to exactly one second, it's not at
> all certain that the *filesystem* clock will be synchronized to the same
> second! Time skew is simply a fact of life.
I think it's even worse; if memory serves one of the Windows file systems
(spit) only stores times to a two-second resolution. So half the time,
waiting for one second won't change the time stamp _at all_.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: [PATCH] Teach git-commit about commit message templates.
From: Junio C Hamano @ 2007-07-25 7:39 UTC (permalink / raw)
To: Steven Grimm; +Cc: Johannes Schindelin, git
In-Reply-To: <46A6F0C8.7010204@midwinter.com>
Steven Grimm <koreth@midwinter.com> writes:
> Junio C Hamano wrote:
>> No, I am way more cunning and lazy than that. I did not have
>> hunch about the common case, so I just had you (and anybody else
>> who would join the thread) do necessary thinking and guessing
>> for me ;-)
>>
>
> Ah, good. So it sounds like what I've got is at least an okay first
> cut from a functionality point of view. Dscho (or anyone else), any
> objections to the code in v2 of my patch? I believe I addressed all
> the feedback from v1.
I have already queued it for 1.5.3-rc3. Thanks.
^ permalink raw reply
* Re: [PATCH] Add a 1-second sleep to git-cvsexportcommit test
From: Marius Storm-Olsen @ 2007-07-25 7:43 UTC (permalink / raw)
To: Andy Parkins
Cc: git, Linus Torvalds, Robin Rosenberg,
Simon 'corecode' Schubert, Junio C Hamano, Jason Sewall,
raa.lkml
In-Reply-To: <200707250835.21181.andyparkins@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 922 bytes --]
Andy Parkins said the following on 25.07.2007 09:35:
> On Tuesday 2007 July 24, Linus Torvalds wrote:
>
>> So if you sleep for one second, the filesystem times will update by one
>> second, but if you try to *synchronize* to exactly one second, it's not at
>> all certain that the *filesystem* clock will be synchronized to the same
>> second! Time skew is simply a fact of life.
>
> I think it's even worse; if memory serves one of the Windows file systems
> (spit) only stores times to a two-second resolution. So half the time,
> waiting for one second won't change the time stamp _at all_.
"File time stamps on FAT drives are rounded to the nearest two seconds
(even number) when the file is written to the drive. The file time
stamps on NTFS drives are rounded to the nearest 100 nanoseconds when
the file is written to the drive."
http://support.microsoft.com/kb/127830
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: submodule init problem
From: Sven Verdoolaege @ 2007-07-25 8:15 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin, Lars Hjemli
Cc: git, Ricky Nite, Chris Larson
In-Reply-To: <7vir89fe1l.fsf@assigned-by-dhcp.cox.net>
On Tue, Jul 24, 2007 at 06:49:26PM -0700, Junio C Hamano wrote:
> Ok, this appears it most likely to be related to the fact that
> one is a prefix of the other in problematic case.
Yes, this has been noted before and Chris Larson sent in a patch,
but he didn't follow up on it.
On Fri, Jul 20, 2007 at 07:36:43PM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 20 Jul 2007, Junio C Hamano wrote:
>
> > "Chris Larson" <clarson@kergoth.com> writes:
> >
> > > + name=$(GIT_CONFIG=.gitmodules git config --get-regexp
> > > '^submodule\..*\.path$' "^$path$" |
> > > sed -nre 's/^submodule\.(.+)\.path .+$/\1/p')
>
> I wonder why it is a regular expression to begin with, since we seem to
> prefer shell patterns on paths.
>
> However, _if_ we already go with regexps, why not just put it into the
> "sed" call, which is _already_ there, and leave "git config" alone? IOW
> call
>
> git config --get-regexp '^submodule\..*\.path$' |
> sed -nre 's/^submodule\.(.*$path.*)\.path .+$\1/p'
>
You would be matching the key (the name of the module) rather than
the value (the path of the module) here.
Anyway, I'm not sure why Lars went for the regexp.
I thought he wanted to match the path exactly, which
is why I originally proposed (the more clunky)
On Sat, Jun 02, 2007 at 09:44:10AM +0200, Sven Verdoolaege wrote:
> On Sat, Jun 02, 2007 at 09:13:55AM +0200, Lars Hjemli wrote:
> > But I don't see an easy way to do the mapping from path to url/submodule
> > with:
> >
> > [submodule "xyzzylib"]
> > path=lib
> > url=git://xyzzy/lib-1.2.3
> >
> > Suggestions?
>
> I'm not a shell programmer, but it could look something like this
>
> $ name=$(git config --get-regexp 'submodule\..*\.path' | while read module modulepath; do if test "$modulepath" = "$path"; then echo $module | sed -e 's/^submodule.//' -e 's/.path//'; fi; done)
skimo
^ permalink raw reply
* Re: [PATCH 3/3] Teach "git branch" about --new-workdir
From: Johannes Schindelin @ 2007-07-25 9:39 UTC (permalink / raw)
To: Marius Storm-Olsen
Cc: Alex Riesen, Junio C Hamano, Shawn O. Pearce, Julian Phillips,
git
In-Reply-To: <46A6F21D.2010306@trolltech.com>
Hi,
On Wed, 25 Jul 2007, Marius Storm-Olsen wrote:
> Alex Riesen said the following on 25.07.2007 01:15:
>
> > I have to stay with Windows, but I'd absolute hate having their stupid
> > line-ending by default. As will my project supervisor, and he gets
> > changes from something like 300 developers. You will definitely get
> > their votes against changing the default
>
> Ok, so maybe not changing the default.
> Though it's weird behavior for _most_ Windows developers out there, I agree
> that the current Windows Git population would mostly prefer the Unix line
> endings. And I can see how someone who's working on Windows and handling a lot
> of patches from other developers of multiple OSs also wanting the
> non-platform-standard Unix line-endings.
Even MacOSX saw the light. More and more tools on Windows (not from M$,
mind you, they still want to lock you in, and I am continually amazed at
the _willingness_ to be locked in!) are behaving sane.
> > Marius said:
> >
> > > I believe, especially at the moment, most Git users on Windows are
> > > mostly developing code in a cross-platform manner, and therefore
> > > care about this problem.
> >
> > Yes. They solve it by working fulltime in \n-lineending. Avoiding that
> > stupid Visual Studio and Notepad helps too.
>
> Huh? You just removed more than 3 _million_[1] potential users.. (Some say 8
> million [2]) Is that a good argument? Why should developers on Windows avoid
> using Windows tools? Because they're 'idiots'? (ref further down in your
> reply)
When somebody does not want the same as you, it comes natural to think of
that person as an idiot. That's psychology, not something rational.
However, I think we are talking about an almost non-issue here: those 3-80
million users "just waiting" for Git probably would not touch it without a
complete installer. And that installer could just ask "which line ending
do you want to suffer through today?"
Which brings _me_ back to my pet hate: why on earth is _no_ one of those
30-800 billion Windows users trying to do something about the lack of a
proper native Windows support for Git? The MinGW port contains commits
from these people (skipping everything that is in official git.git):
Johannes Schindelin
Johannes Sixt
Junio C Hamano
Mark Levedahl
Simon 'corecode' Schubert
I know for certain that the first person, and also the third person, are
not exactly Windows users. I guess not even the last two persons are.
Note that more work has been done on git-gui, because those poor Windows
developers are evidently so uncomfortable with the keyboard that a GUI is
needed. AFAIK only Johannes Sixt and Shawn Pearce worked on the
Windows/git-gui interaction (and again, Shawn is not a Windows user).
Han-Wen made an installer, right, but that installer is lacking bash and
perl, and proper testing, because it was just a proof-of-concept.
Han-Wen is no Windows user either. I tried to pick up on that work, but
unfortunately "gub" (the cross compiling framework he used) is so
Pythonesque that I was put off.
So this leaves me with the question: do Windows users really want a proper
native Windows support for Git? If the answer is yes, why don't they _do_
(as in "not talk") something about it?
(Let me take a BIG, BIIIIIG exception here: Johannes Sixt has worked long
and hard and extremely well on this beast. He is certainly the exception
that proves the rule.)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add --show-size to git log to print message size
From: Marco Costalba @ 2007-07-25 9:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Paul Mackerras
In-Reply-To: <7vabtlf7tf.fsf@assigned-by-dhcp.cox.net>
On 7/25/07, Junio C Hamano <gitster@pobox.com> wrote:
> I've been re-reviewing recent patches, and this is one of them.
Thanks for pushing to pu. Please tell me if you want me to send you a
patch to update to what we have discussed, specifically using "length
unknown" and changing the name to --show-lengths.
> However, I am wondering if this is an intended behaviour...
>
> : git.git master; ./git-log --log-size --abbrev-commit --pretty=oneline \
> ko/master..master
> 9d468ac... log size 47
> Add --log-size to git log to print message size
> ca193cf... log size 40
Well, the patch should be used to speedup the parsing by tools because
you can skip big part of the record and jump directly to the beginning
of the next one. So IMHO I don't see a lot of sense in using it
together with --pretty=oneline.
Anyway only default options should be guaranteed to behave correctly
with all the other options. In general, responsibility for what you
see on the screen it's on the tips of user's fingers. IMHO
responsibility of git is of not crashing and do not show incorrect
info, not that the info should be useful.
Paul, I don't know gitk and Tcl to being able to answer myself, but I
would like to know if this new option could be useful also for gitk.
This option, after the first line, gives the size of the following
part of the record. Does this allow you to delay the parsing of the
biggest part of the commit record?
Author name, date, log title, log message could be read only when it's
needed, so that after reading the first couple lines of a commit you
can point directly to the beginning of the next one skipping the rest.
Marco
^ 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