Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'.
The tip of 'master' has been tagged as 1.7.12-rc0; this deliberately
contains a few topics that have been in 'next' only for a few days,
so plea
A release candidate Git v1.7.12-rc0 is now available for testing
at the usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
09016e819a69b49090756e9bc5c97a4df25c2f78 git-1.7.12.rc0.tar.gz
e85ad0780ff81eacdb05a10762
I have noticed that
git pull --quiet
is actually only "quiet" if no problems are found
If unmerged error occurs, output is seen on BOTH stdout and stderr
$ git pull -q >/dev/null
Pull is not possible because you have unmerged files.
Please, fix them up in the work tree, and then use 'gi
On Tue, Jul 24, 2012 at 2:08 AM, Thomas Gummerer wrote:
> - We added a POC, for partial loading in git grep. This is still a
> pretty hacky implementation, but it demonstrates pretty well
> how much can be gained. Here are the timings Thomas posted on
> IRC yesterday. The improvements of ls-
Jens Lehmann writes:
> Not inside the submodule, me thinks they only make sense in the
> superproject (that's why we clean the environment before working
> inside the submodule).
Yes, that is fundamental and the only sane behaviour that comes from
what submodules are. They are free-standing pro
Stefano Lattarini writes:
> ... and here we should add "invocation":
>
> ... the "make install" invocation ...
>
>> falls back to the default prefix of '$HOME', thus installing git
>> in the user's home directory -- definitely unexpected.
>
> Can you fix those nits locally before merging to '
Hi Junio. I've just noticed a minor typo in the commit message ...
On 07/19/2012 09:50 AM, Stefano Lattarini wrote:
> This provides a reduced but still useful sibling of the Automake's
> "automatic Makefile rebuild" feature. It's important to note that
> we take care to enable the new rules only
Am 23.07.2012 22:34, schrieb Junio C Hamano:
> Jens Lehmann writes:
>
>> We could get rid of the core.worktree setting by assuming that the
>> directory a gitfile was found in is the root of the repo's work
>> tree (unless configured otherwise).
>
> Now you lost me. If you have .git that is not
Hi Junio.
On 07/19/2012 09:50 AM, Stefano Lattarini wrote:
> Those filed
>
Oops, this should read "files", not "filed" ...
> hold variables, settings and information set by the
> configuration process run by './configure'; in Autotools-based
> build system that kind of stuff should only be remove
On 24.07.2012 00:41, Junio C Hamano wrote:
> + if test -f $(dirname "$(type --path compare)")/AraxisMerge
We would need additional quotes around the whole path here as the Windows
installation path is usually something like "C:\Program Files\Araxis\Araxis
Merge" and contains spaces.
Junio C Hamano writes:
> If we limit the problem space by special casing Windows installation
> (e.g. check "uname -s" or something), would it make the problem
> easier to solve? Perhaps it is much more likely that the path the
> program is installed in can be safely identified with a call to
>
On Tue, Jul 24, 2012 at 12:22 AM, Junio C Hamano wrote:
> On the other hand, if the user has bought and installed Araxis, but
> we incorrectly identify it as unusable, the user has wasted good
> money and there is no easy recourse as far as I can see in your
> patch.
Agreed.
> If we limit the p
Sebastian Schuberth writes:
> On Mon, Jul 23, 2012 at 11:16 PM, Junio C Hamano wrote:
>
>> There are only five or six classes of environment that matter in the
>> real world for the purpose of giving "well known" examples: Windows,
>> MacOS X, Gnome, KDE and Linux terminal. By picking a represe
Junio C Hamano skrev 2012-07-22 23.08:
Thomas Rast writes:
Hum, I'm a bit lost now.
What is the status quo? I take it JGit does not have any of ctime, dev,
ino etc., and either leaves the existing value or puts a 0
an argument in favor of splitting stat_crc into its fields again?
A dif
Sebastian Schuberth writes:
> Personally, I've valued the gain of
> the patch to not list araxis as an available diff tool by "git
> difftool --tool-help" when in fact just ImageMagick is in PATH higher
> than the loss to support araxis installations that are in a path not
> containung "araxis" b
Jeff King writes:
> On Mon, Jul 23, 2012 at 02:35:01PM -0700, Junio C Hamano wrote:
> ...
>> I also wondered if something like the following might be useful, but
>> it probably falls into the "water under the bridge" category.
>>
>> builtin/commit.c | 5 +
>> 1 file changed, 5 insertions(+)
On Mon, Jul 23, 2012 at 11:34 PM, David Aguilar wrote:
> Sebastian, are you testing on Windows? The araxis "compare" I used is
> OS X. Does "compare version" open a GUI window for you? For me it
> does not.
> What about "compare -h", or just "compare" ?
Yes, I'm testing on Windows, and unfort
On Mon, Jul 23, 2012 at 02:35:01PM -0700, Junio C Hamano wrote:
> > +FILES
> > +-
> > +
> > +`$GIT_DIR/COMMIT_EDITMSG`::
> > + This file contains the commit message of a commit in progress.
> > + If `git-commit` exits due to an error before creating a commit,
> > + any commit message tha
Jeff King writes:
> Here's a documentation patch.
>
> -- >8 --
> Subject: [PATCH] commit: document the temporary commit message file
>
> We do not document COMMIT_EDITMSG at all, but users may want
> to know about it for two reasons:
>
> 1. They may want to tell their editor to configure itself
On Mon, Jul 23, 2012 at 2:24 PM, Junio C Hamano wrote:
> Sebastian Schuberth writes:
>
>> We have no such assurance. That's why you correctly call it a
>> heuristics after all
>
> ImageMagick "compare" takes "--version" and says something like
> this to its standard output:
>
> $ compare --ve
On Mon, Jul 23, 2012 at 11:24 PM, Junio C Hamano wrote:
> Does Araxis compare take "--version" and behave in a way that is
> cheaply controllable? If it opens a GUI window and pops up a dialog
> that says "Option not understood", then it is not "controllable",
Araxis opens up a GUI dialog with
On Mon, Jul 23, 2012 at 11:16 PM, Junio C Hamano wrote:
> There are only five or six classes of environment that matter in the
> real world for the purpose of giving "well known" examples: Windows,
> MacOS X, Gnome, KDE and Linux terminal. By picking a representative
> one from each and listing
Sebastian Schuberth writes:
> Please feel free to ignore the patch if you feel the heuristics is not
> sufficiently safe. I'm currently unable to come up with a safer
> solution while maintaining portability, i.e. not use "which" or doing
> rather laborious string parsing on the output of "type".
Sebastian Schuberth writes:
> We have no such assurance. That's why you correctly call it a
> heuristics after all
ImageMagick "compare" takes "--version" and says something like
this to its standard output:
$ compare --version
Version: ImageMagick 6.6.0-4 2012-05-02 Q16
http://www.
David Aguilar writes:
> On Mon, Jul 23, 2012 at 1:14 PM, Sebastian Schuberth
> wrote:
>> On Mon, Jul 23, 2012 at 9:52 PM, Junio C Hamano wrote:
>>
-t ::
--tool=::
- Use the diff tool specified by . Valid values include
- emerge, kompare, meld, and vimdiff. Run `gi
On Mon, Jul 23, 2012 at 02:00:19PM -0700, Junio C Hamano wrote:
> >> Liberal use of atexit() for something like this makes me cringe
> >> somewhat.
> >
> > I don't like it either, but there's not really a better way. The die()
> > that Ramana triggered in the initial report is deep inside the iden
On Mon, Jul 23, 2012 at 10:47 PM, Junio C Hamano wrote:
> For example, when the user tells it to install in "/home/ss/bin", if
> it installs its "compare" program in "/home/ss/bin/araxis/compare"
> without allowing the "/araxis/" part to be stripped away, the above
> heuristics is sufficiently sa
Jeff King writes:
> On Mon, Jul 23, 2012 at 01:49:55PM -0700, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > If we launch an editor for the user to create a commit
>> > message, they may put significant work into doing so.
>> > Typically we try to check common mistakes that could cause
>>
On Mon, Jul 23, 2012 at 01:51:25PM -0700, Junio C Hamano wrote:
> > diff --git a/builtin/commit.c b/builtin/commit.c
> > index 95eeab1..20cef95 100644
> > --- a/builtin/commit.c
> > +++ b/builtin/commit.c
> > @@ -725,7 +725,7 @@ static int prepare_to_commit(const char *index_file,
> > const char
On Mon, Jul 23, 2012 at 01:49:55PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > If we launch an editor for the user to create a commit
> > message, they may put significant work into doing so.
> > Typically we try to check common mistakes that could cause
> > the commit to fail early,
Jeff King writes:
> Incidentally, this bug was masked prior to 060d4bb, as the
> initial loose call would taint the later strict call. So the
> commit would succeed (albeit with a bogus committer line in
> the commit object), and nobody noticed that our early check
> did not match the later one.
Jeff King writes:
> If we launch an editor for the user to create a commit
> message, they may put significant work into doing so.
> Typically we try to check common mistakes that could cause
> the commit to fail early, so that we die before the user
> goes to the trouble.
>
> We may still experi
Sebastian Schuberth writes:
> Signed-off-by: Sebastian Schuberth
> ---
> mergetools/araxis | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/mergetools/araxis b/mergetools/araxis
> index 64f97c5..f8899f8 100644
> --- a/mergetools/araxis
> +++ b/mergetools/araxis
>
On Mon, Jul 23, 2012 at 1:14 PM, Sebastian Schuberth
wrote:
> On Mon, Jul 23, 2012 at 9:52 PM, Junio C Hamano wrote:
>
>>> -t ::
>>> --tool=::
>>> - Use the diff tool specified by . Valid values include
>>> - emerge, kompare, meld, and vimdiff. Run `git difftool --tool-help`
>>> -
Florian Achleitner writes:
> To ease testing without depending on a reachable svn server, this
> compact python script mimics parts of svnrdumps behaviour.
> It requires the remote url to start with sim://.
> Eventual slashes at the end of the url are stripped.
s/ventual/xcess/ perhaps?
> The u
Jens Lehmann writes:
> We could get rid of the core.worktree setting by assuming that the
> directory a gitfile was found in is the root of the repo's work
> tree (unless configured otherwise).
Now you lost me. If you have .git that is not a directory but is a
gitfile, then you do not need GIT_
On Mon, Jul 23, 2012 at 9:52 PM, Junio C Hamano wrote:
>> -t ::
>> --tool=::
>> - Use the diff tool specified by . Valid values include
>> - emerge, kompare, meld, and vimdiff. Run `git difftool --tool-help`
>> - for the list of valid settings.
>> + Use the diff tool specified
To ease testing without depending on a reachable svn server, this
compact python script mimics parts of svnrdumps behaviour.
It requires the remote url to start with sim://.
Eventual slashes at the end of the url are stripped.
The url specifies the path of the svn dump file (as created by
svnrdump)
Am 23.07.2012 20:21, schrieb Junio C Hamano:
> Jens Lehmann writes:
>
>> Am 23.07.2012 07:09, schrieb Junio C Hamano:
>>> Daniel Graña writes:
>>>
A common way to track dotfiles with git is using GIT_DIR and
GIT_WORK_TREE to move repository out of ~/.git with something like:
On Mon, Jul 23, 2012 at 09:46:49PM +0200, Matthieu Moy wrote:
> > Damn. That's usually no problem with kmail either, if the config is right.
> > I've already used git-send-email several times.
> > But for replying to threads and adding several Cc: addresses it's a little
> > cumbersome.
> > How d
Sebastian Schuberth writes:
> This way we do not have to risk the list of tools go out of sync
> between the implementation and the documentation. Adjust the documentation
> accordingly to not explicitly list the tools but refer to --tool-help.
>
> Signed-off-by: Junio C Hamano
> Signed-off-by:
Florian Achleitner writes:
> On Monday 23 July 2012 18:24:40 Matthieu Moy wrote:
>> You also have whitespace damages (i.e. line wrapping introduced by your
>> mailer). Using git-send-email avoids this kind of problem (there are
>> also some advices for some mailers in Documentation/SubmittingPatc
Signed-off-by: Sebastian Schuberth
---
mergetools/araxis | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/mergetools/araxis b/mergetools/araxis
index 64f97c5..f8899f8 100644
--- a/mergetools/araxis
+++ b/mergetools/araxis
@@ -16,5 +16,12 @@ merge_cmd () {
}
translat
On Monday 23 July 2012 18:24:40 Matthieu Moy wrote:
> You also have whitespace damages (i.e. line wrapping introduced by your
> mailer). Using git-send-email avoids this kind of problem (there are
> also some advices for some mailers in Documentation/SubmittingPatches).
Damn. That's usually no pro
Max Horn writes:
>>
> On 06.07.2012, at 21:18, Junio C Hamano wrote:
>
>> Max Horn writes:
>>
> +'{caret}!', e.g. 'HEAD{caret}!'::
> + A suffix '{caret}' followed by an exclamation mark
> + means commit '' but forces all of its parents to be excluded. For
> + commands that d
== Work done in the previous 13 weeks ==
- Definition of a tentative index file v5 format [1]. This differs
from the proposal in making it possible to bisect the directory
entries and file entries, to do a binary search. The exact bits
for each section were also defined. To further compress
On 23.07.2012 20:37, Junio C Hamano wrote:
This patch makes sense to me, but at the same time makes [PATCH 1/5]
a "Meh", methinks.
Yeah, I can see why. So I've renamed __git_mergetools_common to
__git_diffmerge_tools and squashed with [PATCH 1/5] to make it
less "Meh" as it does not stand on i
This way we do not have to risk the list of tools go out of sync
between the implementation and the documentation. Adjust the documentation
accordingly to not explicitly list the tools but refer to --tool-help.
Signed-off-by: Junio C Hamano
Signed-off-by: Sebastian Schuberth
---
Documentation/g
On 23.07.2012 19:21, Junio C Hamano wrote:
> This way we do not have to risk the list of tools go out of sync
> between the implementation and the documentation.
>
> Signed-off-by: Junio C Hamano
Thanks! I've squashed this with
[PATCH v2 5/5] Add a few more code comments and blank lines in gue
If we launch an editor for the user to create a commit
message, they may put significant work into doing so.
Typically we try to check common mistakes that could cause
the commit to fail early, so that we die before the user
goes to the trouble.
We may still experience some errors afterwards, thou
The identity of the committer will ultimately be pulled from
the ident code by commit_tree(). However, we make an attempt
to check the author and committer identity early, before the
user has done any manual work like inputting a commit
message. That lets us abort without them having to worry
about
The advise() function takes a variable number of arguments
and converts them into a va_list object to pass to strbuf
for handling. However, we accidentally called strbuf_addf
(that takes a variable number of arguments) instead of
strbuf_vaddf (that takes a va_list).
This bug dates back to v1.7.8.1
On Mon, Jul 23, 2012 at 01:27:26PM -0400, Jeff King wrote:
> On Sat, Jul 21, 2012 at 03:26:26PM +0100, Ramana Kumar wrote:
>
> > If I forget to set user.email and user.name config options and do a commit
> > (possibly the --amend option also required to make this show up), then git
> > 1.7.11.2 w
"abhisek...@gmail.com" writes:
> Now I cannot delete this branch. Running:
> git branch -d --tracking
> gives an error: unknown option `tracking'
I do not think this is supposed to work, but it does by accident.
$ git branch -d -- --tracking
Deleted branch --tracking (was 8670e20).
A m
Sebastian Schuberth writes:
>> This patch makes sense to me, but at the same time makes [PATCH 1/5]
>> a "Meh", methinks.
>
> Yeah, I can see why. So I've renamed __git_mergetools_common to
> __git_diffmerge_tools and squashed with [PATCH 1/5] to make it
> less "Meh" as it does not stand on its o
John Bartholomew writes:
> I find the output of `git branch' to be quite bare, and would like to
> see more information; most importantly, what the state of the branch
> is in relation to its upstream.
That is already present: just run git branch -vv.
--
Thomas Rast
trast@{inf,student}.ethz.ch
Hi,
I am a new user to git and I found an interesting behavior in git. I
am not sure if this is a bug, but I thought I would report this
anyway!
So I can create a local branch called "--tracking" like this:
git checkout -b --tracking origin/somebranch
I messed up the syntax while trying to create
Also, add a few comments that clarify the meaning of these variables and
sort the list of tools alphabetically.
Signed-off-by: Sebastian Schuberth
---
contrib/completion/git-completion.bash | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/contrib/completion/gi
On 23.07.2012 18:46, Junio C Hamano wrote:
>> +# Tools that support both merging and diffing.
>> __git_mergetools_common="araxis bc3 diffuse ecmerge emerge gvimdiff
>> kdiff3 meld opendiff p4merge tkdiff vimdiff xxdiff
>> "
>
> As the set of merge capable tools is not a s
PPS: Yes, I know that I am replying in a patch thread. I will try it asap.
--
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
On Mon, Jul 23, 2012 at 7:09 AM, Junio C Hamano wrote:
> I think this is in line with what we discussed earlier on list when
> the interaction between GIT_DIR/GIT_WORK_TREE and submodules came up
> the last time. Jens?
Yes, it is.
I still have your email marked as TODO to get back to you as I
On Mon, Jul 23, 2012 at 2:38 PM, Jens Lehmann wrote:
> Am 23.07.2012 07:09, schrieb Junio C Hamano:
>> Daniel Graña writes:
>>
>>> A common way to track dotfiles with git is using GIT_DIR and
>>> GIT_WORK_TREE to move repository out of ~/.git with something like:
>>>
>>> git init --bare ~/.do
Jens Lehmann writes:
> Am 23.07.2012 07:09, schrieb Junio C Hamano:
>> Daniel Graña writes:
>>
>>> A common way to track dotfiles with git is using GIT_DIR and
>>> GIT_WORK_TREE to move repository out of ~/.git with something like:
>>>
>>> git init --bare ~/.dotfiles
>>> alias dotfiles=
I find the output of `git branch' to be quite bare, and would like to
see more information; most importantly, what the state of the branch
is in relation to its upstream. For some time I have been using my
own script to do this. It produces output like this:
$ git lsb
commodity-market-lua [behin
On Mon, Jul 23, 2012 at 6:27 PM, Jeff King wrote:
> On Sat, Jul 21, 2012 at 03:26:26PM +0100, Ramana Kumar wrote:
>
>> If I forget to set user.email and user.name config options and do a commit
>> (possibly the --amend option also required to make this show up), then git
>> 1.7.11.2 will drops me
Am 23.07.2012 07:09, schrieb Junio C Hamano:
> Daniel Graña writes:
>
>> A common way to track dotfiles with git is using GIT_DIR and
>> GIT_WORK_TREE to move repository out of ~/.git with something like:
>>
>> git init --bare ~/.dotfiles
>> alias dotfiles="GIT_DIR=~/.dotfiles GIT_WORK_TR
On Sat, Jul 21, 2012 at 03:26:26PM +0100, Ramana Kumar wrote:
> If I forget to set user.email and user.name config options and do a commit
> (possibly the --amend option also required to make this show up), then git
> 1.7.11.2 will drops me into an editor for a commit message, then after that
> co
This way we do not have to risk the list of tools go out of sync
between the implementation and the documentation.
Signed-off-by: Junio C Hamano
---
Junio C Hamano writes:
>> +--tool-help::
>> +List the supported and available diff tools.
>
> This part is a good addition (but it already is
Sebastian Schuberth writes:
> Signed-off-by: Sebastian Schuberth
> ---
> mergetools/araxis | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/mergetools/araxis b/mergetools/araxis
> index 64f97c5..aeba1b9 100644
> --- a/mergetools/araxis
> +++ b/mergetools/araxis
>
Sebastian Schuberth writes:
> Signed-off-by: Sebastian Schuberth
> ---
> Documentation/git-difftool.txt | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt
> index 31fc2e3..5dd54f1 100644
> --- a/Docum
Sebastian Schuberth writes:
> Also, add a few comments that clarify the meaning of these variables.
>
> Signed-off-by: Sebastian Schuberth
> ---
> contrib/completion/git-completion.bash | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/contrib/completion/git-c
David Aguilar writes:
> Teach difftool's --dir-diff mode to use symlinks to represent
> files from the working copy, and make it the default behavior
> for the non-Windows platforms.
>
> Using symlinks is simpler and safer since we do not need to
> worry about copying files back into the worktree
Florian Achleitner writes:
> I had to fix the missing sign-off anyways..
>
> contrib/svn-fe/svnrdump_sim.py | 53
>
You also have whitespace damages (i.e. line wrapping introduced by your
mailer). Using git-send-email avoids this kind of problem (there
Florian Achleitner writes:
> It requires the remote url to start with sim://.
> Start and end revisions are evaluated.
It is a bit unclear where "start" and "end" comes from, and if
"evaluated" is the most important aspect of the handling of these
two values. Do you mean the tool takes start an
To ease testing without depending on a reachable svn server, this
compact python script mimics parts of svnrdumps behaviour.
It requires the remote url to start with sim://.
Start and end revisions are evaluated.
If the requested revision doesn't exist, as it is the case with
incremental imports, i
On Monday 23 July 2012 07:59:21 Jonathan Nieder wrote:
> Florian Achleitner wrote:
> > To ease testing without depending on a reachable svn server, this
> > compact python script mimics parts of svnrdumps behaviour.
>
> Thanks. Mind if I forge your sign-off?
Ups. No problem, anyways I've added i
Florian Achleitner wrote:
> To ease testing without depending on a reachable svn server, this
> compact python script mimics parts of svnrdumps behaviour.
Thanks. Mind if I forge your sign-off?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord..
To ease testing without depending on a reachable svn server, this
compact python script mimics parts of svnrdumps behaviour.
It requires the remote url to start with sim://.
Start and end revisions are evaluated.
If the requested revision doesn't exist, as it is the case with
incremental imports, i
Florian Achleitner wrote:
> But when I fetch from a git repo that imported from svn, the notes are not
> fetched automatically. In this case I currently loose marks and notes.
> What can I do?
In the long term, git will need to be tweaked to automatically fetch
notes along with branches by defau
Matthieu Moy wrote:
> The man page for git-remote-helpers says:
>
> refspec
> [...] It is recommended that all importers providing the import
> capability use this.
>
> I'm not sure I fully understand the rationale, but one difference
> between refs//* and refs/remotes/ is that
> refs/rem
On Sunday 22 July 2012 23:03:27 Florian Achleitner wrote:
> This got stuck on another problem:
> Incremental update of the note tree doesn't work. fast-import refuses to
> update the notes tree: ' doesn't contain '.
> I don't yet know what's the reason for this.
> I'm digging into the internals of
On Sunday 22 July 2012 16:43:33 Jonathan Nieder wrote:
> Hi,
>
> Florian Achleitner wrote:
> > After several mailing iterations, showing me that I was wrong, I found
> > what
> > the right point is, namely that the remote helper writes references to a
> > really private dir in refs//, it doesn't t
Hello,
Egit is not a part of git. It's not developed by the git developers, so this
question is not really fit for this mailing list. You'd have to ask the
Eclipse developers why it's not included.
Ikke
On Fri, Jul 20, 2012 at 11:51 PM, Eugene Sajine wrote:
>
> Hi,
>
> I have a strong impressio
2012/7/23 Nguyen Thai Ngoc Duy :
> On Mon, Jul 23, 2012 at 2:32 PM, Jiang Xin wrote:
>> If build git with GETTEXT_POISON and test, lots of test cases failed.
>> It seems that we haven't run these test cases for i18n for a long time.
>
> Gaah.. I should have resent the poison-fix series but so far
Florian Achleitner writes:
> But my remote-helper didn't advertise the refspec capability, so transport-
> helper assumed it imports to refs/heads/master, which is the default import
> refspec.
The man page for git-remote-helpers says:
refspec
[...] It is recommended that all importers pr
Dan Johnson writes:
> On Tue, Jul 17, 2012 at 10:06 AM, Matthieu Moy wrote:
>> Traditionnally, pages named Foo:Bar are page 'Bar' in namespace 'Foo'.
>> However, it is also possible to call a page Foo:Bar if 'Foo' is not a
>> namespace. In this case, the actual name of the page is 'Foo:Bar', in
Signed-off-by: Sebastian Schuberth
---
Documentation/git-difftool.txt | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt
index 31fc2e3..5dd54f1 100644
--- a/Documentation/git-difftool.txt
+++ b/Documentation
On Mon, Jul 23, 2012 at 2:32 PM, Jiang Xin wrote:
> If build git with GETTEXT_POISON and test, lots of test cases failed.
> It seems that we haven't run these test cases for i18n for a long time.
Gaah.. I should have resent the poison-fix series but so far
procrastination is winning. Will do it s
Signed-off-by: Sebastian Schuberth
---
git-mergetool--lib.sh | 6 ++
1 file changed, 6 insertions(+)
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index ed630b2..ac9a8f0 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -112,14 +112,17 @@ run_merge_tool () {
}
2012/7/23 Junio C Hamano :
>> I find one test case failed, and correct it in PATCH 3/7.
>
> That test used i18ncmp already, so the update to expected string
> would be sufficient. I was worried if there were existing tests
> that have been expecting that the output from am/rebase/merge would
> not
Signed-off-by: Sebastian Schuberth
---
mergetools/araxis | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/mergetools/araxis b/mergetools/araxis
index 64f97c5..aeba1b9 100644
--- a/mergetools/araxis
+++ b/mergetools/araxis
@@ -16,5 +16,11 @@ merge_cmd () {
}
translate
Signed-off-by: Sebastian Schuberth
---
contrib/completion/git-completion.bash | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 5be9dee..f2c4894 100755
--- a/contrib/completion/git-complet
2012/7/23 Sitaram Chamarty :
> On Mon, Jul 23, 2012 at 2:24 AM, Junio C Hamano wrote:
>> mer...@stonehenge.com (Randal L. Schwartz) writes:
>>
"Darek" == Darek Bridges writes:
>>>
>>> Darek> I use git for many things, but I am trying to work out the
>>> Darek> workflow to use git for dep
Also, add a few comments that clarify the meaning of these variables.
Signed-off-by: Sebastian Schuberth
---
contrib/completion/git-completion.bash | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-com
This series introduces various minor clean-ups and improvements to the merge /
diff tool scripts and documentation.
Sorry, the first version was missing a patch.
Sebastian Schuberth (5):
Sort the list of tools that support both merging and diffing
alphabetically
Use variables for the lis
This series introduce various minor clean-ups and improvements to the merge /
diff tool scripts and documentation.
Sebastian Schuberth (4):
Use variables for the lists of tools that support merging / diffing
Explicitly list all valid diff tools and document --tool-help as an
option
Make
96 matches
Mail list logo
