Stefan Beller stefanbel...@googlemail.com writes:
Well if we make sure the whatchanged command can easily be reproduced
with the log command, we could add the missing parameters to it, hence
no change for the user. (git whatchanged == git log --raw --no-merges or
git log --wc [to be done
On Wed, Aug 7, 2013 at 4:00 PM, Stefan Beller
stefanbel...@googlemail.com wrote:
---
builtin/pack-objects.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 1742ea1..0bd8f3b 100644
--- a/builtin/pack-objects.c
+++
Duy Nguyen pclo...@gmail.com writes:
Haven't found time to read the rest yet, but this I can answer.
.git/shallow records graft points. If a commit is in .git/shallow and
it exists in the repository, the commit is considered to have no
parents regardless of what's recorded in repository. So
Duy Nguyen pclo...@gmail.com 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 be ignored by the server side. But if the
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 upstream
Ramkumar Ramachandra artag...@gmail.com 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
On Thu, Aug 8, 2013 at 1:51 PM, Junio C Hamano gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com 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
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 all
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
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
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 *** git:
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 do:
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
management
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
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, to
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 that
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
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 aju...@ixiacom.com
Signed-off-by: Alex Badea aba...@ixiacom.com
---
git-p4.py | 8 ++--
1
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
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)
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
Duy Nguyen pclo...@gmail.com writes:
On Wed, Jul 17, 2013 at 3:11 PM, Thomas Gummerer t.gumme...@gmail.com wrote:
Duy Nguyen pclo...@gmail.com writes:
[..]
+static int read_entries(struct index_state *istate, struct
directory_entry **de,
+ unsigned int
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 little, but
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 git repo on
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
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
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/10
Ramkumar Ramachandra artag...@gmail.com 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
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
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
Morgan McClure mcclure.mor...@gmail.com 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
Ramkumar Ramachandra artag...@gmail.com 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
Ben Tebulin tebu...@googlemail.com 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
Matthieu Moy matthieu@grenoble-inp.fr 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
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
Ramkumar Ramachandra artag...@gmail.com 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
Duy Nguyen pclo...@gmail.com 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() --
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
(which would
Matthieu Moy matthieu@grenoble-inp.fr 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.
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 traverse
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 understand how
Thomas Rast tr...@inf.ethz.ch writes:
Ben Tebulin tebu...@googlemail.com 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
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
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
Matthieu Moy wrote in message vpqfvukdy39@anie.imag.fr:
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
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
Damien Robert damien.olivier.robert+gm...@gmail.com writes:
Matthieu Moy wrote in message vpqfvukdy39@anie.imag.fr:
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
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 this
Nguyễn Thái Ngọc Duy pclo...@gmail.com 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),
+
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
Nguyễn Thái Ngọc Duy pclo...@gmail.com 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
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'm a bit
Martin Fick mf...@codeaurora.org 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
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
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
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 the
Junio C Hamano wrote:
Martin Fick mf...@codeaurora.org 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
Damien Robert damien.olivier.robert+gm...@gmail.com writes:
Matthieu Moy wrote in message vpqfvukdy39@anie.imag.fr:
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
Matthieu Moy matthieu@grenoble-inp.fr writes:
Damien Robert damien.olivier.robert+gm...@gmail.com writes:
Matthieu Moy wrote in message vpqfvukdy39@anie.imag.fr:
that confuses users.
... but I do agree that the doc is really confusing. It would be much
better if the doc could be
Ramkumar Ramachandra artag...@gmail.com 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
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 the history
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
On Thu, Aug 8, 2013 at 3:07 AM, Luke San Antonio
lukesananto...@gmail.com 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
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
From: Christian Couder chrisc...@tuxfamily.org
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
On Wed, Aug 7, 2013 at 5:07 PM, shawn wilson ag4ve...@gmail.com wrote:
On Wed, Aug 7, 2013 at 6:43 AM, Johannes Sixt j.s...@viscovery.net 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
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 not
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, please use
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, is
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 to
From: Stefan Beller stefanbel...@googlemail.com
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
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 (but not
Philip Oakley philipoak...@iee.org writes:
From: Christian Couder chrisc...@tuxfamily.org
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: Stephen Haberman step...@exigencecorp.com
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
Stephen Haberman step...@exigencecorp.com 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
Johannes Schindelin johannes.schinde...@gmx.de 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
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 all and
On Thu, Aug 8, 2013 at 3:18 PM, Andrew Ruder a...@aeruder.net 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
On Thu, Aug 08, 2013 at 03:33:32PM -0700, Justin Collum wrote:
On Thu, Aug 8, 2013 at 3:18 PM, Andrew Ruder a...@aeruder.net 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
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 mack...@gmail.com wrote:
On Aug 8, 2013, at 15:18, Andrew Ruder wrote:
On Thu, Aug 08,
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
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 whatchanged
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 [].
83 matches
Mail list logo
