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

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

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

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

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

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

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

[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

[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

[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

[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