Am 8/9/2013 8:33, schrieb shawn wilson:
> On Fri, Aug 9, 2013 at 2:25 AM, Johannes Sixt wrote:
>> Am 8/8/2013 23:11, schrieb Phil Hord:
>>> On Wed, Aug 7, 2013 at 5:07 PM, shawn wilson wrote:
On Wed, Aug 7, 2013 at 6:43 AM, Johannes Sixt wrote:
> Am 8/7/2013 8:24, schrieb shawn wilson:>
On Fri, Aug 9, 2013 at 2:25 AM, Johannes Sixt wrote:
> Am 8/8/2013 23:11, schrieb Phil Hord:
>> On Wed, Aug 7, 2013 at 5:07 PM, shawn wilson wrote:
>>> On Wed, Aug 7, 2013 at 6:43 AM, Johannes Sixt wrote:
Am 8/7/2013 8:24, schrieb shawn wilson:> ... create a repo for one of
> these scri
On Thu, Aug 8, 2013 at 10:38 PM, Kyle J. McKay wrote:
>> + const char usage[] = "test-urlmatch-normalization [-p | -l]
> Looks good to me except that there seems to be a missing part of the patch.
> Did you also mean to include:
>
> diff --git a/test-urlmatch-normalization.c b/test-urlmatc
Hi!
In my local clone of git.git, currently with the v1.8.4-rc2 tag
checked out and built (and installed on the system), starting up gitk
yields an empty window, with a dialog in front of it:
error
Can't parse git log output: { }
[ OK ]
Has anyone else seen this, and know what might
Am 8/8/2013 23:11, schrieb Phil Hord:
> On Wed, Aug 7, 2013 at 5:07 PM, shawn wilson wrote:
>> On Wed, Aug 7, 2013 at 6:43 AM, Johannes Sixt wrote:
>>> Am 8/7/2013 8:24, schrieb shawn wilson:> ... create a repo for one of
these scripts and I'd like to keep the commit history.
Ok, s
On Aug 8, 2013, at 21:41, Junio C Hamano wrote:
Do not feed a random string as the first parameter to die(); use "%s"
as the format string instead.
Do the same for test-urlmatch-normalization.c while saving a single
pointer variable by turning a "const char *" constant string into
"const char []
Do not feed a random string as the first parameter to die(); use "%s"
as the format string instead.
Do the same for test-urlmatch-normalization.c while saving a single
pointer variable by turning a "const char *" constant string into
"const char []".
Signed-off-by: Junio C Hamano
---
builtin/co
>> The above section primarily explains the use of diff-tree and it was
>> appropriate back when git-whatchanged was a script. The intent of
>> the whole document, not just this section, was to tickle the
>> curiousity of the users and encourage them to see how the above
>> "much more powerful" wh
Junio C Hamano wrote in message
<7v61vg9eht@alter.siamese.dyndns.org>:
> The "tutorial" was written in fairly early days of Git's history, in
> order to primarily help those who want to use the plumbing command
> to script their own Porcelain commands. As it says at the very
> beginning, the
doing
sudo chmod 644 ./.git/index
instead of 777 resulted in the same result a bit later:
$ gs
fatal: index file open failed: Permission denied
On Thu, Aug 8, 2013 at 3:37 PM, Kyle J. McKay wrote:
> On Aug 8, 2013, at 15:18, Andrew Ruder wrote:
>>
>> On Thu, Aug 08, 2013 at 11:35
On Thu, Aug 08, 2013 at 03:33:32PM -0700, Justin Collum wrote:
> On Thu, Aug 8, 2013 at 3:18 PM, Andrew Ruder wrote:
> > he is neither the user dev or the group dev
>
> I am both. There's only one user on this machine and he is me.
If you are running as 'dev', then I'm not sure how the permissio
A release candidate Git v1.8.4-rc2 is now available for testing
at the usual places.
There are only a handful of small documentation and test updates
since -rc1, except one notable change for Cygwin users. We no
longer use a custom "fast but cheating" lstat(2) emulation and
instead use the platfo
On Aug 8, 2013, at 15:18, Andrew Ruder wrote:
On Thu, Aug 08, 2013 at 11:35:35PM +0200, Stefan Beller wrote:
On 08/08/2013 10:27 PM, Justin Collum wrote:
[...]
-rwxrwxrwx 1 dev dev 17K Aug 8 13:12 index
[...]
-rw-rw-r-- 1 dev dev 17K Aug 8 13:16 index # <---
The permissi
On Thu, Aug 8, 2013 at 3:18 PM, Andrew Ruder wrote:
> he is neither the user dev or the group dev
I am both. There's only one user on this machine and he is me.
> he is regularly running chmod -R 777
Yes, true. I have a program that I use to edit some of these files
(not the git files) that li
On Thu, Aug 08, 2013 at 11:35:35PM +0200, Stefan Beller wrote:
> On 08/08/2013 10:27 PM, Justin Collum wrote:
> > [...]
> > -rwxrwxrwx 1 dev dev 17K Aug 8 13:12 index
> > [...]
> > -rw-rw-r-- 1 dev dev 17K Aug 8 13:16 index # <---
>
> The permissions are set to reading for al
On 08/08/2013 11:36 PM, Philip Oakley wrote:
> From: "Stefan Beller"
> Sent: Thursday, August 08, 2013 7:55 PM
> Subject: [PATCH] diff: remove another ternary expression always
> evaluating to true
>
> Have these issues (and the earlier expression simplifications patches
> $gmane/231916, $gmane/2
The condition in the ternary operator was wrong, hence the wrong char
pointer could be used as the parameter for show_submodule_summary.
one->path may be null, but we definitely need a non null path given
to the function.
Signed-off-by: Stefan Beller
Acked-By: Johannes Schindelin
---
diff.c | 2
Johannes Schindelin writes:
> Hi Stefan,
>
> On Thu, 8 Aug 2013, Stefan Beller wrote:
>
>> So you rather propose to have
>> -show_submodule_summary(o->file, one ? one->path : two->path,
>> +show_submodule_summary(o->file, one->path ? one->path :
>> two->path,
>
> I do. T
Stephen Haberman writes:
> Hi Johannes,
>
>> This should probably be added to config.txt and
>> Documentation/git-pull.txt, too, right?
>
> Yep, I meant to note that I'd do that after getting an initial
> confirmation that the pull.preserve-merges was the preferred approach.
If you were to go th
From: "Stephen Haberman"
Hi Johannes,
This should probably be added to config.txt and
Documentation/git-pull.txt, too, right?
Yep, I meant to note that I'd do that after getting an initial
confirmation that the pull.preserve-merges was the preferred approach.
(I was being lazy and didn't wa
"Philip Oakley" writes:
> From: "Christian Couder"
> Sent: Wednesday, August 07, 2013 5:42 AM
>> Users replacing an object with one of a different type were not
>> prevented to do so, even if it was obvious, and stated in the doc,
>> that bad things would result from doing that.
>>
>> To avoid m
Hi Stefan,
On Thu, 8 Aug 2013, Stefan Beller wrote:
> So you rather propose to have
> - show_submodule_summary(o->file, one ? one->path : two->path,
> + show_submodule_summary(o->file, one->path ? one->path :
> two->path,
I do. The reason is that one->path could be NULL
From: "Stefan Beller"
Sent: Thursday, August 08, 2013 7:55 PM
Subject: [PATCH] diff: remove another ternary expression always
evaluating to true
Have these issues (and the earlier expression simplifications patches
$gmane/231916, $gmane/231912 ) been discovered with the "STACK" tool I'd
note
Hi Johannes,
> This should probably be added to config.txt and
> Documentation/git-pull.txt, too, right?
Yep, I meant to note that I'd do that after getting an initial
confirmation that the pull.preserve-merges was the preferred approach.
(I was being lazy and didn't want to write up docs only t
On 08/08/2013 10:27 PM, Justin Collum wrote:
> I've run into a strange situation with git lately. It seems that
> anything I do involving git will alter the permissions on my index
> file to the point that I can't do anything until I re-add the
> permissions on the file.
>
> Looks like a bug to me
On 08/08/2013 11:01 PM, Johannes Schindelin wrote:
> Hi Stefan,
>
> On Thu, 8 Aug 2013, Stefan Beller wrote:
>
>> The condition before the changed line dereferences 'one' to query the mode,
>> so if the condition evaluates to true, the variable one must not be null.
>
> To show this better, plea
Hi Stephen,
On Thu, 8 Aug 2013, Stephen Haberman wrote:
> If a user is working on master, and has merged in their feature branch,
> but now has to "git pull" because master moved, with pull.rebase their
> feature branch will be flattened into master.
>
> This is because "git pull" currently does
On Wed, Aug 7, 2013 at 5:07 PM, shawn wilson wrote:
> On Wed, Aug 7, 2013 at 6:43 AM, Johannes Sixt wrote:
>> Am 8/7/2013 8:24, schrieb shawn wilson:> ... create a repo for one of
>>> these scripts and I'd like to keep the commit history.
>>>
>>> Ok, so:
>>> % find -type f ! -iname "webban.pl" |
From: "Christian Couder"
Sent: Wednesday, August 07, 2013 5:42 AM
Users replacing an object with one of a different type were not
prevented to do so, even if it was obvious, and stated in the doc,
that bad things would result from doing that.
To avoid mistakes, it is better to just forbid that
On Thu, Aug 8, 2013 at 4:04 PM, Ramkumar Ramachandra wrote:
> You will need to educate your contributors and potential contributors
> if you want these problems to be fixed.
TBH, I think Junio is exceedingly kind and generous with his time.
IME (and there's quite a few years of it :-) ), good co
Hi Stefan,
On Thu, 8 Aug 2013, Stefan Beller wrote:
> The condition before the changed line dereferences 'one' to query the mode,
> so if the condition evaluates to true, the variable one must not be null.
To show this better, please use -U10 (or some other appropriate context
option) in the fut
On Thu, Aug 8, 2013 at 3:07 AM, Luke San Antonio
wrote:
>
> Hi, my name's Luke!
>
> Today, I had a problem merging a stash after immediately creating it.
> This is exactly what I did!
>
> git stash save --keep-index
> git stash pop
>
> And BAM! Merge conflict! This was especially weird because my
I've run into a strange situation with git lately. It seems that
anything I do involving git will alter the permissions on my index
file to the point that I can't do anything until I re-add the
permissions on the file.
Looks like a bug to me, is it? It does seem like this has started
happening sin
Junio C Hamano wrote:
>> 3. After a few days of working, the gc heuristics figure out that I
>> have too much garbage and too many packs; a cleanup is required. The
>> gc --auto which doesn't tolerate fragmentation: it tries to put
>> everything into one large pack.
>
> Today's "gc --auto" skims th
Ramkumar Ramachandra writes:
> I asked you a very simple question: what happens when I do "git push"?
You asked "does push send unreachable cruft?" and I said No. Does
that answer your question?
> 3. After a few days of working, the gc heuristics figure out that I
> have too much garbage and t
Matthieu Moy writes:
> Damien Robert writes:
>
>> Matthieu Moy wrote in message :
that confuses users.
>>>
>>> ... but I do agree that the doc is really confusing. It would be much
>>> better if the doc could be reduced to:
>>>
>>> "This is a synonym for linkgit:git-log[1] --raw --some -
Damien Robert writes:
> Matthieu Moy wrote in message :
>>> that confuses users.
>>
>> ... but I do agree that the doc is really confusing. It would be much
>> better if the doc could be reduced to:
>>
>> "This is a synonym for linkgit:git-log[1] --raw --some --other ---options.
>> Please refe
Junio C Hamano wrote:
> Martin Fick writes:
>> Assuming I understand what you are suggesting, would these
>> "young object" likely still get "deduped" in an efficient
>> way without doing history traversal (it sounds like they
>> would)?
>
> Yes.
>
> The very first thing pack-object machinery does
On Thu, Aug 08, 2013 at 08:06:09PM +0200, Matthieu Moy wrote:
> --- a/Documentation/gitcore-tutorial.txt
> +++ b/Documentation/gitcore-tutorial.txt
> @@ -532,12 +532,7 @@ commit, and you can tell it to show a whole series of
> diffs.
> Alternatively, you can tell it to be "silent", and not show t
> This is because "git pull" currently does not know about rebase's
> preserve merges flag, which would this behavior, and instead replay
> on the merge commit of the feature branch onto the new master, and
> not the entire feature branch itself.
Ack, sorry, I was doing this too late last night--
The condition before the changed line dereferences 'one' to query the mode,
so if the condition evaluates to true, the variable one must not be null.
Therefore we do not need the ternary operator depending on one, giving
either one->path or two->path. This always evaluates to one->path, so
we can r
Martin Fick writes:
> Assuming I understand what you are suggesting, would these
> "young object" likely still get "deduped" in an efficient
> way without doing history traversal (it sounds like they
> would)?
Yes.
The very first thing pack-object machinery does is to get the list
of object
On Thu, Aug 08, 2013 at 07:11:04PM +0200, Jens Lehmann wrote:
> Am 07.08.2013 20:28, schrieb Fredrik Gustafsson:
> > On Tue, Aug 06, 2013 at 02:11:56PM -0700, Junio C Hamano wrote:
> >> Thanks, will replace the top two commits and queue. Looks like we
> >> are getting ready for 'next'?
> >
> > I'
Nguyễn Thái Ngọc Duy writes:
> Old operation's updates are removed as new ones are added to keep the
> size under 1 MB. ILOG keeps minimum 10 operations regardless of its
> size. These contansts should be configurable later one. ILOG content
> will be compressed later on so that it leaves minimu
The line being changed is deep inside the function builtin_diff.
The variable name_b, which is used to evaluate the ternary expression
must evaluate to true at that position, hence the replacement with
just name_b.
The name_b variable only occurs a few times in that lengthy function:
As a paramete
Nguyễn Thái Ngọc Duy writes:
> diff --git a/builtin/gc.c b/builtin/gc.c
> index 6be6c8d..99682f0 100644
> --- a/builtin/gc.c
> +++ b/builtin/gc.c
> @@ -167,11 +167,69 @@ static int need_to_gc(void)
> + ...
> + fd = hold_lock_file_for_update(&lock, git_path("gc.pid"),
> +
Damien Robert wrote:
> If I may chime in as a user
By all means. Do not feel inhibited to state your problems because you
are a "user": we are all users; we eventually became contributors
because we found certain things that needed fixing, and fixed them
little by little.
--
To unsubscribe from th
Damien Robert writes:
> Matthieu Moy wrote in message :
>>> that confuses users.
>>
>> ... but I do agree that the doc is really confusing. It would be much
>> better if the doc could be reduced to:
>>
>> "This is a synonym for linkgit:git-log[1] --raw --some --other ---options.
>> Please refe
As of 7612a1efdb (2006-06-09 git-rm: honor -n flag.) the variable
'pathspec' seems to be assumed to be never NULL after calling get_pathspec
There was a NULL pointer check after the seen = NULL assignment, which
was removed by that commit. So if pathspec would be NULL now, we'd segfault
in the line
Matthieu Moy wrote in message :
>> that confuses users.
>
> ... but I do agree that the doc is really confusing. It would be much
> better if the doc could be reduced to:
>
> "This is a synonym for linkgit:git-log[1] --raw --some --other ---options.
> Please refer to the documentation of that co
If a user is working on master, and has merged in their feature branch, but now
has to "git pull" because master moved, with pull.rebase their feature branch
will be flattened into master.
This is because "git pull" currently does not know about rebase's preserve
merges flag, which would this beha
Hey,
Following up on an old thread (2008):
http://git.661346.n2.nabble.com/pull-preserve-merges-td1471688.html
I'd like to finally add a config parameter/setting to allow git pull to preserve
merges when it's rebasing. This addresses a somewhat common boundary case of a
locally merged feature br
Thomas Rast writes:
> Ben Tebulin writes:
>
>> Am 08.08.2013 16:20, schrieb Thomas Rast - tr...@inf.ethz.ch:
>>> Can you try to reproduce with a version older than v1.8.3?
>>> E.g. v1.8.2.3.
>>> I'm asking because the above points at packed_object_info(), which I
>>> recently rewrote to be nonre
Junio C Hamano wrote:
> So I do not see how that question is "obvious". The question
> obviously pointless and misses the mark by wide margin? The
> question makes it obvious that whoever asks it does not understand
> how Git works?
Shall we all sit and mourn over the fact that I don't understan
On Thursday, August 08, 2013 10:56:38 am Junio C Hamano
wrote:
> I thought the discussion was about making the local gc
> cheaper, and the "Imagine we have a cheap way" was to
> address it by assuming that the daily "pack young
> objects into a single pack" can be sped up if we did not
> have to t
Matthieu Moy writes:
> I'd say either this, or add the missing features to "git log" to make my
> suggestion possible (after all, if some people like "git whatchanged",
> then maybe the feature would be of interest to "git log" users ?).
There is no _missing feature_ per se. whatchanged by defa
Duy Nguyen writes:
> I fail to see the point here. There are two different things: what we
> want to send, and what we can make deltas against. Shallow boundary
> affects the former. What the recipient has affects latter. What is the
> twist about?
do_rev_list() --> mark_edges_uninteresting() --
Am 07.08.2013 20:28, schrieb Fredrik Gustafsson:
> On Tue, Aug 06, 2013 at 02:11:56PM -0700, Junio C Hamano wrote:
>> Thanks, will replace the top two commits and queue. Looks like we
>> are getting ready for 'next'?
>
> I'm a bit curious about if we should move towards a reentrent libgit
> (whic
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> it is
>> not a problem for the pack that consolidates young objects into a
>> single pack to contain some unreachable crufts.
>
> So far, we have never considered putting unreachable objects in packs.
> Let me ask the obvious question first:
Ben Tebulin writes:
> c) or defect/buggy Hardware (CPU, Memory)
You may want to try a memcheck86 on your machine for a few hours, in
case ... (if your RAM is broken, you do want to know it!).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsu
I was unable to reproduce the error with the same repo and same Git
version on a different machine (Debian Squeeze x64 on a AMD Phenom x6
1045T).
> I'm running out of ideas.
Me, too. Based on out current observations I'd assume one of:
a) a rare, timing-sensitive bug in Git
b) a compiler/distrib
Matthieu Moy writes:
> What I suggest instead is to edit/track/share template configuration
> files like
>
> ~/.gitconfig.in
> email = me@HOSTNAME@
>
> and then script something like sed -e "s/@HOSTNAME@/$(hostname)/" <
> ~/.gitconfig.in > ~/.gitconfig.
>
> You may also use the include.path func
Ben Tebulin writes:
> Am 08.08.2013 16:20, schrieb Thomas Rast - tr...@inf.ethz.ch:
>> Can you try to reproduce with a version older than v1.8.3?
>> E.g. v1.8.2.3.
>> I'm asking because the above points at packed_object_info(), which I
>> recently rewrote to be nonrecursive.
>
> It seems to run '
Ramkumar Ramachandra writes:
> Matthieu Moy wrote:
>> ... but I do agree that the doc is really confusing. It would be much
>> better if the doc could be reduced to:
>>
>> "This is a synonym for linkgit:git-log[1] --raw --some --other ---options.
>> Please refer to the documentation of that comma
Morgan McClure writes:
> I propose using something reminiscent of bash syntax, either:
> value = $(SOMETEXTTOEXECUTE)
>
> or
>
> value = `SOMETEXTTOEXECUTE`
That would mean executing SOMETEXTTOEXECUTE each time the config file is
read. This raises two issues:
* A security issue, as SOMETEXTTOEX
Matthieu Moy wrote:
> ... but I do agree that the doc is really confusing. It would be much
> better if the doc could be reduced to:
>
> "This is a synonym for linkgit:git-log[1] --raw --some --other ---options.
> Please refer to the documentation of that command."
I don't think there's an exact c
I sync all my dot files (including .gitconfig) among several machines
and it's currently not possible to put conditional logic in many
fields (any that aren't considered strings to be executed as shell
commands ie aliases, editor, etc).
My specific use case is the email address. Normally I want my
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> The only thing it does is to scratch an irrelevant itch by people
>> who peek the codebase and find an old command whose existence does
>> not even hurt them. They may have too much time on their hand, but
>> that is not an excuse to waste
Am 08.08.2013 16:20, schrieb Thomas Rast - tr...@inf.ethz.ch:
> Can you try to reproduce with a version older than v1.8.3?
> E.g. v1.8.2.3.
> I'm asking because the above points at packed_object_info(), which I
> recently rewrote to be nonrecursive.
It seems to run 'much better'
v1.8.2.3 : 3/1
Changes since v2:
* The return value of function stat_tracking_info() is changed.
When the current branch and its remote tracking branch point
to the same commit, will return 1, instead of 0. Because we
want to report the tracking info for such case.
* Remove duplicated codes in builti
If the current branch has an upstream branch, and there are changes
between the current branch and its upstream, some commands (such as
"git status", "git status -bs", and "git checkout") will report their
relationship. E.g.
$ git status
# On branch master
# Your branch is ahead of 'or
gitml.jexp...@recursor.net writes:
>> Using
>>
>> addr2line -e ~/projects/git.git/git-fsck
>>
>> on these addresses may help a little, but not sure it's going to be
>> sufficient :-(.
>
>
> I'm still trying to reproduce this issue using gdb.
> Also I'm trying to reproduce this issue with my gi
> Using
>
> addr2line -e ~/projects/git.git/git-fsck
>
> on these addresses may help a little, but not sure it's going to be
> sufficient :-(.
I'm still trying to reproduce this issue using gdb.
Also I'm trying to reproduce this issue with my git repo on another machine.
ben@n179 /tmp $ addr
gitml.jexp...@recursor.net writes:
> /lib/x86_64-linux-gnu/libc.so.6(+0x7eb96)[0x7fe162d3eb96]
> [0x51e401]
> [0x51e53c]
> [0x51ecc3]
> [0x4e707b]
> [0x4e7485]
> [0x43d433]
> [0x405158]
> [0x4052ee]
> [0x4054ba]
Using
addr2line -e ~/projects/git.git/git-fsck
on these addresses may help a litt
Duy Nguyen writes:
> On Wed, Jul 17, 2013 at 3:11 PM, Thomas Gummerer wrote:
>> Duy Nguyen writes:
>>
>> [..]
>>
+static int read_entries(struct index_state *istate, struct
directory_entry **de,
+ unsigned int *entry_offset, void **mmap,
+
Am 08.08.2013 15:18, schrieb Matthieu Moy - matthieu@grenoble-inp.fr:>
gitml.jexp...@recursor.net writes:
>> So - now the puzzling thing: With valgrind it seems to work!
> Weird, indeed. What about GDB ?
Ah - come on. Is this another Heisenberg bug ?
Still trying to reproduce it using gdb a
gitml.jexp...@recursor.net writes:
> So - now the puzzling thing: With valgrind it seems to work!
> If I run it plain, it doesn't:
>
> /tmp/project.git $ valgrind --track-origins=yes ~/projects/git.git/git-fsck
[...]
> ==3431== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
> /tm
gitml.jexp...@recursor.net writes:
> So - now the puzzling thing: With valgrind it seems to work!
Weird, indeed. What about GDB ?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel
Symlink contents in p4 print sometimes have a trailing
new line character, but sometimes it doesn't. git-p4
should only remove the last character if that character
is '\n'.
Signed-off-by: Alex Juncu
Signed-off-by: Alex Badea
---
git-p4.py | 8 ++--
1 file changed, 6 insertions(+), 2 deletio
Great! Thank you all guys for your extensive instructions!
@Thomas: I only had to add libexpat1-dev to the list.
I checked out Git v1.8.3.4 as this was my used verion and built as
instructed. The error is still reproducible using the "CFLAGS = -O0 -g"
build.
So - now the puzzling thing: With val
If you have something different from both worktree and HEAD in index,
then accidentally do "git add foo", you may find it hard to recover
the previous version of foo in index. This is especially true when you
do "git add -p" with manual patch editing.
This patch makes sure that every operation tha
On 08/08/2013 02:23 PM, gitml.jexp...@recursor.net wrote:
>> Regardless of any possible fault in git-svn, there's an obvious bug here
>> with git-fsck. Can you share the pack (if the project is public) or
>> compile a git-fsck without optimization and with debugging, and run it
>> under valgrind,
gitml.jexp...@recursor.net writes:
>> Regardless of any possible fault in git-svn, there's an obvious bug here
>> with git-fsck. Can you share the pack (if the project is public) or
>> compile a git-fsck without optimization and with debugging, and run it
>> under valgrind, to hopefully get us a
gitml.jexp...@recursor.net writes:
>> Regardless of any possible fault in git-svn, there's an obvious bug here
>> with git-fsck. Can you share the pack (if the project is public) or
>> compile a git-fsck without optimization and with debugging, and run it
>> under valgrind, to hopefully get us a
> Regardless of any possible fault in git-svn, there's an obvious bug here
> with git-fsck. Can you share the pack (if the project is public) or
> compile a git-fsck without optimization and with debugging, and run it
> under valgrind, to hopefully get us a backtrace of where the memory
> manageme
On 08/08/2013 01:56 PM, gitml.jexp...@recursor.net wrote:
> I'm a heavy user of git-svn and experience an issue with one specific
> (git-svn) repository: 'git fsck' reports a corrupt packfile after every
> checkout.
>
> Now I'm totally puzzled about the cause and what do about it.
> This is what I
gitml.jexp...@recursor.net writes:
> ➜ myproject.git git:(master) git fsck
> Checking object directories: 100% (256/256), done.
> error: packed 0f5f33639bfc1a781fe080c31a1f076d9a25c1d3 from
> .git/objects/pack/pack-6a6f5355584a5d71215d5fc867ce09602ceab533.pack is
> corrupt
> *** glibc detected ***
I'm a heavy user of git-svn and experience an issue with one specific
(git-svn) repository: 'git fsck' reports a corrupt packfile after every
checkout.
Now I'm totally puzzled about the cause and what do about it.
This is what I do:
git svn init -s http://svn.foo.com/myproject myproject.git
This may happen when `git gc --auto` is run automatically, then the
user, to avoid wait time, switches to a new terminal, keeps working
and `git gc --auto` is started again because the first gc instance has
not clean up the repository.
This patch tries to avoid multiple gc running, especially in -
Junio C Hamano wrote:
> it is
> not a problem for the pack that consolidates young objects into a
> single pack to contain some unreachable crufts.
So far, we have never considered putting unreachable objects in packs.
Let me ask the obvious question first: what happens when I push? Do I
pack up a
On Thu, Aug 8, 2013 at 1:51 PM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> I think this applies to general case as well, not just shallow.
>> Imagine I have a disconnected commit that points to the latest tree
>> (i.e. it contains most of latest changes). Because it's disconnected,
>> it'll
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> Imagine we have a cheap way to enumerate the young objects without
>> the usual history traversal.
>
> Before we discuss the advantages, can you outline how we can possibly
> get this data without actually walking downwards from the roots
>
Hi, my name's Luke!
Today, I had a problem merging a stash after immediately creating it.
This is exactly what I did!
git stash save --keep-index
git stash pop
And BAM! Merge conflict! This was especially weird because my file had
this in it (taken directly from my code!)
<<< Updated upstre
93 matches
Mail list logo
