Surely you can arrange that. You keep track of what you pushed out, and you refrain from rebasing beyond that point. And fast-forward check in the push to the public will notice if you break that "workflow discipline" by accident. --

Constructor takes additionally URI argument, to add prefix: uri + ": " before real message. Now we don't have to remember about ugly (uri + ": ") prefix in each thrown message; Signed-off-by: Marek Zawirski <marek.zawirski@gmail.com> --- .../spearce/jgit/errors/PackProtocolException.java | 30 +++++++++++++++++++ .../spearce/jgit/errors/TransportException.java | 31 ++++++++++++++++++++ 2 files changed, 61 insertions(+), 0 deletions(-) diff --git ...

Modify existing TransportException constructor calls to new ones with URI as argument. Signed-off-by: Marek Zawirski <marek.zawirski@gmail.com> --- .../spearce/jgit/transport/BasePackConnection.java | 6 +++--- .../jgit/transport/BasePackPushConnection.java | 12 ++++++------ .../org/spearce/jgit/transport/PushProcess.java | 6 +++--- .../spearce/jgit/transport/TransportGitAnon.java | 15 +++++++-------- .../spearce/jgit/transport/TransportGitSsh.java | 18 ...

Tests for method Transport#findRemoteRefUpdatesFor(). Signed-off-by: Marek Zawirski <marek.zawirski@gmail.com> --- .../org/spearce/jgit/transport/TransportTest.java | 181 ++++++++++++++++++++ 1 files changed, 181 insertions(+), 0 deletions(-) create mode 100644 org.spearce.jgit.test/tst/org/spearce/jgit/transport/TransportTest.java diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/transport/TransportTest.java ...

pgm.Push class providing command line push utility, similar to C Git one. Some shared abbreviating methods for both Fetch and Push are moved to TextBuiltin. Signed-off-by: Marek Zawirski <marek.zawirski@gmail.com> --- .../src/org/spearce/jgit/pgm/Fetch.java | 36 +--- .../src/org/spearce/jgit/pgm/Push.java | 235 ++++++++++++++++++++ .../src/org/spearce/jgit/pgm/TextBuiltin.java | 21 ++ 3 files changed, 262 insertions(+), 30 deletions(-) create mode ...

I meant "now that the current git won't work with *some* older servers *without adding an option*". Or did I misunderstand you? -- Lea --

Sorry, while trying to fudge the headers and messages to avoid triggering vger's spam filter, I managed to mangle the subject of that message. It should have read: Subject: Glitches connecting to existing remote using 'next' git --

Say explicitly that this method returns null when revstr can't be resolved. Signed-off-by: Marek Zawirski <marek.zawirski@gmail.com> --- .../src/org/spearce/jgit/lib/Repository.java | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java index 64f93ff..2b43b2c 100644 --- a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java +++ ...

matchDestination(), matchSource(), expandFromSourec() can take String as parameter now, not only Ref (we just need a ref name). Signed-off-by: Marek Zawirski <marek.zawirski@gmail.com> --- .../src/org/spearce/jgit/transport/RefSpec.java | 46 +++++++++++++++++-- 1 files changed, 41 insertions(+), 5 deletions(-) diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/RefSpec.java b/org.spearce.jgit/src/org/spearce/jgit/transport/RefSpec.java index 38489be..1589e19 100644 --- ...

Retained flags was wrongly computed for reset() call inside isMergedInto(). Signed-off-by: Marek Zawirski <marek.zawirski@gmail.com> --- .../src/org/spearce/jgit/revwalk/RevWalk.java | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/org.spearce.jgit/src/org/spearce/jgit/revwalk/RevWalk.java b/org.spearce.jgit/src/org/spearce/jgit/revwalk/RevWalk.java index fc757a5..7976d75 100644 --- a/org.spearce.jgit/src/org/spearce/jgit/revwalk/RevWalk.java +++ ...

This option is useful when caller cares only about locally existing uninteresting objects. Test cases created. Signed-off-by: Marek Zawirski <marek.zawirski@gmail.com> --- .../tst/org/spearce/jgit/lib/PackWriterTest.java | 45 +++++++++++++++++--- .../src/org/spearce/jgit/lib/PackWriter.java | 37 +++++++++++----- 2 files changed, 65 insertions(+), 17 deletions(-) diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/PackWriterTest.java ...

New interfaces and base classes are introduced to cope with lack of multiple inheritance and allow code reuse between fetch and push operations implementations. Some renames (adding Base prefix) are also performed to distinct between interfaces and base implementations. Some generalizations/cleanings in interfaces and implementations (particularly in Base* classes) were introduced. readAdvertisedRefs() in BasePackConnection now support both push and fetch advertisements. Signed-off-by: Marek ...

Class represents result of push operation. In addition to the data provided by OperationResult it also holds information about remote refs updates. Signed-off-by: Marek Zawirski <marek.zawirski@gmail.com> --- .../src/org/spearce/jgit/transport/PushResult.java | 84 ++++++++++++++++++++ 1 files changed, 84 insertions(+), 0 deletions(-) create mode 100644 org.spearce.jgit/src/org/spearce/jgit/transport/PushResult.java diff --git ...

Just remoteName is needed, not a whole RefSpec. Signed-off-by: Marek Zawirski <marek.zawirski@gmail.com> --- .../spearce/jgit/transport/TrackingRefUpdate.java | 10 +++++----- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/TrackingRefUpdate.java b/org.spearce.jgit/src/org/spearce/jgit/transport/TrackingRefUpdate.java index 56234a1..771e77a 100644 --- a/org.spearce.jgit/src/org/spearce/jgit/transport/TrackingRefUpdate.java +++ ...

New constructor operates directly on RefSpec components: remote name, local name, force flag. Signed-off-by: Marek Zawirski <marek.zawirski@gmail.com> --- .../spearce/jgit/transport/TrackingRefUpdate.java | 13 ++++++++++--- 1 files changed, 10 insertions(+), 3 deletions(-) diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/TrackingRefUpdate.java b/org.spearce.jgit/src/org/spearce/jgit/transport/TrackingRefUpdate.java index 771e77a..a84b38a 100644 --- ...

Finally, series with push implementation. It has taken a "while" to squash all bugs this time and polish the series, uhh. Part of this series is signifficant refactor of .transport package to support code reuse between fetch and push implementations + minor fixes/improvements. Needed push operation elements were created. Implementation provides basis for different push protocols by common push process and its dendendencies. Push over git-receive-pack based transports is implemented. Shawn ...

No need to say nor be sorry. The rest looks sane from a quick glance, except that we may want to have a separate clean-up patch that consolidates MAXDEPTH in many places that limits our manual symlink resolution. --

This is not a comment you would want to move to the resulting file that contains only make_absolute_path(). --

Hi all, I just got through a rather painful build and install of 1.5.6.1 on AIX and I was wondering if anyone has any clues on how to get the tests to run a bit better there. The first thing I encountered was that because the tests all use #!/bin/sh the exit code was not what the tests expected. So I ended up running 'make SHELL=`which bash` all' directly in the git/t/ directory. That seemed to shake out and work for most of the tests except for t/t7502-commit.sh. Try as I might, I could ...

Yes, as I said, that set of operations can be performed with git today. What git can't do, is let me "supercede" the old DAG-subset, so people I shared them with can get my new changes without hurting their world. Currently git seems to rely on the idea that "if you accept changes into your tree that will be later rebased, it's up to you to figure it out". I don't see why that is the case. --

Starting with Git 1.5.4, use of dashed forms of git commands in scripts without "PATH=$(git --exec-path):$PATH" was deprecated. Thus we generally advertise the non-dashed forms of commands. git-sh-setup and git-parse-remote do not have non-dashed forms because they are meant to be sourced from a script using .; thus the only recommended way to use them is by updating PATH first. This patch changes the documentation accordingly. This does not matter as much for releases before 1.6.0, because by ...

When working with a lot of people who backport patches all day long, every once in a while I get a patch that modifies the same file more than once inside the same patch. git-apply either fails if the second change relies on the first change or silently drops the first change if the second change is independent. The silent part is the scary scenario for us. Also this behaviour is different from the patch-utils. I have modified git-apply to create a table of the filenames of files ...

Go to your main repo and configure up a new remote using "git remote add' pointing to the bare repo. Then fetch from that remote! jdl --

I have a main repository called main I create a bare clone from main call bare_clone I create clone from bare_clone called work_repository_1 I do my work in work_repository_1, commit, and push changes to bare_clone How to a push the changes in bare_clone into main?? thanks in advance, Doug --

Mentored-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> --- This is an unrelated hunk, patch below which does not contains this. Makefile | 2 +- builtin-merge.c | 1143 +++++++++++++++++++++++++ builtin.h | 1 + git-merge.sh => contrib/examples/git-merge.sh | 0 git.c | 1 + ...

There was no test for this before, so the testsuite passed, even in case the merge summary was missing from the merge commit message. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> --- t/t7604-merge-custom-message.sh | 37 +++++++++++++++++++++++++++++++++++++ 1 files changed, 37 insertions(+), 0 deletions(-) create mode 100755 t/t7604-merge-custom-message.sh diff --git a/t/t7604-merge-custom-message.sh b/t/t7604-merge-custom-message.sh new file mode 100755 index ...

Move all functionality (except config and option parsing) from cmd_fmt_merge_msg() to fmt_merge_msg(), so that other builtins can use it without a child process. All functions have been changed to use strbufs, and now only cmd_fmt_merge_msg() reads directly from a file / writes anything to stdout. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> --- builtin-fmt-merge-msg.c | 155 +++++++++++++++++++++++++++-------------------- builtin.h | 3 + 2 files changed, 92 ...

Hello, Dscho gave me a detailed review on builtin-merge, so I'm sending an updated series. It's based on 49646c5 in git.git, so hopefully it includes all the work Junio did recently in 'pu'. (PARSE_OPT_ARGV0_IS_AN_OPTION removal, etc.) Changes: * "git-fmt-merge-msg: make it usable from other builtins" - Small cleanup. * "Build in merge" - When a custom message was given for a merge, the result was not identical to the one git-merge.sh had. I added a testcase for this and ...

This function is useful outside builtin-merge-recursive, for example in builtin-merge. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> --- builtin-merge-recursive.c | 8 -------- commit.c | 8 ++++++++ commit.h | 1 + 3 files changed, 9 insertions(+), 8 deletions(-) diff --git a/builtin-merge-recursive.c b/builtin-merge-recursive.c index 43bf6aa..3731853 100644 --- ...

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> Signed-off-by: Junio C Hamano <gitster@pobox.com> --- 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 ...

From: Johannes Schindelin <johannes.schindelin@gmx.de> The recent addition of graph.c broke things with our custom implementation of strbuf_vaddf(), because "%*s" was not yet supported (because it did not have any users before). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> --- strbuf.c | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/strbuf.c b/strbuf.c index 72b3585..bd5dc80 100644 --- a/strbuf.c +++ b/strbuf.c @@ -154,6 +154,12 @@ void ...

From: Johannes Schindelin <johannes.schindelin@gmx.de> The most common use of addf() was to init a strbuf and addf() right away. Since it is so common, it makes sense to have a function strbuf_initf() to wrap both calls into one. To do that, we implement a (really minimal) vaddf() lookalike to vsprintf(). At the moment, it only handles %u, %i, %d, %l, %o, %x and %X with size indicators '<number>', ' <number>' and '0<number>', as well as %c and %s, the latter with size indicators '.*' in ...

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> --- I just noticed this was wrong here. The tests passed because a later commit had a hunk to fix this but this fix is unrelated there. So here is the right version. t/t7602-merge-octopus-many.sh | 52 +++++++++++++++++++++++++++++++++++++++++ 1 files changed, 52 ...

"Directly" as in "is child of", or as in "connected by the DAG"? "git rev-list C..B" lists all commits which are not in C but in B. If this list is empty then B is "contained" in C. This is how you can test for being connected by the DAG. For the graph above, all of the following refspecs would return an empty list, indicating connectedness: C..B C..A B..A D..B D..A Are those the "good ones" in your case? Then you know how to test for the bad guys ;) Michael --

Added to the Wiki. --

Added twice, to the Eclipse plugin page too. -- robin --

Actually that's not that easy. git-mv moves untracked files and adds tracked files to the index as well. So such a git-cp would have to copy tracked and untracked files, and add tracked files to the index. I did it in the past: http://thread.gmane.org/gmane.comp.version-control.git/72388/focus=73347 but then we agreed about it's better not encouraging copy-and-paste.

Hi, I knew this from before but for some reason I forgot about it when I tried it now. The documentation for "git diff -C" is a bit misleading. I have originally tested on git 1.5.2.something and the documentation for -C didn't point to --find-copies-harder. I've quickly installed 1.5.6.1 to test the behavior but not the man pages. Looking over the online docs for 1.5.6.1, it appears that there is now a reference to --find-copies-harder. Even so, saying just that "Detect copies as ...

By comparing if files (blobs) are alike. It has some heuristics to guess which files have good changes to be copies or renames of each If you really need it, you can and an alias alias.cp=3D!cp and be done with it ;P --=20 =C2=B7O=C2=B7 Pierre Habouzit =C2=B7=C2=B7O madcoder@debia= n.org OOO http://www.madism.org

In git (not like usually in other projects) ./configure script (autoconf) is used *only* to generate Makefile configuration. It tries to configure compile (build) process in such a way that building git is possible even if some features are missing or are found not in standard place (and also use compat version of functions if they are not in library). It helps you build system. I'm not sure if checking if prerequisites exists and failing loudly otherwise would be a good feature to have. ...

If one can determine during configure time that a required library is not found, it (IMHO) is nice to give an error message and bomb out (via AC_MSG_ERROR). The AC macro archive has a zlib macro which does this, as an example: http://autoconf-archive.cryp.to/check_zlib.html I should note, however, that I disagree with that macro's logic in that it `searches' for zlib if the user does not specify it. IMO, if the user does not give a --with option, and it doesn't work `out of the box' ...

Hi there I added a small subsection to the wiki at http://git.or.cz/gitwiki/Aliases I hope it's OK to just go ahead and edit like I did. I love the power of git aliases. This one shows how easy it is to implement a "hg serve" alike "git serve". In order to be able to use "git serve" from a subdir of the repo without much scripting (git-rev-parse --git-dir) my alias uses the fact that non-git aliases (beginning with "!") are executed with the top-level dir as cwd. Is this ...

When we call "git clone" with a url that has a rewrite rule in either $HOME/.gitconfig or /etc/gitconfig, the URL can be different from what the command line expects it to be. So, let's use the URL as the remote structure has it, not the literal string from the command line. Noticed by Pieter de Bie. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> --- builtin-clone.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/builtin-clone.c ...

What version of git is this? v1.5.5.1 and later contains 60e3aba (Fix config key miscount in url.*.insteadOf, 2008-04-12). --

This seems fine to me. OTOH, I'm not sure the environment variable should be needed in the first place; I think the config stuff should look in git_path("config") without it, and we set the git dir to the one we're initializing. So I think the use of the environment variable is just an artifact of how the shell script did it and how I was originally calling the init_db stuff. Just removing the "setenv()" line survives all of the tests for me, and I remember some of them failing before ...

From: Johannes Sixt <johannes.sixt@telecom.at> This adds a context menu entry below "Stage/Unstage Hunk" that stages or unstages just the line under the mouse pointer. This is by itself useful, for example, if there are unrelated changes in the same hunk and the hunk cannot be split by reducing the context. The feature can also be used to split a hunk by staging a number of additions (or unstaging a number of removals) until there are enough context lines that the hunk gets split. The ...

I've always said that I am not in favor of any form of partial commits, exactly for the reason Robert states, namely that you are not committing what you had in your work tree as a whole. I said so back when the only form of partial commits were "git commit [-o] this-file". I said it again even when I introduced "add -i", that the interface goes backwards and does not fix the issues associated with partial commits. But I agree with you that calling the index half-baked is missing the point. ...

Now I have my guess at the first commit as my tree state, correct? What happens when I decide I need a couple of hunks from another file which I missed in my first guess, and is now in the stashed state? How do I get those out of the stash and into the working tree? If there is no convenient way to do that, then this method is not sufficient to cover the use case I am talking about. Thanks, Bob --

I do this all the time. After I have made $N commits out of my worktree, I usually $ git rebase -i HEAD~$N and turn all 'pick's into 'edit's and 'squash's. Then I can compile and test each commit, perhaps add some fixups, in isolation. -- Hannes --

It's rather a work-around to stash away only the changes that are not in the index. See the other reply to my mail for a patch that adds an git stash pop eventually fix conflicts if you changed the working tree in the meantime go back to the "git add -p" step Björn --

Of course developers need to be able to make bad-commits. If they can't, we quickly end up back in the "don't checkin" mentality of CVS. I want to be able to do bad-commits. Further, I recognize that even with the best of intentions bad-commits will enter the mainline. What I think is missing is a mechanism for re-summarizing a set of committs that does not rely on the fact that they've never been published. See my other email on "supercede".. Consider a big public tree that is using bisect, but ...

I guess I'm not interested in the over-generalizations. ;-) But the ability to use e.g. some stash-like feature (as suggested above) to easily make the index-state (about to be committed) fully available for compiling/processing/testing without losing edits not yet ready for commit is an extra feature we would use here at least some of the time. I will admit it's currently not the "itch" at the top of my list. Thanks, -- Dana L. How danahow@gmail.com +1 650 804 5991 cell --

'git stash save' saves local modifications to a new stash, and runs 'git reset --hard' to revert them to a clean index and work tree. When the '--keep-index' option is specified, after that 'git reset --hard' the previous contents of the index is restored and the work tree is updated to match the index. This option is useful if the user wants to commit only parts of his local modifications, but wants to test those parts before committing. Also add support for the completion of the new option, ...

Hm, I use "stash" for that purpose, which leads to kind of the reverse of your approach. So I do sth. like this: - hack hack hack - Notice that I want to make two commits out of what I have in my working tree - git add -p -- stage what I want in the first commit - git commit -m tmp -- temporary commit - git stash -- stash away what doesn't belong in the first commit - git reset HEAD^ -- drop the temporary commit, with the changes kept in the working tree - test, fix bugs, read ...

On Fri, Jun 27, 2008 at 10:45 AM, Johannes Schindelin Here's a patch to match the local culture: "It is incredible how stupid the idea of the index is." Clearly you should now be interested. Thanks, Bob --

Seems to me the concept of the "index" is a half-baked version of what I really want, which is the ability to factor a working tree's changes into its constituent parts in preparation for committing them. The index provides some very nice facilities to factor out changes in a working tree into a "staging area", but the fundamental flaw of this in my view is that this "staging area" is not instantiated as a tree, so it cannot be compiled and/or tested before committing. Consider a facility ...

Robert, I'm new to git, but I understand where you are going. Why limit it only to working tree changes? For me, the stash machinery is of no help here, because I commit super-often. What I end up with is 30 commits in a topic branch, but where not every point passes 100% of tests. I want to go back through and order them properly, and decide which points are sensible as upstream committs. (especially as I read more about bisect). git has all the concepts I want except one. However, it makes ...

unsigned char sha1[20]; is sufficient here, /me thinks. -- Hannes --

s/4/2/; --

Hi, FWIW I think the rewrite of git-merge as a builtin, which is currently in the works, lifts the limit. However, this is only true if you do not use a custom script which calls commit-tree. Ciao, Dscho --

There is no really good reason to have a merge with more than 16 parents, but we have a history of giving our users rope. Combined with the fact that there was no good reason for that arbitrary limit in the first place, here is an all-too-easy to fix. Kind of wished-for by Len Brown. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> --- On Fri, 27 Jun 2008, Johannes Schindelin wrote: > On Thu, 26 Jun 2008, Len Brown wrote: > > > it would be nice if a merge of ...

Or if you are using git-svn as nobody will ever see your local branches. So rebasing is just the right way to go when tracking a Subversion tree I would say. Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.net --| "The best way to travel is by means of ...

All correct. Sorry about the confusion. --

Sorry, but I think you are wrong, Junio. Rebase can be used to backport changes, not just porting your changes forward, using --onto option: ..........maint ............1-------A'--B'--C' .........../ . . . <-- ??? ........../.......A---B---C ........./......./ ......../......./ .......0--...--D---E---F---G - master Here, A, B, C that are based on D (that is way ahead of the top of the maintenance branch 1) is rebased to the maintenance branch. But in this case, A' is ...

This example you provided Matthieu is exactly my confusion with rebase.. If I want to bring a 'broken feature-a' branch into my topic branch to build on ----- ..and then through 'fixing' the patch, it ends up rebased and accepted onto the mainline origin/master, as a single patch, which (among other things) changed However, in both cases, because Q' is not connected to Q, I don't see how git will do anything sane to help me accept Q' correctly. If I rebased my merge-q-branch ...

Hi, I'm on a CentOS Linux box, tracking 4.6 with Git 1.5.5.4 built from source.= =20 When I run gitk on a repository it works fine, but nothing happens when I r= un git-gui. No error messages, nothing.=20 If I set GITGUI_VERBOSE, I get this auto_load tk_optionMenu source /usr/share/tk8.4/optMenu.tcl auto_load tk::MenuDup source /usr/share/tk8.4/tearoff.tcl auto_load ::status_bar::new source /home/msoulier/git/share/git-gui/lib/status_bar.tcl auto_load class source ...

From: Olivier Marin <dkr@freesurf.fr> This removes, from the documentation and the bash completion script, the two config options that were introduced by the git-whatchanged.sh script and lost in the C rewrite. Today, we can use aliases as an alternative. Signed-off-by: Olivier Marin <dkr@freesurf.fr> --- Documentation/config.txt | 8 -------- contrib/completion/git-completion.bash | 2 -- 2 files changed, 0 insertions(+), 10 deletions(-) diff --git ...

I see. So it would be reasonable for the documentation to be altered slightly to show that the original nodes are still there, and that the primary difference between merging those changes one-by-one and rebasing is that rebase does not connect the new to the old. If you want to keep the old, you can toss a branch name on it, and if not, it still lives until the gc timeout. The current docs showing those nodes missing tells me that they disappear, which is both scarry, and apparently ...

Makes sense --- thanks. This is something we can have automated tests, isn't it? --

So to summarize, the problem is that you have an old tracking branch "refs/remotes/sched" that exists on the client, but upstream has since removed it in favor of "sched/devel", which you are now trying to fetch. And of course there is a conflict, because of the ref naming rules. This doesn't work seamlessly because git-fetch never removes old tracking branches, even if they have been deleted upstream. And normally there is no conflict; leaving the old branches means they don't disappear from ...

Hmm. Is there actually such a rule? I was wondering if it might make more sense to do the equivalent of what checkout_entry() does (i.e. remove_subtree()) when there is such a conflict. After all, tracking branches are meant to accept rewinds and anything that happens on the remote end, and having to run "git remote prune" is not a feature but is a lack of feature in the "git fetch", which may make it look like deletion is somewhat special. --

Previously, if there was an error while storing a local tracking ref, the low-level functions would report an error, but fetch's status output wouldn't indicate any problem. E.g., imagine you have an old "refs/remotes/origin/foo/bar" but upstream has deleted "foo/bar" in favor of a new branch "foo". You would get output like this: error: there are still refs under 'refs/remotes/origin/foo' From $url_of_repo * [new branch] foo -> origin/foo With this patch, the output ...

This does work. But the "unpacking objects" phase becomes very slow. I had 86 objects and I could see every time it did a sleep because the counter would wait a second (or more) before the next object was unpacked. Ciao! --

Is the file only being read, or could there be a simultaneous write to the same file? I'm surmising this could be an effect resulting from simultaneous cache invalidations: prior to Linux 2.6.20 or so, we weren't rigorously following the VFS/VM rules for page locking, and so page cache invalidation in particular could have some curious side-effects. Cheers Trond -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@netapp.com www.netapp.com --

For the bug I sent the information is: Server: Linux dev1 2.4.28 #3 SMP Tue Jan 18 14:59:40 EST 2005 i686 i686 i386 GNU/Linux Red Hat Linux release 9 (Shrike) Client: Linux dev2 2.6.9-42.0.8.ELsmp #1 SMP Tue Jan 30 12:18:01 EST 2007 x86_64 x86_64 x86_64 GNU/Linux CentOS release 4.4 (Final) Ciao! --

By the way, from time to time there on this mailing list is idea to add entries for directories in the index. This could help situation like yours, tracking emty directories, faster operations when some trees are unchanged, subtree <-> subproject changes. But it always comes back to: 1.) no proposed implementation, 2.) "git tracks contents"... -- Jakub Narebski Poland ShadeHawk on #git --

Yes, I've seen the occasional discussions about this. I might volunteer to help solve (1) except that I have a feeling that changing the index format would mangle all sorts of things beyond my current understanding. Attaining that understanding might not be so bad, except for (2), which seems like any proposed changes will probably be rejected anyhow. So naturally I was hoping for a magical alternative suggestion for my current problem instead :) One option I'm thinking about is to ...

I've just done that and here's the output: io1@mib19412i[00m:~/Desktop/git-1.5.6/t$ ./t2004-checkout-cache-temp.sh -d -v -i * expecting success: mkdir asubdir && echo tree1path0 >path0 && echo tree1path1 >path1 && echo tree1path3 >path3 && echo tree1path4 >path4 && echo tree1asubdir/path5 >asubdir/path5 && git update-index --add path0 path1 path3 path4 asubdir/path5 && t1=$(git write-tree) && rm -f path* .merge_* out .git/index && echo tree2path0 >path0 && echo tree2path1 >path1 ...

[Empty message]

Okay. I think I've closed the loop, and have this updating successfully, if not necessarily easily. To update, we need a local branch for each submodule: git checkout -b dojo dojo-trunk <- create local branch and switch to it (only create it the first time through) git svn rebase dojo-trunk <- do this to update each local branch from the remote svn repository version--must have corresponding branch checked out. ... now that we've merged the remote changes to a local branch, we can ...

On Fri, Jun 27, 2008 at 03:04:52PM +0200, Olivier Marin <dkr@freesurf.fr> w= Aah. I should have noticed that. I see now, your hunk is necessary when color.diff and diff.color is not set but color.ui is. Thanks.

Hi, Maybe strcpy(hex, find_unique_abbrev(head, DEFAULT_ABBREV)) would be more intuitive? Ciao, Dscho --

That would always turn colors on. This should respect diff.color: diff --git a/builtin-merge.c b/builtin-merge.c index 66189d2..c2a32ee 100644 --- a/builtin-merge.c +++ b/builtin-merge.c @@ -331,6 +331,8 @@ static void finish(const unsigned char *new_head, const= char *msg) opts.output_format |=3D DIFF_FORMAT_SUMMARY | DIFF_FORMAT_DIFFSTAT; opts.detect_rename =3D DIFF_DETECT_RENAME; + if (diff_use_color_default > 0) + DIFF_OPT_SET(&opts, COLOR_DIFF); ...

On Fri, Jun 27, 2008 at 07:19:48PM +0200, Stephan Beyer <s-beyer@gmx.net> w= Ah, OK. Then the code and the documentation differs and that's a bug, sure. =46rom git-merge.sh: # All the rest are the commits being merged; prepare # the standard merge summary message to be appended to # the given message. I did builtin-merge based on git-merge.sh, not the manpage. ;-)

On Fri, Jun 27, 2008 at 06:12:20PM +0200, Stephan Beyer <s-beyer@gmx.net> w= I think it its current form that is not a bugfix. The user may want to prepend a custom message and may want to replace the original message with a custom one, and I would not consider either of them as "buggy". Funny enough, I just sent a patch: http://thread.gmane.org/gmane.comp.version-control.git/86584/focus=3D86589 that tests the original behaviour. ;-)

Hi, I just looked how you solved that and wanted to start a discussion but Well, when I do -m <msg>, I expect that my commit message is exactly <msg>, and not <msg> with appended stuff. Of course, it doesn't matter what I expect, but I think what the documentation says matters. This is (in "master" and in "builtin-merge" of vmiklos.git): -m <msg>:: The commit message to be used for the merge commit (in case it is created). The `git-fmt-merge-msg` script can be used to give a good ...

I wonder why the bugfix commit aec7e9cd Don't append default merge message to -m message has disappeared or why/if this belongs to js/rebase-i-sequencer. I noticed this because a test case of sequencer failed during rebasing to pure "master"/"next" without js/rebase-i-sequencer. I also have a question: my development branch for the sequencer prototype is based on next, then: * Merge js/rebase-i-sequencer * ... development ... The only reason that makes js/rebase-i-sequencer ...