Yup. I have $HOME/git-active/bin on my $PATH and then these: lrwxrwxrwx 1 junio junio 10 2008-05-25 18:13 /home/junio/git-active -> git-master drwxr-sr-x 6 junio junio 4096 2007-04-04 02:49 /home/junio/git-maint drwxr-sr-x 5 junio junio 4096 2007-12-14 22:46 /home/junio/git-master drwxr-sr-x 6 junio junio 4096 2008-06-23 22:02 /home/junio/git-next drwxr-sr-x 7 junio junio 4096 2007-12-02 02:52 /home/junio/git-pu drwxr-sr-x 4 junio junio 4096 2006-10-14 22:43 ...

Are you sure about that? I've been deliberately fixing that patch. As far as I understand it, your series: - starts out building infrastructure; - adds tests; - finally replaces git-merge with the new implementation. and the test in question comes when git-merge built from that version is still the scripted version with limitation. So if you build and test after applying individual steps (you sure do that, don't you?), the test has to start with expecting failure (from ...

Thanks, both. --

Hi all, I took with me a copy of a local repository to a week away from my station (just rsync'ed it to my laptop). On my return, I just "git push myuser@my-station:/my/git/repo" from my laptop. It seemed to work with no probs. On my station the git repo got the new commits, as I can see in git-log, but the actual files were left untouched. So I need to do something like "git reset --hard HEAD" to get the changes into the local files. Is that considered normal ? or did I do something ...

Hi, I'm a recent convert to git. I've been swapping over my projects from cvs to git. The latest candidate for conversion is the config files for my Linux server. I've been using cvs to record all the config changes, and - mostly-automatically - to setup new servers. Git will do a far better job, I think, but I think I'm going to run into a problem: the root directory of the server will be the working directory. Only relatively few files will be under version control. How do I stop ...

That's where you're wrong. You can't get git to pay attention to anything inside an ignored directory using the .gitignore files. Once you ignore a directory, git stops looking at it completely. You can force git to look at a file inside an ignored directory by adding it directly, though. Git will pay attention to files you add for changes, but won't pay any attention to other files around it. See the log below for what I mean: $ mkdir temp $ cd temp $ git ...

Oups.. sorry for the patch-as-attachment in the previous mail This patch makes the output of git-submodule more useful to handle the management of a repository using multiple submodules. Namely, it displays informations about how the current checked out version relates to the registered one (i.e. direct parent, direct child, "just different", registered revision does not exist), and displays if the submodules contain uncommitted changes. This (among other things) allows to do git-submodule ...

We saw this explanation repeated on the mailing list a few times. Even though the description of individual options to particular commands are explained in their manual pages, the reason behind choosing which is which has not been clearly explained in any of the documentation. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> --- Here is a resend with updates that fix the mistakes you pointed out in the previous version. Includes an update to the Documentation section (Sverre Rabbelier ...

Hi, AFAICT this is the correct way to solve the problem. We do not "leak" memory here, since we just assume objects to be singletons (they are immutable, after all). FWIW I had a "release_all_objects()" function in my personal fork for a long time, which was quite painful to write. But maintaining the "move all builtins into libgit.a and avoid fork()&&exec()ing them" patch was the only user, and since it became way too painful to maintain out of the tree, I dropped ...

Hi Ingo, # 4) Consider changing your PS1 to also show the current branch: # PS1='[\u@\h \W$(__git_ps1 " (%s)")]\$ ' # # The argument to __git_ps1 will be displayed only if you # are currently in a git repository. The %s token will be # the name of the current branch. Regards, Gábor --

i recently switched to 1.5.6.1.89.gd5446 and i'm getting this: Switched to branch "master" Your branch is ahead of the tracked remote branch 'origin/master' by 50 commits. it's a very useful detail! It's especially useful when two branches diverge in a non-trivial way. I used to have ad-hoc scripts to discover this in the past: earth4:~/tip> tip-compare-remote master : differs from remote (-50 commits) tip : differs from remote ...

Just "git checkout" works for me: git (master) $ git checkout Your branch is behind the tracked remote branch 'origin/master' by 6 commits, and can be fast-forwarded. Björn --

{14:44:16|~code/git}% git checkout master Checking out files: 100% (180/180), done. Switched to branch "master" {14:44:24|~code/git}% git shard HEAD\~5 HEAD is now at 8e69d78 Merge branch 'maint' {14:44:28|~code/git}% git checkout HEAD Your branch is behind the tracked remote branch 'origin/master' by 6 commits, and can be fast-forwarded. -- Mikael Magnusson --

I agree, it's a really nice little feature. Indeed, I occasionally do "git checkout master" just to get the message (to see where I am). It feels logical for "git status" to offer the same information (when the information is appropriate). [...] --

i have a tip-curr (shortcut: 'tc') scriptlet to answer the "where I am amongst 100+ branches" question: earth4:~/tip> tc tip/master 200a86b: Merge branch 'x86/unify-setup' which is just a thin wrapper around git-log: earth4:~/tip> cat ~/bin/tip/tip-curr #!/bin/bash . ~/bin/tip/tip-lib echo "tip/"$(get_current_branch)" "$(git log -1 --pretty=format:"%h: %s") Ingo --

Perhaps like this, but be warned this is untested except for compilation testing. builtin-checkout.c | 39 +++++++++++++++++++++------------------ wt-status.c | 22 ++++++++++++++++++++++ 2 files changed, 43 insertions(+), 18 deletions(-) diff --git a/builtin-checkout.c b/builtin-checkout.c index 93ea69b..2cbc39c 100644 --- a/builtin-checkout.c +++ b/builtin-checkout.c @@ -305,7 +305,7 @@ static int merge_working_tree(struct checkout_opts *opts, return 0; } -static ...

I still have problems with the above. I'd write it this way: int len, early; ... /* See if remote matches <name>^^^.. or <name>~<number> */ for (len = 0, ptr = remote + strlen(remote); remote < ptr && ptr[-1] == '^'; ptr--) len++; if (len) early = 1; else { early = 0; ptr = strrchr(remote, '~'); if (ptr) { int seen_nonzero = 0; len++; /* count ~ */ while (*++ptr && isdigit(*ptr)) { seen_nonzero |= (*ptr != '0'); len++; } if ...

Within the next 6 months C git clients will begin asking remote servers for 'git $command' rather than 'git-$command' when using the SSH transport. This change is to allow the C git programs to be removed from the user's $PATH, leaving only the git wrapper binary. For the first 6 months after C git 1.6.0 gets released clients will continue to ask for 'git-$command' but users may change that behavior by specifically asking for 'git $command' in remote.$name.uploadpack or ...

If the RemoteRefUpdate requests us to create a remote name of just "master" (say due to a bug in the push command line tool) we would do just that, creating "$project.git/master" on the remote side. This is not a valid ref for Git and confusion ensues when C Git tries to operate on the same repository. Normally these sorts of bad refs are blocked by git-receive-pack on the remote side, but here we don't have that so we must do the blocking as part of the push connection. Signed-off-by: ...

If we remove a ref we must also remove the reflog. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> --- .../spearce/jgit/transport/WalkPushConnection.java | 7 +++++++ .../jgit/transport/WalkRemoteObjectDatabase.java | 13 +++++++++++++ 2 files changed, 20 insertions(+), 0 deletions(-) diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/WalkPushConnection.java b/org.spearce.jgit/src/org/spearce/jgit/transport/WalkPushConnection.java index f63bedd..5450b84 100644 --- ...

Recently I saw a bundle with a chain of deltas to base objects as A->B->C, where A was the delta depending on the base B. In this pack all of the objects used OBJ_REF_DELTA to link to their base and C was not in the pack (it was assumed to be in the repository). Because of the ordering of the ObjectIds for B and C jgit tried to resolve A's delta base by pulling from the repository, as B was not found in the pack file. The reason B was not found was because it was waiting in the queue (to be ...

On UNIX (and even Cygwin) we can package the entire jgit library into a single JAR file and prefix that JAR with a shell script to start the JVM, passing in the script/JAR file as the only classpath. This trick works because the table of contents for the ZIP file is at the end of the stream, and the JVM tends to only do random access through that table when it looks up classes for loading. A tiny shell script called make_jgit.sh compiles everything with the command line javac and packages it ...

Heh, these three typically come in different order. Look at the log message and docs to see if the design is sound, then look at the code, and if things overall look Ok, then finally apply and test. I unfortunately ran out of time tonight and will look at them probably Thursday evening. It seems that another GSoC topic is finally nearing completion and I can shift my attention to other topics now. By the way Christian is not CC'ed? --

Hi, Ah. I'm sorry. So it is like "git branch <ref>", isn't it? Ah, so squash --from <mark> picks up everything since "mark <mark>", but does not include marked commit! Clever! In this case allowing O.K. I guess that is something left for later, especially that forbidding merges in squashed commit is default (and you can always Perhaps stating that it returns 128 on fatal error, or rewording that any other return value means some fatal error (does it?) would be better. But ...

Hi, the patches for rebase-i migration follow. Why this intermediate mail? Because the patches will not apply to master/next/pu/whatever. It needs js/rebase-i-sequencer, that is "dropped for now" from git.git. So you have to do some extra work to apply. Well, I could've just added a "Squashed js/rebase-i-sequencer patch" or something, but 1. I didn't write the patches so I don't want to claim I'm the author, 2. It's an opportunity to try sequencer, as follows: If you still have the ...

git sequencer is planned as a backend for user scripts that execute a sequence of git instructions and perhaps need manual intervention, for example git-rebase or git-am. Mentored-by: Christian Couder <chriscool@tuxfamily.org> Mentored-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Stephan Beyer <s-beyer@gmx.net> --- Some comments: - It's declared as plumbing, but the prototype can't really be named "plumbing", imho, since it uses porcelain like git-commit. - I hope it is ...

Mentored-by: Christian Couder <chriscool@tuxfamily.org> Mentored-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Stephan Beyer <s-beyer@gmx.net> --- Note that the --quiet tests are test_expect_failure, because I have not really cared about the output behavior of sequencer, and --quiet cannot be a trivial exec >/dev/null, because sometimes editors are invoked, etc. Also note that the fake-editor is quite different from the one in the rebase tests. According to a "session", the file ...

Hi, On Tue, Jul 01, 2008 at 06:02:54AM -0700, Right, you've already mentioned it several times. ;-) But I haven't included it currently, because git-sequencer currently *uses* cherry-pick/revert to pick/revert commits, and I think this can lead to some confusion. And, I think there also has to be some discussion, e.g. if even the single cherry-pick/revert uses sequencer, then the behavior changes for the user: currently you have to "git commit" after a conflict on cherry-pick. When it uses ...

Hi, I don't know. If something like "last created commit" is better, Good question. The reflog is another mistery to me that I haven't really cared about, because I haven't used it yet myself. At least the reflog test cases for git rebase -i in the test suite pass. Forbidding merges is default currently. It's just a sanity check. And the option bypasses this check. Regards, Stephan -- Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F --

Hi, Hey, "--cd=" is free! And it would make explaining easier why -p is applied first. Ciao, Dscho --

There is an analogous concept in patch(1), it's just implemented by cd'ing to a subdirectory first. ;) I think --root makes sense as the root of the patch. The other alternative would be --add (by analogy with --strip); the biggest advantage there is that -a, as a short option, isn't used for anything either by git-am, git-apply, or patch. Incidentally, has anyone talked to the patch(1) maintainers about adding support for the git extensions, like binary patches? The main reason is ...

Although that could imply cd'ing into another git repository to some people. -hpa --

I don't use bundles myself, so I can't comment on how useful this is for a bundle-based workflow. But it seems like a sensible idea in general. When a new feature depends on other, more generic improvements to existing code, it is usually split into two patches. E.g., 1/2: add --stdin to git-bundle 2/2: add git-basis with the advantages that: - it is slightly easier to review each change individually - it is easier for other features to build on the generic improvement ...

Yeah, perhaps we should then check that it can be a mistake by testing if bad is an ancestor of good. If bad is indeed an ancestor of good, it's probably a mistake and we may even ask if the user wants good and bad to be Yes this can be a good idea, if the user gave only one good rev. It maybe more tricky if he gave many good revs, but in this case we may perhaps drop Yeah that might be a plan. Another option is to introduce a switch to "git bisect start", perhaps --strict, to ...

I use "git remote add" for each new repository and haven't had anything in the branches directory of any of my trees for a long time ... --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/

Yes, the earlier "line break adjustments" patch really helped. I've queued all of them to 'pu' while reading them over, except for the last one. I did not look very carefully, but the parts I did look at made sense. In general, I've always preferred to see command names "git-foo" typeset in teletype face, consistent with examples (also typeset in tt), because they are both something the end users are expected to type. With this transition, we are however making "git-foo" not something ...

There are other places with the same breakage. You would need something like this (using the {asterisk} macro I wrote for updating the docs for another topic). The patch shows only a single use location but there are others in the same file. diff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf index 10c1a15..40d43b7 100644 --- a/Documentation/asciidoc.conf +++ b/Documentation/asciidoc.conf @@ -8,6 +8,7 @@ # the command. [attributes] +asterisk=* plus=+ ...

remote.<name>.fetch in config is equivalent of "Pull:" line in $GIT_DIR/remotes/<name>, while remote.<name>.push in config is eqiovalent of "Push:" line in $GIT_DIR/remotes/<name>. -- Jakub Narebski Poland ShadeHawk on #git --

The files under remotes are the old way of configuring remotes (see git help push). The new are config lines in the remotes section, as written by "git remote". I don't think "git remote" can write the lines you want, so I'd suggest: git config remote.ko.url kernel.org:/pub/scm/git/git.git git config remote.ko.fetch refs/heads/master:refs/tags/ko-master git config --add remote.ko.fetch refs/heads/next:refs/tags/ko-next git config --add remote.ko.fetch ...

Adds a new option 'e' to the 'add -p' command loop that lets you edit the current hunk in your favourite editor. If the resulting patch applies cleanly, the edited hunk will immediately be marked for staging. If it does not apply cleanly, you will be given an opportunity to edit again. If all lines of the hunk are removed, then the edit is aborted and the hunk is left unchanged. Applying the changed hunk(s) relies on Johannes Schindelin's new --recount option for git-apply. Note that the ...

Hi, He will not :-) Ciao, Dscho --

Sorry for the resend, but I again squashed an unrelated hunk to the last patch, so I'm sending the changed patches: 08: Add new test to ensure git-merge handles more than 25 refs. 13: git-commit-tree: make it usable from other builtins 14: Build in merge I really hope I won't overlook this next time. The interdiff from the previous version is empty, I just moved that unrelated hunk from patch 13 to patch 08. Junio C Hamano (2): Introduce get_merge_bases_many() Introduce ...

Move all functionality (except option parsing) from cmd_commit_tree() to commit_tree(), so that other builtins can use it without a child process. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> --- builtin-commit-tree.c | 71 ++++++++++++++++++++++++++++-------------------- builtin.h | 4 +++ 2 files changed, 45 insertions(+), 30 deletions(-) diff --git a/builtin-commit-tree.c b/builtin-commit-tree.c index 3881f6c..7a9a309 100644 --- a/builtin-commit-tree.c +++ ...

The old shell version handled only 25 refs but we no longer have this limitation. Add a test to make sure this limitation will not be introduced again in the future. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> --- t/t7602-merge-octopus-many.sh | 52 +++++++++++++++++++++++++++++++++++++++++ 1 files changed, 52 insertions(+), 0 deletions(-) create mode 100755 t/t7602-merge-octopus-many.sh diff --git a/t/t7602-merge-octopus-many.sh b/t/t7602-merge-octopus-many.sh new file mode ...

Mentored-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> --- Interdiff since the previous version: git diff fab9109..b86e8ad Individual commits: git log b86e8ad Makefile | 2 +- builtin-merge.c | 1148 +++++++++++++++++++++++++ builtin.h | 1 + git-merge.sh => contrib/examples/git-merge.sh | 0 ...

e". I just realized that builtin-reset forks read-tree as well, so I did Ah, and this way I don't need memrchr(), which was pointed out to be Right. Now I do strbuf_addstr(&truname, "refs/heads/"); Before appending the remote name to truname, so that should exclude Now if the second token is a valid SHA1 then I die() if it's not a Yes, now it's just: Thanks, that was the case. I thought "false || exit" exits with status Done.

Mentored-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> --- Interdiff: git diff 01a7dae..7709df7 Individual commits (there is only one change this time): git log 7709df7 Ah and please don't forget to apply the testsuite fix I sent in $gmane/86981. (Or is it easier if I resend the whole series?) Makefile | 2 +- builtin-merge.c | 1158 ...

Wait a minute... Are you calling a detached HEAD as head_invalid here? I Which is about HEAD pointing at a branch that isn't born yet. They are two very different concepts. Either the above "else if (head_invalid)" is wrong, or more likely the setting of head_invalid we saw earlier is wrong. Probably what you meant was: - "char *branch" points at either "HEAD" (when detached) or the name of the branch (e.g. "master" when "refs/heads/master"); - "unsigned char head[]" ...

The msysgit release is available at http://code.google.com/p/msysgit/downloads Besides GIT 1.5.6.1, the installer also brings an updated msys-1.0.dll that works on Vista. Steffen --