On Sat, Aug 22, 2015 at 3:06 PM, René Scharfe wrote:
> A ZIP file directory has a 16-bit field for the number of entries it
> contains. There are 64-bit extensions to deal with that. Demonstrate
> that git archive --format=zip currently doesn't use them and instead
> overflows the field.
>
> Inf
On Thu, Aug 20, 2015 at 11:40:20AM -0700, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
> > The format of the files '.git/rebase-apply/{next,last}' changed slightly
> > with the recent builtin 'git am' conversion: while these files were
> > newline-terminated when written by the scripted version
Lars - thanks for persisting with this!
I'm still trying to fully understand what's going on here - can you
point out where I've got it wrong below please!
The server is on Linux, and is case-sensitive. For whatever reason
(probably people committing changes on Windows in the first place)
we've e
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 i
Changes since v4:
- reduced memory usage by reusing string buffer variables
- re-scoped variables in the for-each function
- added tests for 'worktree list' with bare repos
Notes from previous discussion:
- The following snippet:
> + /* If the common_dir DOES NOT end with '/.git', then it
'git worktree list' uses the for_each_worktree function to iterate,
and outputs in the format: ' ()'
Signed-off-by: Michael Rappazzo
---
Documentation/git-worktree.txt | 11 +-
builtin/worktree.c | 55
t/t2027-worktree-list.sh | 81
A ZIP file directory has a 16-bit field for the number of entries it
contains. There are 64-bit extensions to deal with that. Demonstrate
that git archive --format=zip currently doesn't use them and instead
overflows the field.
InfoZIP's unzip doesn't care about this field and extracts all files
Support more than 65535 entries cleanly by writing a "zip64 end of
central directory record" (with a 64-bit field for the number of
entries) before the usual "end of central directory record" (which
contains only a 16-bit field). InfoZIP's zip does the same.
Archives with 65535 or less entries are
Use a simpler conditional right next to the code which makes a higher
creator version necessary -- namely symlink handling and support for
executable files -- instead of a long line with a ternary operator.
The resulting code has more lines but is simpler and allows reuse of
the value easily.
Sign
On Sat, Aug 22, 2015 at 9:21 PM, Christian Couder
wrote:
> On Sat, Aug 22, 2015 at 8:51 AM, Karthik Nayak wrote:
>>
>> The test t1430 'git branch shows badly named ref' has been changed to
>> check the stderr for the warning regarding the broken ref. This is
>> done as ref-filter throws a warning
On Sat, Aug 22, 2015 at 5:14 PM, Johannes Schindelin
wrote:
> The `format_display_notes()` function clearly assumes that the data
> structure holding the notes has been initialized already, i.e. that the
> `display_notes_trees` variable is no longer `NULL`.
>
> However, when there are no notes wha
On Sat, Aug 22, 2015 at 8:51 AM, Karthik Nayak wrote:
>
> The test t1430 'git branch shows badly named ref' has been changed to
> check the stderr for the warning regarding the broken ref. This is
> done as ref-filter throws a warning for broken refs rather than
> directly printing them.
[...]
>
The `format_display_notes()` function clearly assumes that the data
structure holding the notes has been initialized already, i.e. that the
`display_notes_trees` variable is no longer `NULL`.
However, when there are no notes whatsoever, this variable is still
`NULL`, even after initialization.
So
On Sat, Aug 22, 2015 at 2:49 PM, Ivan Chernyavsky wrote
>
>> Note that "branch --list", "tag --list" and "for-each-ref" are being
>> revamped to share more internal code. If you want to pursue this,
>> you probably would want to build on top of that effort once it is
>> done. That way, you may
22.08.2015, 12:19, "Ivan Chernyavsky" :
> One thing I'm worried about is that git-branch already has option --all. So
> we'll get a semantics conflict with setup_revisions() ("all branches" vs "all
> refs"). This will have to be treated carefully, e.g. retrace and fix effects
> of --all afte
22.08.2015, 01:39, "Junio C Hamano" :
> Ivan Chernyavsky writes:
>
>> Another problem is that builtin/branch.c currently does not use
>> setup_revisions(), so I'll have to hook it there as well.
>
> Heh, you say "problem" above, but I do not think it is a "problem"
> per-se. If you want t
Hello All,
As part of GSoC I'm working on the Unification of 'for-each-ref', 'tag -l'
and 'branch -l'.
Current Progress:
1. Building ref-filter.{c,h} from for-each-ref.
This is the process of creating an initial library for the unification
by moving most of the code from for-each-ref to ref-filt
17 matches
Mail list logo
