On Mon, Oct 27, 2014 at 6:32 PM, Junio C Hamano wrote:
> Jeff King writes:
>
>> If that is the only casualty, I think it is probably a net-win. We may
>> want better tooling around viewing the merge later, but that can wait
>> until somebody steps up with a real use case (because even that confli
To compare the old clone with the new, I did:
git branch -r | sort | xargs -n 1 git log --decorate=full -n 1
It turned out other than the empty vs 3 word commit messages
about two years ago on trunk (which are inherited in all the newer
branches), there are two other groups of differences.
One b
On Tue, Oct 28, 2014 at 5:46 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> This is not used anywhere yet. But the goal is to compare quickly if a
>> .gitignore file has changed when we have the SHA-1 of both old (cached
>> somewhere) and new (from index or a tree) versions.
>>
>>
I like René's approach, too. It's more flexible, supports the old
behaviour and it scratches my itch as well.
Don't mind if you dropped my patch and used René's instead.
>> Only *very* lightly tested, and a test for t/is missing anyway. Just
>> wanted to quickly show what I meant. You'd set colo
--
On Mon, Oct 27, 2014 16:56 GMT Eric Wong wrote:
>Eric Wong wrote:
>> Which SVN version are you using? I'm cloning (currently on r373xx)
>> https://svn.r-project.org/R using --stdlayout and
>> unable to see memory growth of the git-svn Perl process beyond 40M
>> (on
--
On Mon, Oct 27, 2014 06:38 GMT Eric Wong wrote:
>Which SVN version are you using? I'm cloning (currently on r373xx)
>https://svn.r-project.org/R using --stdlayout and
>unable to see memory growth of the git-svn Perl process beyond 40M
>(on a 32-bit system).
>
>I als
On Mon, Oct 27, 2014 at 09:52:31AM -0500, Ben Harper wrote:
> Thanks for the clarification. Someone in IRC mentioned the maintain-git.txt
> file. I skimmed it and searched for some keywords, but was unable to find
> the information I needed.
>
> Do you feel a RELEASES document is needed or is th
Nguyễn Thái Ngọc Duy writes:
> This is not used anywhere yet. But the goal is to compare quickly if a
> .gitignore file has changed when we have the SHA-1 of both old (cached
> somewhere) and new (from index or a tree) versions.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> dir.c | 50 ++
Jeff King wrote:
> For the most part, combined-diff (and --cc) will show the interesting
> cases anyway. But if you take a whole file from one side of the merge,
> then there is nothing interesting for diff to show. Do people still want
> to get that more complete list of potentially interesting f
Junio C Hamano writes:
>>> diff --git a/sequencer.c b/sequencer.c
>>> index 0f84bbe..1d97da3 100644
>>> --- a/sequencer.c
>>> +++ b/sequencer.c
>>> @@ -291,13 +291,12 @@ void append_conflicts_hint(struct strbuf *msgbuf)
>>> {
>>> int i;
>>>
>>> - strbuf_addstr(msgbuf, "\nConflicts:\n");
From: Roberto Decurnex
Making clear that `+` before a branch name will force the update even for
non-fast-forward branches.
Signed-off-by: Roberto Decurnex
---
Documentation/git-fetch.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-fetch.txt b/Documen
René Scharfe writes:
> That's by design -- extended headers are meant to be extracted as
> plain files by implementations that do not understand them.
>
> http://pubs.opengroup.org/onlinepubs/009695399/utilities/pax.html
> says: "If a particular implementation does not recognize the type, or
> th
Junio C Hamano writes:
> René Scharfe writes:
>
>> The config option color.grep.match can be used to specify the highlighting
>> color for matching strings. Add the options matchContext and matchSelected
>> to allow different colors to be specified for matching strings in the
>> context vs. in
René Scharfe writes:
> The config option color.grep.match can be used to specify the highlighting
> color for matching strings. Add the options matchContext and matchSelected
> to allow different colors to be specified for matching strings in the
> context vs. in selected lines. This is similar
Cong Wang writes:
> Let's say I want to fix a stupid typo in all of these commits, as
> simply as s/foo/bar/. Usually I use`git rebase -i` and `git commit
> --amend`, but both of them are interactive, apparently I don't want to
> edit them one by one. :)
Both can be scripted, though.
> I know I
Henning Moll writes:
> Just a final question: Is it possible to keep the GIT_COMMITTER_DATE in
> all those rebases?
If you want that you need to work with git filter-branch.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4
David Aguilar writes:
> +write_script .git/fail-right-file <<\EOF
> +echo "$2"
> +exit 1
> +EOF
This should be inside the next one, no?
> +test_expect_success PERL 'difftool stops on error with --trust-exit-code' '
> + >for-diff &&
> + git add for-diff &&
> + echo file>expect &&
> +
The config option color.grep.match can be used to specify the highlighting
color for matching strings. Add the options matchContext and matchSelected
to allow different colors to be specified for matching strings in the
context vs. in selected lines. This is similar to the ms and mc specifiers
in
Jeff King writes:
> On Sun, Oct 26, 2014 at 02:54:56PM -0400, David Michael wrote:
>
>> Yes, the compiler refuses to run by default when a "-L" option occurs
>> after a source/object file. It tries to interpret it as another file
>> name and fails.
>
> Yeah, I think I have seen similar behavior
David Aguilar writes:
>> diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh
>> index dc30a51..9cf5dc9 100755
>> --- a/t/t7800-difftool.sh
>> +++ b/t/t7800-difftool.sh
>> @@ -301,6 +301,14 @@ test_expect_success PERL 'say no to the second file' '
>> ! grep br2 output
>> '
>>
>> +test_e
Jeff King writes:
> Just to play devil's advocate for a moment, though, are we hurting
> people who find it useful to record that information in the commit
> message?
I thought about it, but ultimately, they are using it wrong if they
did depend on them. As you said, the paths themselves are no
Eric Wong wrote:
> Which SVN version are you using? I'm cloning (currently on r373xx)
> https://svn.r-project.org/R using --stdlayout and
> unable to see memory growth of the git-svn Perl process beyond 40M
> (on a 32-bit system).
git-svn hit 45M and took 11:44 to finish. My ping times to
svn.
Thanks for your rapid response - the weblink now works.
Stephen Voynar
Computer Scientist
Naval Surface Warfare Center Dahlgren
CBR Analysis, Testing, and Systems Engineering Branch (Z24)
ATTN Kaitlan Phillips
18372 Frontage Road, Suite 318, Dahlgren, VA 22448-5160
(540) 653-8199, DSN 249-8
Several weblinks located on your git website (http://git-scm.com/) have
broken links to the Documentation page (i.e. the links to
http://git-scm.com/documentation and http://git-scm.com/doc are yielding an
Internal Server Error).
Stephen Voynar
Computer Scientist
Naval Surface Warfare C
On 10/24/2014 04:56 PM, brian m. carlson wrote:
On Thu, Oct 23, 2014 at 05:15:21PM -0500, Ben Harper wrote:
Greetings,
I am unable to find any documentation regarding the life cycle regarding the
various versions of git. Is only the current version supported? What about
older minor/major vers
David Aguilar schrieb am 27.10.2014 um 02:10:
> On Sun, Oct 26, 2014 at 05:41:49PM -0700, David Aguilar wrote:
>> On Sun, Oct 26, 2014 at 09:09:20AM +0100, Johannes Sixt wrote:
>>> An attempt to quit difftool by hitting Ctrl-D (EOF) at its prompt does
>>> not quit it, but is treated as if 'yes' was
update_index_if_able() is moved down so that the updated untracked
cache could be written out.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/commit.c | 5 +++--
wt-status.c | 2 ++
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index 81d
Overall time saving on "git status" is about 40% in the best case
scenario, removing ..collect_untracked() as the most time consuming
function. read and refresh index operations are now at the top (which
should drop when index-helper and/or watchman support is added). More
numbers and analysis belo
When a directory is updated within the same second that its timestamp
is last saved, we cannot realize the directory has been updated by
checking timestamps. Assume the worst (something is update). See
29e4d36 (Racy GIT - 2005-12-20) for more information.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
This could be used to verify correct behavior in tests
Signed-off-by: Nguyễn Thái Ngọc Duy
---
dir.c | 12
1 file changed, 12 insertions(+)
diff --git a/dir.c b/dir.c
index 3eb1a12..57b49f7 100644
--- a/dir.c
+++ b/dir.c
@@ -1918,6 +1918,18 @@ int read_directory(struct dir_struct *
Signed-off-by: Nguyễn Thái Ngọc Duy
---
.gitignore | 1 +
Makefile | 1 +
t/t7063-status-untracked-cache.sh (new +x) | 353 +
test-dump-untracked-cache.c (new) | 61 +
4 files changed,
Signed-off-by: Nguyễn Thái Ngọc Duy
---
cache.h | 1 +
dir.c| 9 +
read-cache.c | 2 +-
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/cache.h b/cache.h
index 2b93217..dcbdc3c 100644
--- a/cache.h
+++ b/cache.h
@@ -296,6 +296,7 @@ static inline unsigned int ca
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-update-index.txt | 6 ++
builtin/update-index.c | 146 +
2 files changed, 152 insertions(+)
diff --git a/Documentation/git-update-index.txt
b/Documentation/git-update-index.txt
index 16f2
Ideally we should implement untracked_cache_remove_from_index() and
untracked_cache_add_to_index() so that they update untracked cache
right away instead of invalidating it and wait for read_directory()
next time to deal with it. But that may need some more work in
unpack-trees.c. So stay simple as
Signed-off-by: Nguyễn Thái Ngọc Duy
---
cache.h | 3 +++
dir.c| 85
dir.h| 1 +
read-cache.c | 12 +
4 files changed, 101 insertions(+)
diff --git a/cache.h b/cache.h
index 5b86065..4f903fa 100644
--- a/c
Signed-off-by: Nguyễn Thái Ngọc Duy
---
read-cache.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index feb10b0..a14646b 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -271,20 +271,26 @@ static int ce_match_stat_basic(c
Signed-off-by: Nguyễn Thái Ngọc Duy
---
dir.c| 147 +--
dir.h| 3 ++
read-cache.c | 5 ++
3 files changed, 151 insertions(+), 4 deletions(-)
diff --git a/dir.c b/dir.c
index d696388..c97b0c3 100644
--- a/dir.c
+++ b/dir.
The main readdir loop in read_directory_recursive() is replaced with a
new one that checks if cached results of a directory is still valid.
If a file is added or removed from the index, the containing directory
is invalidated (but not its subdirs). If directory's mtime is changed,
the same happens
This cuts down a signficant number of open(.gitignore) because most
directories usually don't have .gitignore files.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
dir.c | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/dir.c b/dir.c
index d9675c8..d4f9830 1
If we redo this thing in a functional style, we would have one struct
untracked_dir as input tree and another as output. The input is used
for verification. The output is a brand new tree, reflecting current
worktree.
But that means recreate a lot of dir nodes even if a lot could be
shared between
This allows us to feed different info to read_directory_recursive()
based on untracked cache in the next patch.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
dir.c | 55 +++
1 file changed, 47 insertions(+), 8 deletions(-)
diff --git a/dir.c b/dir.c
It's easy to see that if an existing .gitignore changes, its SHA-1
would be different and invalidate_gitignore() is called.
If .gitignore is removed, add_excludes() will treat it like an empty
.gitignore, which again should invalidate the cached directory data.
if .gitignore is added, lookup_untr
Make sure the starting conditions and all global exclude files are
good to go. If not, either disable untracked cache completely, or wipe
out the cache and start fresh.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
dir.c | 113 --
dir.h |
The idea is if we can capture all input and (non-rescursive) output of
read_directory_recursive(), and can verify later that all the input is
the same, then the second r_d_r() should produce the same output as in
the first run.
The requirement for this to work is stat info of a directory MUST
chan
The last post was five months ago [1]. It's probably time for a resend
in case I'm hit by a bus. Numbers are in 17/19, saving about 40% time
on "git status". Details are in 02/19 and 06/19. Still on the table:
- index-helper series [2] probably helps save about 10-15% in total
- watchman support
This is not used anywhere yet. But the goal is to compare quickly if a
.gitignore file has changed when we have the SHA-1 of both old (cached
somewhere) and new (from index or a tree) versions.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
dir.c | 50 +++---
Well, ok. Not very intuitive, so I added an alias in .gitconfig...
'ls = ls-files --exclude-standard' and that seems to work now alright for me.
Thanks
- Mail original -
> De: "Matthieu Moy"
> À: "Charles Bailey"
> Cc: "Richard PALO" , git@vger.kernel.org
> Envoyé: Lundi 27 Octobre 20
Dennis Kaarsemaker writes:
> On zo, 2014-10-26 at 22:27 -0700, Cong Wang wrote:
>>
>> My question is how to edit dozens of git commit changelogs
>> automatically?
>
> You can use git filter-branch in --msg-filter mode.
Note that in any case, you'll rewrite the history hence change commit
identi
Charles Bailey writes:
> On Mon, Oct 27, 2014 at 07:16:49AM +0100, Richard PALO wrote:
>> Hash: SHA1
>>
>> I'm having an issue in that 'git ls-files -o' seems to ignore
>> [parts of] .gitignore whereas other commands, such as 'git status'
>> seem fine.
>
> This is, as far as I am aware, by desig
49 matches
Mail list logo
