On Thu, Apr 16, 2015 at 02:17:32AM -0400, Jeff King wrote:
> So it uses a special git-specific version of exec, and doesn't touch the
> PATH. Later, we did 231af83 (Teach the "git" command to handle some
> commands internally, 2006-02-26), which says at the end:
>
>There's one other change: t
On Wed, Apr 15, 2015 at 11:00:20AM -0400, Matthew Rothenberg wrote:
> So, I guess what I'm looking for is:
> - A way to prevent the **path to the running "git" itself** portion
> of setup_path from firing, (OR)
Yeah, this behavior leaves me somewhat confused. It is obviously
dangerous (since we
On Mon, Apr 13, 2015 at 8:29 AM, Koosha Khajehmoogahi wrote:
> From: Junio C Hamano
Let's not call this *my* change. The mechanism I did write, but I think the
most important part of the change is to decide which commands in the
log family should honor the configuration variable and which ones s
On Wed, Apr 15, 2015 at 7:22 PM, Jeff King wrote:
>
> In the meantime, unless somebody is planning to jump on this topic
> immediately (I am not), I think we can revert 2bf15a3330a from master.
> It's definitely fixing _a_ problem, but it's one we've lived with for
> many years already.
Yeah, I a
On Wed, Apr 15, 2015 at 6:27 PM, Koosha Khajehmoogahi wrote:
> On 04/14/2015 08:42 AM, Eric Sunshine wrote:
>> On Mon, Apr 13, 2015 at 11:29 AM, Koosha Khajehmoogahi
>> wrote:
>>> From: Junio C Hamano
>>>
>>> [kk: added documentation in git-log.txt]
>>>
>>> Signed-off-by: Koosha Khajehmoogahi
On April 15, 2015 10:22 PM Jeff King wrote:
> Sent: April 15, 2015 10:22 PM
> To: Bryan Turner
> Cc: Junio C Hamano; Git Users
> Subject: Re: [ANNOUNCE] Git v2.4.0-rc2
>
> [side note: please trim your quoted material when doing inline quoting]
>
> On Thu, Apr 16, 2015 at 12:05:57PM +1000, Bryan T
[side note: please trim your quoted material when doing inline quoting]
On Thu, Apr 16, 2015 at 12:05:57PM +1000, Bryan Turner wrote:
> > merge: pass verbosity flag down to merge-recursive
>
> I'm pretty confident this change is working as intended, but the
> intended change is causing a r
On Wed, Apr 15, 2015 at 7:48 AM, Junio C Hamano wrote:
>
> A release candidate Git v2.4.0-rc2 is now available for testing at
> the usual places. The difference since -rc1 is mostly l10n and a
> handful of documentation clean-ups.
>
> The tarballs are found at:
>
> https://www.kernel.org/pub/
On 04/14/2015 08:42 AM, Eric Sunshine wrote:
> On Mon, Apr 13, 2015 at 11:29 AM, Koosha Khajehmoogahi
> wrote:
>> From: Junio C Hamano
>>
>> [kk: added documentation in git-log.txt]
>>
>> Signed-off-by: Koosha Khajehmoogahi
>> ---
>> diff --git a/Documentation/rev-list-options.txt
>> b/Docum
On Wed, Apr 15, 2015 at 01:21:15PM -0700, Junio C Hamano wrote:
> > - type[i++] = c;
> > - if (i >= sizeof(type))
> > - return -1;
> > + strbuf_addch(&typename, c);
> > }
> > - type[i] = 0;
>
> This _might_ have some performance impact in that
On Wed, Apr 15, 2015 at 02:30:17PM -0700, Junio C Hamano wrote:
> I spoke too soon. There are two error-exit paths in this function.
>
> -- >8 --
> A broken or badly formatted commit might not record author or
> committer lines or we may not find a valid name on them. The
> function record_pers
Junio C Hamano writes:
> A broken or badly formatted commit might not record author or
> committer lines; the function record_person() returned after
> calling get_commit_buffer() without calling unuse_commit_buffer()
> on the memory, potentially leaking it.
>
> Signed-off-by: Junio C Hamano
> -
A broken or badly formatted commit might not record author or
committer lines; the function record_person() returned after
calling get_commit_buffer() without calling unuse_commit_buffer()
on the memory, potentially leaking it.
Signed-off-by: Junio C Hamano
---
* to be applied on bc6b8fc1 (use
Junio C Hamano writes:
> Karthik Nayak writes:
> ...
>> -if (argc != 3 && argc != 2)
>> +if (argc < 2 || argc > 4)
>> usage_with_options(cat_file_usage, options);
>
> Hmm, why this change?
>
> By allowing 4 args blindly like this, you will let something like
> these to pass:
Am 15.04.2015 um 20:48 schrieb Junio C Hamano:
The patch should do for now, but I suspect that it may give us a
better abstraction to make the "is_foreground_fd(int fd)" or even
"is_foreground(void)" the public API that would be implemented as
int we_are_in_the_foreground(void)
On Wed, Apr 15, 2015 at 08:13:51PM +0530, Pirate Praveen wrote:
>
> Q: Are the mosh principles relevant to other network applications?
>
> We think so. The design principles that Mosh stands for are
> conservative: warning the user if the state being displayed is out of
> date, serializing an
Karthik Nayak writes:
> Update sha1_loose_object_info() to optionally allow it to read
> from a loose object file of unknown/bogus type; as the function
> usually returns the type of the object it read in the form of enum
> for known types, add an optional "typename" field to receive the
> name o
Karthik Nayak writes:
> case 's':
> - type = sha1_object_info(sha1, &size);
> - if (type > 0) {
> - printf("%lu\n", size);
> - return 0;
> - }
> - break;
> + oi.sizep = &size;
> +
On 2015-04-15 19.36, Johannes Schindelin wrote:
> Hi Torsten,
>
> On 2015-04-15 19:01, Torsten Bögershausen wrote:
>
>> t/t0027-auto-crlf.sh | 155
>> ---
>
> I fear that we duplicated work here, due to me working on Git for Windows 2.x
> and you
On Wed, Apr 15, 2015 at 8:29 PM, Johannes Sixt wrote:
> Windows does not have process groups. It is, therefore, the simplest
> to pretend that each process is in its own process group.
Windows does have some concept of process groups, but probably not
quite what you want:
https://msdn.microsoft.
On wo, 2015-04-15 at 19:46 +0200, Johannes Schindelin wrote:
> On 2015-04-15 17:33, Trevor Saunders wrote:
> > but it certainly does support ssh
> > and then doing IO.
>
Yes, in interactive sessions. mosh synchronizes terminal state, it
doesn't allow random I/O between client and server.
> Ah,
On Wed, Apr 15, 2015 at 07:46:15PM +0200, Johannes Schindelin wrote:
> Hi Trevor,
>
> On 2015-04-15 17:33, Trevor Saunders wrote:
> > On Wed, Apr 15, 2015 at 04:41:42PM +0200, Johannes Schindelin wrote:
> >>
> >> On 2015-04-15 16:18, Pirate Praveen wrote:
> >> > On Wednesday 15 April 2015 07:22 PM
Johannes Sixt writes:
> Windows does not have process groups. It is, therefore, the simplest
> to pretend that each process is in its own process group.
>
> While here, move the getppid() stub from its old location (between
> two sync related functions) next to the two new functions.
>
> Signed-o
Michael Haggerty writes:
> This whole series LGTM; however, I suggest that this patch be split up.
> See below.
>
>> Signed-off-by: Stefan Beller
>> Signed-off-by: Junio C Hamano
>> ---
>> refs.c | 16 ++--
>> 1 file changed, 6 insertions(+), 10 deletions(-)
>>
>> diff --git a/ref
Windows does not have process groups. It is, therefore, the simplest
to pretend that each process is in its own process group.
While here, move the getppid() stub from its old location (between
two sync related functions) next to the two new functions.
Signed-off-by: Johannes Sixt
---
compat/mi
Torsten Bögershausen writes:
> On 2015-04-14 23.49, Junio C Hamano wrote:
>> * tg/perf-lib-test-perf-cleanup (2013-09-19) 2 commits
>> - perf-lib: add test_perf_cleanup target
>> - perf-lib: split starting the test from the execution
>>
>> Add test_perf_cleanup shell function to the perf suit
"Chris O'Kelly" writes:
> To reiterate and clarify I'm not saying the undesirable behavior
> is a built in part of git, just a feature of our hosting
> platform's Git deployment mechanisms, although if what you mean is
> that the post-receive hook on the receiving end shouldn't be
> getting passe
Erik Elfström writes:
> Before this change, clean used resolve_gitlink_ref to check for the
> presence of nested git repositories. This had the drawback of creating
> a ref_cache entry for every directory that should potentially be
> cleaned. The linear search through the ref_cache list caused a
Hi Trevor,
On 2015-04-15 17:33, Trevor Saunders wrote:
> On Wed, Apr 15, 2015 at 04:41:42PM +0200, Johannes Schindelin wrote:
>>
>> On 2015-04-15 16:18, Pirate Praveen wrote:
>> > On Wednesday 15 April 2015 07:22 PM, Michael J Gruber wrote:
>> >> What would that require git to do, beyond taking wh
Hi Torsten,
On 2015-04-15 19:01, Torsten Bögershausen wrote:
> t/t0027-auto-crlf.sh | 155
> ---
I fear that we duplicated work here, due to me working on Git for Windows 2.x
and you sending mails to the non-Windows mailing list.
For what it is
On Wed, Apr 15, 2015 at 12:24 PM, Junio C Hamano wrote:
> The function parses the input to compute the broken-down time in
> "struct tm", and the GMT timezone offset. If the timezone offset
> does not exist in the input, the broken-down time is turned into the
> number of seconds since epoch both
Linus Torvalds writes:
> On Wed, Apr 15, 2015 at 12:22 AM, Eric Sunshine
> wrote:
>>
>> The fix seems to be simply:
>
> Yup, that seems to do it for me. I'm not sure how we get to
> "match_digit()" with the time string "now", though.
The --date= parameter is read by determine_author_info() and
"new safer autocrlf handling":
Check if eols are converted at commit, which have CR (or CLLF) in the repo
(technically speaking in the index)
Add a test-file repoMIX with mixed line-endings.
Check the warnings when converting LF->CRLF or CRLF->LF
checkout_files():
Checking out CRLF_nul a
Make more clear what the tests are doing:
commit_check_warn():
Commit files and checks for conversion warnings.
Old name: create_file_in_repo()
checkout_files():
Checkout files from the repo and check if they have
the appropriate line endings in the work space.
Old name: ch
When running under MINGW, the native line ending is CRLF and not LF.
Adjust the check of the warnings with macros:
WLC: LF become CRLF on non-MINGW
WCL: CRLF become LF on non-MINGW
WMIX: Mixed line endings: either CRLF->LF or LF->CRLF
Improve the information given by check_warning():
Use t
Signed-off-by: Karthik Nayak
---
Documentation/git-cat-file.txt | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-cat-file.txt b/Documentation/git-cat-file.txt
index f6a16f4..226a9c4 100644
--- a/Documentation/git-cat-file.txt
+++ b/Documentation/git-cat-fi
Signed-off-by: Karthik Nayak
---
t/t1006-cat-file.sh | 29 +
1 file changed, 29 insertions(+)
diff --git a/t/t1006-cat-file.sh b/t/t1006-cat-file.sh
index ab36b1e..61fab78 100755
--- a/t/t1006-cat-file.sh
+++ b/t/t1006-cat-file.sh
@@ -47,6 +47,18 @@ $content"
Currently 'git cat-file' throws an error while trying to
print the type or size of a broken/corrupt object. This is
because these objects are usually of unknown types.
Teach git cat-file a '--literally' option where it prints
the type or size of a broken/corrupt object without throwing
an error.
Update sha1_loose_object_info() to optionally allow it to read
from a loose object file of unknown/bogus type; as the function
usually returns the type of the object it read in the form of enum
for known types, add an optional "typename" field to receive the
name of the type in textual form and a f
Version 7 can be found here :
http://thread.gmane.org/gmane.comp.version-control.git/266761/match=patch+v7+0+4
Changes In this version :
sha1_file.c
* sha1_object_info_extended() can now accept object_info *oi with
oi->typename without needing a oi->typep.
* Changes in parse_sha1_header_extend
Binds "g" to focus the sha1 entry box.
Signed-off-by: Ismael Luceno
---
gitk | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gitk b/gitk
index 9a2daf3..0e9d884 100755
--- a/gitk
+++ b/gitk
@@ -2568,6 +2568,7 @@ proc makewindow {} {
bindkey b prevfile
bindkey d "$ctext yview scrol
The function parses the input to compute the broken-down time in
"struct tm", and the GMT timezone offset. If the timezone offset
does not exist in the input, the broken-down time is turned into the
number of seconds since epoch both in the current timezone and in
GMT and the offset is computed as
When the input does not have GMT timezone offset, the code computes
it by computing the local and GMT time for the given timestamp. But
there is no point doing so if the given timestamp is known to be a
bogus one.
Signed-off-by: Junio C Hamano
---
* A simple preliminary clean-up while we are in
On Wed, Apr 15, 2015 at 12:22 AM, Eric Sunshine wrote:
>
> The fix seems to be simply:
Yup, that seems to do it for me. I'm not sure how we get to
"match_digit()" with the time string "now", though.
So your patch fixes things for me, but I think:
- we should move the "tm.tm_isdst = -1;" up a b
Jeff King writes:
> On Tue, Apr 14, 2015 at 12:30:23PM -0700, Junio C Hamano wrote:
>
>> > If I recall correctly, Scott said onstage that some/all of the
>> > conference proceeds would be going directly into this fund. So this
>> > might need to be revised upward by 50-100% sometime soon :)
>>
>
On Tue, Apr 14, 2015 at 4:54 PM, Jeff King wrote:
> On Tue, Apr 14, 2015 at 12:30:23PM -0700, Junio C Hamano wrote:
>
>> > If I recall correctly, Scott said onstage that some/all of the
>> > conference proceeds would be going directly into this fund. So this
>> > might need to be revised upward by
On Wed, Apr 15, 2015 at 04:41:42PM +0200, Johannes Schindelin wrote:
> Hi Praveen,
>
> On 2015-04-15 16:18, Pirate Praveen wrote:
> > On Wednesday 15 April 2015 07:22 PM, Michael J Gruber wrote:
> >> What would that require git to do, beyond taking whatever you tell it
> >> (using GIT_SSH or _GIT_
On Wednesday 15 April 2015 07:52 PM, Johannes Schindelin wrote:
> From https://github.com/keithw/mosh:
>
>> Mosh does not support X forwarding or the non-interactive uses of SSH,
>> including port forwarding.
>
> In particular it "does not support [...] the non-interactive uses of SSH",
> which
Hmm, this all makes sense as to why it's happening, thank you. In my
case the ` /usr/local/Cellar/git/2.3.5/libexec/git-core` (git
--exec-path) does give all the proper binaries and sub-binaries. It
shows up twice because the GIT_EXEC_PATH environment variable is used
too (which is the same in my
Eric Sunshine writes:
> Later parse_date_basic() computes the offset from GMT by comparing
> the values returned by tm_to_time_t() and mktime(). The existing 'tm'
> is passed to mktime() with the tm_isdst field already set to 0 by
> gmtime_r(), and mktime() respects that as a statement that DST i
Hi Praveen,
On 2015-04-15 16:18, Pirate Praveen wrote:
> On Wednesday 15 April 2015 07:22 PM, Michael J Gruber wrote:
>> What would that require git to do, beyond taking whatever you tell it
>> (using GIT_SSH or _GIT_SSH_COMMAND) to use as a drop in replacement for ssh?
>
> May be support git+mos
Hi Praveen "A",
On 2015-04-15 15:07, Pirate Praveen wrote:
> When working with big projects over a slow, unreliable connection,
> currently there is no way to resume a clone or pull when the connection
> breaks. mosh is a better replacement for ssh over unreliable
> connections. supporting g
On Wednesday 15 April 2015 07:22 PM, Michael J Gruber wrote:
> What would that require git to do, beyond taking whatever you tell it
> (using GIT_SSH or _GIT_SSH_COMMAND) to use as a drop in replacement for ssh?
>
> Michael
>
May be support git+mosh as a protocol, since it is not a drop in
repla
Pirate Praveen venit, vidit, dixit 15.04.2015 15:07:
> Hi,
>
> When working with big projects over a slow, unreliable connection,
> currently there is no way to resume a clone or pull when the connection
> breaks. mosh is a better replacement for ssh over unreliable
> connections. supporting git+
On wo, 2015-04-15 at 18:37 +0530, Pirate Praveen wrote:
> Hi,
>
> When working with big projects over a slow, unreliable connection,
> currently there is no way to resume a clone or pull when the connection
> breaks. mosh is a better replacement for ssh over unreliable
> connections. supporting g
Hi,
When working with big projects over a slow, unreliable connection,
currently there is no way to resume a clone or pull when the connection
breaks. mosh is a better replacement for ssh over unreliable
connections. supporting git+mosh protocol will go a long way in
supporting people who work wi
On 04/12/2015 04:55 PM, Yi, EungJun wrote:
> On Wed, Apr 8, 2015 at 8:08 PM, Tony Finch wrote:
>> Yi, EungJun wrote:
>>>
>>> I want a way to response a remote message when a client send any kind
>>> of request. Is it possible?
>>
>> Yes, though you need a wrapper around git. Recent versions of gi
Hi Vitaly,
On 2015-04-15 09:17, Vitaly wrote:
>>
>> feel free to give it a spin: https://git-for-windows.github.io/#download
>>
>
> I have installed msysgit 1.9.4, installing git for windows 2.3.5.8 (into
> default localtion and with "use from Windows command prompt")
Which version, 32-bit or
Disable the display of the progress if stderr is not the
current foreground process.
Still display the final result when done.
Signed-off-by: Luke Mewburn
Acked-by: Nicolas Pitre
---
progress.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/progress.
On 04/15/2015 12:25 AM, Stefan Beller wrote:
> The 'lock_fd' is the same as 'lk->fd'. No need to store it twice so remove
> it. You may argue this introduces more coupling as we need to know more
> about the internals of the lock file mechanism, but this will be solved in
> a later patch.
>
> No f
On 2015-04-14 23.49, Junio C Hamano wrote:
> * tg/perf-lib-test-perf-cleanup (2013-09-19) 2 commits
> - perf-lib: add test_perf_cleanup target
> - perf-lib: split starting the test from the execution
>
> Add test_perf_cleanup shell function to the perf suite, that allows
> the script writers t
Hi Junio,
On 2015-04-14 23:49, Junio C Hamano wrote:
>
> * jc/update-instead-into-void (2015-04-01) 1 commit
> (merged to 'next' on 2015-04-08 at 8ef4e15)
> + push-to-deploy: allow pushing into an unborn branch and updating it
>
> A push into an unborn branch, with "receive.denyCurrentBranch
Ping?
On Tue, Feb 10, Olaf Hering wrote:
> Ping?
>
> On Mon, Jan 26, Olaf Hering wrote:
>
> > ALL_LIBFILES uses wildcard, which provides the result in directory
> > order. This order depends on the underlying filesystem on the
> > buildhost. To get reproducible builds it is required to sort suc
On Tue, Apr 14, 2015 at 09:47:38PM -0700, Junio C Hamano wrote:
> Linus Torvalds writes:
> > Lookie here, I can reproduce it trivially with current git (in the git
> > repo itself):
> >
> > [torvalds@i7 git]$ date; git commit -m Test --allow-empty --date=now
> > Tue Apr 14 21:11:03 PDT 201
Linus Torvalds:
I can't be the only one seeing this? My guess is that there's a
missing initialization of tm.tm_isdst somewhere or whatever.
I can confirm it if I enable DST on my machine (I usually run my
machines on CET all-year, to avoid these kind of issues):
$ echo $TZ
Europe/Oslo
65 matches
Mail list logo
