On Fri, Jan 10, 2014 at 03:34:59PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > ... but the
> > failing test is actually somewhat broken in 'next' already.
>
> Hmph, in what way? I haven't seen t5531 breakage on 'next', with or
> without your series...
The test still passes, but it
I have a business Proposal for you.You can contact me on my private email:
(mrjerrynatai2...@manager.in.th)
--
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 Tue, Nov 19, 2013 at 11:43 PM, Junio C Hamano wrote:
> "Jason St. John" writes:
>
>> Documentation/git-rebase.txt: add a blank line after the two AsciiDoc
>> listing blocks
>
> That looks funnily formatted, out of place and redundant.
>
>> Without these blank lines, AsciiDoc thinks the ope
Ryan Biesemeyer writes:
> + write_script "$HOOK" <<-EOF &&
> + if [ -s "$(git rev-parse --git-dir)/MERGE_HEAD" ]; then
> + exit 0
> + else
> + exit 1
> + fi
> + EOF
The script can be a one-liner
write_scirpt "$HOOK" <<-\EOF &&
test -s
Ryan Biesemeyer writes:
> When merging, make the prepare-commit-msg hook have access to the merge
> state in order to make decisions about the commit message it is preparing.
What information is currently not available, and if available how
would that help the hook to formulate a better message?
Matthieu Moy writes:
> Ryan Biesemeyer writes:
>
>> + test_when_finished "git merge --abort" &&
>> + (
>> +git checkout -B other HEAD@{1} &&
>
> Weird indentation (space/tab mix).
Also I do not quite see why the body has to be in a subshell.
--
To unsubscribe from this list: send
Jeff King writes:
> ... but the
> failing test is actually somewhat broken in 'next' already.
Hmph, in what way? I haven't seen t5531 breakage on 'next', with or
without your series...
> fixes it, and should be done regardless of the other series.
>
> t/t5531-deep-submodule-push.sh | 1 +
> 1
Jonathan Nieder writes:
> There is no guarantee that strbuf_read_file must error out for
> directories. On some operating systems (e.g., Debian GNU/kFreeBSD
> wheezy), reading a directory gives its raw content:
>
> $ head -c5 < / | cat -A
> ^AM-|^_^@^L$
>
> As a result, 'git diff -O/
What's cooking in git.git (Jan 2014, #02; Fri, 10)
--
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
Quite a few topics have graduated to 'mas
From: "Junio C Hamano"
"Philip Oakley" writes:
From: "Junio C Hamano"
I think we already use a nicer way to set up a page alias to keep
old links working than making a copy in Documentation/; please mimic
that if possible.
This was mainly about ensuring that the 'git help' command could
a
I had to convert every file from windows line endings to unix line
endings with dos2unix (dos2unix was a separate install). I did that
with this command: find . -type f | xargs dos2unix
I also had to install: libiconv, gettext, expat, gettext-devel, expat-devel
That got my make -j8 to run withou
Hi,
Philip Oakley wrote:
> The "Everyday GIT With 20 Commands Or So" guide is not accessible
> via the git help system. Fix that.
Neat. :)
Junio covered everything I'd want to say about patch 1/6.
After fixing that, I'd suggest squashing all 6 patches into a single
patch. They all are part of
There is no guarantee that strbuf_read_file must error out for
directories. On some operating systems (e.g., Debian GNU/kFreeBSD
wheezy), reading a directory gives its raw content:
$ head -c5 < / | cat -A
^AM-|^_^@^L$
As a result, 'git diff -O/' succeeds instead of erroring out o
On 2014-01-10 20.28, Jonathan Nieder wrote:
> Dan Kaplan wrote:
>
>> Do you think it'll still work?
>
> Yes, that's why I suggested it. ;-)
>
> You might need to install the gcc-core, libcurl-devel, openssl-devel,
> and subversion-perl packages first.
>
> Regards,
>
Johannes Sixt writes:
> The file is renamed to no-such-dir without the slash at the end. The
> updated commit message would be:
>
> mv: let 'git mv file no-such-dir/' error out on Windows, too
>
> The previous commit c57f628 (mv: let 'git mv file no-such-dir/' error out)
> relies on that rename("
Dan Kaplan wrote:
> Do you think it'll still work?
Yes, that's why I suggested it. ;-)
You might need to install the gcc-core, libcurl-devel, openssl-devel,
and subversion-perl packages first.
Regards,
Jonathan
--
To unsubscribe from this list: send the line "unsubs
Am 09.01.2014 23:42, schrieb Junio C Hamano:
> Johannes Sixt writes:
>
>> The previous commit c57f628 (mv: let 'git mv file no-such-dir/' error out)
>> relies on that rename("src", "dst/") fails if directory dst does not
>> exist (note the trailing slash). This does not work as expected on Window
Because I'm on cygwin, that's a little intimidating to me. I've never
compiled sources on cygwin. Do you think it'll still work?
On Fri, Jan 10, 2014 at 11:16 AM, Jonathan Nieder wrote:
> Hi Dan,
>
> Dan Kaplan wrote:
>
>> My environment is probably different from most. I'm using cygwin.
>> Th
Hi Dan,
Dan Kaplan wrote:
> My environment is probably different from most. I'm using cygwin.
> This makes it very difficult to use different versions of
> git/svn/git-svn, but I'm interested in learning git more so I'm
> willing to try whatever it takes.
>
> $ git version
> git version 1.8.3.4
I found this mailing list thread discussing the problem I'm currently
experiencing:
http://git.661346.n2.nabble.com/Fwd-Error-with-git-svn-pushing-a-rename-td7599382.html
Apparently a patch was submitted to fix this bug and I'm trying to
figure out what version of what I need to fix this bug. Th
The diff information render the spec file unusable as is by p4,
do not include it when run with --prepare-p4-only so that the
given file can be directly passed to p4.
---
git-p4.py | 70 +++
1 file changed, 39 insertions(+), 31 deletions(
"Philip Oakley" writes:
> From: "Junio C Hamano"
>>I think we already use a nicer way to set up a page alias to keep
>> old links working than making a copy in Documentation/; please mimic
>> that if possible.
>
> This was mainly about ensuring that the 'git help' command could
> access these ex
Michael Haggerty writes:
> As for removing the third argument of refname_match(): although all
> callers pass it ref_ref_parse_rules, that array is sometimes passed to
> the function via the alias "ref_fetch_rules". So I suppose somebody
> wanted to leave the way open to make these two rule sets
Thank you :)
On 1/10/14, Thomas Gummerer wrote:
>
> Hi,
>
> Enno Weichert writes:
>> Hi,
>>
>> I'd like to have a more technical look into the index file and what/how
>> it
>> stores data; call it educational spelunking.
>>
>> I know the index-format.txt but I'd really like to save me the work t
On 01/10/2014 12:01 AM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> As long as we're being pathologically stingy with mallocs, we might as
>> well do the math right and save 6 (!) bytes.
>>
>> Signed-off-by: Michael Haggerty
>> ---
>> It is left to the reader to show how another 7 byte
Hello,
In mykernel repository, I'm having 2 different behaviours with git-log
but I don't understand why:
Doing:
$ git log --oneline --cherry-pick --left-right v3.4.71-1^{}...next
and
$ git log --oneline --cherry-pick --left-right v3.4.71-1...next
give something different (where v3.4.
Hi,
Enno Weichert writes:
> Hi,
>
> I'd like to have a more technical look into the index file and what/how it
> stores data; call it educational spelunking.
>
> I know the index-format.txt but I'd really like to save me the work to
> implement a pretty-printed output based on it.
> I know ls-fi
Hi,
I'd like to have a more technical look into the index file and what/how it
stores data; call it educational spelunking.
I know the index-format.txt but I'd really like to save me the work to
implement a pretty-printed output based on it.
I know ls-files but that's obviously not the whole thin
On Wed, Jan 08, 2014 at 05:09:25PM +0100, Michael Haggerty wrote:
> It's not only racy WRT other processes. If the current git process
> would create a new reference, it wouldn't be reflected in the cache.
>
> It's true that the main ref_cache doesn't invalidate itself
> automatically either whe
On Fri, Jan 10, 2014 at 09:59:25AM +0100, Michael Haggerty wrote:
> > However, is it safe to prime only part of the loose ref namespace?
> [...]
>
> prime_ref_dir() is called by do_for_each_entry(), which all the
> iteration functions pass through. It is always called before the
> iteration star
On 01/09/2014 10:49 PM, Jeff King wrote:
> On Wed, Jan 08, 2014 at 12:29:51PM +0100, Michael Haggerty wrote:
>
>>> Here's a fixed version of patch 3/5.
>>
>> v2 4/5 doesn't apply cleanly on top of v3 3/5. So I'm basing my review
>> on the branch you have at GitHub peff/git "jk/cat-file-warn-ambig
Am 10.01.2014 00:49, schrieb Junio C Hamano:
> I think we already use a nicer way to set up a page alias to keep
> old links working than making a copy in Documentation/; please mimic
> that if possible.
>
> It may be overdue to refresh the suggested set of "top 20" commands,
> as things have vast
From: "Junio C Hamano"
I think we already use a nicer way to set up a page alias to keep
old links working than making a copy in Documentation/; please mimic
that if possible.
This was mainly about ensuring that the 'git help' command could access
these extra extra guides that it currently mi
33 matches
Mail list logo