There is the git user's manual: http://www.kernel.org/pub/software/scm/git/docs/user-manual.html http://git.or.cz/gitwiki/GitDocumentation contains links to more -- --

For that particular use case, I'd suggest --first-parent. It is not just about filtering the output but more importantly also affects the way the traversal is done (it does not descend into side branches). It simply is more suited for the job you described. At this point, I have a mild aversion to a random addition to rev-list that does not have to affect how the traversal works but only filters the output, and more importantly does only a single purpose filtering. It is very much unclear if ...

The attached patch adds a new permission mode for core.sharedRepository. -- Heikki Orsila heikki.orsila@iki.fi http://www.iki.fi/shd

I have tried to fix this, but I don't know the code. The previous logic was obviously (?) broken, as it had this (paraphrased): if (remove_directories || matches) remove_dir_recursively(...); which should have been &&. But with only this change, top-level directories were not removed even if "-d" was given. Looking at the (!ISDIR) branch, I guessed that it should instead trigger if pathspec is NULL; i.e, generally treat (!pathspec) as a match. It looks like the behaviour is correct now...

Git is missing the fact that, while refs/remotes/x86/latest doesn't exist, there is a fetch rule that would create it. It should suggest "git fetch x86" or "git fetch x86 latest". This is a bit tricky, because you've used a shorthand for something that doesn't exist, so there isn't a unique answer for which full name you're looking for, but there is a unique solution (in this case) for which one could be created by a pattern you The right error message here would probably be: /home/ming...

Thanks. It is always enlightening to see this kind of walkthru session to learn where the UI warts are. The ones with concrete suggestions for You told git that "I'll interact with this other repository from now on, so please help me with some extra settings to do so. Namely I do not want to keep typing it in full URL all the time so I want an abbreviated way to tell you I am talking about this remote repository, and also I want to have set of remote tracking branches for this one". Maybe "r...

Hey Junio, I'm hearing you here! :-) I think a furtherance of this notion is to teach "git fetch ; git merge" before "git pull". Thanks, jdl --

For me personally, I think this bottom-up approach makes the most sense to learning (this may look familiar from the commit message to a patch I sent earlier): 1. here is what "git pull $repo $branch" means 2. here is a way to shorten it to "git pull $repo" (set up remote $repo) 3. here is a way to shorten it to "git pull" (default to origin) But I think there are people who will get to the list and say "why didn't you just tell me 'git pull' in the first place?" That is, the compl...

My co-workers frequently get confused by this too. The problem is that "x86/latest" is a locally existing remote branch ref, while "x86 latest" is supposed to be a branch ref on a remote system. I think the real problem here is that you can't refer to a remote+branch as a single "word". If you could, then people could just learn to use that everywhere and never get confused. For example, in svn you can talk about svn+ssh://reposerver/path/to/repo/branches/foo@1234; it's a single "word" that ...

Teemu Likonen <tlikonen@iki.fi> writes: [By the way, please never redirect the response to your messages away from you with: Mail-Followup-To: Jeff King <peff@peff.net>, Ingo Molnar <mingo@elte.hu>, git@vger.kernel.org You wasted 30 seconds of my (and anybody who potentially wanted to give advice to you) time by forcing me fix the To: header while composing this response. I know Jeff understands what I am going to mention, and I do I'd suggest you to study:...

This has been discussed before and rejected, because the point of doing a fetch of a URL (rather than a remote name) is to do a "one-off" thing. IOW, you don't _want_ the tracking branches, as they will just clutter your branch space (plus choosing the last component is a bad heuristic; lots of people must ask Linus to pull from their .../linux-2.6 repository). Almost nobody says "git fetch <URL>"; it is just a subpart of "git pull <URL>" which is intended for one-off merges (i.e., yo...

Ah, OK. In that case, I think the right thing to do would not be to set up a remote, but to fetch explicitly into a local branch. I assume when you say "joining" you mean "so I can get rid of the individual ones". So something like: cd repo1 git fetch ../repo2 master:repo2-topic which creates refs/heads/repo2 in repo1, and you can safely delete repo2. If you _did_ want to keep repo2 around indefinitely, and you are "joining" so that you can do diffs, then you probably do want a remote ...

Hi, Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Ciao, Dscho --

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I gues that's key here. The remote was added, but you don't actually have fetched the branches yet. Thus the merge fails, but the pull with The syntax is "git pull <repository> <refspec>" So you're trying to fetch/pull from a repository in "x86/latest", that path doesn't exist and that is pretty fatal as you cannot fetch/pull AFAIK merge cannot handle stuff that's outside your repo. To merge stuff from another repo ...

Welcome to git community. This message talks about how git.git is managed, and how you can work with it. * IRC and Mailing list Many active members of development community hang around on #git IRC channel on Freenode. Its log is available at: http://colabti.org/irclogger/irclogger_log/git The development however is primarily done on the git mailing list (git@vger.kernel.org). If you have patches, please send them to the list, following Documentation/SubmittingPatches. I usual...

* The 'master' branch has these since v1.5.5. Frank Lichtenheld (4): var: Don't require to be in a git repository. Git.pm: Don't require a repository instance for config Git.pm: Don't require repository instance for ident send-email: Don't require to be called in a repository Gerrit Pape (2): gitweb: fallback to system-wide config file if default config does not exist gitweb: fallback to system-wide config file (fixup) Govind Salinas (1): pretty.c: add %x00 format specifie...

This dq should not be necessary. The rest of this looked fine. --

That's not a fair complaint. It is often very hard to document that "we do not do X", because the line to stop at becomes fuzzier as you try to do more thorough job. We do not warn on empty ident, we do not warn on typos in commit log messages, we do not warn on empty blob, we do not warn on ... You get the idea. --

When an argument for an option is optional, like in -n from git-tag, putting a space between the option and the argument is interpreted as a missing argument for the option plus an isolated argument. Documentation now reflects the need to write the parameter following the option -n, as in "git tag -nARG", for instance. Signed-off-by: Carlos Rica <jasampler@gmail.com> --- Documentation/git-tag.txt | 4 ++-- parse-options.c | 2 +- 2 files changed, 3 insertions(+), 3 deletion...

This patch series fixes bugs in git and git's testsuite to allow all tests to pass when the working directory contains whitespace and/or shell metacharacters. The first three patches in this series fix bugs in git itself that were uncovered in the process of fixing the test suite. Each contains additional tests and/or updates to existing tests to exercise the bug in question. The remaining patches fix bugs in the test suite itself. Bryan Donlan (8): git-rebase.sh: Fix --merge --abort failure...

This is not strictly necessary: The RHS expression of an assignment does not undergo IFS splitting; but better safe than sorry. (But note that 'export foo=$bar', which is not POSIX, is *not* an assignment, and In effect, you modify only this test to stress-test strange characters, but other tests in the test suite still run in a "sane" environment. IOW, I don't think you should go to this extreme for this one test only. The better approach would be to rename 'trash' in test-lib.sh to this strange ...

I for my taste could live without a test because the fix is so obvious. Given that you have to prepend 'cd "$work_dir"' to *all* the tests, this really just highlights that for the purpose of this test the name 'trash' of the regular test directory is just too simple ;) Of course, it's Junio's draw, and he likes to have tests for fixes that On second sight, this indeed looks just like an omission and your change is good. -- Hannes --

Signed-off-by: Bryan Donlan <bdonlan@fushizen.net> --- config.c | 2 +- t/t1303-wacky-config.sh | 6 ++++++ 2 files changed, 7 insertions(+), 1 deletions(-) diff --git a/config.c b/config.c index 0624494..6c07245 100644 --- a/config.c +++ b/config.c @@ -672,7 +672,7 @@ static int store_write_section(int fd, const char* key) if (dot) { strbuf_addf(&sb, "[%.*s \"", (int)(dot - key), key); for (i = dot - key + 1; i < store.baselen; i++) { - if (key[i]...

The included patch to the test suite is an example - specifically if an element of the configuration key name other than the first or last contains a backslash, it would not be escaped on output, but would be treated as an escape sequence on input. Thus the backslash would be lost. --

Also, update t/t9001-send-email.sh to test for this bug. Signed-off-by: Bryan Donlan <bdonlan@fushizen.net> --- git-send-email.perl | 2 +- t/t9001-send-email.sh | 8 ++++++-- 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/git-send-email.perl b/git-send-email.perl index be4a20d..975df1c 100755 --- a/git-send-email.perl +++ b/git-send-email.perl @@ -510,7 +510,7 @@ EOT close(C); my $editor = $ENV{GIT_EDITOR} || $repo->config("core.editor") || $ENV{VISUA...