Use of uninitialized value in substitution iterator at gitweb.cgi line 1560
Signed-off-by: Orgad Shaneh org...@gmail.com
---
gitweb/gitweb.perl |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 0f207f2..862b9cd 100755
---
On 12/21/2012 09:04 AM, Jeff King wrote:
When we delete a ref that is packed, we rewrite the whole
packed-refs file and simply omit the ref that no longer
exists. However, we base the rewrite on whatever happens to
be in our refs cache, not what is necessarily on disk. That
opens us up to a
Orgad Shaneh org...@gmail.com writes:
Use of uninitialized value in substitution iterator at gitweb.cgi line 1560
This is not just about squelching an error message, but more
importantly, attempting to fix an information lossage, no?
The statement captures each control character in the string
When looking for ignored files, we do not recurse into untracked
directory, and simply consider the directory ignored status.
As a consequence, we don't see ignored files in those directories.
Change that behavior by recursing into untracked directories searching
for ignored files.
* Junio C Hamano gits...@pobox.com [2012-12-25 23:47:53 -0800]:
Can we make it take an optional third parameter so that we could say
PROMPT_COMMAND='__git_ps1 : \h \W ; /%s'
to do the same as what the command substitution mode would have
given for
PS1=': \h \W$(__git_ps1
When looking for ignored files, we do not recurse into untracked
directory, and simply consider the directory ignored status.
As a consequence, we don't see ignored files in those directories.
Change that behavior by recursing into untracked directories, if not
ignored themselves, searching for
On Thu, Sep 20, 2012 at 02:31:57PM -0700, Junio C Hamano wrote:
Adam Spiers g...@adamspiers.org writes:
void add_exclude(const char *string, const char *base,
-int baselen, struct exclude_list *el)
+int baselen, struct exclude_list *el, const char *src, int
Junio C Hamano gits...@pobox.com writes:
Antoine Pelisse apeli...@gmail.com writes:
I'm wondering if it would be needed to add a no-use-mailmap option to
log command so that it can cancel this configuration option.
The usual way for adding a new feature is to add a --enable-feature
I was planning to send you a fix pretty close to that,
Thanks a lot Junio!
On Wed, Dec 26, 2012 at 5:14 PM, Junio C Hamano gits...@pobox.com wrote:
Junio C Hamano gits...@pobox.com writes:
Antoine Pelisse apeli...@gmail.com writes:
I'm wondering if it would be needed to add a no-use-mailmap
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
@@ -134,101 +131,102 @@ static int dowild(const uchar *p, const uchar *text,
int force_lower_case)
p_ch = NEGATE_CLASS;
#endif
/* Assign literal TRUE/FALSE because of matched
comparison.
The optional third parameter when __git_ps1 is used in
PROMPT_COMMAND mode as format string for printf to further
customize the way the git status string is embedded in the
user's PS1 prompt.
Signed-off-by: Simon Oosthoek s.oosth...@xs4all.nl
---
contrib/completion/git-prompt.sh | 32
Antoine Pelisse apeli...@gmail.com writes:
Currently mailmap can be used to display log authors and committers
but there no way to use mailmap to find commits with mapped values.
This commit allows those commands to work:
git log --use-mailmap --author mapped_name_or_email
git log
Simon Oosthoek s.oosth...@xs4all.nl writes:
The optional third parameter when __git_ps1 is used in
PROMPT_COMMAND mode as format string for printf to further
customize the way the git status string is embedded in the
user's PS1 prompt.
Signed-off-by: Simon Oosthoek s.oosth...@xs4all.nl
---
Hi all
I've been very frustrated by the process to setup a commandline for git
format-patch, to include everyone in the cc list and reply to the right
message-id.
In my frustration I created a perl script to generate the options from a saved
e-mail, I realise that it may be non-general and
* Junio C Hamano gits...@pobox.com [2012-12-26 11:45:48 -0800]:
Simon Oosthoek s.oosth...@xs4all.nl writes:
The optional third parameter when __git_ps1 is used in
PROMPT_COMMAND mode as format string for printf to further
customize the way the git status string is embedded in the
Hi all
I've been very frustrated by the process to setup a commandline for git
format-patch, to include everyone in the cc list and reply to the right
message-id.
In my frustration I created a perl script to generate the options from a saved
e-mail, I realise that it may be non-general and
Simon Oosthoek s.oosth...@xs4all.nl writes:
The problem with doing it in pre-post is when inside non-git
directories. You want to avoid any gitstring output, including the
brackets, when not inside a repository.
Ah, Ok, that is probably what I missed.
Or we could go the other way and drop
Simon Oosthoek s.oosth...@xs4all.nl writes:
Hi all
I've been very frustrated by the process to setup a commandline for git
format-patch, to include everyone in the cc list and reply to the right
message-id.
In my frustration I created a perl script to generate the options from a
saved
Simon Oosthoek s.oosth...@xs4all.nl writes:
Every time I looked at this line, I wondered why '*' state is
bad. Does a user go into any bad state by having a dirty
working tree? Same for untracked ($u) and detached. These are all
perfectly normal part of a workflow, so while choice of red
Junio C Hamano gits...@pobox.com writes:
But as I said, there probably is a reason why that approach does not
work, that is why I said...
I have a feeling that I am missing something major, though...
In any case, this was more like if we were doing this from scratch
conversation.
I think
* Junio C Hamano gits...@pobox.com [2012-12-26 12:32:20 -0800]:
The point of the above two was that __git_ps1 does not have to set
PS1 as long as the insn says user to use PROMPT_COMMAND that sets
PS1 himself, exactly as illustrated above. In other words, replace
the last PS1=... in the
* Junio C Hamano gits...@pobox.com [2012-12-26 12:35:28 -0800]:
Anyway, I could imagine this as optional flag of git format-patch, so you
could say:
$ git format-patch -s --in-reply-to-email mboxfile a7fe7de8
But I'll save that as an exercise for the reader (or the future)
I think
+static int commit_rewrite_authors(struct strbuf *buf, const char *what,
struct string_list *mailmap)
+{
+ char *author, *endp;
+ size_t len;
+ struct strbuf name = STRBUF_INIT;
+ struct strbuf mail = STRBUF_INIT;
+ struct ident_split ident;
+
+ author =
-Original Message-
From: Simon Oosthoek
Sent: Wednesday, December 26, 2012 4:08 PM
* Junio C Hamano gits...@pobox.com [2012-12-26 12:35:28 -0800]:
Anyway, I could imagine this as optional flag of git format-patch,
so you could say:
$ git format-patch -s --in-reply-to-email
Antoine Pelisse apeli...@gmail.com writes:
+static int commit_rewrite_authors(struct strbuf *buf, const char *what,
struct string_list *mailmap)
+{
+ char *author, *endp;
+ size_t len;
+ struct strbuf name = STRBUF_INIT;
+ struct strbuf mail = STRBUF_INIT;
+ struct
On Wed, Dec 26, 2012 at 09:31:46PM +, Pyeron, Jason J CTR (US) wrote:
That would work for the message-ID, but not for the various To: and Cc:
addresses.
The hacky script that I sent afterwards produces a string with the
Nit, it does not make use of the reply-to header if present.
On Mon, Dec 24, 2012 at 09:08:46AM -0500, Eric Chamberland wrote:
Doing a git clone always work fine, but when we git pull or git
gc or git fsck, often (1/5) the local repository get corrupted.
for example, I got this error two days ago while doing git gc:
error: index file
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The final release for this cycle will happen sometime next week,
hopefully.
You can find the changes described here in the integration
This is a small preparatory step to build a new merge strategy based
on the disused merge-tree proof-of-concept code. It starts with a
small set of code clean-up patches and ends with two bugfixes, at
least for now.
Junio C Hamano (5):
Which merge_file() function do you mean?
merge-tree:
There are two different static functions and one global function,
all of them called merge_file(), with different signatures and
purposes. Rename them all to reduce confusion in git grep output:
* Rename the static one in merge-index to merge_one_path(const char
*path) as that function is
Drop the unused field from the structure.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/merge-tree.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/builtin/merge-tree.c b/builtin/merge-tree.c
index ebd0d25..b61d811 100644
--- a/builtin/merge-tree.c
+++
This option is always set; simplify.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/merge-tree.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/builtin/merge-tree.c b/builtin/merge-tree.c
index b61d811..95de162 100644
--- a/builtin/merge-tree.c
+++ b/builtin/merge-tree.c
@@
Rename the branch1 parameter given to resolve() to ours, to
clarify what is going on. Also, annotate the unresolved_directory()
function with some comments to show what decisions are made in each
step, and highlight two bugs that need to be fixed.
Add two tests to t4300 to illustrate these bugs.
The previous commit documented two known breakages revolving around
a case where one side flips a tree into a blob (or vice versa),
where the original code simply gets confused and feeds a mixture of
trees and blobs into either the recursive merge-tree (and recursing
into the blob will fail) or
Use $TMPDIR when creating the /dev/null placeholder for p4merge.
This prevents users from finding a seemingly random untracked file
in their worktree.
This is different than what mergetool does with $LOCAL and
$REMOTE because those files exist to aid users when resolving
merges. p4merge's
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:
-
7c4c97c0ac turned the flags in struct dir_struct into a single bitfield
variable, but forgot to update this document.
Signed-off-by: Adam Spiers g...@adamspiers.org
---
For some reason this patch was dropped from the v2 series when it was
applied to the 'pu' branch.
From the perspective of a newcomer to the codebase, the directory
traversal API has a few potentially confusing properties. These
comments clarify a few key aspects and will hopefully make it easier
to understand for other newcomers in the future.
Signed-off-by: Adam Spiers g...@adamspiers.org
Continue adopting clearer names for exclude functions. This 'is_*'
naming pattern for functions returning booleans was discussed here:
http://thread.gmane.org/gmane.comp.version-control.git/204661/focus=204924
Also adjust their callers as necessary.
Signed-off-by: Adam Spiers
The excluded function uses a new helper function called
last_exclude_matching_from_list() to perform the inner loop over all of
the exclude patterns. The helper just tells us whether the path is
included, excluded, or undecided.
However, it may be useful to know _which_ pattern was triggered.
Continue adopting clearer names for exclude functions. This is_*
naming pattern for functions returning booleans was discussed here:
http://thread.gmane.org/gmane.comp.version-control.git/204661/focus=204924
Signed-off-by: Adam Spiers g...@adamspiers.org
---
attr.c | 2 +-
dir.c | 10
In a similar way to the previous commit, this extracts a new helper
function last_exclude_matching() which returns the last exclude_list
element which matched, or NULL if no match was found. is_excluded()
becomes a wrapper around this, and just returns 0 or 1 depending on
whether any matching
It is clearer to use a 'clear_' prefix for functions which empty
and deallocate the contents of a data structure without freeing
the structure itself, and a 'free_' prefix for functions which
also free the structure itself.
http://article.gmane.org/gmane.comp.version-control.git/206128
For exclude patterns read in from files, the filename is stored in the
exclude list, and the originating line number is stored in the
individual exclude (counting starting at 1).
For exclude patterns provided on the command line, a string describing
the source of the patterns is stored in the
Previously each exclude_list could potentially contain patterns
from multiple sources. For example dir-exclude_list[EXC_FILE]
would typically contain patterns from .git/info/exclude and
core.excludesfile, and dir-exclude_list[EXC_DIRS] could contain
patterns from multiple per-directory .gitignore
By the end of a directory traversal, a dir_struct instance will
typically contains pointers to various data structures on the heap.
clear_directory() provides a convenient way to reclaim that memory.
Signed-off-by: Adam Spiers g...@adamspiers.org
---
This will be reused by a new git check-ignore command.
Signed-off-by: Adam Spiers g...@adamspiers.org
---
pathspec.c | 20 ++--
pathspec.h | 1 +
2 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/pathspec.c b/pathspec.c
index 8aea0d2..6724121 100644
---
This works in a similar manner to git-check-attr.
Thanks to Jeff King and Junio C Hamano for the idea:
http://thread.gmane.org/gmane.comp.version-control.git/108671/focus=108815
Signed-off-by: Adam Spiers g...@adamspiers.org
---
Since v2, the missing documentation has been fixed, and the
Since we have just created a new pathspec-handling library, now is a
good time to add some comments explaining get_pathspec().
Signed-off-by: Adam Spiers g...@adamspiers.org
---
setup.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/setup.c b/setup.c
index 7663a4c..03d6d5c
Extract the following functions from builtin/add.c to pathspec.c, in
preparation for reuse by a new git check-ignore command:
- fill_pathspec_matches()
- find_used_pathspec()
- treat_gitlink()
- treat_gitlinks()
- validate_pathspec()
The functions being extracted are not changed in any
The 'argc' argument passed to validate_pathspec() was never used.
Signed-off-by: Adam Spiers g...@adamspiers.org
---
builtin/add.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin/add.c b/builtin/add.c
index 856d232..1ba2a86 100644
--- a/builtin/add.c
+++
Extract the body of the for loop in treat_gitlinks() into a separate
treat_gitlink() function so that it can be reused elsewhere. This
paves the way for a new check-ignore sub-command.
Signed-off-by: Adam Spiers g...@adamspiers.org
---
builtin/add.c | 50
In a similar way to the previous commit, this extracts a new helper
function last_exclude_matching_path() which return the last
exclude_list element which matched, or NULL if no match was found.
is_path_excluded() becomes a wrapper around this, and just returns 0
or 1 depending on whether any
'el' is only *slightly* less cryptic, but is already used as the
variable name for a struct exclude_list pointer in numerous other
places, so this reduces the number of cryptic variable names in use by
one :-)
Signed-off-by: Adam Spiers g...@adamspiers.org
---
dir.c | 10 +-
dir.h | 4
Start adopting clearer names for exclude functions. This 'is_*'
naming pattern for functions returning booleans was agreed here:
http://thread.gmane.org/gmane.comp.version-control.git/204661/focus=204924
Signed-off-by: Adam Spiers g...@adamspiers.org
---
builtin/add.c | 2 +-
Antoine Pelisse apeli...@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
On Wed, Dec 26, 2012 at 06:37:55PM -0800, Junio C Hamano wrote:
Antoine Pelisse apeli...@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
Jeff King p...@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
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,
Thomas sabo are characterized by a few colossal as the choice Thomas Sabo
Gold. From the variety of a number of precious metal necklaces, diamond
earrings including a bracelet-type gold charm available for sale. strong
thomas sabo uk http://www.thomassabobraceletsshop.co.uk/ /strong is
really a
strong pandora charms http://www.pandoracanadacharm.org/ /strong are
generally mostly of the makes to make available a new discounted in decided
on expensive jewelry. Look for an online site that will gives you the most
up-to-date savings proposed by Pandora. This specific allows you to obtain
Pandora Bracelets is everything regarding taking into account which will
1982, nevertheless it is that arrival in pandora uk on 1999 which will
without doubt started ones own magnificence. That splendid expensive jewelry
in Pandora is termed soon enough as soon as that Historic Lie in Zeus, just
62 matches
Mail list logo
