Hey.
I was looking for an ideally simple way to make a "full" copy of a git
repo. Many howtos are floating around on this on the web, with also lots
of voodoo.
First, it shouldn't be just a clone, i.o.w.
- I want to have all refs (local/remote branches/tags) and of course all
objects from the so
Vitor Antunes wrote:
>Junio C Hamano wrote:
>>Pete, these tests blame to your 9b6513ac (git p4 test: split up big
>>t9800 test, 2012-06-27). I presume that you tested the result of
>>this splitting, but do you happen to know if we did something to
>>cause the test to break recently?
>
>I also w
On Friday, March 27, 2015, Eric Sunshine wrote:
> On Fri, Mar 27, 2015 at 6:32 PM, Stefan Beller wrote:
> > I observe that filter is going out of scope, but the
> > implementation proposed in this patch produces just a
> > crash instead of any helpful fix.
> >
> > Signed-off-by: Stefan Beller
>
File file11 is copied from file2 and diff-tree correctly reports this file as
its the source. But it is possible that the diff-tree algorithm detects file10,
which was also copied from file2, as the origin of the new file.
This fix uses a case statement to support both files as the source of file1
Signed-off-by: Vitor Antunes
---
t/t9814-git-p4-rename.sh |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t9814-git-p4-rename.sh b/t/t9814-git-p4-rename.sh
index 95f4421..efae143 100755
--- a/t/t9814-git-p4-rename.sh
+++ b/t/t9814-git-p4-rename.sh
@@ -180,7 +180,7 @@
Updated both fixes:
1. Remove "true" from case statements and replaced it with ":".
2. Also use a case statement in the copy detection test to allow
diff-tree to detect two different files as the origin of the
copy. I've also reverted a change I introduced in the V1 patch
that no longer m
Junio C Hamano wrote:
>Vitor Antunes writes:
>
>> File file11 is copied from file2 and diff-tree correctly reports this file as
>> its the source, but the test expression was checking for file10 instead
>> (which
>> was a file that also originated from file2). It is possible that the
>> diff-t
On Fri, Mar 27, 2015 at 6:32 PM, Stefan Beller wrote:
> I observe that filter is going out of scope, but the
> implementation proposed in this patch produces just a
> crash instead of any helpful fix.
>
> Signed-off-by: Stefan Beller
> ---
> diff --git a/entry.c b/entry.c
> index 1eda8e9..538300
On Fri, Mar 27, 2015 at 6:32 PM, 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.
>
> Signed-off-by: Stefan Beller
> ---
> diff --git a/pack-bitmap.c b/pack
On Fri, Mar 27, 2015 at 6:32 PM, Stefan Beller wrote:
> 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 | 2 ++
> 1 file changed, 2 insertio
On Fri, Mar 27, 2015 at 6:32 PM, Stefan Beller wrote:
> Signed-off-by: Stefan Beller
> ---
> diff --git a/shallow.c b/shallow.c
> index d8bf40a..f8b0458 100644
> --- a/shallow.c
> +++ b/shallow.c
> @@ -416,7 +416,7 @@ static void paint_down(struct paint_info *info, const
> unsigned char *sha1,
>
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 | 2 ++
1 file changed, 2 insertions(+)
diff --git a/wt-status.c b/wt-status.c
index 853419f..9d2a349 1
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
---
shallow.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/shallow.c b/shallow.c
index d8bf40a..f8b0458 100644
--- a/shallow.c
+++ b/shallow.c
@@ -416,7 +416,7 @@ 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
`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.
Signed-off-by: Stefan Beller
---
Notes:
I wonder however if we need to free the actual bitmaps
stored in the recent_bitmaps a
Here comes another bunch of memory leaks fixed.
patches 1-4 are safe bets, but 5 and 6 are not so.
In patch 5 I wonder if we need to fix more aggressively and
in patch 6 I just know there is a leak but I have no idea how to
actually fix it.
The patches are apply-able to origin/master.
Version 2
I observe that filter is going out of scope, but the
implementation proposed in this patch produces just a
crash instead of any helpful fix.
Signed-off-by: Stefan Beller
---
entry.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/entry.c b/entry.c
index 1eda8e9..5383001 1
Vitor Antunes writes:
> File file11 is copied from file2 and diff-tree correctly reports this file as
> its the source, but the test expression was checking for file10 instead (which
> was a file that also originated from file2). It is possible that the diff-tree
> algorithm was updated in recent
On Fri, Mar 27, 2015 at 3:09 PM, Stefan Beller wrote:
> Here comes another bunch of memory leaks fixed.
> patches 1-4 are safe bets, but 5 and 6 are not so.
>
> In patch 5 I wonder if we need to fix more aggressively and
> in patch 6 I just know there is a leak but I have no idea how to
> actually
I observe that filter is going out of scope, but the
implementation proposed in this patch produces just a
crash instead of any helpful fix.
Signed-off-by: Stefan Beller
---
entry.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/entry.c b/entry.c
index 1eda8e9..5383001 1
Signed-off-by: Stefan Beller
---
shallow.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/shallow.c b/shallow.c
index d8bf40a..f8b0458 100644
--- a/shallow.c
+++ b/shallow.c
@@ -416,7 +416,7 @@ static void paint_down(struct paint_info *info, const
unsigned char *sha1,
`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.
Signed-off-by: Stefan Beller
---
Notes:
I wonder however if we need to free the actual bitmaps
stored in the recent_bitmaps a
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 | 2 ++
1 file changed, 2 insertions(+)
diff --git a/wt-status.c b/wt-status.c
index 853419f..9d2a349 1
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
`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.
Signed-off-by: Stefan Beller
---
Notes:
I wonder however if we need to free the actual bitmaps
stored in the recent_bitmaps a
Signed-off-by: Stefan Beller
---
shallow.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/shallow.c b/shallow.c
index d8bf40a..f8b0458 100644
--- a/shallow.c
+++ b/shallow.c
@@ -416,7 +416,7 @@ static void paint_down(struct paint_info *info, const
unsigned char *sha1,
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 | 2 ++
1 file changed, 2 insertions(+)
diff --git a/wt-status.c b/wt-status.c
index 853419f..9d2a349 1
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
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
Here comes another bunch of memory leaks fixed.
patches 1-4 are safe bets, but 5 and 6 are not so.
In patch 5 I wonder if we need to fix more aggressively and
in patch 6 I just know there is a leak but I have no idea how to
actually fix it.
Stefan Beller (6):
shallow: fix a memleak
line-log.c
On Mar 26, 2015, at 14:09, Junio C Hamano wrote:
* jc/show-branch (2014-03-24) 5 commits
- show-branch: use commit slab to represent bitflags of arbitrary
width
- show-branch.c: remove "all_mask"
- show-branch.c: abstract out "flags" operation
- show-branch.c: lift all_mask/all_revs to a glob
Jeff King writes:
> It is possible that we may drop an object that is depended
> upon by another object in the alternate. For example,
> imagine two repositories, A and B, with A pointing to B as
> an alternate. Now imagine a commit that is in B which
> references a tree that is only in A. Traver
On Fri, Mar 27, 2015 at 03:27:27PM +0100, Stefan Näwe wrote:
> > If i now clone the repository on my local machine, then the default branch
> > should be pointing to mainline and not master. However, the issue is that it
> > still points to master. Am I /wrong/ in assuming that changing the entry
Garbageyard writes:
> If i now clone the repository on my local machine, then the default branch
> should be pointing to mainline and not master. However, the issue is that it
> still points to master. Am I /wrong/ in assuming that changing the entry in
> file HEAD for a given repository on Git s
Junio C Hamano pobox.com> writes:
>
> Martin Pettersson siamect.com> writes:
>
> > I use Git for versioning PLC program written for Beckhoff TwinCAT v2 that
> > saves the files in binary format.
> > You can probably do the same for most other systems as well.
> >
> > My way of doing i
Martin Pettersson writes:
> I use Git for versioning PLC program written for Beckhoff TwinCAT v2 that
> saves the files in binary format.
> You can probably do the same for most other systems as well.
>
> My way of doing it is...
> I have a batch file that starts TwinCAT including a fil
Bharat Suvarna icloud.com> writes:
>
> Hi
>
> I am trying to find a way of using version control on
PLC programmers like Allen Bradley PLC. I
can't find a way
> of this.
>
> Could you please give me an idea if it will work with
Plc programs. Which are basically Ladder
logic.
>
> Sent fro
Am 27.03.2015 um 13:27 schrieb Garbageyard:
> We use Gitolite for access control and i have admin access on Git server. I
> wanted to make sure that whenever a new repository is created and is then
> cloned on any machine, the default branch should point to mainline. To do
> this, when I run the re
We use Gitolite for access control and i have admin access on Git server. I
wanted to make sure that whenever a new repository is created and is then
cloned on any machine, the default branch should point to mainline. To do
this, when I run the repository creation script, i change the content of
fi
When pruning and repacking a repository that has an
alternate object store configured, we may traverse a large
number of objects in the alternate. This serves no purpose,
and may be expensive to do. A longer explanation is below.
Commits d3038d2 and abcb865 taught prune and pack-objects
(respectiv
Kirill Marchuk <62mkv mail.ru> writes:
>
> Kirill Marchuk <62mkv mail.ru> writes:
>
> >
> > Hi everyone
> >
> > I'm totally stuck with a following problem:
> (censor cut)
> ...
> >
> > But I believe that it might be due to my total misunderstanding of something
> >
> > Anyway, I
Please find attached (for text encoding reasons) an update to the
Swedish translation for gitk.
--
\\// Peter - http://www.softwolves.pp.se/
0001-gitk-sv.po-Update-Swedish-translation-305t0f0u.patch.gz
Description: Binary data
Hi!
Please find attached (for text encoding reasons) an update to the
Swedish translation for git-gui.
--
\\// Peter - http://www.softwolves.pp.se/
0001-git-gui-sv.po-Update-Swedish-translation-547t0f0u.patch.gz
Description: [PATCH] git-gui: sv.po: Update Swedish translation (547t0f0u)
The failure case which occurs on teaching git the '-' shorthand
is when there exists no branch pointed to by '@{-1}'. In this case, if there
is a file named - in the working tree, the user can be unambiguously
assumed to be referring to it while issuing this command.
The ambiguous case occurs wh
Teaching reset the - shorthand involves checking if any file named '-' exists.
check_filename() is used to perform this check.
When the @{-1} branch does not exist then it can be safely assumed that the
user is referring to the file '-',if any. If this file exists then it is reset.
Otherwise, a ba
46 matches
Mail list logo
