* Re: Help! My ISP blocks repo.or.cz. How to push changes? (a solution)
From: Asheesh Laroia @ 2009-01-14 17:18 UTC (permalink / raw)
To: Jakub Narebski
Cc: Mike Hommey, Alex Riesen, git, Markus Heidelberg, Luciano Rocha,
J.H.
In-Reply-To: <200901141455.23935.jnareb@gmail.com>
On Wed, 14 Jan 2009, Jakub Narebski wrote:
> Jakub Narebski wrote:
>
>> The ISP I use (Telekomunikacja Polska S.A., aka TP) made some
>> unannounced changes for ADSL service (Neostrada) which made it block
>> repo.or.cz (and of course its aliases, including git.or.cz where git
>> wiki resides).
>
> Thank you all for your help with arriving at solution. I'll describe it
> below; perhaps it would help somebody else (now that it is in mailing
> list archive).
I'll just add some comments that explain what I suggested with a little
more clarity. I'm not saying you have to use it or anything, I just want
to make sure I was clear!
And I'm glad you have a solution!
> First, let me explain what I am working with:
>
> I have access to shell account with set up SSH key access; let's name
> this machine host.example.com. I don't have admin rights there, and
> quota is quite tight; I have installed netcat (nc) in ~/bin - it is
> only 22 kB.
Yes, that is great!
> I don't know where to find SOCKS5 proxy, and I don't have 'tsocks'
> installed either on my computer, or on shell account... I think.
tsocks is packaged in Debian, and surely in other distributions as well.
You don't run it on the shell account, but on your own workstation (which
I call "laptop" below for clarity).
A SOCKS5 proxy can be generated by ssh by running:
[user@laptop] $ ssh -D 1080 shelluser@shellbox
Now:
[user@laptop] $ telnet localhost 1080
will demonstrate that local port 1080 is listening. Because you created it
with -D to ssh, that local port 1080 *is* a SOCKS5 proxy, created by the
local SSH client.
> Now, solutions:
>
> 1. For reading gitweb at repo.or.cz, and for reading and editing git
> wiki at http://git.or.cz/gitwiki/ I use one of free HTTP proxies:
> http://www.4proxy.de (first such proxy I have found that has an
> option to _not_ obfuscate URLs; it still unnecessary escapes some
> things like '/' in the query argument).
Great! (Though note that configuring the web browser to use your
SSH-created SOCKS5 proxy would let you avoid this escaping since the whole
system would be under your control.)
> 2. For pushing changes to repo.or.cz I use SSH tunnel (I could have
> used ProxyCommand solution with netcat instead[1]). I run:
>
> $ autossh -M 2000 -f -N -L 2222:repo.or.cz:22 jnareb@host.example.com
>
> at startup, and I have set the following in ~/.ssh/config:
>
> # TP S.A. blocks repo.or.cz
> Host repo.or.cz
> #ssh -f -N -L 2222:repo.or.cz:22 host.example.com
> NoHostAuthenticationForLocalhost yes
> HostName localhost
> Port 2222
>
> [1] Alternate solution:
>
> # TP S.A. blocks repo.or.cz
> Host repo.or.cz
> ProxyCommand ssh host.example.com exec /home/jnareb/bin/nc %h %p
Right-o.
> 3. For fetching changes via git:// protocol from repo.or.cz I use the
> following setup in git config:
>
> [core]
> gitProxy = ssh-proxy for "repo.or.cz"
>
> Unfortunately example from Documentation/config.txt with "ssh" as
> git proxy command doesn't work, and neither putting command with
> options (e.g. "ssh host.example.com /home/jnareb/bin/nc") doesn't
> work: the command is _not_ split on whitespace. So I had to use
> helper script ~/bin/ssh-proxy:
>
> #!/bin/sh
>
> ssh host.example.com /home/jnareb/bin/nc "$1" "$2"
Great!
> I hope that would help somebody... and if somebody notices better
> solution, hs/she would provide me with it :-)
(-:
-- Asheesh.
--
A visit to a fresh place will bring strange work.
^ permalink raw reply
* Re: [PATCH next v2] git-notes: add test case for multi-line notes
From: Johannes Sixt @ 2009-01-14 17:14 UTC (permalink / raw)
To: Jeff King; +Cc: Tor Arne Vestbø, Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <20090114165633.GC15758@coredump.intra.peff.net>
Jeff King schrieb:
> On Wed, Jan 14, 2009 at 05:28:11PM +0100, Tor Arne Vestbø wrote:
>
>> +MSG=${MSG//%/}
>> +printf "$MSG" > "$1"
>> +printf "$MSG" >& 2
>
> Substitution parameter expansion is a bash-ism, IIRC. How about just
>
> printf %s "$MSG" ?
A the point was that $MSG contains \n, which should be turned int LF. IMO,
the easiest way to achieve this is:
MSG='b3
c3c3c3c3
d3d3d3'
test_expect_success ' ... ' '
...
MSG="$MSG" git notes edit
'
and go back to using echo in the part cited above.
-- Hannes
^ permalink raw reply
* Re: [PATCH next v2] git-notes: add test case for multi-line notes
From: Jeff King @ 2009-01-14 17:13 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: Tor Arne Vestbø, git
In-Reply-To: <200901141109.56580.bss@iguanasuicide.net>
On Wed, Jan 14, 2009 at 11:09:52AM -0600, Boyd Stephen Smith Jr. wrote:
> > printf %s "$MSG" ?
>
> On my box
> $ printf '%s\n' '\n'
> \n
> $
>
> He wants '\n' in $MSG to be expanded, and what you gave doesn't do that.
Oh, sorry. That's what I get for not reading his patch carefully.
It looks like all of the input is statically included in the test
script. While I think it is nice to be defensive, it is probably
simplest to just assume there is no '%' in this case (which we can
verify by reading the script).
-Peff
^ permalink raw reply
* Re: [PATCH next v2] git-notes: add test case for multi-line notes
From: Boyd Stephen Smith Jr. @ 2009-01-14 17:09 UTC (permalink / raw)
To: Jeff King; +Cc: Tor Arne Vestbø, git
In-Reply-To: <20090114165633.GC15758@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 819 bytes --]
On Wednesday 2009 January 14 10:56:33 Jeff King wrote:
>On Wed, Jan 14, 2009 at 05:28:11PM +0100, Tor Arne Vestbø wrote:
>> +MSG=${MSG//%/}
>> +printf "$MSG" > "$1"
>> +printf "$MSG" >& 2
>
>Substitution parameter expansion is a bash-ism, IIRC. How about just
MSG=$(printf '%s\n' "$MSG" | sed -e 's/%/%%/g')
printf "$MSG" > "$1"
printf "$MSG" >& 2
Is my best attempt at portable and "safe". It's a few extra processes though.
> printf %s "$MSG" ?
On my box
$ printf '%s\n' '\n'
\n
$
He wants '\n' in $MSG to be expanded, and what you gave doesn't do that.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH v2 3/3] mark fixed breakage as expect pass for "git mv -k" multiple files
From: Michael J Gruber @ 2009-01-14 17:03 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
In-Reply-To: <1231952603-32527-3-git-send-email-git@drmicha.warpmail.net>
The new tests pass now so mark them as such.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
t/t7001-mv.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t7001-mv.sh b/t/t7001-mv.sh
index 5c1485d..ef2e78f 100755
--- a/t/t7001-mv.sh
+++ b/t/t7001-mv.sh
@@ -49,7 +49,7 @@ test_expect_success \
test -f untracked1 &&
test ! -f path0/untracked1'
-test_expect_failure \
+test_expect_success \
'checking -k on multiple untracked files' \
'touch untracked2 &&
git mv -k untracked1 untracked2 path0 &&
--
1.6.0.6
^ permalink raw reply related
* [PATCH v2 1/3] add test cases for "git mv -k"
From: Michael J Gruber @ 2009-01-14 17:03 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
In-Reply-To: <1231952603-32527-1-git-send-email-git@drmicha.warpmail.net>
Add test cases for ignoring nonexisting and untracked files using the -k
option to "git mv". There is one known breakage related to multiple
untracked files specfied as consecutive arguments.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
t/t7001-mv.sh | 25 +++++++++++++++++++++++++
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/t/t7001-mv.sh b/t/t7001-mv.sh
index 575ef5b..5c1485d 100755
--- a/t/t7001-mv.sh
+++ b/t/t7001-mv.sh
@@ -39,6 +39,31 @@ test_expect_success \
grep "^R100..*path1/COPYING..*path0/COPYING"'
test_expect_success \
+ 'checking -k on non-existing file' \
+ 'git mv -k idontexist path0'
+
+test_expect_success \
+ 'checking -k on untracked file' \
+ 'touch untracked1 &&
+ git mv -k untracked1 path0 &&
+ test -f untracked1 &&
+ test ! -f path0/untracked1'
+
+test_expect_failure \
+ 'checking -k on multiple untracked files' \
+ 'touch untracked2 &&
+ git mv -k untracked1 untracked2 path0 &&
+ test -f untracked1 &&
+ test -f untracked2 &&
+ test ! -f path0/untracked1
+ test ! -f path0/untracked2'
+
+# clean up the mess in case bad things happen
+rm -f idontexist untracked1 untracked2 \
+ path0/idontexist path0/untracked1 path0/untracked2 \
+ .git/index.lock
+
+test_expect_success \
'adding another file' \
'cp "$TEST_DIRECTORY"/../README path0/README &&
git add path0/README &&
--
1.6.0.6
^ permalink raw reply related
* [PATCH v2 2/3] fix handling of multiple untracked files for git mv -k
From: Michael J Gruber @ 2009-01-14 17:03 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
In-Reply-To: <1231952603-32527-2-git-send-email-git@drmicha.warpmail.net>
The "-k" option to "git mv" should allow specifying multiple untracked
files. Currently, multiple untracked files raise an assertion if they
appear consecutively as arguments. Fix this by decrementing the loop
index after removing one entry from the array of arguments.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
builtin-mv.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/builtin-mv.c b/builtin-mv.c
index 4f65b5a..bce9959 100644
--- a/builtin-mv.c
+++ b/builtin-mv.c
@@ -192,6 +192,7 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
memmove(destination + i,
destination + i + 1,
(argc - i) * sizeof(char *));
+ i--;
}
} else
die ("%s, source=%s, destination=%s",
--
1.6.0.6
^ permalink raw reply related
* [PATCH v2 0/3] Add test cases for "git mv -k" and fix a known breakage.
From: Michael J Gruber @ 2009-01-14 17:03 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
In-Reply-To: <alpine.DEB.1.00.0901141653540.3586@pacific.mpi-cbg.de>
This adds test cases for the "-k" option of "git mv", including one
known breakage reported by Matthieu Moy <Matthieu.Moy@imag.fr> which
appears when multiple untracked files are specified as consecutive
arguments. This breakage is fixed in the second patch and marked
"expect_pass" in the last one.
The cumulative code/other ratio is 1 line/27 lines which I blame solely
on Dscho ;) Seriously, feel free to squash. But on the other hand: How
else can I see the beautiful "1 known breakage fixed" other than by
having 2 and 3 separate in this series...
The patch is off master but builtin-mv.c hasn't changed since
81dc2307d0ad87a4da2e753a9d1b5586d6456eed tags/v1.6.0-rc1~1, so I suggest
this patch for maint.
Michael J Gruber (3):
add test cases for "git mv -k"
fix handling of multiple untracked files for git mv -k
mark fixed breakage as expect pass for "git mv -k" multiple files
builtin-mv.c | 1 +
t/t7001-mv.sh | 25 +++++++++++++++++++++++++
2 files changed, 26 insertions(+), 0 deletions(-)
^ permalink raw reply
* Re: [PATCH next v2] git-notes: add test case for multi-line notes
From: Jeff King @ 2009-01-14 16:56 UTC (permalink / raw)
To: Tor Arne Vestbø; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <496E129B.3020502@trolltech.com>
On Wed, Jan 14, 2009 at 05:28:11PM +0100, Tor Arne Vestbø wrote:
> +MSG=${MSG//%/}
> +printf "$MSG" > "$1"
> +printf "$MSG" >& 2
Substitution parameter expansion is a bash-ism, IIRC. How about just
printf %s "$MSG" ?
-Peff
^ permalink raw reply
* Re: Commit messages
From: Ted Pavlic @ 2009-01-14 16:55 UTC (permalink / raw)
To: Teemu Likonen; +Cc: git
In-Reply-To: <8763kjt0mw.fsf_-_@iki.fi>
That rule could be modified to support .stgit-edit.txt as well.
> (add-to-list 'auto-mode-alist
> '("/\\.git/\\(COMMIT\\|TAG\\)_EDITMSG\\'" .
> vcs-message-mode))
--
Ted Pavlic <ted@tedpavlic.com>
Please visit my ALS association page:
http://web.alsa.org/goto/tedpavlic
My family appreciates your support in the fight to defeat ALS.
^ permalink raw reply
* Re: [PATCH 3/3] implement pattern matching in ce_path_match
From: Jeff King @ 2009-01-14 16:53 UTC (permalink / raw)
To: Samuel Tardieu
Cc: Johannes Schindelin, Clemens Buchacher, git, Junio C Hamano,
johannes
In-Reply-To: <2009-01-14-17-18-40+trackit+sam@rfc1149.net>
On Wed, Jan 14, 2009 at 05:18:39PM +0100, Samuel Tardieu wrote:
> My taste would favor:
>
> static int has_special(const char *p)
> {
> for (; *p; p++)
> if (isspecial(*p))
> return 1;
> return 0;
> }
That was my first thought upon reading the other two, as well. And I
agree with all of the reasoning you gave.
-Peff
^ permalink raw reply
* Re: [BUG] assertion failure in builtin-mv.c with "git mv -k"
From: Jeff King @ 2009-01-14 16:47 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Johannes Schindelin, Matthieu Moy, git
In-Reply-To: <496E0D1C.20807@drmicha.warpmail.net>
On Wed, Jan 14, 2009 at 05:04:44PM +0100, Michael J Gruber wrote:
> It was a lame attempt at getting around it, it's just one line... I
> didn't know I've been being noticed long enough ;)
> So, should I prepare a series like:
>
> 1: test case and mark known fail
> 2: the 1 line fix
> 3: mark test pass
>
> Or should 2+3 be squashed into one?
Definitely the fix and marking the test as passing should be one patch,
since then you see that it is the fix which causes the test to pass. But
really, for a simple fix I usually just squash it all into a single
patch. Then somebody looking at the patch later says "Oh, this is what
was broken, and here is how it was fixed."
-Peff
^ permalink raw reply
* Re: [ANNOUNCE] tig-0.13
From: Ted Pavlic @ 2009-01-14 16:33 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <20090113233643.GA28898@diku.dk>
Thanks for this. It's a nice tool.
> What is tig?
> ------------
> Tig is an ncurses-based text-mode interface for git. It functions mainly
> as a git repository browser, but can also assist in staging changes for
> commit at chunk level and act as a pager for output from various git
> commands.
>
> - Homepage: http://jonas.nitro.dk/tig/
> - Manual: http://jonas.nitro.dk/tig/manual.html
> - Tarballs: http://jonas.nitro.dk/tig/releases/
> - Git URL: git://repo.or.cz/tig.git
> - Gitweb: http://repo.or.cz/w/tig.git
--
Ted Pavlic <ted@tedpavlic.com>
Please visit my ALS association page:
http://web.alsa.org/goto/tedpavlic
My family appreciates your support in the fight to defeat ALS.
^ permalink raw reply
* Re: [PATCH 3/3] implement pattern matching in ce_path_match
From: Samuel Tardieu @ 2009-01-14 16:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Clemens Buchacher, git, Junio C Hamano, johannes
In-Reply-To: <alpine.DEB.1.00.0901141641500.3586@pacific.mpi-cbg.de>
>>>>> "Johannes" == Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Dscho> I would prefer something like this:
My taste would favor:
static int has_special(const char *p)
{
for (; *p; p++)
if (isspecial(*p))
return 1;
return 0;
}
as it underlines the intent (loop over "p" characters and stop no
later than the end of the string) while avoiding using side effects in
the body to increment the pointer. This habit comes from Ada, where
loop indices are considered read-only in the loop body.
It also eases further extensions such as
static int has_special(const char *p)
{
for (; *p; p++)
if (isspecial(*p) || isveryspecial(*p))
return 1;
return 0;
}
without having to move the "++" somewhere else.
Dscho> but that is probably a matter of taste.
Agreed.
Sam
--
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/
^ permalink raw reply
* [PATCH next v2] git-notes: add test case for multi-line notes
From: Tor Arne Vestbø @ 2009-01-14 16:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901141627440.3586@pacific.mpi-cbg.de>
The tests adds a third commit with a multi-line note. The output of
git log -2 is then checked to see if the note lines are wrapped
correctly, and that there's a line separator between the two commits.
Signed-off-by: Tor Arne Vestbø <tavestbo@trolltech.com>
---
Thanks for the feedback Johannes! Here's an updated patch. I removed
the blank line instead of adding another, as that's the current style
of that file.
t/t3301-notes.sh | 35 ++++++++++++++++++++++++++++++++---
1 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/t/t3301-notes.sh b/t/t3301-notes.sh
index ba42c45..e260d79 100755
--- a/t/t3301-notes.sh
+++ b/t/t3301-notes.sh
@@ -8,8 +8,9 @@ test_description='Test commit notes'
. ./test-lib.sh
cat > fake_editor.sh << \EOF
-echo "$MSG" > "$1"
-echo "$MSG" >& 2
+MSG=${MSG//%/}
+printf "$MSG" > "$1"
+printf "$MSG" >& 2
EOF
chmod a+x fake_editor.sh
VISUAL=./fake_editor.sh
@@ -59,7 +60,35 @@ EOF
test_expect_success 'show notes' '
! (git cat-file commit HEAD | grep b1) &&
git log -1 > output &&
- git diff expect output
+ test_cmp expect output
+'
+test_expect_success 'create multi-line notes (setup)' '
+ : > a3 &&
+ git add a3 &&
+ test_tick &&
+ git commit -m 3rd &&
+ MSG="b3\nc3c3c3c3\nd3d3d3" git notes edit
+'
+
+cat > expect-multiline << EOF
+commit 1584215f1d29c65e99c6c6848626553fdd07fd75
+Author: A U Thor <author@example.com>
+Date: Thu Apr 7 15:15:13 2005 -0700
+
+ 3rd
+
+Notes:
+ b3
+ c3c3c3c3
+ d3d3d3
+EOF
+
+printf "\n" >> expect-multiline
+cat expect >> expect-multiline
+
+test_expect_success 'show multi-line notes' '
+ git log -2 > output &&
+ test_cmp expect-multiline output
'
test_done
--
1.6.0.2.GIT
^ permalink raw reply related
* [Q] git rebase -i -p conflicts with squash
From: Constantine Plotnikov @ 2009-01-14 16:13 UTC (permalink / raw)
To: git
If I run git rebase --interactive with --preserve-merges option and
select "squash" for one of the commit, the rebase process fails with
the message "Refusing to squash a merge:
5e775c536654640c173ba71a0af7e84bf8bc618a". However the neither commit
participating in the squash is a merge commit. Even more, there are no
merge commits in the repository at all.
>From my limited understanding of squash operation, it should fail only
if one of squashed commits is a merge commit, but it should be
possible to squash non-merge commits without problem as it looks like
quite safe and local operation (and I might want to preserve merges
that happened after squashed commits). Is it the current behaviour a
bug or a feature?
Constantine
^ permalink raw reply
* Re: [PATCH 2/3] remove pathspec_match, use match_pathspec instead
From: Clemens Buchacher @ 2009-01-14 16:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano, johannes
In-Reply-To: <alpine.DEB.1.00.0901141637170.3586@pacific.mpi-cbg.de>
On Wed, Jan 14, 2009 at 04:40:42PM +0100, Johannes Schindelin wrote:
> > Both versions have the same functionality. This removes any
> > redundancy.
> >
> > This also adds makes two extensions to match_pathspec:
>
> s/makes//
Thanks.
> Nice. Does it still pass the test suite? (From my reading, it should,
> but I do not quite have the time to run it right now.)
It sure does. I am not confident enough to send untested patches yet. :-)
On Wed, Jan 14, 2009 at 04:44:36PM +0100, Johannes Schindelin wrote:
> I would prefer something like this:
>
> static int has_special(const char *p)
> {
> while (*p)
> if (isspecial(*(p++)))
> return 1;
> return 0;
> }
Ok, no problem.
^ permalink raw reply
* Re: [BUG] assertion failure in builtin-mv.c with "git mv -k"
From: Michael J Gruber @ 2009-01-14 16:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Matthieu Moy, git
In-Reply-To: <alpine.DEB.1.00.0901141653540.3586@pacific.mpi-cbg.de>
Johannes Schindelin venit, vidit, dixit 14.01.2009 16:54:
> Hi,
>
> On Wed, 14 Jan 2009, Michael J Gruber wrote:
>
>> I'll send a patch but I'm not sure if this needs a test case.
>
> Umm, Michael, you have been here long enough to know that the answer is a
> "YES!". If you fix something, you want to provide a test case just to
> make sure you do not need to fix it again later.
>
> Ciao,
> Dscho
>
It was a lame attempt at getting around it, it's just one line... I
didn't know I've been being noticed long enough ;)
So, should I prepare a series like:
1: test case and mark known fail
2: the 1 line fix
3: mark test pass
Or should 2+3 be squashed into one?
Cheers,
Michael
^ permalink raw reply
* Re: git Thunderbird Synching
From: Sitaram Chamarty @ 2009-01-14 16:01 UTC (permalink / raw)
To: git
In-Reply-To: <496D99BA.6000208@vt.edu>
On 2009-01-14, Nicholas LaRoche <nlaroche@vt.edu> wrote:
> I want to do something like this with my main profile, but I'm concerned
> that if I send/receive email on either machine independently that there
> will be corruption in some of the files when I push back to my main box.
The mbox files making up the actual mail are probably safe
enough, assuming you do the git operations with TB shut
down, not running. In effect, each message is one chunk of
code, and you're basically deleting or adding them. Ugly,
but it would probably work.
But I expect serious trouble with the MSF files that TB
maintains, symptoms being quick searches not working or
showing something in the message list pane and some other
unrelated message in the preview pane.
And that's if you can get git to merge them in the first
place -- which I very much doubt. For all practical
purposes they're binary blobs.
So if you don't care about the MSF at all and can rebuild
them each time, this would work.
Otherwise IMAP is a better option :-)
^ permalink raw reply
* Re: [PATCH 3/3] implement pattern matching in ce_path_match
From: Sverre Rabbelier @ 2009-01-14 15:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Clemens Buchacher, git, Junio C Hamano, johannes
In-Reply-To: <alpine.DEB.1.00.0901141641500.3586@pacific.mpi-cbg.de>
On Wed, Jan 14, 2009 at 16:44, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>> +static int has_special(const char *p)
>> +{
>> + int x;
>> +
>> + while ((x = *p++) != '\0')
>> + if (isspecial(x))
>> + return 1;
>> +
>> + return 0;
>> +}
>
> I would prefer something like this:
>
> static int has_special(const char *p)
> {
> while (*p)
> if (isspecial(*(p++)))
> return 1;
> return 0;
> }
>
> but that is probably a matter of taste.
FWIW, I think the above is a lot less readable due to the assignment
in the while loop's conditional. Whereas in Dscho's version it is
intuitively obvious what the termination condition of the while loop
is.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [StGit] import --mail/--mbox question
From: Shinya Kuribayashi @ 2009-01-14 15:35 UTC (permalink / raw)
To: git
Hi,
I've been wondering this for quite some time, now try to sort out.
---
Question: when importing Mozilla Thunderbird mails (eml or mbox), the
imported patch always have committer's date in git log, not submitter's
date. However, if importing the same mails with git am, we could see
submitter's date in git log.
Is this intentionally-designed log management of StGit? I would expect
the submitter's date & locale is kept when importing patches from
e-mails.
Reproducible: Always
Steps to Reproduce:
1. Prepare eml or mbox file.
[Thunderbird eml file]
- Select a mail,
- File -> Save as -> File,
- Format -> Mail files
[mbox file]
- use add-ons, such as ImportExportTools(MboxImport)
- extract directly from profile/ dir
2. Import eml/mbox file with --mail/--mbox option
$ stg import --mail [eml file]
$ stg import --mbox [mbox file]
3. Check git log
Example:
Mbox header (this mbox contains one patch)
------------------------------------------
From - Wed Jan 7 00:41:57 2009
X-Account-Key: account3
X-UIDL: 6d997fc0c53b4541c56eeeeb45732171
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys: X-DTI-Virus-Check: checked
X-DTI-Recipient: <skuribay@ruby.dti.ne.jp>
Return-Path: <sr@denx.de>
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by pop.ruby.dti.ne.jp (3.10p) with ESMTP id n06AZr2v009835 for <skuribay@ruby.dti.ne.jp>; Tue, 6 Jan 2009 19:35:53 +0900 (JST)
Received: from localhost.localdomain (p5B2A461A.dip.t-dialin.net [91.42.70.26])
by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis)
id 0MKwpI-1LK9Hn0ym1-0002Ja; Tue, 06 Jan 2009 11:35:51 +0100
From: Stefan Roese <sr@denx.de>
To: u-boot@lists.denx.de
Cc: skuribay@ruby.dti.ne.jp
Subject: [PATCH 1/3 v2] MIPS: Add VCT board series support (Part 1/3)
Date: Tue, 6 Jan 2009 11:35:46 +0100
Message-Id: <1231238146-2813-1-git-send-email-sr@denx.de>
X-Mailer: git-send-email 1.6.1
X-Provags-ID: V01U2FsdGVkX19dTpfkGdmBDPbfKKBfEQYFLGbts7teQcJyLTZ
xUdZWxGujKNfCpOIRv/s7i7nrf13E4zGP6P0nibSP6yFfDLBv3
0qZDbTBuPI1ViEQrnIGZCASl9Z6H8em
This patch adds support for the Micronas VCT board series.
Currently the following platforms are supported:
:
:
Resulting git log
-----------------
commit b659910dd0d75220c3cdbd3408a5025340e6a562
Author: Stefan Roese <sr@denx.de>
Date: Thu Jan 15 00:06:27 2009 +0900 <-- this is my date & locale(JP)
MIPS: Add VCT board series support (Part 1/3)
This patch adds support for the Micronas VCT board series.
Currently the following platforms are supported:
vct_premium
vct_premium_small
vct_premium_onenan
:
:
Version:
Stacked GIT 0.14.3.327.ge4f6.dirty
git version 1.5.4.3
Python version 2.5.2 (r252:60911, Jul 31 2008, 17:28:52)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)]
Thanks in advance,
Shinya
^ permalink raw reply
* Re: git merge and cherry-pick and duplicated commits?
From: Sitaram Chamarty @ 2009-01-14 15:53 UTC (permalink / raw)
To: git
In-Reply-To: <2729632a0901132333h6caf9facu871869abce5597c1@mail.gmail.com>
On 2009-01-14, skillzero@gmail.com <skillzero@gmail.com> wrote:
> I guess maybe a better question is how do people normally handle
> situations like mine where I did some work on branch X and I later
> realize I need only a portion of that work on branch Y? I'm not sure
> how I can change my workflow to completely eliminate these situations.
> For example, I often start a branch to add a new feature and I end up
> fixing bug A on that branch. Then other people on my team decide they
> need the fix for bug A immediately and can't wait for me to finish my
> feature branch and do a full merge.
>
> Is there some way I can change my workflow such that I can fix bug A
> (maybe on a separate branch?) and somehow apply it to both both
> branches in a way that won't result in duplicate commits?
>
> Does this kind of thing ever happen with the Linux kernel or git
> itself: somebody does a fix as part of their topic branch and the
> Linux kernel or git master wants that particular fix now, but is not
> ready for the full topic branch? Would they just suggest the fix be
> separated into its own topic branch and that merged? If so, how would
> that new topic branch merge into the original topic branch without
> resulting in a duplicate commit when it's later merged into master?
If I understand you right, you're talking about a situation
where a particular change is in two different branches, but
the SHA is different.
And yet, in your scenario, both of these branches somehow
get merged into the final branch.
In other words, a DAG of branches merging itself has a
merge, if that makes sense :-)
You may need to think about how commits flow from branch to
branch, and what branches are private, and therefore can be
rebased or change history, and what are public, and how
often and when the private ones rebase off of the public
ones.
^ permalink raw reply
* Re: [BUG] assertion failure in builtin-mv.c with "git mv -k"
From: Johannes Schindelin @ 2009-01-14 15:54 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Matthieu Moy, git
In-Reply-To: <496DFC75.2000904@drmicha.warpmail.net>
Hi,
On Wed, 14 Jan 2009, Michael J Gruber wrote:
> I'll send a patch but I'm not sure if this needs a test case.
Umm, Michael, you have been here long enough to know that the answer is a
"YES!". If you fix something, you want to provide a test case just to
make sure you do not need to fix it again later.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/3] implement pattern matching in ce_path_match
From: Johannes Schindelin @ 2009-01-14 15:44 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git, Junio C Hamano, johannes
In-Reply-To: <1231944876-29930-4-git-send-email-drizzd@aon.at>
Hi,
On Wed, 14 Jan 2009, Clemens Buchacher wrote:
> @@ -25,6 +25,17 @@ static int default_show_root = 1;
> static const char *fmt_patch_subject_prefix = "PATCH";
> static const char *fmt_pretty;
>
> +static int has_special(const char *p)
> +{
> + int x;
> +
> + while ((x = *p++) != '\0')
> + if (isspecial(x))
> + return 1;
> +
> + return 0;
> +}
I would prefer something like this:
static int has_special(const char *p)
{
while (*p)
if (isspecial(*(p++)))
return 1;
return 0;
}
but that is probably a matter of taste.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] fix handling of multiple untracked files for git mv -k
From: Michael J Gruber @ 2009-01-14 15:42 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <vpqwscy81o8.fsf@bauges.imag.fr>
The "-k" option to "git mv" should allow specifying multiple untracked
files. Currently, multiple untracked files raise an assertion if they
appear consecutively as arguments. Fix this by decrementing the loop
index after removing one entry from the array of arguments.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
builtin-mv.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
Reported by the OP. Do we need a test case for this? It's a really
trivial change. The patch is off master but builtin-mv.c hasn't change
since 81dc2307d0ad87a4da2e753a9d1b5586d6456eed tags/v1.6.0-rc1~1, so I
suggest this patch for maint.
diff --git a/builtin-mv.c b/builtin-mv.c
index 4f65b5a..bce9959 100644
--- a/builtin-mv.c
+++ b/builtin-mv.c
@@ -192,6 +192,7 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
memmove(destination + i,
destination + i + 1,
(argc - i) * sizeof(char *));
+ i--;
}
} else
die ("%s, source=%s, destination=%s",
--
1.6.0.6
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox