* [PATCH v2 0/9] fnmatch replacement step 1
From: Nguyễn Thái Ngọc Duy @ 2012-12-28 4:10 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
v2 has no big changes:
- 'special' variable in dowild() is removed in favor of two
new, better named ones
- fix TRUE/FALSE in comments as well as code in the rename patch
- some tests for "*/" and "*<literal>" optimizations
- USE_WILDMATCH patch is moved to the end of the series
Nguyễn Thái Ngọc Duy (9):
compat/fnmatch: respect NO_FNMATCH* even on glibc
wildmatch: replace variable 'special' with better named ones
wildmatch: rename constants and update prototype
wildmatch: make dowild() take arbitrary flags
wildmatch: support "no FNM_PATHNAME" mode
test-wildmatch: add "perf" command to compare wildmatch and fnmatch
wildmatch: make a special case for "*/" with FNM_PATHNAME
wildmatch: advance faster in <asterisk> + <literal> patterns
Makefile: add USE_WILDMATCH to use wildmatch as fnmatch
Makefile | 6 ++
compat/fnmatch/fnmatch.c | 3 +-
dir.c | 3 +-
git-compat-util.h | 13 +++++
t/t3070-wildmatch.sh | 41 +++++++++++++
test-wildmatch.c | 82 +++++++++++++++++++++++++-
wildmatch.c | 147 +++++++++++++++++++++++++++++------------------
wildmatch.h | 23 +++++---
8 files changed, 251 insertions(+), 67 deletions(-)
--
1.8.0.rc2.23.g1fb49df
^ permalink raw reply
* Re: git log commit limiting "show commits with >1 child" possible?
From: David @ 2012-12-28 3:15 UTC (permalink / raw)
To: git
In-Reply-To: <CAMPXz=rQxh3niOKiASZE3qqbYUEKXN6TscPsjPPoZjZLnCRpFA@mail.gmail.com>
CORRECTION:
So I hope to see:
* 00a27e0 J
| * 160d232 I
|/
* b981ea0 F
| * daa5b69 H
|/
* 546ae44 B
* 734db0c A
On 28/12/2012, David <bouncingcats@gmail.com> wrote:
> My branches are very long so for years I have been doing a lot of scrolling
> when using gitk. I have just now discovered how to see a simplified
> history.
>
> For this example history where commits were added in alphabetical order:
>
> A--B--C--D--H
> \
> E--F--G--I
> \
> J
>
> I do this:
>
> $ git log --graph --branches --simplify-by-decoration --source --oneline
> * 00a27e0 J
> | * 160d232 I
> |/
> | * daa5b69 H
> |/
> * 734db0c A
>
> and similar in gitk using the View > Edit View > Simple History = 1
> This is a great step forward for me! I am very happy with it.
>
> Is there any way to ask git log to additionally display all commits with
> more than one child, to show where each branch diverges?
>
> So I hope to see:
>
> * 00a27e0 J
> | * 160d232 I
> |/
> * b981ea0 G
> | * daa5b69 H
> |/
> * 546ae44 C
> * 734db0c A
>
> I have read man git-log but I do not understand it all. If there is a way
> to
> achieve this then I am not seeing it.
>
> I notice that there is commit limiting by --merges and --no-merges.
> If --merges means "show only commits with more than one parent", and
> --no-merges means "show only commits with only one parent", what I
> want is "show also commits with more than one child".
>
> Or perhaps "show only commits with more than one parent or child".
>
> Is there a way to do this? It will be nice if it also works in gitk.
> Presently I have git version 1.7.2.3
>
^ permalink raw reply
* git log commit limiting "show commits with >1 child" possible?
From: David @ 2012-12-28 3:12 UTC (permalink / raw)
To: git
My branches are very long so for years I have been doing a lot of scrolling
when using gitk. I have just now discovered how to see a simplified history.
For this example history where commits were added in alphabetical order:
A--B--C--D--H
\
E--F--G--I
\
J
I do this:
$ git log --graph --branches --simplify-by-decoration --source --oneline
* 00a27e0 J
| * 160d232 I
|/
| * daa5b69 H
|/
* 734db0c A
and similar in gitk using the View > Edit View > Simple History = 1
This is a great step forward for me! I am very happy with it.
Is there any way to ask git log to additionally display all commits with
more than one child, to show where each branch diverges?
So I hope to see:
* 00a27e0 J
| * 160d232 I
|/
* b981ea0 G
| * daa5b69 H
|/
* 546ae44 C
* 734db0c A
I have read man git-log but I do not understand it all. If there is a way to
achieve this then I am not seeing it.
I notice that there is commit limiting by --merges and --no-merges.
If --merges means "show only commits with more than one parent", and
--no-merges means "show only commits with only one parent", what I
want is "show also commits with more than one child".
Or perhaps "show only commits with more than one parent or child".
Is there a way to do this? It will be nice if it also works in gitk.
Presently I have git version 1.7.2.3
^ permalink raw reply
* [ANNOUNCE] Git v1.8.0.3
From: Junio C Hamano @ 2012-12-28 0:48 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
The latest maintenance release Git v1.8.0.3 is now available at
the usual places.
This is primarily to down-merge documentation updates that have been
accumulating to the 'master' front for the upcoming 1.8.1 to the
maintenance series.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
b1695f28448c00e61e110b3c7bcd66c8047ef176 git-1.8.0.3.tar.gz
83c46b62e0c3979c5ef77a407ca41507658b5726 git-htmldocs-1.8.0.3.tar.gz
63df55f90b9c6c11dd827ce1880b5b5fdf79c1c1 git-manpages-1.8.0.3.tar.gz
Also the following public repositories all have a copy of the v1.8.0.3
tag and the maint branch that the tag points at:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
Git v1.8.0.3 Release Notes
==========================
Fixes since v1.8.0.2
--------------------
* "git log -p -S<string>" did not apply the textconv filter while
looking for the <string>.
* In the documentation, some invalid example e-mail addresses were
formatted into mailto: links.
Also contains many documentation updates backported from the 'master'
branch that is preparing for the upcoming 1.8.1 release.
----------------------------------------------------------------
Changes since v1.8.0.2 are as follows:
Adam Spiers (2):
SubmittingPatches: add convention of prefixing commit messages
Documentation: move support for old compilers to CodingGuidelines
Anders Kaseorg (1):
git-prompt: Document GIT_PS1_DESCRIBE_STYLE
Chris Rorvick (2):
Documentation/git-checkout.txt: clarify usage
Documentation/git-checkout.txt: document 70c9ac2 behavior
Gunnlaugur Þór Briem (1):
Document git-svn fetch --log-window-size parameter
Jeff King (7):
pickaxe: hoist empty needle check
pickaxe: use textconv for -S counting
.mailmap: match up some obvious names/emails
.mailmap: fix broken entry for Martin Langhoff
.mailmap: normalize emails for Jeff King
.mailmap: normalize emails for Linus Torvalds
contrib: update stats/mailmap script
John Keeping (1):
Documentation: don't link to example mail addresses
Junio C Hamano (6):
fetch --tags: clarify documentation
README: it does not matter who the current maintainer is
t7004: do not create unneeded gpghome/gpg.conf when GPG is not used
Documentation: Describe "git diff <blob> <blob>" separately
git(1): show link to contributor summary page
Git 1.8.0.3
Krzysztof Mazur (1):
doc: git-reset: make "<mode>" optional
Manlio Perillo (1):
git.txt: add missing info about --git-dir command-line option
Matthew Daley (1):
Fix sizeof usage in get_permutations
Max Horn (1):
git-remote-helpers.txt: document invocation before input format
Nguyễn Thái Ngọc Duy (1):
index-format.txt: clarify what is "invalid"
Ramkumar Ramachandra (1):
Documentation: move diff.wordRegex from config.txt to diff-config.txt
Sebastian Leske (4):
git-svn: Document branches with at-sign(@).
git-svn: Recommend use of structure options.
git-svn: Expand documentation for --follow-parent
git-svn: Note about tags.
Sitaram Chamarty (1):
clarify -M without % symbol in diff-options
Stefano Lattarini (1):
README: Git is released under the GPLv2, not just "the GPL"
Thomas Ackermann (8):
Split over-long synopsis in git-fetch-pack.txt into several lines
Shorten two over-long lines in git-bisect-lk2009.txt by abbreviating some sha1
Change headline of technical/send-pack-pipeline.txt to not confuse its content with content from git-send-pack.txt
Documentation/technical: convert plain text files to asciidoc
Documentation/howto: convert plain text files to asciidoc
Documentation: build html for all files in technical and howto
Remove misleading date from api-index-skel.txt
Sort howto documents in howto-index.txt
Tom Jones (1):
Add -S, --gpg-sign option to manpage of "git commit"
^ permalink raw reply
* Lockless Refs? (Was [PATCH] refs: do not use cached refs in repack_without_ref)
From: Martin Fick @ 2012-12-27 23:11 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Jeff King, git, Junio C Hamano
In-Reply-To: <50DAB447.8000101@alum.mit.edu>
On Wednesday, December 26, 2012 01:24:39 am Michael Haggerty
wrote:
> ... lots of discussion about ref locking...
It concerns me that git uses any locking at all, even for
refs since it has the potential to leave around stale locks.
For a single user repo this is not a big deal, the lock can
always be cleaned up manually (and it is a rare occurrence).
However, in a multi user server environment, possibly even
from multiple hosts over a shared filesystem such as NFS,
stale locks could lead to serious downtime and risky recovery
(since it is currently hard to figure out if a lock really is
stale). Even though stale locks are probably rare even today
in the larger shared repo case, as git scales to even larger
shared repositories, this will eventually become more of a
problem *1. Naturally, this has me thinking that git should
possibly consider moving towards a lockless design for refs
in the long term.
I realize this is hard and that git needs to support many
different filesystems with different semantics. I had an idea I
think may be close to a functional lockless design for loose
refs (one piece at a time) that I thought I should propose,
just to get the ball rolling, even if it is just going to be
found to be flawed (I realize that history suggests that such
schemes usually are). I hope that it does not make use of
any semantics which are not currently expected from git of
filesystems. I think it relies only on the ability to rename
a file atomically, and the ability to scan the contents of a
directory reliably to detect the "ordered" existence of files.
My idea is based on using filenames to store sha1s instead of
file contents. To do this, the sha1 one of a ref would be
stored in a file in a directory named after the loose ref. I
believe this would then make it possible to have lockless
atomic ref updates by renaming the file.
To more fully illustrate the idea, imagine that any file
(except for the null file) in the directory will represent the
value of the ref with its name, then the following
transitions can represent atomic state changes to a refs
value and existence:
1) To update the value from a known value to a new value
atomically, simply rename the file to the new value. This
operation should only succeed if the file exists and is still
named old value before the rename. This should even be
faster than today's approach, especially on remote filesystems
since it would require only 1 round trip in the success case
instead of 3!
2) To delete the ref, simply delete the filename representing
the current value of the ref. This ensures that you are
deleting the ref from a specific value. I am not sure if git
needs to be able to delete refs without knowing their values?
If so, this would require reading the value and looping until
the delete succeeds, this may be a bit slow for a constantly
updated ref, but likely a rare situation (and not likely
worse than trying to acquire the ref-lock today). Overall,
this again would likely be faster than today's approach.
3) To create a ref, it must be renamed from the null file (sha
0000...) to the new value just as if it were being updated
from any other value, but there is one extra condition:
before renaming the null file, a full directory scan must be
done to ensure that the null file is the only file in the
directory (this condition exists because creating the
directory and null file cannot be atomic unless the filesystem
supports atomic directory renames, an expectation git does
not currently make). I am not sure how this compares to
today's approach, but including the setup costs (described
below), I suspect it is slower.
While this outlines the state changes, some additional
operations may be needed to setup some starting conditions
and to clean things up. But these operations could/should be
performed by any process/thread and would not cause any state
changes to the ref existence or value. For example, when
creating a ref, the ref directory would need to be created
and the null file needs to be created. Whenever a null file is
detected in the directory at the same time as another file, it
should be deleted. Whenever the directory is empty, it may
be deleted (perhaps after a grace period to reduce retries
during ref creation unless the process just deleted the ref).
I don't know how this new scheme could be made to work with
the current scheme, it seems like perhaps new git releases
could be made to understand both the old and the new, and a
config option could be used to tell it which method to write
new refs with. Since in this new scheme ref directory names
would conflict with old ref filenames, this would likely
prevent both schemes from erroneously being used
simultaneously (so they shouldn't corrupt each other), except
for the fact that refs can be nested in directories which
confuses things a bit. I am not sure what a good solution to
this is?
What did I miss, where are my flaws? Does anyone else share
my concern for stale locks? How could we similarly eliminate
locks for the packed-refs file?
-Martin
*1 We have been concerned with stale locks in the Gerrit
community when trying to design atomic cross repository
updates. Of course, while a lockless solution eliminates
stale locks, it might make it impossible to do atomic cross
repository updates since all of our solutions so far need
locks. :(
^ permalink raw reply
* Re: Python version auditing followup
From: Dennis Kaarsemaker @ 2012-12-27 21:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric S. Raymond, git
In-Reply-To: <7vobho60fs.fsf@alter.siamese.dyndns.org>
On do, 2012-12-20 at 10:30 -0800, Junio C Hamano wrote:
> Which platforms that are long-term-maintained by their vendors still
> pin their Python at 2.4.X?
RHEL 5.x and its clones still use python 2.4. It is supported by red hat
until at least 2017 (though end of production phase two, Q1 2014, seems
like a reasonable cut-off point).
--
Dennis Kaarsemaker
^ permalink raw reply
* Re: "fatal: git-write-tree: error building trees" from `git stash`
From: Junio C Hamano @ 2012-12-27 20:11 UTC (permalink / raw)
To: Jeff King; +Cc: Alex Vandiver, git discussion list
In-Reply-To: <20121227190542.GB28811@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> but I suspect it is not sufficient:
>
> 1. There are other code paths that will end up in write-tree which
> should probably be protected, too.
Among 6 calls to write-tree, only the first ones in create_stash and
apply_stash are about the index the user originally had. If the
only expected failure case is unmerged entries, it should be
sufficient to protect these two (and the one in apply_stash is
already covered, I think).
> 2. Unmerged entries are only one reason that write-tree might fail.
> It's OK not to catch them all (since ultimately write-tree will
> complain if need be), but we may want to also handle intent-to-add
> entries with a nicer message.
Hrmph.
We used to fail write-tree when I-T-A entries existed and relied on
that behaviour to implement "no state lost"; as we broke write-tree
recently by allowing to write a tree out by pretending that I-T-A
entries do not exist, I think we broke it. Stashing with I-T-A and
then unstashing it may lose the file. Sigh...
^ permalink raw reply
* Re: "fatal: git-write-tree: error building trees" from `git stash`
From: Junio C Hamano @ 2012-12-27 19:21 UTC (permalink / raw)
To: Alex Vandiver; +Cc: git discussion list
In-Reply-To: <1356634556.13818.136.camel@umgah.localdomain>
Alex Vandiver <alex@chmrr.net> writes:
> ... "Cannot stash while resolving conflicts" or similar would be
> more understandable to the end user than the above.
Interestingly enough, the "apply" side is protected with this one
liner:
# current index state
c_tree=$(git write-tree) ||
die "$(gettext "Cannot apply a stash in the middle of a merge")"
since 5fd448f (git stash: Give friendlier errors when there is
nothing to apply, 2009-08-11). I would think something in line with
that change on the "create" side is a welcome one.
Thanks.
^ permalink raw reply
* Re: "fatal: git-write-tree: error building trees" from `git stash`
From: Jeff King @ 2012-12-27 19:05 UTC (permalink / raw)
To: Alex Vandiver; +Cc: Junio C Hamano, git discussion list
In-Reply-To: <1356634556.13818.136.camel@umgah.localdomain>
On Thu, Dec 27, 2012 at 01:55:56PM -0500, Alex Vandiver wrote:
> On Thu, 2012-12-27 at 10:51 -0800, Junio C Hamano wrote:
> > > $ git stash
> > > foo: needs merge
> > > foo: needs merge
> > > foo: unmerged (aeaa7e5e87cf309a7368d5d92a71c1f9e6a8c9e7)
> > > foo: unmerged (a77fa514de2720c72c1a861de098595959a2c97a)
> > > foo: unmerged (4a622d2b991f1a19ba7be313a46dc6f03692cd0a)
> > > fatal: git-write-tree: error building trees
> > > Cannot save the current index state
> >
> > This is totally expected, isn't it?
> >
> > You do not save state in the middle of a conflict with "git stash"
> > (instead, you would "git stash" away your own work in progress
> > before you start operation that may create and leave conflicts).
>
> Apologies for not being clear. While being unable to stash is not
> unexpected, perhaps, "Cannot stash while resolving conflicts" or similar
> would be more understandable to the end user than the above.
Yeah, I think the outcome is reasonable, but that message is just
horrible. Something like this might be better:
diff --git a/git-stash.sh b/git-stash.sh
index 688e259..7ea425c 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -217,6 +217,12 @@ save_stash () {
stash_msg="$*"
+ if ! git diff-index --cached --diff-filter=U --quiet HEAD; then
+ echo >&2 "fatal: unable to stash unmerged entries:"
+ git diff-index --cached --diff-filter=U --name-status HEAD
+ exit 1
+ fi
+
git update-index -q --refresh
if no_changes
then
but I suspect it is not sufficient:
1. There are other code paths that will end up in write-tree which
should probably be protected, too.
2. Unmerged entries are only one reason that write-tree might fail.
It's OK not to catch them all (since ultimately write-tree will
complain if need be), but we may want to also handle intent-to-add
entries with a nicer message.
-Peff
^ permalink raw reply related
* Re: "fatal: git-write-tree: error building trees" from `git stash`
From: Alex Vandiver @ 2012-12-27 18:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git discussion list
In-Reply-To: <7vsj6rl456.fsf@alter.siamese.dyndns.org>
On Thu, 2012-12-27 at 10:51 -0800, Junio C Hamano wrote:
> > $ git stash
> > foo: needs merge
> > foo: needs merge
> > foo: unmerged (aeaa7e5e87cf309a7368d5d92a71c1f9e6a8c9e7)
> > foo: unmerged (a77fa514de2720c72c1a861de098595959a2c97a)
> > foo: unmerged (4a622d2b991f1a19ba7be313a46dc6f03692cd0a)
> > fatal: git-write-tree: error building trees
> > Cannot save the current index state
>
> This is totally expected, isn't it?
>
> You do not save state in the middle of a conflict with "git stash"
> (instead, you would "git stash" away your own work in progress
> before you start operation that may create and leave conflicts).
Apologies for not being clear. While being unable to stash is not
unexpected, perhaps, "Cannot stash while resolving conflicts" or similar
would be more understandable to the end user than the above.
- Alex
^ permalink raw reply
* Re: "fatal: git-write-tree: error building trees" from `git stash`
From: Junio C Hamano @ 2012-12-27 18:51 UTC (permalink / raw)
To: Alex Vandiver; +Cc: git discussion list
In-Reply-To: <1356631626.13818.126.camel@umgah.localdomain>
Alex Vandiver <alex@chmrr.net> writes:
> Heya,
> I just ran into the following with `git stash`. The set-up:
> ...
> $ git stash pop
> Auto-merging foo
> CONFLICT (content): Merge conflict in foo
> Recorded preimage for 'foo'
>
> $ git stash
> foo: needs merge
> foo: needs merge
> foo: unmerged (aeaa7e5e87cf309a7368d5d92a71c1f9e6a8c9e7)
> foo: unmerged (a77fa514de2720c72c1a861de098595959a2c97a)
> foo: unmerged (4a622d2b991f1a19ba7be313a46dc6f03692cd0a)
> fatal: git-write-tree: error building trees
> Cannot save the current index state
This is totally expected, isn't it?
You do not save state in the middle of a conflict with "git stash"
(instead, you would "git stash" away your own work in progress
before you start operation that may create and leave conflicts).
^ permalink raw reply
* Re: [PATCH v2] log: grep author/committer using mailmap
From: Junio C Hamano @ 2012-12-27 18:48 UTC (permalink / raw)
To: Antoine Pelisse; +Cc: git
In-Reply-To: <7v1uebmizx.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Thanks. I'll queue this on top.
>
> -- >8 --
> Subject: [PATCH] log --use-mailmap: optimize for cases without --author/--committer search
And this I will *not* queue further on top.
-- >8 --
Subject: [PATCH] [DO NOT USE] log --use-mailmap --author/--committer: further
optimize identity rewriting
We used to always allocate a temporary buffer to search for
author/committer names even when the author/committer does not
appear in the mailmap. Update the logic to do the allocation
on demand to reduce needless malloc()/free() calls.
It turns out that this does not affect performance at all; all the
time is spent in map_user() which is a look-up in string_list, so
let's not use this patch in the production, but it illustrates an
interesting point.
In map_identities() function, we already know who the author
recorded in the commit is, either in "author" strbuf, or in buffer
between [a_at..a_len], so we could grep_buffer() the author
regexp(s) specified from the command line right there, and combine
that result with the main grep_buffer() done for the --grep= option
at the end of the commit_match() function.
That may essentially amount to going in the totally opposite
direction from what 2d10c55 (git log: Unify header_filter and
message_filter into one., 2006-09-20) attempted to do. We used to
have two grep expressions (one for header, the other one for body)
commit_match() runs grep_buffer() on and combined the results.
2d10c55 merged them into one grep expression by introducing a term
that matches only header elements. But we would instead split the
"header" expression into "author" and "committer" expressions
(making it three from one) if we go that route.
In any case, I *think* the bottleneck is in map_user() so until that
is solved, such an update (or this patch) is not very useful.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
revision.c | 95 +++++++++++++++++++++++++++++++++++++-------------------------
1 file changed, 57 insertions(+), 38 deletions(-)
diff --git a/revision.c b/revision.c
index 56b72f7..4b66598 100644
--- a/revision.c
+++ b/revision.c
@@ -2220,49 +2220,73 @@ static int rewrite_parents(struct rev_info *revs, struct commit *commit)
return 0;
}
-static int commit_rewrite_person(struct strbuf *buf, const char *what, struct string_list *mailmap)
+static void map_person(const char *buf, size_t len, const char *head, int headlen,
+ struct strbuf *result, struct string_list *mailmap,
+ int *matchofs, int *matchlen)
{
- char *person, *endp;
- size_t len;
+ struct ident_split ident;
+ const char *endp, *person;
struct strbuf name = STRBUF_INIT;
struct strbuf mail = STRBUF_INIT;
- struct ident_split ident;
- person = strstr(buf->buf, what);
+ person = memmem(buf, len, head, headlen);
if (!person)
- goto left_intact;
-
- person += strlen(what);
+ return;
+ person += headlen;
endp = strchr(person, '\n');
if (!endp)
- goto left_intact;
-
- len = endp - person;
-
- if (split_ident_line(&ident, person, len))
- goto left_intact;
-
+ return;
+ *matchofs = person - buf;
+ *matchlen = endp - person;
+ if (split_ident_line(&ident, person, *matchlen))
+ return;
strbuf_add(&name, ident.name_begin, ident.name_end - ident.name_begin);
strbuf_add(&mail, ident.mail_begin, ident.mail_end - ident.mail_begin);
-
- if (map_user(mailmap, &mail, &name)) {
- strbuf_addf(&name, " <%s>", mail.buf);
-
- strbuf_splice(buf, ident.name_begin - buf->buf,
- ident.mail_end - ident.name_begin + 1,
- name.buf, name.len);
-
- strbuf_release(&name);
- strbuf_release(&mail);
-
- return 1;
- }
-
-left_intact:
+ if (map_user(mailmap, &mail, &name))
+ strbuf_addf(result, "%s <%s>", name.buf, mail.buf);
strbuf_release(&name);
strbuf_release(&mail);
+}
- return 0;
+static void map_identities(struct strbuf *buf, const char *buffer, struct string_list *mailmap)
+{
+ const char *eob;
+ struct strbuf author = STRBUF_INIT;
+ struct strbuf committer = STRBUF_INIT;
+ int a_at = -1, a_len, c_at = -1, c_len;
+
+ eob = strstr(buffer, "\n\n");
+ if (!eob)
+ eob = buffer + strlen(buffer);
+ map_person(buffer, eob - buffer, "\nauthor ", 8, &author, mailmap,
+ &a_at, &a_len);
+ map_person(buffer, eob - buffer, "\ncommitter ", 11, &committer, mailmap,
+ &c_at, &c_len);
+ if (!author.len && !committer.len)
+ goto done;
+
+ /* Now, we know we need rewriting */
+ if (!buf->len)
+ strbuf_addstr(buf, buffer);
+
+ if (c_at < 0 || !committer.len) {
+ strbuf_splice(buf, a_at, a_len, author.buf, author.len);
+ } else if (a_at < 0 || !author.len) {
+ strbuf_splice(buf, c_at, c_len, committer.buf, committer.len);
+ } else if (a_at < c_at) {
+ strbuf_splice(buf, c_at, c_len, committer.buf, committer.len);
+ strbuf_splice(buf, a_at, a_len, author.buf, author.len);
+ } else {
+ /*
+ * The commit records committer before the author, which is malformed,
+ * which we may want to warn about.
+ */
+ strbuf_splice(buf, a_at, a_len, author.buf, author.len);
+ strbuf_splice(buf, c_at, c_len, committer.buf, committer.len);
+ }
+ done:
+ strbuf_release(&author);
+ strbuf_release(&committer);
}
static int commit_match(struct commit *commit, struct rev_info *opt)
@@ -2283,13 +2307,8 @@ static int commit_match(struct commit *commit, struct rev_info *opt)
if (buf.len)
strbuf_addstr(&buf, commit->buffer);
- if (opt->grep_filter.header_list && opt->mailmap) {
- if (!buf.len)
- strbuf_addstr(&buf, commit->buffer);
-
- commit_rewrite_person(&buf, "\nauthor ", opt->mailmap);
- commit_rewrite_person(&buf, "\ncommitter ", opt->mailmap);
- }
+ if (opt->grep_filter.header_list && opt->mailmap)
+ map_identities(&buf, commit->buffer, opt->mailmap);
/* Append "fake" message parts as needed */
if (opt->show_notes) {
--
1.8.1.rc3.221.g8d09d94
^ permalink raw reply related
* Re: [PATCH v2] log: grep author/committer using mailmap
From: Junio C Hamano @ 2012-12-27 18:45 UTC (permalink / raw)
To: Antoine Pelisse; +Cc: git
In-Reply-To: <1356622318-19523-1-git-send-email-apelisse@gmail.com>
Antoine Pelisse <apelisse@gmail.com> writes:
> Currently you can use mailmap to display log authors and committers
> but you can't use the mailmap to find commits with mapped values.
>
> This commit allows you to run:
>
> git log --use-mailmap --author mapped_name_or_email
> git log --use-mailmap --committer mapped_name_or_email
>
> Of course it only works if the --use-mailmap option is used.
>
> Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
> ---
Thanks. I'll queue this on top.
-- >8 --
Subject: [PATCH] log --use-mailmap: optimize for cases without --author/--committer search
When we taught the commit_match() mechanism to pay attention to the
new --use-mailmap option, we started to unconditionally copy the
commit object to a temporary buffer, just in case we need the author
and committer lines updated via the mailmap mechanism.
It turns out that this has a rather unpleasant performance
implications. In the linux kernel repository, running
$ git log --author='Junio C Hamano' --pretty=short >/dev/null
under /usr/bin/time, with and without --use-mailmap (the .mailmap
file is 118 entries long, the particular author does not appear in
it), cost (with warm cache):
[without --use-mailmap]
5.34user 0.25system 0:05.60elapsed 100%CPU (0avgtext+0avgdata 2004832maxresident)k
0inputs+0outputs (0major+137600minor)pagefaults 0swaps
[with --use-mailmap]
6.87user 0.24system 0:07.11elapsed 99%CPU (0avgtext+0avgdata 2006352maxresident)k
0inputs+0outputs (0major+137696minor)pagefaults 0swaps
which is with about 29% overhead. The command is doing extra work,
so the extra cost may be justified.
But it is inexcusable to pay the cost when we do not need
author/committer match. In the same repository,
$ git log --grep='fix menuconfig on debian lenny' --pretty=short >/dev/null
shows very similar numbers as the above:
[without --use-mailmap]
5.30user 0.24system 0:05.55elapsed 99%CPU (0avgtext+0avgdata 2004896maxresident)k
0inputs+0outputs (0major+137604minor)pagefaults 0swaps
[with --use-mailmap]
6.82user 0.26system 0:07.07elapsed 100%CPU (0avgtext+0avgdata 2006352maxresident)k
0inputs+0outputs (0major+137697minor)pagefaults 0swaps
The latter case is an unnecessary performance regression. We may
want to _show_ the result with mailmap applied, but we do not have
to copy and rewrite the author/committer of all commits we try to
match if we do not query for these fields.
Trivially optimize this performace regression by limiting the
rewrites for only when we are matching with author/committer fields.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
revision.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/revision.c b/revision.c
index fa16b9d..56b72f7 100644
--- a/revision.c
+++ b/revision.c
@@ -2283,7 +2283,7 @@ static int commit_match(struct commit *commit, struct rev_info *opt)
if (buf.len)
strbuf_addstr(&buf, commit->buffer);
- if (opt->mailmap) {
+ if (opt->grep_filter.header_list && opt->mailmap) {
if (!buf.len)
strbuf_addstr(&buf, commit->buffer);
--
1.8.1.rc3.221.g8d09d94
^ permalink raw reply related
* "fatal: git-write-tree: error building trees" from `git stash`
From: Alex Vandiver @ 2012-12-27 18:07 UTC (permalink / raw)
To: git discussion list
Heya,
I just ran into the following with `git stash`. The set-up:
git init
echo "Initial" > foo
git add .
git commit -m 'Initial commit'
echo "Rewrite" > foo
git commit -am 'Second commit, rewrites content'
echo "Stashed changes" >> foo
git stash
git co HEAD~
$ git stash pop
Auto-merging foo
CONFLICT (content): Merge conflict in foo
Recorded preimage for 'foo'
$ git stash
foo: needs merge
foo: needs merge
foo: unmerged (aeaa7e5e87cf309a7368d5d92a71c1f9e6a8c9e7)
foo: unmerged (a77fa514de2720c72c1a861de098595959a2c97a)
foo: unmerged (4a622d2b991f1a19ba7be313a46dc6f03692cd0a)
fatal: git-write-tree: error building trees
Cannot save the current index state
- Alex
^ permalink raw reply
* Re: [PATCH v2] wt-status: Show ignored files in untracked dirs
From: Antoine Pelisse @ 2012-12-27 17:35 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20121227161920.GA28162@sigill.intra.peff.net>
> By "committed", I assume you meat that you have "dirA/unco" as an
> untracked file, and "dirA/committed" as a file in the index?
Of course,
> Thanks for putting this together. I agree with the expected output in
> each case, and I think this covers the cases we have seen (case 1 is
> Michael's original report, case 2 is what I wrote in my mail, and case 3
> is the one you just came up with). I can't think offhand of any others.
Great, so I can build some tests reflecting those behaviors while
waiting more inputs
^ permalink raw reply
* Re: [PATCH] gitk: Replaced "green" with "#00FF00".
From: Junio C Hamano @ 2012-12-27 17:27 UTC (permalink / raw)
To: Peter Hofmann; +Cc: git, Paul Mackerras
In-Reply-To: <20121227125916.GC7039@mobiltux>
Peter Hofmann <git-dev@uninformativ.de> writes:
> Subject: Re: [PATCH] gitk: Replaced "green" with "#00FF00".
That should be
Subject: [PATCH] gitk: replace "green" with "#00FF00"
around here. Instead of reporting what you did in the past tense,
you give an order to somebody to do something to make the codebase
into more desirable shape, without the final full-stop.
> The definition of "green" has changed in Tk 8.6:
>
> - http://wiki.tcl.tk/21276
> - http://www.tcl.tk/cgi-bin/tct/tip/403
Concise reference to the background information is very much
appreciated. It would have been even nicer if you wrote one line
summary of it, e.g. "This change was to make Tk applications more in
line with Web standard colors."
> gitk looks pretty awkward with Tk 8.6. "green" is simply too dark now
> because it has changed from "#00FF00" to "#008000".
Your observation "awkward" is somewhat subjective and I am hesitant
to recommend this change without a better justification. Given the
reasoning behind the change Tcl/Tk people made, I wouldn't be
surprised if people coming from webapp world view the "green" color
rendered by updated Tcl/Tk more natural.
Besides, if we are declaring with this patch that we will stick to
X11 colors and will not adopt W3C colors, the patch shouldn't update
only "green", but set all the other colors in stone, no? "purple",
for example, is also different between X11 and W3C.
> One could also use "lime" instead of "#00FF00" but that would break
> compatibility with older versions of Tk.
A better solution might be to make these colors customizable.
> Signed-off-by: Peter Hofmann <git-dev@uninformativ.de>
> ---
> gitk-git/gitk | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
Please make gitk patches against
url = git://ozlabs.org/~paulus/gitk.git
which is my upstream maintained by Paul Mackerras <paulus@samba.org>
(cc'ed) and keep him in the loop.
A patch against Paul's tree would have these lines
> diff --git a/gitk-git/gitk b/gitk-git/gitk
> index d93bd99..d7e922b 100755
> --- a/gitk-git/gitk
> +++ b/gitk-git/gitk
without "/gitk-git".
Thanks.
^ permalink raw reply
* Re: [PATCH v2] wt-status: Show ignored files in untracked dirs
From: Antoine Pelisse @ 2012-12-27 16:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7va9t0m69o.fsf@alter.siamese.dyndns.org>
> Nicely analysed. Perhaps we would want new test pieces to define
> the behaviour we want to see first?
I think we should.
I also thought about the use case of "committed" and ignored directory
which is also broken to me (point 3 in the table below).
Anyway I tried to make a table to sum-up/discuss the list of behaviors
we would like to see/test, taking Jeff mail into account.
(warning: that requires fixed width font)
|----------------------+---------------------+---------------------------|
| Output | A. status --ignored | B. status --ignored -uall |
| | | (or with potential |
| | | --ignored=all) |
|----------------------+---------------------+---------------------------|
| 1. Untracked dirU | Current: | Current: |
| with ignored unco.ig | Empty | Empty |
| in it | | |
| | Expected: | Expected: |
| | !!dirU/ | !!dirU/unco.ig |
|----------------------+---------------------+---------------------------|
| 2. Untracked and | Current (OK): | Current: |
| ignored dirU with | !!dirU/ | !!dirU/ |
| file in it | | |
| | | Expected: |
| | | !!dirU/unco |
|----------------------+---------------------+---------------------------|
| 3. "Committed" dirA | Current: | Current: |
| yet ignored | Empty | Empty |
| with uncommitted | | |
| file in it | Expected: | Expected: |
| | dirA/ | dirA/unco |
|----------------------+---------------------+---------------------------|
^ permalink raw reply
* Re: [PATCH v2] wt-status: Show ignored files in untracked dirs
From: Jeff King @ 2012-12-27 16:19 UTC (permalink / raw)
To: Antoine Pelisse; +Cc: Junio C Hamano, git
In-Reply-To: <CALWbr2wFg_9oDoZ_BUQwAzVV+UJSqBQRrMYmt6fv=fo02RL7Zg@mail.gmail.com>
On Thu, Dec 27, 2012 at 05:14:54PM +0100, Antoine Pelisse wrote:
> > Nicely analysed. Perhaps we would want new test pieces to define
> > the behaviour we want to see first?
>
> I think we should.
>
> I also thought about the use case of "committed" and ignored directory
> which is also broken to me (point 3 in the table below).
By "committed", I assume you meat that you have "dirA/unco" as an
untracked file, and "dirA/committed" as a file in the index?
> Anyway I tried to make a table to sum-up/discuss the list of behaviors
> we would like to see/test, taking Jeff mail into account.
> (warning: that requires fixed width font)
>
> |----------------------+---------------------+---------------------------|
> | Output | A. status --ignored | B. status --ignored -uall |
> | | | (or with potential |
> | | | --ignored=all) |
> |----------------------+---------------------+---------------------------|
> | 1. Untracked dirU | Current: | Current: |
> | with ignored unco.ig | Empty | Empty |
> | in it | | |
> | | Expected: | Expected: |
> | | !!dirU/ | !!dirU/unco.ig |
> |----------------------+---------------------+---------------------------|
> | 2. Untracked and | Current (OK): | Current: |
> | ignored dirU with | !!dirU/ | !!dirU/ |
> | file in it | | |
> | | | Expected: |
> | | | !!dirU/unco |
> |----------------------+---------------------+---------------------------|
> | 3. "Committed" dirA | Current: | Current: |
> | yet ignored | Empty | Empty |
> | with uncommitted | | |
> | file in it | Expected: | Expected: |
> | | dirA/ | dirA/unco |
> |----------------------+---------------------+---------------------------|
Thanks for putting this together. I agree with the expected output in
each case, and I think this covers the cases we have seen (case 1 is
Michael's original report, case 2 is what I wrote in my mail, and case 3
is the one you just came up with). I can't think offhand of any others.
-Peff
^ permalink raw reply
* [PATCH v2] log: grep author/committer using mailmap
From: Antoine Pelisse @ 2012-12-27 15:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Antoine Pelisse
In-Reply-To: <7vy5gkmr53.fsf@alter.siamese.dyndns.org>
Currently you can use mailmap to display log authors and committers
but you can't use the mailmap to find commits with mapped values.
This commit allows you to run:
git log --use-mailmap --author mapped_name_or_email
git log --use-mailmap --committer mapped_name_or_email
Of course it only works if the --use-mailmap option is used.
Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
---
revision.c | 54 ++++++++++++++++++++++++++++++++++++++++++++++++++++
t/t4203-mailmap.sh | 18 ++++++++++++++++++
2 files changed, 72 insertions(+)
diff --git a/revision.c b/revision.c
index 95d21e6..fa16b9d 100644
--- a/revision.c
+++ b/revision.c
@@ -13,6 +13,7 @@
#include "decorate.h"
#include "log-tree.h"
#include "string-list.h"
+#include "mailmap.h"
volatile show_early_output_fn_t show_early_output;
@@ -2219,6 +2220,51 @@ static int rewrite_parents(struct rev_info *revs, struct commit *commit)
return 0;
}
+static int commit_rewrite_person(struct strbuf *buf, const char *what, struct string_list *mailmap)
+{
+ char *person, *endp;
+ size_t len;
+ struct strbuf name = STRBUF_INIT;
+ struct strbuf mail = STRBUF_INIT;
+ struct ident_split ident;
+
+ person = strstr(buf->buf, what);
+ if (!person)
+ goto left_intact;
+
+ person += strlen(what);
+ endp = strchr(person, '\n');
+ if (!endp)
+ goto left_intact;
+
+ len = endp - person;
+
+ if (split_ident_line(&ident, person, len))
+ goto left_intact;
+
+ strbuf_add(&name, ident.name_begin, ident.name_end - ident.name_begin);
+ strbuf_add(&mail, ident.mail_begin, ident.mail_end - ident.mail_begin);
+
+ if (map_user(mailmap, &mail, &name)) {
+ strbuf_addf(&name, " <%s>", mail.buf);
+
+ strbuf_splice(buf, ident.name_begin - buf->buf,
+ ident.mail_end - ident.name_begin + 1,
+ name.buf, name.len);
+
+ strbuf_release(&name);
+ strbuf_release(&mail);
+
+ return 1;
+ }
+
+left_intact:
+ strbuf_release(&name);
+ strbuf_release(&mail);
+
+ return 0;
+}
+
static int commit_match(struct commit *commit, struct rev_info *opt)
{
int retval;
@@ -2237,6 +2283,14 @@ static int commit_match(struct commit *commit, struct rev_info *opt)
if (buf.len)
strbuf_addstr(&buf, commit->buffer);
+ if (opt->mailmap) {
+ if (!buf.len)
+ strbuf_addstr(&buf, commit->buffer);
+
+ commit_rewrite_person(&buf, "\nauthor ", opt->mailmap);
+ commit_rewrite_person(&buf, "\ncommitter ", opt->mailmap);
+ }
+
/* Append "fake" message parts as needed */
if (opt->show_notes) {
if (!buf.len)
diff --git a/t/t4203-mailmap.sh b/t/t4203-mailmap.sh
index db043dc..e16187f 100755
--- a/t/t4203-mailmap.sh
+++ b/t/t4203-mailmap.sh
@@ -248,11 +248,29 @@ Author: Other Author <other@author.xx>
Author: Some Dude <some@dude.xx>
Author: A U Thor <author@example.com>
EOF
+
test_expect_success 'Log output with --use-mailmap' '
git log --use-mailmap | grep Author >actual &&
test_cmp expect actual
'
+cat >expect <<\EOF
+Author: Santa Claus <santa.claus@northpole.xx>
+Author: Santa Claus <santa.claus@northpole.xx>
+EOF
+
+test_expect_success 'Grep author with --use-mailmap' '
+ git log --use-mailmap --author Santa | grep Author >actual &&
+ test_cmp expect actual
+'
+
+>expect
+
+test_expect_success 'Only grep replaced author with --use-mailmap' '
+ git log --use-mailmap --author "<cto@coompany.xx>" >actual &&
+ test_cmp expect actual
+'
+
# git blame
cat >expect <<\EOF
^OBJI (A U Thor DATE 1) one
--
1.7.9.5
^ permalink raw reply related
* [PATCH] Remove Documentation/pt_BR/gittutorial.txt
From: Thomas Ackermann @ 2012-12-27 14:15 UTC (permalink / raw)
To: th.acker, git
This file is rather outdated and IMHO shouldn't be there in the first place.
(If there are translations of the Git documentation they are better be kept
separate from the original documentation.)
Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
---
Documentation/pt_BR/gittutorial.txt | 675 ------------------------------------
1 file changed, 675 deletions(-)
delete mode 100644 Documentation/pt_BR/gittutorial.txt
diff --git a/Documentation/pt_BR/gittutorial.txt b/Documentation/pt_BR/gittutorial.txt
deleted file mode 100644
index beba065..0000000
--- a/Documentation/pt_BR/gittutorial.txt
+++ /dev/null
@@ -1,675 +0,0 @@
-gittutorial(7)
-==============
-
-NOME
-----
-gittutorial - Um tutorial de introdução ao git (para versão 1.5.1 ou mais nova)
-
-SINOPSE
---------
-git *
-
-DESCRIÇÃO
------------
-
-Este tutorial explica como importar um novo projeto para o git,
-adicionar mudanças a ele, e compartilhar mudanças com outros
-desenvolvedores.
-
-Se, ao invés disso, você está interessado primariamente em usar git para
-obter um projeto, por exemplo, para testar a última versão, você pode
-preferir começar com os primeiros dois capítulos de
-link:user-manual.html[O Manual do Usuário Git].
-
-Primeiro, note que você pode obter documentação para um comando como
-`git log --graph` com:
-
-------------------------------------------------
-$ man git-log
-------------------------------------------------
-
-ou:
-
-------------------------------------------------
-$ git help log
-------------------------------------------------
-
-Com a última forma, você pode usar o visualizador de manual de sua
-escolha; veja linkgit:git-help[1] para maior informação.
-
-É uma boa idéia informar ao git seu nome e endereço público de email
-antes de fazer qualquer operação. A maneira mais fácil de fazê-lo é:
-
-------------------------------------------------
-$ git config --global user.name "Seu Nome Vem Aqui"
-$ git config --global user.email voce@seudominio.exemplo.com
-------------------------------------------------
-
-
-Importando um novo projeto
------------------------
-
-Assuma que você tem um tarball project.tar.gz com seu trabalho inicial.
-Você pode colocá-lo sob controle de revisão git da seguinte forma:
-
-------------------------------------------------
-$ tar xzf project.tar.gz
-$ cd project
-$ git init
-------------------------------------------------
-
-Git irá responder
-
-------------------------------------------------
-Initialized empty Git repository in .git/
-------------------------------------------------
-
-Agora que você iniciou seu diretório de trabalho, você deve ter notado que um
-novo diretório foi criado com o nome de ".git".
-
-A seguir, diga ao git para gravar um instantâneo do conteúdo de todos os
-arquivos sob o diretório atual (note o '.'), com 'git-add':
-
-------------------------------------------------
-$ git add .
-------------------------------------------------
-
-Este instantâneo está agora armazenado em uma área temporária que o git
-chama de "index" ou índice. Você pode armazenar permanentemente o
-conteúdo do índice no repositório com 'git-commit':
-
-------------------------------------------------
-$ git commit
-------------------------------------------------
-
-Isto vai te pedir por uma mensagem de commit. Você agora gravou sua
-primeira versão de seu projeto no git.
-
-Fazendo mudanças
---------------
-
-Modifique alguns arquivos, e, então, adicione seu conteúdo atualizado ao
-índice:
-
-------------------------------------------------
-$ git add file1 file2 file3
-------------------------------------------------
-
-Você está agora pronto para fazer o commit. Você pode ver o que está
-para ser gravado usando 'git-diff' com a opção --cached:
-
-------------------------------------------------
-$ git diff --cached
-------------------------------------------------
-
-(Sem --cached, o comando 'git-diff' irá te mostrar quaisquer mudanças
-que você tenha feito mas ainda não adicionou ao índice.) Você também
-pode obter um breve sumário da situação com 'git-status':
-
-------------------------------------------------
-$ git status
-# On branch master
-# Changes to be committed:
-# (use "git reset HEAD <file>..." to unstage)
-#
-# modified: file1
-# modified: file2
-# modified: file3
-#
-------------------------------------------------
-
-Se você precisar fazer qualquer outro ajuste, faça-o agora, e, então,
-adicione qualquer conteúdo modificado ao índice. Finalmente, grave suas
-mudanças com:
-
-------------------------------------------------
-$ git commit
-------------------------------------------------
-
-Ao executar esse comando, ele irá te pedir uma mensagem descrevendo a mudança,
-e, então, irá gravar a nova versão do projeto.
-
-Alternativamente, ao invés de executar 'git-add' antes, você pode usar
-
-------------------------------------------------
-$ git commit -a
-------------------------------------------------
-
-o que irá automaticamente notar quaisquer arquivos modificados (mas não
-novos), adicioná-los ao índices, e gravar, tudo em um único passo.
-
-Uma nota em mensagens de commit: Apesar de não ser exigido, é uma boa
-idéia começar a mensagem com uma simples e curta (menos de 50
-caracteres) linha sumarizando a mudança, seguida de uma linha em branco
-e, então, uma descrição mais detalhada. Ferramentas que transformam
-commits em email, por exemplo, usam a primeira linha no campo de
-cabeçalho "Subject:" e o resto no corpo.
-
-Git rastreia conteúdo, não arquivos
-----------------------------
-
-Muitos sistemas de controle de revisão provêem um comando `add` que diz
-ao sistema para começar a rastrear mudanças em um novo arquivo. O
-comando `add` do git faz algo mais simples e mais poderoso: 'git-add' é
-usado tanto para arquivos novos e arquivos recentemente modificados, e
-em ambos os casos, ele tira o instantâneo dos arquivos dados e armazena
-o conteúdo no índice, pronto para inclusão do próximo commit.
-
-Visualizando a história do projeto
------------------------
-
-Em qualquer ponto você pode visualizar a história das suas mudanças
-usando
-
-------------------------------------------------
-$ git log
-------------------------------------------------
-
-Se você também quiser ver a diferença completa a cada passo, use
-
-------------------------------------------------
-$ git log -p
-------------------------------------------------
-
-Geralmente, uma visão geral da mudança é útil para ter a sensação de
-cada passo
-
-------------------------------------------------
-$ git log --stat --summary
-------------------------------------------------
-
-Gerenciando "branches"/ramos
------------------
-
-Um simples repositório git pode manter múltiplos ramos de
-desenvolvimento. Para criar um novo ramo chamado "experimental", use
-
-------------------------------------------------
-$ git branch experimental
-------------------------------------------------
-
-Se você executar agora
-
-------------------------------------------------
-$ git branch
-------------------------------------------------
-
-você vai obter uma lista de todos os ramos existentes:
-
-------------------------------------------------
- experimental
-* master
-------------------------------------------------
-
-O ramo "experimental" é o que você acaba de criar, e o ramo "master" é o
-ramo padrão que foi criado pra você automaticamente. O asterisco marca
-o ramo em que você está atualmente; digite
-
-------------------------------------------------
-$ git checkout experimental
-------------------------------------------------
-
-para mudar para o ramo experimental. Agora edite um arquivo, grave a
-mudança, e mude de volta para o ramo master:
-
-------------------------------------------------
-(edita arquivo)
-$ git commit -a
-$ git checkout master
-------------------------------------------------
-
-Verifique que a mudança que você fez não está mais visível, já que ela
-foi feita no ramo experimental e você está de volta ao ramo master.
-
-Você pode fazer uma mudança diferente no ramo master:
-
-------------------------------------------------
-(edit file)
-$ git commit -a
-------------------------------------------------
-
-neste ponto, os dois ramos divergiram, com diferentes mudanças feitas em
-cada um. Para unificar as mudanças feitas no experimental para o
-master, execute
-
-------------------------------------------------
-$ git merge experimental
-------------------------------------------------
-
-Se as mudanças não conflitarem, estará pronto. Se existirem conflitos,
-marcadores serão deixados nos arquivos problemáticos exibindo o
-conflito;
-
-------------------------------------------------
-$ git diff
-------------------------------------------------
-
-vai exibir isto. Após você editar os arquivos para resolver os
-conflitos,
-
-------------------------------------------------
-$ git commit -a
-------------------------------------------------
-
-irá gravar o resultado da unificação. Finalmente,
-
-------------------------------------------------
-$ gitk
-------------------------------------------------
-
-vai mostrar uma bela representação gráfica da história resultante.
-
-Neste ponto você pode remover seu ramo experimental com
-
-------------------------------------------------
-$ git branch -d experimental
-------------------------------------------------
-
-Este comando garante que as mudanças no ramo experimental já estão no
-ramo atual.
-
-Se você desenvolve em um ramo ideia-louca, e se arrepende, você pode
-sempre remover o ramo com
-
--------------------------------------
-$ git branch -D ideia-louca
--------------------------------------
-
-Ramos são baratos e fáceis, então isto é uma boa maneira de experimentar
-alguma coisa.
-
-Usando git para colaboração
----------------------------
-
-Suponha que Alice começou um novo projeto com um repositório git em
-/home/alice/project, e que Bob, que tem um diretório home na mesma
-máquina, quer contribuir.
-
-Bob começa com:
-
-------------------------------------------------
-bob$ git clone /home/alice/project myrepo
-------------------------------------------------
-
-Isso cria um novo diretório "myrepo" contendo um clone do repositório de
-Alice. O clone está no mesmo pé que o projeto original, possuindo sua
-própria cópia da história do projeto original.
-
-Bob então faz algumas mudanças e as grava:
-
-------------------------------------------------
-(editar arquivos)
-bob$ git commit -a
-(repetir conforme necessário)
-------------------------------------------------
-
-Quanto está pronto, ele diz a Alice para puxar as mudanças do
-repositório em /home/bob/myrepo. Ela o faz com:
-
-------------------------------------------------
-alice$ cd /home/alice/project
-alice$ git pull /home/bob/myrepo master
-------------------------------------------------
-
-Isto unifica as mudanças do ramo "master" do Bob ao ramo atual de Alice.
-Se Alice fez suas próprias mudanças no intervalo, ela, então, pode
-precisar corrigir manualmente quaisquer conflitos. (Note que o argumento
-"master" no comando acima é, de fato, desnecessário, já que é o padrão.)
-
-O comando "pull" executa, então, duas operações: ele obtém mudanças de
-um ramo remoto, e, então, as unifica no ramo atual.
-
-Note que, em geral, Alice gostaria que suas mudanças locais fossem
-gravadas antes de iniciar este "pull". Se o trabalho de Bob conflita
-com o que Alice fez desde que suas histórias se ramificaram, Alice irá
-usar seu diretório de trabalho e o índice para resolver conflitos, e
-mudanças locais existentes irão interferir com o processo de resolução
-de conflitos (git ainda irá realizar a obtenção mas irá se recusar a
-unificar --- Alice terá que se livrar de suas mudanças locais de alguma
-forma e puxar de novo quando isso acontecer).
-
-Alice pode espiar o que Bob fez sem unificar primeiro, usando o comando
-"fetch"; isto permite Alice inspecionar o que Bob fez, usando um símbolo
-especial "FETCH_HEAD", com o fim de determinar se ele tem alguma coisa
-que vale puxar, assim:
-
-------------------------------------------------
-alice$ git fetch /home/bob/myrepo master
-alice$ git log -p HEAD..FETCH_HEAD
-------------------------------------------------
-
-Esta operação é segura mesmo se Alice tem mudanças locais não gravadas.
-A notação de intervalo "HEAD..FETCH_HEAD" significa mostrar tudo que é
-alcançável de FETCH_HEAD mas exclua tudo o que é alcançável de HEAD.
-Alice já sabe tudo que leva a seu estado atual (HEAD), e revisa o que Bob
-tem em seu estado (FETCH_HEAD) que ela ainda não viu com esse comando.
-
-Se Alice quer visualizar o que Bob fez desde que suas histórias se
-ramificaram, ela pode disparar o seguinte comando:
-
-------------------------------------------------
-$ gitk HEAD..FETCH_HEAD
-------------------------------------------------
-
-Isto usa a mesma notação de intervalo que vimos antes com 'git log'.
-
-Alice pode querer ver o que ambos fizeram desde que ramificaram. Ela
-pode usar a forma com três pontos ao invés da forma com dois pontos:
-
-------------------------------------------------
-$ gitk HEAD...FETCH_HEAD
-------------------------------------------------
-
-Isto significa "mostre tudo que é alcançável de qualquer um deles, mas
-exclua tudo que é alcançável a partir de ambos".
-
-Por favor, note que essas notações de intervalo podem ser usadas tanto
-com gitk quanto com "git log".
-
-Após inspecionar o que Bob fez, se não há nada urgente, Alice pode
-decidir continuar trabalhando sem puxar de Bob. Se a história de Bob
-tem alguma coisa que Alice precisa imediatamente, Alice pode optar por
-separar seu trabalho em progresso primeiro, fazer um "pull", e, então,
-finalmente, retomar seu trabalho em progresso em cima da história
-resultante.
-
-Quando você está trabalhando em um pequeno grupo unido, não é incomum
-interagir com o mesmo repositório várias e várias vezes. Definindo um
-repositório remoto antes de tudo, você pode fazê-lo mais facilmente:
-
-------------------------------------------------
-alice$ git remote add bob /home/bob/myrepo
-------------------------------------------------
-
-Com isso, Alice pode executar a primeira parte da operação "pull" usando
-o comando 'git-fetch' sem unificar suas mudanças com seu próprio ramo,
-usando:
-
--------------------------------------
-alice$ git fetch bob
--------------------------------------
-
-Diferente da forma longa, quando Alice obteve de Bob usando um
-repositório remoto antes definido com 'git-remote', o que foi obtido é
-armazenado em um ramo remoto, neste caso `bob/master`. Então, após isso:
-
--------------------------------------
-alice$ git log -p master..bob/master
--------------------------------------
-
-mostra uma lista de todas as mudanças que Bob fez desde que ramificou do
-ramo master de Alice.
-
-Após examinar essas mudanças, Alice pode unificá-las em seu ramo master:
-
--------------------------------------
-alice$ git merge bob/master
--------------------------------------
-
-Esse `merge` pode também ser feito puxando de seu próprio ramo remoto,
-assim:
-
--------------------------------------
-alice$ git pull . remotes/bob/master
--------------------------------------
-
-Note que 'git pull' sempre unifica ao ramo atual, independente do que
-mais foi passado na linha de comando.
-
-Depois, Bob pode atualizar seu repositório com as últimas mudanças de
-Alice, usando
-
--------------------------------------
-bob$ git pull
--------------------------------------
-
-Note que ele não precisa dar o caminho do repositório de Alice; quando
-Bob clonou seu repositório, o git armazenou a localização de seu
-repositório na configuração do mesmo, e essa localização é usada
-para puxar:
-
--------------------------------------
-bob$ git config --get remote.origin.url
-/home/alice/project
--------------------------------------
-
-(A configuração completa criada por 'git-clone' é visível usando `git
-config -l`, e a página de manual linkgit:git-config[1] explica o
-significado de cada opção.)
-
-Git também mantém uma cópia limpa do ramo master de Alice sob o nome
-"origin/master":
-
--------------------------------------
-bob$ git branch -r
- origin/master
--------------------------------------
-
-Se Bob decidir depois em trabalhar em um host diferente, ele ainda pode
-executar clones e puxar usando o protocolo ssh:
-
--------------------------------------
-bob$ git clone alice.org:/home/alice/project myrepo
--------------------------------------
-
-Alternativamente, o git tem um protocolo nativo, ou pode usar rsync ou
-http; veja linkgit:git-pull[1] para detalhes.
-
-Git pode também ser usado em um modo parecido com CVS, com um
-repositório central para o qual vários usuários empurram modificações;
-veja linkgit:git-push[1] e linkgit:gitcvs-migration[7].
-
-Explorando história
------------------
-
-A história no git é representada como uma série de commits
-interrelacionados. Nós já vimos que o comando 'git-log' pode listar
-esses commits. Note que a primeira linha de cada entrada no log também
-dá o nome para o commit:
-
--------------------------------------
-$ git log
-commit c82a22c39cbc32576f64f5c6b3f24b99ea8149c7
-Author: Junio C Hamano <junkio@cox.net>
-Date: Tue May 16 17:18:22 2006 -0700
-
- merge-base: Clarify the comments on post processing.
--------------------------------------
-
-Nós podemos dar este nome ao 'git-show' para ver os detalhes sobre este
-commit.
-
--------------------------------------
-$ git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7
--------------------------------------
-
-Mas há outras formas de se referir aos commits. Você pode usar qualquer
-parte inicial do nome que seja longo o bastante para identificar
-unicamente o commit:
-
--------------------------------------
-$ git show c82a22c39c # os primeiros caracteres do nome são o bastante
- # usualmente
-$ git show HEAD # a ponta do ramo atual
-$ git show experimental # a ponta do ramo "experimental"
--------------------------------------
-
-Todo commit normalmente tem um commit "pai" que aponta para o estado
-anterior do projeto:
-
--------------------------------------
-$ git show HEAD^ # para ver o pai de HEAD
-$ git show HEAD^^ # para ver o avô de HEAD
-$ git show HEAD~4 # para ver o trisavô de HEAD
--------------------------------------
-
-Note que commits de unificação podem ter mais de um pai:
-
--------------------------------------
-$ git show HEAD^1 # mostra o primeiro pai de HEAD (o mesmo que HEAD^)
-$ git show HEAD^2 # mostra o segundo pai de HEAD
--------------------------------------
-
-Você também pode dar aos commits nomes à sua escolha; após executar
-
--------------------------------------
-$ git tag v2.5 1b2e1d63ff
--------------------------------------
-
-você pode se referir a 1b2e1d63ff pelo nome "v2.5". Se você pretende
-compartilhar esse nome com outras pessoas (por exemplo, para identificar
-uma versão de lançamento), você deveria criar um objeto "tag", e talvez
-assiná-lo; veja linkgit:git-tag[1] para detalhes.
-
-Qualquer comando git que precise conhecer um commit pode receber
-quaisquer desses nomes. Por exemplo:
-
--------------------------------------
-$ git diff v2.5 HEAD # compara o HEAD atual com v2.5
-$ git branch stable v2.5 # inicia um novo ramo chamado "stable" baseado
- # em v2.5
-$ git reset --hard HEAD^ # reseta seu ramo atual e seu diretório de
- # trabalho a seu estado em HEAD^
--------------------------------------
-
-Seja cuidadoso com o último comando: além de perder quaisquer mudanças
-em seu diretório de trabalho, ele também remove todos os commits
-posteriores desse ramo. Se esse ramo é o único ramo contendo esses
-commits, eles serão perdidos. Também, não use 'git-reset' num ramo
-publicamente visível de onde outros desenvolvedores puxam, já que vai
-forçar unificações desnecessárias para que outros desenvolvedores limpem
-a história. Se você precisa desfazer mudanças que você empurrou, use
-'git-revert' no lugar.
-
-O comando 'git-grep' pode buscar strings em qualquer versão de seu
-projeto, então
-
--------------------------------------
-$ git grep "hello" v2.5
--------------------------------------
-
-procura por todas as ocorrências de "hello" em v2.5.
-
-Se você deixar de fora o nome do commit, 'git-grep' irá procurar
-quaisquer dos arquivos que ele gerencia no diretório corrente. Então
-
--------------------------------------
-$ git grep "hello"
--------------------------------------
-
-é uma forma rápida de buscar somente os arquivos que são rastreados pelo
-git.
-
-Muitos comandos git também recebem um conjunto de commits, o que pode
-ser especificado de várias formas. Aqui estão alguns exemplos com 'git-log':
-
--------------------------------------
-$ git log v2.5..v2.6 # commits entre v2.5 e v2.6
-$ git log v2.5.. # commits desde v2.5
-$ git log --since="2 weeks ago" # commits das últimas 2 semanas
-$ git log v2.5.. Makefile # commits desde v2.5 que modificam
- # Makefile
--------------------------------------
-
-Você também pode dar ao 'git-log' um "intervalo" de commits onde o
-primeiro não é necessariamente um ancestral do segundo; por exemplo, se
-as pontas dos ramos "stable" e "master" divergiram de um commit
-comum algum tempo atrás, então
-
--------------------------------------
-$ git log stable..master
--------------------------------------
-
-irá listar os commits feitos no ramo "master" mas não no ramo
-"stable", enquanto
-
--------------------------------------
-$ git log master..stable
--------------------------------------
-
-irá listar a lista de commits feitos no ramo "stable" mas não no ramo
-"master".
-
-O comando 'git-log' tem uma fraqueza: ele precisa mostrar os commits em
-uma lista. Quando a história tem linhas de desenvolvimento que
-divergiram e então foram unificadas novamente, a ordem em que 'git-log'
-apresenta essas mudanças é irrelevante.
-
-A maioria dos projetos com múltiplos contribuidores (como o kernel
-Linux, ou o próprio git) tem unificações frequentes, e 'gitk' faz um
-trabalho melhor de visualizar sua história. Por exemplo,
-
--------------------------------------
-$ gitk --since="2 weeks ago" drivers/
--------------------------------------
-
-permite a você navegar em quaisquer commits desde as últimas duas semanas
-de commits que modificaram arquivos sob o diretório "drivers". (Nota:
-você pode ajustar as fontes do gitk segurando a tecla control enquanto
-pressiona "-" ou "+".)
-
-Finalmente, a maioria dos comandos que recebem nomes de arquivo permitirão
-também, opcionalmente, preceder qualquer nome de arquivo por um
-commit, para especificar uma versão particular do arquivo:
-
--------------------------------------
-$ git diff v2.5:Makefile HEAD:Makefile.in
--------------------------------------
-
-Você pode usar 'git-show' para ver tal arquivo:
-
--------------------------------------
-$ git show v2.5:Makefile
--------------------------------------
-
-Próximos passos
-----------
-
-Este tutorial deve ser o bastante para operar controle de revisão
-distribuído básico para seus projetos. No entanto, para entender
-plenamente a profundidade e o poder do git você precisa entender duas
-idéias simples nas quais ele se baseia:
-
- * A base de objetos é um sistema bem elegante usado para armazenar a
- história de seu projeto--arquivos, diretórios, e commits.
-
- * O arquivo de índice é um cache do estado de uma árvore de diretório,
- usado para criar commits, restaurar diretórios de trabalho, e
- armazenar as várias árvores envolvidas em uma unificação.
-
-A parte dois deste tutorial explica a base de objetos, o arquivo de
-índice, e algumas outras coisinhas que você vai precisar pra usar o
-máximo do git. Você pode encontrá-la em linkgit:gittutorial-2[7].
-
-Se você não quiser continuar com o tutorial agora nesse momento, algumas
-outras digressões que podem ser interessantes neste ponto são:
-
- * linkgit:git-format-patch[1], linkgit:git-am[1]: Estes convertem
- séries de commits em patches para email, e vice-versa, úteis para
- projetos como o kernel Linux que dependem fortemente de patches
- enviados por email.
-
- * linkgit:git-bisect[1]: Quando há uma regressão em seu projeto, uma
- forma de rastrear um bug é procurando pela história para encontrar o
- commit culpado. Git bisect pode ajudar a executar uma busca binária
- por esse commit. Ele é inteligente o bastante para executar uma
- busca próxima da ótima mesmo no caso de uma história complexa
- não-linear com muitos ramos unificados.
-
- * link:everyday.html[GIT diariamente com 20 e tantos comandos]
-
- * linkgit:gitcvs-migration[7]: Git para usuários de CVS.
-
-VEJA TAMBÉM
---------
-linkgit:gittutorial-2[7],
-linkgit:gitcvs-migration[7],
-linkgit:gitcore-tutorial[7],
-linkgit:gitglossary[7],
-linkgit:git-help[1],
-link:everyday.html[git diariamente],
-link:user-manual.html[O Manual do Usuário git]
-
-GIT
----
-Parte da suite linkgit:git[1].
--
1.8.0.msysgit.0
---
Thomas
^ permalink raw reply related
* [PATCH] gitk: Replaced "green" with "#00FF00".
From: Peter Hofmann @ 2012-12-27 12:59 UTC (permalink / raw)
To: git; +Cc: gitster
The definition of "green" has changed in Tk 8.6:
- http://wiki.tcl.tk/21276
- http://www.tcl.tk/cgi-bin/tct/tip/403
gitk looks pretty awkward with Tk 8.6. "green" is simply too dark now
because it has changed from "#00FF00" to "#008000".
One could also use "lime" instead of "#00FF00" but that would break
compatibility with older versions of Tk.
Signed-off-by: Peter Hofmann <git-dev@uninformativ.de>
---
gitk-git/gitk | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index d93bd99..d7e922b 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -2209,7 +2209,7 @@ proc makewindow {} {
set h [expr {[font metrics uifont -linespace] + 2}]
set progresscanv .tf.bar.progress
canvas $progresscanv -relief sunken -height $h -borderwidth 2
- set progressitem [$progresscanv create rect -1 0 0 $h -fill green]
+ set progressitem [$progresscanv create rect -1 0 0 $h -fill "#00FF00"]
set fprogitem [$progresscanv create rect -1 0 0 $h -fill yellow]
set rprogitem [$progresscanv create rect -1 0 0 $h -fill red]
}
@@ -2342,7 +2342,7 @@ proc makewindow {} {
$ctext tag conf dresult -fore [lindex $diffcolors 1]
$ctext tag conf m0 -fore red
$ctext tag conf m1 -fore blue
- $ctext tag conf m2 -fore green
+ $ctext tag conf m2 -fore "#00FF00"
$ctext tag conf m3 -fore purple
$ctext tag conf m4 -fore brown
$ctext tag conf m5 -fore "#009090"
@@ -3226,7 +3226,7 @@ set rectmask {
0x00, 0x00, 0xfc, 0x0f, 0xfc, 0x0f, 0xfc, 0x0f,
0xfc, 0x0f, 0xfc, 0x0f, 0xfc, 0x0f, 0xfc, 0x0f, 0x00, 0x00};
}
-image create bitmap reficon-H -background black -foreground green \
+image create bitmap reficon-H -background black -foreground "#00FF00" \
-data $rectdata -maskdata $rectmask
image create bitmap reficon-o -background black -foreground "#ddddff" \
-data $rectdata -maskdata $rectmask
@@ -5909,7 +5909,7 @@ proc drawcmittext {id row col} {
if {$id eq $nullid} {
set ofill red
} elseif {$id eq $nullid2} {
- set ofill green
+ set ofill "#00FF00"
} elseif {$id eq $mainheadid} {
set ofill yellow
} else {
@@ -6377,7 +6377,7 @@ proc drawtags {id x xt y1} {
} else {
# draw a head or other ref
if {[incr nheads -1] >= 0} {
- set col green
+ set col "#00FF00"
if {$tag eq $mainhead} {
set font mainfontbold
}
@@ -11617,7 +11617,7 @@ if {[tk windowingsystem] eq "aqua"} {
set extdifftool "meld"
}
-set colors {green red blue magenta darkgrey brown orange}
+set colors {"#00FF00" red blue magenta darkgrey brown orange}
if {[tk windowingsystem] eq "win32"} {
set uicolor SystemButtonFace
set bgcolor SystemWindow
--
1.8.0.2
^ permalink raw reply related
* Re: Push Windows to Linux Repository Problem
From: Robin Rosenberg @ 2012-12-27 12:18 UTC (permalink / raw)
To: Dennis Putnam; +Cc: git
In-Reply-To: <50D7230F.80204@bellsouth.net>
----- Ursprungligt meddelande -----
> Hi Andreas,
>
> Thanks for the reply and no, I could not. However, you put me on the
> right track. Since I was only pushing/pulling from Windows to/from my
> Linux repository, I did not realize that an SSH session from the
> Linux
> back to Windows would ever be necessary. I don't really understand
> why
> but apparently it is.
No. Git itself does not require a reverse connection of any kind. Maybe the Linux
box checks that reverse lookup is set up for the client and refuses connection
if reverse lookup of the connecting client's ip does not resolve to a hostname that
in turn resolves back to the client's ip. If that is the case the server does not
actually try to connect to the client with SSH or otherwise.
-- robin
^ permalink raw reply
* Re: [PATCH v3 00/19] new git check-ignore sub-command
From: Michael Leal @ 2012-12-27 5:15 UTC (permalink / raw)
To: git
In-Reply-To: <1356575558-2674-1-git-send-email-git@adamspiers.org>
Adam Spiers <git <at>
adamspiers.org> writes:
>
> This v3 re-roll of my check-
ignore series is a reasonably
substantial
> revamp over v2, and applies on
top of Junio's current
> nd/attr-match-optim-more
branch (82dce998c202).
>
> All feedback and patches from
the v2 series has been
incorporated, and
> several other improvements
too, including:
>
> - composite exclude_lists
have been split up into
> exclude_list_groups each
containing one exclude_list per
source
>
> - smaller commits for easier
review
>
> - minor memory leaks have
been fixed and verified via
valgrind
>
> - t0007-ignores.sh has been
renumbered to t0008-ignores.sh
to avoid
> a conflict with t0007-git-
var.sh
>
> - improvements to
documentation and comments
>
> For reference, the v2 series
was announced here:
>
> http://thread.gmane.org/
gmane.comp.version-
control.git/204661/
focus=206074
>
> All tests pass except for t91*,
since there seems to be some
> pre-existing breakage in
82dce998c202 relating to git-
svn.
>
> Adam Spiers (19):
> api-directory-listing.txt:
update to match code
> Improve documentation and
comments regarding directory
traversal API
> dir.c: rename cryptic 'which'
variable to more consistent
name
> dir.c: rename path_excluded()
to is_path_excluded()
> dir.c: rename
excluded_from_list() to
is_excluded_from_list()
> dir.c: rename excluded() to
is_excluded()
> dir.c: refactor
is_excluded_from_list()
> dir.c: refactor is_excluded()
> dir.c: refactor
is_path_excluded()
> dir.c: rename free_excludes()
to clear_exclude_list()
> dir.c: use a single struct
exclude_list per source of
excludes
> dir.c: keep track of where
patterns came from
> dir.c: provide clear_directory()
for reclaiming dir_struct memory
> add.c: refactor treat_gitlinks()
> add.c: remove unused
argument from
validate_pathspec()
> pathspec.c: move reusable
code from builtin/add.c
> pathspec.c: extract new
validate_path() for reuse
> setup.c: document
get_pathspec()
> Add git-check-ignore sub-
command
>
> .gitignore
| 1 +
> Documentation/git-check-
ignore.txt | 89 ++++
> Documentation/gitignore.txt
| 6 +-
> Documentation/technical/api-
directory-listing.txt | 35 +-
> Makefile
| 3 +
> attr.c |
2 +-
> builtin.h
| 1 +
> builtin/add.c
| 84 +--
> builtin/check-ignore.c
| 170 +++++++
> builtin/clean.c
| 3 +-
> builtin/ls-files.c
| 11 +-
> command-list.txt
| 1 +
> contrib/completion/git-
completion.bash | 1 +
> dir.c |
243 +++++++--
> dir.h |
87 +++-
> git.c |
1 +
> pathspec.c
| 107 ++++
> pathspec.h
| 6 +
> setup.c
| 15 +
> t/t0008-ignores.sh
| 595
++++++++++++++++++++++
> unpack-trees.c
| 14 +-
> 21 files changed, 1305
insertions(+), 170 deletions(-)
> create mode 100644
Documentation/git-check-
ignore.txt
> create mode 100644 builtin/
check-ignore.c
> create mode 100644
pathspec.c
> create mode 100644
pathspec.h
> create mode 100755 t/t0008-
ignores.sh
>
^ permalink raw reply
* Re: [PATCH v2] wt-status: Show ignored files in untracked dirs
From: Junio C Hamano @ 2012-12-27 5:08 UTC (permalink / raw)
To: Jeff King; +Cc: Antoine Pelisse, git
In-Reply-To: <20121227034859.GA20817@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> IOW, given:
>
> git init
> mkdir untracked ignored
> >untracked/file
> >ignored/file
> echo ignored >.git/info/exclude
>
> I would expect:
>
> $ git status --short --ignored --untracked=normal
> ?? untracked/
> !! ignored/
Sensible.
> $ git status --short --ignored --untracked=all
> ?? untracked/file
> !! ignored/file
Again sensible; OK, --untracked=all is what I was missing.
> I do not know if anybody cares about the distinction, but optionally we
> could give --ignored its own selector, like:
>
> $ git status --short --ignored=all --untracked=normal
> ?? untracked/
> !! ignored/file
>
> where obviously it would default to "none" (whereas untracked defaults
> to "normal").
We could just say the selector for the ignored implicitly follows
what is given for --untracked, if we don't care.
> But the behavior with Antoine's patch is:
>
> $ git status --short --ignored --untracked=normal
> ?? untracked/
> !! ignored
>
> $ git status --short --ignored --untracked=all
> ?? untracked/file
> !! ignored
>
> which seems wrong to me for two reasons:
>
> 1. It does not recurse for ignored but untracked entries. Neither does
> the current code, but I think it should.
>
> 2. It loses the trailing slash from the ignored directory in both
> cases (which is printed by the current code).
Nicely analysed. Perhaps we would want new test pieces to define
the behaviour we want to see first?
^ permalink raw reply
* Re: [PATCH v2] wt-status: Show ignored files in untracked dirs
From: Jeff King @ 2012-12-27 3:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Antoine Pelisse, git
In-Reply-To: <7vip7omd8c.fsf@alter.siamese.dyndns.org>
On Wed, Dec 26, 2012 at 06:37:55PM -0800, Junio C Hamano wrote:
> Antoine Pelisse <apelisse@gmail.com> writes:
>
> > When looking for ignored files, we do not recurse into untracked
> > directory, and simply consider the directory ignored status.
>
> When asked to show ignored ones, instead of listing all ignored
> files in such a directory, we just say "everything in this directory
> is ignored"?
>
> That sounds like a more desirable behaviour, than listing everything
> there, at least to me, but perhaps I am missing something.
I do not use this feature myself, but I would think that it should
respect the same DIR_SHOW_OTHER_DIRECTORIES flag (or a parallel flag)
that we already hook into "--untracked={all,normal}".
IOW, given:
git init
mkdir untracked ignored
>untracked/file
>ignored/file
echo ignored >.git/info/exclude
I would expect:
$ git status --short --ignored --untracked=normal
?? untracked/
!! ignored/
$ git status --short --ignored --untracked=all
?? untracked/file
!! ignored/file
I do not know if anybody cares about the distinction, but optionally we
could give --ignored its own selector, like:
$ git status --short --ignored=all --untracked=normal
?? untracked/
!! ignored/file
where obviously it would default to "none" (whereas untracked defaults
to "normal"). But the behavior with Antoine's patch is:
$ git status --short --ignored --untracked=normal
?? untracked/
!! ignored
$ git status --short --ignored --untracked=all
?? untracked/file
!! ignored
which seems wrong to me for two reasons:
1. It does not recurse for ignored but untracked entries. Neither does
the current code, but I think it should.
2. It loses the trailing slash from the ignored directory in both
cases (which is printed by the current code).
-Peff
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox