They have been marked as UNINTERESTING for a reason, lets respect that.
Currently the first ref is handled properly, but not the rest, so:
% git fast-export master ^master
Would currently throw a reset for master (2nd ref), which is not what we
want.
% git fast-export master ^foo ^bar ^roo
%
When an object has already been exported (and thus is in the marks) it's
flagged as SHOWN, so it will not be exported again, even if in a later
time it's exported through a different ref.
We don't need the object to be exported again, but we want the ref
updated, which doesn't happen.
Since we ca
First the expected, then the actual, otherwise the diff would be the
opposite of what we want.
Signed-off-by: Felipe Contreras
---
t/t9350-fast-export.sh | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/t/t9350-fast-export.sh b/t/t9350-fast-export.sh
index 0c8d828..b7d30
Setting 'commit' to 'commit' is a no-op. It might have been there to
avoid a compiler warning, but if so, it was the compiler to blame, and
it's certainly not there any more.
Signed-off-by: Felipe Contreras
---
builtin/fast-export.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --g
People seeking for reference would find it useful.
Signed-off-by: Felipe Contreras
---
git-remote-testgit | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/git-remote-testgit b/git-remote-testgit
index 4e8b356..1116587 100755
--- a/git-remote-testgit
+++ b/git-remote-testgit
Doesn't make a difference for the tests, but it does for the ones
seeking reference.
Signed-off-by: Felipe Contreras
---
git-remote-testgit | 11 +++
1 file changed, 11 insertions(+)
diff --git a/git-remote-testgit b/git-remote-testgit
index 6c348b0..4e8b356 100755
--- a/git-remote-test
Unfortunately they do not work.
Signed-off-by: Felipe Contreras
---
git-remote-testgit| 18 +
t/t5801-remote-helpers.sh | 49 +++
2 files changed, 63 insertions(+), 4 deletions(-)
mode change 100755 => 100644 t/t5801-remote-hel
We don't need a bare 'server' and an intermediary 'public'. The repos
can talk to each other directly; that's what we want to exercise.
Signed-off-by: Felipe Contreras
---
t/t5801-remote-helpers.sh | 67 +++
1 file changed, 33 insertions(+), 34 deletio
Only makes sense for remote-testpy.
Signed-off-by: Felipe Contreras
---
t/t5801-remote-helpers.sh | 13 -
1 file changed, 13 deletions(-)
diff --git a/t/t5801-remote-helpers.sh b/t/t5801-remote-helpers.sh
index 2eca42e..a03d087 100755
--- a/t/t5801-remote-helpers.sh
+++ b/t/t5801-re
This only makes sense for the python remote helpers framework.
Signed-off-by: Felipe Contreras
---
git-remote-testgit| 3 ---
t/t5801-remote-helpers.sh | 46 +-
2 files changed, 17 insertions(+), 32 deletions(-)
diff --git a/git-remote-testgi
It's way simpler. It exerceises the same features of remote helpers.
It's easy to read and understand. It doesn't depend on python.
It does _not_ exercise the python remote helper framework; there's
another tool and another test for that.
For now let's just copy the old remote-helpers test script
This script is not really exercising the remote-helper functionality,
but more the python framework for remote helpers that live in
git_remote_helpers.
It's also not a good example of how to write remote-helpers, unless you
are planning to use python, and even then you might not want to use this
f
Basically this is what we want:
== pull ==
testgit transport-helper
* export -> import
# testgit.marks git.marks
== push ==
testgit transport-helper
* import<- export
# te
We want to be able to import, and then export, using the same marks, so
that we don't push things that the other side already received.
Unfortunately, fast-export doesn't store blobs in the marks, but
fast-import does. This creates a mismatch when fast export is reusing a
mark that were previously
Hi,
I found more issues in fast-export. remote-testgit, and eventually I decided
there's no reason to use this python script, so I wrote a much simpler version
that does the same, and more. I'm not going to list all the reasons because
apparently opinions are not welcome in the list any more. For
Hey all.
Using git-merge --log to merge commit messages that spawn multiple lines
will produce overlong summary lines.
That's because each summary line for a commit includes the entire commit
message (all lines concatenated).
According to git-fmt-merge-msg(1), --log should 'populate the log
messa
On Thu, Nov 1, 2012 at 1:40 PM, Ramsay Jones wrote:
> Jeff King wrote:
>> What's cooking in git.git (Oct 2012, #09; Mon, 29)
>> --
>>
>
> [snip]
>
>> * cr/cvsimport-local-zone (2012-10-16) 1 commit
>> - git-cvsimport: allow author-specific timezones
Kevin wrote:
> As I see it, the problem is not the possibility to add new lines, but
> colleagues being too lazy to add them.
I suspect the underlying problem is that we make it too hard to tell
git which text editor to run.
Ram, what platform do your colleagues use?
Thanks,
Jonathan
--
To unsu
Right now, there are events which can cause git fetch to hang forever.
This is really problematic in automatic use.
A git fetch --timeout which would exit with a nonzero exit code if no
forward progress is made would be really helpful.
-hpa
--
To unsubscribe from this list: send the line
As I see it, the problem is not the possibility to add new lines, but
colleagues being too lazy to add them.
On Thu, Nov 1, 2012 at 5:29 PM, Lars Gullik Bjønnes wrote:
> Ramkumar Ramachandra writes:
>
> | Hi,
>>
> | Some of my colleagues are lazy to fire up an editor and write proper
> | commit
Ramkumar Ramachandra writes:
| Hi,
>
| Some of my colleagues are lazy to fire up an editor and write proper
| commit messages- they often write one-liners using `git commit -m`.
| However, that line turns out to be longer than 72 characters, and the
| resulting `git log` output is ugly. So, I wa
Am 01.11.2012 11:43, schrieb Ramkumar Ramachandra:
> Hi,
>
> v1 is here:
> http://mid.gmane.org/1349196670-2844-1-git-send-email-artag...@gmail.com
>
> I've fixed the issues pointed out in the review by Jens.
Thanks, looking good to me.
--
To unsubscribe from this list: send the line "unsubscrib
On Thu, Nov 1, 2012 at 2:12 PM, Thomas Adam wrote:
> Hi,
>
> On 1 November 2012 16:07, Ramkumar Ramachandra wrote:
>>
>> Hi,
>>
>> Some of my colleagues are lazy to fire up an editor and write proper
>> commit messages- they often write one-liners using `git commit -m`.
>> However, that line turn
Junio C Hamano wrote:
> We've been hoping we can do without a rigid code of conduct written
> down to maintain cordial community focused on technical merits, and
> instead relied on people's common sense, but sense may not be so
> common, unfortunately, so we may have to have one.
I think that ex
When we use git on a network filesystem, occasionally and sporadically
we will see the following from a git checkout command:
error: git checkout-index: unable to create file foo (File exists)
Through a very basic grepping and following of the source it seems that
the core of the error message is
Jeff King wrote:
> Thinking on it more, my patch, hacky thought it seems, may not be the
> worst solution. Here are the options that I see:
>
> 1. Use a regex library that does not require NUL termination. If we
> are bound by the regular regexec interface, this is not feasible.
> But
Jeff King wrote:
> What's cooking in git.git (Oct 2012, #09; Mon, 29)
> --
>
[snip]
> * cr/cvsimport-local-zone (2012-10-16) 1 commit
> - git-cvsimport: allow author-specific timezones
>
> Allows "cvsimport" to read per-author timezone from the
Hi,
On 1 November 2012 16:07, Ramkumar Ramachandra wrote:
>
> Hi,
>
> Some of my colleagues are lazy to fire up an editor and write proper
> commit messages- they often write one-liners using `git commit -m`.
> However, that line turns out to be longer than 72 characters, and the
> resulting `git
On Thu, Nov 1, 2012 at 3:47 PM, Martin Langhoff
wrote:
> Felipe,
>
> I'll invite you to reread some of your words:
>
>> That being said, I did wonder what must be going through his mind to
>> not see that as obvious,
> (...)
>
>> Following the guideline of always assuming good faith
>
> So perhaps
Hi Peff,
thanks for this information.
I will report the issue to scm-manager. In the meantime I will try to
use ssh protocol to connect to my remote server.
Thanks again,
Kevin
2012/11/1 Jeff King :
> On Wed, Oct 31, 2012 at 03:34:22PM +0100, kevin molcard wrote:
>
>> I forgot to mention that I a
Felipe,
I'll invite you to reread some of your words:
> That being said, I did wonder what must be going through his mind to
> not see that as obvious,
(...)
> Following the guideline of always assuming good faith
So perhaps it does apply that you could try to assume good
intellectual faith in
On Thu, Nov 1, 2012 at 2:46 PM, René Scharfe
wrote:
> Am 01.11.2012 03:58, schrieb Felipe Contreras:
>
>> On Thu, Nov 1, 2012 at 2:32 AM, Junio C Hamano wrote:
>>>
>>> Johannes Schindelin wrote:
>>>
On Wed, 31 Oct 2012, Felipe Contreras wrote:
> It doesn't get any more obvious than
On Thu, Nov 1, 2012 at 9:46 AM, René Scharfe
wrote:
> You probably didn't intend it, but your sentences at the top can be read
> more like: "This is a logical consequence. If you don't understand that,
> your mental capabilities must be lacking.". That's obviously (ha!) a rude
> thing to say.
+
On Thu, Nov 1, 2012 at 1:46 PM, René Scharfe
wrote:
> Also, and I'm sure you didn't know that, "Jedem das Seine" (to each his own)
> was the slogan of the Buchenwald concentration camp. For that reason some
> (including me) hear the unspoken cynical half-sentence "and some people just
> have to b
Am 01.11.2012 03:58, schrieb Felipe Contreras:
On Thu, Nov 1, 2012 at 2:32 AM, Junio C Hamano wrote:
Johannes Schindelin wrote:
On Wed, 31 Oct 2012, Felipe Contreras wrote:
It doesn't get any more obvious than that. But to each his own.
In my opinion, Jonathan does not deserve any of suc
On Wed, Oct 31, 2012 at 03:34:22PM +0100, kevin molcard wrote:
> I forgot to mention that I am using scm manager:
> https://bitbucket.org/sdorra/scm-manager/wiki/Home
>
> So that maybe the " custom layer you are talking about.
Yeah, that is very important. If I am reading the scm-manager code ri
Currently, 'git diff --submodule' displays output with a bold diff
header for non-submodules. So this part is in bold:
diff --git a/file1 b/file1
index 30b2f6c..2638038 100644
--- a/file1
+++ b/file1
For submodules, the header looks like this:
Submodule submodule1 012b072..2
Introduce a diff.submodule configuration variable corresponding to the
'--submodule' command-line option of 'git diff'.
Signed-off-by: Ramkumar Ramachandra
---
Documentation/diff-config.txt|7 +++
Documentation/diff-options.txt |3 ++-
builtin/diff.c |4 ++
19299a8 (Documentation: Move diff..* from config.txt to
diff-config.txt, 2011-04-07) moved the diff configuration options to
diff-config.txt, but forgot about diff.wordRegex, which was left
behind in config.txt. Fix this.
Signed-off-by: Ramkumar Ramachandra
---
Documentation/config.txt |
Hi,
v1 is here:
http://mid.gmane.org/1349196670-2844-1-git-send-email-artag...@gmail.com
I've fixed the issues pointed out in the review by Jens.
Sorry about the delay; need to find a new dayjob.
Ramkumar Ramachandra (3):
Documentation: move diff.wordRegex from config.txt to diff-config.txt
On Wed, Oct 31, 2012 at 10:10:24AM -0400, Jeff King wrote:
> On Wed, Oct 31, 2012 at 10:53:27AM +0100, Peter Baumann wrote:
>
> > > covers the basics (current behavior and intent of the change) in its
> > > first two paragraphs and anyone wanting more detail can use
> > >
> > > GIT_NOTES_REF=re
41 matches
Mail list logo
