Jeff King wrote:
>On Sun, Apr 27, 2014 at 12:35:13PM +1000, James Denholm wrote:
>
>> >Do we even make [subproject and mainline] anymore? It looks like
>they are part
>> >of the tests, but the whole test script runs inside its own trash
>> >directory.
>>
>> subproject and mainline are actually ma
On Sun, Apr 27, 2014 at 12:35:13PM +1000, James Denholm wrote:
> >Do we even make [subproject and mainline] anymore? It looks like they are
> >part
> >of the tests, but the whole test script runs inside its own trash
> >directory.
>
> subproject and mainline are actually made in contrib/subtree
Jeff King wrote:
>I think the problem is that
>contrib/subtree does not really have an active dedicated area
>maintainer.
Yeah, I can see how that might become a bit of a problem. I was
actually thinking of doing a bit of work on subtree beyond this
specific patch, so hopefully that won't be a sh
On Sat, Apr 26, 2014 at 2:13 PM, Jeff King wrote:
> [+cc Duy, whose patch this is]
>
> On Fri, Apr 25, 2014 at 04:10:49PM -0400, Jörn Engel wrote:
>
>> A second option is to add a --pager (or rather --no-pager) option to
>> the command line and allow the user to specify
>> GIT_PAGER="git --no-
Currently, git records a checksum, author, commit date/time, and commit
message with every commit (as get be seen from 'git log'). I think it
would be useful if, along with the Author and Date, git recorded the
name of the current branch on each commit. The branch name can provide
useful cont
If a file contained CRLF line endings in a repository with
core.autocrlf=input, then blame always marked lines as "Not Committed Yet",
even if they were unmodified. Don't attempt to convert the line endings
when creating the fake commit so that blame works correctly regardless of
the autocrlf sett
On 04/26/2014 02:12 PM, tolga ceylan wrote:
Yes, when git-p4 runs git-apply to test the patch, this fails
due to abbreviated blob object names. I think git-apply requires
full object names for binary patches.
This looks like a straightforward change, but can you give a
bit more background on
Yes, when git-p4 runs git-apply to test the patch, this fails
due to abbreviated blob object names. I think git-apply requires
full object names for binary patches.
On 04/26/2014 05:43 AM, Pete Wyckoff wrote:
tolga.cey...@gmail.com wrote on Thu, 24 Apr 2014 21:46 -0700:
When applying binary pat
This patch series comes from what Peff sent in the following thread:
http://thread.gmane.org/gmane.comp.version-control.git/243361/focus=243528
I added the following fixes:
- add "strbuf_release(&result);" in import_object(); this was suggested
by Eric Sunshine
- use MODE_LIST instead of MODE_
From: Jeff King
The git-replace command has three modes: listing, deleting,
and replacing. The first two are selected explicitly. If
none is selected, we fallback to listing when there are no
arguments, and replacing otherwise.
Let's figure out up front which operation we are going to
do, before
From: Jeff King
This allows you to run:
git replace --edit SHA1
to get dumped in an editor with the contents of the object
for SHA1. The result is then read back in and used as a
"replace" object for SHA1. The writing/reading is
type-aware, so you get to edit "ls-tree" output rather than
th
From: Jeff King
By using OPT_CMDMODE, the mutual exclusion between modes is
taken care of for us. It also makes it easy for us to
maintain a single variable with the mode, which makes its
intent more clear. We can use a single switch() to make sure
we have covered all of the modes.
This ends up
From: Jeff King
As we add new options that operate on objects before
replacing them, we'll want to be able to feed raw sha1s
straight into replace_object. Split replace_object into the
object-resolution part and the actual replacement.
Signed-off-by: Jeff King
Signed-off-by: Christian Couder
-
Philip Oakley wrote:
> From: "Felipe Contreras"
> > are the bedstone of science. You can make sensible decisions based on that
> > alone, and in fact that's how most good decisions are made.
>
> At the moment we are missing the repeatable measurements,
Sure, that's part of science, but my point
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > So you grant that there is no reason anybody can think of why we would ever
> > want a post-update-branch?
>
> No, it only shows that you (and I) are not imaginative enough
> (and/or we didn't bother spending enough brain cycles) to come up
Am 26.04.2014 20:33, schrieb Marius Ungureanu:
> ... add as many unit tests I can.
Great! Keep in mind that quantity is secondary. Quality counts.
> I’ll start a new thread with the new
> patch as soon as I’m done with it.
If possible, do not start a new thread, but post your new patch as a
repl
On 26 Apr 2014, at 20:49, Johannes Sixt wrote:
> Am 26.04.2014 11:55, schrieb Marius Ungureanu:
>> On 26 Apr 2014, at 10:10, Johannes Sixt wrote:
>>> Am 26.04.2014 01:25, schrieb Marius Ungureanu:
diff --git a/userdiff.c b/userdiff.c
index fad52d6..7612c5d 100644
--- a/userdiff.c
>
Junio C Hamano writes:
> David Kastrup writes:
>
>> Includes reasonably tasteful begging.
>
> Thanks, but no thanks---I do not see it tasteful.
Well, begging rarely is. The point simply is that without commensurate
recompensation, I cannot afford any more work of that kind on Git, and
there is
On Sat, Apr 26, 2014 at 10:50:26AM -0700, Dan Albert wrote:
> git-imap-send was directly prompting for a password rather than using
> git-credential. git-send-email, on the other hand, supports
> git-credential.
Yay. These sorts of conversions were definitely on my mind when I did
the original cr
On Sat, Apr 26, 2014 at 10:30 AM, David Kastrup wrote:
> David Kastrup writes:
>
>> http://repo.or.cz/r/wortliste.git
>> git blame [-M / -C] wortliste
>>
>> The latter one is _really_ taking a severe hit from the O(n^2)
>> algorithms. If your benchmarks for that one still point mostly to the
>>
git-imap-send was directly prompting for a password rather than using
git-credential. git-send-email, on the other hand, supports git-credential.
This is a necessary improvement for users that use two factor authentication, as
they should not be expected to remember all of their app specific passw
On Sat, Apr 26, 2014 at 10:24:50AM -0700, Junio C Hamano wrote:
> Suvorov Ivan writes:
>
> > I want to extend the functionality of git due to the possibility of
> > separation of the user repository into 2 parts - one part will be
> > stored as usual, under version control git, and the second pa
Am 26.04.2014 11:55, schrieb Marius Ungureanu:
> On 26 Apr 2014, at 10:10, Johannes Sixt wrote:
>> Am 26.04.2014 01:25, schrieb Marius Ungureanu:
>>> diff --git a/userdiff.c b/userdiff.c
>>> index fad52d6..7612c5d 100644
>>> --- a/userdiff.c
>>> +++ b/userdiff.c
>>> @@ -133,14 +133,14 @@ PATTERNS(
On Thu, Apr 24, 2014 at 07:17:36PM +0200, Ivo Bellin Salarin wrote:
> To shortly resume it, the problem is that:
> * when the authentication method (WWW-Authenticate) is Negotiate AND
> * when the server proposes a NTLMSSP_CHALLENGE in response of the
> client's NTLMSSP_NEGOTIATE,
> => libcurl yiel
Felipe Contreras writes:
> So you grant that there is no reason anybody can think of why we would ever
> want a post-update-branch?
No, it only shows that you (and I) are not imaginative enough
(and/or we didn't bother spending enough brain cycles) to come up
with an example. Your lack of imagi
[+cc Duy for real this time]
On Sat, Apr 26, 2014 at 10:27:07AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > [+cc Duy, whose patch this is]
> >
> > On Fri, Apr 25, 2014 at 04:10:49PM -0400, Jörn Engel wrote:
> >
> >> A second option is to add a --pager (or rather --no-pager) option to
David Kastrup writes:
> http://repo.or.cz/r/wortliste.git
> git blame [-M / -C] wortliste
>
> The latter one is _really_ taking a severe hit from the O(n^2)
> algorithms. If your benchmarks for that one still point mostly to the
> unpacking, your jgit blame should be fine regarding the stuff
> I
David Kastrup writes:
> Includes reasonably tasteful begging.
Thanks, but no thanks---I do not see it tasteful.
In any case, any large change that is not a regression fix (or a fix
to a code added since 1.9 series) is way too late for 2.0 at this
point, but I do look forward to reading the patc
Jeff King writes:
> [+cc Duy, whose patch this is]
>
> On Fri, Apr 25, 2014 at 04:10:49PM -0400, Jörn Engel wrote:
>
>> A second option is to add a --pager (or rather --no-pager) option to
>> the command line and allow the user to specify
>> GIT_PAGER="git --no-pager -p column --mode='dense c
Suvorov Ivan writes:
> I want to extend the functionality of git due to the possibility of
> separation of the user repository into 2 parts - one part will be
> stored as usual, under version control git, and the second part will
> be stored in another location such as an FTP-server.
Sounds like
Shawn Pearce writes:
> Right, and JGit blame still is missing the -M and -C options, as I
> have not implemented those yet. I got basic blame and reverse blame
> working a few years ago and then stopped working on the code for a
> while. Now we have interest in improving the latency for $DAY_JOB,
On Sat, Apr 26, 2014 at 9:50 AM, David Kastrup wrote:
> Shawn Pearce writes:
>
>> On Sat, Apr 26, 2014 at 12:48 AM, David Kastrup wrote:
>>> Shawn Pearce writes:
And JGit was already usually slower than git-core. Now it will be
even slower! :-)
>>>
>>> If your statement about JGi
Shawn Pearce writes:
> Thanks for doing this. Unfortunately I can't read the patch itself as
> I am also trying to improve JGit's blame code for $DAY_JOB, and JGit
> is BSD licensed.
Actually, I'd have suggested asking $EMPLOYER to buy the rights for
looking at the code, but as I wrote previousl
Shawn Pearce writes:
> On Sat, Apr 26, 2014 at 12:48 AM, David Kastrup wrote:
>> Shawn Pearce writes:
>>>
>>> And JGit was already usually slower than git-core. Now it will be
>>> even slower! :-)
>>
>> If your statement about JGit is accurate, it should likely have beat
>> Git for large use ca
On Sat, Apr 26, 2014 at 12:48 AM, David Kastrup wrote:
> Shawn Pearce writes:
>
>> On Fri, Apr 25, 2014 at 4:56 PM, David Kastrup wrote:
>>> The previous implementation used a single sorted linear list of blame
>>> entries for organizing all partial or completed work. Every subtask had
>>> to s
tolga.cey...@gmail.com wrote on Thu, 24 Apr 2014 21:46 -0700:
> When applying binary patches a full index is required. format-patch
> already handles this, but diff-tree needs '--full-index' argument
> to always output full index.
>
> Signed-off-by: Tolga Ceylan
> ---
> git-p4.py |2 +-
> 1
dpr...@gmail.com wrote on Tue, 22 Apr 2014 10:20 +0100:
> As part of my work to help get git-p4 close to bug-free before Git
> 2.0, I'm posting all bugs and patches to this mailing list. Please
> direct me elsewhere if this is incorrect.
>
> When trying to clone a particular directory from a depot
On 04/22/2014 06:54 PM, Junio C Hamano wrote:
Interesting. It will break immediately when the project starts
wanting to distribute its "canonical" ignore list
If that happens, that's a problem caused by the project wanting to
misuse .gitignore.
There are good practices and bad practices. F
On a side note, I noticed some of the keywords I added shouldn’t be there.
I just realised that simple statements have no reason to be there, but only
block definitions. I’ll reduce the size of this patch on the keywords part.
Thanks,
Marius--
To unsubscribe from this list: send the line "unsubsc
On 26 Apr 2014, at 10:10, Johannes Sixt wrote:
> Am 26.04.2014 01:25, schrieb Marius Ungureanu:
>> New keywords: foreach, break, in, try, finally, as, is, typeof, var,
>> default, fixed, checked, unchecked, this, lock, readonly, unsafe,
>> ref, out, base, null, delegate, continue.
>>
>> Removed
From: "Felipe Contreras"
My conclusion is based on logic and reason,
you forget "And repeatable measurement / evidence"
which
are the bedstone of science.
You can make sensible decisions based on that alone, and in fact
Hello.
I want to extend the functionality of git due to the possibility of separation
of the user repository into 2 parts - one part will be stored as usual, under
version control git, and the second part will be stored in another location
such as an FTP-server.
This will be done in order to be
On Fri, Apr 25, 2014 at 04:09:47PM -0700, a...@bellandwhistle.net wrote:
> >Andrew Ardill writes:
> >
> >As a data point, I have seen people add ".gitignore" to their
> >.gitignore file, as they don't want to share the file.
>
> Right, I've seen that too.
That something I am actually doing in my
Shawn Pearce writes:
> On Fri, Apr 25, 2014 at 4:56 PM, David Kastrup wrote:
>> The previous implementation used a single sorted linear list of blame
>> entries for organizing all partial or completed work. Every subtask had
>> to scan the whole list, with most entries not being relevant to the
On Sat, Apr 26, 2014 at 02:56:15PM +1000, nod.h...@gmail.com wrote:
> > contrib/subtree/Makefile is a shambles in regards to it's consistency
> > with other makefiles, which makes subtree overly painful to include in
> > build scripts.
> >
> > Two major issues are present:
> >
> > Firstly, calls t
[+cc Duy, whose patch this is]
On Fri, Apr 25, 2014 at 04:10:49PM -0400, Jörn Engel wrote:
> A second option is to add a --pager (or rather --no-pager) option to
> the command line and allow the user to specify
> GIT_PAGER="git --no-pager -p column --mode='dense color'" git -p branch
I think
Am 26.04.2014 01:25, schrieb Marius Ungureanu:
> New keywords: foreach, break, in, try, finally, as, is, typeof, var,
> default, fixed, checked, unchecked, this, lock, readonly, unsafe,
> ref, out, base, null, delegate, continue.
>
> Removed keywords: instanceof. It's only in Java.
> Moved keyword
47 matches
Mail list logo
