* Re: git push bug?
From: Joakim Tjernlund @ 2007-10-18 16:10 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <1192723269.9433.21.camel@gentoo-jocke.transmode.se>
On Thu, 2007-10-18 at 18:01 +0200, Joakim Tjernlund wrote:
> On Thu, 2007-10-18 at 17:14 +0200, Steffen Prohaska wrote:
> > On Oct 18, 2007, at 4:50 PM, Joakim Tjernlund wrote:
> >
> > >
> > > I thougth I could create a new branch on the server using:
> > >
> > > # > git push ssh://devsrv/var/git/os2kernel.git linus:refs/linus
> > > Warning: No xauth data; using fake authentication data for X11
> > > forwarding.
> > > updating 'refs/linus' using 'refs/heads/linus'
> > > from 0000000000000000000000000000000000000000
> > > to bbf25010f1a6b761914430f5fca081ec8c7accd1
> > > Generating pack...
> > > Done counting 0 objects.
> > > Writing 0 objects...
> > > Total 0 (delta 0), reused 0 (delta 0)
> > > error: refusing to create funny ref 'refs/linus' locally
> > > ng refs/linus funny refname
> > > error: failed to push to 'ssh://devsrv/var/git/os2kernel.git'
> > >
> > > but that doesn't work. Am I doing this wrong?
> >
> > Include 'heads' in your remote refspec:
> >
> > git push ssh://devsrv/var/git/os2kernel.git linus:refs/heads/linus
>
> Now the push went OK:
> git push ssh://devsrv/var/git/os2kernel.git linus:refs/head/linus
> Warning: No xauth data; using fake authentication data for X11 forwarding.
> updating 'refs/head/linus' using 'refs/heads/linus'
> from 0000000000000000000000000000000000000000
> to bbf25010f1a6b761914430f5fca081ec8c7accd1
> Generating pack...
> Done counting 0 objects.
> Writing 0 objects...
> Total 0 (delta 0), reused 0 (delta 0)
> refs/head/linus: 0000000000000000000000000000000000000000 -> bbf25010f1a6b761914430f5fca081ec8c7accd1
>
> but there is no linus branch in the server repo!
>
> However:
> git push ssh://devsrv/var/git/os2kernel.git linus
>
> creates a linus branch in the server and
>
> git push ssh://devsrv/var/git/os2kernel.git :linus
> Warning: No xauth data; using fake authentication data for X11 forwarding.
> deleting 'refs/heads/linus'
> refs/heads/linus: bbf25010f1a6b761914430f5fca081ec8c7accd1 -> deleted
> Everything up-to-date
>
> deletes the linus branch on the server and so does
> git push ssh://devsrv/var/git/os2kernel.git :refs/heads/linus
>
> ahh, now I see. When creating the branch the refspec needs to be refs/heads/linus,
> not refs/head/linus
>
> refs/head/linus will create just that on the server. git branch does not look
> there, only in refs/heads
>
> Seems like it is a bit too easy to make mistakes here. Why can I delete
> a branch with :linus but not create one with linus:linus?
> Also confusing that git lets me create refs/head/linus when git branch
> cannot find it.
>
> Jocke
BTW this does not work either:
git reset --hard HEAD^
git push -f ssh://devsrv/var/git/os2kernel.git +master:master
updating 'refs/heads/master'
from 9c344d18d01221c8f25080cb58910e6b09efbf55
to 5761a9e5924b34615c748fba2dcb977ed04c1243
Generating pack...
Done counting 0 objects.
Writing 0 objects...
Total 0 (delta 0), reused 0 (delta 0)
error: denying non-fast forward refs/heads/master (you should pull first)
ng refs/heads/master non-fast forward
error: failed to push to 'ssh://devsrv/var/git/os2kernel.git'
I thought the + in +master:master and the -f option should let me
do that.
^ permalink raw reply
* Re: git push bug?
From: Steffen Prohaska @ 2007-10-18 16:13 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: git
In-Reply-To: <1192723269.9433.21.camel@gentoo-jocke.transmode.se>
On Oct 18, 2007, at 6:01 PM, Joakim Tjernlund wrote:
> Seems like it is a bit too easy to make mistakes here. Why can I
> delete
> a branch with :linus but not create one with linus:linus?
> Also confusing that git lets me create refs/head/linus when git branch
> cannot find it.
I absolutely agree. But I'm not sure if those who use git since the
ancient days do agree too.
Steffen
^ permalink raw reply
* Re: [BUG] git remote add failure
From: Johannes Schindelin @ 2007-10-18 16:09 UTC (permalink / raw)
To: Guido Ostkamp; +Cc: Git Mailing List
In-Reply-To: <1192697719.31199.1216526739@webmail.messagingengine.com>
Hi,
On Thu, 18 Oct 2007, Guido Ostkamp wrote:
> I think I've found a bug in "git remote add". I tried the following:
>
> $ git remote add -f spearce2 http://repo.or.cz/git/spearce.git
> Cannot get the repository state from http://repo.or.cz/git/spearce.git
> fetch spearce2: command returned error: 1
>
> Obviously I used the wrong URI. Then I tried again:
>
> $ git remote add -f spearce2 http://repo.or.cz/r/git/spearce.git
> remote spearce2 already exists.
>
> I think Git should not store the bad info and block the name when the
> first call wasn't successfull.
The problem there is of course that the fetch could fail because you are
offline. In that case, you do not want git remote to throw the
information away.
BTW you missed the trailing slash in the HTTP URL, I guess.
Ciao,
Dscho
^ permalink raw reply
* Re: git push bug?
From: Joakim Tjernlund @ 2007-10-18 16:01 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <0DAC53EF-021D-441C-9520-9795AAB6DE54@zib.de>
On Thu, 2007-10-18 at 17:14 +0200, Steffen Prohaska wrote:
> On Oct 18, 2007, at 4:50 PM, Joakim Tjernlund wrote:
>
> >
> > I thougth I could create a new branch on the server using:
> >
> > # > git push ssh://devsrv/var/git/os2kernel.git linus:refs/linus
> > Warning: No xauth data; using fake authentication data for X11
> > forwarding.
> > updating 'refs/linus' using 'refs/heads/linus'
> > from 0000000000000000000000000000000000000000
> > to bbf25010f1a6b761914430f5fca081ec8c7accd1
> > Generating pack...
> > Done counting 0 objects.
> > Writing 0 objects...
> > Total 0 (delta 0), reused 0 (delta 0)
> > error: refusing to create funny ref 'refs/linus' locally
> > ng refs/linus funny refname
> > error: failed to push to 'ssh://devsrv/var/git/os2kernel.git'
> >
> > but that doesn't work. Am I doing this wrong?
>
> Include 'heads' in your remote refspec:
>
> git push ssh://devsrv/var/git/os2kernel.git linus:refs/heads/linus
Now the push went OK:
git push ssh://devsrv/var/git/os2kernel.git linus:refs/head/linus
Warning: No xauth data; using fake authentication data for X11 forwarding.
updating 'refs/head/linus' using 'refs/heads/linus'
from 0000000000000000000000000000000000000000
to bbf25010f1a6b761914430f5fca081ec8c7accd1
Generating pack...
Done counting 0 objects.
Writing 0 objects...
Total 0 (delta 0), reused 0 (delta 0)
refs/head/linus: 0000000000000000000000000000000000000000 -> bbf25010f1a6b761914430f5fca081ec8c7accd1
but there is no linus branch in the server repo!
However:
git push ssh://devsrv/var/git/os2kernel.git linus
creates a linus branch in the server and
git push ssh://devsrv/var/git/os2kernel.git :linus
Warning: No xauth data; using fake authentication data for X11 forwarding.
deleting 'refs/heads/linus'
refs/heads/linus: bbf25010f1a6b761914430f5fca081ec8c7accd1 -> deleted
Everything up-to-date
deletes the linus branch on the server and so does
git push ssh://devsrv/var/git/os2kernel.git :refs/heads/linus
ahh, now I see. When creating the branch the refspec needs to be refs/heads/linus,
not refs/head/linus
refs/head/linus will create just that on the server. git branch does not look
there, only in refs/heads
Seems like it is a bit too easy to make mistakes here. Why can I delete
a branch with :linus but not create one with linus:linus?
Also confusing that git lets me create refs/head/linus when git branch
cannot find it.
Jocke
> You may need to cleanup though. I'm not sure if the remote side
> already created 'refs/linus'. The error message only indicates that
> locally git refused to create the "funny refname". Pushing a refspec
> with an empty local part should delete the "funny refname" on the
> remote:
>
> git push ssh://devsrv/var/git/os2kernel.git :refs/linus
>
> Did this solve your problem?
>
> Steffen
>
^ permalink raw reply
* Proposed git mv behavioral change
From: lmage11 @ 2007-10-18 15:47 UTC (permalink / raw)
To: git
Hey, all...
Based on a question I asked on freenode's #git channel a few days ago, it seems that most
people only use git
mv when the file they're moving is clean. Those that don't have become accustomed to the
behavior that git-mv
uses when the file is dirty - to pull all unstaged changes into the index. As far as I can tell,
this behavior is
largely historical. When git-mv was written in bash (or perl, or whatever it was initially written
in), it was most
convenient to implement it as "mv oldname newname; git add newname;", or something
similar, which would
result in pulling in all wd changes. However, it seems to me that this behavior violates git's
consistency. Usually
when I do something with git, I expect it to do only what it says it will do, and nothing more.
The
documentation for git-mv says "The index is updated after successful completion", but I
would tend to assume
that this was referring to the name change and not the change in the actual contents of the
file.
In my situation, I have some changes to a file that I'm not yet ready to commit. In the
meantime, I've started
working on another unrelated change that involves renaming one of the files which contain
unstaged changes.
I'd like to be able to perform this move without having my unstaged changes implicitly
staged without my
knowledge. When I want information put into the index, I either use git update-index if I
want to explicitly
stage an entire file or I use git add -i's patch command to explicitly stage individual chunks. I
like having very
fine-grained control over what goes into the index and what doesn't.
Therefore, I propose that git mv's behavior be changed. I think it would make far more sense
for a move to only
change the actual name of the file and to not pull in unstaged changes. In other words, I'd
like the index entry
for the original file name to be removed and an index entry to be added with a different
name, but using the
exact same blob hash as the original file. I don't know exactly how git manages the index
internally, but a
shortcut for this would be to simply rename the index entry in place.
I'm willing to look into what changes would need to be made to the code for this change to
happen; I'm not
asking for someone to do all the work for me. :)
So... Yeah. I'd like to know what people think about this before I put a significant amount of
effort into it. After
all, we know how lazy programmers are... :)
Thanks,
Ari
^ permalink raw reply
* Re: [PATCH] Remove link to the survey from the git home page.
From: Paolo Ciarrocchi @ 2007-10-18 15:30 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: pasky, git
In-Reply-To: <2c6b72b30710180525s3924c720rb7cb715dc7b43c3b@mail.gmail.com>
On 10/18/07, Jonas Fonseca <jonas.fonseca@gmail.com> wrote:
> On 10/16/07, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
> > As far as I know the survey is close so it makes sense to remove the link/text from the home page.
>
> Pasky has provided me with write access to git-homepage.git and to test
> the setup I have applied this change, which seemed to have been overlooked.
>
> Pasky, maybe you can update git.or.cz and perhaps also remove the link
> from the front page of repo.or.cz? :)
Pasky, Jonas,
I cannot enter IRC at the moment so I'm sending here a note with my proposal.
I recently got interested in drupal and I wondered whether it would a
good idea to try to play in a sandbox with a drupal installation and
somehow compare the actual static homepage with an alternative drupal
based portal.
What do you think?
Regards,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
^ permalink raw reply
* Re: git push bug?
From: Steffen Prohaska @ 2007-10-18 15:14 UTC (permalink / raw)
To: joakim.tjernlund; +Cc: git
In-Reply-To: <1192719040.9433.5.camel@gentoo-jocke.transmode.se>
On Oct 18, 2007, at 4:50 PM, Joakim Tjernlund wrote:
>
> I thougth I could create a new branch on the server using:
>
> # > git push ssh://devsrv/var/git/os2kernel.git linus:refs/linus
> Warning: No xauth data; using fake authentication data for X11
> forwarding.
> updating 'refs/linus' using 'refs/heads/linus'
> from 0000000000000000000000000000000000000000
> to bbf25010f1a6b761914430f5fca081ec8c7accd1
> Generating pack...
> Done counting 0 objects.
> Writing 0 objects...
> Total 0 (delta 0), reused 0 (delta 0)
> error: refusing to create funny ref 'refs/linus' locally
> ng refs/linus funny refname
> error: failed to push to 'ssh://devsrv/var/git/os2kernel.git'
>
> but that doesn't work. Am I doing this wrong?
Include 'heads' in your remote refspec:
git push ssh://devsrv/var/git/os2kernel.git linus:refs/heads/linus
You may need to cleanup though. I'm not sure if the remote side
already created 'refs/linus'. The error message only indicates that
locally git refused to create the "funny refname". Pushing a refspec
with an empty local part should delete the "funny refname" on the
remote:
git push ssh://devsrv/var/git/os2kernel.git :refs/linus
Did this solve your problem?
Steffen
^ permalink raw reply
* git push bug?
From: Joakim Tjernlund @ 2007-10-18 14:50 UTC (permalink / raw)
To: git
I thougth I could create a new branch on the server using:
# > git push ssh://devsrv/var/git/os2kernel.git linus:refs/linus
Warning: No xauth data; using fake authentication data for X11 forwarding.
updating 'refs/linus' using 'refs/heads/linus'
from 0000000000000000000000000000000000000000
to bbf25010f1a6b761914430f5fca081ec8c7accd1
Generating pack...
Done counting 0 objects.
Writing 0 objects...
Total 0 (delta 0), reused 0 (delta 0)
error: refusing to create funny ref 'refs/linus' locally
ng refs/linus funny refname
error: failed to push to 'ssh://devsrv/var/git/os2kernel.git'
but that doesn't work. Am I doing this wrong?
git 1.5.3.4
Jocke
^ permalink raw reply
* Subversion developer: svn is for dumb people
From: Steven Grimm @ 2007-10-18 14:25 UTC (permalink / raw)
To: 'git'
Thought folks here might get a kick out of this:
http://blog.red-bean.com/sussman/?p=79
Okay, my summary is slightly facetious, but that's basically the gist of
what he's saying: you should choose Subversion rather than a DVCS
because most of your users won't be smart enough to use the better tool.
I can't say he's completely wrong, especially about the 20/80% idea
(though I think "20%" is generous), but some of his specific arguments
about DVCS are on the bogus side. "Centralized systems encourage code
reviews," for one -- I challenge him to find a project with a more
pervasive and effective code-reviewing culture than the git project. I
find code reviews *harder* in a centralized system because you end up
building external tools to help people try out each other's changes.
-Steve
^ permalink raw reply
* Re: [PATCH] Add a message explaining that automatic GC is about to start
From: Nicolas Pitre @ 2007-10-18 14:21 UTC (permalink / raw)
To: Brian Gernhardt
Cc: koreth, Jeff King, Linus Torvalds, Luke Lu, Christer Weinigel,
Tom Tobin, git
In-Reply-To: <3391BADA-B5B4-4A8E-A6C0-42169AFC0331@silverinsanity.com>
On Thu, 18 Oct 2007, Brian Gernhardt wrote:
>
> On Oct 18, 2007, at 12:41 AM, koreth@midwinter.com wrote:
>
> > And as an added bonus, we can tell people how to turn off automatic GC
> > and how to invoke it by hand.
>
> > + fprintf(stderr, "Packing your repository for optimum "
> > + "performance. If you would rather run\n"
> > + "\"git gc\" by hand, run \"git config gc.auto 0\" "
> > + "to disable automatic cleanup.\n");
>
> I'm not sure telling the users how to disable it every time it shows up is a
> good idea. gc --auto exists for the naive user, and suggesting they turn it
> off each time it happens will just result in... people turning it off,
> leading back to the performance issues that caused the feature to be installed
> in the first place. Perhaps a message more along the lines of "To avoid this,
> run "git gc" manually on a regular basis. See 'git help gc' for more
> information."
This is indeed a good point.
And for those who start repacking manually then the automatic repacking
will very rarely trigger, reducing the need for turning automatic
repacking off anyway.
Nicolas
^ permalink raw reply
* Re: [PATCH] Add a message explaining that automatic GC is about to start
From: Steven Grimm @ 2007-10-18 14:16 UTC (permalink / raw)
To: Brian Gernhardt
Cc: Jeff King, Linus Torvalds, Luke Lu, Christer Weinigel, Tom Tobin,
git
In-Reply-To: <3391BADA-B5B4-4A8E-A6C0-42169AFC0331@silverinsanity.com>
Brian Gernhardt wrote:
> I'm not sure telling the users how to disable it every time it shows
> up is a good idea. gc --auto exists for the naive user, and
> suggesting they turn it off each time it happens will just result
> in... people turning it off, leading back to the performance issues
> that caused the feature to be installed in the first place. Perhaps a
> message more along the lines of "To avoid this, run "git gc" manually
> on a regular basis. See 'git help gc' for more information."
That's a good point. Jeff / Shawn, do you agree with that? I'll come up
with an alternate patch if so.
-Steve
^ permalink raw reply
* Re: git stash apply usability issues
From: Steven Grimm @ 2007-10-18 14:12 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
In-Reply-To: <47171A21.9030003@viscovery.net>
Johannes Sixt wrote:
> (2) when 'git stash apply' runs merge-recursive, it treats the current
> state as 'ours' and the stash as 'theirs'. IMHO it should be the other
> way round: I have stashed away changes to a binary file. Then
> committed a different modification to it, and now want to apply the
> stash. This results in a conflict that leaves the current state in the
> working tree, but I had preferred that the stashed binary file were in
> the working tree now.
>
> What do other git-stash users think about changing the order?
Seems right to me. I'd expect to get the stashed version in the working
tree in that case.
-Steve
^ permalink raw reply
* Re: [PATCH] Add a message explaining that automatic GC is about to start
From: Brian Gernhardt @ 2007-10-18 13:52 UTC (permalink / raw)
To: koreth
Cc: Jeff King, Linus Torvalds, Luke Lu, Christer Weinigel, Tom Tobin,
git
In-Reply-To: <20071018044143.GA24043@midwinter.com>
On Oct 18, 2007, at 12:41 AM, koreth@midwinter.com wrote:
> And as an added bonus, we can tell people how to turn off automatic GC
> and how to invoke it by hand.
> + fprintf(stderr, "Packing your repository for optimum "
> + "performance. If you would rather run\n"
> + "\"git gc\" by hand, run \"git config gc.auto 0\" "
> + "to disable automatic cleanup.\n");
I'm not sure telling the users how to disable it every time it shows
up is a good idea. gc --auto exists for the naive user, and
suggesting they turn it off each time it happens will just result
in... people turning it off, leading back to the performance issues
that caused the feature to be installed in the first place. Perhaps
a message more along the lines of "To avoid this, run "git gc"
manually on a regular basis. See 'git help gc' for more information."
~~ Brian
^ permalink raw reply
* Re: [QGIT4 PATCH] Add --no-color option to several calls to git
From: Yaacov Akiba Slama @ 2007-10-18 13:41 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550710171638l26d3e55ej9dc8b38f8aee7592@mail.gmail.com>
Marco Costalba wrote:
> Could you please confirm me that with this patch qgit works flawless
> for you when "diff.color = true", I' m worried to push a new point
> release just to discover we need to fix some more.
>
I can confirm that at least the basic operations are working for me
with several repositories.
But I wonder if it's not better to add to git the support of a
GIT_COLORS environment variable which would be set for instance to :
diff=false:branch=false:status=false
in gitk, qgit and other frontends.
--yas
^ permalink raw reply
* Re: [PATCH] Use exit 1 instead of die when req_Root fails.
From: Frank Lichtenheld @ 2007-10-18 13:33 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Brian Gernhardt, git
In-Reply-To: <20071018050456.GD14735@spearce.org>
On Thu, Oct 18, 2007 at 01:04:56AM -0400, Shawn O. Pearce wrote:
> Brian Gernhardt <benji@silverinsanity.com> wrote:
> > On Oct 17, 2007, at 3:06 PM, Frank Lichtenheld wrote:
> >
> > >I have this in my repo and will submit this with the other git-
> > >cvsserver
> > >changes. I was just waiting for either Junio to return or someone else
> > >stepping up.
> >
> > Ah. I had missed that. I just dug up the patch when switching to
> > Shawn's repo gave me those old testing errors. Had thought it had
> > gotten lost in the shuffle.
>
> It did. I have your resubmit that started this thread in my INQ and
> will try to get to it today. But if Frank has a queue of stuff I've
> missed I'd like a pointer to it so I can also try to start working
> through it. I know I also have some other topics that Lars Hjemli
> accumlated in his tree that I still need to cherry-pick over into
> mine, but I don't see the one we are talking about in there.
Yeah, I postponed sending it to tomorrow for some days now :/
Anyway, my current queue is visible at
git://source.djpig.de/git/git-cvsserver.git cvsserver
So you can fetch and merge/cherry-pick it yourself if you prefer.
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: [BUG] git-svn not following svn moves
From: cho @ 2007-10-18 13:11 UTC (permalink / raw)
To: git
In-Reply-To: <20071018121328.GA5358@xp.machine.xx>
Le Thu, 18 Oct 2007 14:13:28 +0200, Peter Baumann a écrit :
> Any chance you could provide a testcase which is similar to what
> happened in your private repo so that the problem could be reproduced
> here?
I've surprised myself but yes, there is a simple testcase.
svnadmin create repo
svn checkout file://$PWD/repo checkout
cd checkout/
svn mkdir trunk tags branches
svn ci -m 'Standard svn layout.'
cd trunk/
svn mkdir doc
touch doc/README
svn add doc/README
svn ci -m 'Add README.'
cd ..
svn mv trunk/ branches/oldtrunk
svn ci -m 'Moved trunk.'
svn mkdir trunk
svn ci -m 'New trunk.'
cd trunk/
touch THIS_IS_THE_NEW_TRUNK
svn add THIS_IS_THE_NEW_TRUNK
svn ci -m 'Add marker.'
cd ../..
git svn clone file://$PWD/repo --stdlayout git-clone
cd git-clone/
tree
So the testcase basically involves moving the trunk.
git-svn gets very confused and keeps a mixture of the old and new trunk.
^ permalink raw reply
* Re: Cloning an StGit repository
From: Karl Hasselström @ 2007-10-18 12:51 UTC (permalink / raw)
To: Rajkumar S; +Cc: Git Mailing List
In-Reply-To: <64de5c8b0710180456x24031754od7062d504e72b215@mail.gmail.com>
On 2007-10-18 17:26:48 +0530, Rajkumar S wrote:
> git --bare fetch ../stg_branch my_branch02:my_branch02
> my_branch02:my_branch02 my_branch01:my_branch01 master:master
[...]
> It says
> * refs/heads/my_branch02: not updating to non-fast forward branch
> 'my_branch02' of ../stg_branch
>
> my_branch02 is the StGit managed branch from stg_branch, other
> normal branchs are getting merged. Since this is StGit managed, fast
> forward merge is not possible, I guess. So how can I pull in the
> StGit managed changes to web.git repository?
Either prefix each of the refspects with a + (as in
+my_branch01:my_branch01), or use the -f flag (which has the same
effect as using + on all the refspecs). This will allow the refs to be
overwritten even if it's not a fast-forward.
You have to do this with StGit-managed branches, since StGit is
essentially just a convenient way to rebase commits.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] Remove link to the survey from the git home page.
From: Petr Baudis @ 2007-10-18 12:46 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Paolo Ciarrocchi, git
In-Reply-To: <2c6b72b30710180525s3924c720rb7cb715dc7b43c3b@mail.gmail.com>
On Thu, Oct 18, 2007 at 02:25:15PM +0200, Jonas Fonseca wrote:
> On 10/16/07, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
> > As far as I know the survey is close so it makes sense to remove the link/text from the home page.
>
> Pasky has provided me with write access to git-homepage.git and to test
> the setup I have applied this change, which seemed to have been overlooked.
>
> Pasky, maybe you can update git.or.cz and perhaps also remove the link
> from the front page of repo.or.cz? :)
Done.
Please poke me on IRC whenever you need.
--
Petr "Pasky" Baudis
Early to rise and early to bed makes a male healthy and wealthy and dead.
-- James Thurber
^ permalink raw reply
* Re: [PATCH 2/2] filter-branch: update current branch when rewritten
From: Bill Lear @ 2007-10-18 12:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, spearce, gitster
In-Reply-To: <Pine.LNX.4.64.0710170322400.25221@racer.site>
On Wednesday, October 17, 2007 at 03:23:10 (+0100) Johannes Schindelin writes:
>
>Earlier, "git filter-branch --<options> HEAD" would not update the
>working tree after rewriting the branch. This commit fixes it.
>
>Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>---
>
> Bill, I hope this clarifies some things for you, too...
Thanks very much. I hope so, too. I'll pull this in to my tree
when it gets into the git repository (how do I know when that happens,
or do I just need to pull and inspect?).
Bill
^ permalink raw reply
* Re: [PATCH] Remove link to the survey from the git home page.
From: Jonas Fonseca @ 2007-10-18 12:25 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: pasky, git
In-Reply-To: <20071016235714.190672ff@paolo-desktop>
On 10/16/07, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
> As far as I know the survey is close so it makes sense to remove the link/text from the home page.
Pasky has provided me with write access to git-homepage.git and to test
the setup I have applied this change, which seemed to have been overlooked.
Pasky, maybe you can update git.or.cz and perhaps also remove the link
from the front page of repo.or.cz? :)
--
Jonas Fonseca
^ permalink raw reply
* Re: [BUG] git-svn not following svn moves
From: Peter Baumann @ 2007-10-18 12:13 UTC (permalink / raw)
To: cho; +Cc: git
In-Reply-To: <ff7fhg$2eu$1@ger.gmane.org>
On Thu, Oct 18, 2007 at 11:20:16AM +0000, cho wrote:
> Hello,
>
> I have a git-svn checkout that apparently did not follow a move correctly.
> The files are not present in an svn checkout, but are in a git svn clone.
>
> According to a trac browser, some of the files that appear in my git
> checkout had in fact been moved to their separate branch before doing git-
> svn clone. I noticed this when trying to commit changes to those files,
> getting the error message:
> > Le système de fichiers ne contient pas cet élément: Fichier non
> trouvé : transaction '3926-1', chemin '.../composants.py' at /home/marc/
> bin/git-svn line 2960
> It's a standard subversion error, "Filesystem has no item"
>
> I've made a clean checkout (with today's 1.5.3.4.206.g58ba4), and I still
> have the moved files present.
> The clone command is just:
> git svn clone --stdlayout svn+ssh://host/srv/subversion/proj/appli/proj
>
> Tell me if I can give more info (the repository isn't public).
>
Any chance you could provide a testcase which is similar to what happened
in your private repo so that the problem could be reproduced here?
-Peter
^ permalink raw reply
* Cloning an StGit repository
From: Rajkumar S @ 2007-10-18 11:56 UTC (permalink / raw)
To: Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 2124 bytes --]
Hi all,
My group is following a remote git repository, and we have some
custom private patches, our development is on top of our custom
patches. So our ideal work flow is to
1. Clone the upstream to a local repo (for our reference of upstream work)
2. Clone the local repo to an StGit repo, with our custom patches
3. StGit repo is fetched with git --bare fetch (for git-web)
3. All of us clone from git-web repo and hack on individual branches
4. Once a feature is locally developed and tested, it's added to
StiGit repo as a patch.
5. We periodically pull from upstream to local StGit repo for updates
When I try this work flow, changes made in Stgit is not getting
reflected in the git-web repository
git --bare fetch ../stg_branch my_branch02:my_branch02
my_branch02:my_branch02 my_branch01:my_branch01 master:master
remote: Generating pack...
remote: Done counting 33 objects.
Result has 21 objects.
Deltifying 21 objects...
100% (21/21) donemote: ne
Total 21 (delta 11), reused 0remote: (delta 0)
Unpacking 21 objects...
100% (21/21) done
* refs/heads/my_branch02: not updating to non-fast forward branch
'my_branch02' of ../stg_branch
old...new: 64609a4...322d3bf
* refs/heads/my_branch01: fast forward to branch 'my_branch01' of ../stg_branch
old..new: 35a22b1..2fb9b65
* refs/heads/master: fast forward to branch 'master' of ../stg_branch
old..new: 464a9b4..1754e61
It says
* refs/heads/my_branch02: not updating to non-fast forward branch
'my_branch02' of ../stg_branch
my_branch02 is the StGit managed branch from stg_branch, other normal
branchs are getting merged. Since this is StGit managed, fast forward
merge is not possible, I guess. So how can I pull in the StGit managed
changes to web.git repository?
I have made a script of the testing I have done, and attaching it as a
file. It can be run as such in a directory, where it will create some
git and stgit repositories, illustrating the problem.
In the script upstream is my upstream, stg_branch is stgit managed
branch, web.git is for git-web, my-project is cloned from web.git and
my-project-stgit is cloned from stg_branch.
raj
[-- Attachment #2: stgit_test-1.sh --]
[-- Type: application/x-sh, Size: 7118 bytes --]
^ permalink raw reply
* Re: On Tabs and Spaces
From: Nikolai Weibull @ 2007-10-18 11:39 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jari Aalto, git
In-Reply-To: <20071018113442.GO18279@machine.or.cz>
On 10/18/07, Petr Baudis <pasky@suse.cz> wrote:
> On Thu, Oct 18, 2007 at 11:19:48AM +0300, Jari Aalto wrote:
> > [1] 99 % of the projects do not use Kernel's 8-wide indentation
> > convention.
> 99 % of the list participants sorely wish this thread would die already.
To change the subject, let me point out that the percent symbol should
be juxtaposed with the number, that is, write "99%", not "99 %", in
English.
;-)
^ permalink raw reply
* Re: On Tabs and Spaces
From: Petr Baudis @ 2007-10-18 11:34 UTC (permalink / raw)
To: Jari Aalto; +Cc: git
In-Reply-To: <abqgltqz.fsf@blue.sea.net>
On Thu, Oct 18, 2007 at 11:19:48AM +0300, Jari Aalto wrote:
> [1] 99 % of the projects do not use Kernel's 8-wide indentation
> convention.
99 % of the list participants sorely wish this thread would die already.
Petr "Pasky" Baudis
^ permalink raw reply
* Re: Howto request: going home in the middle of something?
From: Andy Parkins @ 2007-10-18 11:29 UTC (permalink / raw)
To: git; +Cc: Jan Wielemaker
In-Reply-To: <200710181144.22655.wielemak@science.uva.nl>
On Thursday 2007 October 18, Jan Wielemaker wrote:
> I've somewhere seen it in a mail, but I can't find it anymore. I have a
> bare central (public) repository and clones on various machines I work
> on. We all know it, you're right in the middle of something and it is
> really time to go home. You want to pick up your work at home, but
> without pushing to the shared repository.
>
> I'm sure GIT can do this elegantly, but I'm not yet sure how. I guess
> Ideally I want "git stash" at work, transfer the stashed changes to my
> other machine and apply them. How do I do that?
>
> Alternatively, I guess, one can commit at machine A, fetch the commit
> from machine A and continue. I'm still too uncertain about the remote
> access options to work this out properly, but it also feels less
> clean.
>
> How do you deal with this?
I have two remotes (typically) in my .git/config. One for the real central
repository and one for the alternate computer. The two locations (say home
and work) list the other as a remote.
So; before I go home I do this:
git commit -b temp -a -m "Hold for transport home"
Then when I get home I do this:
git fetch work
git merge work/temp
git reset HEAD^
# code code code
git commit -b temp -a -m "Hold for transport to work"
When I'm finished at home and want to carry on at work:
git fetch --force home
git merge home/temp
git reset HEAD^
# start coding for the day
Obviously if you do this repeatedly you'd need to tidy up the left over temp
branches, or ensure that your remote configurations list "+" in the fetch
lines. You can also use pushes instead of fetches if you're that way
inclined, or you have a connection problem in one direction because of a
firewall.
It's slightly inelegant but it does ensure that nothing is ever accidentally
lost by overwriting new with newer, which happened a few times in the days
when I used rsync for copying the working directory between computers.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ 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