git is in the process of moving subcommands to /usr/libexec/git-core This move breaks an assumption in guilt about the location of git-sh-setup. We can ask git for where it thinks its executables live. Signed-off-by: Alex Chiang <achiang@hp.com> --- diff --git a/guilt b/guilt index 50414a4..ba4593a 100755 --- a/guilt +++ b/guilt @@ -23,7 +23,7 @@ esac # we change directories ourselves SUBDIRECTORY_OK=1 -. git-sh-setup +. `git --exec-path`/git-sh-setup # # Git version ...

Hi! I'm tracking a subversion repository which is running on a windows machine with git-svn. The user names look like DOMAIN\username and that's giving a strange display in gitk as the backslash sequence is evaluated. I'm not sure if I found the correct place to prevent this, so I'd like to ask if the following change would be the correct thing to prepare as patch... ciao, Torsten. diff --git a/gitk-git/gitk b/gitk-git/gitk index fddcb45..f114fa2 100644 --- a/gitk-git/gitk +++ b/gi...

Hi, Somewhat related to the recent thread about Apache Synapse, I'm having trouble making a git-svn clone of a project that has been moved around in a Subversion repository. See the script at the end of this message for a simple test case that does the following svn commits: PREPARE: creates projectA with the standard trunk,branches,tags structure VERSION1: first version of README.txt in projectA/trunk TAG1: tags projectA/trunk to projectA/tags/v1 MOVE: moves projectA to proje...

Mentored-by: Christian Couder <chriscool@tuxfamily.org> Mentored-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Stephan Beyer <s-beyer@gmx.net> --- Documentation/git-sequencer.txt | 673 +++++++++++++++++++++++++++++++++++++++ 1 files changed, 673 insertions(+), 0 deletions(-) create mode 100644 Documentation/git-sequencer.txt diff --git a/Documentation/git-sequencer.txt b/Documentation/git-sequencer.txt new file mode 100644 index 0000000..8a701c4 --- /dev/null ...

Hi, the following patches migrate git-am and git-rebase--interactive to git-sequencer. But there are some issues I want to mention. I've compared performance of original rebase and am with the sequencer-based ones and the sequencer-based ones perform fairly bad. For example, applying 45 patches with git-am took 3 seconds using the original and 8 seconds using the sequencer-based one. Rebasing 100 commits takes 10.1 seconds instead of only 4.8 seconds on my test machine. I expect that the b...

Currently, aborting a git-am process during a conflict is done by resetting to the HEAD before applying the patches and removing the .git/rebase directory manually. This patch introduces an --abort option for git-am to make this as easy as in git-rebase. Mentored-by: Christian Couder <chriscool@tuxfamily.org> Mentored-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Stephan Beyer <s-beyer@gmx.net> --- Documentation/git-am.txt | 5 ++++- Documentati...

Full copy detection can take quite some time on large repositories, which substantially decreases perceived usability of the 'git gui blame' command. This set of patches tries to overcome it by: 1) Allowing the user to disable '-C -C' and/or set the detection threshold. 2) Explicitly killing back-end processes, which don't produce any output during copy detection, and thus normally won't receive SIGPIPE until it is finished. Runaway processes are annoying. 3) To compensate for (1), adding a...

Currently 'git-gui blame' does not kill its back-end process, hoping that it will die anyway when the pipe is closed. However, in some cases the process works for a long time without producing any output. This behavior results in a runaway CPU hog. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> --- The -f flag is necessary for msysgit. For this fix I submitted to msysgit a patch that includes a Cygwin-compatible kill.exe in the installer. -- Alexander git-gui.sh ...

Apply the work-around for checking the executable permission of hook files not only on Cygwin, but on Windows in general. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> --- This is a fix for msysgit issue #118. (http://code.google.com/p/msysgit/issues/detail?id=118) I've already sent this patch, but resend it as I haven't received any reply, and it is not in git-gui.git yet. -- Alexander git-gui.sh | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff...

The message length depends on the length of the branch name. In my case, the branch name "origin/add-chickens2" put the first line of the "your branch has diverged" message over 80 characters, which triggered "less -FS" to not exit automatically as expected. This patch puts the newlines in slightly different places to reduce the probability of this happening. Now you'd need a significantly longer branch name to trigger the problem. Signed-off-by: Avery Pennarun <apenwarr@gmail.com> --- ...

Personally, I would be fine with shorter messages; this doesn't seem the best time to report the name of the tracked branch anyhow. I use 80x24 terminals too most of the time. However, I didn't write the original patch either, and I recall that this feature was so popular that it actually resulted in a list thread Well, the fact that the number of commits is "variable" isn't so important, unless you start diverging by 1e9 commits or something :) It might be nice to minimize the amount of stat...

The following series implements submodule support in git mv and git rm, plus enhancing the submodules testsuite a bit. I'd appreciate comments, especially on the git mv change, since the index_path_src_sha1 is really a horrible hack. The pinnacle of this series was supposed to be merge-recursive support for submodule-somethingelese conflicts, however that seems a bit more complicated than I expected, so I decided to first send the rest for a review. --- Petr Baudis (7): t7403: Submodul...

This patch adds support for removing submodules to 'git rm', including removing the appropriate sections from the .gitmodules file to reflect this Signed-off-by: Petr Baudis <pasky@suse.cz> --- Documentation/git-rm.txt | 6 +++- builtin-rm.c | 65 ++++++++++++++++++++++++++++++++++++++-------- 2 files changed, 58 insertions(+), 13 deletions(-) diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt index 4d0c495..bfc3dfa 100644 --- a/Documentation/git-rm.txt ...

The interface will be used for git-mv and git-rm submodule support. So far, only the submodule_by_path() function is defined, however more can be probably expected in the future if/when the git-submodule command is ported from shell. Signed-off-by: Petr Baudis <pasky@suse.cz> --- Makefile | 2 ++ submodule.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++ submodule.h | 8 ++++++++ 3 files changed, 60 insertions(+), 0 deletions(-) create mode 100644 submodule.c cre...

This patch fixes git submodule add behaviour when we add submodule living at a same path as logical name of existing submodule. This can happen e.g. in case the user git mv's the previous submodule away and then git submodule add's another under the same name. A test-case is obviously included. This is not completely satisfactory since .git/config cross-commit conflicts can still occur. A question is whether this is worth handling, maybe it would be worth adding some kind of randomization of the...

The path list builder had a branch for the case the source is not in index, but this can happen only if the source was a directory. However, in that case we have already expanded the list to the directory contents and set mode to WORKING_DIRECTORY, which is tested earlier. The patch removes the superfluous branch and adds an assert() instead. git-mv testsuite still passes. Signed-off-by: Petr Baudis <pasky@suse.cz> --- builtin-mv.c | 16 +++++++--------- 1 files changed, 7 insertions...

This probably is a borderline with feaping creaturism. What's the use of it in a real workflow that you need this for? "git add -u" may be too broad in that it also adds anything modified, but so is --if-missing too broad in that it removes anything removed, and if you are going to limit by giving pathspecs _anyway_, then... Old timers might just do: git diff --name-only --diff-filter=D | git update-index --remove --stdin Not your fault in entirety, but we should drop these " =...

Wouldn't: git rm $(git ls-files --deleted) do the trick, or am I missing something? Regards, David -- David Christensen End Point Corporation david@endpoint.com --

I see the idea here: right now you can do: touch a b c git add . And have it auto-add all the new files, so "git commit" will work. But there is no equivalent for rm, because for obvious reasons, rm b c git rm . Doesn't do the same thing. And "git add ." doesn't auto-recognize deletions, which probably also makes sense. "git commit -a", on the other hand, will automatically commit all deletions for you. But you don't always want to commit *all* your ...

The grep selection at compile time is purely a choice between "no external grep at all" and "whatever external grep is in $PATH". exec_grep() literally does .. pid = fork(); if (pid < 0) return pid; if (!pid) { execvp("grep", (char **) argv); exit(255); } .. so you can choose your version of external grep at run-time by just setting PATH appropriately. Or you can just decide that you don't want to use any external grep binary at all, which is the compile-time c...

Hi, there have been a number of occasions where I came across people trying to be helpful and teaching Git newbies a few tricks. However, in quite a number of cases, which seem to surge over the last weeks, I see people suggesting the use of rev-parse, ls-tree, rev-list etc. Their rationale is invariably "but I found it useful", and they seem to be unable to recognize the puzzlement in the faces of the people they are trying to help. Instead they insist that they did nothing wrong. ...

Hi, So you would say that remembering the name "rev-parse" is just as easy as remembering "show"? You want to say that --keep-dash-dash and --stat are on the same level, since both work? Somehow I don't think so. Ciao, Dscho --

Hi, In this case, I have to add that it is natural because it is the way you _have_ to do it. Even if the other SCMs hide it. You almost never commit a full revision. You usually update just a couple of files. Now, even CVS has an extra command to add a file, so it accepts the fact that staging and committing are two different operations, even if "cvs add" does not stage the changes of a tracked file. Of course, it is easier for us: we can use all the lessons learnt from Heh. I ...

Hi, I agree that if you know Git internals -- and you and me do -- it comes in _right_ handy to know the 100+ commands with many options by heart. However, my point was about telling users, especially new ones. For example, I would _never_ suggest the following workflow to a n00b because it would be confusing: $ tar xvf <xyz> <try to compile> <fix a compile error> <fix other things> <oh, I could contribute the fixes!> $ git init $ git remote add -...

Well, Git is not the easiest tool on the market to learn. For people used to centralized systems such as RCS/CVS/Subversion, many concepts are truly alien. I've recently experienced a transition at our company from MKS/SI (a RCS derivative) to Subversion, and the mental gap was for many users HUGE. Had we done the transition from MKS/SI to Git, I'm sure several user's brains would have exploded. From my perspective, the concept I found most difficult to grasp at the very beginning was ho...