* Re: git pull versus fetch/merge
From: Jeff King @ 2008-07-21 11:09 UTC (permalink / raw)
To: Rene Herman; +Cc: Björn Steinbrink, git, Takashi Iwai
In-Reply-To: <48846BC2.4090407@keyaccess.nl>
On Mon, Jul 21, 2008 at 12:58:10PM +0200, Rene Herman wrote:
> Thank you. Also due to a reply on the ALSA list by Mark brown I now get
> this. Yes, the remote was rebased while I had it setup as a remote here
> it seems; only recently have it under this name, so I didn't think that
> was the case. After a "git remote rm tiwai, git remote add tiwai <url>"
> things work fine again as it fetched a completely new branch.
Not that adding the remote with "git remote add" will add a fetchspec
line like this:
[remote "tiwai"]
fetch = +refs/heads/*:+refs/remotes/tiwai/*
where the '+' means to force fetching rewound branches instead of
rejecting them (this is safe, since you are just overwriting tracking
branches, not your local work). So this should not come up again;
presumably your previous remote configuration was set up differently.
-Peff
^ permalink raw reply
* Re: git pull versus fetch/merge
From: Jeff King @ 2008-07-21 11:09 UTC (permalink / raw)
To: Rene Herman; +Cc: Björn Steinbrink, git, Takashi Iwai
In-Reply-To: <20080721110900.GA8550@sigill.intra.peff.net>
On Mon, Jul 21, 2008 at 07:09:00AM -0400, Jeff King wrote:
> Not that adding the remote with "git remote add" will add a fetchspec
^^^
Err, that should be "note", of course. I am having a real problem typing
today.
-Peff
^ permalink raw reply
* Re: Git Branding Overview, Re: Git.or.cz Experimental Design
From: Johannes Schindelin @ 2008-07-21 11:20 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <g61q6n$645$1@ger.gmane.org>
Hi,
On Mon, 21 Jul 2008, Michael J Gruber wrote:
> Martin Langhoff venit, vidit, dixit 20.07.2008 23:50:
> > On Fri, Jul 18, 2008 at 10:39 PM, Petr Baudis <pasky@suse.cz> wrote:
> > > On Wed, Jul 02, 2008 at 11:11:02PM -0400, David Baldwin wrote:
> > > > http://baldwindev.com/git.or.cz/
> > > I'm not sure if this is really an improvement on the current state,
> > > but then again, the current state pretty much matches my idea and maybe
> > > others will agree that your proposal is better. Thus, it's better to
> > > show this to the Git community at large. :-)
> >
> > FWIW, I like it. I like both the better font and whitespace layout and
> > the 3-color-spot-merge-to-white. As Petr says, we have had the
> > (apologies, but to me) ugly logo for a while, so it is widely used,
> > and perhaps it has even grown on people.
> >
> > BazaarNG managed to grab the best concept logo of the lot, IMHO, with
> > the 'merge' roadsign.
> >
> > > If you think you have a cooler logo, that's fine too, but then it's
> > > again better to present it explicitly, I believe.
> >
> > Can we separate the 2 things? The better fonts and layout look like a win to
> > me.
> >
> > WRT the logo, the current one is not a particularly strong image, and
> > we haven't spent millions in plastering it over magazines or anything.
> > So a good new logo would be something to take on.
>
> I like that new logo (plusminus G), too, it's very descriptive. I just want to
> raise one question which I can't answer myself:
>
> Are there any potential issues with the Helvetica license?
>
> In any case it may be safer do redo it with a GPL sans serif font. If one
> wants to keep the association of the shape of "G" with a circular arrow then
> FreeSans and Nimbus Sans L seem to be the only options.
>
> Alternatively, it may be easier to redo it in plain PS. I'll attach 2 KISS
> variants. 1.5k for the eps, 3 colors only.
You could have spared yourself the trouble:
http://repo.or.cz/w/msysgit.git?a=blob_plain;f=share/resources/gitlogo.svg;h=c0d67e70ab31394f0635c141998e512437a138b4;hb=HEAD
Done without the use of any font at all.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v2] Ensure that SSH runs in non-interactive mode
From: Johannes Schindelin @ 2008-07-21 11:22 UTC (permalink / raw)
To: Jeff King; +Cc: Jakub Narebski, Fredrik Tolf, git
In-Reply-To: <20080721110436.GA8395@sigill.intra.peff.net>
Hi,
On Mon, 21 Jul 2008, Jeff King wrote:
> On Mon, Jul 21, 2008 at 12:56:14PM +0200, Johannes Schindelin wrote:
>
> > > or syntax used in RPM spec macros
> > >
> > > %{?p:-P %p}
> > >
> > > (and there is complementing %{!?<var>:<expansion>} in RPM spec macro
> > > language).
> >
> > Yes, this is overkill. I would even have passed the port argument
> > _always_, since the port 22 for ssh is as likely to change as hell will
> > not freeze over. Actually, I am not so sure about the latter.
>
> But keep in mind that "-p 22" on the command line _overrides_ what the
> user has in their ssh config, so it is not a good idea to pass it all
> the time.
Oh, good point. So we might need something distasteful as what Jakub
proposed... Hrmpf.
Ciao,
Dscho
^ permalink raw reply
* Re: git pull versus fetch/merge
From: Rene Herman @ 2008-07-21 11:30 UTC (permalink / raw)
To: Jeff King; +Cc: Björn Steinbrink, git, Takashi Iwai
In-Reply-To: <20080721110900.GA8550@sigill.intra.peff.net>
On 21-07-08 13:09, Jeff King wrote:
> On Mon, Jul 21, 2008 at 12:58:10PM +0200, Rene Herman wrote:
>
>> Thank you. Also due to a reply on the ALSA list by Mark brown I now get
>> this. Yes, the remote was rebased while I had it setup as a remote here
>> it seems; only recently have it under this name, so I didn't think that
>> was the case. After a "git remote rm tiwai, git remote add tiwai <url>"
>> things work fine again as it fetched a completely new branch.
>
> Note that adding the remote with "git remote add" will add a fetchspec
> line like this:
>
> [remote "tiwai"]
> fetch = +refs/heads/*:+refs/remotes/tiwai/*
>
> where the '+' means to force fetching rewound branches instead of
> rejecting them (this is safe, since you are just overwriting tracking
> branches, not your local work).
Not here...
rene@7ixe4:~/src/linux/7ixe4$ git remote add tmp
git://git.alsa-project.org/alsa-kernel.git
rene@7ixe4:~/src/linux/7ixe4$ tail -3 .git/config
[remote "tmp"]
url = git://git.alsa-project.org/alsa-kernel.git
fetch = refs/heads/*:refs/remotes/tmp/*
rene@7ixe4:~/src/linux/7ixe4$ git --version
git version 1.5.5
> So this should not come up again; presumably your previous remote
> configuration was set up differently.
Must be something new or configuration dependent I presume? It's not an
option to git-remote it seems (but yes, thanks, I guess I'll add the +s
-- a failed merge is warning enough that I need to rebuild whatever
branch I'm pulling it into I guess).
Rene.
^ permalink raw reply
* Re: error: hook declined to update refs/heads/master
From: Jonathan Biolaz @ 2008-07-21 11:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807211153340.3305@eeepc-johanness>
> Hi,
>
> On Mon, 21 Jul 2008, Jonathan Biolaz wrote:
>
>> $ git push origin master
>>
>> Counting objects: 1709, done.
>> Compressing objects: 100% (1523/1523), done.
>> Writing objects: 100% (1709/1709), 1.95 MiB | 3818 KiB/s, done.
>> Total 1709 (delta 535), reused 0 (delta 0)
>> *** Project description file hasn't been set
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>> error: hooks/update exited with error code 1
>> error: hook declined to update refs/heads/master
>
> Apparently, you have a hook installed on the remote side which
> checks for
> a valid description, and refuses even updating refs before you set the
> description correctly.
Ok.
So, what's a hook ? and how I set the description ??
Thanks
^ permalink raw reply
* Re: git pull versus fetch/merge
From: Björn Steinbrink @ 2008-07-21 11:33 UTC (permalink / raw)
To: Rene Herman; +Cc: Jeff King, git, Takashi Iwai
In-Reply-To: <48847344.5060908@keyaccess.nl>
On 2008.07.21 13:30:12 +0200, Rene Herman wrote:
> On 21-07-08 13:09, Jeff King wrote:
>
>> On Mon, Jul 21, 2008 at 12:58:10PM +0200, Rene Herman wrote:
>>
>>> Thank you. Also due to a reply on the ALSA list by Mark brown I now
>>> get this. Yes, the remote was rebased while I had it setup as a
>>> remote here it seems; only recently have it under this name, so I
>>> didn't think that was the case. After a "git remote rm tiwai, git
>>> remote add tiwai <url>" things work fine again as it fetched a
>>> completely new branch.
>>
>> Note that adding the remote with "git remote add" will add a fetchspec
>> line like this:
>>
>> [remote "tiwai"]
>> fetch = +refs/heads/*:+refs/remotes/tiwai/*
>>
>> where the '+' means to force fetching rewound branches instead of
>> rejecting them (this is safe, since you are just overwriting tracking
>> branches, not your local work).
>
> Not here...
>
> rene@7ixe4:~/src/linux/7ixe4$ git remote add tmp
> git://git.alsa-project.org/alsa-kernel.git
> rene@7ixe4:~/src/linux/7ixe4$ tail -3 .git/config
>
> [remote "tmp"]
> url = git://git.alsa-project.org/alsa-kernel.git
> fetch = refs/heads/*:refs/remotes/tmp/*
> rene@7ixe4:~/src/linux/7ixe4$ git --version
> git version 1.5.5
Broken in 1.5.5 and 1.5.5.1, Jeff's fix went into 1.5.5.2. Bad luck ;-)
Björn
^ permalink raw reply
* Re: git pull versus fetch/merge
From: Rene Herman @ 2008-07-21 11:39 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Jeff King, git, Takashi Iwai
In-Reply-To: <20080721113352.GA21009@atjola.homenet>
On 21-07-08 13:33, Björn Steinbrink wrote:
>> rene@7ixe4:~/src/linux/7ixe4$ git --version
>> git version 1.5.5
>
> Broken in 1.5.5 and 1.5.5.1, Jeff's fix went into 1.5.5.2. Bad luck ;-)
Sheesh. Thanks :-)
Rene.
^ permalink raw reply
* Re: Git Branding Overview, Re: Git.or.cz Experimental Design
From: Michael J Gruber @ 2008-07-21 12:20 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.0807211218470.8986@racer>
Johannes Schindelin venit, vidit, dixit 21.07.2008 13:20:
> Hi,
>
> On Mon, 21 Jul 2008, Michael J Gruber wrote:
>
>> Martin Langhoff venit, vidit, dixit 20.07.2008 23:50:
>>> On Fri, Jul 18, 2008 at 10:39 PM, Petr Baudis <pasky@suse.cz> wrote:
>>>> On Wed, Jul 02, 2008 at 11:11:02PM -0400, David Baldwin wrote:
>>>>> http://baldwindev.com/git.or.cz/
>>>> I'm not sure if this is really an improvement on the current state,
>>>> but then again, the current state pretty much matches my idea and maybe
>>>> others will agree that your proposal is better. Thus, it's better to
>>>> show this to the Git community at large. :-)
>>> FWIW, I like it. I like both the better font and whitespace layout and
>>> the 3-color-spot-merge-to-white. As Petr says, we have had the
>>> (apologies, but to me) ugly logo for a while, so it is widely used,
>>> and perhaps it has even grown on people.
>>>
>>> BazaarNG managed to grab the best concept logo of the lot, IMHO, with
>>> the 'merge' roadsign.
>>>
>>>> If you think you have a cooler logo, that's fine too, but then it's
>>>> again better to present it explicitly, I believe.
>>> Can we separate the 2 things? The better fonts and layout look like a win to
>>> me.
>>>
>>> WRT the logo, the current one is not a particularly strong image, and
>>> we haven't spent millions in plastering it over magazines or anything.
>>> So a good new logo would be something to take on.
>> I like that new logo (plusminus G), too, it's very descriptive. I just want to
>> raise one question which I can't answer myself:
>>
>> Are there any potential issues with the Helvetica license?
>>
>> In any case it may be safer do redo it with a GPL sans serif font. If one
>> wants to keep the association of the shape of "G" with a circular arrow then
>> FreeSans and Nimbus Sans L seem to be the only options.
>>
>> Alternatively, it may be easier to redo it in plain PS. I'll attach 2 KISS
>> variants. 1.5k for the eps, 3 colors only.
>
> You could have spared yourself the trouble:
Thanks for the appreciation ;)
>
> http://repo.or.cz/w/msysgit.git?a=blob_plain;f=share/resources/gitlogo.svg;h=c0d67e70ab31394f0635c141998e512437a138b4;hb=HEAD
>
> Done without the use of any font at all.
I don't think that was on the wiki before. Henrik's version (which was,
and was being discussed here) *is* based on Helvetica.
Still, the suggestion stands to replace it by something more polished.
Michael
^ permalink raw reply
* Re: problem using jgit
From: Marek Zawirski @ 2008-07-21 12:35 UTC (permalink / raw)
To: Stephen Bannasch; +Cc: git, Robin Rosenberg, Shawn O. Pearce
In-Reply-To: <488467E3.7000107@gmail.com>
Marek Zawirski wrote:
> Stephen Bannasch wrote:
>> I've setup a simple test class that integrates jgit to clone a git
>> repository. However I'm getting a NullPointerError when
>> RevWalk.parseAny ends up producing a null object id.
>>
>> The code and the stack trace for the error are here:
>>
>> http://pastie.org/237711
>>
>> This problem occurs using the jgit from the master branch from this
>> repo:
>>
>> git://repo.or.cz/egit.git
> Hello Stephen,
>
> I think you've experienced error caused by the same bug as me, during
> my latest fetch/push GUI works few days ago.
> Your code looks fine, probably it's actually bug in jgit. I think
> it's some regression. Thanks for reporting.
It's caused by 14a630c3: Cached modification times for symbolic refs too
Changes introduced by this patch made Repository#getAllRefs() including
Ref objects with null ObjectId in case of unresolvable (invalid?) HEAD
symbolic ref, and null Ref for HEAD when it doesn't exist. Previous
behavior was just not including such refs in result.
Fix for null Ref is just a matter of simple filtering out null Ref
object for HEAD, if it doesn't exist (just is it considered to be legal
state of repository when HEAD doesn't exist?).
To fix null ObjectId issue, we have to either change all clients of this
method or revert method to previous behavior. Now it's just unspecified
in javadoc.
Robin, Shawn, what do you think? If we want to have unresolvable refs
included, IMO it may be sensible to provide argument includeUnresolbable
for Repository#getAllRefs() to let clients avoid burden of filtering
them out when they don't need them (most cases, perhaps).
I can prepare fix for it (rather easy one) as you are unavailable now,
let me now what's your opinion.
^ permalink raw reply
* Re: [PATCH v2] Ensure that SSH runs in non-interactive mode
From: Fredrik Tolf @ 2008-07-21 13:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, Jakub Narebski, git
In-Reply-To: <alpine.DEB.1.00.0807211221310.8986@racer>
On Mon, 2008-07-21 at 12:22 +0100, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 21 Jul 2008, Jeff King wrote:
>
> > On Mon, Jul 21, 2008 at 12:56:14PM +0200, Johannes Schindelin wrote:
> >
> > > > or syntax used in RPM spec macros
> > > >
> > > > %{?p:-P %p}
> > > >
> > > > (and there is complementing %{!?<var>:<expansion>} in RPM spec macro
> > > > language).
> > >
> > > Yes, this is overkill. I would even have passed the port argument
> > > _always_, since the port 22 for ssh is as likely to change as hell will
> > > not freeze over. Actually, I am not so sure about the latter.
> >
> > But keep in mind that "-p 22" on the command line _overrides_ what the
> > user has in their ssh config, so it is not a good idea to pass it all
> > the time.
>
> Oh, good point. So we might need something distasteful as what Jakub
> proposed... Hrmpf.
Two suggestions:
* Use %P as I suggested. I know it is kind of ugly, but I might still
consider it less ugly than adding full shell-style substitution to
the code. Especially considering that it would almost only have to be
used inside of Git. Users outside of the Git source would only very
seldomly have to touch it. (It would essentially only be those users
who both use alternative SSH ports *and* has an non-standard default
in their ssh_config *and* use a custom SSH command...)
* Put the SSH port number and host name in the environment and call
"/bin/sh -c" with the textual concatenation of the SSH command and
the command that Git wants to call. While a bit more ugly than
handling word splitting internally, I don't really think that it has
any real ill effects, seeing how the Git command is word-split on the
remote side anyhow (I think that has to be SSH's most stupid
"feature").
Fredrik Tolf
^ permalink raw reply
* Re: [GSoC] What is status of Git's Google Summer of Code 2008 projects?
From: Joshua Roys @ 2008-07-21 13:23 UTC (permalink / raw)
To: gittorrent; +Cc: Petr Baudis, Jakub Narebski, Sam Vilain, git
In-Reply-To: <20080721104032.GI32184@machine.or.cz>
Petr Baudis wrote:
> On Mon, Jul 21, 2008 at 12:23:45PM +0200, Jakub Narebski wrote:
>> [*1*] "the current implementation is quite slow (requiring two calls to
>> 'git-cat-file' for each object)" <-- why you don't use '--batch' or
>> '--batch-check' options to git cat file: see also Git::Repo and friends
>> implementation send by Lea Wiemann to git mailing list as part of
>> "Gitweb caching" project? BTW. by keeping discussion off the list,
>> you are off the knowledge of git community, too.
>
> I concur. Only now I realized that this project might be an important
> Git Perl API user. Can you please reconsider having a separate mailing
> list for discussions etc.? The traffic seems to be very low anyway, and
> I'm not sure what benefits does it actually have at all.
>
> Petr "Pasky" Baudis
Thank you for that suggestion! I made it call cat-file only once in
batch mode and it goes quite a bit faster now.
Josh
^ permalink raw reply
* Re: error: hook declined to update refs/heads/master
From: Dmitry Potapov @ 2008-07-21 13:24 UTC (permalink / raw)
To: Jonathan Biolaz; +Cc: Johannes Schindelin, git
In-Reply-To: <33E8E17B-D34A-4035-945A-CDB8A786A975@sikatizen.com>
On Mon, Jul 21, 2008 at 3:33 PM, Jonathan Biolaz
<jonathan.biolaz@sikatizen.com> wrote:
>
> So, what's a hook ?
http://www.kernel.org/pub/software/scm/git/docs/githooks.html
> and how I set the description ??
By editing .git/description file.
Dmitry
^ permalink raw reply
* Re: [PATCH] Rename ".dotest/" to ".git/rebase" and ".dotest-merge" to "rebase-merge"
From: Olivier Marin @ 2008-07-21 13:39 UTC (permalink / raw)
To: Junio C Hamano
Cc: Theodore Tso, Nanako Shiraishi, Johannes Schindelin,
René Scharfe, Stephan Beyer, Joe Fiorini, git, Jari Aalto
In-Reply-To: <7vd4l9zgmp.fsf@gitster.siamese.dyndns.org>
Junio C Hamano a écrit :
>
> Anything that changes "am" to require a clean working tree will NEVER be
> accepted. I personally rely on the ability for it to run in a dirty tree,
> so does Linus.
>
> Side note. Anything that changes "merge" to require a clean
> working tree is also unacceptable. Cf.
>
> http://thread.gmane.org/gmane.comp.version-control.git/9073/focus=9089
>
> Linus talks about "patch" in the paragraph second to the last one
> in the message; back then he was talking about "git-applymbox" but
> the same argument there applies to its newer incarnation "git-am".
>
> Side note #2. It would have been nice if "rebase" were also
> written in such a way that it can work in a dirty tree as long as
> local changes did not interfere with the operation, but it is a
> lot more involved.
Thanks for the explanation and the really interesting pointer.
The last thing that still annoy me is the --skip that refuse to skip in 3-way
merge. Perhaps we can use the "git read-tree --reset -u" thing for skip too.
So, what about the following patch?
-- >8 --
From: Olivier Marin <dkr@freesurf.fr>
git am --skip: clean the index while preserving local changes
In 3-way merge, "am" will let the index with unmerged path waiting
for us to resolve conflicts and continue. But if we want to --skip
instead, "am" refuses to continue because of the dirty index.
With this patch, "am" will clean the index without touching files
locally modified, before continue.
Signed-off-by: Olivier Marin <dkr@freesurf.fr>
---
git-am.sh | 12 +++++++++---
t/t4151-am-abort.sh | 11 +++++++++--
2 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index 60aaa4a..864c77e 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -202,8 +202,15 @@ then
die "previous rebase directory $dotest still exists but mbox given."
resume=yes
- case "$abort" in
- t)
+ case "$skip,$abort" in
+ t,)
+ git rerere clear
+ git read-tree --reset -u HEAD HEAD
+ orig_head=$(cat "$GIT_DIR/ORIG_HEAD")
+ git reset HEAD
+ git update-ref ORIG_HEAD $orig_head
+ ;;
+ ,t)
git rerere clear
git read-tree --reset -u HEAD ORIG_HEAD
git reset ORIG_HEAD
@@ -297,7 +304,6 @@ last=`cat "$dotest/last"`
this=`cat "$dotest/next"`
if test "$skip" = t
then
- git rerere clear
this=`expr "$this" + 1`
resume=
fi
diff --git a/t/t4151-am-abort.sh b/t/t4151-am-abort.sh
index dda7e2c..249093b 100755
--- a/t/t4151-am-abort.sh
+++ b/t/t4151-am-abort.sh
@@ -14,7 +14,7 @@ test_expect_success setup '
git add file-1 file-2 &&
git commit -m initial &&
git tag initial &&
- for i in 2 3 4 5
+ for i in 2 3 4 5 6
do
echo $i >>file-1 &&
test_tick &&
@@ -32,7 +32,7 @@ do
git reset --hard initial &&
cp file-2-expect file-2 &&
- test_must_fail git am$with3 000[124]-*.patch &&
+ test_must_fail git am$with3 000[1245]-*.patch &&
git log --pretty=tformat:%s >actual &&
for i in 3 2 initial
do
@@ -41,6 +41,13 @@ do
test_cmp expect actual
'
+ test_expect_success "am$with3 --skip continue after failed am$with3" '
+ test_must_fail git-am$with3 --skip >output &&
+ test "$(grep "^Applying" output)" = "Applying 6" &&
+ test_cmp file-2-expect file-2 &&
+ test ! -f .git/rr-cache/MERGE_RR
+ '
+
test_expect_success "am --abort goes back after failed am$with3" '
git-am --abort &&
git rev-parse HEAD >actual &&
--
1.5.6.4.570.g052e.dirty
^ permalink raw reply related
* Re: [PATCH] builtin-clone: Use is_dir_sep() instead of '/'
From: Kristian Høgsberg @ 2008-07-21 13:43 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Johannes Sixt, Junio C Hamano, git
In-Reply-To: <alpine.LNX.1.00.0807191333550.19665@iabervon.org>
On Sat, 2008-07-19 at 13:44 -0400, Daniel Barkalow wrote:
> On Sat, 19 Jul 2008, Johannes Sixt wrote:
>
> > On Samstag, 19. Juli 2008, Johannes Sixt wrote:
> > > On Samstag, 19. Juli 2008, Junio C Hamano wrote:
> > > > Ok, but the surrounding code in this function look very suspicious.
> > >
> > > How about this then?
> > >
> > > -- snip --
> > > builtin-clone: Rewrite guess_dir_name()
> > >
> > > The function has to do three small and independent tasks, but all of them
> > > were crammed into a single loop. This rewrites the function entirely by
> > > unrolling these tasks.
> >
> > Sigh. I knew it, I knew it. If it had been that trivial, then Daniel had done
> > it this way in the first place. :-(
> >
> > This needs to be squashed in. It makes sure that we handle 'foo/.git';
> > and .git was not stripped if we cloned from 'foo.git/'.
>
> I actually got that from Johannes Schindelin, who added bundle support to
> my clone patch. I remember looking at his change, thinking it looked
> overly complicated, but finding that anything I tried to do to simplify it
> failed tests. If this gets through the test suite (lots of the tests other
> than the clone test try to do a wider variety of odd things than I expect
> users do in practice most of the time), then it's probably a better
> implementation.
I wrote the original guess_git_dir(), and it *is* pretty subtle, sorry.
I would not rewrite it unless you really have to, since git clone now is
pretty stable and the dir sep separator change doesn't need this kind of
rewrite to fix the issue. That said, with the last couple of changes
from Johannes Sixt, I believe it handles the same case that I had in
mind when I first wrote the loop.
cheers,
Kristian
^ permalink raw reply
* [PATCH] git-am: remove dash from help message
From: Olivier Marin @ 2008-07-21 14:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
From: Olivier Marin <dkr@freesurf.fr>
Signed-off-by: Olivier Marin <dkr@freesurf.fr>
---
git-am.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index 864c77e..c0a1583 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -44,7 +44,7 @@ stop_here_user_resolve () {
printf '%s\n' "$resolvemsg"
stop_here $1
fi
- cmdline=$(basename $0)
+ cmdline="git am"
if test '' != "$interactive"
then
cmdline="$cmdline -i"
--
1.5.6.4.570.g052e.dirty
^ permalink raw reply related
* [PATCH] mailinfo: better parse email adresses containg parentheses
From: Philippe Bruhat (BooK) @ 2008-07-21 13:34 UTC (permalink / raw)
To: git; +Cc: Philippe Bruhat (BooK)
When using git-rebase, author fields containing a ')' at the last
position had the close-parens character incorrectly removed
because the From: parser incorrectly matched it as
user@host (User Name)
(removing parentheses), instead of
User Name (me) <user@host>
Signed-off-by: Philippe Bruhat (BooK) <book@cpan.org>
---
builtin-mailinfo.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index b99a5b6..5581c9f 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -115,10 +115,10 @@ static void handle_from(const struct strbuf *from)
* the () pair at the end.
*/
strbuf_trim(&f);
- if (f.buf[0] == '(')
+ if (f.buf[0] == '(' && f.len && f.buf[f.len - 1] == ')') {
strbuf_remove(&name, 0, 1);
- if (f.len && f.buf[f.len - 1] == ')')
strbuf_setlen(&f, f.len - 1);
+ }
get_sane_name(&name, &f, &email);
strbuf_release(&f);
--
1.5.4.3
^ permalink raw reply related
* Re: [PATCH] mailinfo: better parse email adresses containg parentheses
From: Lukas Sandström @ 2008-07-21 14:36 UTC (permalink / raw)
To: Philippe Bruhat (BooK); +Cc: git, Junio C Hamano
In-Reply-To: <1216647269-12287-1-git-send-email-book@cpan.org>
Philippe Bruhat (BooK) wrote:
> When using git-rebase, author fields containing a ')' at the last
> position had the close-parens character incorrectly removed
> because the From: parser incorrectly matched it as
>
> user@host (User Name)
>
> (removing parentheses), instead of
>
> User Name (me) <user@host>
>
> Signed-off-by: Philippe Bruhat (BooK) <book@cpan.org>
ACK.
> ---
> builtin-mailinfo.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
> index b99a5b6..5581c9f 100644
> --- a/builtin-mailinfo.c
> +++ b/builtin-mailinfo.c
> @@ -115,10 +115,10 @@ static void handle_from(const struct strbuf *from)
> * the () pair at the end.
> */
> strbuf_trim(&f);
> - if (f.buf[0] == '(')
> + if (f.buf[0] == '(' && f.len && f.buf[f.len - 1] == ')') {
> strbuf_remove(&name, 0, 1);
Note: The line above should obviously be "strbuf_remove(&f, 0, 1);",
another error from the strbuf conversion I made. Sigh.
> - if (f.len && f.buf[f.len - 1] == ')')
> strbuf_setlen(&f, f.len - 1);
> + }
>
> get_sane_name(&name, &f, &email);
> strbuf_release(&f);
/Lukas
^ permalink raw reply
* Re: Hacks for AIX
From: Brandon Casey @ 2008-07-21 15:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Chris Cowan, git
In-Reply-To: <7vd4l9c5ud.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>>> * /usr/bin/patch - really old version, doesn't do well with some
>>> diff formats. I avoid using it.
>> t4109 seems to use patch to produce expected output for the tests; we
>> should ship a precomputed expected results. Do you know of any other
>> places "patch" is used?
>
> As usual, I won't commit this patch unless I hear from people who
> potentially would benefit from it. I do not need such a patch myself and
> I really shouldn't be spending too much of my time on these.
Unless I'm doing something wrong, this doesn't apply cleanly to master.
> -- >8 --
> [PATCH] do not rely on external "patch" in tests
>
> Some of our tests assumed a working "patch" command to produce expected
> results when checking "git-apply", but some systems have broken "patch".
>
> We can compare our output with expected output that is precomputed
> instead to sidestep this issue.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> t/t4109-apply-multifrag.sh | 119 +++++++++++++++++++++++++++++++++++---------
> t/t4110-apply-scan.sh | 35 ++++++++++---
> 2 files changed, 123 insertions(+), 31 deletions(-)
>
> diff --git a/t/t4109-apply-multifrag.sh b/t/t4109-apply-multifrag.sh
> index bd40a21..4805863 100755
> --- a/t/t4109-apply-multifrag.sh
> +++ b/t/t4109-apply-multifrag.sh
> @@ -138,39 +138,112 @@ diff --git a/main.c b/main.c
The t4109-apply-multifrag.sh that I have only has 52 lines.
> EOF
It does not have this line above. Perhaps you also moved the
../t4109/patch*.patch files into the script in another commit?
-brandon
^ permalink raw reply
* [PATCH] builtin-merge: give a proper error message for invalid strategies in config
From: Miklos Vajna @ 2008-07-21 16:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Till now 'git merge -s foobar' bailed out with an error message, but
foobar in pull.twohead or pull.octopus was just silently ignored. It's
better to inform the user then just silently doing nothing.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
builtin-merge.c | 35 +++++++++++++++--------------------
t/t7601-merge-pull-config.sh | 6 ++++++
2 files changed, 21 insertions(+), 20 deletions(-)
diff --git a/builtin-merge.c b/builtin-merge.c
index e97c79e..5037acf 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -93,28 +93,13 @@ static void append_strategy(struct strategy *s)
use_strategies[use_strategies_nr++] = s;
}
+static void add_strategies(const char *string, unsigned attr);
+
static int option_parse_strategy(const struct option *opt,
const char *name, int unset)
{
- int i;
- struct strategy *s;
-
- if (unset)
- return 0;
-
- s = get_strategy(name);
-
- if (s)
- append_strategy(s);
- else {
- struct strbuf err;
- strbuf_init(&err, 0);
- for (i = 0; i < ARRAY_SIZE(all_strategy); i++)
- strbuf_addf(&err, " %s", all_strategy[i].name);
- fprintf(stderr, "Could not find merge strategy '%s'.\n", name);
- fprintf(stderr, "Available strategies are:%s.\n", err.buf);
- exit(1);
- }
+ if (!unset)
+ add_strategies(name, 0);
return 0;
}
@@ -639,7 +624,7 @@ static void split_merge_strategies(const char *string, struct strategy **list,
static void add_strategies(const char *string, unsigned attr)
{
struct strategy *list = NULL;
- int list_alloc = 0, list_nr = 0, i;
+ int list_alloc = 0, list_nr = 0, i, j;
memset(&list, 0, sizeof(list));
split_merge_strategies(string, &list, &list_nr, &list_alloc);
@@ -650,6 +635,16 @@ static void add_strategies(const char *string, unsigned attr)
s = get_strategy(list[i].name);
if (s)
append_strategy(s);
+ else {
+ struct strbuf err;
+
+ strbuf_init(&err, 0);
+ for (j = 0; j < ARRAY_SIZE(all_strategy); j++)
+ strbuf_addf(&err, " %s", all_strategy[j].name);
+ fprintf(stderr, "Could not find merge strategy '%s'.\n", list[i].name);
+ fprintf(stderr, "Available strategies are:%s.\n", err.buf);
+ exit(1);
+ }
}
return;
}
diff --git a/t/t7601-merge-pull-config.sh b/t/t7601-merge-pull-config.sh
index 95b4d71..ca63451 100755
--- a/t/t7601-merge-pull-config.sh
+++ b/t/t7601-merge-pull-config.sh
@@ -126,4 +126,10 @@ test_expect_success 'merge picks up the best result' '
test $auto_count != $resolve_count
'
+test_expect_success 'merge errors out on invalid strategy' '
+ git config pull.twohead "foobar" &&
+ git reset --hard c5 &&
+ test_must_fail git merge c6
+'
+
test_done
--
1.5.6.4.433.g09651.dirty
^ permalink raw reply related
* Re: making a branch with just one file and keeping its whole history
From: Eric Raible @ 2008-07-21 16:19 UTC (permalink / raw)
To: git
In-Reply-To: <20080721061804.223f7801@mail.tin.it>
<ncrfgs <at> tin.it> writes:
>
> Hi,
>
> I have a working local repository and I'd like to make a branch with just one
> file (let's say path2/filename2) and to keep its whole history.
http://www.gitcasts.com/posts/empty-branches
- Eric
^ permalink raw reply
* Re: Suggestion: doc restructuring
From: Junio C Hamano @ 2008-07-21 16:22 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Johannes Schindelin, Michael J Gruber, git
In-Reply-To: <48842FA8.5070309@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Junio C Hamano wrote:
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>>> So what I really would like is this: leave the plumbing pages as
>>> they are, but enhance those pages that users (especially new ones)
>>> are likely to see most often.
>>
>> Regarding the original "do we want to ever teach plumbing to new users?"
>> issue, I suspect that, with sufficient enhancement to Porcelain, we might
>> be able to reach a point where end users can work without ever touching a
>> single plumbing command at all.
>>
>> Side note, that was why I suggested us to first think about use
>> cases in our every day work that we still need to resort to the
>> plumbing, so that we can identify what that enhancement would
>> consist of.
>>
>
> Half a year or so ago, there were some mailings to the list along the lines
> of "what git commands do you use?", using the bash history and a shell
> oneliner to dig out some crude intel. Here's mine:
> cat ~/.bash_history | grep ^git | awk '{ print $2 }' | grep -v '^--' | sort | uniq --count | sort -nr
> 29 status
> 26 diff
> 19 show
> 17 log
> ...
While that stat might be interesting to look at, it does not have
much relevance to what I was suggesting.
^ permalink raw reply
* [PATCH] builtin-merge: missing structure bzero.
From: Pierre Habouzit @ 2008-07-21 17:03 UTC (permalink / raw)
To: git; +Cc: gitster, Pierre Habouzit
This cause segfaults when replacing a directory with a submodule in a
fast-forward.
Adds tests that revealed the issue, even if the second one isn't yet fixed for
another reason.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
In the process of writing a test for a problem with submodules that quite
bugs me so that I can fix it, I found a segfault that this patch fix.
The problem I tried to fix (hence I first wrote a test) is what happens
when you have in your repository a "dir/file.c" and that you replace
"dir/" witha submodule that also has a "file.c". git-merge pretends the
submodule checkout would clobber unversionned files, probably due to a too
late removal. anyways, that's for a next patch when I will understand the
root of this issue ;)
builtin-merge.c | 1 +
t/t7403-submodule-merge.sh | 62 ++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 63 insertions(+), 0 deletions(-)
create mode 100755 t/t7403-submodule-merge.sh
diff --git a/builtin-merge.c b/builtin-merge.c
index e97c79e..0ed1acf 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -580,6 +580,7 @@ static int checkout_fast_forward(unsigned char *head, unsigned char *remote)
memset(&trees, 0, sizeof(trees));
memset(&opts, 0, sizeof(opts));
memset(&t, 0, sizeof(t));
+ memset(&dir, 0, sizeof(dir));
dir.show_ignored = 1;
dir.exclude_per_dir = ".gitignore";
opts.dir = &dir;
diff --git a/t/t7403-submodule-merge.sh b/t/t7403-submodule-merge.sh
new file mode 100755
index 0000000..a803829
--- /dev/null
+++ b/t/t7403-submodule-merge.sh
@@ -0,0 +1,62 @@
+#!/bin/sh
+#
+# Copyright (c) 2008 Pierre Habouzit
+#
+
+test_description='Test merging with submodules'
+
+. ./test-lib.sh
+
+test_expect_success 'Setup a repository used as a submodule for other tests' '
+ mkdir submodule &&
+ cd submodule &&
+ git init &&
+ echo a > a &&
+ git add a &&
+ git commit -asm"submodule init" &&
+ cd ..
+'
+
+test_expect_success 'Replace a directory with a submodule, no file conflict' '
+ mkdir test &&
+ cd test &&
+ : create our repository with a sub/b file &&
+ git init &&
+ mkdir sub && echo b > sub/b &&
+ git add sub && git commit -asm"initial repository" &&
+ : save this state in a new branch &&
+ git branch temp &&
+ : then replace sub with it &&
+ git rm -rf sub &&
+ git submodule add -- "$(pwd)/../submodule/.git/" sub &&
+ git commit -asm "replace sub/ with a submodule" &&
+ : then try to update the "temp" branch &&
+ git checkout temp &&
+ git merge master &&
+ : and finally cleanse the mess &&
+ cd .. &&
+ rm -rf test
+'
+
+test_expect_failure 'Replace a directory with a submodule, with a file conflict' '
+ mkdir test &&
+ cd test &&
+ : create our repository with a sub/a file &&
+ git init &&
+ mkdir sub && echo a > sub/a &&
+ git add sub && git commit -asm"initial repository" &&
+ : save this state in a new branch &&
+ git branch temp &&
+ : then replace sub with it &&
+ git rm -rf sub &&
+ git submodule add -- "$(pwd)/../submodule/.git/" sub &&
+ git commit -asm "replace sub/ with a submodule" &&
+ : then try to update the "temp" branch &&
+ git checkout temp &&
+ git merge master &&
+ : and finally cleanse the mess &&
+ cd .. &&
+ rm -rf test
+'
+
+test_done
--
1.5.6.3
^ permalink raw reply related
* Re: [PATCH] builtin-merge: missing structure bzero.
From: Miklos Vajna @ 2008-07-21 17:21 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git, gitster
In-Reply-To: <1216659830-22063-1-git-send-email-madcoder@debian.org>
[-- Attachment #1: Type: text/plain, Size: 1015 bytes --]
On Mon, Jul 21, 2008 at 07:03:50PM +0200, Pierre Habouzit <madcoder@debian.org> wrote:
> This cause segfaults when replacing a directory with a submodule in a
> fast-forward.
Thanks.
> +test_expect_failure 'Replace a directory with a submodule, with a file conflict' '
> + mkdir test &&
> + cd test &&
> + : create our repository with a sub/a file &&
> + git init &&
> + mkdir sub && echo a > sub/a &&
> + git add sub && git commit -asm"initial repository" &&
> + : save this state in a new branch &&
> + git branch temp &&
> + : then replace sub with it &&
> + git rm -rf sub &&
> + git submodule add -- "$(pwd)/../submodule/.git/" sub &&
> + git commit -asm "replace sub/ with a submodule" &&
> + : then try to update the "temp" branch &&
> + git checkout temp &&
It seems this one fails. I guess this will be a problem in the low-level
merge code (read-tree -m) and not in builtin-merge.
> + git merge master &&
> + : and finally cleanse the mess &&
> + cd .. &&
> + rm -rf test
> +'
> +
> +test_done
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Git Branding Overview, Re: Git.or.cz Experimental Design
From: Jakub Narebski @ 2008-07-21 17:23 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <g61uun$lt0$1@ger.gmane.org>
Michael J Gruber <michaeljgruber+gmane@fastmail.fm> writes:
> Johannes Schindelin venit, vidit, dixit 21.07.2008 13:20:
>> On Mon, 21 Jul 2008, Michael J Gruber wrote:
>>>
>>> I like that new logo (plusminus G), too, it's very descriptive.
>>> I just want to raise one question which I can't answer myself:
>>> Are there any potential issues with the Helvetica license?
>>>
>>> In any case it may be safer do redo it with a GPL sans serif
>>> font. If one wants to keep the association of the shape of "G"
>>> with a circular arrow then FreeSans and Nimbus Sans L seem to be
>>> the only options.
GPL license for a _font_? Besides I think that _using_ font in
a work, as opposed to adding it to some software to use, is permitted
by any proprietary font license / trademark, but IANAL.
>>> Alternatively, it may be easier to redo it in plain PS. I'll
>>> attach 2 KISS variants. 1.5k for the eps, 3 colors only.
>>
>> You could have spared yourself the trouble:
>
> Thanks for the appreciation ;)
>
>> http://repo.or.cz/w/msysgit.git?a=blob_plain;f=share/resources/gitlogo.svg;h=c0d67e70ab31394f0635c141998e512437a138b4;hb=HEAD
>> Done without the use of any font at all.
>
> I don't think that was on the wiki before. Henrik's version (which
> was, and was being discussed here) *is* based on Helvetica.
Both SVG version mentioned above, and your logos can be now found at
http://git.or.cz/gitwiki/GitRelatedLogos (please correct any mistakes).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
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