On Sat, Jun 1, 2013 at 11:26 PM, Ramkumar Ramachandra
artag...@gmail.com 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
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
Add support for completing 'git blame'. List only the common short
options.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
contrib/completion/git-completion.bash | 11 +++
1 file changed, 11 insertions(+)
diff --git a/contrib/completion/git-completion.bash
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 artag...@gmail.com
---
contrib/completion/git-completion.bash | 11 +++
1 file changed, 11 insertions(+)
diff
'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.
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
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$
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
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
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
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:
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 rene.scha...@lsrfire.ath.cx
---
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 rene.scha...@lsrfire.ath.cx
---
cache.h | 6 --
1 file changed, 4 insertions(+), 2
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 rene.scha...@lsrfire.ath.cx
---
unpack-trees.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
On Sun, Jun 2, 2013 at 10:46 AM, René Scharfe
rene.scha...@lsrfire.ath.cx 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
Felipe Contreras wrote:
This breaks 'git format-patch master..TAB'.
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
Am 02.06.2013 19:25, schrieb Felipe Contreras:
On Sun, Jun 2, 2013 at 10:46 AM, René Scharfe
rene.scha...@lsrfire.ath.cx wrote:
+ for (i = 0; i n; i++) {
+ struct cache_entry *ce = src[i + o-merge];
+ if (ce != o-df_conflict_entry)
On Sun, Jun 2, 2013 at 12:54 PM, René Scharfe
rene.scha...@lsrfire.ath.cx wrote:
Am 02.06.2013 19:25, schrieb Felipe Contreras:
On Sun, Jun 2, 2013 at 10:46 AM, René Scharfe
rene.scha...@lsrfire.ath.cx wrote:
+ for (i = 0; i n; i++) {
+ struct
Jens Lehmann jens.lehm...@web.de 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
Matthijs Kooijman matth...@stdin.nl 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
Ramkumar Ramachandra artag...@gmail.com 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
Duy Nguyen pclo...@gmail.com 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
Xidorn Quan quanxunz...@gmail.com writes:
Add protocol imap, imaps, ftp and smtp for credential-osxkeychain.
Signed-off-by: Xidorn Quan quanxunz...@gmail.com
Acked-by: John Szakmeister j...@szakmeister.net
Acked-by: Jeff King p...@peff.net
---
Hmph, I think I already have an identical copy
On Sun, Jun 2, 2013 at 2:33 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Before overwriting the destination index, first let's discard it's
contents.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
unpack-trees.c | 4 +++-
Ramkumar Ramachandra artag...@gmail.com 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
They haven't been touched in six years.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Another candidates for removal: contrib/blameview (6 years); anoyone
using this?
contrib/continuous/cidaemon| 503 -
Am 02.06.2013 19:59, schrieb Felipe Contreras:
On Sun, Jun 2, 2013 at 12:54 PM, René Scharfe
rene.scha...@lsrfire.ath.cx wrote:
Am 02.06.2013 19:25, schrieb Felipe Contreras:
On Sun, Jun 2, 2013 at 10:46 AM, René Scharfe
rene.scha...@lsrfire.ath.cx wrote:
+ for (i = 0; i n;
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 paragraph.
Michael Haggerty mhag...@alum.mit.edu 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
Felipe Contreras felipe.contre...@gmail.com writes:
On Sun, Jun 2, 2013 at 2:33 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Before overwriting the destination index, first let's discard it's
contents.
Signed-off-by: Felipe Contreras
John Keeping j...@keeping.me.uk 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
On Sun, Jun 2, 2013 at 3:26 PM, René Scharfe
rene.scha...@lsrfire.ath.cx wrote:
Am 02.06.2013 19:59, schrieb Felipe Contreras:
On Sun, Jun 2, 2013 at 12:54 PM, René Scharfe
rene.scha...@lsrfire.ath.cx wrote:
Am 02.06.2013 19:25, schrieb Felipe Contreras:
On Sun, Jun 2, 2013 at 10:46 AM,
Ramkumar Ramachandra artag...@gmail.com writes:
They haven't been touched in six years.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Another candidates for removal: contrib/blameview (6 years); anoyone
using this?
This is in line with contrib/README removal of disused and
On Sun, Jun 2, 2013 at 5:17 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Sun, Jun 2, 2013 at 2:33 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Before overwriting the destination index,
On Sun, Jun 2, 2013 at 5:08 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com 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
Am 03.06.2013 00:38, schrieb Felipe Contreras:
On Sun, Jun 2, 2013 at 3:26 PM, René Scharfe
rene.scha...@lsrfire.ath.cx wrote:
Am 02.06.2013 19:59, schrieb Felipe Contreras:
On Sun, Jun 2, 2013 at 12:54 PM, René Scharfe
rene.scha...@lsrfire.ath.cx wrote:
Am 02.06.2013 19:25, schrieb Felipe
On Sun, Jun 2, 2013 at 6:06 PM, René Scharfe
rene.scha...@lsrfire.ath.cx wrote:
Am 03.06.2013 00:38, schrieb Felipe Contreras:
On Sun, Jun 2, 2013 at 3:26 PM, René Scharfe
rene.scha...@lsrfire.ath.cx wrote:
Am 02.06.2013 19:59, schrieb Felipe Contreras:
On Sun, Jun 2, 2013 at 12:54 PM,
Hello Junio,
Replied inline.
Regards,
--
Anthony Ramine
Le 2 juin 2013 à 23:53, Junio C Hamano a écrit :
Anthony Ramine n.ox...@gmail.com writes:
ase folding is not done correctly when matching against the [:upper:]
character class and uppercased character ranges (e.g. A-Z).
Johannes Sixt j...@kdbg.org 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
Thomas Rast tr...@inf.ethz.ch 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
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
On Sun, Jun 2, 2013 at 6:47 PM, René Scharfe
rene.scha...@lsrfire.ath.cx 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 !=
Anybody? Any ideas?
Thanks in advance!
Eugene
On Fri, May 31, 2013 at 4:22 PM, Eugene Sajine eugu...@gmail.com 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
2013/6/3 Junio C Hamano gits...@pobox.com:
* 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
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: %s
48 matches
Mail list logo
