* Sun 2008-02-03 Dmitry Potapov <dpotapov@gmail.com> Only if you're grown with git. Everywhere else the concept of HEAD or TIP is more natural, thus progression: HEAD, HEAD~1, HEAD~2 Jari -- Welcome to FOSS revolution: we fix and modify until it shines -

What's with the "(No. 1)" here? If you want to add some comment that should *not* be part of commit message, put it in brackets beside PATCH, for example "[PATCH/RFC]", "[PATCH (resend)]", I guess that it is copy'n'paste error, and it should be I would say "[--whitespace=<option>]" or "[--whitespace=<action>]" instead of introducing yet not agreed upon notation (this has the advantage of shortening synopisis, which should be short IMHO). Besides here the mutually exclusive option...

This is meant to be an improvement for [01/11] and I think should be done from the beginning by squashing into it. Haven't looked at the decompression side yet. Help in reviewing this series from others are appreciated. -

Although the original does not bother to, the return value from compress_next() should be checked in later rounds. -

(Cosmetic) Your log message lines are wrapped a bit too short, while some (Naming) This returns Z_OK unconditionally and most callers do not even bother checking the return value. Shouldn't this be of type void? Especially the use of this in if() conditional, after [06/11] Eventually, this should check errors from deflateEnd() and propagate that to the caller. -

A zero commit date could be caused by: * a missing author line * a missing commiter line * a malformed email address in the commiter line * a malformed commit date Simply reporting it as zero commit date is missleading. Additionally, it upgrades the message to an error (instead of an printf). Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at> --- builtin-fsck.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/builtin-fsck.c b/builtin-fsck.c inde...

In the case of an malformed object, the object specific parsing functions would return an error, which is currently ignored. The object can be partial initialized in this case. This patch make parse_object_buffer propagate such errors. Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at> --- object.c | 12 ++++++++---- 1 files changed, 8 insertions(+), 4 deletions(-) diff --git a/object.c b/object.c index 5a5ebe2..4e7f27a 100644 --- a/object.c +++ b/object.c @@ -140,7 +140,8...

This is a good change (but might not make sense without the following ...and this is not; usage string is now too long. Please either use placeholder ([<whitespace>]), or enumerate only short version of commands ([-i] [-v] [-m]) in synopsis, -- Jakub Narebski Poland ShadeHawk on #git -

Git don't attach history to a file, but to a content. Just do a: cp foo bar git add bar git commit -m "copying foo to bar" And it will be done, and when needed, git will be able to know that this was a copy. -- Rémi Vanicat -

You can just put git-cp shell script doing this in PATH (or GIT_EXEC_PATH if they are different) for "git cp" to just work. Or you can write builtin-cp.c, following builtin-mv.c -- Jakub Narebski Poland ShadeHawk on #git -

Hi, It seems that everytime you send a new patch series, it gets longer/more complicated/affects more and more of git. As far as I understood, your problem was _purely_ a submodule issue. I find it utterly unnerving that you keep trying to sneak in _anything_ unrelated to submodules. Such as the origin issue. I am getting pretty angry that you keep trying to complicating things in that area! origin is origin is origin. It is the default remote. It is what you can change to fetch ...

Signed-off-by: Mark Levedahl <mlevedahl@gmail.com> --- git-remote.perl | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/git-remote.perl b/git-remote.perl index d13e4c1..75d2371 100755 --- a/git-remote.perl +++ b/git-remote.perl @@ -328,6 +328,11 @@ sub rm_remote { $git->command('config', '--remove-section', "remote.$name"); + my $defremote = $git->config("core.origin"); + if (defined $defremote && $defremote eq $name) { + $git->...

For submodules defined relative to their parent, it is likely that the parent's defined default remote is correct for the child as well. This allows use of remote names other than "origin", important as managed submodules are typically checked out on a detached head and therefore submodule-update invokes git-fetch using the default remote. Without this change, submodules effectively had to have a default remote of "origin." Signed-off-by: Mark Levedahl <mlevedahl@gmail.com> --- Documentatio...

When working in top-level directory, it is natural to create a new submodule in a subdirectory, then add that submodule to top-level in place. This allows "git submodule add <intended url> subdir" to add the existing subdir to the current project. The presumption is the user will later push / clone the subdir to the <intended url> so that future submodule init / updates will work. Absent this patch, "git submodule add" insists upon cloning the subdir from the remote, which is fine for a...

This patch series was inspired by several issues dealing with multiple remotes and submodules. The tests added as the last patch demonstrate the specific use pattern to be supported, and that does not work currently. 1 - user A creates a project on server "frotz" with a submodule. 2 - user B clones the project, forks it, adds a submodule, and publishes the fork on server "fork" user A adds the fork to his working tree, via git remote add + git fetch. The desire is that: 1 - git submodule init +...

Signed-off-by: Mark Levedahl <mlevedahl@gmail.com> --- git-remote.perl | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/git-remote.perl b/git-remote.perl index d13e4c1..75d2371 100755 --- a/git-remote.perl +++ b/git-remote.perl @@ -328,6 +328,11 @@ sub rm_remote { $git->command('config', '--remove-section', "remote.$name"); + my $defremote = $git->config("core.origin"); + if (defined $defremote && $defremote eq $name) { + $git->...

For submodules defined relative to their parent, it is likely that the parent's defined default remote is correct for the child as well. This allows use of remote names other than "origin", important as managed submodules are typically checked out on a detached head and therefore submodule-update invokes git-fetch using the default remote. Without this change, submodules effectively had to have a default remote of "origin." Signed-off-by: Mark Levedahl <mlevedahl@gmail.com> --- Documentatio...

When working in top-level directory, it is natural to create a new submodule in a subdirectory, then add that submodule to top-level in place. This allows "git submodule add <intended url> subdir" to add the existing subdir to the current project. The presumption is the user will later push / clone the subdir to the <intended url> so that future submodule init / updates will work. Absent this patch, "git submodule add" insists upon cloning the subdir from the remote, which is fine for a...

And Ohloh stack count gives yet another idea. Both Debian popularity counter and number of Ohloh stacks are mentioned in GitSurvey2007[*1*], around question about used SCMs. Google Trends above not yet, and perhaps will not because it is even more skewed than mentioned results, perhaps even more than result of Git _User's_ Survey 2007. [*1*] http://git.or.cz/gitwiki/GitSurvey2007#head-4ed59e7615e2dc4f4baa8fa0beccde52c93789f8 -- Jakub Narebski Warsaw, Poland ShadeHawk on #git -

I'm guessing now, but try -Z '--cvs-direct'. -- robin -

If both computers are always online and you can connect at will then "pull" is the simplest solution. The problem with "push" is that pushing to the local branch of another that has the working directory attached to it will give you not exactly what you want. The default refspec for "push" is only suitable for pushing into a "bare" repository from where anyone can pull. However, if you do not want to have a separate bare repository for synchronization, you can avoid by providing suitable refspec fo...

Do you have access to the apache error_log ? Mike -

For whatever error message shows up at the time corresponding to when the MKCOL request was done. You can grep MKCOL in the access_log to find out. That might help you understand why the MKCOL fails. Mike -

Here are the topics that have been kept out of 'master'. Commits prefixed with '-' are only in 'pu' while commits prefixed with '+' are in 'next'. The topics list the commits in reverse chronological order. I'd like to get post-release fixes to 'maint' first, tag 1.5.4.1 and merge that to 'master', and then start merging things from 'next' to 'master'. My wish is to have small but short release cycle for 1.5.5 and leave bigger ones cooking for 1.6.0. ----------------------------------------...

Err... that is incorrect without further surgery. <refspec> is either <ref>:<ref>, <ref> or some other exotic case; in the form <ref>:<ref> it can include globbing. The fragment above talks about situation where <refspec> is <ref>, and does not contain colon. -- Jakub Narebski Poland ShadeHawk on #git -