Hi all, I am a newbie to git. Do we have any documentation for the usage of git. Basically i have downloaded open-fcoe project into my machine, i want to roll back to the earlier version. I want some documents which gives a list of command to be used to see the different versions and download the somewhat older/stable version. Thanks in Advance. ~Cheers Prasanna --

From: Dirk Suesserott <newsletter@dirk.my1.cc> Signed-off-by: Dirk Suesserott <newsletter@dirk.my1.cc> --- Documentation/git-request-pull.txt | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Documentation/git-request-pull.txt b/Documentation/git-request-pull.txt index 270df9b..9a14c04 100644 --- a/Documentation/git-request-pull.txt +++ b/Documentation/git-request-pull.txt @@ -24,7 +24,7 @@ OPTIONS URL to include in the summary. <end>:: - Commit to send at; ...

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 ...

Signed-off-by: Matthias Kestenholz <mk@spinlock.ch> --- This patch adds color.ui support for scripts. It does that by modifying `git config --get-colorbool`, because there is no way to differentiate between undefined and `false` configuration variables in scripts. Additionally, the scripts don't need to be changed. I have only tested git add -i; git svn uses the same functions in Git.pm, so it should work too. Of course, it would have been nicer if I had made this change before the ...

I have found this refs/heads/*:refs/remotes/* stuff quite confusing, but I'm starting to understand them. I know my way with them but still they seem quite unnecessary hackerish. Pull and push work pretty nicely without knowing about any refs/* stuff; they can be operated with simple branch names. Fetch is another story. Some ideas: $ git fetch <URL> would be equivalent to $ git fetch <URL> +refs/heads/*:refs/remotes/<name>/* In other words, fetch all the branches from remote repo ...

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 --

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: ...

Something along the lines of: Error description Why it happened How to solve/Sugestion -- []s, André Goddard --

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

Many other commands use the "no arguments" form to show a list (e.g., git-branch, git-tag). While we did show all remotes for just "git remote", we displayed a usage error for "git remote show" with no arguments. This is counterintuitive, since by giving it _more_ information, we get _less_ result. The usage model can now be thought of as: - "git remote show <remote>": show a remote - "git remote show": show all remotes - "git remote": assume "show"; i.e., shorthand for "git remote ...

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 ...

First, thank you for such a detailed information and giving somewhat different point of view from mine. Ok, "git fetch <URL>" has its own "point", as you noted, and no doubt it's for good reasons. I just had partially misunderstood its point. See Hmm, maybe. I recently wanted to join two purely local repos together. Both of them had just one branch. Totally different histories so no actual mergin would happen; just two branches in the same repo. I don't know why but "git fetch ...

i just had a rather annoying session with git - here's the dump and commentary, in case anyone is interested in usability fineprint. it was with git-core-1.5.4.3-2.fc8 - so if it's all fixed/improved in 1.5.5, or if this is blatant user error for which i deserve to be punished then my apologies! usually i just have a single git repo that tracks everything interesting, but this time i did something i rarely do: i tried to merge one local tree of mine into another local tree of mine. So ...

As you figured out later, the problem was that "git remote add" doesn't actually fetch the remote's contents: it just sets up the remote. There is a "-f" option which does the fetch automagically after adding. In this case, had "-f" been the default, it would have Just Worked for you. So that's something for us to consider, but I'm not sure if we This is another place where we might have DWYM, by seeing that your repository name started with "<name of a remote>/" and splitting it ...

With recent git, parsecvs now always fails like this: ... Save: master *.................... 1 of 269 Save: master *.................... 2 of 269 error: char77: malformed tagger field fatal: invalid tag signature file git-mktag < '.git-cvs/tag-0': No such file or directory This is due to the change that makes git's mktag perform stricter input validation. parsecvs patch below. [BTW, Keith, or anyone with ...

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. Caution. "next" has been rebuilt with the remaining topics on top of "master". "maint" is still for 1.5.4.X maintenance track for tonight. A rough timeline from now on. * Brown paper back fixes, if any, for 1.5.5.1 (2008-04-16). * Discussion and review on new feature and enhancement patch ...

The latest feature release GIT 1.5.5 is available at the usual places: http://www.kernel.org/pub/software/scm/git/ git-1.5.5.tar.{gz,bz2} (tarball) git-htmldocs-1.5.5.tar.{gz,bz2} (preformatted docs) git-manpages-1.5.5.tar.{gz,bz2} (preformatted docs) RPMS/$arch/git-*-1.5.5-1.$arch.rpm (RPM) We kept this cycle just slightly over two months, as the previous 1.5.4 cycle was painfully tooooo long. GIT v1.5.5 Release Notes ======================== Updates since ...

--

I didn't mean it as a complaint, but rather was hoping for a response of the form "no, it's not there" or "it's in the ... section" - sorry for not being clear. It caught me out, if that was my own fault then fair enough - but if this was because the documentation doesn't make it clear then I can submit a documentation patch to try and help others avoid the same problem. I think that the fast-import tool is extremely useful, and generally very well documented. That doesn't mean that ...

When an argument for an option is optional, like in -n from git-tag, puting 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> --- I forgot to make the same change to the command's syntax in builtin-tag.c. I didn't check if this also happens for ...

How exotic ought it be? I'm not entirely sure which characters are allowed on windows or any other non-unixes that git supports (are there any?) Thanks, Bryan --

I split it out as it's not really related to the goals of 5/8 or 8/8, but is rather pure elimination of code duplication. However if it's considered better to squash it into 5/8 I'd be happy to do so. Thanks, Bryan --

In particular, this function correctly handles cases where the pwd contains spaces, quotes, and other troublesome metacharacters. Signed-off-by: Bryan Donlan <bdonlan@fushizen.net> --- t/test-lib.sh | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/t/test-lib.sh b/t/test-lib.sh index 17d4bc0..6f43376 100644 --- a/t/test-lib.sh +++ b/t/test-lib.sh @@ -160,6 +160,15 @@ die () { trap 'die' exit +test_set_editor () { + # If the editor path contains a ...

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 ...

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{VISUAL} || ...

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 ...

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] == ...

Signed-off-by: Bryan Donlan <bdonlan@fushizen.net> --- t/lib-git-svn.sh | 11 ++++++----- 1 files changed, 6 insertions(+), 5 deletions(-) diff --git a/t/lib-git-svn.sh b/t/lib-git-svn.sh index 9decd2e..1b37ba8 100644 --- a/t/lib-git-svn.sh +++ b/t/lib-git-svn.sh @@ -7,9 +7,9 @@ then exit fi -GIT_DIR=$PWD/.git -GIT_SVN_DIR=$GIT_DIR/svn/git-svn -SVN_TREE=$GIT_SVN_DIR/svn-tree +GIT_DIR="$PWD/.git" +GIT_SVN_DIR="$GIT_DIR/svn/git-svn" +SVN_TREE="$GIT_SVN_DIR/svn-tree" svn ...

I agree with that. For me, each day this group shows 200+ topics when I opened Gnus. I think this could be divided into two groups, one for git-user and the other for git-devel. -- DigitalPig E-mail: digitalpiglee AT gmail DOT com ALL WE SEEN IS ILLUSION. --

The private Error file is not installed if perl/Makefile.PL detects than an Error.pm recent enough on your system. Do you actually have perl/blib/lib/Error.pm ? Try to run (cd perl; make clean; cd ..; make) and try the tests again. --

Thanks for the patch René! First I reproduced my problem on vanilla git v1.5.5, and it is still there as in v.1.5.4.4. I applied this patch and that fixed my issue, testing both tar and zip. Ulrik Sverdrup --

We actually encourage people to send email to the list without subscribing if they just have a particular question they'd like answered and don't want a ton of other mail. -Daniel *This .sig left intentionally blank* --

Hi, Yep, I wrote "-1", but what I actually meant was "--no-walk". Sorry, Dscho --

On Wed, Apr 09, 2008 at 04:06:57PM +0200, Johannes Schindelin <Johannes.Sch= If you mean: git log -1 $(git rev-list --parents HEAD | sed -n "s/ .* .*//p") then it'll show only the first merge, --only-merges shows each merge. (While of course you can still use -1 or tag.. or so.)

[Grmpf, the next time you drop from me Cc:, I'll not bother to answer...] Change the "." to "file:///tmp/test-repo/trunk" in the svn cp command and you get: Changed paths: A /release (from /trunk:3) Seems more useful. No idea why SVN decides to record crap when you use Uhm, and what happens then, when you actually _did_ just copy over a few files, but not all of them? Right, you get a branch to start at a later revision and see a bunch of reverts. Equally broken. Björn --

That's good advice, but I'm wondering how to convert my existing svn Sure, if you create a situation that GIT can't represent then there's nothing much git-svn can do. However, when there are different source revisions: - Taking the highest revision will give correct results in the common case, and "equally broken" results in the uncommon case. - Taking any other revision (the current behaviour) is guaranteed to give the wrong result. There's no way a branch that was created with ...

I don't suppose you have a demo site showing it in action? -- Alex, homepage: http://www.bennee.com/~alex/ The worst is not so long as we can say "This is the worst." -- King Lear --

Probably logarithmically with the number of cores. But for reasonable machines, this number is relatively low, so the log is not so costly. For a binary search, using just 2 cores, you can try the next in the list in case of a "git bisect good" for example, and if the hypothesis is true, you've just gained a factor 2 (assuming it happens 50% of times, that should be a 50% speedup). Similarly, you should get a factor 2 with 3 cores. And as said before, you can also try trisection or N-section. ...

Yeah. But to get a factor 3, you need 7 cores; and for 4, you need 15. It goes downhill from there. If your build+test cycle is parallelizable at all, I don't think you'll find those numbers hard to beat. (There's also the fact that testing several revisions at once assumes that the whole build+test cycle is automated, or at least most of it. Otherwise you need more people as well as more cores.) -- Karl Hasselström, kha@treskal.com www.treskal.com/kalle --

In fact, you have to give all the good revisions you have, not just the last one. So it should be "git bisect start CURRENT-BAD X GOOD1 GOOD2 ..." or "git bisect start X GOOD1 GOOD2 ..." Above also you must give all the good ones, so it is: Regards, Christian. --

Good point. I re-read the cvsps manpage and found the information about "FUNKY" and "INVALID" tags. I'd forgotten that cvsps does the right thing in some cases by warning the user about tags that are beyond its abilities to describe. (But there are other problems that cvsps doesn't warn about; see below.) Then I looked in the git-cvsimport code to see how it deals with FUNKY and INVALID tags. It does the *wrong* thing by explicitly ignoring these warnings (!). IMHO git-cvsimport should ...

Sorry, I wasn't clear. I meant that there's no fundamental reason that this shouldn't be possible; as far as I know, there's no way to make git do this in an obvious way (yet). It's encouraging that other people seem to want the same behaviour as me, which means I might get to working on it sooner :) Not that this should discourage you from trying, of course: perhaps I'm just missing something too. Note: I think a big part of the secret is using "." as the location of the submodule's ...

That I don't know. If there aren't any others, then I agree, I'm not Not exactly. The idea is that if the supermodule and submodules are all lumped into a single repo (and your refs are set up correctly), then cloning the supermodule will also clone all the submodules. So everyone will have all the necessary refs anyway; as long as git-checkout checks them out, .gitmodules shouldn't have to exist at all, becaues there's nothing "special" for git-submodule to do. Have fun, Avery --

I could be mistaken, but I don't think "git submodule add" does anything to the .git/config. In fact, how settings migrate between .gitmodules and .git/config has been a long standing source of slight confusion for me. Please correct me if I'm wrong, but it seems that the only reason for the file .gitmodules to be there at all is because it can be revved through commits, just as any file under Git's control. .git/config doesn't have such a property. Other than that, it is not Speaking of ...

Hallo Johannes, It this really a proper way to call git merge? The manpage says: The second syntax (<msg> HEAD <remote>) is supported for historical reasons. Do not use it from the command line or in new scripts. It is the same as git merge -m <msg> <remote>. And how would you pass the option for the strategy to this form? Git rebase calls git merge with -s. Bye, J=F6rg. --=20 But in the case of "git revert", it should be an ancestor (or the user is just insane, in which ...

The old fake-editor selects only lines they start with pick, if you give the number of a line. With the new commands mark, merge and reset it was not possible to select such lines for the new TODO list. The new fake-editor selects all kinds of lines, but replaces only the command “pick” with a different action. --- t/t3404-rebase-interactive.sh | 5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh index ...

Junio proposed to add the commands mark, merge and reset to rebase interactive for a better support of rebase with preserve merges. The current format can only cope with flat lineare lists of commits and not with the non

This command redoes merges. It's useful if you rebase a branch that contains merges and you want to preserve these merges. You can also use it to add new merges. --- git-rebase--interactive.sh | 25 +++++++++++++++++++++++++ t/t3404-rebase-interactive.sh | 3 +++ 2 files changed, 28 insertions(+), 0 deletions(-) diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh index 7dac51b..18cdf3d 100755 --- a/git-rebase--interactive.sh +++ b/git-rebase--interactive.sh @@ ...

--- git-rebase--interactive.sh | 14 ++++++++------ 1 files changed, 8 insertions(+), 6 deletions(-) diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh index 973770e..1698c3e 100755 --- a/git-rebase--interactive.sh +++ b/git-rebase--interactive.sh @@ -115,14 +115,17 @@ has_action () { } redo_merge() { - author_script=$(get_author_ident_from_commit $sha1) - eval "$author_script" + local sha1 + sha1=$1 + shift + + eval "$(get_author_ident_from_commit $sha1)" ...

--- git-rebase--interactive.sh | 248 ++++++++++++++++++++++++----------------- t/t3404-rebase-interactive.sh | 34 ++++++ 2 files changed, 181 insertions(+), 101 deletions(-) diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh index 060b40f..27bd87e 100755 --- a/git-rebase--interactive.sh +++ b/git-rebase--interactive.sh @@ -22,12 +22,10 @@ TODO="$DOTEST"/git-rebase-todo DONE="$DOTEST"/done MSG="$DOTEST"/message ...