Signed-off-by: Samuel Bronson <naesten@gmail.com> --- Documentation/Makefile | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/Documentation/Makefile b/Documentation/Makefile index 7a8037f..f5d670e 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -106,6 +106,7 @@ endif SHELL_PATH ?= $(SHELL) # Shell quote; SHELL_PATH_SQ = $(subst ','\'',$(SHELL_PATH)) +# unconfuse Emacs: ' # # Please note that there is a minor bug in asciidoc. -- ...

Without this, "make help" first builds "help.o", then tries to link it to make a "help" executable, which might take a while to fail in a clean tree. Signed-off-by: Samuel Bronson <naesten@gmail.com> --- Makefile | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/Makefile b/Makefile index eaae45d..07a141d 100644 --- a/Makefile +++ b/Makefile @@ -1,6 +1,12 @@ # The default target of this Makefile is... all:: +.PHONY: help +help: + @echo ...

On Mon, May 25, 2009 at 6:28 PM, Julian Phillips I understand all of that but now I am not sure what the best procedure is. This is what I have been doing. - create an integration branch - pull changes from someones repo into my integration branch - do whatever testing/reviewing/etc. necessary and if I want their changes, continue... - merge integration branch (which contains their changes) into my master branch (test etc...) - push my master to my origin I expect there is a simple way ...

Move a char and a char * outside of a for loop for speed improvements Signed-off-by: Thomas Spura <tomspur@fedoraproject.org> --- Comments? transport.c | 7 +++---- 1 files changed, 3 insertions(+), 4 deletions(-) diff --git a/transport.c b/transport.c index 17891d5..e350937 100644 --- a/transport.c +++ b/transport.c @@ -263,11 +263,10 @@ static int write_refs_to_temp_dir(struct strbuf *temp_dir, int refspec_nr, const char **refspec) { int i; + unsigned char ...

Thanks, sorry for the noise... Thomas --

It's a good idea to include actual timings, to give the reader a better Please turn off automatic line wrapping in your email program when I wouldn't expect this to significantly change the object code. Declaring variables in as narrow a scope as possible often helps to make the code more readable, though. write_refs_to_temp_dir() is short This introduces a memory leak. The string pointed to by ref is allocated by dwim_ref() and needs to be free()'d after use, and -- more importantly -- ...

Heya, On Mon, May 25, 2009 at 21:14, Giuseppe Bilotta Sweet! I now have a vested interest to see this accepted :P. -- Cheers, Sverre Rabbelier --

This small patchset introduces a framework to allow git-am to support patchsets not in mailbox format. The first patch introduces a new patch_format variable that holds the (autodetected) patch format. All patches are assumed to be in the same format. Autodetection for Mercurial and StGIT patches is also implemented, including series index expansion for StGIT. The second patch introduces actual support for StGIT patches by using some awk code to convert them to mailbox format. Giuseppe ...

I personally do not trust "autodetection" (especially done by others ;-), # have parseopt to set explicit patch_format before this part... if test -z "$patch_format" && { test $# = 0 || test "x$1" = x- } then patch_format=mbox else patch_format=$(guess_patch_format) fi Having this extra logic inside the main codeflow makes it extremely harder Can the "series-index-name" file begin with '-' (which would affect the way how 'set "@"' ...

Convert StGIT patches to mbox format so that they can be imported. Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com> --- git-am.sh | 32 ++++++++++++++++++++++++++++++++ 1 files changed, 32 insertions(+), 0 deletions(-) diff --git a/git-am.sh b/git-am.sh index 3508b7e..5199354 100755 --- a/git-am.sh +++ b/git-am.sh @@ -375,6 +375,38 @@ else exit 1 } ;; + stgit) + this=0 + for stgit in "$@" + do + this=`expr "$this" + 1` + msgnum=`printf "%0${prec}d" ...

Subject: [PATCH] fix segfault showing an empty remote In case of an empty list, the search for its tail caused a NULL-pointer dereference. Reported-by: Erik Faye-Lund <kusmabite@googlemail.com> Signed-off-by: Clemens Buchacher <drizzd@aon.at> --- This should fix it. I simply copied this from other uses of match_refs. I wonder if this calls for a find_link_ref_tail() function, but I didn't know where to put it. Clemens builtin-remote.c | 8 ++++---- t/t5505-remote.sh | 10 ...

With the --squash option, merge sets up the index just like for a real merge, but without the merge info (stages). Say so. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> --- I think this kind of fell under the rug back then when it was discussed (http://permalink.gmane.org/gmane.comp.version-control.git/119185). So I'm resending it. Cheers, Michael Documentation/merge-options.txt | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git ...

If all you're looking for is a "single set of read-only docs" conglomeration of all the KDE submodules projects documentation so you can translate them, what about using "archive"? Since archive takes a "tree-ish", and work on remote upload-pack servers (if it's enabled), you can get an un-versioned "remote partial checkout" with something like do things like: git archive --format=tar --prefix=git/Documentation/ --remote=git://repo.or.cz/git.git HEAD:Documentation | tar tf - | head git archive ...

Thanks. --

I don't know. I had assumed a safety valve we put in git-am might need to be matched in rebase. But I don't recall whether I have screwed myself in the same way with rebase. Perhaps because rebase happens on a detached HEAD, I tend to notice sooner that something is not right. -Peff --

I do not see it as a major downside, but not telling them that they may --

No, that would defeat the purpose. The problem is that we have no idea what has happened since the initial "git am". The user may have made commits they want to keep, and we don't want to reset those away. They may even have pulled, which means ORIG_HEAD can no longer be trusted for I think you raise a good point here. If we do decide to stop doing the reset automatically, it is probably better not to simply stop doing it (as my patch does), but to downgrade it to a warning ("You probably ...

Hi, Hmm. I think I would revert that patch after merging git.git right away. Can you at least check for a dirty tree and reset --hard if it is clean? In the other case, you could still say "you seem to have modifications, bla bla bla"... Ciao, Dscho --

Ah, maybe that's the difference. rebase seems to detach the HEAD, then do a bunch of stuff, then reset the original branch only when it's done. So aborting doesn't reset any branches at all, it just checks out the original branch. Thus one option would be to try to make am more like rebase: detach the HEAD before it starts, and reattach it only on success. At least then you only have one set of UI problems to fix. (Of course, I've gotten myself into trouble anyway by checking new stuff ...

cat-file with an object on the command line requires an option to tell it what to output (type, size, pretty-print, etc). However, the square brackets in the usage imply that those options are not required. This patch switches them to parentheses to indicate "required but grouped-OR" (curly braces might also work, but this follows the convention used already by "git stash"). While we're at it, let's change the <sha1> specifier in the usage to <object>. That's what the documentation uses, ...

Back in history, ce_path_match() was first introduced in commit fdee7d07ba6c79b3e5125e96adbe1d9c3e75ce1d, in diff-cache.c. It seems to be used to handle pathspec that we have today. But it did not support wildcards. About one year later, match_pathspec() was introduced as match() in commit 0d78153952e70c21e94dc6b7eefcb2ac5337a902, builtin-add.c. This version supported wildcards. For some reasons diff code did not get converted to use match_pathspec(). So diff commands do not understand ...

No, to my knowledge Apple FileMerge isn't open source either and it's supported. Cheers, Wincent --

Hi, Well, I think it is the first closed-source tool that we support, and I would feel less unhappy if somebody reported back that she tested it and it works fine. For the future, it might be better if mergetool could be configured using /etc/gitconfig to call the merge helper properly. Then we would not need to clutter git.git with properietary stuff, but could just have the Windows-specific handling in Git for Windows. Ciao, Dscho --

I have the same reservations. When I first picked up mergetool it supported ecmerge. ecmerge is also closed which is why I reasoned that it was ok to try and win over Windows users. It should be possible to configure it today using /etc/gitconfig, so we might be best served going down the add-an-entry-to-the-git-wiki route next time; provided Windows paths and shell-quoting doesn't drive us mad when writing it, of course ;) -- David --

Your only option may be to use git filter-branch then. It lets you do pretty much anything you want, although merging it back together again could be entertaining. (Making it correctly mergeable is by far the git subtree manipulates only commit objects (and a reference to the single tree object representing the subtree in each commit) so it's very fast and doesn't depend on file sizes or number of files. Basically git subtree split is O(n) in the number of *commits* since the most recent ...

I think you would want to use git-ls-files, using --exclude-from=<file> option, and perhaps also -i/--ignored to create list of files to be What git-filter-branch does is to write _new_ history, and move old history to refs/original/* namespace (that might have changed; anyway the old history should be available via reflog). The visible efect Yes, it would... well, you have to take into account that ordinary clone over local filesystem does hardlinking of packfiles, and you need to use ...

Since the .gitignore format supports !, I believe that should not make Yes, sure, and that is why I asked whether there is some tool in git that can give a list of concrete files surviving a .gitignore list of Thanks. OK, I see now that filter-branch will not destroy the original repository. That is not at all obvious from reading the man page, when the very first sentence says that it will rewrite history. But the main point of this exercise is to reduce the size of the reduced repository ...

Are you sure you want to define the list with exclusions instead of inclusions? I don't really know your use case. Anyway, if you're using git filter-branch, it'll be up to you to fix the index to contain the list of files you want. (See man You probably need to read about the differences between git trees, blobs, and commits. You're not actually "copying" anything; you're just creating some new directory structures that contain the *existing* blobs. And of course the existing blobs ...

Hi, Maybe mention here that it just so happens that when there were no changes in base->local, it does not matter what changes (_if any_) were made to base->remote, we should output the remote version. Took me more than 2 seconds to find that out, so let's spare the occasional reader this time (2 seconds is my attention span). Your fix is correct. Ciao, Dscho --

This was spotted by someone on stackoverflow.com. It seems that git merge-file will wipe the merged file in the degenerate case when all the inputs have identical contents. As far as I can tell this is a bug, albeit one which will never be triggered in practice because merge-file won't ever be called on files that are identical in base, local and remote versions. I think that the problem is just an overzealous null check in xdl_merge. Certainly with the fix, the test suite still passes ...

xdl_merge used to have a check to ensure that there was at least some change in one or other side being merged but this suppressed output for the degenerate case when base, local and remote contents were all identical. Removing this check enables correct output in the degenerate case and xdl_free_script handles freeing NULL scripts so there is no need to have the check for these calls. Signed-off-by: Charles Bailey <charles@hashpling.org> --- xdiff/xmerge.c | 32 ...

We have "index ..." and other metainformation (most noticeable when renames and mode changes are involved) before any hunk begins. POSIX unified context format of course would not know about them either. In the context of git, file modification time often does not have a defined meaning. If you are comparing two arbitrary tree objects (or two arbitrary blob objects), there is no concept of "timestamp of the preimage and the postimage". If you are comparing two commits, you _could_ show the ...

Hi, Both solutions require refactoring and new code that is abled to walk the DAG mercurial gives us since in both cases we'd need to find the fork point. I don't know mercurials good enough to say if and how much its API can help here. I don't use git any longer and do only fix obvious breakages for hg-fast-export, read: since this is a new feature I'm afraid I won't implement it. Rocco --

Hi, I'm afraid there's nothing you can do except a) wait until somebody with push access to the repo merges or b) do that yourself. The error means that on a branch there's more than one head (i.e. childless revision). There's no equivalent concept in git which is why I don't know what to do. Generating fake branch names for git may be a little messy I think. Rocco --

You can use the object name of the empty tree with diff-* in that case, that's what the pre-commit.sample hook does. Björn --

I'm one of those people :) Writing git support for IDEs is quite tricky at times, and status check was one of quite unpleasant experiences. BTW git-diff won't work in situation when the directory was just initialized and there were no commit. In that case added file = staged file and it is possible to use git-ls-files. Constantine --

There is no need to introduce any new program, I think. Nobody is against your teaching the "git am" callchain to accept things other than Berkeley mbox. "git am" is "import-patches" in that sense already. You can add a conditional (perhaps triggered by a "the patches are in this format" command line option) to "git am" to alter the way it splits the input into individual pieces of e-mail, named 0001, 0002, 0003, ..., and leaves the total number of message in $dotest/last. Currently we ...

I like this idea. I like the idea of git subtree in general. :) however, we've decided to go the "copy all documentation into svn" route for now (so that the translators can keep using only svn). I'll be back when we run into the next svn-external issue (there's sure to be more). :) -- This message brought to you by eevil bananas and the number 3. www.chani3.com

We have DIFF_XDL_TST these days; while it is currently equivalent to what you do here, I thought part of the purpose was to abstract it to make it simpler to later add master/slave magic. -Peff --

I just read through the series, and it looks sane to me. My only concern would be that we are forgetting some option that needs to disable the optimization (in the same way that find-copies-harder) does, but I couldn't think of one. And that is, after all, what cooking it in next is for. :) But I am not terribly familiar with the cache-trees corner of the code, so take my endorsement with a grain of salt. There is a minor typo in the subject of 2/5. -Peff --

Never mind about this one. It is broken with /usr/ucb/touch (because it uses "-r"), but I usually do my auto-builds with /usr/bin/touch (I just noticed it because I was testing by hand). -Peff --

OK. I'll give that a shot. I would still like to know what went wrong with my own sources though. After all I am going to be using it with my own sources. --

Sorry for the delay, Here's hopefully the final patch: Collapse double slashes to make patches like this work with --index or --cached: git apply --index <<-EOF --- a/perl//Git.pm +++ b/perl//Git.pm @@ -1358,3 +1358,4 @@ 1; # Famous last words +# test EOF Signed-off-by: Michal Marek <mmarek@suse.cz> --- builtin-apply.c | 28 ++++++++++++++++++++++------ 1 files changed, 22 insertions(+), 6 deletions(-) diff --git a/builtin-apply.c b/builtin-apply.c index ...

It's cross compiler 4.3. Will try the patch. -- Duy --

This doesn't happen for me: neither with Windows's original snprintf nor with the version from compat/. Are you using the latest msysgit environment to compile, i.e. gcc 4.4? There was a change regarding SNPRINTF_SIZE_CORR; perhaps that's the culprit? I don't undertand what this patch does, anyway. Where is the detail that I They also pass for me with your earlier fix-up patch, but with or without --

Thanks. --

I see a recursion here. Could this not overflow the stack if there is a long ancestry chain? -- Hannes --

Well, in the scenario I described earlier, the project developers (your "average users") _do_ have push access to the submodules. And that scenario For the purposes of this discussion, this is pretty close to the use case I described earlier in my scenario as well. Thanks, Avery, for presenting the Yes, and I have never argued that your "average users" should use 'merge'. Indeed I have not argued that 'merge' is suitable for your workflow _at_ _all_. One of the guiding principles I ...

Hi, Well, that is probably because you are not forced by me to use submodules. Because in the project I use submodules most heavily, there is one recurring theme: you cannot push to the submodules. And by "you" I mean "a regular user". So virtually all you do in these submodules cannot be pushed at all. It has to be submitted to the respective submodule maintainer. And guess what happens in such a case when you set that tentative "update" variable to "merge"? Exactly. FWIW ...

On Mon, May 25, 2009 at 2:57 PM, Johannes Schindelin I have the same problem. Out of curiosity, how do you handle the case where you really need to make a change to the submodule and let your team members see that change, even though the submodule's upstream is slow and/or doesn't accept the patch? In that situation, we've had to make local shared mirrors of all the submodules and point .gitmodules at that. But that would be your "toy" scenario - our local users have push access to the ...

I suggest the default should be whatever "git submodule update" does today, which is what I've called 'checkout' above (i.e. it simply checks out the submodule commit, which naturally detaches the head). If you prefer, I can split my previous patch in two; one that fixes the config variable, and one that adds "submodule update --merge", so that they can be evaluated separately. Hmm? Have fun! :) ...Johan -- Johan Herland, <johan@herland.net> www.herland.net --

Unfortunately, this change breaks MinGW git because the absolute path that this produces is MSYS-style /c/path/to/repo, but git does not understand this; it should be c:/path/to/repo. This value is ultimately assigned to GIT_DIR, but the path name mangling that usually happens when an MSYS program (like perl) spawns a non-MSYS program (like git) does not happen. Your commit message is quite vague about the problems that you have seen. I vote to revert this change. -- Hannes --

Thanks. --

One of the ways that locking might fail is that there is a DF conflict between two refs (e.g., you want to lock "foo/bar" but "foo" already exists). In this case, we return an error, but there is no way for the caller to know the specific problem. This patch sets errno to ENOTDIR, which is the most sensible code. It's what we would see if the refs were stored purely in the filesystem (but these days we must check the namespace manually due to packed refs). Signed-off-by: Jeff King ...