* git-svn.perl (%cmd): Add the command `proplist'. (&cmd_proplist): New. * t/t9101-git-svn-props.sh: Test git svn proplist. Signed-off-by: Benoit Sigoure <tsuna@lrde.epita.fr> --- git-svn.perl | 17 +++++++++++++++++ t/t9101-git-svn-props.sh | 21 +++++++++++++++++++++ 2 files changed, 38 insertions(+), 0 deletions(-) diff --git a/git-svn.perl b/git-svn.perl index e58ff38..466fdd3 100755 --- a/git-svn.perl +++ b/git-svn.perl @@ -132,6 +132,9 @@ my %cmd = ( ...

Hello, this is a fairly simple patch series that adds easy access to SVN properties from within git-svn. The first patch simply factors some code that was used for git-svn show-ignore in order to easily implement git-svn create-ignore (2nd patch). The 3rd and 4th patch implement git-svn propget / proplist to easily access SVN properties. The last patch does some cleanup because I found it more convenient to not have to remember to add a `\n' at the end of each error message. ...

* git-svn.perl (&traverse_ignore): Remove. (&prop_walk): New. (&cmd_show_ignore): Use prop_walk. Signed-off-by: Benoit Sigoure <tsuna@lrde.epita.fr> --- git-svn.perl | 66 ++++++++++++++++++++++++++++++++++++++++----------------- 1 files changed, 46 insertions(+), 20 deletions(-) diff --git a/git-svn.perl b/git-svn.perl index 777e436..abc83ec 100755 --- a/git-svn.perl +++ b/git-svn.perl @@ -488,7 +488,15 @@ sub cmd_show_ignore { my ($url, $rev, $uuid, $gs) = ...

Signed-off-by: Christian Couder <chriscool@tuxfamily.org> --- Documentation/git-rev-list.txt | 16 ++++++++++++++++ 1 files changed, 16 insertions(+), 0 deletions(-) Le lundi 15 octobre 2007, Frank Lichtenheld a écrit : > > --bisect-all is still missing a Documentation/ patch. Thanks for catching that. Here is a patch. diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt index 7cd0e89..f6dd0c4 100644 --- a/Documentation/git-rev-list.txt +++ ...

Here is my pain when using git without partial checkout and submodule improvement. I want to manage src and compiled bin together consistently. And when deploying, I don't need the src directory. My directory structure is like Project Src Bin Following is two schemes I have considered 1. src, bin as two submoudles When changes are made in src, compiled binaries are put in bin directory. So when I commit, I have to commit 3 times and write 3 commit comments separately ...

Hi, Nice! I like it. Ciao, Dscho -

Not just git. This driver has known issues with a number of pieces of software. The company I work with uses Delphi quite a bit and they also have Logitech WebCams for the devs and for some reason this driver makes debugging impossible with Delphi. I have personally experienced this. I have also heard of this Logitech software having problems with other software too. I have not however tracked down exactly WHY this piece of software causes so much grief, only that it ...

It sounds like a good idea to remove all the references to Cogito from the git homepage since it's not longer supported. Changes tested with a local installation of the web server lighttpd Signed-off-by: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> --- index.html | 12 +----------- 1 files changed, 1 insertions(+), 11 deletions(-) diff --git a/index.html b/index.html index 340aee0..41605ed 100644 --- a/index.html +++ b/index.html @@ -94,7 +94,6 @@ Junio C Hamano.</p> --> <br /><a ...

Hi, I have the slight suspicion that we will somehow have problems with /etc/gitconfig, /share/git-gui/ and friends, should we try to use zsh. At least with gitbox, we can hack a "/" translation for scripts. Ciao, Dscho -

All zsh links in [2] are dead. I did try hard to find the legendary zsh for Windows before giving up and porting busybox's ash instead. If -- Duy -

In terms of the MSYS/Cygwin style of fork emulation, large memory allocations shouldn't pose any real problem, but they will be slow as the fork emulation has to manually replicate the state of the parent in the child and this means copying memory extents. (Yes, horribly ugly, no doubt about it, but it allows for porting.) This emulation code is sensitive enough that the Cygwin list has begun to maintain a list of software whose hooks/interference can cause Cygwin apps to fail: ...

I'm not smart enough to know without debugging it. W2K and WXP have different system libraries and somewhat different memory layouts. A bug can get away on one, but not on the other. -

Hi, Ah, thanks for the explanation! (I knew that this thread still had We never had the problem in git itself, since we never used fork() on Windows. The problem lies in our usage of bash and perl. Bash we can fix in the long run (this goes under the keyword "builtinification" on the git list), but I do not see our reliance on Perl going away, not for git {send-email,cvsimport,cvsexportcommit,svn}. These are not too common operations, so common users will be able to do without ...

Hi, No, not yet. The problem is not so much ash, as Nguyen, who said that gitbox is not there yet. Ciao, Dscho -

Hmm... Could the allocation of large contiguous blocks also lock the system hard? For instance, I avoid starting the test suite on my XP workstation at work: it locks up hard every time. W2k works. The system has nothing unusual in it. Well, it has an antivirus program (which hopefully stopped working after a series of crashes, which is just as well), an NVidia card with native driver (which is broken in its own usual ways). Maybe that's enough -

Added a new section beneath "On Automatic following" called "On Backdating Tags". This includes an explanation of when to use this method, a brief explanation of the kind of date that can be used in GIT_AUTHOR_DATE, and an example invocation of git-tag using a custom setting of GIT_AUTHOR_DATE. Signed-off-by: Michael W. Olson <mwolson@gnu.org> --- [Resending, this time without trying to send through Gmane and munge Reply-To.] Documentation/git-tag.txt | 21 +++++++++++++++++++++ 1 ...

Hi, [excluding make-w32 list as per explicit request] No, it is not equivalent. For example, you can still see the file. For example, you cannot reuse the filename for another file. And -- the killer -- you cannot remove the directory which contains the file. But really, we have workarounds in place to make this a non-issue. My bigger concerns are the performance and stability. For example, I had a very annoying problem on one of the machines I am testing msysGit on. The ...

If /bin/sh is /bin/dash, then the script will display an error if $parent_sha1 is undefined. This patch works fixes the issue by quoting both arguments to `test'. Arguments composed solely of variable expansions should always be quoted, unless we know for certain that the contents are defined. Signed-off-by: Michael W. Olson <mwolson@gnu.org> --- Resending, this time directly to the mailing list instead of via Gmane. git-rebase--interactive.sh | 2 +- 1 files changed, 1 ...

Since I consider it unlikely that Jonathan is making your life harder on purpose, it might be somewhat more helpful to offer submission advice: Jonathan, try git rebase -i HEAD~3 or so in order to consolidate the last 3 patches you did. Interactive rebase is one useful manner of munging history until it looks reasonably nice for submission. One major point of git's distributed operation is that one can clean up the development history locally before handing things out. That makes ...

When collaborating with projects managed by some other scm, it often makes sense to have git read that other scm's ignore-files. This patch lets git do just that, if the user only tells it the name of the per-directory ignore file by specifying the newly introduced git config option 'core.ignorefile'. Theoretically, this could cause problems when projects get ported from some other scm to git, but in practice that is a moot point, as such changes are always followed by a flagday ...

Well, then this should be fixed in git general, by sorting the ignores (wildcards in the first place where they can match), and then just moving those patterns that can actually match according to sort order to the list of fnmatch candidates (and moving those files that can't match anymore die to the sort order out again). I don't think that the final "solution" for avoiding a lousy global O(n^2) algorithm is to replace it with lousy local O(n^2) algorithms and just hope for smaller values of ...

From: Johannes Sixt <johannes.sixt@telecom.at> A file copy would be detected only if the original file was modified in the same commit. This implies that there will be a patch listed under the original file name, and we would expect that clicking the original file name in the file list warps the patch window to that file's patch. (If the original file was not modified, the copy would not be detected in the first place, the copied file would be listed as "new file", and this whole matter would ...

From: Jonathan del Strother <jon.delStrother@bestbefore.tv> (Väinö Järvelä supplied this patch a while ago for 1.5.2. It no longer applied cleanly, so I'm reposting it.) MacBook doesn't seem to recognize MouseRelease-4 and -5 events, at all. So i added a support for the MouseWheel event, which i limited to Tcl/tk aqua, as i couldn't test it neither on Linux or Windows. Tcl/tk needs to be updated from the version that is shipped with OS X 10.4 Tiger, for this patch to work. Signed-off-by: ...

Huh? void is a type, not a value. void would insinuate that it was wrong to ask the question, not that its answer could not be Well, I don't. Basically, I would say that this seems to be so much a matter of personal taste that we should at this point of time leave the decision of how to pick this to Junio. Whether this gets resolved by vote or by authority: seems like the fine lines are no longer worth the time invested in discussing them. -- David Kastrup -

git-rebase uses format-patch's --ignore-if-in-upstream option, but we never document the user-visible behavior. The example is placed near the top of the example list rather than at the bottom because it is: a. a simple example b. a reasonably common scenario for many projects (mail some patches which get accepted upstream, then rebase) Signed-off-by: Jeff King <peff@peff.net> --- And whoever said procrastination didn't get things done? Documentation/git-rebase.txt | 25 ...

No it is not. A process will always see the same filesystem object under the same path at the any given time (IOW, you can't have many namespaces active at the same time). -

Well don't do that in your repos (unless need that for something). It is not like someone creates a distribution which does it automagically all the time and you're forced to use that distribution. -

I prefer GCC (the MinGW port), but without the MSYS ports of additional tools. I use the GnuWin32 ports augmented by some of my own (where GnuWin32 ports are buggy or terribly slow). -

Hi, Last time I checked, POSIX was already an abstraction, thankyouverymuch. Anyway, this discussion gets out of hand. The question was: does Git work on Windows natively, and the answer as far as you are concerned is: yes. Ciao, Dscho -

I, for one, appreciate all the hard work invested in that. While we are at that: can you (or someone else) point me to instructions on how to build the MinGW port of GIT? I found a tarball of the MinGW-ported GIT (v1.5.3, I think), but what I don't seem to be able to find is some kind of HOWTO: what tools I need to have installed, how to configure them (if there are any special issues there), what command(s) to type, etc. Is there anything like that out there, or can someone post such ...

Okay, thanks a lot for the info. -

Thanks, I will try. -

OK, enough. I am extremely grateful for the porting and maintenance efforts of the GNU make porting team (since I have no Windows--or Amiga, or OS/2, or OpenVMS--systems to maintain these ports myself) and I'm not going to choose a tool unless it supports their environment and helps them to work more efficiently (or at least no less efficiently). I'm not interested in getting into a pissing match over which operating system is better or worse, and I'm certainly not interested in ...

They should work, too. If a tool is missing, ought to notice it soon enough. These are important to note, though: - The tools must not do their own LF->CRLF conversion when they are used in a pipeline, "just because they know it better". - GNU tar is needed (in the cpio emulator). - ln must be able to create hard links on NTFS or do the equivalent of cp -p - GNU cp -al will be needed and should create hard links on NTFS. (I plan to use it for local clones in place of cpio ...

They aren't. One can mount the same file system several times in different places. In Linux, one can even mount directories and files to several places at once. Most Unices also support some case-insensitive file systems, and readlink does not canonicalize the Not even that. A unique identifier for files would imply that touching the file does not affect, say, the access times of files with other unique identifiers. -- David Kastrup -

Hi, ... yes! There you have it. Absolute filenames, resolved by readlink() are assumed to be the unique (!) identifiers for the contents. _Note:_ absolute paths _without_ readlink() resolving are _still_ unique identifiers; this time for files/symlinks. Things like this utter rubbish that two different file names (which are the keys in the keystore that a filesystem really is) make Windows' filesystem operations so slow. I wonder when Windows heads will realise that this ...

I've been using it recently, I have to say it's pretty impressive - you can use it from cmd.com or from a bash window (courtesy of the msys environment included). The GUIs that ship with git are there (git-gui, gitk). I use gitk extensively, and it works *great*. My work-style is of a shell window for status/diff/commit actions and one or more gitk windows for browsing of proj history. You can use git-gui for a visual status/git/commit workflow, or qgit. qgit is more integrated, and might ...

They tend to be so exactly because they know how pathetic they are. They just want to have something where they don't suck and do everything to find it. And fail. Then they resort to graphics and user-friendly interface. -

Let others do the research for you, hm? http://repo.or.cz/w/git/mingw.git?a=blob;f=compat/mingw.c;h=2554f19765da5709b787e873da... -- Hannes -

Yep. Will do. -

Translation: "I feel that I am superior to other people. This post has no content apart from me shooting my mouth off in an attempt to prove how much cleverer I am than anyone else. However apart from my self-love I have no contribution to make to the discussion." This isn't slashdot. A computer is just a tool, and it's really *you* who are being pathetic, because you confuse a choice of mass-manufactured consumer product with a statement about personal identity. Loyalty to your ...

Hi, I sense a classical Stockholm Syndrome here ;-) Ciao, Dscho -

FWIW, I'm using the MinGW port from cmd.exe, i.e. not from a posix shell, on a *production* repository. gitk and git-gui work. Not all operations that I regularly use are available[*] via the GUIs, like git-rebase or non-fast-forwarding push, so the use of the command line is needed from time to time. Unfortunately, "Fetch" does not yet work[*] from within git-gui, so you have to fall back to git-fetch on the command line. Of course, the Posix toolset, including a shell, must still be ...

That's because you think file names are simple strings and can be compared by simple string comparison. This naìve view is not true even on POSIX systems: "foo/bar" and "/a/b/foo/bar" can be the same file, as well as "/a/b/c/d" and "/x/y/z", given the right symlinks. But for some reason that eludes me, people who are accustomed to POSIX stop right there and in effect say "file names are strings, if we only make them absolute and resolve links". Instead, recognize that file names are not ...

Hi, Ah, that explains it! But do you not need to do "2,bad|2,good|2,dunno" in that case? Or even better: "2,*"? Thanks, Dscho -

That's also why I suggested "skip"; you might not be able to test a particular commit, but you might also not *want* to test a particular commit for some reason. Dave. -

...or we could go all spaghetti western, and call it "ugly". (as in "git-bisect [the <good>, the <bad> and the <ugly>]") Have fun! :) ...Johan -- Johan Herland, <johan@herland.net> www.herland.net -

<personal opinion> Yes, it's funny, but I don't think an SCM interface is a place for jokes or puns. Git already has one big tongue-in-cheek attribute: it's name, so let's leave it at that. </personal opinion> Cheers, Wincent -

But it is an _action_, while "good" and "bad" are properties. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -

I apologize, though I got your first email about Documentation/SubmittingPatches after I had sent in this patch; I had gone rummaging around the homepage for some information, but had found nothing special. I just submitted a patch (properly!) to Petr Baudis Don't worry, I didn't take it personally ;-) Sincerely, Michael Witten -

I have a feeling it was because -u currently just updates modified files in the current directory, while -a updated all modified files. Fortunately, the suggestion above does not break anything. Michael Witten P.S. When is Junio coming back? I know I know... Look through the archives. :-P-

There is no .gitignore, only .git/info/exclude. -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory

How spoiled we are. I just ran cvs status on a checkout of a repo located on a server in the local network. It took 6 seconds to complete :P -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 -

I fail to see how the mechanism work then. You said that I needed to add the .gitignore before adding all the other bummer stuff, fair enough. AFAIK .git/info/exclude doesn't need to be added, it's just there. But you can try to change the test, add the .git/info/exclude *first* and then make a commit and then add all the bummer stuff and then commit, and finally, do a git-status, for me it still takes 9s. -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory

Ouch. That sounds largely unavoidable.. *But*. Maybe we have a bug here. In particular, we generally shouldn't care about the exclude/.gitignore file for ay paths that we know about, which means that during an import, we really shouldn't ever even care about .gitignore, since all the files are files we are expected to know about. So yes, in general, "git status" is going to be slow in a tree that has been built (since things like object files etc will have to be checked against ...

I re-used the test that was posted some time ago: ------------------------------------------------------------------------ --- # # first create a tree of roughly 100k files # mkdir bummer cd bummer for ((i=0;i<100;i++)); do mkdir $i && pushd $i; for ((j=0;j<1000;j++)); do echo "$j" >$j; done; popd; done # # init and add this to git # time git init git config user.email "no@thx" git config user.name "nothx" time git add . time git commit -m 'buurrrrn' -a for ...

Has anyone put any thought into mapping the other direction? i.e. .gitignore -> svn:ignore -chris -

Hi, Sorry for the late reply. I was away from my computer in the weekend. Hi Pierre, I didn't try: http://git.madism.org/?p=git.git;a=commit;h=7406e83342cd445ac38c1753c5fce75377737e2f because the bad commit turns out to be b449f4c according to `git bisect'. Hi Shawn, I include the output of `git count-objects -v' for your information: count: 104 size: 552 in-pack: 10652 packs: 12 prune-packable: 0 garbage: 0 Regards, Kevin Leung -

I don't get the reason for your "because" but so be it. The commit you show is not obviously broken to me, especially not in fast-import.c, so I'll need more input. Could you please run your test in valgrind and report the output please? Or if the data to reproduce the bug are online or shareable, it'd be great to share, so that I can reproduce the issue here. --=20 =C2=B7O=C2=B7 Pierre Habouzit =C2=B7=C2=B7O madcoder@debia= n.org OOO ...

Hi, Almost. It also needs to be updated when switching branches. For every file. Since the commit blamed for the current version could be different for For the $Id$ thing: Documentation/gitattributes.txt. For the $Date$ thing: Documentation/hooks.txt, and Documentation/git-rev-list.txt. You'll need to roll your own thing there, since Git oldtimers feel that what you want to do is the wrong thing (see Randal's comment on generating it as part of the build process). What you ...

OK, second attempt at this. First patch fixes quoting in git rebase. Second patch allows you to run tests from a path with a space in. The third allows you to run tests from a path with an apostrophe in (and is where things start to get a bit ugly, hence the separate patch). -

If we want to support apostrophed paths in tests, I'll flatten 2 & 3 into a single patch. I thought I'd make the apostrophe part optional since there seemed to be some resistance to having to bother about quoting & escaping in tests.. -

From: Jonathan del Strother <jon.delStrother@bestbefore.tv> Double-quoting all paths so the tests can be run from inside a directory named "Joe's git" Signed-off-by: Jonathan del Strother <jon.delStrother@bestbefore.tv> --- t/t9100-git-svn-basic.sh | 54 +++++++++++++++--------------- t/t9101-git-svn-props.sh | 6 ++-- t/t9102-git-svn-deep-rmdir.sh | 6 ++-- t/t9104-git-svn-follow-parent.sh | 50 ++++++++++++++-------------- ...

From: Jonathan del Strother <jon.delStrother@bestbefore.tv> git-rebase used to fail when run from a path with a space in. Signed-off-by: Jonathan del Strother <jon.delStrother@bestbefore.tv> --- git-rebase.sh | 26 +++++++++++++------------- 1 files changed, 13 insertions(+), 13 deletions(-) diff --git a/git-rebase.sh b/git-rebase.sh index 1583402..9995d9d 100755 --- a/git-rebase.sh +++ b/git-rebase.sh @@ -59,7 +59,7 @@ continue_merge () { die "$RESOLVEMSG" fi - cmt=`cat ...

git-gui is scraping the output of the current progress meter using a regex and then building a graphical progress bar from that output. Any change in how git produces the progress bar should still keep it in a form that git-gui can regex match and scrape, preferably without needing to know what version of git it is pulling that output from. For example just teach git-gui to try two different regexps, new format and if that doesn't match then try the old (aka current) format. -- ...

Both. Most of the time, I find the diff output easier to read. Only when a change modifies a whole bunch of lines sprinkled around do I find the side-by-side format easier. Even then, it is only marginal. However, asking for a side-by-side diff viewer is probably the most common request I've gotten from people I work with starting to use git. David -

Ahh, good pointer. I had to google for it to find that it's part of the kdesdk package, which I hadn't installed. But a simple "yum install kdesdk" worked fine. Much better than my stupid script ;) Linus -

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Wondering if adding a file dimension to gitk might help and adding the ability to diff different version of a file git gitk by doing something I just download 'meld', looks interesting, I didn't know about it or 'kompare'. Linking either one into gitk would be a pleasant graphical Hmm, actually I'm only seeing rev topology up to 2.6.13, later version seem to be linear and when I try to use a larger time window something seems to crashing, ...

I can't see how bk's difftool could possibly have any relevance to the "reasonable to stick with CVS" decision, but hey, I'm always surprised by peoples inventiveness in rationalizing their decisions ;) I don't know what difftool does that a simple git diff -U99 | viewdiff - wouldn't do, but in all honesty, I don't think I ever used difftool (I found the other tools in bk much more useful - eg mergetool, renametool) I don't actually know of any sane programs to view unified ...