Jiang Xin writes:
> 2013/5/13 Matthieu Moy :
>> Jiang Xin writes:
>>
>>> * color.interactive.: Use customized color for interactive
>>>git-clean output (like git add --interactive). may be
>>>prompt, header, help or error.
>>
>> This should go to the documentation (a short summary is w
Jiang Xin writes:
> My initial intention for flags toggle is for git newbies, who are not clear
> about how to use -x/-d/-X/-ff options. I feel it may have values for these
> people.
It may have value for some of them, but throwing too many options in a
menu is usually counter-productive for a n
On Mon, May 13, 2013 at 7:19 AM, Eric Sunshine wrote:
> On Sat, May 11, 2013 at 12:21 PM, Johan Herland wrote:
>> +* When displaying more then just remote-tracking branches, make the
> s/then/than/
Thanks, will fix.
...Johan
--
Johan Herland,
www.herland.net
--
To unsubscribe from th
On Mon, May 13, 2013 at 6:54 AM, Junio C Hamano wrote:
> Johan Herland writes:
>
>> Although we definitely support and encourage use of multi-level branch
>> names, we have never conciously tried to give support for multi-level
>> remote names. Currently, they are allowed, but there is no evidenc
Johan Herland writes:
> Obviously, I named it '%1' since it expands into the _first_ component
> of the (slash-separated) shorthand.
OK, I can buy something like
%*
refs/%*
refs/heads/%*
...
refs/remotes/%*/HEAD
refs/remotes/%1/%2
refs/pee
On Mon, May 13, 2013 at 6:48 AM, Eric Sunshine wrote:
> On Sat, May 11, 2013 at 12:21 PM, Johan Herland wrote:
>> Although we definitely support and encourage use of multi-level branch
>> names, we have never conciously tried to give support for multi-level
>
> s/conciously/consciously/
Thanks,
On Mon, May 13, 2013 at 6:56 AM, Junio C Hamano wrote:
> Johan Herland writes:
>
>> The refname_expand() function no longer uses mkpath()/mksnpath() to
>> perform the pattern expansion. Instead, it uses strbuf_expand(), which
>> removes the need for using fixed-length buffers from the code.
>
> I
Ramkumar Ramachandra writes:
> +finish_rebase () {
> + if test -f "$state_dir/autostash"
> + then
> + stash_sha1=$(cat "$state_dir/autostash")
> + if git stash apply $stash_sha1 2>&1 >/dev/null
> + then
> + echo "Applied autostash"
>
Jiang Xin writes:
> 2013/5/13 Matthieu Moy :
>> Jiang Xin writes:
>>
>>> * color.interactive.: Use customized color for interactive
>>>git-clean output (like git add --interactive). may be
>>>prompt, header, help or error.
>>
>> This should go to the documentation (a short summary is w
On Sat, May 11, 2013 at 12:21 PM, Johan Herland wrote:
> diff --git a/builtin/branch.c b/builtin/branch.c
> index 4480be2..9a6bce8 100644
> --- a/builtin/branch.c
> +++ b/builtin/branch.c
> @@ -328,74 +326,80 @@ static int append_ref(const char *refname, const
> unsigned char *sha1, int flags,
>
Michael Haggerty writes:
> Michael Haggerty (2):
> Extract a struct stat_data from cache_entry
> add a stat_validity struct
Some indentation glitches carried over from the original in that
"from-ondisk" function were distracting while reading it through,
but I think these show us a reasonabl
Kevin Bracey writes:
> On 12/05/2013 19:58, John Keeping wrote:
>>
>> With the patch below, the --ancestry-path version drops to under 2
>> seconds.
>>
>> I'm not sure if this is a good idea though. It helps me say "I know
>> nothing that isn't on the ancestry path can be patch-identical, so don
Michael J Gruber writes:
> Adding to that:
>
> Somehow I still feel I should introduce a new attribute "show" (or a
> better name) similar to "diff" so that you can specifiy a diff driver to
> use for showing a blob (or grepping it), which may or may not be the
> same you use for "diff". This wou
Ramkumar Ramachandra writes:
> Minor changes since v2 in response to reviews by Junio and Eric
> Sunshine.
>
> Should be ready to merge soon.
That, and the "completed" on the Subject line are not for you to
decide, I would have to say ;-)
Overall the patches look cleanly done, but I did not car
Ramkumar Ramachandra writes:
> Nobody has branch names that end with + or *. Then why put a space
> after the branch name and before [*|+][=|<|>] in the prompt string?
I do not think the space is for disambiguation.
It is like asking why typeset a space after a sentence a tad wider
than a spac
Heiko Voigt writes:
> /*
> - * The fields f and name of top need to be initialized before calling
> + * All source specific fields in the union, name and the callbacks
> + * fgetc, ungetc, ftell of top need to be initialized before calling
> * this function.
> */
> -static int do_config_from
Johan Herland writes:
> The refname_expand() function no longer uses mkpath()/mksnpath() to
> perform the pattern expansion. Instead, it uses strbuf_expand(), which
> removes the need for using fixed-length buffers from the code.
It is a brilliant idea to use strbuf_expand() for this. I like it.
Johan Herland writes:
> Although we definitely support and encourage use of multi-level branch
> names, we have never conciously tried to give support for multi-level
> remote names. Currently, they are allowed, but there is no evidence that
> they are commonly used.
>
> Now, they do provide a so
On Sat, May 11, 2013 at 12:21 PM, Johan Herland wrote:
> Although we definitely support and encourage use of multi-level branch
> names, we have never conciously tried to give support for multi-level
s/conciously/consciously/
> remote names. Currently, they are allowed, but there is no evidence
It can sometimes be useful to know whether a path in the
filesystem has been updated without going to the work of
opening and re-reading its content. We trust the stat()
information on disk already to handle index updates, and we
can use the same trick here.
This patch introduces a "stat_validity"
This structure will later be used to check the validity of other types
of file.
Signed-off-by: Michael Haggerty
---
Feel free to suggest better names. I tried to follow the convention
of names used nearby.
builtin/ls-files.c | 12 ++--
cache.h| 33 ---
read-cache.c
This series is a possible replacement for Peff's
"[PATCH 2/4] add a stat_validity struct"
that doesn't misuse the cache_entry too much in the implementation of
the new functions. It is only interesting in the context of Peff's
series (or something like it), or if there are other places where
2013/5/13 Matthieu Moy :
> Jiang Xin writes:
>
>> * color.interactive.: Use customized color for interactive
>>git-clean output (like git add --interactive). may be
>>prompt, header, help or error.
>
> This should go to the documentation (a short summary is welcome in the
> commit messag
On 05/07/2013 04:43 AM, Jeff King wrote:
> Once we read the packed-refs file into memory, we cache it
> to save work on future ref lookups. However, our cache may
> be out of date with respect to what is on disk if another
> process is simultaneously packing the refs. Normally it
> is acceptable fo
2013/5/13 Matthieu Moy :
> Junio C Hamano writes:
>
>> Cleaning all unneeded files inside a single interactive session
>> should *never* be the goal---that will lead to an over-engineered
>> design (e.g. switching "clean -x" flags in the middle? why?). I
>> think Jiang's latest series is already
On 05/07/2013 04:39 AM, Jeff King wrote:
> It can sometimes be useful to know whether a path in the
> filesystem has been updated without going to the work of
> opening and re-reading its content. We trust the stat()
> information on disk already to handle index updates, and we
> can use the same t
On Sat, May 11, 2013 at 4:22 AM, David Aguilar wrote:
> Mac OS X Mountain Lion prints warnings when building git:
>
> warning: 'SHA1_Init' is deprecated
> (declared at /usr/include/openssl/sha.h:121)
>
> Silence the warnings by using the Common Digest SHA-1
> functions for SHA1_Ini
On Sun, May 12, 2013 at 03:54:14PM -0700, Junio C Hamano wrote:
> Paul Mackerras writes:
>
> > On Sat, Apr 27, 2013 at 05:01:39PM -0500, Felipe Contreras wrote:
> >> git diff is perfectly able to do this with '-- files', no need for
> >> manual filtering.
> >>
> >> Signed-off-by: Felipe Contrera
On 05/07/2013 04:38 AM, Jeff King wrote:
> [...]
> This patch solves it by factoring out the fallback code from
> the lstat() case and calling it from both places. We do not
> need to do the same thing for the symlink/readlink code
> path, even though it might receive ENOENT, too, because
> symlink
On 05/07/2013 04:38 AM, Jeff King wrote:
> When we attempt to resolve a ref, the first thing we do is
> call lstat() to see if it is a symlink or a real ref. If we
> find that the ref is missing, we fall back to looking it up
> in the packed-refs file. If we find the loose ref does exist
> (and is
Paul Mackerras writes:
> On Sat, Apr 27, 2013 at 05:01:39PM -0500, Felipe Contreras wrote:
>> git diff is perfectly able to do this with '-- files', no need for
>> manual filtering.
>>
>> Signed-off-by: Felipe Contreras
>
> Thanks, applied, with the commit message expanded to say that this
> ma
The set-up step to prepare a repository with 5 tags used a
non-porable '\+' to match one-or-more.
The error was not caught because the next test that uses that
repository did not even bother to check if these expected tags were
actually cloned to the resulting repository.
Fix the sed construc
Kevin Bracey writes:
> Although I realised after
> sending my mail you could also use
>
>git log --ancestry-path --left-right E...F --not $(git merge-base
> --all E F)
>
> which looks like we're having to repeat ourselves because it's not
> paying attention...
You are half wrong; "--left-rig
John Keeping writes:
>> But it is not a big problem. Either 3-way merge notices that there
>> is nothing new, or you get a conflict and have chance to inspect
>> what is going on.
>
> It's not a problem here, but false negatives would be annoying if you're
> looking at "git log --cherry-mark".
On Sun, May 12, 2013 at 2:25 PM, Junio C Hamano wrote:
> David Aguilar writes:
>
>> Yup, warnings still remain, but only in imap-send.c. All the SHA1
>> ones are gone. Those were particularly bothersome since they affected
>> several files.
>>
>> I haven't dug to deeply into how to fix these.
David Aguilar writes:
> Yup, warnings still remain, but only in imap-send.c. All the SHA1
> ones are gone. Those were particularly bothersome since they affected
> several files.
>
> I haven't dug to deeply into how to fix these. In case anyone has any
> pointers, the warnings look like this:
Heiko Voigt writes:
> Since ages we do not care about our program enough. Lets not treat them
> as slaves anymore and say please.
>
> Signed-off-by: Heiko Voigt
> Signed-off-by: Jonathan Nieder
> Signed-off-by: Jens Lehmann
> Signed-off-by: Thomas Rast
> Signed-off-by: Johan Herland
So thes
On Sun, May 12, 2013 at 11:37 AM, Eric Sunshine wrote:
> On Sat, May 11, 2013 at 4:22 AM, David Aguilar wrote:
>> Mac OS X Mountain Lion prints warnings when building git:
>>
>> warning: 'SHA1_Init' is deprecated
>> (declared at /usr/include/openssl/sha.h:121)
>>
>> Silence the wa
On Sat, May 11, 2013 at 4:22 AM, David Aguilar wrote:
> Mac OS X Mountain Lion prints warnings when building git:
>
> warning: 'SHA1_Init' is deprecated
> (declared at /usr/include/openssl/sha.h:121)
>
> Silence the warnings by using the Common Digest SHA-1
> functions for SHA1_Ini
On 12/05/2013 19:58, John Keeping wrote:
With the patch below, the --ancestry-path version drops to under 2
seconds.
I'm not sure if this is a good idea though. It helps me say "I know
nothing that isn't on the ancestry path can be patch-identical, so don't
bother checking if it is" but it reg
Junio C Hamano writes:
> Cleaning all unneeded files inside a single interactive session
> should *never* be the goal---that will lead to an over-engineered
> design (e.g. switching "clean -x" flags in the middle? why?). I
> think Jiang's latest series is already way over-engineered,
I didn't r
On Fri, May 10, 2013 at 10:23 PM, David Aguilar wrote:
> Mac OS X Mountain Lion prints warnings when building git:
>
> warning: 'SHA1_Init' is deprecated
> (declared at /usr/include/openssl/sha.h:121)
>
> Silence the warnings by using the Common Digest SHA-1
> functions for SHA1_In
Jiang Xin writes:
> * color.interactive.: Use customized color for interactive
>git-clean output (like git add --interactive). may be
>prompt, header, help or error.
This should go to the documentation (a short summary is welcome in the
commit messages in addition, but users won't read
On 12/05/2013 19:33, John Keeping wrote:
On Sun, May 12, 2013 at 05:28:24PM +0100, John Keeping wrote:
You're right (and I was wrong in my reply to Junio's parallel message)
ancestry path does seem to be what I want:
$ git rev-list --ancestry-path --left-right --count \
master
Jiang Xin writes:
> +column.clean::
> + Specify whether to output cleaning files in `git clean -i` in columns.
> + See `column.ui` for details.
> +
> +static void pretty_print_dels()
Ah, OK. That's the helper function I was expecting in 01/10. The patches
would be easier to review if t
On Sun, May 12, 2013 at 05:28:24PM +0100, John Keeping wrote:
> However, this doesn't seem to make a difference to the time taken when I
> add in --cherry-mark (which is why I was partially correct in the
> parallel thread - it doesn't have the effect on cherry-mark that I want
> it to):
>
> $
Jiang Xin writes:
> + putchar('\n');
> +
> + /* Display dels in "Would remove ..." format */
> + for_each_string_list_item(item, &del_list) {
> + qname = quote_path_relative(item->string, -1,
> &buf, *the_pre
On Sun, May 12, 2013 at 05:28:24PM +0100, John Keeping wrote:
> On Sun, May 12, 2013 at 06:44:30PM +0300, Kevin Bracey wrote:
> > On 11/05/2013 15:23, John Keeping wrote:
> > > This is helpful when examining branches with disjoint roots, for example
> > > because one is periodically merged into a s
On Sun, May 12, 2013 at 06:44:30PM +0300, Kevin Bracey wrote:
> On 11/05/2013 15:23, John Keeping wrote:
> > This is helpful when examining branches with disjoint roots, for example
> > because one is periodically merged into a subtree of the other.
> >
> >
> >
> > $ git log --left-right F
On 11/05/2013 15:23, John Keeping wrote:
This is helpful when examining branches with disjoint roots, for example
because one is periodically merged into a subtree of the other.
$ git log --left-right F...E --not $(git merge-base --merge-child F E)
< F
> E
Wouldn'
Hi all,
This is a complicated question to try and ask, let alone answer, so I had best
give some background.
I have two repositories --- one of them, which I'll call "repoA", is the main
repository, it's the one which most of the code we develop ends up. The other
repository, "repoB" is our p
davidf...@gmail.com wrote on Mon, 06 May 2013 10:59 -0700:
> I've observed that the p4 command that git-p4 delegates to
> occasionally outputs Windows-style line endings even on the OS X
> platform. When this happens, git-p4 gets very confused and crashes
> out.
>
> I've attached a patch which see
Junio C Hamano venit, vidit, dixit 11.05.2013 19:36:
> Michael J Gruber writes:
>
+ if (!DIFF_OPT_TOUCHED(&rev->diffopt, ALLOW_TEXTCONV) ||
+ !DIFF_OPT_TST(&rev->diffopt, ALLOW_TEXTCONV))
+ return stream_blob_to_fd(1, sha1, NULL, 0);
>>>
>>> It is surprising that the
Adding to that:
Somehow I still feel I should introduce a new attribute "show" (or a
better name) similar to "diff" so that you can specifiy a diff driver to
use for showing a blob (or grepping it), which may or may not be the
same you use for "diff". This would be a much more fine-grained and
sys
On Sun, May 12, 2013 at 12:41:31PM +0100, John Keeping wrote:
> diff --git a/t/t6007-rev-list-cherry-pick-file.sh
> b/t/t6007-rev-list-cherry-pick-file.sh
> index 28d4f6b..378cf3e 100755
> --- a/t/t6007-rev-list-cherry-pick-file.sh
> +++ b/t/t6007-rev-list-cherry-pick-file.sh
> @@ -207,4 +207,20 @
This new feature allows a rebase to be executed on a dirty worktree or
index. It works by creating a temporary "dangling merge commit" out
of the worktree and index changes (via 'git stash create'), and
automatically applying it after a successful rebase or abort.
rebase stores the SHA-1 hex of t
Return control to the caller git-rebase.sh to get these two tasks
rm -fr "$dotest"
git gc --auto
done by it.
Signed-off-by: Ramkumar Ramachandra
---
git-rebase--merge.sh | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/git-rebase--merge.sh b/git-rebase--merge.sh
We only need to do these two tasks
git gc --auto
rm -fr "$dotest"
ourselves if the script was invoked as a standalone program; when
invoked with --rebasing (from git-rebase--am.sh), cascade control back
to the ultimate caller git-rebase.sh to do this for us.
Signed-off-by: Ramkumar Ramac
Return control to the caller git-rebase.sh to get these two tasks
rm -fr "$dotest"
git gc --auto
done by it.
Signed-off-by: Ramkumar Ramachandra
---
git-rebase--interactive.sh | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-
On successful completion of a rebase in git-rebase--$backend.sh, the
$backend script cleans up on its own and exits. The cleanup routine
is however, independent of the $backend, and each $backend script
unnecessarily duplicates this work:
rm -rf "$state_dir"
git gc --auto
Prepare git-reb
In preparation for a later patch that creates $dotest/autostash in
git-rebase.sh before anything else happens, don't assume that the
presence of a $dotest directory implies the existence of the
$dotest/next and $dotest/last files. Look for them explicitly.
Signed-off-by: Ramkumar Ramachandra
---
In preparation for a later patch that will create $state_dir/autostash
in git-rebase.sh before anything else can happen, change a `mkdir
$state_dir` call to `mkdir -p $state_dir`. The change is safe,
because this is not a test to detect an in-progress rebase (that is
already done much earlier in g
Minor changes since v2 in response to reviews by Junio and Eric
Sunshine.
Should be ready to merge soon.
Ramkumar Ramachandra (7):
am: tighten a conditional that checks for $dotest
rebase -i: don't error out if $state_dir already exists
rebase: prepare to do generic housekeeping
am: retur
This adds a new configuration variable "patchid.cacheRef" which controls
whether (and where) patch IDs will be cached in a notes tree. The cache
includes a hash of the diff options in place when the cache was
generated as well as the version of Git that generated it.
When the diff options hash ch
On Sun, May 12, 2013 at 3:20 AM, Heiko Voigt wrote:
> Since ages we do not care about our program enough. Lets not treat them
> as slaves anymore and say please.
>
> Signed-off-by: Heiko Voigt
> Signed-off-by: Jonathan Nieder
> Signed-off-by: Jens Lehmann
> Signed-off-by: Thomas Rast
> Signed-
Heiko Voigt wrote:
> Since ages we do not care about our program enough. Lets not treat them
> as slaves anymore and say please.
> 9 files changed, 90 insertions(+), 23 deletions(-)
Um, why such an elaborate joke?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a
Thomas Rast writes:
> Jeff King writes:
>
>> When we run a regular "git fetch" without arguments, we
>> update the tracking refs according to the configured
>> refspec. However, when we run "git fetch origin master" (or
>> "git pull origin master"), we do not look at the configured
>> refspecs a
Jeff King writes:
> When we run a regular "git fetch" without arguments, we
> update the tracking refs according to the configured
> refspec. However, when we run "git fetch origin master" (or
> "git pull origin master"), we do not look at the configured
> refspecs at all, and just update FETCH_H
On Sat, May 11, 2013 at 06:57:02PM -0500, Johannes Schindelin wrote:
> On Sat, 11 May 2013, Linus Torvalds wrote:
>
> > [...] I really think caching patch ID's should be something people
> > should be aware of is fundamentally wrong, even if it might work.
>
> Given the incredible performance win
On Sat, May 11, 2013 at 08:00:44PM -0700, Junio C Hamano wrote:
> Linus Torvalds writes:
>
> > On Sat, May 11, 2013 at 2:49 PM, John Keeping wrote:
> >>
> >> Hmm... I hadn't realised that. Looking a bit closer, it looks like
> >> init_patch_ids sets up its own diffopts so its not affected by th
Since ages we do not care about our program enough. Lets not treat them
as slaves anymore and say please.
Signed-off-by: Heiko Voigt
Signed-off-by: Jonathan Nieder
Signed-off-by: Jens Lehmann
Signed-off-by: Thomas Rast
Signed-off-by: Johan Herland
---
.gitignore | 1 +
Since ages we do not care about our program enough. Lets not treat them
as slaves anymore and say please.
Signed-off-by: Heiko Voigt
Signed-off-by: Jonathan Nieder
Signed-off-by: Jens Lehmann
Signed-off-by: Thomas Rast
Signed-off-by: Johan Herland
---
I do not know why this very urgent patch
72 matches
Mail list logo
