On Sat, Jun 1, 2013 at 11:26 PM, Ramkumar Ramachandra
wrote:
> Sitaram Chamarty wrote:
>> I think I'd have to be playing with *several* branches simultaneously
>> before I got to the point of forgetting the branch name!
>
> Yeah, I work on lots of small unrelated things: the patch-series I
> send
Currently, the completion for 'git format-patch' uses
__git_complete_revlist. Although this is technically correct, and you
can
$ git format-patch master contrib
where master is a ref and contrib is a pathspec, just like in 'git log',
the usage is unidiomatic and undocumented. 'git format-pat
Add support for completing 'git blame'. List only the common short
options.
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-completion.bash | 11 +++
1 file changed, 11 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion
Currently, the 'git ls-tree', 'git archive', and 'git show' completions
use __git_complete_file (aliased to __git_complete_revlist_file).
In the case of 'git ls-tree' and 'git archive', they necessarily require
a tree-ish argument (and optionally a pathspec filter, or "file
argument"):
$ git ls
Add support for completing 'git rev-parse'. List only the options that
are likely to be used on the command-line, as opposed to scripts.
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-completion.bash | 11 +++
1 file changed, 11 insertions(+)
diff --git a/contrib/comple
'git difftool' is clearly a frontend to 'git diff' and is used in
exactly the same way, but it uses a misleading completion function name
__git_complete_file (aliased to to __git_complete_revlist_file). Change
it to use __git_complete_revlist_file, just like 'git diff'. No
functional changes.
Si
Another lazy Sunday afternoon. All of these are trivial.
Thanks.
Ramkumar Ramachandra (6):
prompt: don't scream continuation state
completion: add common options for rev-parse
completion: add common options for blame
completion: correct completion for format-patch
completion: clarify d
Currently, when performing any operation that saves the state and
expects the user the continue (like rebase, bisect, am), the prompt
screams:
artagnon|completion|REBASE-i 2/2:~/src/git$
Lowercase the words, so we get a more pleasant
artagnon|completion|rebase-i 2/2:~/src/git$
Signed-off-by
Hi,
.gitignore is a flexible way to customize what dir/file to search or
not to search. So it is of general use and is more flexible than what
is offered by "find". I'm wondering if there is an API than I can use
besides using it within git. Thanks.
--
Regards,
Peng
--
To unsubscribe from this l
Change the type merge_fn_t to accept the array of cache_entry pointers
as const pointers to const pointers. This documents the fact that the
merge functions don't modify the cache_entry contents or replace any of
the pointers in the array.
Only a single cast is necessary in unpack_nondirectories
Duplicate the merge entry right away and work with that instead of
modifying the entry we got and duplicating it only at the end of
the function. Then mark that pointer const to document that we
don't modify the referenced cache_entry.
This change is safe because all existing merge functions call
Changes in v2: Only changed the loop style in patch 7, as suggested
by Felipe.
This series adds const to cache_entry pointers in a lot of places, in
order to show that we can free them in unpack_nondirectories, which
the last patch finally does.
First three easy patches for adding const and split
ie_match_stat and ie_modified only derefence their struct cache_entry
pointers for reading. Add const to the parameter declaration here and
do the same for the static helper function used by them, as it's the
same there as well. This allows callers to pass in const pointers.
Signed-off-by: René
The merge functions duplicate entries as needed and they don't free
them. Release them in unpack_nondirectories, the same function
where they were allocated, after we're done.
As suggested by Felipe, use the same loop style (zero-based for loop)
for freeing as for allocating.
Improved-by: Felipe
Add const to struct cache_entry pointers throughout the tree which are
only used for reading. This allows callers to pass in const pointers.
Signed-off-by: René Scharfe
---
builtin/read-tree.c | 2 +-
diff-lib.c | 23 +++---
unpack-trees.c | 91 +++
Add const for pointers that are only dereferenced for reading by the
inline functions copy_cache_entry and ce_mode_from_stat. This allows
callers to pass in const pointers.
Signed-off-by: René Scharfe
---
cache.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/cache.h
While we're add it, mark the struct cache_entry pointer of add_entry
const because we only read from it and this allows callers to pass in
const pointers.
Signed-off-by: René Scharfe
---
unpack-trees.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/unpack-trees.
On Sun, Jun 2, 2013 at 9:03 AM, Ramkumar Ramachandra wrote:
> Currently, the completion for 'git format-patch' uses
> __git_complete_revlist. Although this is technically correct, and you
> can
>
> $ git format-patch master contrib
>
> where master is a ref and contrib is a pathspec, just like
On Sun, Jun 2, 2013 at 10:46 AM, René Scharfe
wrote:
> The merge functions duplicate entries as needed and they don't free
> them. Release them in unpack_nondirectories, the same function
> where they were allocated, after we're done.
>
> As suggested by Felipe, use the same loop style (zero-base
Felipe Contreras wrote:
> This breaks 'git format-patch master..'.
Oh, ouch.
> Moreover, this is a perfectly fine usage of 'git format-patch':
>
> % git format-patch --full-diff master..fc/remote/hg-next --
> contrib/remote-helpers/git-remote-bzr
Never mind then. Drop this patch.
--
To unsubscr
Am 02.06.2013 19:25, schrieb Felipe Contreras:
On Sun, Jun 2, 2013 at 10:46 AM, René Scharfe
wrote:
+ for (i = 0; i < n; i++) {
+ struct cache_entry *ce = src[i + o->merge];
+ if (ce != o->df_conflict_entry)
It's possible that ce is NU
On Sun, Jun 2, 2013 at 12:54 PM, René Scharfe
wrote:
> Am 02.06.2013 19:25, schrieb Felipe Contreras:
>>
>> On Sun, Jun 2, 2013 at 10:46 AM, René Scharfe
>> wrote:
>>>
>>> + for (i = 0; i < n; i++) {
>>> + struct cache_entry *ce = src[i + o->merge];
>>> +
Jens Lehmann writes:
> Am 30.05.2013 01:58, schrieb Junio C Hamano:
>> * jl/submodule-mv (2013-04-23) 5 commits
>> (merged to 'next' on 2013-04-23 at c04f574)
>> + submodule.c: duplicate real_path's return value
>> (merged to 'next' on 2013-04-19 at 45ae3c9)
>> + rm: delete .gitmodules entr
Matthijs Kooijman writes:
>> Doing it "correctly" (in the shorter term) would involve:
>
> Given below suggestion, I take it you don't like what Jonathan proposed
> (changing the meaning of the deepen parameter in the protocol so that
> the server effectively decides how to interpret --depth)?
C
Ramkumar Ramachandra writes:
> So the problem is that I can't do:
>
> git blame -- :/Makefile
>
> So blame has to be converted to use pathspec semantics, and should
> error out when the pathspec doesn't match the concrete path of a file.
Correct, that is what I wrote in two messages ago in the
Duy Nguyen writes:
>> + then
>> + false
>> + fi
>> +'
>
> Nit pick, maybe this instead?
>
> test_must_fail grep "^one/a.1" output
Neither.
! grep "^one/a.1" output
The second bullet point in the "Don't" section of t/README may want
to be updated to clarify tha
Felipe Contreras writes:
> Before overwriting the destination index, first let's discard it's
> contents.
>
> Signed-off-by: Felipe Contreras
> ---
> unpack-trees.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/unpack-trees.c b/unpack-trees.c
> index ede4299..eff29
Xidorn Quan writes:
> Add protocol imap, imaps, ftp and smtp for credential-osxkeychain.
>
> Signed-off-by: Xidorn Quan
> Acked-by: John Szakmeister
> Acked-by: Jeff King
> ---
Hmph, I think I already have an identical copy in my tree. Sent a
wrong patch?
> contrib/credential/osxkeychain/g
On Sun, Jun 2, 2013 at 2:33 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> Before overwriting the destination index, first let's discard it's
>> contents.
>>
>> Signed-off-by: Felipe Contreras
>> ---
>> unpack-trees.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>>
Ramkumar Ramachandra writes:
>> Without
>> --pickaxe-all, only the filepairs matching the given
>> criterion is left in the output; all filepairs are left in
>> the output when --pickaxe-all is used and if at least one
>> filepair matches the given criterio
They haven't been touched in six years.
Signed-off-by: Ramkumar Ramachandra
---
Another candidates for removal: contrib/blameview (6 years); anoyone
using this?
contrib/continuous/cidaemon| 503 -
contrib/continuous/post-receive-cinotify |
Am 02.06.2013 19:59, schrieb Felipe Contreras:
On Sun, Jun 2, 2013 at 12:54 PM, René Scharfe
wrote:
Am 02.06.2013 19:25, schrieb Felipe Contreras:
On Sun, Jun 2, 2013 at 10:46 AM, René Scharfe
wrote:
+ for (i = 0; i < n; i++) {
+ struct cache_entry *ce =
Junio C Hamano wrote:
>> Why do a poor-man's version of --pickaxe-all here, when the last
>> paragraph already does justice to this?
>
> The point of the first paragraph is to serve to help both:
My question pertains to whether or not the explanation of
--pickaxe-all can wait till the last paragra
Michael Haggerty writes:
>> The only caller of remove-duplicates is bundle.c, which gets many
>> starting points and end points from the command line and tries to be
>> nice by removing obvious duplicates, e.g.
>>
>> git bundle create t.bundle master master
>>
>> but I think its logic of d
Anthony Ramine writes:
> ase folding is not done correctly when matching against the [:upper:]
> character class and uppercased character ranges (e.g. A-Z).
> Specifically, an uppercase letter fails to match against any of them
> when case folding is requested because plain characters in the patt
Felipe Contreras writes:
> It's _very_ slow in many cases, and there's really no point in fetching
> *everything* from the remote just for completion. In many cases it might
> be faster for the user to type the whole thing.
Besides, if I understand the use of __git_refs correctly, it is
primaril
Felipe Contreras writes:
> On Sun, Jun 2, 2013 at 2:33 PM, Junio C Hamano wrote:
>> Felipe Contreras writes:
>>
>>> Before overwriting the destination index, first let's discard it's
>>> contents.
>>>
>>> Signed-off-by: Felipe Contreras
>>> ---
>>> unpack-trees.c | 4 +++-
>>> 1 file changed,
John Keeping writes:
> On Thu, May 30, 2013 at 10:38:59PM +0530, Ramkumar Ramachandra wrote:
>> Matthieu Moy wrote:
>> > I find it a bit weird that Git sets the configuration for external
>> > commands, but it may make sense. No strong opinion here.
>>
>> I don't mean a setenv() kind of thing: h
On Sun, Jun 2, 2013 at 3:26 PM, René Scharfe
wrote:
> Am 02.06.2013 19:59, schrieb Felipe Contreras:
>
>> On Sun, Jun 2, 2013 at 12:54 PM, René Scharfe
>> wrote:
>>>
>>> Am 02.06.2013 19:25, schrieb Felipe Contreras:
On Sun, Jun 2, 2013 at 10:46 AM, René Scharfe
wrote:
>
Ramkumar Ramachandra writes:
> They haven't been touched in six years.
>
> Signed-off-by: Ramkumar Ramachandra
> ---
> Another candidates for removal: contrib/blameview (6 years); anoyone
> using this?
This is in line with contrib/README "removal of disused and inactive
ones", I think. If so
On Sun, Jun 2, 2013 at 5:17 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> On Sun, Jun 2, 2013 at 2:33 PM, Junio C Hamano wrote:
>>> Felipe Contreras writes:
>>>
Before overwriting the destination index, first let's discard it's
contents.
Signed-off-by: Felipe Con
On Sun, Jun 2, 2013 at 5:08 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> It's _very_ slow in many cases, and there's really no point in fetching
>> *everything* from the remote just for completion. In many cases it might
>> be faster for the user to type the whole thing.
>
> Besides,
Am 03.06.2013 00:38, schrieb Felipe Contreras:
On Sun, Jun 2, 2013 at 3:26 PM, René Scharfe
wrote:
Am 02.06.2013 19:59, schrieb Felipe Contreras:
On Sun, Jun 2, 2013 at 12:54 PM, René Scharfe
wrote:
Am 02.06.2013 19:25, schrieb Felipe Contreras:
On Sun, Jun 2, 2013 at 10:46 AM, René Sch
On Sun, Jun 2, 2013 at 6:06 PM, René Scharfe
wrote:
> Am 03.06.2013 00:38, schrieb Felipe Contreras:
>
>> On Sun, Jun 2, 2013 at 3:26 PM, René Scharfe
>> wrote:
>>>
>>> Am 02.06.2013 19:59, schrieb Felipe Contreras:
>>>
On Sun, Jun 2, 2013 at 12:54 PM, René Scharfe
wrote:
>
>
>
Hello Junio,
Replied inline.
Regards,
--
Anthony Ramine
Le 2 juin 2013 à 23:53, Junio C Hamano a écrit :
> Anthony Ramine writes:
>
>> ase folding is not done correctly when matching against the [:upper:]
>> character class and uppercased character ranges (e.g. A-Z).
>> Specifically, an upp
Johannes Sixt writes:
> In t4023 and t4114, we have to remove the entries using 'git rm' because
> otherwise the entries that must turn from symbolic links to regular files
> would stay symbolic links in the index. For the same reason, we have to
> use 'git mv' instead of plain 'mv' in t3509.
>
>
Thomas Rast writes:
> This interacts with the tests from
>
>> * fc/at-head (2013-05-08) 13 commits
>
> to fail valgrind in t1508 like so:
>
> ==22927== Invalid read of size 1
> ==22927==at 0x4C2C71B: __GI_strnlen (mc_replace_strmem.c:377)
> ==22927==by 0x567FF6B: vfprintf (in /lib64
Am 03.06.2013 01:23, schrieb Felipe Contreras:
I didn't say we should do 'if (ce) free(ce);' instead of 'free(ce);' I
said we should do 'if (cd && ce != o->df_conflict_entry)' instead of
'if (ce != o->df_conflict_entry)'.
I did assume you meant the latter.
There's no reason not to.
Only the
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
Many topics that have been cooking in 'next' from the previous cycle
have now graduated to 'master', so the RelNotes have been updated
again.
N
On Sun, Jun 2, 2013 at 6:47 PM, René Scharfe
wrote:
> Am 03.06.2013 01:23, schrieb Felipe Contreras:
>
>> I didn't say we should do 'if (ce) free(ce);' instead of 'free(ce);' I
>> said we should do 'if (cd && ce != o->df_conflict_entry)' instead of
>> 'if (ce != o->df_conflict_entry)'.
>
>
> I did
Anybody? Any ideas?
Thanks in advance!
Eugene
On Fri, May 31, 2013 at 4:22 PM, Eugene Sajine wrote:
> Hi,
>
> I'm trying to test this new feature and having problems getting any
> results in the following scenario:
>
> i have a repo in local folder
>
> /home/users/myuser/repos/projectA/.git
>
>
2013/6/3 Junio C Hamano :
>
> * jx/clean-interactive (2013-05-22) 15 commits
> - test: add t7301 for git-clean--interactive
> - git-clean: add documentation for interactive git-clean
> - git-clean: add ask each interactive action
> - git-clean: add select by numbers interactive action
> - git-
Typo in Documentation/RelNotes/1.8.4.txt
line 39:
opportunisticly -> opportunistically
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
By default, reflog won't show committer date and for some cases won't
show commit log either. It will be helpful to show them all by passing
a more complicated pretty formatter to `git reflog` like this:
$ git reflog show \
--pretty="%Cred%h%Creset %gd: %gs%n >> %Cblue%ci (%cr)%Creset:
54 matches
Mail list logo
