If I create an alias with `git config alias.foo '!pwd'` and then run it from a subdirectory of my repo, it prints out the root of my repo. This prevents the ability to create aliases that take filenames, as they simply won't work if you try and reference a file from a subdirectory. -- Kevin Ballard http://kevin.sb.org kevin@sb.org http://www.tildesoft.com --

Hello All, Today I got another user complaining that git rebase interactive sometimes squashing changes without being told to do that. Studying the reflog revealed what I expected to see: the user started the process of editing of chain of patches started by "git rebase -i", and then used "git commit --amend" to correct some of them, but at some point the process of rebasing was stopped due to a conflict caused by some previous changes. The user after resolving this conflict run "git commit ...

Odds are it is in her HEAD reflog. You can look for it with `git log -g`. If you know some part of the commit message you may be able to filter it down with `git log -g --grep=X` or part of the change with `git log -g -SX`. A coworker just did something like that today and lost his change; looking in the HEAD reflog and cherry-picking the commit recovered it quite easily. -- Shawn. --

This will allow server side programs such as upload-pack to be installed outside $PATH. Connections to git-daemon still ask for "git-program" to retain backward compatibility for daemons before 1.5.6.1 and 1.6.0. Signed-off-by: Junio C Hamano <gitster@pobox.com> --- * This is essentially your patch. This can be in 1.6.0 clients and it should also be in 1.5.6.1 as people might keep ancient clients to talk to new servers that won't have anything but "git" on $PATH. builtin-clone.c ...

Agreed about holding back. But I wonder if this patch is even worth it at some later point in time. Are we also going to change git-daemon to stop accepting "git-" form? Is it a worthwhile change? -- Shawn. --

Sorry I wasn't clear. I was talking about the SSH transport only. For git:// we could just always send git-upload-pack, like your transitional patch does. Then we stay compatible with even very old git:// servers. -- Shawn. --

Ack. Thanks for cleaning up the code in connect.c to not segfault or send garbage. I think you want to squash this in as well: diff --git a/builtin-send-pack.c b/builtin-send-pack.c index d76260c..f693a6d 100644 --- a/builtin-send-pack.c +++ b/builtin-send-pack.c @@ -12,7 +12,7 @@ static const char send_pack_usage[] = " --all and explicit <ref> specification are mutually exclusive."; static struct send_pack_args args = { - /* .receivepack = */ "git-receive-pack", + /* ...

By the way I looked at gitosis (Tommi CC'ed). http://repo.or.cz/w/gitosis.git?a=blob;f=gitosis/serve.py;h=c0b7135bf45305ee1079b0dcab... In gitosis/serve.py, there are COMMANDS_READONLY and COMMANDS_WRITE array that holds 'git-upload-pack' and 'git-receive-pack' commands, and they are compared with user commands after doing: verb, args = command.split(None, 1) (and "verb" is looked up in the set of valid commands). It should not ...

First of all, if you are in CVS mindset, you may not want to necessarily do "git pull", but "git fetch" followed by "git rebase". I suspect the last one in the above sequence of yours is "git stash pop". "git diff [--options] origin..." (three-dots) is often used. This is a shorthand for: git diff [--options] $(git merge-base origin HEAD) HEAD This would be useful if you are using "fetch + rebase", but in any case git log --graph --pretty=oneline origin.. may be prettier these ...

Push into it. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git --

<opublikowany i wysłany> git-merge-base -- Jakub Narebski Warsaw, Poland ShadeHawk on #git --

Why? Let's suppose you work with CVS and you started to edit some file and then realize than the change that you make is stupid, would not you want just to discard these change without committing them to CVS? Perhaps, you are confused by thinking that git commit and cvs commit are conceptually same commands. IMHO, far better to analogue to cvs commit would be git push to a repository with denyNonFastForwards policy. Git commit allows you to save your changes locally as series of patches, but ...

Which git version do you use? Does it have the following configuration variable (also available as command option): status.showUntrackedFiles:: By default, linkgit:git-status[1] and linkgit:git-commit[1] show files which are not currently tracked by Git. Directories which contain only untracked files, are shown with the directory name only. Showing untracked files means that Git needs to lstat() all all the files in the whole repository, which might ...

Hmm, can you do dnotify over NFS? I'd like to know how hg goes any faster. As far as I can see, git is going as fast as can be without some kind of daemon or other magic. (Except for my point #3, which seems relatively minor.) Thanks, Avery --

You can try to take a look at how (third-party and Linux only) inotify extension for Mercurial works. AFAIK IIRC it uses some kind of daemon which watches for inotify notices and updates Mercorial's equivalent of index. -- Jakub Narebski Poland --

That's on 'master' progressing forward to eventually become 1.6.0. --

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi list, I felt quite helpless when trying to get egit running as neither http://git.or.cz/gitwiki/EclipsePlugin nor the README/INSTALL aren't overly verbose. I put the idiot-proof recipe on http://wiki.jcurl.org/index.php5?title=GitSvn#Eclipse_Plugin - maybe you can weave it into either wiki or INSTALL? Greetings, M -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - ...

I don't think git ls-files does that, but git diff --cached --name-only will. Cheers, Michael --

I wasn't able to make "git ls-files" do what you want. However, "git diff --name-only --cached" did. It's still porcelain, but it does what you want :) -- Ian Hilt Ian.Hilt (at) gmx.com GnuPG key: 0x4AFC1EE3 --

`git status` will do this, unless you need to do additional processing on the results. HTH, - Reece --

Perfect, exactly what I wanted. Thanks. -Kate --

Hmm. Actually, there is a test in t6300 that runs with each atom name. Unfortunately, it doesn't bother actually checking the output for sanity, so the fact that these atoms returned the empty string was missed. -Peff --

Try the following on a repository with tag objects in it: git for-each-ref --format='%(object)' git for-each-ref --format='%(type)' Each command prints only newlines. The %(type) and %(object) options are not rejected with an error message (like "%(doesnotexist)"), but they don't seem to be implemented. "%(tag)" works though. Anyone care to implement the missing options? Or should they rather be removed from the documentation? -- Lea --

Ah, sorry, I read this paragraph: In addition to the above, for commit and tag objects, the header field names (tree, parent, object, type, and tag) can be used to specify the value in the header field. But not this one (which perhaps should be right after the above instead of 3 paragraphs down): In any case, a field name that refers to a field inapplicable to the object referred by the ref does not ...

Sources considered by gitweb are: 1. projectlist file 2. owner key in .git/config ("gitweb.owner") 3. file owner of the git dir It's funny this results in an empty owner in your case: What does "finger erez.silber" say? Michael Use the source, Luke ;) sub git_get_project_owner { my $project = shift; my $owner; return undef unless $project; $git_dir = "$projectroot/$project"; if (!defined $gitweb_project_owner) { ...

Hi, Please note that we support pushing using the HTTP DAV extensions. It seems to be only rarely used in practice though, since developers seem to either work at sane companies, are tunneling through the firewalls or the firewalls are adjusted if this is required for development of their day-job applications. There are some cases where this is useful, but I don't tihnk they are very numerous (in practicular, I've had more requests (about three?) for git-cvsserver than for HTTP DAV ...

Well, if you do not trust them, just set receive.denynonfastforwards and they won't be able to. --

Thanks for the info about shared object storage for shared repositories. That's great, and looks like a good implementation method. Previously I was thinking in terms of making a different server to change behavior. However, I think the comments I've read are shifting my mindset towards making a client-wrapper. I want to provide a system [wrapper] without the user-burden of thinking about three repositories (local, my-public, shared-public). Doing this as a wrapper has other benefits, like the ...

If you don't mind helping the investigation a bit, could you please go into the t/ directory and run bash -x t2004-checkout-cache-temp.sh -d -v -i and post the output here? This diagnostics are much more useful (well, essential, in this case). Are running the tests on HFS+, BTW? --

repo.or.cz has support for forks, i.e. sharing object database (for old objects) via alternates, although it is not "common object database" (as in, for example, $GIT_DIR/objects symlinked to single common parent repository) GitHub has also some support for "forks", but as it is closed source I don't think anybody knows how it is done. -- Jakub Narebski Poland ShadeHawk on #git --

Sometimes it is desirable to have non-fast-forward branches in a shared repository. A typical example of that is the 'pu' branch. This patch extends the format of allowed-users and allow-groups files by using the '+' sign at the beginning as the mark that non-fast-forward pushes are permitted to the branch. Signed-off-by: Dmitry Potapov <dpotapov@gmail.com> --- <snip> Thank you for advice. I have corrected the patch. Documentation/howto/update-hook-example.txt | 75 ...

Thanks. 1/2 queued for 'maint' (as it was an obvious fix) to be included in 1.5.6.1, but not this one that is a feature enhancement even though it "expr substr"? Please don't. cf. http://www.opengroup.org/onlinepubs/000095399/utilities/expr.html I'd probably write this part like so: ... pipe ... | while read heads users do # does this rule apply to us? head_pattern=${heads#+} matchlen=$(expr "$1" : "$head_pattern") ...

Test stg refresh more extensively -- including some things it only recently learned to do. Signed-off-by: Karl Hasselström <kha@treskal.com> --- t/t2300-refresh-subdir.sh | 29 ++++++++++++++++++++++++++++- 1 files changed, 28 insertions(+), 1 deletions(-) diff --git a/t/t2300-refresh-subdir.sh b/t/t2300-refresh-subdir.sh index 92c1cc8..d731a11 100755 --- a/t/t2300-refresh-subdir.sh +++ b/t/t2300-refresh-subdir.sh @@ -4,7 +4,7 @@ test_description='Test the refresh command from a ...

(...) Wouldn't it be a good idea to add a warning in git update-server-info when it detects pack.indexVersion is not 1, too ? Mike --

As announced for 1.6.0. Git older than version 1.5.2 (or any other git version with this option set to 1) may revert to version 1 of the pack index by manually deleting all .idx files and recreating them using 'git index-pack'. Communication over the git native protocol is unaffected since the pack index is never transferred. Signed-off-by: Nicolas Pitre <nico@cam.org> --- Documentation/config.txt | 6 +++--- pack-write.c | 2 +- 2 files changed, 4 insertions(+), 4 ...

Rather than talk about when it does _not_ matter, wouldn't it be better to talk about when it _can_ matter? Namely when using dumb protocols, either http or rsync, with the other end being some ancient git thing (and it is worth mentioning version of what counts as 'ancient' too, I can't remember, probably means that pretty much nobody else can either). Linus --

That would give the idea that index v2 is not good, while what we want is to encourage everyone to move to index v2 ASAP. Nicolas --

$ git describe --contains b6945f5 Looks fine to me. Will you amend the patches or do you want me to repost them? Nicolas --

As announced for 1.6.0. Access over the native protocol by old git versions is unaffected as this capability is negociated by the protocol. Otherwise setting this config option to "false" and doing a 'git repack -a -d' is enough to remain compatible with ancient git versions (older than 1.4.4). Signed-off-by: Nicolas Pitre <nico@cam.org> --- Documentation/config.txt | 10 +++++++--- git-repack.sh | 6 +----- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git ...

Thanks. This is a much better equivalent to the "probably fixed with this" patch you sent earlier ;-) --

Yeah, I missed the patch to connect.c that was buried among other changes. Sorry. --

Of course. I am assuming that he runs git-shell for user account, and that's what the change in 'next' is about. --

<< a patch to conditionally change "git-program" default to "git program" snipped >> How would that help client that talk with git-daemon, unlike what I sent earlier? --

Otherwise remote executions directly over ssh won't find them as they used to. --upload-pack and --receive-pack options _could_ be used on the client side, but things should keep working out-of-box for older clients. Later versions of clients (fetch-pack and send-pack) probably could start asking for these programs with dashless form, but that is a different topic. Signed-off-by: Junio C Hamano <gitster@pobox.com> --- * しらいしななこ <nanako3@lavabit.com> writes: > Doesn't "git archive ...

Actually I'd go the other direction. Allow the higher up level to supply "git upload-pack" and convert it to git- for the git:// Pasky also has to update: $ git ls-remote --upload-pack='git upload-pack' repo.or.cz:/srv/git/egit.git fatal: unrecognized command 'git upload-pack '/srv/git/egit.git'' fatal: The remote end hung up unexpectedly diff --git a/builtin-clone.c b/builtin-clone.c index 5c5acb4..98d0f0f 100644 --- a/builtin-clone.c +++ b/builtin-clone.c @@ -37,7 +37,7 @@ static ...

Well, the thing is, "higher up" would not have enough clue to see if it needs to give dashed form (for git-daemon) or space form (for ssh), so that suggestion won't help much. I do not care too much about closed source service, but gitosis should be able to update the pattern to allow "git[ -]upload-pack" reasonably easily. Any other suggestions that is workable? --

Is that really 6 and 12 months, or "6/12 months or at the next major release boundary, whichever is later". i.e., would make some of these changes as part of a minor dot release, such as having the client side change what it starts asking for in 1.6.3 or some such? Presumably the earliest that change would happen is 1.7, and the earliest to make the server side installation changes is 1.8, right? Or did you really mean a hard 6/12 months, regardless of release cycle issues? ...

Shouldn't "git upload-pack" work on the server side as far back as 0.99.9k? That's back really old. And my patch fixed "git " to be "git-" when talking to git-daemon, thus keeping clients compatible with all current git:// servers. For SSH servers that can't handle "git upload-pack" the user can change it to --upload-pack=git-upload-pack and get back to the old behavior, until the server operator can upgrade. Check my change in git_connect again: diff --git a/connect.c ...

To do so, check_pack_crc() moved from builtin-pack-objects.c to pack-check.c where it is more logical to share. Signed-off-by: Nicolas Pitre <nico@cam.org> --- builtin-pack-objects.c | 22 ---------------------- pack-check.c | 39 +++++++++++++++++++++++++++++++++++++-- pack.h | 2 +- 3 files changed, 38 insertions(+), 25 deletions(-) diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c index 827673c..28207d9 100644 --- ...

Using find_pack_entry_one() to get object offsets is rather suboptimal when nth_packed_object_offset() can be used directly. Signed-off-by: Nicolas Pitre <nico@cam.org> --- cache.h | 1 + pack-check.c | 4 +--- sha1_file.c | 2 +- 3 files changed, 3 insertions(+), 4 deletions(-) diff --git a/cache.h b/cache.h index a68866c..16222a3 100644 --- a/cache.h +++ b/cache.h @@ -711,6 +711,7 @@ extern void close_pack_windows(struct packed_git *); extern void unuse_pack(struct ...

Yup. That's one of the reasons git is so attractive. There is some good stuff ...most notably, all their DAGs in a single repository to save space is important. Thousands of copies of thousands of repositories adds up. Especially when most of the users who want to commit something probably commit <1-10k of unique stuff. Seems pretty easy to change though. git.or.cz and github will both be wanting this eventually. The other big one is ACLs in 'well named' repositories, so multiple people ...

But a branch in repository also has a local history. The ref-log. And git could use that to produce a distributed branch-history. <wishful thinking> A developer prepares a series of commits in a local branch to push to the server. On the server the ref-log of a branch gets updated with a new entry for each push, and other developers pulling from the server get the servers ref-log as ref-log of their remote tracking branch and can see the push-points there. Those push-points seem to be ...

Yes. I figure that patching to make --not --stdin work how I'd like would break something else, and implementing --not-stdin seems hackish. Adam Brewster --

Because of time zone issues I didn't get a chance to check this until now. This fixes the segfault issue for me. Thanks! --

We might be able to get by with them, but submodules appear to be significantly more complex than symlinks, and we sometimes symlink just a file or two if that's all we need. Splitting up submodules to that level of granularity would be hard to manage. My understanding of the submodule workflow is: Projects A, B, and C (we actually have about 17 of these) all share common code in project Common. Then, each of A, B, and C adds Common as a submodule. While working on project A, the need arises to ...

I am very confident in the series as far as using it on Windows is concerned. But I must admit that I have started to use it on Linux only recently. Therefore, cooking it in 'next' for a few days is probably not a mistake. -- Hannes --

definitely; that sounds like an obvious thing for "diff --check". Ciao! --

We used to mark hooks we ship as samples by making them unexecutable, but some filesystems cannot tell what is executable and what is not. This makes it much more explicit. The hooks are suffixed with .sample (but now are made executable), so enabling it is still one step operation (instead of "chmod +x $hook", you would do "mv $hook.sample $hook") but now they won't get accidentally enabled on systems without executable bit. Signed-off-by: Junio C Hamano <gitster@pobox.com> --- * This ...

Well, I think you really want this to handle filenames with spaces: for i in $* do git checkout HEAD -- "$i" done I still think it would be nice this as a built-in for "git revert-file" since this is much easier to type than "git checkout HEAD -- " (all those characters and capital letters). But if it ends up being a private shell script for people who do this a lot, that's also fine. I will say that it was not at all obvious that "git checkout" can also be used to revert files, ...

Hi, Nice. And now my friend says "why does this braindamaged Git not have that command by _default_? Hmm? It is _just as braindamaged_ as CVS!" And I would not have anything reasonable for my defense. Because Git _should_ have an intuitive command to switch branches by default. "git checkout" just does not fly, especially given that it can be used to revert single files (which "git revert" should know how to, but does not, see ...

But why? I don't want to 'branch', I want to 'checkout' another branch, which incidentally matches the git command I need to use to achieve that. Matthias --

Isn't that this? #!/bin/sh exec git checkout HEAD -- "$@" --

Hi, just to add to Junio's comments: But "reset" _means_ to discard something. Frankly, we could introduce "git reset --hard --force --really --really-i-mean-it --do-reset-the-fscking-working-directory-NOW", but I do not think that it makes sense. If you want to reset the working directory, you want to reset the working directory. If you wanted to save the changes somewhere, you should have Apparently not. So again, "reset --hard" means to reset HEAD, index and working ...

Craig, I'm not trying to say that git incorrectly uses 'checkout' word :) -- Best regards, Anton mailto:agladkov@parallels.com --

$ git config alias.switch checkout $ git switch topic Hm? Notice that the command even reports back: Switched to branch "topic" ^^^^^^^^ -- Hannes --

Won't fly. 'git checkout -- "$@"' is to revert to the last staged version. * You say "git checkout branch" when you want to "check out that branch"; * You say "git checkout -- file" when you want to "check out the file from the index"; * You say "git checkout v1.5 -- file" when you want to "check out the file out of that revision". It's not that hard. --

No, it's not "that hard." But are you really claiming that it's beyond improvement? -- -Steven Walter <stevenrwalter@gmail.com> --

Then you should revise your impression, as it is simply *WRONG*. When I say something about history of git, I know what I am talking about ;-) Reset has been about nuking local changes from the very beginning. That is why it removes MERGE_HEAD, rr-cache/MERGE_RR as well as removing conflicted stages in the index and reverts local changes from the worktree. It is "my worktree state is a mess, and I cannot even describe nor care which paths are dirty --- just get rid of the local changes so ...

Ah, interesting. It appears that the current "reset in C" inherited that bug from the scripted version. It works most of the time without -- except for one place. # prove that the work tree is clean... $ git reset --hard HEAD is now at 7b7f39e Fix use after free() in builtin-fetch $ git diff $ git diff --cached # what's different since HEAD^? $ git diff --name-only HEAD^ builtin-fetch.c # reset the path $ git reset HEAD^ ...

I agree that "git switch" would be a great alias to have for "git checkout". It is much more intuitive; traditionally, the issue has always been that it's not so intuitive for existing git users, who have gotten used to the existing quirks, and it people won't want to break things for the existing users. (There are analogues to this is the English language --- why is it that "though", "through", "plough", "cough", "hough", or "tough" don't rhyme[1]?) Neither does the English language; but ...

Just to chime in, this reminds me of Cogito - it had cg-switch for switching branches (like git checkout) and cg-restore for restoring files in working copy (like git checkout, too; but you would pass -f if you wanted to overwrite existing copy). (Though, Cogito didn't quite get it right either since it tried to overload cg-switch with the git branch functionality of creating new branches. I still didn't quite come in terms with any UI model of the branches I know about.) -- Petr ...

Oops, I got mixed up. Only git-reset requires the --. Would it make sense to bring git-reset into line with everything else, then? Thanks, Avery --

That seems to be the first piece of information you're giving regarding your environment and setup. Giving more may result in getting more answers. (I grepped for 141 in the source after your first posting) Maybe you can cut'n'paste the actual output of git svn fetch? What's the command line you're using, where's the svn repo? Michael --

That's a good idea! However, this patch is not going anyplace, I think. Junio submitted a different patch to disable the pre-commit example. Junio, do you want me to make this change anyway? It does make sense. The unittests for the pre-commit hook may or may not still be useful. Ciao! --

All of those module?/{tags,branches} are empty, right? I assume branches So you want one git repo, reflecting the modules simply by different subdirs? I'm afraid that raises similar problems like those I asked about in my (yet unanswered) post This should give you all "modules" (as subsdirs) for all branches and tags already. svn branch "branchname" becomes git remote branch "branchname", svn tag "tagname" becomes git remote branch "tags/tagname". Note that your new git branch trunk ...

Thanks, Weird. It looks like a stupid bug on my part. I'm surprised --

In [foo "bar"] baz = value foo and baz must be config.c::iskeychar() (and baz must be isalpha()), but "bar" can be almost anything. Isn't "not underscore" coming from DNS hostname part restriction? --

Ha. It would not be hard to make it accept any two tags the user happens to use. fast/slow, works/broken, fina-fisken/totalkvaddad, ... it even comes with built-in internationalization! /me ducks. -- Karl Hasselström, kha@treskal.com www.treskal.com/kalle --

One tree tracks a configuration file that just contains specs for other trees. The idea is something like this: Given a refspec on the configuration tree, git-view the configuration file and use the contained refspecs to clone/pull/fetch/reset/whatever a bunch of other trees. Note that I'm not trying to solve the problem addressed by the Well yes, but that is only half of it. One of the scenarios I'm pondering is this: A user wants to take an old configuration based on tags and try some ...

Depending on the definition of "potentially destructive", most commands are "potentially destructive". git pull loses the point where the branch used to point when the reflog expires. git add loses the old content of the index. ... And adding too many --force options removes its real value. Many people type "rm -fr" any time they just want "rm", just because they were annoyed by the multiple interactive confirmations of plain "rm" (if aliased to "rm -i"). Asking people to type --force ...

The git_dir variable is always set from the directory provided on the command line. However, the work_tree can be overridden by the environment. For some reason I missed the giant 'work_tree = getenv("GIT_WORK_TREE")' when I looked before. But that means that they are not necessarily related. So my original patch was too clever. Here is the less clever patch, with an extra test that would break with the clever version. -- >8 -- clone: create intermediate directories of destination ...

Yea, OK, I know what that is. I busted PackIndex.isTOC. I asked it to compare a 4 byte array (TOC only) to an 8 byte array (TOC + version) and of course 4 != 8 so it fails. Thus all V2 index files look like V1 files. Only they aren't; and then all hell breaks loose when we start treating parts of the V2 index as different sections of the V1 index. That's because Marek's branch includes additional tests for features he added to PackIndexV2. But all PackIndexV2 reading is ...

Does not work. only --hard will do the job. The working directory is not touched and if you'll do a git-diff you'll see the diff between old-head the closest to git reset --hard that I can think of is: Lets say I have $ git-branch -a * mybranch remote/master I can $ git reset --hard remote/master Or I can $ git-checkout -b temp_mybranch remote/master $ git-branch -M temp_mybranch mybranch The second will complain if I have local changes. I have just written 2 scripts. One ...

Hmmmm.... Wouldn't it be easier on fingers to use git reset --soft integration -- Jakub Narebski Poland --

Oh no. I can only agree and repeat myself, as I think this is nonsense. git is a tool, and like every tool you can hurt yourself with it if you don't read the manual and follow really simple guidelines. I used git reset --hard on a test-repo before using it on my real code, and it has never bit me since. Why do we have --hard then? It would be "An option which does nothing unless you also specify -f on the command-line". Just my opinion, but I think quite a few people feel the ...

The perldiag(1) has following to say about this: "Can't do inplace edit without backup" (F) You're on a system such as MS-DOS that gets confused if you try reading from a deleted (but still opened) file. You have to say -i.bak, or some such. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> --- t/t5303-pack-corruption-resilience.sh | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/t/t5303-pack-corruption-resilience.sh ...

Try looking at git log --follow <name> --

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' while commits prefixed with '+' are in 'next'. The topics list the commits in reverse chronological order. It already is beginning to become clear what 1.6.0 will look like. What's already in 'next' all are well intentioned (I do not guarantee they are already bug-free --- that is what cooking them in 'next' is for) and are good set of feature enhancements. But bigger changes will be: * MinGW will be ...

Why not just provide some api-functions to return a strbuf of the short and long options each? parse_opt_short_help(strbuf *sb, options...); parse_opt_long_help(strbuf *sb_long, options...); That way multi-parseopt programs can get their help-texts done right with very little extra work. -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 --

FYI, it actually runs git-upload-pack, gets the list of advertised refs, then closes the connection immediately. The other side sees the client hang up and just terminates silently, since the client didn't "want" anything packed and sent. -- Shawn. --

On Tue, Jun 24, 2008 at 05:11:44PM -0700, Jakub Narebski <jnareb@gmail.com>= =20 $ git ls-remote server:/home/vmiklos/git/test bash: git-upload-pack: command not found fatal: The remote end hung up unexpectedly

What does "git ls-remote server:/home/vmiklos/git/test" invoke on server? -- Jakub Narebski Poland ShadeHawk on #git --

We'd need a maint release soon to push out the mkstemp() breakage but not tonight. There are a handful changes that are in 'master' and 'next' that need backport/backmerge before 1.5.6.1 happens. * The 'maint' branch has these fixes since the last announcement. Jan Krüger (1): git-svn: make rebuild respect rewriteRoot option Patrick Higgins (1): Workaround for AIX mkstemp() * The 'master' branch has these since the last announcement in addition to the above. Jeff King (1): ...

Thanks, both. Its in my tree. -- Shawn. --

Sorry, this is my fault. I hadn't looked at the recount patches closely, but I had thought they were submit-worthy, so I encouraged Thomas to include them in his series (since his patch depends on them). I'll try to look them over more closely in the next day or two. -Peff --