JH> git cherry-pick master..origin/master
Thanks Johan.
--
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
From: Johannes Sixt
MSYS bash interprets the slash in the argument core.commentchar="/"
as root directory and mangles it into a Windows style path. Use a
different core.commentchar to dodge the issue.
Signed-off-by: Johannes Sixt
---
t/t6200-fmt-merge-msg.sh | 6 +++---
1 file changed, 3 inser
On Thu, Apr 18, 2013 at 7:18 AM, Ilya Basin wrote:
> I asked this on stackoverflow, but no reply.
> http://stackoverflow.com/questions/15971244/git-put-their-commits-after-my-commits-with-a-single-rebase-command
>
> Suppose master and origin/master diverged.
> I'm on master and I want to put the c
Am 4/18/2013 7:18, schrieb Ilya Basin:
> desired result:
>
> A---B---C origin/master
> /
> D---E---F---G---A'---B'---C' *master
>
>
>
> Variant 1:
>
> git branch -f tmp
> git reset --hard origin/master
> git rebase tmp
Variant 1a:
git reset --hard origin/m
On Thu, Apr 18, 2013 at 1:06 AM, Felipe Contreras
wrote:
> git fast-import expects an extra newline after the commit message data,
> but we are adding it only on hg-git compat mode, which is why the
> bidirectionality tests pass.
>
> We should add it unconditionally.
This doesn't depend on any ot
git fast-import expects an extra newline after the commit message data,
but we are adding it only on hg-git compat mode, which is why the
bidirectionality tests pass.
We should add it unconditionally.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-hg | 3 ++-
1 file chang
I asked this on stackoverflow, but no reply.
http://stackoverflow.com/questions/15971244/git-put-their-commits-after-my-commits-with-a-single-rebase-command
Suppose master and origin/master diverged.
I'm on master and I want to put the commits from origin/master after my commits
and then push --f
Just shuffle the die() part to make it more explicit, and cleanup the
code-style.
Signed-off-by: Felipe Contreras
---
transport-helper.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/transport-helper.c b/transport-helper.c
index 573eaf7..9d31f2d 100644
--- a/transpo
When pushing, the remote namespace is updated correctly
(e.g. refs/origin/master), but not the remote helper's
(e.g. refs/testgit/origin/master), which currently is only updated while
fetching.
Since the remote namespace is used to tell fast-export which commits to
avoid (because they were already
For the modes that need it. In the future we should probably error out,
instead of providing half-assed support.
The reason we want to do this is because if it's not present, the remote
helper might be updating refs/heads/*, or refs/remotes/origin/*,
directly, and in the process fetch will get con
The refspec capability is not only used by 'import', also by 'export',
and it's recommend in both.
Signed-off-by: Felipe Contreras
---
Documentation/gitremote-helpers.txt | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/gitremote-helpers.txt
b/Documen
This has never worked, since it's inception the code simply skips all
the refs, essentially telling fast-export to do nothing.
Let's at least tell the user what's going on.
Signed-off-by: Felipe Contreras
---
Documentation/gitremote-helpers.txt | 4 ++--
t/t5801-remote-helpers.sh | 6
The *:* refspec doesn't work, and never has, clarify the code and
documentation to reflect that. This in effect reverts commit 9e7673e
(gitremote-helpers(1): clarify refspec behaviour).
Signed-off-by: Felipe Contreras
---
Documentation/gitremote-helpers.txt | 4 ++--
t/t5801-remote-helpers.sh
Hi,
Same as before, but with a small bug fix, and minor test improvements.
It seems the workings of transport-helper are anything but clear, so let's try
to clarify them a bit, and after that, hopefully it would become clearer why
the last patch is actually a good fix.
Felipe Contreras (6):
tr
On Wed, Apr 17, 2013 at 7:05 PM, Felipe Contreras
wrote:
> --- a/t/t5801-remote-helpers.sh
> +++ b/t/t5801-remote-helpers.sh
> @@ -153,4 +153,16 @@ test_expect_success 'push ref with existing object' '
> compare_refs local dup server dup
> '
>
> +test_expect_success 'push update refs' '
On Wed, Apr 17, 2013 at 6:56 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> And how do you know this will be part of the 1%? You don't. How many
>> times have you tracked regressions in transport helper's import/export
>> functionality? How many times in remote-hg? How many times has
>
Make "git add ..." notice paths that have been removed
from the working tree, i.e. a synonym to "git add -A ...".
Given that "git add " is to update the index with the
state of the named part of the working tree as a whole, it makes it
more intuitive, and also makes it possible to simplify the adv
Drew Northup writes:
>> That makes it sound like the "per instance overrides common overrides
>> built-in" cascading is what is unusual and what we need to apologize
>> for.
>
> I don't think were apologizing for anything. It is helpful to say "we
> do some things differently here and don't plan
Jeff King writes:
> Yeah, I had the same thought, as this warning has been bugging me for
> the last day or two. The worst part about it is that I finally trained
> myself to type "git add ." to silence the _other_ warning, and now it
> triggers this one. :)
So here is the "reworked" one on top
On Tue, Apr 16, 2013 at 6:26 PM, Jonathan Nieder wrote:
> Drew Northup wrote:
>
>> This is unobtrusive yet to the point.
>
> I agree with the spirit.
>
> [...]
>> --- a/Documentation/gitweb.conf.txt
>> +++ b/Documentation/gitweb.conf.txt
>> @@ -55,7 +55,8 @@ following o
On Wed, Apr 17, 2013 at 5:05 PM, Felipe Contreras
wrote:
> This has never worked, since it's inception the code simply skips all
> the refs, essentially telling fast-export to do nothing.
Makes sense.
--
Cheers,
Sverre Rabbelier
--
To unsubscribe from this list: send the line "unsubscribe git"
"Philip Oakley" writes:
> How about
>* E.g. git gui uses the extended regular expression "^git version
> [1-9]+(\.[0-9]+)+.*"
>* to check for an acceptable version string.
>
> The ERE is from git-gui.sh:L958.
That is exactly the kind of guarantee we do _not_ want to give.
> ... Hence my
Just shuffle the die() part to make it more explicit, and cleanup the
code-style.
Signed-off-by: Felipe Contreras
---
transport-helper.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/transport-helper.c b/transport-helper.c
index 573eaf7..9d31f2d 100644
--- a/transpo
When pushing, the remote namespace is updated correctly
(e.g. refs/origin/master), but not the remote helper's
(e.g. refs/testgit/origin/master), which currently is only updated while
fetching.
Since the remote namespace is used to tell fast-export which commits to
avoid (because they were already
This has never worked, since it's inception the code simply skips all
the refs, essentially telling fast-export to do nothing.
Let's at least tell the user what's going on.
Signed-off-by: Felipe Contreras
---
Documentation/gitremote-helpers.txt | 4 ++--
t/t5801-remote-helpers.sh | 6
For the modes that need it. In the future we should probably error out,
instead of providing half-assed support.
The reason we want to do this is because if it's not present, the remote
helper might be updating refs/heads/*, or refs/remotes/origin/*,
directly, and in the process fetch will get con
The *:* refspec doesn't work, and never has, clarify the code and
documentation to reflect that. This in effect reverts commit 9e7673e
(gitremote-helpers(1): clarify refspec behaviour).
Signed-off-by: Felipe Contreras
---
Documentation/gitremote-helpers.txt | 4 ++--
t/t5801-remote-helpers.sh
The refspec capability is not only used by 'import', also by 'export',
and it's recommend in both.
Signed-off-by: Felipe Contreras
---
Documentation/gitremote-helpers.txt | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/gitremote-helpers.txt
b/Documen
Hi,
It seems the workings of transport-helper are anything but clear, so let's try
to clarify them a bit, and after that, hopefully it would become clearer why
the last patch is actually a good fix.
Felipe Contreras (6):
transport-helper: clarify *:* refspec
transport-helper: update refspec d
Felipe Contreras writes:
> And how do you know this will be part of the 1%? You don't. How many
> times have you tracked regressions in transport helper's import/export
> functionality? How many times in remote-hg? How many times has
> *anybody* done so?
The last point makes it all the more impo
From: "Ramkumar Ramachandra"
Sent: Wednesday, April 17, 2013 12:56 PM
We've been over this several times in earlier emails. [...]
Again, I'm not saying that my approach is Correct and Final. What I'm
saying is: "Here's what I've done. Something interesting is going on.
It's probably worth
From: "Junio C Hamano"
Sent: Tuesday, April 16, 2013 11:35 PM
"Philip Oakley" writes:
int cmd_version(int argc, const char **argv, const char *prefix)
{
+ /*
+ * The format of this string should be kept stable for
compatibility
+ * with external projects that rely on the output of "git vers
Christian Stimming writes:
> Thanks for the regular update! This is great work.
>
> One issue with the plural form messages, though:
>
> Am Montag, 15. April 2013, 18:27:40 schrieb Ralf Thielow:
>> #: bundle.c:186
>> -#, fuzzy, c-format
>> +#, c-format
>> msgid "The bundle contains this ref:"
>
On Thu, Apr 18, 2013 at 1:02 AM, Ramkumar Ramachandra
wrote:
>> No, the point is people make mistakes. What do we do in that case? Or
>> will you introduce yet another "gc" command for clean up ~/bare?
>
> So, people don't make mistakes when they use 'git submodule add', but
> do make mistakes whe
Junio C Hamano writes:
>> Do we want to use approxidate_careful here to catch other junk?
>
> We can catch a misspelt argument or configuration value that way.
> That would be a good idea.
-- >8 --
Subject: date.c: add parse_expiry_date()
"git reflog --expire=all" tries to expire reflog entries
On Sat, Apr 6, 2013 at 12:13 PM, John Keeping wrote:
> --- a/Documentation/gitremote-helpers.txt
> +++ b/Documentation/gitremote-helpers.txt
> @@ -174,8 +174,8 @@ ref.
> This capability can be advertised multiple times. The first
> applicable refspec takes precedence. The left-hand of refspec
Forrest Galloway writes:
> git 1.8.2.1 on OSX(Mountain Lion) installed with Homebrew
>
> I am seeing an issue when trying to format the output from rev-list command.
> git log --pretty=format:"%H - %an, %ar : %s" When I attempt the above
> string, instead of printing to the shell, LESS is opened
Karsten Blees writes:
> I'll send fixups for #11 and #14, or you can pick the entire series rebased
> to pu from:
> https://github.com/kblees/git/tree/kb/improve-git-status-ignored-v2-pu
> git pull git://github.com/kblees/git.git kb/improve-git-status-ignored-v2-pu
Will take a look; very much a
Jeff King writes:
> On Wed, Apr 17, 2013 at 08:33:54PM +0200, René Scharfe wrote:
>
>> Minimal patch, test case missing. It's a bit sad that the old commit
>> parser of blame handled Ivan's specific corruption (extra "-<>" after
>> email) gracefully because it used the spaces as cutting points i
The SVN::Fetcher module is now able to filter for inclusion as well
as exclusion (as used by --ignore-path). Also added tests, documentation
changes and git completion script.
If you have an SVN repository with many top level directories and you
only want a git-svn clone of some of them then using
Am 17.04.2013 01:52, schrieb Junio C Hamano:
>> * jk/submodule-subdirectory-ok (2013-04-10) 2 commits
>> - submodule: drop the top-level requirement
>> - rev-parse: add --prefix option
>>
>> Allow various subcommands of "git submodule" to be run not from the
>> top of the working tree of the su
Am 17.04.2013 23:07, schrieb Jeff King:
On Wed, Apr 17, 2013 at 08:33:54PM +0200, René Scharfe wrote:
Minimal patch, test case missing. It's a bit sad that the old commit
parser of blame handled Ivan's specific corruption (extra "-<>" after
email) gracefully because it used the spaces as cutti
git 1.8.2.1 on OSX(Mountain Lion) installed with Homebrew
I am seeing an issue when trying to format the output from rev-list command.
git log --pretty=format:"%H - %an, %ar : %s" When I attempt the above
string, instead of printing to the shell, LESS is opened and the
output is displayed there.
On Wed, Apr 17, 2013 at 08:33:54PM +0200, René Scharfe wrote:
> Minimal patch, test case missing. It's a bit sad that the old commit
> parser of blame handled Ivan's specific corruption (extra "-<>" after
> email) gracefully because it used the spaces as cutting points instead
> of "<" and ">".
On Wed, Apr 17, 2013 at 09:06:21PM +0200, René Scharfe wrote:
> Am 17.04.2013 20:02, schrieb Jeff King:
> >I think we also need to do something about "git cat-file -p", which does
> >not use the split_ident_line parser (but has its own problems with the
> >home-grown parser).
>
> Ah, while it pri
Am 17.04.2013 07:16, schrieb Junio C Hamano:
> Phil Hord writes:
>
>> On Mon, Apr 1, 2013 at 3:02 PM, Jens Lehmann wrote:
>>> Okay, so here is the patch for that. If someone could point out
>>> a portable and efficient way to check if a directory is already
>>> empty I would be happy to use that
On Wed, Apr 17, 2013 at 11:14:42AM -0700, Junio C Hamano wrote:
> > I think it is just the warning code avoiding extra complexity and
> > overhead, if you are talking about not getting warning in the
> > pre-2.0 step that is in 'next'. Patches are very much welcomed,
> > especially the ones that
'git-status --ignored' still scans the work tree twice to collect
untracked and ignored files, respectively.
fill_directory / read_directory already supports collecting untracked and
ignored files in a single directory scan. However, the DIR_COLLECT_IGNORED
flag to enable this has some git-add spe
Signed-off-by: Karsten Blees
---
builtin/add.c | 5 +---
builtin/check-ignore.c | 16 --
builtin/ls-files.c | 15 +++---
dir.c | 79 --
dir.h | 16 ++
unpack-trees.c | 10 +-
Am 15.04.2013 22:25, schrieb Junio C Hamano:
> Karsten Blees writes:
>
>> Am 15.04.2013 21:33, schrieb Junio C Hamano:
>>> Junio C Hamano writes:
>>>
Karsten Blees writes:
> This patch series addresses several bugs and performance issues in
> .gitignore processing.
A
On Wed, Apr 17, 2013 at 1:36 PM, Felipe Contreras
wrote:
> On Wed, Apr 17, 2013 at 9:10 AM, Torsten Bögershausen wrote:
>> The test cases in contrib/remote-helpers use mercurial and python.
>> Before the tests are run, we check if python can import
>> "mercurial" and "hggit".
>> To run this check
Am 17.04.2013 20:02, schrieb Jeff King:
I think we also need to do something about "git cat-file -p", which does
not use the split_ident_line parser (but has its own problems with the
home-grown parser).
Ah, while it prints commit object contents verbatim, it formats the date
of tags. And it d
On Tue, Apr 16, 2013 at 5:45 PM, Phil Hord wrote:
> On Tue, Apr 16, 2013 at 3:04 PM, Felipe Contreras
> wrote:
>> On Tue, Apr 16, 2013 at 4:59 AM, Thomas Rast wrote:
>>> A cursory look^W^Wreview of the messages in fc/remote-hg:
>>
>> [skipping irrelevant comments]
>>
>> I'm sorry, did you actual
On Wed, Apr 17, 2013 at 9:10 AM, Torsten Bögershausen wrote:
> The test cases in contrib/remote-helpers use mercurial and python.
> Before the tests are run, we check if python can import
> "mercurial" and "hggit".
> To run this check, python pointed out by PYTHON_PATH is used.
> This may not work
split_ident_line() can leave us with the pointers date_begin, date_end,
tz_begin and tz_end all set to NULL. Check them before use and supply
the same fallback values as in the case of a negative return code from
split_ident_line().
The "(unknown)" is not actually shown in the output, though, bec
Centralize the parsing of the date and time zone strings in the new
helper function show_ident_date() and make sure it checks the pointers
provided by split_ident_line() for NULL before use.
Reported-by: Ivan Lyapunov
Signed-off-by: Rene Scharfe
---
The first test case passes on v1.8.1, i.e. it
Junio C Hamano writes:
> Thomas Rast writes:
>
>> I can see that problem, but along the same lines, why shouldn't I have
>> an expectation that when I say 'git add "*.py"' it removes stuff that I
>> have removed?
>
> You _should_ have that expectation.
>
> If it does not remove with the code tha
On Wed, Apr 17, 2013 at 07:59:28PM +0200, René Scharfe wrote:
> >What about sane_ident_split in builtin/commit.c? It explicitly rejects a
> >NULL date. The logic in determine_author_info is a little hard to follow
> >(it assembles the ident line with fmt_ident and then reparses it), but I
> >belie
Am 17.04.2013 08:39, schrieb Jeff King:
On Tue, Apr 16, 2013 at 10:26:40PM -0700, Junio C Hamano wrote:
Junio C Hamano writes:
René Scharfe writes:
How about making split_ident_line() a bit friendlier be letting it
provide the epoch as default time stamp instead of NULL?
Two knee-jerk c
Jeff King writes:
> What about sane_ident_split in builtin/commit.c? It explicitly rejects a
> NULL date. The logic in determine_author_info is a little hard to follow
> (it assembles the ident line with fmt_ident and then reparses it), but I
> believe it should be catching a bogus line from "com
Ramkumar Ramachandra writes:
> 1. Any stash that can be shown can be applied, but not necessarily
> popped or dropped (as the documentation indicates). The reason for
> this is simple: a pop/drop attempts to clear the entry in the stash
> reflog as well, but all stashes need to have a correspond
Duy Nguyen writes:
> No, the point is people make mistakes. What do we do in that case? Or
> will you introduce yet another "gc" command for clean up ~/bare?
I do not know if it will be a "gc", but we would need a way for the
user to say "I no longer need the repository for this submodule kept
l
Thomas Rast writes:
> I can see that problem, but along the same lines, why shouldn't I have
> an expectation that when I say 'git add "*.py"' it removes stuff that I
> have removed?
You _should_ have that expectation.
If it does not remove with the code that has been prepared for 2.0
(that is
Torsten Bögershausen writes:
> The test cases in contrib/remote-helpers use mercurial and python.
> Before the tests are run, we check if python can import
> "mercurial" and "hggit".
> To run this check, python pointed out by PYTHON_PATH is used.
> This may not work when different python binaries
Duy Nguyen writes:
> Somewhat related to the topic. Why can't .gitattributes be used for
> storing what's currently in .gitmodules?
You _could_ use gitattributes to encode, but it goes against what a
gitattributes file does or is for. It is a mechanism to associate
groups of paths (that may not
Junio C Hamano writes:
> Thomas Rast writes:
>
>> The warning triggers in some cases where it shouldn't, relating to
>> submodules:
>>
>> $ git submodule add gito...@git.csa.inf.ethz.ch:domjudge.git domjudge
>> Adding existing repo at 'domjudge' to the index
>> warning: In Git 2.0, 'git ad
Hi,
Torsten Bögershausen wrote:
> Git respects PYTHON_PATH, hg does not.
Probably more relevant is that contrib/remote-helpers/git-remote-hg
has a shebang line of "#!/usr/bin/env python" and hence does not
respect PYTHON_PATH.
> Use python instead of $PYTHON_PATH to check for installed modules.
Ramkumar Ramachandra wrote:
> 2. This ugliness complicates implementation of add/ rm/ mv, because
> each of them will have to know about this contrived path solution.
Why is that? Can't they look at the gitfile or call some helper
(that happens to be part of the same binary)?
--
To unsubscribe f
Am Mittwoch, 17. April 2013, 10:09:29 schrieb Thomas Rast:
> >> > msgid "The bundle contains this ref:"
> >> > msgid_plural "The bundle contains these %d refs:"
> >> >
> >> > -msgstr[0] "Das Paket enthält %d Referenz"
> >> > -msgstr[1] "Das Paket enthält %d Referenzen"
> >> > +msgstr[0] "Das Pak
John Keeping writes:
> On Tue, Apr 16, 2013 at 04:52:14PM -0700, Junio C Hamano wrote:
>> > * jk/remote-helper-with-signed-tags (2013-04-15) 3 commits
>> > - transport-helper: add 'signed-tags' capability
>> > - transport-helper: pass --signed-tags=warn-strip to fast-export
>> > - fast-export:
Duy Nguyen writes:
>> This is to handle a corrupt input, e.g. "%C(auto)%Cbleu%H" where
>> (perhaps deprecated) "%Cblue" is misspelled, and parse_color()
>> returns 0 without consuming any byte.
>>
>> Does it make sense not to turn auto off in such a case?
>
> We don't have any mechanism to report
Thomas Rast writes:
> The warning triggers in some cases where it shouldn't, relating to
> submodules:
>
> $ git submodule add gito...@git.csa.inf.ethz.ch:domjudge.git domjudge
> Adding existing repo at 'domjudge' to the index
> warning: In Git 2.0, 'git add ...' will also update
> the in
Lukas Fleischer writes:
> Not sure if you care but the commit messages of these are all wrong now
> that you squashed your API fix into the first commit. They all refer to
> read_blob_data_from_index_path()...
Ouch; thanks for noticing.
--
To unsubscribe from this list: send the line "unsubscrib
Duy Nguyen wrote:
> Well, it has "submodule" in the command line. My first reaction would
> be looking for "git submodule rm" or something.
No, 'git submodule rm' cannot remove the corresponding GITDIR. What
if there are other branches that refer to the submodule? What if you
want to remove it f
The test cases in contrib/remote-helpers use mercurial and python.
Before the tests are run, we check if python can import
"mercurial" and "hggit".
To run this check, python pointed out by PYTHON_PATH is used.
This may not work when different python binaries exist,
and PYTHON_PATH is not set:
Make
Duy Nguyen wrote:
> On Wed, Apr 17, 2013 at 9:56 PM, Ramkumar Ramachandra
> wrote:
>>> why not reuse tag object with some nea header lines?
>>
>> Or a unified blob, which is currently what we have. The point is to
>> have structured parseable information that the object-parsing code of
>> git cod
On Wed, Apr 17, 2013 at 9:56 PM, Ramkumar Ramachandra
wrote:
>> why not reuse tag object with some nea header lines?
>
> Or a unified blob, which is currently what we have. The point is to
> have structured parseable information that the object-parsing code of
> git code and easily slurp and give
Duy Nguyen wrote:
> Include me to those everyone. url feels like a local thing that should
> not stay in object database (another way of looking at it is like an
> email address: the primary one fixed in stone in commits with .mailmap
> for future substitution).
We've been over this several times
On Wed, Apr 17, 2013 at 9:13 PM, Ramkumar Ramachandra
wrote:
> Duy Nguyen wrote:
>> No, submodule code does not change "git clone". If I'm not mistaken,
>> submodule will not kick in until you type "git submodule something".
>> If I turn clone.submoduleGitDir on, how can I undo my mistake in a
>>
On Wed, Apr 17, 2013 at 9:06 PM, Ramkumar Ramachandra
wrote:
> Duy Nguyen wrote:
>> Somewhat related to the topic. Why can't .gitattributes be used for
>> storing what's currently in .gitmodules?
>
> It can. It's just a small syntax change from "key = value" attributes
> inside a toplevel [submod
Duy Nguyen wrote:
> No, submodule code does not change "git clone". If I'm not mistaken,
> submodule will not kick in until you type "git submodule something".
> If I turn clone.submoduleGitDir on, how can I undo my mistake in a
> user friendly way?
So, if you currently want to add a submodule, yo
Duy Nguyen wrote:
> Somewhat related to the topic. Why can't .gitattributes be used for
> storing what's currently in .gitmodules?
It can. It's just a small syntax change from "key = value" attributes
inside a toplevel [submodule ] section separated by newlines, to
a path marked with multiple "ke
On Wed, Apr 17, 2013 at 8:53 PM, Ramkumar Ramachandra
wrote:
> Duy Nguyen wrote:
>> What if I clone a repo then realize it was a mistake and remove it?
>> With current clone, a "rm -rf" would do. With this, I'll need to
>> figure out which subdir in the top .git contains the repo I want to
>> remo
Duy Nguyen wrote:
> What if I clone a repo then realize it was a mistake and remove it?
> With current clone, a "rm -rf" would do. With this, I'll need to
> figure out which subdir in the top .git contains the repo I want to
> remove. I'm not sure how "git submodule" handles this case though
> (i.e
On Mon, Apr 8, 2013 at 7:23 AM, Jonathan Nieder wrote:
> Ramkumar Ramachandra wrote:
>
>> It's about the core object code of git parsing links, as
>> opposed to a fringe submodule.c/ submodule.sh parsing .gitmodules.
>
> What's stopping the core object code of git parsing .gitmodules?
missed a list sorry for dup
I ment the same because git changes the version too. Also
netbeans/eclipse upgrade are not synced, because of different
products. So the same ment only names, not versions. But in deep
search another repos I found the broken commits in Eclipse repo dated
by 13 march 201
On Sun, Apr 14, 2013 at 5:23 AM, Ramkumar Ramachandra
wrote:
> This configuration variable comes into effect when 'git clone' is
> invoked inside an existing git repository's worktree. When set,
> instead of cloning the given repository as-is, it relocates the gitdir
> of the repository to the pa
On Wed, Apr 17, 2013 at 7:33 AM, Junio C Hamano wrote:
>> @@ -1005,7 +1006,15 @@ static size_t format_commit_one(struct strbuf *sb, /*
>> in UTF-8 */
>> /* these are independent of the commit */
>> switch (placeholder[0]) {
>> case 'C':
>> - return parse_color(sb, pl
Junio C Hamano writes:
> * jc/add-2.0-delete-default (2013-03-08) 3 commits
> - git add ... defaults to "-A"
> (merged to 'next' on 2013-04-05 at 199442e)
> + git add: start preparing for "git add ..." to default to "-A"
> + builtin/add.c: simplify boolean variables
>
> In Git 2.0, "git add
On Wed, Apr 17, 2013 at 6:41 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> +delete_trailing_dollar() {
>> + sed 's/\$$//'
>> +}
>
> This is what we have qz_to_tab_space for, isn't it?
Thanks! I looked for something like this, but my eyes focused on
similar sed line and forgo
On Wed, 17 Apr 2013 13:14:48 +0400
Ivan Lyapunov wrote:
> netbeans use some integrated git wrapper and I don't know about JGit
> source base or not. In Eclipse we use Egit. Also all broken commits
> limited to november 2012, but we still continue to use the same
> development environments without
netbeans use some integrated git wrapper and I don't know about JGit
source base or not. In Eclipse we use Egit. Also all broken commits
limited to november 2012, but we still continue to use the same
development environments without any problems
Ivan
2013/4/17 John Keeping :
> On Wed, Apr 17, 201
On Mon, Apr 15, 2013 at 01:28:53PM -0700, Junio C Hamano wrote:
> Here are the topics that have been cooking. Commits prefixed with
> '-' are only in 'pu' (proposed updates) while commits prefixed with
> '+' are in 'next'.
> [...]
> --
> [New Topics]
On 04/15/2013 07:39 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> Stop emitting an error message for dangling packed references found
>> when deleting another packed reference. See the previous commit for a
>> longer explanation of the issue.
>>
>> Change repack_without_ref_fn() to s
On Tue, Apr 16, 2013 at 04:52:14PM -0700, Junio C Hamano wrote:
> > * jk/remote-helper-with-signed-tags (2013-04-15) 3 commits
> > - transport-helper: add 'signed-tags' capability
> > - transport-helper: pass --signed-tags=warn-strip to fast-export
> > - fast-export: add --signed-tags=warn-strip
So, I read through git-stash.sh a little more, and found the following:
1. Any stash that can be shown can be applied, but not necessarily
popped or dropped (as the documentation indicates). The reason for
this is simple: a pop/drop attempts to clear the entry in the stash
reflog as well, but all
On Wed, Apr 17, 2013 at 09:22:01AM +0400, Ivan Lyapunov wrote:
> I checked René Scharfe's patch and it works - no more git log crash.
> Also I checked a broken commits by git show and the most of them
> created by me. I can confirm I never used anyting else except console
> git commit or netbeans g
On 04/17/2013 01:22 AM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> would be that it expires *everything*. But in fact it seems to only
>> expire things that are at least one second old, which doesn't seem at
>> all useful in the real world. "--expire=all" is accepted without
>> compl
Ralf Thielow writes:
> Hi,
>
> Thanks for review!
>
> On Mon, Apr 15, 2013 at 9:26 PM, Christian Stimming wrote:
>
>> Thanks for the regular update! This is great work.
>>
>> One issue with the plural form messages, though:
>>
>> Am Montag, 15. April 2013, 18:27:40 schrieb Ralf Thielow:
>> > #:
Ralf Thielow writes:
>> #: sequencer.c:536
>> #, c-format
>> msgid "could not revert %s... %s"
>> msgstr "Konnte %s nicht zurücksetzen... %s"
>>
>> #: sequencer.c:1016
>> msgid "Can't revert as initial commit"
>> msgstr "Kann nicht zu initialer Version zurücksetzen."
>>
>> which I d
1 - 100 of 101 matches
Mail list logo
