On Tue, May 21, 2013 at 3:18 PM, Chico Sokol chico.so...@gmail.com wrote:
Ok, we discovered that the commit object actually contains the tree
object's sha1, by reading its contents with python zlib library.
So the bug must be with our java code (we're building a java lib).
Is there any
Junio C Hamano venit, vidit, dixit 21.05.2013 02:15:
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The final version of 1.8.3 is expected to be tagged late this week.
While applying a
SZEDER Gábor sze...@ira.uka.de writes:
Hi,
On Tue, May 21, 2013 at 10:54:27PM +0200, Thomas Gummerer wrote:
Currently the __git_ps1 git prompt gives the following error with a
repository converted by git-svn, when used with zsh:
__git_ps1_show_upstream:19: bad pattern: svn_remote[
BTW, I love our rev-list machinery:
log --graph --abbrev-commit --pretty=oneline --decorate --cherry-mark
--left-right mjg/grep-textconv...origin/next
701cdb7 Merge branch 'mg/more-textconv' into next
|\
| = afa15f3 (gitster/mg/more-textconv) grep: honor --textconv for the
case rev:path
| =
Felipe Contreras felipe.contre...@gmail.com writes:
On Tue, May 21, 2013 at 3:54 PM, Thomas Gummerer t.gumme...@gmail.com wrote:
Currently the __git_ps1 git prompt gives the following error with a
repository converted by git-svn, when used with zsh:
__git_ps1_show_upstream:19: bad
Currently the __git_ps1 git prompt gives the following error with a
repository converted by git-svn, when used with zsh:
__git_ps1_show_upstream:19: bad pattern: svn_remote[
__git_ps1_show_upstream:45: bad substitution
To reproduce the problem, the __git_ps1_show_upstream function can be
On Tue, May 21, 2013 at 5:35 PM, Junio C Hamano gits...@pobox.com wrote:
Johan Herland jo...@herland.net writes:
On Tue, May 21, 2013 at 2:15 AM, Junio C Hamano gits...@pobox.com wrote:
* jh/shorten-refname (2013-05-07) 4 commits
- t1514: refname shortening is done after dereferencing
On Wed, May 22, 2013 at 2:40 AM, Thomas Gummerer t.gumme...@gmail.com wrote:
Currently the __git_ps1 git prompt gives the following error with a
repository converted by git-svn, when used with zsh:
__git_ps1_show_upstream:19: bad pattern: svn_remote[
__git_ps1_show_upstream:45: bad
Sorry for coming late to the party.
On 05/22/2013 03:40 AM, Jiang Xin wrote:
Original design of relative_path() is simple, just strip the prefix
(*base) from the absolute path (*abs). In most cases, we need a real
relative path, such as: ../foo, ../../bar. That's why there is another
I'm guessing Kirill meant to send this to the list and not just to me.
It looks to me like the segfault is in MSys's mkdir.exe and not a Git
process.
- Forwarded message from Kirill Berezin ene...@develop-project.ru -
From: Kirill Berezin ene...@develop-project.ru
To: John Keeping
ec9 (push: Add support for pre-push hooks, 2013-01-13) forgot to
add a note to git-push(1) about the new --no-verify option.
Signed-off-by: Thomas Rast tr...@inf.ethz.ch
---
The insertion spot is at the end, because the existing ordering is
indistinguishable from random. This should also be
As Junio pointed out in [0/2], this is not for 1.8.3; it's just a
regular enhacement.
In [1/2], I've extended the commit message with the justification I
wrote out for Junio.
In [2/2], I've made sure to print the correct error message
everytime: I missed the detached HEAD case last time. I'm
Currently, when no (valid) upstream is configured for a branch, you get
an error like:
$ git show @{u}
error: No upstream configured for branch 'upstream-error'
error: No upstream configured for branch 'upstream-error'
fatal: ambiguous argument '@{u}': unknown revision or path not in the
Currently, when we try to resolve @{N} or @{date} when the reflog
doesn't go back far enough, we get errors like:
# on branch master
$ git show @{1}
fatal: Log for '' only has 7 entries.
$ git show @{1.days.ago}
warning: Log for '' only goes back to Tue, 21 May 2013 14:14:45
commit ec9f937727bcb0fa8a3dfe6af68c188e968a added
--no-verify flag to git push, but didn't document it.
It's a useful flag when using pre-push hooks so
add the documentation.
Suggested-by: Thomas Rast tr...@inf.ethz.ch
Cc: Aaron Schrab aa...@schrab.com
Signed-off-by: Michael S. Tsirkin
On Tue, May 21, 2013 at 11:39:21PM -0400, Josef 'Jeff' Sipek wrote:
I applied this one and the guilt: skip empty line after... patch.
Thanks! BTW, it looks like you are not using git am -s to apply
these patches? The reason why I ask is that whatever you're using
isn't removing the [XXX]
To make it harder to accidentally do git push with a guilt patch
applied, guilt push changes branch from e.g. master to
guilt/master starting with commit 67d3af63f422. This is a feature
which I use for ext4 development; I actually *do* want to be able to
push patches to the dev branch, which is a
Michael S. Tsirkin m...@redhat.com writes:
commit ec9f937727bcb0fa8a3dfe6af68c188e968a added
--no-verify flag to git push, but didn't document it.
It's a useful flag when using pre-push hooks so
add the documentation.
Suggested-by: Thomas Rast tr...@inf.ethz.ch
Cc: Aaron Schrab
On Wed, May 22, 2013 at 02:12:21PM +0200, Thomas Rast wrote:
Michael S. Tsirkin m...@redhat.com writes:
commit ec9f937727bcb0fa8a3dfe6af68c188e968a added
--no-verify flag to git push, but didn't document it.
It's a useful flag when using pre-push hooks so
add the documentation.
On 05/22/13 14:11, Theodore Ts'o wrote:
To make it harder to accidentally do git push with a guilt patch
applied, guilt push changes branch from e.g. master to
guilt/master starting with commit 67d3af63f422. This is a feature
which I use for ext4 development; I actually *do* want to be able to
When the option is true (the default), Guilt does not create a new Git
branch when patches are applied. This way, you can switch between
Guilt 0.35 and the current version of Guilt with no issues.
At a future time, maybe a year after Guilt with guilt.reusebranch
support is released, the default
I naively tried to override merge.ff = false using --ff-only on the
command line. I expected that it would override the configured default
and perform a fast-forward merge. Instead, it said:
$ git config -l | grep -F 'merge.ff'
merge.ff=false
$ git merge --ff-only foo
fatal: You
Hi all,
this is a hack I made a couple of years ago in order to store my current
location in git commits (I travel a lot and being able to associate a
place with the commit date helps me to quickly recover what were doing
at that time). Long story short, the screeenshot at
On Fri, May 10, 2013 at 12:22 PM, Junio C Hamano gits...@pobox.com wrote:
I think what I missed is that the same logic to ignore side branches
whose history gets cauterised with such an ours merge may apply to
an ours merge that people already make, but the latter may want to
take both
On Wed, May 22, 2013 at 08:10:10AM -0400, Theodore Ts'o wrote:
On Tue, May 21, 2013 at 11:39:21PM -0400, Josef 'Jeff' Sipek wrote:
I applied this one and the guilt: skip empty line after... patch.
Thanks! BTW, it looks like you are not using git am -s to apply
these patches? The reason
On Fri, May 10, 2013 at 3:34 AM, William Swanson swanson...@gmail.com wrote:
I started working on something like this a few weeks ago, but
eventually came to the conclusion that this information does not
belong in the commit graph itself.
A better approach, I think, would be to enhance the
On Wed, May 22, 2013 at 03:01:36PM +0200, Per Cederqvist wrote:
When the option is true (the default), Guilt does not create a new Git
branch when patches are applied. This way, you can switch between
Guilt 0.35 and the current version of Guilt with no issues.
At a future time, maybe a year
Hi,
Le 22.05.2013 15:21, Matt McClure a écrit :
I naively tried to override merge.ff = false using --ff-only on the
command line. I expected that it would override the configured
default
and perform a fast-forward merge. Instead, it said:
$ git config -l | grep -F 'merge.ff'
2013/5/20 Holger Hellmuth hol...@gspranz.de:
Am 19.05.2013 18:56, schrieb Ralf Thielow:
2013/5/16 Holger Hellmuth (IKS) hellm...@ira.uka.de:
[...]
+reset = neu setzen (maybe umsetzen?)
zurücksetzen
reset can be used with every existing commit. zurücksetzen
would imply that it
I'm not criticizing JGit, guys. It simply doesn't fit into our needs.
We're not interested in mapping git commands in java and don't have
the same RAM limitations.
I know JGit team is doing a great job and we do not intend to build a
library with such completeness.
Are you guys contributors of
Your code is broken. IOUtils is probably corrupting what you get back.
After inflating the stream you should see the object type (commit),
space, its length in bytes as a base 10 string, and then a NUL ('\0').
Following that is the tree line, and parent(s) if any. I wonder if
IOUtils
Ramkumar Ramachandra artag...@gmail.com writes:
Why should I lie in the patch? The terminal flipping was a very big
itch I had, and the patch fixes exactly that issue. Showing the real
branch name was an unintended side-effect.
I just said early and showed a nice end-user example in which
Junio C Hamano wrote:
The patch may have been done by a wrong motivation, in that it does
not fundamentally fix the itch. The particular itch is not
something we are going to promise to the end users, ever, anyway.
Just out of curiosity, is it possible to write a correct fix at all?
Even if
I just had another idea (although I haven't had a chance to code up
anything yet). Perhaps instead of, or in addition to, a global
setting (i.e., guilt.reusebranch), perhaps we should have a per-branch
setting, such as branch.branch.guiltReuseBranch?
I was actually thinking that it might be
Solved! It was exaclty the problem pointed by Shawn.
Here is the working code:
File dotGit = new File(objects/25/0f67ef017fcb97b5371a302526872cfcadad21);
InflaterInputStream inflaterInputStream = new InflaterInputStream(new
FileInputStream(dotGit));
Integer read = inflaterInputStream.read();
2013/5/20 Christian Stimming stimm...@tuhh.de:
Thanks for the update. I would like to add some comments on this G+E glossary
and I hope you are interested in reading those, even though it is known that I
prefer a pure Ger translation. However, as I wrote in my other message I
agree that for
On Wed, May 22, 2013 at 6:32 AM, Matt McClure matthewlmccl...@gmail.com wrote:
Is there a way to push/pull reflogs among different repositories?
Not that I am aware of, at least not in core git.
In my original scenario:
1. the commits are created on a developer machine
2. pushed to a
Am 22.05.2013 17:16, schrieb Ralf Thielow:
hunk = Bereich
IMHO Kontext is better if you use a German word. Technically the context is
something else, but in a German text IMHO it fits nicer when explaining to the
user where he/she can select the n-th hunk.
Not sure if
I am trying to setup a repository for use inside the LAN, but I have
been unable to checkout any branch so far. I am very new to git.
The repository is being served from gitblit over https. I have
GIT_SSL_NO_VERIFY=true. The repository was created from git svn.
git ls-remote
shows the
Michael Haggerty mhag...@alum.mit.edu writes:
Different results for relative_path() before and after this refactor:
abs path base path relative (original) relative (refactor)
= === ===
/a/b/c/ /a/b c/
On Wed, May 22, 2013 at 10:45:31AM -0400, Theodore Ts'o wrote:
I just had another idea (although I haven't had a chance to code up
anything yet). Perhaps instead of, or in addition to, a global
setting (i.e., guilt.reusebranch), perhaps we should have a per-branch
setting, such as
Michael J Gruber g...@drmicha.warpmail.net writes:
* mg/more-textconv (2013-05-10) 7 commits
- grep: honor --textconv for the case rev:path
- grep: allow to use textconv filters
- t7008: demonstrate behavior of grep with textconv
- cat-file: do not die on --textconv without textconv
On Wednesday 2013-05-22 17:52, Holger Hellmuth (IKS) wrote:
Not sure if German users would know what hunk means, in case we
leave it untranslated. And I'm not sure if I would understand Kontext.
I tend to leave it untranslated.
I don't think Bereich is a bad choice. As hunk is not a word
Felipe Contreras felipe.contre...@gmail.com writes:
She told Git that her local svn-branch was the basis for svn-next. She
DIT NOT TELL Git to fetch from there. She told Git to fetch from any
location Git thought best to fetch from, either a) or b) would fetch
from the wrong location, but a)
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
The patch may have been done by a wrong motivation, in that it does
not fundamentally fix the itch. The particular itch is not
something we are going to promise to the end users, ever, anyway.
Just out of curiosity, is
Thomas Rast tr...@inf.ethz.ch writes:
ec9 (push: Add support for pre-push hooks, 2013-01-13) forgot to
add a note to git-push(1) about the new --no-verify option.
Does it take --verify option (that may well be the default) so that
somebody with
[alias] put = push --no-verify
can
Ramkumar Ramachandra artag...@gmail.com writes:
2. Callers calling in with programmatic data, and expecting the function
to return and not die(). In this case, why would anyone ever
construct a string containing @{u} programmatically in the first
place?
If you have to ask why, and
Matt McClure matthewlmccl...@gmail.com writes:
On Fri, May 10, 2013 at 12:22 PM, Junio C Hamano gits...@pobox.com wrote:
I think what I missed is that the same logic to ignore side branches
whose history gets cauterised with such an ours merge may apply to
an ours merge that people already
Theodore Ts'o ty...@mit.edu writes:
I was actually thinking that it might be interesting to have a
branch.branch.rewindable, which would change the guilt defaults, and
could also key changes in key git behavior which makes it less likely
that a user shoots him or herself in the foot --- i.e.,
On Wed, May 22, 2013 at 10:58:49AM -0700, Junio C Hamano wrote:
Theodore Ts'o ty...@mit.edu writes:
I was actually thinking that it might be interesting to have a
branch.branch.rewindable, which would change the guilt defaults, and
could also key changes in key git behavior which makes it
Andreas Krey a.k...@gmx.de writes:
A short trial showed that representing first parent chains as
straight lines in the graph does actually improve understandability,
as feature branches clearly stand out as separate lines even when
they no longer carry a branch name.
If you have a
Matt McClure matthewlmccl...@gmail.com writes:
I naively tried to override merge.ff = false using --ff-only on the
command line. I expected that it would override the configured default
and perform a fast-forward merge. Instead, it said:
$ git config -l | grep -F 'merge.ff'
Theodore Ts'o ty...@mit.edu writes:
On Wed, May 22, 2013 at 10:58:49AM -0700, Junio C Hamano wrote:
Theodore Ts'o ty...@mit.edu writes:
I was actually thinking that it might be interesting to have a
branch.branch.rewindable, which would change the guilt defaults, and
could also key
Felipe Contreras felipe.contre...@gmail.com writes:
diff --git a/contrib/related/git-related b/contrib/related/git-related
new file mode 100755
index 000..b96dcdd
--- /dev/null
+++ b/contrib/related/git-related
@@ -0,0 +1,124 @@
+#!/usr/bin/env ruby
+
+# This script finds people that
Junio C Hamano gits...@pobox.com writes:
Felipe Contreras felipe.contre...@gmail.com writes:
diff --git a/contrib/related/git-related b/contrib/related/git-related
new file mode 100755
index 000..b96dcdd
--- /dev/null
+++ b/contrib/related/git-related
@@ -0,0 +1,124 @@
On Wed, May 22, 2013 at 7:25 AM, Chico Sokol chico.so...@gmail.com wrote:
Your code is broken. IOUtils is probably corrupting what you get back.
After inflating the stream you should see the object type (commit),
space, its length in bytes as a base 10 string, and then a NUL ('\0').
Following
On Wed, May 22, 2013 at 7:20 AM, Chico Sokol chico.so...@gmail.com wrote:
I'm not criticizing JGit, guys. It simply doesn't fit into our needs.
We're not interested in mapping git commands in java and don't have
the same RAM limitations.
I guess you aren't trying to process the WebKit or Linux
Ok, version is: 1.8.1.msysgit.1
Segmentation fault at the git clone --recursive
http://github.com/Exsul/al_server
0 [main] mkdir 6596 open_stackdumpfile: Dumping stack trace to
mkdir.exe.stackdump
C:\Users\\libexec\git-core\git-submodule: line 181: 6596
Segmentation fault (core dumped) mkdir
I have some peculiar reasons for doing this, but nonetheless I don't
believe there's anything illegal here. I have a repo with a bunch of
remotes set up to pull in branches and tags from different places, and
I need all those branches and tags name-spaced. Eg. to illustrate, the
config looks
So instead of doing;
git fetch --all --no-tags
I'm now doing this to avoid the problem;
git remote | xargs -n 1 git fetch --no-tags
I suspect that this is 8556646 (fetch --all: pass --tags/--no-tags through to
each remote, 2012-09-05) which is in 1.7.12.2 and upwards.
--
To
On 22 May 2013 17:31, Junio C Hamano gitster-v...@pobox.com wrote:
So instead of doing;
git fetch --all --no-tags
I'm now doing this to avoid the problem;
git remote | xargs -n 1 git fetch --no-tags
I suspect that this is 8556646 (fetch --all: pass --tags/--no-tags through to
each
From: Felipe Contreras felipe.contre...@gmail.com
Sent: Wednesday, May 22, 2013 12:03 AM
On Tue, May 21, 2013 at 5:33 PM, Philip Oakley philipoak...@iee.org
wrote:
From: Felipe Contreras felipe.contre...@gmail.com
Sent: Tuesday, May 21, 2013 10:21 PM
On Tue, May 21, 2013 at 11:23 AM, Junio C
On Wed, May 22, 2013 at 11:50 AM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
She told Git that her local svn-branch was the basis for svn-next. She
DIT NOT TELL Git to fetch from there. She told Git to fetch from any
location Git thought best
On Wed, May 22, 2013 at 5:09 PM, Philip Oakley philipoak...@iee.org wrote:
From: Felipe Contreras felipe.contre...@gmail.com
Sent: Wednesday, May 22, 2013 12:03 AM
The value of the trick was acknowledged as now being in use
http://article.gmane.org/gmane.comp.version-control.git/223572
How
On Wed, May 22, 2013 at 2:23 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
diff --git a/contrib/related/git-related b/contrib/related/git-related
new file mode 100755
index 000..b96dcdd
--- /dev/null
+++ b/contrib/related/git-related
@@
On Mon, Apr 22, 2013 at 23:02:29 +0200, Torstein Hegge wrote:
There has to be a better way to get the range of possible first bad
commits, similar to the output of 'git log --bisect --format=%H'.
I just realized that this felt clunky because I didn't understand what
'--not' does in git
Felipe Contreras felipe.contre...@gmail.com writes:
Depending on the nature of the change in question, it may match well
or worse to what you are trying to find out. When you are trying to
say What were you smoking when you implemented this broken logic?,
using -C may be good, but when your
On Wed, May 22, 2013 at 5:38 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Depending on the nature of the change in question, it may match well
or worse to what you are trying to find out. When you are trying to
say What were you smoking when
Felipe Contreras felipe.contre...@gmail.com writes:
On Wed, May 22, 2013 at 5:38 PM, Junio C Hamano gits...@pobox.com wrote:
...
As I already said in the above, the answer is no, when you are
trying to find who moved the code from the original place.
But I'm not trying to find who moved the
Junio C Hamano gits...@pobox.com writes:
Felipe Contreras felipe.contre...@gmail.com writes:
On Wed, May 22, 2013 at 5:38 PM, Junio C Hamano gits...@pobox.com wrote:
...
As I already said in the above, the answer is no, when you are
trying to find who moved the code from the original place.
On Wed, May 22, 2013 at 5:53 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Wed, May 22, 2013 at 5:38 PM, Junio C Hamano gits...@pobox.com wrote:
...
As I already said in the above, the answer is no, when you are
trying to find who moved
Junio C Hamano gits...@pobox.com writes:
The person who moved the code will be on the list regardless,
That is exactly the point I have been trying to raise. Does the
person appear in the list when you run blame with -CCC? You ask for
s/person/commit/;
the body of the function, and the
Felipe Contreras felipe.contre...@gmail.com writes:
IIRC, git-gui runs two blames, one without any -C and one with (I do
not offhand recall how many -C it uses) to show both.
'git blame' is a very expensive operation, perhaps we should add
another option so users don't need to run two blames
On Wed, May 22, 2013 at 11:55:00AM -0700, Junio C Hamano wrote:
But in a triangular workflow, the way to make the result reach the
upstream is *not* by pushing there yourself. For developers at
the leaf level, it is to push to their own repository (often on
GitHub), which is different from
This doesn't make any sense:
---
cd /tmp
rm -rf blame
git init blame
cd blame
cp ~/dev/git/COPYING COPYING
git add COPYING
git commit -m initial
sed -ne 120,140p COPYING EXTRACTING
git add EXTRACTING
git commit -m second
git log --oneline
git blame -C EXTRACTING
echo COPYING
git commit
On Wed, May 22, 2013 at 10:23 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
This doesn't make any sense:
Ah, never mind, it's COPYING the one being modified, not EXTRACTING.
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
On Wed, May 22, 2013 at 7:08 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
IIRC, git-gui runs two blames, one without any -C and one with (I do
not offhand recall how many -C it uses) to show both.
'git blame' is a very expensive operation,
Hi.
I just downloaded your Windows version, and got a virus attack, and a trojan.
So sad to try a new world on the net, and then getting attacked. What to do
? Any clues ?
Sincerely
A very very very disapointed - Klavs.
Ps : both McAfee, Symantec and Kaspersky find these attacks.
Sendt
On Wed, May 22, 2013 at 11:07 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Wed, May 22, 2013 at 7:08 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
IIRC, git-gui runs two blames, one without any -C and one with (I do
not offhand
Klavs Rommedahl:
I just downloaded your Windows version, and got a virus attack, and a trojan.
So sad to try a new world on the net, and then getting attacked. What to do
? Any clues ?
Which URL did you download from, exactly?
On Thu, May 23, 2013 at 12:40 AM, Peter Krefting pe...@softwolves.pp.se wrote:
Klavs Rommedahl:
I just downloaded your Windows version, and got a virus attack, and a
trojan.
So sad to try a new world on the net, and then getting attacked. What
to do ? Any clues ?
Which URL did you
81 matches
Mail list logo
