Jeff King writes:
> On Tue, Jul 31, 2012 at 11:01:27PM -0700, Junio C Hamano wrote:
>
>> - As entries in rename cache that record high scores have names of
>>"similar" blobs, pack-objects may be able to take advantage of
>>this information.
>
> Yeah, although I suspect it is not as big a
L10n teams,
As Junio has already merged i18n topic branches and last round of l10n
commits, New round of translation begins. This update of "po/git.pot" is
not trival.
You can fetch this update at the usual place and start translation:
* https://github.com/git-l10n/git-po/commits/master
Commit
2012/8/2 Ralf Thielow :
> $(eval_gettext 'It seems that there is already a $state_dir_base directory,
> and
> -I wonder if you ware in the middle of another rebase. If that is the
> +I wonder if you are in the middle of another rebase. If that is the
It's my fault in commit c7108b. I am curiou
Robert Luberda wrote:
> Eric Wong wrote:
> > How about making this optional and configurable at init/clone time?
>
> I don't think it will be hard to make it configurable. I can try to make
> such a change, do you have any preferences about the option and
> configuration key names?
No preference
Jiang Xin writes:
> The following changes since commit 9e2116adbe192f3090785bdf3412bf7e3e2767b7:
>
> Update draft release notes to 1.7.12 (2012-07-27 22:25:19 -0700)
>
> are available in the git repository at:
>
> git://github.com/git-l10n/git-po master
>
> for you to fetch changes up to 9c87
On Wed, Aug 1, 2012 at 5:55 PM, Junio C Hamano wrote:
>
> As the basic structure and the direction looks good, let's start
> nitpicking ;-)
Sounds good.
> We tend to write the commit log message in imperative mood, as if
> you are giving an order to the codebase to "behave this way!". Also
> we
Hi Junio,
The following changes since commit 9e2116adbe192f3090785bdf3412bf7e3e2767b7:
Update draft release notes to 1.7.12 (2012-07-27 22:25:19 -0700)
are available in the git repository at:
git://github.com/git-l10n/git-po master
for you to fetch changes up to 9c87b0d28f05c8ffcfe28da3216
Eric Wong wrote:
Hi,
>
> I've long wanted to change this, but it breaks compatibility if folks
> are importing from the same repo, sharing changes and one upgrades
> git-svn.
Yes, I'm aware of this. That's why in our team at work everybody is
forced to use the modified version of git-svn:)
[ A
Angus Hammond writes:
>>But from the bigger UI consistency point of view, it would be
>>chaotic to change the default of some options for a single
>>command depending on the nature of the operand, so I would
>>recommend against going this route, and pick one view between
>>"gi
On Wed, 01 Aug 2012 14:55:52 -0700
Junio C. Hamano wrote:
> J Smith writes:
>
>> grep.extendedRegexp::
>> -If set to true, enable '--extended-regexp' option by default.
>> +If set to true, enable '--extended-regexp' option by default. This
>> +option is ignored when the 'grep.pattern
Jeff King writes:
> On Tue, Jul 31, 2012 at 11:01:27PM -0700, Junio C Hamano wrote:
> ...
>> As we still have the pathname in this codepath, I am wondering if we
>> would benefit from custom "content hash" that knows the nature of
>> payload than the built-in similarity estimator, driven by the
>
J Smith writes:
As the basic structure and the direction looks good, let's start
nitpicking ;-)
> Adds the grep.patternType configuration setting which sets the default
> pattern matching behavior. The values "basic", "extended", "fixed", and
> "perl" can be used to set "--basic-regexp", "--exte
On Tue, Jul 31, 2012 at 11:01:27PM -0700, Junio C Hamano wrote:
> > @@ -175,6 +177,11 @@ static int estimate_similarity(struct diff_filespec
> > *src,
> > if (max_size * (MAX_SCORE-minimum_score) < delta_size * MAX_SCORE)
> > return 0;
> >
> > + hashcpy(pair.one, src->sha1);
>
Robert Luberda wrote:
> While importing changes from SVN by `git svn fetch' strip any
> white spaces from beginnings and endings of SVN commit messages
> and skip adding a new line character before `git-svn-id:'
> line in case the commit message ends with another pseudo-header
> (like From:, Signe
dcommit didn't handle errors returned by SVN and coped very
poorly with concurrent commits that appear in SVN repository
while dcommit was running. In both cases it left git repository
in inconsistent state: index (which was reset with `git reset
--mixed' after a successful commit to SVN) no longer
While importing changes from SVN by `git svn fetch' strip any
white spaces from beginnings and endings of SVN commit messages
and skip adding a new line character before `git-svn-id:'
line in case the commit message ends with another pseudo-header
(like From:, Signed-off-by: or Change-Id:, etc.).
On Wed, Aug 01, 2012 at 01:34:23PM +0700, Nguyen Thai Ngoc Duy wrote:
> On Wed, Aug 1, 2012 at 1:09 PM, Junio C Hamano wrote:
> > Nguyen Thai Ngoc Duy writes:
> >
> >> Yes. This is probably cosmetics only, but without path information, we
> >> leave it to chance to decide which A to pair with B
Michael G Schwern wrote:
> That's the part that doesn't matter. People matter.
> What I'm trying to say is I have much less interest in doing it without the
> overloading. It's not interesting to me. It's no fun. No fun means no
> patch. No patch means no improvement. No improvement is the
On Wed, Aug 01, 2012 at 11:36:00AM +0700, Nguyen Thai Ngoc Duy wrote:
> > That is orthogonal to the issue of what is being stored. I chose my
> > mmap'd disk implementation because it is very fast, which makes it nice
> > for a performance cache. But you could store the same thing in git-notes
> >
Jeff King writes:
> Hopefully the above has answered these questions for you.
>
> However, I hope it has also showed the limitations of pure file renames
> when you are looking at content movement from one file to another.
Nice write-up.
Care to save this somewhere more permanent (e.g. git.wiki
On Tue, Jul 31, 2012 at 10:39:43AM +0200, Gerlando Falauto wrote:
> I have some questions about rename detection.
> The way I understand it, renames are not tracked in any way by GIT,
> at least not in the repository. Instead some detection algorithm is
> executed when data is extracted from the r
On 12-08-01 02:48 PM, Junio C Hamano wrote:
> Paul Gortmaker writes:
>
>> In order to make a commit be invariant (excluding ID) over
>> a format-patch and subsequent am cycle, one needs to use
>> the '--keep-non-patch' so that commits like:
>>
>> [PATCH] [i386] fix foo bar arch/x86/mm
>>
>>
Hi again,
Florian Achleitner wrote:
> When the first line arrives at the remote-helper, it starts importing one
> line
> at a time, leaving the remaining lines in the pipe.
> For importing it requires the data from fast-import, which would be mixed
> with
> import lines or queued at the end o
Am 2012-07-31 22:39, schrieb Linus Torvalds:
On Tue, Jul 31, 2012 at 1:16 PM, Junio C Hamano wrote:
Eek.
Oh, I agree. Doing a full character set conversion both ways is quite
a bit more work.
Not just write_entry() codepath that creates the final paths on the
filesystem, you would need to
Paul Gortmaker writes:
> In order to make a commit be invariant (excluding ID) over
> a format-patch and subsequent am cycle, one needs to use
> the '--keep-non-patch' so that commits like:
>
> [PATCH] [i386] fix foo bar arch/x86/mm
>
> only lose the [PATCH] and not the [i386] part. Since
Adds the grep.patternType configuration setting which sets the default
pattern matching behavior. The values "basic", "extended", "fixed", and
"perl" can be used to set "--basic-regexp", "--extended-regexp",
"--fixed-strings", and "--perl-regexp" options by default respectively.
A value of true is
>But from the bigger UI consistency point of view, it would be
>chaotic to change the default of some options for a single
>command depending on the nature of the operand, so I would
>recommend against going this route, and pick one view between
>"give the user a chance to fix"
Andreas Grünbacher writes:
> * Support for double-quoted filenames in the "diff --git" format: when a
> filename starts with a double quote, it is interpreted as a C string
> literal. The escape sequences \\, \", \a, \b, \f, \n, \r, \t, \v, and \ooo
> (a three-digit octal number between 0
Chris Webb writes:
[summary: this, when 59a8fde does not have any commit log message,
refuses to commit]
> $ git cherry-pick 59a8fde
> Aborting commit due to empty commit message.
> I can see that this check could make sense when the message has been
> modified, but it seems strange when it
On Tue, Jul 31, 2012 at 11:51 PM, Frans Klaver wrote:
> On Wed, Aug 1, 2012 at 1:44 AM, Ammon Riley wrote:
>> 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 po
In order to make a commit be invariant (excluding ID) over
a format-patch and subsequent am cycle, one needs to use
the '--keep-non-patch' so that commits like:
[PATCH] [i386] fix foo bar arch/x86/mm
only lose the [PATCH] and not the [i386] part. Since it
is a common desire (e.g. linux k
Fix a typo in the error messages which is
shown if it seems that a rebase is already
in progress.
Signed-off-by: Ralf Thielow
---
git-rebase.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index 0e6fd09..15da926 100755
--- a/git-rebase.sh
+++
After another improvement in git-style diff support to better handle
concatenated
diffs, here is a last call for testing to ensure that the code works
well enough to
become the next stable release. Please find the latest development snapshots
here:
ftp://alpha.gnu.org/gnu/patch/
The following s
Whilst doing some extra sanity checking of my git-rebase--interactive.sh
patch yesterday, I came across a behaviour which has been present for some
time, but seems surprising. You can reproduce with
$ git init -q foo && cd foo
$ touch one && git add one && git commit -q -m one
$ touch two &&
This is the best site for storing all your docs online and 100% secure too.
I have uploaded the docs n t very easy to access
--
View this message in context:
http://git.661346.n2.nabble.com/My-Personal-datavault-Mypdv-tp7562340p7564235.html
Sent from the git mailing list archive at Nabble.com.
On Tuesday 31 July 2012 15:43:57 Jonathan Nieder wrote:
> Florian Achleitner wrote:
> > I haven't tried that yet, nor do I remember anything where I've already
> > seen two processes writing to the same pipe.
>
> It's a perfectly normal and well supported thing to do.
I played around with a littl
On Wed, Aug 1, 2012 at 4:52 AM, Andrew Ardill wrote:
> On Wednesday, August 1, 2012, jaseem abid wrote:
>>
>> [...]
>>
>> Any help will be greatly appreciated.
>
>
> Was there anything in particular you wanted help with: code review, fixing
> bugs, implementing features?
1. Code review, I don't w
37 matches
Mail list logo
