[PATCH] doc: format-patch: fix typo
reroll count documentation states that v will be pretended to the
filename. Judging by the examples that should have been 'prepended'.
Signed-off-by: Frans Klaver
---
Documentation/git-format-patch.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-format-patch.txt
b/Documentation/git-format-patch.txt
index bb3ea93..0dac4e9 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -170,7 +170,7 @@ will want to ensure that threading is disabled for `git
send-email`.
-v ::
--reroll-count=::
Mark the series as the -th iteration of the topic. The
- output filenames have `v` pretended to them, and the
+ output filenames have `v` prepended to them, and the
subject prefix ("PATCH" by default, but configurable via the
`--subject-prefix` option) has ` v` appended to it. E.g.
`--reroll-count=4` may produce `v4-0001-add-makefile.patch`
--
2.4.0
--
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: [PATCH] Fix bash completion when `egrep` is aliased to `egrep --color=always`
On Mon, Nov 26, 2012 at 12:23 PM, Adam Tkac wrote: > Good idea, thanks. Improved patch is attached. It is custom on this list to mail the patches, rather than attaching them, so people can review your changes in-line. You can read more about it in in git/Documentation/SubmittingPatches. Cheers, Frans -- 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 1.8.0.rc0.18.gf84667d trouble with "git commit -p file"
On Fri, 05 Oct 2012 16:20:45 +0200, Horst H. von Brand wrote: What I did: - New file images/coins.asy ~~-> 'git add images/coins.asy' - Started adding new stuff to fg.tex - Noticed a old bug in fg.tex, fixed that one - Did 'git -pm "Some message"' and selected just the bugfix But git created a commit _including_ the new file. Tried to go back: Exactly what's supposed to happen. "git add" tells git you want to add the file to the index. The index is what you're going to commit later on. So what you did there was - Tell git to add images/coins.asy to the next commit - hack hack hack - fix old_bug - Add old_bug chunks of code to next commit && create commit - 'git reset HEAD^' Now the new file isn't staged anymore What I expected to happen: - Only the explicitly selected chunks commited - No "losing staged changes" As explained above, you didn't lose staged changes, you staged more changes and committed. Then you use git reset to go back to the state of HEAD^, where the file wasn't tracked and therefore not staged either. So you're back at square one[1], commit the bug fix, then add the bugfixes in a commit and stage the new file for inclusion in your next commit. Hope this helps, Frans [1] Arguably two, since you still have changes lying around. -- 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 gui does not open bare repositories
Hi, Please remember to reply to all when discussing things on the git mailing list. On Fri, Sep 28, 2012 at 10:29 AM, Angelo Borsotti wrote: > Hello > > I apologise for having used the wrong script to reproduce the error. > This is the right one: > > angelo@ANGELO-PC /d/gtest (master) > $ mkdir remote.git > > angelo@ANGELO-PC /d/gtest (master) > $ cd remote.git > > angelo@ANGELO-PC /d/gtest/remote.git (master) > $ git init --bare > Initialized empty Git repository in d:/gtest/remote.git/ > > Now with the git gui I try to open the d:/gtest/remote.git/ and > receive the message > that it is not a git repository. > > I understand that the gui is mostly aimed to non-bare repositories, > but in such a case > it would be better it could give me a message like, e.g. "could not > open a bare repository" > instead of telling me that it is not a git repository (I thought my > bare repository was > corrupt, and tried to figure out what was wrong with it). Actually git-gui 0.16.0 is telling me that it cannot use bare repositories, much in the vein of what I wrote earlier. Don't know if it matters that I'm on Linux though. Frans -- 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 gui does not open bare repositories
On Fri, Sep 28, 2012 at 9:50 AM, Angelo Borsotti wrote: > I have created a bare repository: > > $ mkdir remote.git > > angelo@ANGELO-PC /d/gtest (master) > $ git init --bare > Initialized empty Git repository in d:/gtest/ This creates a bare repository in d:/gtest, not in d:/gtest/remote.git. You'll need to cd into remote.git to create a bare repo. > and then tried to open it with the git gui, but have got the message: > "remote.git is not a git repository". So this message is correct. Be as it may, as soon as you've initialized the repo as required, git gui will (probably) tell you: "Cannot use bare repository: d:/gtest/remote.git" So nothing gained there. So I'm wondering what you expect git gui to give you in a bare repo? It seems to me that this tool is specifically aimed at non-bare repos, allowing for creating commits, merges and whatnot; all things you cannot typically do in a bare repo. Frans -- 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 die message written to stdout?
On Wed, 26 Sep 2012 18:01:39 +0200, 乙酸鋰 wrote: Is git die() messages written to stdout? Should it be written to stderr? As far as I know git die() routines write their output to stderr. Do you have an indication that that might not be the case? Frans -- 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 -- 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: Broken git-svn tests known?
On Wed, Aug 1, 2012 at 1:44 AM, Ammon Riley wrote: > Hi, > > On a freshly checked out copy of the maint branch (0e4c8822), the > t9100-git-svn-basic.sh tests are failing 21 of 25 tests. Is this > known, or am I missing some dependencies? Is it possibly due to > using subversion 1.7? Yes, and work is done on it as we speak[1]. > I've run into a small bug with git-svn, and wanted to make sure > the test suite still passed with my patch applied. You would probably have to base your work on this work in progress, or test with svn 1.6 for the time being. [1] http://thread.gmane.org/gmane.comp.version-control.git/202419 -- 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
