On Sun, Aug 30, 2015 at 9:00 AM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Sat, Aug 29, 2015 at 10:12 AM, Karthik Nayak karthik@gmail.com wrote:
Add a function called 'for_each_fullref_in()' to refs.{c,h} which
iterates through each ref for the given path without trimming the path
On Sun, Aug 30, 2015 at 9:12 AM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Sat, Aug 29, 2015 at 10:12 AM, Karthik Nayak karthik@gmail.com wrote:
Create format_ref_array_item() out of show_ref_array_item(). This will
store the output format for the given ref_array_item into the
On Sun, Aug 30, 2015 at 2:51 AM, Karthik Nayak karthik@gmail.com wrote:
On Sun, Aug 30, 2015 at 9:00 AM, Eric Sunshine sunsh...@sunshineco.com
wrote:
On Sat, Aug 29, 2015 at 10:12 AM, Karthik Nayak karthik@gmail.com
wrote:
+int for_each_fullref_in(const char *prefix, each_ref_fn fn,
On Sun, Aug 30, 2015 at 10:11 AM, Gabor Bernat ber...@primeranks.net wrote:
this can work instead of the data command for getting the time
elapsed, however for getting the actual date of a timestamp is not
possible generally; so I think I will just remove that part.
Bernát GÁBOR
On Sun, Aug
On Sun, Aug 30, 2015 at 4:04 AM, Mikael Magnusson mika...@gmail.com wrote:
On Sun, Aug 30, 2015 at 5:15 AM, Eric Sunshine sunsh...@sunshineco.com
wrote:
On Sat, Aug 29, 2015 at 11:00 PM, Gabor Bernat ber...@primeranks.net wrote:
Reading after it, I think the most close we can get with this
Thanks for your feedback!
I like the “handle big files” plugin kind of idea. However, I wonder if it
makes sense to put more and more stuff into git-p4.py (3000 LOC already). What
do you think about splitting git-p4 into multiple files?
Regarding Python 3:
Would you drop Python 2 support or
On Sun, Aug 30, 2015 at 9:12 AM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Sat, Aug 29, 2015 at 10:12 AM, Karthik Nayak karthik@gmail.com wrote:
Create format_ref_array_item() out of show_ref_array_item(). This will
store the output format for the given ref_array_item into the
Comments below.
diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt
index 82aa5d6..a188840 100644
--- a/Documentation/git-p4.txt
+++ b/Documentation/git-p4.txt
@@ -252,6 +252,18 @@ Git repository:
Use a client spec to find the list of interesting files in p4.
Hello,
I've submitted this first to this list as a feature request, however
in the meantime with the help of Jeff King p...@peff.net, Junio C
Hamano gits...@pobox.com, Eric Sunshine sunsh...@sunshineco.com
and Mikael Magnusson mika...@gmail.com came up with solution, so now
I submit it as a
On 26.08.15 21:46, David Turner wrote:
Instead of a linear search over common_list to check whether
a path is common, use a trie. The trie search operates on
path prefixes, and handles excludes.
Signed-off-by: David Turner dtur...@twopensource.com
---
path.c| 226
On 28 August 2015 at 13:24, larsxschnei...@gmail.com wrote:
From: Lars Schneider larsxschnei...@gmail.com
I am migrating huge Perforce repositories including history to Git. Some of
them contain large files that would blow up the resulting Git repositories.
This patch adds an option to
While we are here, remove some boilerplate by using test_commit.
Signed-off-by: Erik Elfström erik.elfst...@gmail.com
---
t/t7300-clean.sh | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/t/t7300-clean.sh b/t/t7300-clean.sh
index 27557d6..86ceb38 100755
---
On Sat, Aug 29, 2015 at 10:12 AM, Karthik Nayak karthik@gmail.com wrote:
In 'tag.c' we can print N lines from the annotation of the tag using
the '-nnum' option. Copy code from 'tag.c' to 'ref-filter' and
modify it to support appending of N lines from the annotation of tags
to the given
this can work instead of the data command for getting the time
elapsed, however for getting the actual date of a timestamp is not
possible generally; so I think I will just remove that part.
Bernát GÁBOR
On Sun, Aug 30, 2015 at 10:04 AM, Mikael Magnusson mika...@gmail.com wrote:
On Sun, Aug 30,
On Sun, Aug 30, 2015 at 10:39 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
I meant mutually exclusive in the sense of only one or the other of
'align' and 'contents' ever being used within a single 'atom_value'
instance. (I wasn't referring to the user experience.)
Sorry for the
for_each_worktree iterates through each worktree and invokes a callback
function. The main worktree (if not bare) is always encountered first,
followed by worktrees created by `git worktree add`.
If the callback function returns a non-zero value, iteration stops, and
the callback's return value
'git worktree list' uses the for_each_worktree function to iterate,
and outputs the worktree dir. With the verbose option set, it also
shows the branch or revision currently checked out in that worktree.
Signed-off-by: Michael Rappazzo rappa...@gmail.com
---
Documentation/git-worktree.txt | 10
Changes since v5:
- used already existing functions instead of reimplementing:
- resolve_ref_unsafe
- find_unique_abbrev
- shorten_unambiguous_ref
- added more tests for 'worktree list'
Michael Rappazzo (2):
worktree: add 'for_each_worktree' function
worktree: add 'list'
On Sun, Aug 30, 2015 at 6:58 PM, Gabor Bernat ber...@primeranks.net wrote:
I would argue against the every n commit check, or at least making it
configurable, as in my case the speed is something between 0.01 and
1.5 seconds per commit. Checking it every n commit would make it I
feel quite
On Sun, Aug 30, 2015 at 7:45 AM, Gabor Bernat ber...@primeranks.net wrote:
I've submitted this first to this list as a feature request, however
in the meantime with the help of Jeff King p...@peff.net, Junio C
Hamano gits...@pobox.com, Eric Sunshine sunsh...@sunshineco.com
and Mikael Magnusson
We currently ignore the first line passed to `git interpret-trailers`,
when looking for the beginning of the trailers.
Unfortunately this does not work well when a commit is created with a
line break in the title, using for example the following command:
git commit -m 'place of
code: change we
On Sun, Aug 30, 2015 at 5:15 AM, Eric Sunshine sunsh...@sunshineco.com wrote:
(Please don't top-post on this list.)
On Sat, Aug 29, 2015 at 11:00 PM, Gabor Bernat ber...@primeranks.net wrote:
Reading after it, I think the most close we can get with this is, awk
'BEGIN { print strftime(%c,
I'm working on an old OS X machine. I needed to perform:
AR=libtool
ARFLAGS=-static -o
...
make configure
./configure ...
make
However, it appears the Makefile does not respect ARFLAGS:
$ grep -IR '$(AR)' *
Makefile:$(QUIET_AR)$(RM) $@ $(AR) rcs $@ $^
Makefile:
Eric Sunshine sunsh...@sunshineco.com writes:
With the disclaimer that I wasn't following the quoting discussion
closely: Is this condition going to be sufficient for all cases, such
as an %(if:) atom? That is, if you have:
%(if:notempty)%(bloop)%(then) --option=%(bloop)%(end)
isn't
(please don't top-post on this list)
On Sun, Aug 30, 2015 at 12:58 PM, Gabor Bernat ber...@primeranks.net wrote:
I would argue against the every n commit check, or at least making it
configurable, as in my case the speed is something between 0.01 and
1.5 seconds per commit. Checking it every n
On Sun, Aug 30, 2015 at 03:40:20PM -0400, Eric Sunshine wrote:
I suppose a viable approach might be to test once outside the loop if
date +%s is supported and print the (%d elapsed / %d estimated
remaining) annotation within the loop if it is, else not. The test
might look something like this:
On Sun, Aug 30, 2015 at 10:57 AM, Karthik Nayak karthik@gmail.com wrote:
On Sun, Aug 30, 2015 at 8:57 AM, Eric Sunshine sunsh...@sunshineco.com
wrote:
+struct align {
+ align_type position;
+ unsigned int width;
};
#define REF_FORMATTING_STATE_INIT { 0, NULL }
@@ -69,6
On Sun, Aug 30, 2015 at 12:52 PM, Junio C Hamano gits...@pobox.com wrote:
http://stackoverflow.com/questions/2445198/get-seconds-since-epoch-in-any-posix-compliant-shell
Found this,
awk 'BEGIN{srand();print srand()}'
srand() in awk returns the previous seed value, and calling it without
an
On Sun, Aug 30, 2015 at 1:02 PM, Karthik Nayak karthik@gmail.com wrote:
On Sun, Aug 30, 2015 at 1:23 PM, Eric Sunshine sunsh...@sunshineco.com
wrote:
On Sat, Aug 29, 2015 at 10:12 AM, Karthik Nayak karthik@gmail.com
wrote:
struct atom_value {
const char *s;
struct
Make DATE_LOCAL a bit flag that may be combined with the other formats.
In order to keep date_mode_type as a true enumeration the possible
combinations are included explicitly (except relative local time which
is nonsensical).
Signed-off-by: John Keeping j...@keeping.me.uk
---
I primarily want
I would argue against the every n commit check, or at least making it
configurable, as in my case the speed is something between 0.01 and
1.5 seconds per commit. Checking it every n commit would make it I
feel quite slow to adapt. But it's debatable.
On 8/30/15, Junio C Hamano gits...@pobox.com
On 30 August 2015 at 11:18, Lars Schneider larsxschnei...@gmail.com wrote:
Thanks for your feedback!
I like the “handle big files” plugin kind of idea. However, I wonder if it
makes sense to put more and more stuff into git-p4.py (3000 LOC already).
What do you think about splitting git-p4
On Sun, Aug 30, 2015 at 8:57 AM, Eric Sunshine sunsh...@sunshineco.com wrote:
Add documentation and tests for the same.
Signed-off-by: Karthik Nayak karthik@gmail.com
---
diff --git a/ref-filter.c b/ref-filter.c
index 432cea0..21c8b5f 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@
Eric Sunshine sunsh...@sunshineco.com writes:
Most portable likely would be Perl, however, that's probably too
heavyweight inside a loop like this, even if called only once each N
iterations.
I think that is true. Now, when it is too heavy to spawn perl,
would it be light enough to spawn
On Sun, Aug 30, 2015 at 1:23 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Sat, Aug 29, 2015 at 10:12 AM, Karthik Nayak karthik@gmail.com wrote:
In 'tag.c' we can print N lines from the annotation of the tag using
the '-nnum' option. Copy code from 'tag.c' to 'ref-filter' and
modify
On Sat, Aug 29, 2015 at 10:12 AM, Karthik Nayak karthik@gmail.com wrote:
In 'tag.c' we can print N lines from the annotation of the tag using
the '-nnum' option. Copy code from 'tag.c' to 'ref-filter' and
modify it to support appending of N lines from the annotation of tags
to the given
On Sun, Aug 30, 2015 at 9:38 AM, Karthik Nayak karthik@gmail.com wrote:
On Sun, Aug 30, 2015 at 8:57 AM, Eric Sunshine sunsh...@sunshineco.com
wrote:
On Sat, Aug 29, 2015 at 10:12 AM, Karthik Nayak karthik@gmail.com
wrote:
+static void append_atom(struct atom_value *v, struct
On Sun, Aug 30, 2015 at 1:27 PM, Junio C Hamano gits...@pobox.com wrote:
Eric Sunshine sunsh...@sunshineco.com writes:
With the disclaimer that I wasn't following the quoting discussion
closely: Is this condition going to be sufficient for all cases, such
as an %(if:) atom? That is, if you
I was rebasing my local kernel patches on top of v4.2 (using Debian
git_1:2.5.1-1_amd64), and ran into the following when one of the
files I modified got renamed in mainline:
Applying: drivers/ntb/ntb_hw.c: Use prandom_u32_max()
Using index info to reconstruct a base tree...
A
On Sun, Aug 30, 2015 at 3:13 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Sat, Aug 29, 2015 at 10:12 AM, Karthik Nayak karthik@gmail.com wrote:
In 'tag.c' we can print N lines from the annotation of the tag using
the '-nnum' option. Copy code from 'tag.c' to 'ref-filter' and
modify
Thanks for working on this. I apologize for not reviewing earlier
rounds (other than v2 [1]); it's been difficult to find a block of
time to do so...
On Sun, Aug 30, 2015 at 3:10 PM, Michael Rappazzo rappa...@gmail.com wrote:
for_each_worktree iterates through each worktree and invokes a
Eric Sunshine sunsh...@sunshineco.com writes:
I suppose a viable approach might be to test once outside the loop if
date +%s is supported and print the (%d elapsed / %d estimated
remaining) annotation within the loop if it is, else not. The test
might look something like this:
echo $(date
42 matches
Mail list logo
