Git commit list
Good day, everyone. I have some kind of a confusion here, explained it in details here: http://stackoverflow.com/questions/11289124/git-commit-list but didn't get any answers, maybe someone could give me a hint about that?-- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git with uucp for deployment
Randal L. Schwartz schrieb: I am unaware of *anyone* using uucp these days, UUCP over TCP/IP is still in use for transmission of mail and Usenet news. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: congif spec in GIT
Radu Manea skrev 2012-07-06 13.46: Hi, Thank you for the detailed presentation posted on git.or.cz site. One question: is there any equivalent config spec file for GIT as is in ClearCase today? Repo (http://source.android.com/source/version-control.html) is perhaps the tool that is most similar in functionality to the config spec. It allows you to perform operations over multiple repositories. -- robin -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Egit/Jgit support for relocated .git directories
Chris Packham skrev 2012-06-26 10.18: Hi, This is a bit of a secondhand bug report/query so sorry if the details are a bit sketchy. Since git 1.7.8: ``When populating a new submodule directory with git submodule init, the $GIT_DIR metainformation directory for submodules is created inside $GIT_DIR/modules/name/ directory of the superproject and referenced via the gitfile mechanism. This is to make it possible to switch between commits in the superproject that has and does not have the submodule in the tree without re-cloning.'' I've had several colleagues at work tell me that with the relocated $GIT_DIR the Egit integration with eclipse doesn't work. I can't really qualify doesn't work but from what I've been told importing the project works but blaming/annotating doesn't. I believe the gitfile mechanism isn't new but it possibly hasn't been used by many Egit/Jgit users. Can anyone confirm if it is supported by Egit/Jgit (and I'm barking up the wrong tree). It is supported. There is however a commit as late as in May that relates to gitfile, so you may need 2.0. -- robin -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/2] rm: don't fail when removing populated submodules
Am 06.07.2012 08:57, schrieb Junio C Hamano: Jens Lehmann jens.lehm...@web.de writes: Also apply the same policy as for regular files and require forcing when the submodules HEAD is different than what is recorded in the index. I think the policy for regular files is that git rm $path errors out to avoid losing information in $path. Even if the HEAD in the submodule points at the same commit as recorded in the index, if the submodule directory has other changes that (cd $path git status) would report, we would not want to remove it, no? I am not sure if the difference between $path/.git/HEAD and :$path (the version in the index) matters. Maybe it does, maybe it doesn't. Doh. I don't know how I got the idea it would be so, but a quick test with checkout and rebase showed they ignore if a submodules HEAD is different from the commit recorded. So plain rm should do the same as long as it doesn't touch the submodule work tree and I'll remove checking the HEAD from patch 1. I'll prepare v2 which will also include an updated commit message. One possible sane behaviour of git rm $path might be: - If --force is given, remove it from the index and from the working tree (i.e. rm -rf $path), but use the gitfile facility to save $path/.git away to $GIT_DIR/modules/$name; error out if the submodule directory $path cannot be removed like this. We would probably want to remove submodule.name.* entries in .gitmodules for name for which submodule.name.path matches the $path. - If --cached is given, remove it from the index if the version in the index match either HEAD or the $path/.git/HEAD, without touching the working tree. This is consistent with what happens to a regular file. - If neither --force nor --cached is given, run an equivalent of (cd $path git status), and also check if $path/.git/HEAD matches the index version. Error out if the submodule directory is dirty (again I am not sure about this part). If the submodule directory is clean, do the same as the case with --force. What you describe here is exactly how I think git submodule rm and git rm --recurse-submodules should behave. The questions remaining for me are: * What should a git rm --no-recurse-submodules do? I think it should try to follow the policy git core commands use: - don't touch the submodule's work tree - remove the submodule directory if it is empty and warn if not (currently it dies if not, to change that to a warning is the subject of patch 1) The more difficult question is if it should remove the submodule entry from .gitmodules (patch 2). As that file is part of the superproject's work tree and core git already learned to read configuration options for status, diff and fetch from it I think it's a good idea to help the user by doing so (but maybe we should make this configurable and/or add an option to enable/disable it). But on the other hand maybe users expect this only to happen when they use git submodule rm and git rm should leave .gitmodules alone? * What should the default behavior of git rm be. I tend to think that as all other core git commands never manipulate a submodule's work tree without the --recurse-submodules option, rm should do the same. So I think we should default to the --no-recure-submodules case described above to not surprise the user. That makes checking the submodule for modifications unnecessary until the --recure-submodules option is implemented. Does that make sense? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: congif spec in GIT
On 06.07.12 13:46, Radu Manea wrote: Hi, Thank you for the detailed presentation posted on git.or.cz site. One question: is there any equivalent config spec file for GIT as is in ClearCase today? There are similarities, and differences between git and ClearCase, I can only point out the very basic differences, because the philosophy of these 2 tools is completely different. CC has a virtual file system, often mounted on /vobs on Unix, and M:\ (or another drive name) on Windows. CC simulates a file system, where files are seen according to the config spec. Changing the config spec will change the version of the files seen under /vobs immediately. If you want a copy of all the files on your local disk, you need to create a snapshot view. After changing the config spec, the snapshot view needs to be updated. git always has a working tree, similar to a snapshot view (except for bare repositories, they correspond to a CC server) CC uses branches git uses branches CC uses labels git uses commit ids, A tag may point to a commit id CC defines for each file/directory which label is used When a file is checked out, a branch is created for that file element different directories may use different branches - git uses the same branch for the whole repo CC uses labels for each directory, whatever the config spec say for that very directory. - git uses a commit id as a base for that branch. So if try to transform a branch in git into a config spec, we do: $ git status # On branch my_feature_branch (and that branch is defined on the whole working tree, similar to /vobs/projects/git/tb) If I open the engine bonnet of git, to see what that means technically, I run on the command line: $ cat .git/HEAD ref: refs/heads/my_feature_branch (we are on branch my_feature_branch) When I dig further: $ cat .git/refs/heads/my_feature_branch a5b0a8ff7f48cfd5ea19712680c64a029e99c2ba We see that my branch is taking commit a5b08ff7 as a base line So a config spec could include 3 lines, kind of all files are CHECKOUT/CHECKIN All files are based on commit id a5b0a8ff7f48cfd5ea19712680c64a029e99c2ba If you commit one or more files at once, they are recorded on branch my_feature_branch HTH /Torsten -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
bug report: git status --porcelain inconsistent quoting
mkdir D cd D git init Initialized empty Git repository in /tmp/D/.git/ echo 1 with space git status --porcelain ?? with space NO QOUTES git add with\ space git status --porcelain A with space - WITH QOUTES git --version git version 1.7.9.7 git config -l |grep quote core.quotepath=on -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] test: git-stash conflict sets up rerere
Add a failing test to confirm a conflicted stash apply invokes rerere to record the conflicts and resolve the the files it can. In this failing state, mergetool may be confused by a left-over state from previous rerere activity. Also, the next test expected us to finish up with a reset, which is impossible to do if we fail (as we must) and it's an unreasonable expectation anyway. Begin the next test with a reset of his own instead. Signed-off-by: Phil Hord ho...@cisco.com --- t/t7610-mergetool.sh | 40 1 file changed, 40 insertions(+) diff --git a/t/t7610-mergetool.sh b/t/t7610-mergetool.sh index f5e16fc..c9f2fdc 100755 --- a/t/t7610-mergetool.sh +++ b/t/t7610-mergetool.sh @@ -55,6 +55,16 @@ test_expect_success 'setup' ' git rm file12 git commit -m branch1 changes +git checkout -b stash1 master +echo stash1 change file11 file11 +git add file11 +git commit -m stash1 changes + +git checkout -b stash2 master +echo stash2 change file11 file11 +git add file11 +git commit -m stash2 changes + git checkout master git submodule update -N echo master updated file1 @@ -193,7 +203,37 @@ test_expect_success 'mergetool skips resolved paths when rerere is active' ' git reset --hard ' +test_expect_failure 'conflicted stash sets up rerere' ' +git config rerere.enabled true +git checkout stash1 +echo Conflicting stash content file11 +git stash + +git checkout --detach stash2 +test_must_fail git stash apply + +test -e .git/MERGE_RR +test -n $(git ls-files -u) +conflicts=$(git rerere remaining) +test $conflicts = file11 +output=$(git mergetool --no-prompt) +test $output != No files need merging + +git commit -am save the stash resolution + +git reset --hard stash2 +test_must_fail git stash apply + +test -e .git/MERGE_RR +test -n $(git ls-files -u) +conflicts=$(git rerere remaining) +test -z $conflicts +output=$(git mergetool --no-prompt) +test $output = No files need merging +' + test_expect_success 'mergetool takes partial path' ' +git reset --hard git config rerere.enabled false git checkout -b test12 branch1 git submodule update -N -- 1.7.11.1.213.gb567ea5.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] stash: invoke rerere in case of conflict
'stash apply' directly calls a backend merge function
which does not automatically invoke rerere. This
confuses mergetool when leftover rerere state is left
behind from previous merges.
Invoke rerere explicitly when we encounter a conflict
during stash apply
Change the test for this flaw to expect success.
Signed-off-by: Phil Hord ho...@cisco.com
Mentored-by: Junio C Hamano gits...@pobox.com
---
git-stash.sh | 1 +
t/t7610-mergetool.sh | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/git-stash.sh b/git-stash.sh
index 4e2c7f8..bbefdf6 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -469,6 +469,7 @@ apply_stash () {
else
# Merge conflict; keep the exit status from merge-recursive
status=$?
+ git rerere
if test -n $INDEX_OPTION
then
gettextln Index was not unstashed. 2
diff --git a/t/t7610-mergetool.sh b/t/t7610-mergetool.sh
index c9f2fdc..419cc38 100755
--- a/t/t7610-mergetool.sh
+++ b/t/t7610-mergetool.sh
@@ -203,7 +203,7 @@ test_expect_success 'mergetool skips resolved paths when
rerere is active' '
git reset --hard
'
-test_expect_failure 'conflicted stash sets up rerere' '
+test_expect_success 'conflicted stash sets up rerere' '
git config rerere.enabled true
git checkout stash1
echo Conflicting stash content file11
--
1.7.11.1.213.gb567ea5.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] stash: invoke rerere in case of conflict
[PATCH v2 1/2] test: git-stash conflict sets up rerere A rewritten failing test to verify rerere is used during 'stash apply' conflicts. [PATCH v2 2/2] stash: invoke rerere in case of conflict The fix (written entirely by JCH) and switched the test to expect success. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Restore umasks influence on the permissions of work tree created by clone
The original (shell coded) version of the git-clone just used mkdir(1) to create the working directories. The builtin changed the mode argument to mkdir(2) to 0755, which was a bit unfortunate, as there are use cases where umask-controlled creation is preferred and in any case it is a well-known behaviour for new directory/file creation. --- On Fri, 6 Jul 2012, Daniel Barkalow wrote: On Fri, 6 Jul 2012, Alex Riesen wrote: when git-clone was built in, its treatment of umask has changed: the shell version respected umask for newly created directories by using plain mkdir(1), and the builtin version just uses mkdir(work_tree, 0755). Is it intentional? I have the vague feeling that it was intentional, but it's entirely plausible that I just overlooked that mkdir(2) applies umask and went for the mode that you normally want. I don't think there's any particular need for this operation to be more restrictive than umask. I didn't look hard enough, but still, I found not much of complaining either way (frankly - none, but as I said, I didn'l look hard): none before - for being too permissive, the only one in original post after building the thing in - for being too restrictive. Maybe we should reconsider and go back to the old permission handling? builtin/clone.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/clone.c b/builtin/clone.c index d3b7fdc..e314b0b 100644 --- a/builtin/clone.c +++ b/builtin/clone.c @@ -708,7 +708,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix) if (safe_create_leading_directories_const(work_tree) 0) die_errno(_(could not create leading directories of '%s'), work_tree); - if (!dest_exists mkdir(work_tree, 0755)) + if (!dest_exists mkdir(work_tree, 0777)) die_errno(_(could not create work tree dir '%s'.), work_tree); set_git_work_tree(work_tree); -- 1.7.11.1.185.g5abe2c9 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
