On Mon, Nov 26, 2012 at 10:40:00AM +0530, Sitaram Chamarty wrote:
On Mon, Nov 26, 2012 at 4:17 AM, Eric S. Raymond e...@thyrsus.com wrote:
Krzysztof Mazur krzys...@podlesie.net:
What about embedded systems? git is also useful there. C and shell is
everywhere, python is not.
Supposing
Indeed stat seems to be broken on master by commit 74faaa16 from Linus Torvalds
There are three separated issues here:
- unmerged files are marked as interesting in stat and probably
shouldn't, with some patch like this:
data-is_interesting = p-status != 0;
if (!one || !two) {
Brandon Casey dixit:
The number of threads that pack uses can be configured in the global
or system gitconfig file by setting pack.threads.
[…]
The other setting you should probably look at is pack.windowMemory
which should help you control the amount of memory git uses while
packing. Also look
Eric S. Raymond:
and (b) include the removal of import-directories.perl in my
integration patch.
Yes, please.
--
\\// Peter - http://www.softwolves.pp.se/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info
On 11/25/2012 11:44 PM, Eric S. Raymond wrote:
Felipe Contreras felipe.contre...@gmail.com:
According to the results of the last survey, our users do care about
performance, so I don't think there's anything excessive about it. Are
there any hidden costs in maintenance problems? I don't think
On Thu, Nov 22, 2012 at 02:55:21PM -0500, Marc Khouzam wrote:
On Thu, Nov 22, 2012 at 10:41 AM, Adam Tkac at...@redhat.com wrote:
Hello all,
attached patch fixes bash completion when `egrep` is aliased to `egrep
--color=always`.
To avoid any aliases, it may be better to use
\egrep
On Mon, Nov 26, 2012 at 12:23 PM, Adam Tkac at...@redhat.com wrote:
Good idea, thanks. Improved patch is attached.
It is custom on this list to mail the patches, rather than attaching
them, so people can review your changes in-line. You can read more
about it in in
On Mon, Nov 26, 2012 at 5:09 AM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Sun, Nov 11, 2012 at 3:19 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
This is a re-roll of the previous series to add support to fetch and push
special
On Mon, Nov 26, 2012 at 5:03 AM, Junio C Hamano gits...@pobox.com wrote:
Antoine Pelisse apeli...@gmail.com writes:
fast-export can fail because of some pruned-reference when importing a
mark file.
The problem happens in the following scenario:
$ git fast-export --export-marks=MARKS
Add config pack.graphcompression similar to pack.compression.
Applies to non-blob objects and if unspecified falls back to pack.compression.
We may identify objects compressed with level 0 by their leading bytes.
Use this to force recompression when the source and target levels mismatch.
On Fri, Nov 23, 2012 at 06:58:49PM -0800, Junio C Hamano wrote:
Kacper Kornet drae...@pld-linux.org writes:
The following patch is an attempt to implement this idea.
I think revert is a wrong word (implying you have already done
something and you are trying to defeat the effect of that old
On Mon, 26 Nov 2012 04:55:10 +
Carl Smith carl.in...@gmail.com wrote:
After suggesting using zip files to move our projects around, I was
told that you can not zip a git repo without loosing all the history.
This didn't make sense to me, but two people told me the same thing,
so I wasn't
Hi,
This looks really weird and I cannot explain why it occurs.
Setup is as follows:
- origin
- mirror
- local clone
Reference repository is origin from where builds are done etc.
Parallel to that, we keep a mirror that is synced manually
(fetch/merge/push).
I do this from my local clone
On Mon, 26 Nov 2012 14:06:09 +0100, Igor Lautar igor.lau...@gmail.com wrote:
git log file modified by commit
- commit NOT shown in file history any more and file does not have this
change
does `git log --full-history file modified by commit` show the commit?
--
To unsubscribe from this list:
On Mon, Nov 26, 2012 at 12:37 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Mon, Nov 26, 2012 at 5:03 AM, Junio C Hamano gits...@pobox.com wrote:
Is this a safe and sane thing to do, and if so why? Could you
describe that in the log message here?
Why would fast-export try to
On Mon, Nov 26, 2012 at 2:23 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
The other related question being: does reading the section History
Simplification in man git-log help? ;-)
Somewhat, but it does not explain why the file no longer has that
change. I can understand omitting
Igor Lautar igor.lau...@gmail.com writes:
On Mon, Nov 26, 2012 at 2:23 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
The other related question being: does reading the section History
Simplification in man git-log help? ;-)
Somewhat, but it does not explain why the file no longer has
On Mon, Nov 26, 2012 at 2:38 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Igor Lautar igor.lau...@gmail.com writes:
Somewhat, but it does not explain why the file no longer has that
change.
It still has, but it's not shown by git log file, probably because
one of the parent of the
On Mon, Nov 26, 2012 at 2:23 PM, Antoine Pelisse apeli...@gmail.com wrote:
On Mon, Nov 26, 2012 at 12:37 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Mon, Nov 26, 2012 at 5:03 AM, Junio C Hamano gits...@pobox.com wrote:
Is this a safe and sane thing to do, and if so why? Could
If that's the case, I don't think it should throw a warning even just skip
them.
Removing the warning seems fine to me.
Then, in the actual export if some of these objects are referenced the
export would fail anyway (but they won't).
Of course it will fail to export anything that requires
On Mon, Nov 26, 2012 at 3:03 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Your initial message was about the output of git log. Do you mean that
the file, on the filesystem, does not have the line introduced by the
commit?
Yes, sorry if I was not clear enough.
If so, check the
On Mon, Nov 26, 2012 at 3:19 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
What about git annotate file merge-commit^1?
No change, line version goes back to when file was added.
Was the merge completely automatic, or were there any conflict?
No conflicts at all. In fact, that
Patrik Gornicz wrote:
Just a hunch but your remote's location uses a relative path
'../linux-2.6.git', perhaps git is messing up what the path is relative
to.
That makes sense. Git is looking at the URL and not realizing that it's
relative to the home directory.
[remote upstream]
Hi Junio,
On Sun, 25 Nov 2012, Junio C Hamano wrote:
From: Johannes Schindelin johannes.schinde...@gmx.de
Subject: Re: [PATCH v3 4/4] fast-export: make sure refs are updated properly
Date: Fri, 2 Nov 2012 16:17:14 +0100 (CET)
Message-ID:
On Mon, Nov 26, 2012 at 09:08:34AM -0800, Junio C Hamano wrote:
Krzysztof Mazur krzys...@podlesie.net writes:
In some cases the user may want to send email with Cc: line with
email address we cannot extract. Now we allow user to extract
such email address for us.
Signed-off-by:
Krzysztof Mazur krzys...@podlesie.net writes:
In some cases the user may want to send email with Cc: line with
email address we cannot extract. Now we allow user to extract
such email address for us.
Signed-off-by: Krzysztof Mazur krzys...@podlesie.net
---
git-send-email.perl | 9
Antoine Pelisse apeli...@gmail.com writes:
On Mon, Nov 26, 2012 at 12:37 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Mon, Nov 26, 2012 at 5:03 AM, Junio C Hamano gits...@pobox.com wrote:
Is this a safe and sane thing to do, and if so why? Could you
describe that in the log
Johannes Schindelin johannes.schinde...@gmx.de writes:
If you changed your stance on the patch Sverre and I sent to fix this, we
could get a non-partial fix for this.
This is long time ago so I may be misremembering the details, but I
thought the original patch was (ab)using object flags to
Kacper Kornet drae...@pld-linux.org writes:
Is there any interaction between this pull --reverse-parents
change and possible conflict resolution when the command stops and
asks the user for help? For example, whom should --ours and -X
ours refer to? Us, or the upstream?
The change of
Hi guys,
Any further interest on this scalability problem or should I move on?
Thanks,
Uri
On Thu, Nov 8, 2012 at 5:35 PM, Uri Moszkowicz u...@4refs.com wrote:
I tried on the local disk as well and it didn't help. I managed to
find a SUSE11 machine and tried it there but no luck so I think we
Antoine Pelisse apeli...@gmail.com writes:
parenthesis are not matching in `builtin_remote_sethead_usage`
as a square bracket is closing something never opened.
---
This will also break all translation files, should I also send a patch
to update them ?
git grep -A2 -e 'remote set-head name'
On Mon, Nov 26, 2012 at 3:50 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
What's possible is that someone had already merged the branch containing
new, got conflicts, and resolved it in favor of old somewhere in the
history of your master branch.
This is exactly what happened. I've
Paul Gortmaker paul.gortma...@windriver.com writes:
Currently, if you don't have curl installed, you will get
$ make distclean 21 | grep curl
/bin/sh: curl-config: not found
/bin/sh: curl-config: not found
/bin/sh: curl-config: not found
/bin/sh: curl-config: not found
Chris Rorvick ch...@rorvick.com writes:
Pass all rejection reasons back from transport_push(). The logic is
simpler and more flexible with regard to providing useful feedback.
Signed-off-by: Chris Rorvick ch...@rorvick.com
---
Thanks for a reroll.
I do not think they are masks, by the
Chris Rorvick ch...@rorvick.com writes:
Pushes must already (by default) update to a commit-ish due the fast-
forward check in set_ref_status_for_push(). But rejecting for not being
a fast-forward suggests the situation can be resolved with a merge.
Flag these updates (i.e., to a blob or a
Chris Rorvick ch...@rorvick.com writes:
diff --git a/remote.c b/remote.c
index 4a6f822..012b52f 100644
--- a/remote.c
+++ b/remote.c
@@ -1315,14 +1315,18 @@ void set_ref_status_for_push(struct ref *remote_refs,
int send_mirror,
*
* (1) if the old thing does
parenthesis are not matching in `builtin_remote_sethead_usage`
as a square bracket is closing something never opened.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
builtin/remote.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/remote.c b/builtin/remote.c
I may need to be nudged in a better direction, but please try to understand my
intentions.
I am facing a situation where I would like to use git bundle but at the same
time inspect the contents to prevent a spillage[1].
Given we have a public repository which was cloned on to a secret
Left off a citation to an old thread.
-Original Message-
From: Pyeron, Jason J CTR (US)
Sent: Monday, November 26, 2012 2:25 PM
I may need to be nudged in a better direction, but please try to
understand my intentions.
I am facing a situation where I would like to use git bundle
I am not sure I follow the above, but anyway, I think the patch does
is safe because (1) future fast-export will not refer to these
pruned objects in its output (we have decided that these pruned
objects are not used anywhere in the history so nobody will refer to
them) and (2) we still need
On 2012-10-24 20:33, Peter Oberndorfer wrote:
Hi,
i am using a textconv filter to display .doc files as plain text.
It seems git gui does not use this textconv filter for displaying new
unstaged files
(other files? = _O)
It seems diff.tcl start_show_diff calls show_other_diff because of
Pyeron, Jason J CTR (US) jason.j.pyeron@mail.mil writes:
In this situation we should assume that the bundle does not have
any content which is already in the public repository, that is it
has the minimum data to make it pass a git bundle verify from the
public repositories point of view.
On Mon, Nov 26, 2012 at 9:04 PM, Antoine Pelisse apeli...@gmail.com wrote:
I am not sure I follow the above, but anyway, I think the patch does
is safe because (1) future fast-export will not refer to these
pruned objects in its output (we have decided that these pruned
objects are not used
Antoine Pelisse apeli...@gmail.com writes:
I am not sure I follow the above, but anyway, I think the patch does
is safe because (1) future fast-export will not refer to these
pruned objects in its output (we have decided that these pruned
objects are not used anywhere in the history so nobody
-Original Message-
From: Felipe Contreras
Sent: Monday, November 26, 2012 3:20 PM
On Mon, Nov 26, 2012 at 8:24 PM, Pyeron, Jason J CTR (US)
jason.j.pyeron@mail.mil wrote:
I may need to be nudged in a better direction, but please try to
understand my intentions.
I am
-Original Message-
From: Junio C Hamano
Sent: Monday, November 26, 2012 3:38 PM
Pyeron, Jason J CTR (US) writes:
In this situation we should assume that the bundle does not have
any content which is already in the public repository, that is it
has the minimum data to make it
Peter Oberndorfer kumbay...@arcor.de writes:
Does anybody have a idea which git command would output the diff
of a untracked file against /dev/null?
The --no-index option is meant as a bolt-on to let you use various
features of git diff that is missing from other people's diff in
a context
From: W. Trevor King wk...@tremily.us
This option allows you to record a submodule.name.branch option in
.gitmodules. Git does not currently use this configuration option for
anything, but users have used it for several things, so it makes sense
to add some syntactic sugar for initializing the
From: W. Trevor King wk...@tremily.us
This allows users to checkout the current
superproject-recorded-submodule-sha as a branch, avoiding the detached
head state that the standard submodule update creates. This may be
useful for the existing --rebase/--merge workflows which already avoid
From: W. Trevor King wk...@tremily.us
---
git-submodule.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 28eb4b1..f4a681c 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -640,7 +640,7 @@ Maybe you want to use 'update
-Original Message-
From: Stephen Bash
Sent: Monday, November 26, 2012 3:56 PM
- Original Message -
From: Jason J CTR Pyeron (US)
Sent: Monday, November 26, 2012 2:24:54 PM
Subject: git bundle format
I am facing a situation where I would like to use git bundle but
Hi Junio,
On Mon, 26 Nov 2012, Junio C Hamano wrote:
Johannes Schindelin johannes.schinde...@gmx.de writes:
If you changed your stance on the patch Sverre and I sent to fix this,
we could get a non-partial fix for this.
This is long time ago so I may be misremembering the details, but
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
- Original Message -
From: Jason J CTR Pyeron (US) jason.j.pyeron@mail.mil
Sent: Monday, November 26, 2012 4:06:59 PM
Subject: RE: git bundle format [OT]
First, a shot out of left field: how about a patch based workflow?
(similar to the mailing list, just replace email with
I found an interesting bug in git-format-patch.
Say you have a branch A. You create branch B and add a patch to it. You then
merge that patch into branch A. After the merge, some other process (we will
call it 'gerrit') uses annotate and changes the comment on the patch that
exists on branch
Junio C Hamano gits...@pobox.com:
I'll reword the title (readers of git log output 6 months down the
road will not care if this is the third try or the first one) and
tweak things here and there before queuing.
Result looks good from here.
The next things on my git to-do list are
1. Audit
e...@thyrsus.com (Eric S. Raymond) writes:
@@ -0,0 +1,91 @@
+= Integrating new subcommands =
+
+This is how-to documentation for people who want to add extension
+commands to git. It should be read alongside api-builtin.txt.
+
+== Runtime environment ==
+
+git subcommands are standalone
On Mon, Nov 26, 2012 at 11:26 AM, Johannes Schindelin
johannes.schinde...@gmx.de wrote:
We added rev_cmdline_info since then so that we can tell what refs
were given from the command line in what way, and I thought that we
applied a patch from Sverre that uses it instead of the object
flags.
Brandon Casey draf...@gmail.com writes:
So, this series should result in s-o-b and (cherry picked from...) being
appended to commit messages in a more consistent and deterministic way. For
example, the decision about whether to insert a blank line before appending
a s-o-b. As discussed,
Junio C Hamano gits...@pobox.com:
Even though ={n} title ={n} is a valid AsciiDoc heading, all other
files use (older) underscored titles; please refrain from being
original.
Especially, this interferes with the way the api-index.txt file in
the same directory is autogenerated.
Noted for
Sverre Rabbelier srabbel...@gmail.com writes:
On Mon, Nov 26, 2012 at 11:26 AM, Johannes Schindelin
johannes.schinde...@gmx.de wrote:
We added rev_cmdline_info since then so that we can tell what refs
were given from the command line in what way, and I thought that we
applied a patch from
Olsen, Alan R alan.r.ol...@intel.com writes:
I found an interesting bug in git-format-patch.
Say you have a branch A. You create branch B and add a patch to
it. You then merge that patch into branch A. After the merge, some
other process (we will call it 'gerrit') uses annotate and changes
Krzysztof Mazur krzys...@podlesie.net writes:
Not having this new code inside elsif (/^e/) { } feels somewhat
sloppy, even though it is not *too* bad. Also do we know this
ok, I will fix that.
function will never be used for addresses other than recipients' (I
gave a cursory look to see
Felipe Contreras felipe.contre...@gmail.com writes:
On Tue, Nov 27, 2012 at 12:04 AM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
I'm rerolling this series with the changes fron Junio, plus a bit more
cleanups.
I dropped the last patch,
On Tue, Nov 27, 2012 at 12:43 AM, Eric S. Raymond e...@thyrsus.com wrote:
Felipe Contreras felipe.contre...@gmail.com:
Might be easier to just call 'git ls-files --with-three foo', but I
don't see the point of those calls:
Ah, much is now explained. You were looking at an old version. I had
Brandon Casey bca...@nvidia.com writes:
From: Brandon Casey draf...@gmail.com
This example in the documentation seems to be trying to describe the likely
remote tracking branch that will be updated by a push to the origin remote
with the destination branch 'satellite/master', but it forgot
The current version contains the sentence:
Further suppose that the other person already pushed changes leading to
A back to the original repository you two obtained the original commit
X.
which doesn't parse for me; I've changed it to
Further suppose that the other person already pushed
On 11/26/2012 5:30 PM, Junio C Hamano wrote:
Brandon Casey bca...@nvidia.com writes:
From: Brandon Casey draf...@gmail.com
This example in the documentation seems to be trying to describe the likely
remote tracking branch that will be updated by a push to the origin remote
with the
On Mon, Nov 26, 2012 at 12:43 PM, Junio C Hamano gits...@pobox.com wrote:
Chris Rorvick ch...@rorvick.com writes:
Pass all rejection reasons back from transport_push(). The logic is
simpler and more flexible with regard to providing useful feedback.
Signed-off-by: Chris Rorvick
On Mon, Nov 26, 2012 at 12:53 PM, Junio C Hamano gits...@pobox.com wrote:
Chris Rorvick ch...@rorvick.com writes:
Pushes must already (by default) update to a commit-ish due the fast-
forward check in set_ref_status_for_push(). But rejecting for not being
a fast-forward suggests the
tcsh users sometimes alias the 'git' command to another name. In
this case, the user expects to only have to issue a new 'complete'
command using the alias name.
However, the tcsh script currently uses the command typed by the
user to call the appropriate function in git-completion.bash, either
On Mon, Nov 26, 2012 at 12:57 PM, Junio C Hamano gits...@pobox.com wrote:
Chris Rorvick ch...@rorvick.com writes:
diff --git a/remote.c b/remote.c
index 4a6f822..012b52f 100644
--- a/remote.c
+++ b/remote.c
@@ -1315,14 +1315,18 @@ void set_ref_status_for_push(struct ref
*remote_refs, int
Junio C Hamano gits...@pobox.com wrote:
Olsen, Alan R alan.r.ol...@intel.com writes:
I found an interesting bug in git-format-patch.
Say you have a branch A. You create branch B and add a patch to
it. You then merge that patch into branch A. After the merge,
some other process (we will
On Mon, Nov 26, 2012 at 12:23 PM, Matt McClure
matthewlmccl...@gmail.com wrote:
I'm finding the behavior of `git difftool -d` surprising. It seems that it
only uses symlinks to the working copy for files that are modified in the
working copy since the most recent commit. I would have expected
On Tue, Nov 27, 2012 at 12:43 AM, Eric S. Raymond e...@thyrsus.com wrote:
---
commit 1
directory foo-1.1
Release 1.1 of project foo
.
commit 2
directory foo-1.2
..This is an example of a byte-stuffed line.
Release 1.2 of project foo
.
commit 3
Felipe Contreras felipe.contre...@gmail.com:
I believe that log file is much more human readable. Yet I still fail
to see why would anybody want so much detail only to import tarballs.
The first time I needed such a tool (and I really should have built it then)
was during the events I wrote up
[url=http://www.cheaptiffanyjewellerysale.co.uk/]tiffany uk[/url] is
certainly maintaining that will available your different singapore jewelry
generates near to the universe so that the human beings with countless many
section benefit your preferred specialist together with lesser tiffany
Felipe Contreras felipe.contre...@gmail.com:
The main objective of the logfile design is to make hand-crafting
these easy.
Here's another version with YAML:
Clever.
Now I have to decide if I should allow my aesthetic dislike of YAML to
prevail despite the fact that it's pretty well
On Mon, Nov 26, 2012 at 5:11 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
And I don't agree that the project would be better off with something
else, if it was, somebody would have proposed an alternative by now,
but there aren't any. I have tried gitg, and giggle, and I have even
79 matches
Mail list logo
