* Re: Application to install man pages.
From: Shawn O. Pearce @ 2007-10-19 1:16 UTC (permalink / raw)
To: Evan Carroll; +Cc: git
In-Reply-To: <428b865e0710181159i7a12f2b7y22619f0eaf36d2c1@mail.gmail.com>
Evan Carroll <me@evancarroll.com> wrote:
> This is a one liner but might help for simply a quick install of the
> git manpages.
...
> +#/bin/sh
> + cp -R --copy-contents ./man* /usr/local/man
> --
Isn't this covered by the "make -C Documentation quick-install"?
Which is what "make quick-install-doc" does in the top level Makefile.
--
Shawn.
^ permalink raw reply
* [PATCH] git-gc: improve wording of --auto notification
From: Jeff King @ 2007-10-19 1:12 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Steven Grimm, Brian Gernhardt, git
In-Reply-To: <20071019001648.GO14735@spearce.org>
The previous message had too much of a "boy, you should
really turn off this annoying gc" flair to it. Instead,
let's make sure the user understands what is happening, that
they can run it themselves, and where to find more info.
Suggested by Brian Gernhardt.
Signed-off-by: Jeff King <peff@peff.net>
---
Shawn said:
> A patch against spearce/master to revert the prior message and insert
> something that is perhaps more reasonable would be most appreciated.
Geez, you really _are_ the maintainer now, prodding your minions to
write trivial patches for you. :) I don't see any point in reverting the
other patch separately, since we can just improve the message.
I tried not to use the word "avoid" since I think we don't want to imply
that auto-gc sucks. It doesn't, but some people might prefer to run it
manually, and we should let them know it's an option. I'm open to
wording improvements.
builtin-gc.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin-gc.c b/builtin-gc.c
index f99b212..3a2ca4f 100644
--- a/builtin-gc.c
+++ b/builtin-gc.c
@@ -206,9 +206,9 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
if (!need_to_gc())
return 0;
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");
+ "performance. You may also\n"
+ "run \"git gc\" manually. See "
+ "\"git help gc\" for more information.\n");
} else {
/*
* Use safer (for shared repos) "-A" option to
--
1.5.3.4.1249.g895be-dirty
^ permalink raw reply related
* Re: git-merge: need a tap with the cluestick, please
From: walt @ 2007-10-19 1:00 UTC (permalink / raw)
To: git
In-Reply-To: <20071018233518.GL14735@spearce.org>
Shawn O. Pearce wrote:
> walt <wa1ter@myrealbox.com> wrote:
>> Now when I pull from Linus the merge stops in the middle because of
>> conflicts with my .gitignore file <sigh>. Anything I try now with
>> git-merge tells me I can't do that in the middle of a conflicted
>> merge. Yes, I know that now, but what should I do instead?
>>
>> I could move my 'obj' out-of-tree but then I wouldn't learn anything.
>> This has to be bone-head easy, but not for me :)
>
> How about putting the ignore for your obj dir in your own private
> exclude file:
>
> $ echo /obj >>.git/info/exclude
>
> will cause Git to ignore an "obj" directory if it is found in the
> top level of the repository. And since this file is not actually
> tracked as part of the repository it will apply to all branches
> in this repository and won't cause merge conflicts when upstream
> makes changes to .gitignore.
Thanks to both you and Lars, who gave me the same advice off-list.
I will do exactly that.
Just to illustrate how much of life depends on blind luck, both good
and bad, I'll explain what really got me in trouble here. On the
very first pull from Linus after I added my obj directory to
.gitignore -- I pulled this commit:
commit 9e447a7f1fd997bcb9266899e777c37469245365
Author: Denis V. Lunev <den@openvz.org>
Date: Tue Oct 16 11:22:21 2007 +0400
.gitignore update for x86 arch
This patch: - makes .gitignore files visible to git
I'd like to think that if I'd made my changes on *any* other day
but yesterday I wouldn't have been so completely confused by what
happened. (But perhaps I flatter myself :o)
Thanks again.
^ permalink raw reply
* Re: Qgit performance and maintain CVS environment with GIT repository
From: Johannes Schindelin @ 2007-10-19 0:50 UTC (permalink / raw)
To: Pete/Piet Delaney
Cc: Marco Costalba, Robin Rosenberg, piet.delaney, Linus Torvalds,
VMiklos, free cycle, git, piet.delaney, Piet Delaney
In-Reply-To: <4717F8CF.9060103@bluelane.com>
Hi,
On Thu, 18 Oct 2007, Pete/Piet Delaney wrote:
> I'll try the git-cvsserver path. If anyone has any war stories to share
> on the path this would be an ideal time to share them.
I was responsible for a medium long running CVS repository, and I wanted
to switch to git. For a long time, I just ran tests and tried to flesh
out things, and eventually went for it.
A few of the patches to git-cvsserver from me were direct results of
problems we ran to. But mind you, that was almost over a year ago.
In the meantime, many of my developers switched. Some because it was
easier than waiting for me to fix the bugs with the cvs server.
Some because they saw me working with git.
I still do not know why the third group switched.
Now I have exactly one dev left, who refuses to use anything else than
cvs. Fine with me. I can live with other people using inferiour programs
than myself.
I even patched cvsserver not to print the "committed using git-cvsserver"
message locally.
But then, I was never a cvs "power" user. Only a git power user.
Ciao,
Dscho
^ permalink raw reply
* Re: git push bug?
From: Shawn O. Pearce @ 2007-10-19 0:49 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Steffen Prohaska, git
In-Reply-To: <1192723847.9433.25.camel@gentoo-jocke.transmode.se>
Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> 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.
Yes, but its only on the client side.
See when we do a push the local client side determines if the push is
going to be a fast-forward or not. If it isn't then the git-push
client aborts before it even uploads data to the remote side.
The --force or + can be used to make the client side skip this
check and just plow forward anyway.
But the remote side can also veto a non-fast-forward update. By
default it refuses to allow such updates as they can orphan commits
(and thus potentially lose important work). See the config option
receive.denyNonFastForwards; you may want to set this to true in
the remote side's config file.
--
Shawn.
^ permalink raw reply
* [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'
From: Shawn O. Pearce @ 2007-10-19 0:45 UTC (permalink / raw)
To: git; +Cc: Nicolas Pitre
Recently I was referred to the Grammar Police as the git-pack-objects
progress message 'Deltifying %u objects' is considered to be not
proper English to at least some small but vocal segment of the
English speaking population. Techncially we are applying delta
compression to these objects at this stage, so the new term is
slightly more acceptable to the Grammar Police but is also just
as correct.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
To go on top of your 'np/progress' series that is currently in next.
I think it might keep us out of trouble with certain individuals...
builtin-pack-objects.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 15d3750..f79fc0b 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -1718,7 +1718,7 @@ static void prepare_pack(int window, int depth)
if (nr_deltas && n > 1) {
unsigned nr_done = 0;
if (progress)
- start_progress(&progress_state, "Deltifying objects",
+ start_progress(&progress_state, "Delta compressing objects",
nr_deltas);
qsort(delta_list, n, sizeof(*delta_list), type_size_sort);
ll_find_deltas(delta_list, n, window+1, depth, &nr_done);
--
1.5.3.4.1249.g895be
^ permalink raw reply related
* Re: Qgit performance and maintain CVS environment with GIT repository
From: Jeff King @ 2007-10-19 0:41 UTC (permalink / raw)
To: Pete/Piet Delaney
Cc: Johannes Schindelin, Marco Costalba, Robin Rosenberg,
piet.delaney, Linus Torvalds, VMiklos, free cycle, git,
piet.delaney, Piet Delaney
In-Reply-To: <4717F8CF.9060103@bluelane.com>
On Thu, Oct 18, 2007 at 05:22:39PM -0700, Pete/Piet Delaney wrote:
> I've got root access on the CVS server and want to switch to git without
> disturbing the environment more than is necessary to make the switch.
> I think developers will want to us git and git-cvsserver looks like
> the more likely desirable path.
Depending on the environment and the willingness of people to change to
git, it might be worth moving slowly and keeping the backend as CVS at
first. I.e., keep the "official" repository as CVS, and let some devs
start moving to access through git-cvsimport and git-cvsexportcommit
(and maybe even provide an official git repo which is backed by the CVS
repo, so that all of the import/export happens in one place). That will
give them time to get used to git, give those who are resistant to the
change their original interface, and if anything goes wrong, you can
always fall back to the "old" way.
And then when everything seems to be going well, swap it. Make git the
official repo, but provide a "legacy" CVS access for the die-hards
(using git-cvsserver).
And then eventually just shut off CVS access entirely (when everyone is
happier using git).
Of course none of that is necessary, but one of the nice things about
git is how it can integrate with existing setups, so you can really ease
into a transition without investing a lot of resources.
-Peff
^ permalink raw reply
* Re: Splitting a repository
From: Jeff King @ 2007-10-19 0:33 UTC (permalink / raw)
To: Gonzalo Garramuno; +Cc: git
In-Reply-To: <47179944.6080608@filmaura.com>
On Thu, Oct 18, 2007 at 02:35:00PM -0300, Gonzalo Garramuno wrote:
> I have a project I have been working on for some time and one of its
> libraries has grown too much.
> I'm now wanting to split that library into a separate git repository.
> I'm wondering what's the best way to go around this. Ideally I would like
> to have:
Look at the documentation for "git-filter-branch". You can make a new
history for each of the split parts that you want.
-Peff
^ permalink raw reply
* Re: git push bug?
From: Shawn O. Pearce @ 2007-10-19 0:24 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: joakim.tjernlund, git
In-Reply-To: <0DAC53EF-021D-441C-9520-9795AAB6DE54@zib.de>
Steffen Prohaska <prohaska@zib.de> wrote:
> On Oct 18, 2007, at 4:50 PM, Joakim Tjernlund wrote:
> >
> ># > git push ssh://devsrv/var/git/os2kernel.git linus:refs/linus
...
> >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'
...
> 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".
Cute. The error message "error: refusing to create .. locally"
is actually coming from the remote site. Locally here is
actually remotely. We *really* should change that. Its l.169 of
receive-pack.c, which is only running on the remote side. :)
Anyone game to improve that error message? Should be a pretty
simple patch. One of the may low-hanging fruits in Git.
--
Shawn.
^ permalink raw reply
* Re: Qgit performance and maintain CVS environment with GIT repository
From: Pete/Piet Delaney @ 2007-10-19 0:22 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Marco Costalba, Robin Rosenberg, piet.delaney, Linus Torvalds,
VMiklos, free cycle, git, piet.delaney, Piet Delaney
In-Reply-To: <Pine.LNX.4.64.0710190054570.25221@racer.site>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Johannes Schindelin wrote:
> Hi,
>
> On Thu, 18 Oct 2007, Pete/Piet Delaney wrote:
>
>> Johannes:
>> I read somewhere in the past week that it was possible to maintain
>> our existing CVS environment with git. I though it was a separate
>> package to export git back to cvs but I just noticed a git-cvsserver
>> and as a std part of git and was wondering about using that.
>
> Where did you read that?
Don't recall exactly, I thought it was a page like the one showing
git Related tools but didn't find it today when looking for it.
> AFAIK git-cvsserver is one option. The other is
> cvsexportcommit. The former is more appropriate if you want to switch the
> developers over to git, and want to provide a smooth path for the devs (or
> cannot convert a few hardcore CVS "fans").
>
> The latter is appropriate if you cannot control the server side, or are
> not allowed to switch to CVS.
I've got root access on the CVS server and want to switch to git without
disturbing the environment more than is necessary to make the switch.
I think developers will want to us git and git-cvsserver looks like
the more likely desirable path.
>
>> We have a number of build machines with flamebox perl scripts pulling
>> out CVS branches for builds. I was wondering what is the best way to use
>> git and it's nicer pull/push model and merge facility and possibly
>> maintain CVS exports for scripts doing builds if possible the cvsweb and
>> bonsai (CVS Query Form) that a number of engineers are currently using.
>
> I don't know how cvsweb copes with git-cvsserver, but I guess that there
> will be no problem.
great.
>
>> I started looking over out flamebox scripts with the intent up
>> converting them over to git but I mentioned the git to cvs coexistence
>> and we are wondering if that's a better route than upgrading the
>> flamebox scripts. Having our existing cvsweb, bonsai, and gitweb along
>> with the git utilities seems at least desirable. Any thoughts or
>> suggestions?
>
> My suggestion: if you're fine with CVS, stick with it. Really. I am not
> here to teach the whole world about the advantages of git, so by all
> means, if you yourself do not find any advantage to using git, don't use
> it. Stick with what works for you.
We are definitely not fine with CVS, the branch merging isn't
comfortable. I'm just wondering about maintaining the existing
CVS browsers and the build scripts if it's not a big deal. I'll
try the git-cvsserver path. If anyone has any war stories to share
on the path this would be an ideal time to share them.
- -piet
>
> Ciao,
> Dscho
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHF/jPJICwm/rv3hoRAkXgAJ9pa/DHxka926i3FHqYTsxCb5kzcQCeKiSk
j/Paxc6tJemOPK0TV8MhFGs=
=ut2Q
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [BUG] git remote add failure
From: Shawn O. Pearce @ 2007-10-19 0:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Guido Ostkamp, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0710181708230.25221@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> 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.
Right. But maybe there should be an easier way for the user to
"force" adding the remote over the existing remote. Much like how
they can force creating a branch over an existing branch.
Too bad -f is already taken. :-\
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Add a message explaining that automatic GC is about to start
From: Shawn O. Pearce @ 2007-10-19 0:16 UTC (permalink / raw)
To: Steven Grimm
Cc: Brian Gernhardt, Jeff King, Linus Torvalds, Luke Lu,
Christer Weinigel, Tom Tobin, git
In-Reply-To: <47176AB9.7010409@midwinter.com>
Steven Grimm <koreth@midwinter.com> wrote:
> 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.
Arrgh. I already have the original patch in this thread in my master
so I can't rewind it. But yes, the argument Brian is making above
makes a lot of sense and I like his proposed message even better
than what I've already applied.
A patch against spearce/master to revert the prior message and insert
something that is perhaps more reasonable would be most appreciated.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 2/2] filter-branch: update current branch when rewritten
From: Shawn O. Pearce @ 2007-10-19 0:06 UTC (permalink / raw)
To: Bill Lear; +Cc: Johannes Schindelin, git, gitster
In-Reply-To: <18199.21729.535096.397497@lisa.zopyra.com>
Bill Lear <rael@zopyra.com> wrote:
> 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?).
This is actually already in my maint branch:
git://repo.or.cz/git/spearce.git
http://repo.or.cz/r/git/spearce.git
The best way to know if a given patch has been applied is to just
fetch every so often and look. But you are also subscribed to
the mailing list and there's usually a weekly "What's in git.git"
and a "What's cooking in git.git" messages sent describing the
recent changes. Monitoring these can also tell you when it may be
a good time for you to pull in a more recent version.
My last What's in/What's cooking messages were sent out on Monday.
I've got a lot of stuff from folks since then going into my tree
(the above is one of them) so I'll probably wrap up this week with
another set of messages tomorrow.
Of course the maintainer could send an email for every patch that
he/she applies, but the mailing list volume is already quite high.
Junio (and myself) both prefer to not bother responding to accepted
patches when they come from regular contributors, as we know the
regular contributor will be pulling in the near future anyway.
--
Shawn.
^ permalink raw reply
* Re: Qgit performance and maintain CVS environment with GIT repository
From: Johannes Schindelin @ 2007-10-19 0:00 UTC (permalink / raw)
To: Pete/Piet Delaney
Cc: Marco Costalba, Robin Rosenberg, piet.delaney, Linus Torvalds,
VMiklos, free cycle, git, piet.delaney, Piet Delaney
In-Reply-To: <4717EF40.6000509@bluelane.com>
Hi,
On Thu, 18 Oct 2007, Pete/Piet Delaney wrote:
> Johannes:
> I read somewhere in the past week that it was possible to maintain
> our existing CVS environment with git. I though it was a separate
> package to export git back to cvs but I just noticed a git-cvsserver
> and as a std part of git and was wondering about using that.
Where did you read that? AFAIK git-cvsserver is one option. The other is
cvsexportcommit. The former is more appropriate if you want to switch the
developers over to git, and want to provide a smooth path for the devs (or
cannot convert a few hardcore CVS "fans").
The latter is appropriate if you cannot control the server side, or are
not allowed to switch to CVS.
> We have a number of build machines with flamebox perl scripts pulling
> out CVS branches for builds. I was wondering what is the best way to use
> git and it's nicer pull/push model and merge facility and possibly
> maintain CVS exports for scripts doing builds if possible the cvsweb and
> bonsai (CVS Query Form) that a number of engineers are currently using.
I don't know how cvsweb copes with git-cvsserver, but I guess that there
will be no problem.
> I started looking over out flamebox scripts with the intent up
> converting them over to git but I mentioned the git to cvs coexistence
> and we are wondering if that's a better route than upgrading the
> flamebox scripts. Having our existing cvsweb, bonsai, and gitweb along
> with the git utilities seems at least desirable. Any thoughts or
> suggestions?
My suggestion: if you're fine with CVS, stick with it. Really. I am not
here to teach the whole world about the advantages of git, so by all
means, if you yourself do not find any advantage to using git, don't use
it. Stick with what works for you.
Ciao,
Dscho
^ permalink raw reply
* Re: Qgit performance and maintain CVS environment with GIT repository
From: Pete/Piet Delaney @ 2007-10-18 23:41 UTC (permalink / raw)
To: Marco Costalba, Johannes Schindelin
Cc: Robin Rosenberg, piet.delaney, Linus Torvalds, VMiklos,
free cycle, git, piet.delaney, Piet Delaney
In-Reply-To: <e5bfff550710171626h733228aw7a251746d2b43c63@mail.gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Marco Costalba wrote:
> On 10/17/07, Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
>> You could avoid the temporary files if you just pipe the diff to kompare. That
>> would require an option to tell qgit that the external viewer can read a git diff.
>>
>> At the time qgit 1.5 was written, kompare could not handle git diffs.
>>
>
> So does the other tools I have checked at that time.
>
> But I don't know if this fixes the problem of slowness reported. A
> little test Pete may do is just as I have written in the former email:
> try to save the big files that cause troubles where he prefers and run
> Kompare on them directly from the command line.
>
> Is kompare faster? If no probably the 'pipe' technique will not solve
> the problem and shrinks the applicability of the external diff
> launcher to tools that handle diffs directly.
Marco:
I'll try kcompare on the huge files both on and off the NFS
file system to see if it has a noticeable impact.
Johannes:
I read somewhere in the past week that it was possible to maintain
our existing CVS environment with git. I though it was a separate
package to export git back to cvs but I just noticed a git-cvsserver
and as a std part of git and was wondering about using that.
We have a number of build machines with flamebox perl scripts pulling
out CVS branches for builds. I was wondering what is the best way to
use git and it's nicer pull/push model and merge facility and possibly
maintain CVS exports for scripts doing builds if possible the cvsweb
and bonsai (CVS Query Form) that a number of engineers are currently
using. I started looking over out flamebox scripts with the intent
up converting them over to git but I mentioned the git to cvs
coexistence and we are wondering if that's a better route than
upgrading the flamebox scripts. Having our existing cvsweb, bonsai,
and gitweb along with the git utilities seems at least desirable.
Any thoughts or suggestions?
- -piet
>
> Marco
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHF+8/JICwm/rv3hoRApKnAJ4suTVrULHeVnU2HrS3TDo+eTzxVQCbBH7x
NzKdc6wRc1VdAOWgXOXBJ4U=
=RuQc
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: git-merge: need a tap with the cluestick, please
From: Shawn O. Pearce @ 2007-10-18 23:35 UTC (permalink / raw)
To: walt; +Cc: git
In-Reply-To: <ff80tr$hh1$1@ger.gmane.org>
walt <wa1ter@myrealbox.com> wrote:
> Now when I pull from Linus the merge stops in the middle because of
> conflicts with my .gitignore file <sigh>. Anything I try now with
> git-merge tells me I can't do that in the middle of a conflicted
> merge. Yes, I know that now, but what should I do instead?
>
> I could move my 'obj' out-of-tree but then I wouldn't learn anything.
> This has to be bone-head easy, but not for me :)
How about putting the ignore for your obj dir in your own private
exclude file:
$ echo /obj >>.git/info/exclude
will cause Git to ignore an "obj" directory if it is found in the
top level of the repository. And since this file is not actually
tracked as part of the repository it will apply to all branches
in this repository and won't cause merge conflicts when upstream
makes changes to .gitignore.
As for aborting a merge that you have gotten into the middle of
decided you want to get out of, use `git reset --hard`. That will
throw away all of the unmerged state and put you back to your
pre-merge state.
--
Shawn.
^ permalink raw reply
* RE: linux-2.6.git mirror
From: Linus Torvalds @ 2007-10-18 23:24 UTC (permalink / raw)
To: Medve Emilian-EMMEDVE1, Shawn O. Pearce; +Cc: Git Mailing List
In-Reply-To: <598D5675D34BE349929AF5EDE9B03E270168517F@az33exm24.fsl.freescale.net>
On Thu, 18 Oct 2007, Medve Emilian-EMMEDVE1 wrote:
>
> > > Is this something I should be worried about?
> >
> > No, but if it still happens with a newer git, holler.
>
> I tested this with Junio's latest master and a couple of stable releases
> from the maint branch with the same result.
Ok, what is going on is:
- append_fetch_head() looks up the SHA1 for all heads (including tags):
if (get_sha1(head, sha1))
return error("Not a valid object name: %s", head);
- it then wants to check if it's a candidate for merging (because
fetching also does the whole "list which heads to merge" in case it is
going to be part of a "pull"):
commit = lookup_commit_reference(sha1);
if (!commit)
not_for_merge = 1;
- and that "lookup_commit_reference()" is just very vocal about the case
where it fails. It really shouldn't be, and it shouldn't affect the
actual end result, but that basically explains why you get that scary
warning.
In short, the warning is just bogus, and should be harmless, but I agree
that it's ugly. I think the appended patch should fix it.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
And yes, I think this should go into Shawns tree of fixes, assuming that
Emil confirms that it fixes it for him.
Linus
builtin-fetch--tool.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-fetch--tool.c b/builtin-fetch--tool.c
index 1e43d79..e26817d 100644
--- a/builtin-fetch--tool.c
+++ b/builtin-fetch--tool.c
@@ -131,7 +131,7 @@ static int append_fetch_head(FILE *fp,
if (get_sha1(head, sha1))
return error("Not a valid object name: %s", head);
- commit = lookup_commit_reference(sha1);
+ commit = lookup_commit_reference_gently(sha1, 1);
if (!commit)
not_for_merge = 1;
^ permalink raw reply related
* Re: Problem with git-svnimport
From: Steven Grimm @ 2007-10-18 23:06 UTC (permalink / raw)
To: Jan Hudec; +Cc: VAUCHER Laurent, git
In-Reply-To: <20071018180916.GK26127@efreet.light.src>
Jan Hudec wrote:
> git-svnimport is obsoleted (or mostly so) by git-svn. Look at that, please.
>
This has been asked before, but I don't think there was a good answer:
What remaining features does git-svnimport have that git-svn doesn't? It
would be nice to not have two such tools if one of them doesn't actually
add any value. Can we safely deprecate git-svnimport in the next release?
-Steve
^ permalink raw reply
* Re: git-svn help for authorsfile
From: Sam Vilain @ 2007-10-18 22:53 UTC (permalink / raw)
To: Dongsheng Song; +Cc: git
In-Reply-To: <4b3406f0710172326y29c73a79x648ef98208adba78@mail.gmail.com>
Dongsheng Song wrote:
> In general, all svn projects share the same authorsfile, e.g.
>
> [svn]
> authorsfile=/path/to/authorsfile
>
> [svn-remote "project-a"]
> url = http://server.org/svn
> branches = branches/*/project-a:refs/remotes/project-a/branches/*
> tags = tags/*/project-a:refs/remotes/project-a/tags/*
> trunk = trunk/project-a:refs/remotes/project-a/trunk
>
> [svn-remote "project-b"]
> url = http://server.org/svn
> branches = branches/*/project-b:refs/remotes/project-b/branches/*
> tags = tags/*/project-b:refs/remotes/project-b/tags/*
> trunk = trunk/project-b:refs/remotes/project-b/trunk
>
> But if project-a and project-b has same svn id, map to different
> user/email, how do I do?
>
> Can we move authorsfile from svn to svn-remote section ?
Dongsheng,
If you come up with a patch that allows this, then I'm sure it can be
considered; below is what I imagine it would minimally require. However,
I haven't tested this at all so please treat with caution.
Subject: [PATCH] git-svn: allow per-remote authors map
Allow the authors map to be overridden on a per-remote basis.
---
git-svn.perl | 14 +++++++++-----
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index c015ea8..47f524d 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -5,7 +5,7 @@ use warnings;
use strict;
use vars qw/ $AUTHOR $VERSION
$sha1 $sha1_short $_revision
- $_q $_authors %users/;
+ $_q %users/;
$AUTHOR = 'Eric Wong <normalperson@yhbt.net>';
$VERSION = '@@GIT_VERSION@@';
@@ -65,7 +65,7 @@ my %remote_opts = ( 'username=s' => \$Git::SVN::Prompt::_username,
'config-dir=s' => \$Git::SVN::Ra::config_dir,
'no-auth-cache' => \$Git::SVN::Prompt::_no_auth_cache );
my %fc_opts = ( 'follow-parent|follow!' => \$Git::SVN::_follow_parent,
- 'authors-file|A=s' => \$_authors,
+ 'authors-file|A=s' => \$Git::SVN::_authors,
'repack:i' => \$Git::SVN::_repack,
'noMetadata' => \$Git::SVN::_no_metadata,
'useSvmProps' => \$Git::SVN::_use_svm_props,
@@ -142,7 +142,7 @@ my %cmd = (
'oneline' => \$Git::SVN::Log::oneline,
'show-commit' => \$Git::SVN::Log::show_commit,
'non-recursive' => \$Git::SVN::Log::non_recursive,
- 'authors-file|A=s' => \$_authors,
+ 'authors-file|A=s' => \$Git::SVN::authors,
'color' => \$Git::SVN::Log::color,
'pager=s' => \$Git::SVN::Log::pager,
} ],
@@ -187,7 +187,6 @@ exit 1 if (!$rv && $cmd && $cmd ne 'log');
usage(0) if $_help;
version() if $_version;
usage(1) unless defined $cmd;
-load_authors() if $_authors;
# make sure we're always running
unless ($cmd =~ /(?:clone|init|multi-init)$/) {
@@ -748,6 +747,7 @@ sub file_to_s {
# '<svn username> = real-name <email address>' mapping based on git-svnimport:
sub load_authors {
+ my $_authors = shift;
open my $authors, '<', $_authors or die "Can't open $_authors $!\n";
my $log = $cmd eq 'log';
while (<$authors>) {
@@ -891,7 +891,7 @@ package Git::SVN;
use strict;
use warnings;
use vars qw/$default_repo_id $default_ref_id $_no_metadata $_follow_parent
- $_repack $_repack_flags $_use_svm_props $_head
+ $_repack $_repack_flags $_use_svm_props $_head $_authors
$_use_svnsync_props $no_reuse_existing $_minimize_url/;
use Carp qw/croak/;
use File::Path qw/mkpath/;
@@ -993,6 +993,8 @@ sub fetch_all {
$remotes ||= read_all_remotes();
my $remote = $remotes->{$repo_id} or
die "[svn-remote \"$repo_id\"] unknown\n";
+ my $authors = $remote->{authors} || $_authors;
+ load_authors($authors) if $authors;
my $fetch = $remote->{fetch};
my $url = $remote->{url} or die "svn-remote.$repo_id.url not defined\n";
my (@gs, @globs);
@@ -1050,6 +1052,8 @@ sub read_all_remotes {
die "The '*' glob character must be the last ",
"character of '$g'\n";
}
+ } elsif (m!^(.+)\.authors=\s*(.*)\s*$!) {
+ $r->{$1}->{authors} = $2;
}
}
$r;
--
1.5.3.2.3.g2f2dcc-dirty
^ permalink raw reply related
* Re: [PATCH] Remove link to the survey from the git home page.
From: Petr Baudis @ 2007-10-18 22:51 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: Jonas Fonseca, git
In-Reply-To: <4d8e3fd30710180830l30e2e371r4cadee0c8ff2e82f@mail.gmail.com>
Hi,
On Thu, Oct 18, 2007 at 05:30:58PM +0200, Paolo Ciarrocchi wrote:
> 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?
to be honest, I'm kinda sceptical. It's not really clear at all to me
what added value would drupal bring, and there're plenty of downsides
(mainly around various additional maintenance costs) to balance out.
I probably wouldn't be able to tend for a drupal installation
personally, since I barely get time to maintain even the current
simplistic web page.
(But it isn't required that *I* run the homepage. :-) And I certainly
wouldn't want to stifle "innovation".)
--
Petr "Pasky" Baudis
Early to rise and early to bed makes a male healthy and wealthy and dead.
-- James Thurber
^ permalink raw reply
* Re: git on afs (fwd)
From: Brandon Casey @ 2007-10-18 22:48 UTC (permalink / raw)
To: git
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; format=flowed; charset=X-UNKNOWN, Size: 1077 bytes --]
Added the mailing list back in.
On Thu, 18 Oct 2007, Todd T. Fries wrote:
> link() returns -1 errno 17 File exists on afs.
>
> To further muddy the waters, linking within the same dir is ok,
> linking outside the same dir is not:
>
> todd@ispdesk/p6 ~/tmp¦61$ mkdir dir
> todd@ispdesk/p6 ~/tmp¦62$ touch a
> todd@ispdesk/p6 ~/tmp¦63$ ln a b
> todd@ispdesk/p6 ~/tmp¦64$ ls -l a b
> -rw-r--r-- 2 4 wheel 0 Oct 18 17:09 a
> -rw-r--r-- 2 4 wheel 0 Oct 18 17:09 b
> todd@ispdesk/p6 ~/tmp¦65$ ls -li a b
> 2068032 -rw-r--r-- 2 4 wheel 0 Oct 18 17:09 a
> 2068032 -rw-r--r-- 2 4 wheel 0 Oct 18 17:09 b
> todd@ispdesk/p6 ~/tmp¦66$ ln a dir/b
> ln: dir/b: File exists
> todd@ispdesk/p6 ~/tmp¦67$ echo $?
That error is just bogus on afs. If it returned a sane
error, things would just work.
But, looks like afs only supports linking within the same
directory: http://www.angelfire.com/hi/plutonic/afs-faq.html
So, you could look into whether the temp file can be sanely
created in the same directory as the final filename.
-brandon
^ permalink raw reply
* Re: git on afs
From: Linus Torvalds @ 2007-10-18 22:47 UTC (permalink / raw)
To: Todd T. Fries; +Cc: git
In-Reply-To: <20071018203106.GA13518@fries.net>
On Thu, 18 Oct 2007, Todd T. Fries wrote:
>
> 2) git presumes that DTYPE(de) != DT_DIR .. means the dirent is not a dir
> this is not true for afs
That's a major bug, and has nothing to do with AFS. Oops.
If you look just a bit lower, you'll see that just a few lines down, git
handles DT_UNKNOWN correctly, and just does a lstat() on it as required. I
guess that logic should be moved up, or alternatively the exclude logic
should be moved down.
Your patch looks ok, but at the same time, I don't think it's really the
right thing to do, since it now does that lstat() twice.
Linus
^ permalink raw reply
* RE: linux-2.6.git mirror
From: Medve Emilian-EMMEDVE1 @ 2007-10-18 22:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.999.0710181518120.26902@woody.linux-foundation.org>
Hi Linus,
> > Is this something I should be worried about?
>
> No, but if it still happens with a newer git, holler.
I tested this with Junio's latest master and a couple of stable releases
from the maint branch with the same result. In my ignorance I suspected
the build infrastructure so I tried different gcc versions (4.x and 3.x)
and optimization levels (including -O0) different libraries, etc. that I
had on a few machines around here. The result was the same.
What worried me is that I think I traced the source of the error message
in commit.c and in both two possible places from where the message could
come the processing flow seems to be cut shorter because of this.
Thanks for your reply,
Emil.
^ permalink raw reply
* Re: Subversion developer: svn is for dumb people
From: Sam Vilain @ 2007-10-18 22:40 UTC (permalink / raw)
To: Steven Grimm; +Cc: 'git'
In-Reply-To: <47176CE0.7030609@midwinter.com>
Steven Grimm wrote:
> some of his specific arguments
> about DVCS are on the bogus side. "Centralized systems encourage code
> reviews," for one --
I heard this from the core Subversion team too. The hypothesis is that
by forcing groups to be unable to proceed without continually rebasing
to each other's work, that collaboration is enhanced.
I think any argument which states that a restrictive system is better
than a non-restrictive system, when the non-restrictive system can be
used in the same way as the restrictive system (either with
configuration, or agreement with the committers) is quite bizarre.
Sam.
^ permalink raw reply
* Re: [PATCH] git-blame shouldn't crash if run in an unmerged tree
From: Linus Torvalds @ 2007-10-18 22:38 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, B.Steinbrink
In-Reply-To: <20071018063407.GA28861@spearce.org>
On Thu, 18 Oct 2007, Shawn O. Pearce wrote:
>
> I'm applying this patch to my maint tree tonight as it does resolve
> the issue for now. What surprised me was the file that we were
> crashing out on wasn't even the file we wanted to get the blame
> data for. :-\
Please feel free to add a Signed-off-by: there. I guess I didn't add it in
the original email, because I wasn't sure if I'd have the energy to see if
I could just remove the clearing of "ce_mode". I never did.
That whole "ce->ce_mode = 0" thing is really hacky, and we use it for two
totally different things ("git read-tree" uses it for "delete this entry",
and reading the index uses it when you ask for only merged entries). Bad
form, and not very logical.
Linus
^ 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