Stefan Beller writes:
> From: John Keeping
>
> stream_blob_to_fd() always frees the filter now, so there is no memory
> leak in entry.c:152 just before the `goto finish`.
>
> Signed-off-by: John Keeping
> Signed-off-by: Stefan Beller
> ---
>
> I added Johns signoff here tentatively, John ca
On 30.03.2015 22:06, Junio C Hamano wrote:
> If add-line-range does not take ownership of
> parent_range from us, shouldn't we be freeing it whether we called
> it or not???
In my understanding it does take ownership of it. (According to my code
review on friday)
--
To unsubscribe from this list:
Stefan Beller writes:
> Signed-off-by: Stefan Beller
> ---
> line-log.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/line-log.c b/line-log.c
> index b43ac58..db6e58d 100644
> --- a/line-log.c
> +++ b/line-log.c
> @@ -1129,6 +1129,9 @@ static int process_ranges_ordinary_commit(str
On 03/30/2015 07:41 PM, Kenny Lee Sin Cheong wrote:
Signed-off-by: Kenny Lee Sin Cheong
---
t/t1505-rev-parse-last.sh | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/t/t1505-rev-parse-last.sh b/t/t1505-rev-parse-last.sh
index 4969edb..a1976ad 100755
--- a/t/t1
On 03/31/2015 03:22 AM, Stefan Beller wrote:
Signed-off-by: Stefan Beller
---
line-log.c | 3 +++
1 file changed, 3 insertions(+)
Would it make sense to join 2/6 and 3/6 into a single patch ?
Both fix the memleaks in the same file, and the
header can be "fix memleaks".
--
To unsubscribe f
On Mon, Mar 30, 2015 at 12:39:17PM -0700, Junio C Hamano wrote:
> Whichever way you implement "remote rename", you will make half of
> the users happy while making other half unhappy. One use case will
> be happier if remote.pushdefault is left intact; the other use case
> will be happier if remo
On Mon, Mar 30, 2015 at 06:22:10PM -0700, Stefan Beller wrote:
> Signed-off-by: Stefan Beller
> ---
> pack-bitmap.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/pack-bitmap.c b/pack-bitmap.c
> index 365f9d9..62a98cc 100644
> --- a/pack-bitmap.c
> +++ b/pack-bitmap.c
> @@ -986,6 +9
On Fri, Mar 27, 2015 at 03:32:48PM -0700, Stefan Beller wrote:
> `recent_bitmaps` is allocated in the function load_bitmap_entries_v1
> and it is not passed into any function, so it's safe to free it before
> leaving that function.
I think this is OK, though it might be easier still to just turn
When using the auto-completion included with git for tcsh, several commands do
directly completion with an additional space appended to the end, which defeats
the ability to complete to a deeper sub-directory.
For example, if I have a git repository including the following:
basedir/foo/bar/somef
On Tue, Mar 31, 2015 at 10:45:11AM +0900, Mike Hommey wrote:
> Using git branch --contains can be a very expensive thing:
> [...]
Yes, this is well known. It does a separate traversal for each branch,
which is why you noticed that it's linear in the number of branches.
I changed the "tag --conta
On Mon, Mar 30, 2015 at 9:22 PM, Stefan Beller wrote:
> shallow: fix a memleak
> Signed-off-by: Stefan Beller
> ---
> diff --git a/shallow.c b/shallow.c
> index d8bf40a..11d5c4e 100644
> --- a/shallow.c
> +++ b/shallow.c
> @@ -412,11 +412,12 @@ static void paint_down(struct paint_info *info, cons
Hi,
Sometimes I want to know what (possibly remote) branch contains a given
commit. The repository where I do that has thousands of branches:
$ git for-each-ref | wc -l
7657
And a lot of commits:
$ git rev-list --all | wc -l
538174
Using git branch --contains can be a very expensive thing:
$
From: John Keeping
stream_blob_to_fd() always frees the filter now, so there is no memory
leak in entry.c:152 just before the `goto finish`.
Signed-off-by: John Keeping
Signed-off-by: Stefan Beller
---
I added Johns signoff here tentatively, John can you confirm the sign off?
streaming.c
The `filepair` is assigned new memory with any iteration via
process_diff_filepair, so free it before the current iteration ends.
Signed-off-by: Stefan Beller
---
line-log.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/line-log.c b/line-log.c
index a490efe..b43ac58 100644
--- a/line-log.c
Signed-off-by: Stefan Beller
---
pack-bitmap.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/pack-bitmap.c b/pack-bitmap.c
index 365f9d9..62a98cc 100644
--- a/pack-bitmap.c
+++ b/pack-bitmap.c
@@ -986,6 +986,8 @@ void test_bitmap_walk(struct rev_info *revs)
fprintf(stderr,
In any code path of shorten_unambiguous_ref the return value is a
xstrdup(some string), so it is safe to free the variable `base`
in any codepath.
Signed-off-by: Stefan Beller
---
wt-status.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/wt-status.c b/wt-status.c
index 853419f..38cb165 100
I changed the patches based on Erics feedback, all of them look sane to me now.
I still retain 2 patches which I need to convince myself are reasonable to send
to the list though.
John Keeping (1):
entry.c: fix a memleak
Stefan Beller (5):
shallow: fix a memleak
line-log.c: fix a memleak
Signed-off-by: Stefan Beller
---
shallow.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/shallow.c b/shallow.c
index d8bf40a..11d5c4e 100644
--- a/shallow.c
+++ b/shallow.c
@@ -412,11 +412,12 @@ static void paint_down(struct paint_info *info, const
unsigned char *sha1,
Signed-off-by: Stefan Beller
---
line-log.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/line-log.c b/line-log.c
index b43ac58..db6e58d 100644
--- a/line-log.c
+++ b/line-log.c
@@ -1129,6 +1129,9 @@ static int process_ranges_ordinary_commit(struct rev_info
*rev, struct commit *c
On Mon, Mar 30, 2015 at 09:08:54PM -0400, Jeff King wrote:
> Commit b27cfb0 (git-cherry-pick: Add keep-redundant-commits
> option, 2012-04-20), added the --keep-redundant-commits
> option, and switched the default behavior (without that
> option) to silently ignore empty commits. Later, the second
Commit b27cfb0 (git-cherry-pick: Add keep-redundant-commits
option, 2012-04-20), added the --keep-redundant-commits
option, and switched the default behavior (without that
option) to silently ignore empty commits. Later, the second
half of that commit was reverted in ac2b0e8 (cherry-pick:
regressio
When we find an object in a packfile index, we make sure we
can still open the packfile itself (or that it is already
open), as it might have been deleted by a simultaneous
repack. If we can't access the packfile, we print a warning
for the user and tell the caller that we don't have the
object (we
On Tue, Mar 31, 2015 at 6:36 AM, Joey Hess wrote:
> Duy Nguyen wrote:
>> You can do "git --literal-pathspecs ls-files ..." or set
>> GIT_LITERAL_PATHSPECS.
>
> Thanks! --literal-pathspecs does allow getting around this.
>
> Now I'm wondering what other parts of plumbing might be doing globbing
>
On Mon, Mar 30, 2015 at 07:36:14PM -0400, Joey Hess wrote:
> Duy Nguyen wrote:
> > You can do "git --literal-pathspecs ls-files ..." or set
> > GIT_LITERAL_PATHSPECS.
>
> Thanks! --literal-pathspecs does allow getting around this.
>
> Now I'm wondering what other parts of plumbing might be doin
On Tue, Mar 31, 2015 at 08:35:52AM +0900, Mike Hommey wrote:
> On Tue, Mar 31, 2015 at 08:02:09AM +0900, Mike Hommey wrote:
> > Hi,
> >
> > I am trying to get all the children commits of a set of commits. To do
> > that, I'm using this:
> >
> > git rev-list --topo-order --ancestry-path --bounda
On Tue, Mar 31, 2015 at 08:02:09AM +0900, Mike Hommey wrote:
> Hi,
>
> I am trying to get all the children commits of a set of commits. To do
> that, I'm using this:
>
> git rev-list --topo-order --ancestry-path --boundary ^A ^B ...
>
> where A, B, and following are those commits I want the c
Duy Nguyen wrote:
> You can do "git --literal-pathspecs ls-files ..." or set
> GIT_LITERAL_PATHSPECS.
Thanks! --literal-pathspecs does allow getting around this.
Now I'm wondering what other parts of plumbing might be doing globbing
that I did not anticipate. Maybe I should set the environment v
Hi Joey,
Joey Hess wrote:
> Since I wanted to avoid this wildcard expension, I tried slash-escaping
> the wildcard characters. This works:
>
> joey@darkstar:~/tmp/aaa>git ls-files 'foo\*bar'
> foo*bar
Does 'git --noglob-pathspecs' help?
Curious,
Jonathan
--
To unsubscribe from this list: send t
On Tue, Mar 31, 2015 at 6:04 AM, Joey Hess wrote:
> I was very surprised to learn the other day that git ls-files 'foo*'
> will expand wildcards (including character classes), in the absence of
> expansion by the shell. (git version 2.1.4)
>
> joey@darkstar:~/tmp/aaa>git ls-files 'foo*bar'
> foo*b
I was very surprised to learn the other day that git ls-files 'foo*'
will expand wildcards (including character classes), in the absence of
expansion by the shell. (git version 2.1.4)
joey@darkstar:~/tmp/aaa>git ls-files 'foo*bar'
foo*bar
foobazbar
joey@darkstar:~/tmp/aaa>git ls-files '[abc]'
[abc
Hi,
I am trying to get all the children commits of a set of commits. To do
that, I'm using this:
git rev-list --topo-order --ancestry-path --boundary ^A ^B ...
where A, B, and following are those commits I want the children of. From
the gitrevisions documentation, it seems that should get me
On Mon, Mar 30, 2015 at 03:24:26PM -0700, Junio C Hamano wrote:
> Mike Hommey writes:
>
> > (Maybe --topics should always require one rev on the command
> > line?)
>
> That sounds line a good thing to do.
>
> > - else if (all_heads + all_remotes)
> > - snarf_refs(all_heads, all_remo
Junio C Hamano writes:
> ...? I am not saying the change
> is problematic; it is just I haven't looked at this code for a long
> time that the existing machinery is already designed to tolerate
> duplicated input.
"for a long time to say that the existing code is OK or not" is what
I meant to s
Mike Hommey writes:
> (Maybe --topics should always require one rev on the command
> line?)
That sounds line a good thing to do.
> - else if (all_heads + all_remotes)
> - snarf_refs(all_heads, all_remotes);
> else {
> while (0 < ac) {
>
On Tue, Mar 31, 2015 at 12:55:33AM +0900, Yi EungJun wrote:
> From: Yi EungJun
>
> Highlighted string might be broken if the common subsequence is a proper
> subset
> of a multibyte character. For example, if the old string is "진" and the new
> string is "지", then we expect the diff is rendered
"git show-branch --topics ..." displays ancestry graph, only
considering commits that are in all given revs, except the first one.
"git show-branch" displays ancestry graph for all local branches.
Unfortunately, "git show-branch --topics " only prints out the rev
info for the given rev, and noth
On Mon, Mar 30, 2015 at 01:49:34PM -0700, Jonathon Mah wrote:
> During a few years of discussing git operations with colleagues, I’ve found
> the “git rebase --onto” operation particularly ambiguous. The reason is that
> I always describe a rebase operation as “onto” something else (because of th
On Sun, Mar 29, 2015 at 08:25:33AM +0700, Duy Nguyen wrote:
> I'm not sure if "it" means $GIT_DIR/config.worktree or
> $GIT_DIR/info/config.worktree. At this point $GIT_COMMON_DIR is not
> involved (i.e. you can still spit config even in a normal repo).
> .../info/config.worktree may be shared, I g
Jonathon Mah writes:
> During a few years of discussing git operations with colleagues, I’ve
> found the “git rebase --onto” operation particularly ambiguous. The
> reason is that I always describe a rebase operation as “onto”
> something else (because of the English phrase “A is based on
> B”).
On 30.03.2015 22:23, Junio C Hamano wrote:
Ignoring a merge can be read as ignoring the changes a merge commit
introduces altogether, as if the entire side branch the merge commit
merged was removed from the history. But that is not what happens
Sounds good to me. Thanks.
--
Sebastian Schube
Jonathon Mah wrote:
> Personally, I understand “git-rebase --onto new-base old-base” as
> meaning “rebase from old-base to new-base”. Some prepositions that
> might make this clearer:
>
> $ git rebase --from old-base new-base # “Rebase HEAD onto new-base, from
> old-base"
Would having an option
During a few years of discussing git operations with colleagues, I’ve found the
“git rebase --onto” operation particularly ambiguous. The reason is that I
always describe a rebase operation as “onto” something else (because of the
English phrase “A is based on B”). For example:
$ git rebase ne
`git prune --worktrees` was pruning worktrees which were non-existent OR
expired, while it rather should prune those which are orphaned AND
expired, as git-checkout documentation describes. Fix it.
Add test 'not prune proper checkouts', which uses valid but expired
worktree.
Modify test 'not prun
Junio C Hamano writes:
>> Ignoring a merge sounds like dropping the merge commit and all side
>> branches it merges from history.
>
> ... Yes to _some_ people (including you, but not me). And that is
> why we are trying to improve the text in the documentation, no?
Let's try this again as I do
Sebastian Schuberth writes:
>> That is, at least to me,
>>
>> D---E---F
>> / \
>> ---A---B---C---G---H
>>
>> the former, i.e. "the changes the merge G introdues", is "diff C G",
>
> To me, too. In other words, this is the combined diff of all commits
> reachable from
Kenny Lee Sin Cheong writes:
> Allows the use of the "-" shorthand notation, including
> use with revision ranges. If we plan to allow "-" as a stand in every
> where a revision is allowed, then "-" would also need to be usable in
> plumbing commands, for writing tests, for example.
>
> Checks if
On Mon, Mar 30, 2015 at 7:23 PM, Junio C Hamano wrote:
>> Ignoring a merge sounds like ignoring the changes a merge commit
>> introduces altogether, as if the merge commit was skipped or dropped from
>> history. But that is not what happens if "-p" is not specified.
>
> Every time I read the abov
Alexander Duytschaever writes:
> When defining pushdefault and renaming the associated remote, the
> pushdefault setting becomes invalid. Instead, it should follow the
> renamed remote if that was designated as pushdefault.
>
> Test procedure:
>
> 1. Create/cd empty directory
> 2. `git init .`
>
From: Matthias Rüster
The use of 'symbolische Verknüpfung' for 'symbolic link' is more common
than 'symbolischer Verweis'.
Signed-off-by: Matthias Rüster
Signed-off-by: Ralf Thielow
---
po/de.po | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/po/de.po b/
Duy Nguyen writes:
> This is true. But I wonder if we should (and can) support
> --super-mirror option (disabled by default), where reflog and stashes
> are kept, for backup purposes. We might keep unreferenced objects as
> well if it's not hard to do.
I doubt that we want to be in the business
Signed-off-by: Kenny Lee Sin Cheong
---
t/t0102-previous-shorthand.sh | 40
1 file changed, 40 insertions(+)
create mode 100644 t/t0102-previous-shorthand.sh
diff --git a/t/t0102-previous-shorthand.sh b/t/t0102-previous-shorthand.sh
new file mode 100644
This is an attempt to allow '-' everywhere a revision is normally allowed.
I previously attempted this as a microproject and the subject was disscussed
at : http://article.gmane.org/gmane.comp.version-control.git/265672
Currently, something like '-~2' does not work. I tried tracing the execution
Check the argument as a revision at first. If it fails, then tries to
check it as an option, and finally as a pathspec.
Returns -1 when we have an ambiguous revision range, such as
"master..next", to allow the argument to get checked as an option before
calling die() from verify_non_filename(). Th
Allows the use of the "-" shorthand notation, including
use with revision ranges. If we plan to allow "-" as a stand in every
where a revision is allowed, then "-" would also need to be usable in
plumbing commands, for writing tests, for example.
Checks if the argument can be interpreted as a revi
Signed-off-by: Kenny Lee Sin Cheong
---
t/t1505-rev-parse-last.sh | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/t/t1505-rev-parse-last.sh b/t/t1505-rev-parse-last.sh
index 4969edb..a1976ad 100755
--- a/t/t1505-rev-parse-last.sh
+++ b/t/t1505-rev-parse-last.sh
@@
Translate 99 messages came from git.pot update in c2ea120
(l10n: git.pot: v2.4.0 round 1 (99 new, 92 removed)).
Signed-off-by: Ralf Thielow
---
po/de.po | 289 ++-
1 file changed, 101 insertions(+), 188 deletions(-)
diff --git a/po/de.
Hi,
>If I read the code correctly, this is an error message that appears
>when
>someone tries to apply a patch that modifies a file with the leading
>directory
>being a symlink.
>
Okey.
>What about skipping the "read" part (because it's an implementation
>detail)
>and translate it as
>"'%s' is
Sebastian Schuberth writes:
> So how about:
>
> [PATCH] docs: Clarify what git-rebase's "-p" / "--preserve-merges" does
>
> Ignoring a merge sounds like ignoring the changes a merge commit
> introduces altogether, as if the merge commit was skipped or dropped from
> history. But that is not what
Hi,
2015-03-29 17:48 GMT+02:00 Phillip Sz :
> Hi,
>
>> #: builtin/apply.c:3238
>> -#, fuzzy, c-format
>> +#, c-format
>> msgid "reading from '%s' beyond a symbolic link"
>> -msgstr "Pfadspezifikation '%s' ist hinter einem symbolischen Verweis"
>> +msgstr "Lese von '%s' hinter einem symbolischen
From: Yi EungJun
Highlighted string might be broken if the common subsequence is a proper subset
of a multibyte character. For example, if the old string is "진" and the new
string is "지", then we expect the diff is rendered as follows:
-진
+지
but actually it was rendered as follo
On Sat, Mar 28, 2015 at 9:31 PM, Kevin D wrote:
> Git clone is never going to get you a copy where nothing is lost.
>
> What you are losing on clone is:
>
> * config settings (this includes the configures remotes)
> * hooks
> * reflog (history of refs, though, by default disabled for bare
> repo
Lee Winder gmail.com> writes:
>
> When using git fetch --prune, git will remove any branches from
> remotes/origin/ that have inconsistent case in folder names.
> ...
> Thanks
> Lee
>
Hello,
Same type of issue here using Jenkins.
In a gitBash console:
$ git branch --list
* feature/testCI1
On Mon, Mar 30, 2015 at 06:30:33PM +0800, Paul Tan wrote:
> The ordering of the list of suffixes tested in enter_repo() is
> documented as "%s.git/.git", "%s/.git", "%s.git", "%s". This does not
> match the ordering of the list of suffixes tested in the code which is
> "%s/.git", "%s", "%s.git/.gi
Paul Tan writes:
> The ordering of the list of suffixes tested in enter_repo() is
> documented as "%s.git/.git", "%s/.git", "%s.git", "%s". This does not
> match the ordering of the list of suffixes tested in the code which is
> "%s/.git", "%s", "%s.git/.git", "%s.git". Fix this.
Indeed:
The ordering of the list of suffixes tested in enter_repo() is
documented as "%s.git/.git", "%s/.git", "%s.git", "%s". This does not
match the ordering of the list of suffixes tested in the code which is
"%s/.git", "%s", "%s.git/.git", "%s.git". Fix this.
Signed-off-by: Paul Tan
---
path.c | 4 +
On 3/26/2015 19:18, Junio C Hamano wrote:
> Although I fully agree that the new text is better than the original,
> I think the new text fails to point out one major aspect by not
> mentioning "linear" or "flatten" anywhere. The point of "git rebase"
> without "-p" is not just to replay but to fl
When defining pushdefault and renaming the associated remote, the pushdefault
setting becomes invalid. Instead, it should follow the renamed remote if that
was designated as pushdefault.
Test procedure:
1. Create/cd empty directory
2. `git init .`
3. `git remote add abc def`
4. Observe that `gi
67 matches
Mail list logo
