Junio C Hamano gits...@pobox.com writes:
* tr/test-v-and-v-subtest-only (2013-05-16) 6 commits
- test-lib: support running tests under valgrind in parallel
- test-lib: allow prefixing a custom string before ok N etc.
- test-lib: valgrind for only tests matching a pattern
- test-lib:
[+CC: Matthieu Moy]
Mathieu Liénard--Mayor wrote:
-Cleaner error message when git rm fails with multiple files
Should be fairly straightforward to implement. Just collect the
errors and print them out at once.
-Add configuration options for some commonly used command-line options
I'd really
From: Junio C Hamano gits...@pobox.com
Sent: Monday, May 20, 2013 11:22 PM
Philip Oakley philipoak...@iee.org writes:
So we can have a branch whose remote is '.'
_and_ a remote whose URL is '.'
Yes, and they are two separate concepts.
Thank you of the confirmation.
git fetch while on
On Mon, May 20, 2013 at 03:36:58PM -0700, Junio C Hamano wrote:
Dmitry Marakasov amd...@amdmi3.ru writes:
Use /bin/sh interpreter instead of /bin/bash for contrib/git-subtree:
it's required for systems which don't use bash by default (for example,
FreeBSD), while there seem to be no
On Tue, May 21, 2013 at 10:59:17AM +1000, Quilkey, Tony wrote:
I am looking at formulating and then documenting our vcs workflow
using Git at work. I have an idea of how I want things to work, but am
a little hazy on some of the details.
Our basic workflow will be based around:
Hi,
Seeing other patches on the list, I decided that I should do something
for 1.8.3 as well (as opposed to constantly writing new features). So
here's my contribution.
The first error message has annoyed me endlessly, and I took this
opportunity to fix it. Interested people can sprinkle in
Currently, when no (valid) upstream is configured for a branch, we 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
for the current branch doesn't go back far enough, we get errors like:
$ 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
On Friday, May 17, 2013 at 14:02 EDT,
ASHISH VERMA ashunew1...@gmail.com wrote:
Hi, i am using git to push my code from eclipse to heroku , but
recently iam getting error like::
master:master rejected:non fast forward
and i am not able to resolve it .I tried a git pull but that
On Monday, May 20, 2013 at 20:59 EDT,
Quilkey, Tony t...@thorpesystems.com wrote:
I am looking at formulating and then documenting our vcs workflow
using Git at work. I have an idea of how I want things to work, but am
a little hazy on some of the details.
Our basic workflow will be
On 2013-05-21 02:59, Quilkey, Tony wrote:
Hi,
I am looking at formulating and then documenting our vcs workflow
using Git at work. I have an idea of how I want things to work, but am
a little hazy on some of the details.
Our basic workflow will be based around:
Thomas Rast tr...@inf.ethz.ch writes:
Junio C Hamano gits...@pobox.com writes:
In addition to your topic, it may be a good idea to notice this at
the Porcelain level (e.g. checkout -b and branch, but not at the
update-ref level) and warn or even die if a Porcelain tries to
create a branch
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 symbolic refs
- shorten_unambiguous_ref(): Fix shortening
Thomas Rast tr...@inf.ethz.ch writes:
Junio C Hamano gits...@pobox.com writes:
* tr/test-v-and-v-subtest-only (2013-05-16) 6 commits
- test-lib: support running tests under valgrind in parallel
- test-lib: allow prefixing a custom string before ok N etc.
- test-lib: valgrind for only
Philip Oakley philipoak...@iee.org writes:
From: Junio C Hamano gits...@pobox.com
Sent: Monday, May 20, 2013 11:22 PM
Philip Oakley philipoak...@iee.org writes:
So we can have a branch whose remote is '.'
_and_ a remote whose URL is '.'
Yes, and they are two separate concepts.
Thank you
Ramkumar Ramachandra artag...@gmail.com writes:
Seeing other patches on the list, I decided that I should do something
for 1.8.3 as well
Fixes to something that are broken the same way between 'master' and
older release versions are the same as enhancements (which you can
view as fix to lack
Ramkumar Ramachandra artag...@gmail.com writes:
Currently, when no (valid) upstream is configured for a branch, we 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
Ramkumar Ramachandra artag...@gmail.com writes:
Currently, when we try to resolve @{N} or @{date} when the reflog
for the current branch doesn't go back far enough, we get errors like:
$ git show @{1}
fatal: Log for '' only has 7 entries.
$ git show @{1.days.ago}
warning:
Felipe Contreras felipe.contre...@gmail.com writes:
Certain remote-helpers (the ones with 'export') would try to push
regardless.
Obviously this is not what the user wants.
Also, add a check for the 'dry-run' option, so remote-helpers can
implement it.
This sounds like a good thing to do.
Will apply for 1.8.3.
--
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
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
This series introduces:
- %(current), which either shows * if the ref is pointed by HEAD
or a space. Junio called it %(headness). I don't like that.
I don't like %(current) either but we have to start somewhere.
Name suggestion?
Michael Haggerty mhag...@alum.mit.edu writes:
Change cmd_diff() to use a (struct object_array) for holding the trees
that it accumulates, rather than rolling its own equivalent.
A significant detail missing here is that this lifts the hardcoded
100 tree limit in combined diff but that does
Michael Haggerty mhag...@alum.mit.edu writes:
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
revision.c | 20 ++--
revision.h | 32 +---
2 files changed, 35 insertions(+), 17 deletions(-)
Looks obviously good for *.c file, but I am on
Michael Haggerty mhag...@alum.mit.edu writes:
The condition under which gc_boundary() is called was previously
if (alloc = nr)
. But by construction, nr can never exceed alloc, so the check looks
unnecessarily mysterious. In fact, the purpose of the check is to try
to avoid a
Michael Haggerty mhag...@alum.mit.edu writes:
There is no logical reason for this test to be here. At the caller we
might be able to figure out its meaning.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
I do not think this change is justified, *unless* the caller later
in the
Junio C Hamano wrote:
Fixes to something that are broken the same way between 'master' and
older release versions are the same as enhancements (which you can
view as fix to lack of feature). They are not regression fixes
and not for 1.8.3 at this point in the cycle, deep into -rc.
If we view
On 21/05/2013 19:52, Junio C Hamano wrote:
Ramkumar Ramachandra artag...@gmail.com writes:
The empty string '' looks ugly and inconsistent with the output of
branch@{N}. Replace it with the string 'current branch'.
Wouldn't that be '*the* current branch'?
More importantly, doesn't real_ref
Junio C Hamano wrote:
Does a failure in interpret-branch-name that issue these error
messages always followed by die() in the caller? I know you looked
at the cases you noticed as an end-user (like the above git show @{u}
example), but if some codepaths did this:
if
Ramkumar Ramachandra artag...@gmail.com writes:
So, is it
because that version was too long ago that we don't consider it a
regression (do we backport fixes)?
The regression fixes pre-release -rc period is for is to make sure
to avoid unwanted/unintended behaviour changes between releases.
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
Does a failure in interpret-branch-name that issue these error
messages always followed by die() in the caller? I know you looked
at the cases you noticed as an end-user (like the above git show @{u}
example), but if some
Junio C Hamano wrote:
So did you or did you not audit the codepath?
No; I was explaining why I didn't in the first place. Going through it now.
--
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
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
So did you or did you not audit the codepath?
No; I was explaining why I didn't in the first place. Going through it now.
I did not mean You must do so or we should discard the patch. I
just wanted to make sure the log
Junio C Hamano wrote:
More importantly, doesn't real_ref have the name of the branch?
Suppose the user said git show @{1} instead of git show
master@{1} while on 'master'.
My stupidity, sorry.
It could be argued that it may look nicer to say your current
branch does not have enough
Junio C Hamano wrote:
People have _already_ seen and lived with these issues in released
versions. Changing it may or may not be getting it back to the
state to that of an even older release, but at that point the
differences do not matter. It is a fix, too late for the kind of
regression
There's still a lot to think about.
[3/3] is the big itch: [1/2] and [2/2] are just setup patches.
Ramkumar Ramachandra (3):
push: factor out the detached HEAD error message
push: fail early with detached HEAD and current
push: don't push the volatile HEAD with current
builtin/push.c |
With push.default set to upstream or simple, and a detached HEAD, git
push prints the following error:
$ git push
fatal: You are not currently on a branch.
To push the history leading to the current (detached HEAD)
state now, use
git push ram HEAD:name-of-remote-branch
This error is
Setting push.default to current adds the refspec HEAD for the
transport layer to handle. If HEAD doesn't resolve to a branch (and
since no refspec rhs is specified), the push fails after some time with
a cryptic error message:
$ git push
error: unable to push to unqualified destination: HEAD
Since a push does not lock the HEAD ref, there is no guarantee that it
will remain the same for the entire operation of the push. Practically,
this means that with push.default set to current:
# on branch push-current-head
$ git push
# on another terminal
$ git checkout master
# return
Johan Herland jo...@herland.net writes:
On Mon, May 20, 2013 at 6:37 PM, Junio C Hamano gits...@pobox.com wrote:
...
That backing out can be made more intelligently than just dying
with compare and swap failed--please retry message, e.g. you at
that point notice what you started with, what
Ramkumar Ramachandra artag...@gmail.com writes:
There's still a lot to think about.
Is there? I do not think volatile is particularly a good
description for this, but showing what is pushed as a concrete
branch name feels like a good improvement to me, at least in
principle.
I haven't picked
On 2013-05-21 00.52, Junio C Hamano wrote:
Thanks, will replace da/darwin with this round.
(May be late response, not sure if this is the right email thread.
I eventually managed to compile under 10.6, what we have on pu)
One minor nit, or 2:
imap-send.c: In function ‘cram’:
imap-send.c:913:
Ramkumar Ramachandra wrote:
Junio C Hamano wrote:
So did you or did you not audit the codepath?
No; I was explaining why I didn't in the first place. Going through it now.
So, this is what I have:
interpret_branch_name - interpret_branch_name (recursion)
-
Torsten Bögershausen wrote:
One minor nit, or 2:
imap-send.c: In function ‘cram’:
imap-send.c:913: warning: statement with no effect
This fixes it:
diff --git a/imap-send.c b/imap-send.c
index 8ea180f..11577c9 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -35,7 +35,7 @@ typedef void
Junio C Hamano wrote:
Is there? I do not think volatile is particularly a good
description for this, but showing what is pushed as a concrete
branch name feels like a good improvement to me, at least in
principle.
Okay. I used volatile, because push does not lock HEAD when the
operation
Ramkumar Ramachandra artag...@gmail.com writes:
Ramkumar Ramachandra wrote:
Junio C Hamano wrote:
So did you or did you not audit the codepath?
No; I was explaining why I didn't in the first place. Going through it now.
So, this is what I have:
interpret_branch_name -
Junio C Hamano wrote:
interpret_branch_name - interpret_branch_name (recursion)
- get_sha1_basic - get_sha1 [context] (end-user data)
- substitute_branch_name - dwim (end-user data)
- strbuf_branchname (callers pass a branch name;
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
Is there? I do not think volatile is particularly a good
description for this, but showing what is pushed as a concrete
branch name feels like a good improvement to me, at least in
principle.
Okay. I used volatile,
Ramkumar Ramachandra artag...@gmail.com writes:
@{u}. What am I missing?
You draw the arrow the other way around, that is what made the text
confusing.
--
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
On Tue, May 21, 2013 at 11:32 AM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
I won't
bother rationalizing if this makes sense for 'master'
As this is a change to an old code/behaviour that was with us with
many released versions, it hardly is
On Tue, May 21, 2013 at 11:55 AM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Certain remote-helpers (the ones with 'export') would try to push
regardless.
Obviously this is not what the user wants.
Also, add a check for the 'dry-run' option,
Hello,
I'm building a library to manipulate git repositories (interacting
directly with the filesystem).
Currently, we're trying to parse commit objects. After decompressing
the contents of a commit object file we got the following output:
commit 191
author Francisco Sokol chico.so...@gmail.com
On Tue, May 21, 2013 at 4:21 PM, Chico Sokol chico.so...@gmail.com wrote:
Hello,
I'm building a library to manipulate git repositories (interacting
directly with the filesystem).
Currently, we're trying to parse commit objects. After decompressing
the contents of a commit object file we got
On Tue, May 21, 2013 at 5:21 PM, Chico Sokol chico.so...@gmail.com wrote:
Hello,
I'm building a library to manipulate git repositories (interacting
directly with the filesystem).
Currently, we're trying to parse commit objects. After decompressing
the contents of a commit object file we got
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 non-standard issue in git's zlib compression? We're
decompressing its contents with
Chico Sokol chico.so...@gmail.com writes:
Hello,
I'm building a library to manipulate git repositories (interacting
directly with the filesystem).
Currently, we're trying to parse commit objects. After decompressing
the contents of a commit object file we got the following output:
Who
Chico Sokol chico.so...@gmail.com writes:
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).
Why aren't you using jgit?
--
To unsubscribe from
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 Hamano gits...@pobox.com
wrote:
Philip Oakley philipoak...@iee.org writes:
On Sat, May 4, 2013 at 2:51 PM, Jonathan Nieder jrnie...@gmail.com
wrote:
Another trick
It was git who created that object.
We're trying to build a improved java library focused in our needs
(jgit has a really confusing api focused in solving egit needs). But
we're about to get into their code to discover how to decompress git
objects.
--
Chico Sokol
On Tue, May 21, 2013 at 7:22
On Tue, May 21, 2013 at 12:19 PM, Torsten Bögershausen tbo...@web.de wrote:
On 2013-05-21 00.52, Junio C Hamano wrote:
Thanks, will replace da/darwin with this round.
(May be late response, not sure if this is the right email thread.
I eventually managed to compile under 10.6, what we have on
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[
This was introduced by 6d158cba
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 Hamano gits...@pobox.com
wrote:
Philip Oakley philipoak...@iee.org writes:
On Sat,
On Tue, May 21, 2013 at 5:41 PM, SZEDER Gábor sze...@ira.uka.de wrote:
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:
Felipe Contreras felipe.contre...@gmail.com writes:
I still haven't received a response: which makes more sense?
a)
% git checkout svn-ext
% git fetch
From .
* branchmaster - FETCH_HEAD
# oops
% git fetch git-svn
% git log
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.
I have kept many late topics outside 'next' during the -rc period
Chico Sokol wrote:
We're trying to build a improved java library focused in our needs
(jgit has a really confusing api focused in solving egit needs).
JGit is also open to contributions, including contributions that
add less confusing API calls. :) See
On Tue, May 21, 2013 at 06:04:35PM -0500, Felipe Contreras wrote:
On Tue, May 21, 2013 at 5:41 PM, SZEDER Gábor sze...@ira.uka.de wrote:
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
On Tue, May 21, 2013 at 07:03:09PM -0500, Felipe Contreras wrote:
On Tue, May 21, 2013 at 6:36 PM, SZEDER Gábor sze...@ira.uka.de wrote:
On Tue, May 21, 2013 at 06:04:35PM -0500, Felipe Contreras wrote:
On Tue, May 21, 2013 at 5:41 PM, SZEDER Gábor sze...@ira.uka.de wrote:
On Tue, May
Felipe Contreras felipe.contre...@gmail.com writes:
On Tue, May 21, 2013 at 11:55 AM, Junio C Hamano gits...@pobox.com wrote:
This sounds like a good thing to do. Perhaps the refspec mapping
can be handled the same way as a backend feature so that you do not
have to unconditionally disable
Felipe Contreras felipe.contre...@gmail.com writes:
On Tue, May 21, 2013 at 6:24 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
I still haven't received a response: which makes more sense?
a)
% git checkout svn-ext
% git fetch
Add subcommand relative_path in test-path-utils, and add test cases
in t0060.
Signed-off-by: Jiang Xin worldhello@gmail.com
---
t/t0060-path-utils.sh | 26 ++
test-path-utils.c | 25 +
2 files changed, 51 insertions(+)
diff --git
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
reimplementation (path_relative()) in quote.c.
Refactor relative_path() in path.c to
Since there is an enhanced version of relative_path() in path.c,
remove duplicate counterpart path_relative() in quote.c.
Signed-off-by: Jiang Xin worldhello@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
quote.c | 55 ++-
1
After substitute path_relative() in quote.c with relative_path() from
path.c, parameters (such as len and prefix_len) are obsolete in function
quote_path_relative(). Remove unused parameters and change the order of
parameters for quote_path_relative() function.
Signed-off-by: Jiang Xin
Show what would be done and the user must confirm before actually
cleaning.
Would remove ...
Would remove ...
Would remove ...
Remove [y/n]?
Press y to start cleaning, and press n if you want to abort.
Signed-off-by: Jiang Xin worldhello@gmail.com
Signed-off-by: Junio C
Before introducing interactive git-clean, refactor git-clean operations
into two phases:
* hold cleaning items in del_list,
* and remove them in a separate loop at the end.
We will introduce interactive git-clean between the two phases. The
interactive git-clean will show what would be done
When there are lots of items to be cleaned, it is hard to see them all
in one screen. Show them in columns will solve this problem.
Signed-off-by: Jiang Xin worldhello@gmail.com
Comments-by: Matthieu Moy matthieu@imag.fr
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Show header, help, error messages, and prompt in colors for interactive
git-clean. Re-use config variables, such as color.interactive and
color.interactive.slot for command `git-add--interactive`.
Signed-off-by: Jiang Xin worldhello@gmail.com
Comments-by: Matthieu Moy matthieu@imag.fr
Rewrite menu using a new method `list_and_choose`, which is borrowed
from `git-add--interactive.perl`. We will use this framework to add
new actions for interactive git-clean later.
Please NOTE:
* Method `list_and_choose` return an array of integers, and
* it is up to you to free the allocated
Add a new action for interactive git-clean: filter by pattern. When the
user chooses this action, user can input space-separated patterns (the
same syntax as gitignore), and each clean candidate that matches with
one of the patterns will be excluded from cleaning. When the user feels
it's OK,
Draw a multiple choice menu using `list_and_choose` to select items
to be deleted by numbers.
User can input:
* 1,5-7 : select 1,5,6,7 items to be deleted
* * : select all items to be deleted
* -*: unselect all, nothing will be deleted
*: (empty) finish selecting, and
Add new section Interactive mode for documentation of interactive
git-clean.
Signed-off-by: Jiang Xin worldhello@gmail.com
Helped-by: Eric Sunshine sunsh...@sunshineco.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/git-clean.txt | 65
Add a new action for interactive git-clean: ask each. It's just like
the rm -i command, that the user must confirm one by one for each
file or directory to be cleaned.
Signed-off-by: Jiang Xin worldhello@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/clean.c | 36
Add test cases for git-clean--interactive.
Signed-off-by: Jiang Xin worldhello@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
t/t7301-clean-interactive.sh | 439 +++
1 file changed, 439 insertions(+)
create mode 100755
After substitute path_relative() in quote.c with relative_path() from
path.c, parameters (such as len and prefix_len) are obsolete in function
write_name_quoted_relative(). Remove unused parameters from
write_name_quoted_relative() and related functions.
Signed-off-by: Jiang Xin
Commit 2cc8d353d7ecb broke manually written patch descriptions of the
form:
Frobnozzle: this is a patch subject
From: Fred McNurk f...@mcnurt.foo
This is the patch description
Commit 8f88f953580a0 partially fixed things by filtering out the From:
field, but it did not
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
On Tue, May 21, 2013 at 7:50 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Tue, May 21, 2013 at 6:24 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
I still haven't received a response: which
On Tue, May 21, 2013 at 7:47 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Tue, May 21, 2013 at 11:55 AM, Junio C Hamano gits...@pobox.com wrote:
This sounds like a good thing to do. Perhaps the refspec mapping
can be handled the same way
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 pattern: svn_remote[
This was introduced by
If the date field has a space in it, such as:
Date: Tue, 14 May 2013 18:37:15 +0200
previously guilt would go belly up:
+ export GIT_AUTHOR_DATE=Tue, 14 May 2013 18:37:15 +0200
/usr/local/bin/guilt: 571: export: 14: bad variable name
Fix this.
Signed-off-by: Theodore Ts'o
On Tue, May 21, 2013 at 10:55:57PM -0400, 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
I applied this one and the guilt: skip empty line after... patch.
Jeff.
On Tue, May 21, 2013 at 11:13:31PM -0400, Theodore Ts'o wrote:
If the date field has a space in it, such as:
Date: Tue, 14 May 2013 18:37:15 +0200
previously guilt would go belly up:
+ export
On Tue, 21 May 2013 19:18:35 +, Chico Sokol 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).
That's interesting. We ran in a
On Tue, May 21, 2013 at 3:33 PM, Chico Sokol chico.so...@gmail.com wrote:
It was git who created that object.
We're trying to build a improved java library focused in our needs
(jgit has a really confusing api focused in solving egit needs).
JGit code... is confusing because its fast. We
On Tue, May 21, 2013 at 9:51 PM, Andreas Krey a.k...@gmx.de wrote:
On Tue, 21 May 2013 19:18:35 +, Chico Sokol 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
95 matches
Mail list logo
