* Migration problems from SVN
From: Øyvind Harboe @ 2009-01-06 12:09 UTC (permalink / raw)
To: git
Hi all,
I'm trying to migrate from svn to git, but has run into a snag for which
I haven't found any good solutions on the web:
If I early on and accidentally commit a *large* binary object, how do I get rid
of it from .git again?
svn copes with this reasonably well as the binary object will no longer be
downloaded if it is deleted. Also when converting old SVN repositories,
such objects needs to be pruned. Somewhat related I also need to enumerate
the offending large binary objects that I should get rid of.
It is unpractical to live by the rule that no big objects should ever
be committed
accidentally given the number of people involved and the walks of life they come
from.... So there really needs to be some way to deal with this once the
damage has been done.
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer
^ permalink raw reply
* Re: Migration problems from SVN
From: Thomas Rast @ 2009-01-06 12:39 UTC (permalink / raw)
To: Øyvind Harboe; +Cc: git
In-Reply-To: <c09652430901060409p23d2737ck6e41b3f8f1eaf01@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 769 bytes --]
Øyvind Harboe wrote:
> If I early on and accidentally commit a *large* binary object, how do I get rid
> of it from .git again?
git-filter-branch can do that. See the top of the EXAMPLES section in
http://www.kernel.org/pub/software/scm/git/docs/git-filter-branch.html
This requires a rewrite of all history affected; make sure you
understand the implications if you have already published it. See the
DISCUSSION in the same manpage.
Also note that due to the distributed nature, you cannot force such
changed history upon anyone; i.e., you cannot remove the objects from
anyone else's repository. You can only ask them to accept your new
history and forget that the old one was ever there.
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH/RFC 2/4] Use 'lstat_cache()' instead of 'has_symlink_leading_path()'
From: Kjetil Barvik @ 2009-01-06 12:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <7vk598j17u.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Kjetil Barvik <barvik@broadpark.no> writes:
>
>> Start using the optimised, faster and more effective symlink/directory
>> cache. The previously used call:
>>
>> has_symlink_leading_path(len, name);
>>
>> should be identically with the following call to lstat_cache():
>>
>> lstat_cache(len, name,
>> LSTAT_SYMLINK|LSTAT_DIR,
>> LSTAT_SYMLINK);
>> ...
>
> Care to enlighten why some of callers use the above, but not others?
> Namely, check_removed() in diff-lib.c
I though that first it would be a good thing to introduce as little
changes as possible, and then later on do some cleanups. Regarding
the 'check_removed()' function, I though that it could later have been
written something like this after cleanups:
[....]
static int check_removed(const struct cache_entry *ce, struct stat *st)
{
unsigned int ret_flags =
check_lstat_cache(ce_namelen(ce), ce->name,
LSTAT_SYMLINK|LSTAT_NOTDIR|LSTAT_DIR);
if (ret_flags & (LSTAT_SYMLINK|LSTAT_NOTDIR))
return 1;
if (ret_flags & LSTAT_LSTATERR)
return -1;
if (ret_flags & LSTAT_DIR) {
unsigned char sub[20];
[....]
This would have saved one more lstat() call in some cases. But after
a test, I now see that it does not work. The reason is that it does
not set the 'struct stat *st' parameter and/or that for the moment you
can not tell the 'lstat_cache()' function to also always test the last
path component. It could be extended to do this, if someone ask for
it and if it would be useful to extend the lstat_cache() for this
fact.
I will remove the '|LSTAT_NOTDIR' part from the call to lstat_cache()
in 'check_removed()' in the next version of the patch.
> and callers in unpack-trees.c care about NOTDIR unlike others, even
> though the original code checked for exactly the same condition.
Regarding the 'verify_absent()' function in unpack-trees.c, the
'|LSTAT_NOTDIR' part of the call to lstat_cache() helps to avoid 16047
lstat() calls for the given test case mentioned in the cover-letter.
And from the source code:
[...]
if (lstat_cache(ce_namelen(ce), ce->name,
LSTAT_SYMLINK|LSTAT_NOTDIR|LSTAT_DIR,
LSTAT_SYMLINK|LSTAT_NOTDIR))
return 0;
if (!lstat(ce->name, &st)) {
[...]
it should be easy to see that if we from the lstat_cache() could
already spot that some path component of ce->name does not exists,
then we can avoid the following lstat() call, as it then should known
to be failing.
regarding the 'unlink_entry()' function in unpack-trees.c, the
'|LSTAT_NOTDIR' part of the call to lstat_cache() does not for the
moment helps to avoid any lstat() calls, as far as I can see. But,
again, from the source code:
[..]
char *name = ce->name;
if (lstat_cache(ce_namelen(ce), ce->name,
LSTAT_SYMLINK|LSTAT_NOTDIR|LSTAT_DIR,
LSTAT_SYMLINK|LSTAT_NOTDIR))
return;
if (unlink(name))
return;
[...]
it should be correct, since if we already know that some path
component of ce-name does not exist, the call to unlink(name) would
always fail (with ENOENT).
> Does this mean that some callers of has_symlink_leading_path() checked
> only for leading symlinks when they should also have checked for a leading
> non-directory, and this patch is also a bugfix?
Yes, as indicated above, has_symlink_leading_path() should have
checked for leading non-directories when called from for the
'verify_absent()' function to be able to optimise away some more
lstat() calls.
I admit that I do not know the source code good enough to decide if
this is an indication of a bug somewhere, or just an optimisation.
-- kjetil
^ permalink raw reply
* Re: Migration problems from SVN
From: Øyvind Harboe @ 2009-01-06 12:44 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <200901061339.49843.trast@student.ethz.ch>
On Tue, Jan 6, 2009 at 1:39 PM, Thomas Rast <trast@student.ethz.ch> wrote:
> Øyvind Harboe wrote:
>> If I early on and accidentally commit a *large* binary object, how do I get rid
>> of it from .git again?
>
> git-filter-branch can do that. See the top of the EXAMPLES section in
Ah! Thanks! I will study this. Thanks for your patience with a beginner, I guess
I should have spotted this one. There is a lot to read and git is refreshingly
different and there is a lot of things to catch up on.
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer
^ permalink raw reply
* Problems with large compressed binaries when converting from svn
From: Øyvind Harboe @ 2009-01-06 12:55 UTC (permalink / raw)
To: git
I'm converting from svn and I've run into a
problem with tar.gz and tar.bz2 compressed files.
(This is a separate but only slightly related to previous post).
In subversion we committed large tar.bz2/gz files. These files would
change relatively rarely, but only very slightly. The trouble with the tar.bz2
format is that if the first byte changes, then the rest of the file will also
be different. .zip does not have this problem, but .zip isn't a very friendly
format for our purposes.
Later on the tar.bz2/gz files started to change fairly often, but harddrives
get bigger much more quickly than the .svn repository grows so we just
kept doing things the same way rather than reeducate and reengineer
the procedures.
With .git we need to handle this differently somehow.
Does git have some capability to store diffs of compressed files efficiently?
The only other alternative I can think of is to commit uncompressed
.tar files which is a bit of a bump in the road, but I suppose could be
made to work.
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer
^ permalink raw reply
* BUG?? INSTALL MAKEFILE
From: Lars Sadau @ 2009-01-06 13:26 UTC (permalink / raw)
To: git
Hallo,
i'm a brand-new git user. Just one minute ago I wanted to install git in
my home directory. The INSTALL file says type simply "make install", but
the makefile does a global installation.
Lars
^ permalink raw reply
* Re: Error: unable to unlink ... when using "git gc"
From: Matthieu Moy @ 2009-01-06 13:27 UTC (permalink / raw)
To: Johnny Lee; +Cc: Junio C Hamano, git
In-Reply-To: <488807870901060118y2dbc7430ocea5cf9ce4bca3c7@mail.gmail.com>
"Johnny Lee" <johnnylee194@gmail.com> writes:
> Thanks for your consideration Junio,
>
> Peff has already helped me to figure out the root cause of this error
> is a possible bad practice on collaboration work.
>
> Here I attached the previous mail.
See core.sharedRepository in man git-config or
http://www.kernel.org/pub/software/scm/git/docs/git-config.html
--
Matthieu
^ permalink raw reply
* Re: [PATCH/RFC 1/4] Optimised, faster, more effective symlink/directory detection
From: Kjetil Barvik @ 2009-01-06 13:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <7v3afwizi7.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
<snipp>
> If everything is working correctly, I do not think you will ever have a
> situation where you check "A/B" here and get ENOTDIR back. lstat("A/B")
> would yield ENOTDIR if "A" is not a directory, but:
>
> (1) If you did test "A" in the earlier round in the loop, you would have
> already found it is not a directory and would have exited the loop
> with LSTAT_ERR. You cannot test "A/B" in such a case;
>
> (2) If you did not test "A" in the loop, that has to be because you had a
> cached information for it, and the caching logic would have returned
> early if "A" was a non-directory without entering the loop; in other
> words, you would test "A/B" here without testing "A" in the loop only
> when the cache says "A" was a directory. You cannot get ENOTDIR in
> such a case.
>
> In any case, my main puzzlement still stands. I think ENOTDIR case should
> behave differently from ENOENT case.
>
> And I think it is an indication of a grave error, either this code is
> racing with an external process that is actively mucking with the work
> tree to make your cached information unusable, or somebody forgot to call
> clear_lstat_cache().
>
> Hmm?
I have looked at this once more, and I have to admit that what you
have said is correct. Sorry for being confusing! I will update the
patch by removing the 'errno == ENOTDIR' part from the if-test.
-- kjetil
^ permalink raw reply
* Re: BUG?? INSTALL MAKEFILE
From: Matthieu Moy @ 2009-01-06 14:56 UTC (permalink / raw)
To: Lars Sadau; +Cc: git
In-Reply-To: <49635BF8.1010700@sadau-online.de>
Lars Sadau <lars@sadau-online.de> writes:
> Hallo,
>
> i'm a brand-new git user. Just one minute ago I wanted to install git in
> my home directory. The INSTALL file says type simply "make install", but
> the makefile does a global installation.
I was going to write:
Either run ./configure --prefix=$HOME/wherever/you/want or edit the
prefix variable in config.mak.
but then realized that prefix is set to $(HOME) by default. Are you
sure you didn't edit the Makefile or run any sort of ./configure
before "make install" ?
--
Matthieu
^ permalink raw reply
* Re: Error: unable to unlink ... when using "git gc"
From: Johnny Lee @ 2009-01-06 15:05 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: git
In-Reply-To: <slrngm6hoj.n4a.sitaramc@sitaramc.homelinux.net>
Copy that.
Thanks Sitaram.
We also plan to do it in this way, just a small wondering that it
looks a kind of workaround instead of a more graceful solution.
Regards,
Johnny
On Tue, Jan 6, 2009 at 7:57 PM, Sitaram Chamarty <sitaramc@gmail.com> wrote:
> On 2009-01-06, Jeff King <peff@peff.net> wrote:
>> If you are going to have multiple users sharing a repository, generally
>> they should be in the same group and the core.sharedrepository config
>> option should be set (see "git help config", or the "shared" option to
>> git-init).
>>
>> I've never used that personally, though. I have always just used POSIX
>> ACLs, with a default ACL on each directory giving access to everyone.
>> E.g. (off the top of my head):
>>
>> for user in user1 user2 user3; do
>> setfacl -R -m u:$user:rwX -m d:u:$user:rwX /path/to/repo
>> done
>
> If you're not worried about the finer-grained access control
> that acl(5) gives you, just do what "git init
> --shared=group" does:
>
> git config core.sharedrepository 1 # as mentioned above
> chmod g+ws .git
>
> Now set the group to something (I use "gitpushers" ;-)
>
> chgrp -R gitpushers .git
>
> amd make sure all your users are part of that group.
>
> Works fine for small teams...
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
we all have our crosses to bear
^ permalink raw reply
* [PATCH (topgit) 0/2] tg-patch: fix pagination
From: Kirill Smelkov @ 2009-01-06 15:16 UTC (permalink / raw)
To: git; +Cc: Kirill Smelkov
Kirill Smelkov (2):
Implement setup_pager just like in git
tg-patch: fix pagination
tg-patch.sh | 3 +++
tg.sh | 53 +++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 56 insertions(+), 0 deletions(-)
^ permalink raw reply
* [PATCH (topgit) 2/2] tg-patch: fix pagination
From: Kirill Smelkov @ 2009-01-06 15:16 UTC (permalink / raw)
To: git; +Cc: Kirill Smelkov
In-Reply-To: <cover.1231254832.git.kirr@landau.phys.spbu.ru>
Previously, when I was invoking `tg patch` the following used to happen:
1. .topmsg content was sent directly to _terminal_
2. for each file in the patch, its diff was generated with `git diff`
and sent to *PAGER*
3. trailing 'tg: ...' was sent to terminal again
So the problem is that while `tg patch >file` works as expected, plain
`tg patch` does not -- in pager there is only a part of the whole patch
(first file diff) and header and trailer are ommitted.
I've finally decided to fix this inconvenience, and the way it works is
like in git -- we just hook `setup_pager` function in commands which
need to be paginated.
Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru>
---
tg-patch.sh | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/tg-patch.sh b/tg-patch.sh
index a704375..dc699d2 100644
--- a/tg-patch.sh
+++ b/tg-patch.sh
@@ -24,6 +24,9 @@ done
base_rev="$(git rev-parse --short --verify "refs/top-bases/$name" 2>/dev/null)" ||
die "not a TopGit-controlled branch"
+
+setup_pager
+
git cat-file blob "$name:.topmsg"
echo
[ -n "$(git grep '^[-]--' "$name" -- ".topmsg")" ] || echo '---'
--
1.6.1.48.ge9b8
^ permalink raw reply related
* [PATCH (topgit) 1/2] Implement setup_pager just like in git
From: Kirill Smelkov @ 2009-01-06 15:16 UTC (permalink / raw)
To: git; +Cc: Kirill Smelkov
In-Reply-To: <cover.1231254832.git.kirr@landau.phys.spbu.ru>
setup_pager() spawns a pager process and redirect the rest of our output
to it.
This will be needed to fix `tg patch` output in the next commit.
Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru>
---
tg.sh | 53 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 53 insertions(+), 0 deletions(-)
diff --git a/tg.sh b/tg.sh
index 8c23d26..51a82af 100644
--- a/tg.sh
+++ b/tg.sh
@@ -243,6 +243,59 @@ do_help()
fi
}
+## Pager stuff
+
+# isatty FD
+isatty()
+{
+ tty -s 0<&$1 || return 1
+ return 0
+}
+
+# setup_pager
+# Spawn pager process and redirect the rest of our output to it
+setup_pager()
+{
+ isatty 1 || return 0
+
+ # TG_PAGER = GIT_PAGER | PAGER
+ # http://unix.derkeiler.com/Newsgroups/comp.unix.shell/2004-03/0792.html
+ case ${GIT_PAGER+XXX} in
+ '')
+ case ${PAGER+XXX} in
+ '')
+ # both GIT_PAGER & PAGER unset
+ TG_PAGER=''
+ ;;
+ *)
+ TG_PAGER="$PAGER"
+ ;;
+ esac
+ ;;
+ *)
+ TG_PAGER="$GIT_PAGER"
+ ;;
+ esac
+
+ [ -z "$TG_PAGER" -o "$TG_PAGER" = "cat" ] && return 0
+
+
+ # now spawn pager
+ export LESS=${LESS:-FRSX} # as in pager.c:pager_preexec()
+
+ _pager_fifo="$(mktemp -t tg-pager-fifo.XXXXXX)"
+ rm "$_pager_fifo" && mkfifo -m 600 "$_pager_fifo"
+
+ "$TG_PAGER" < "$_pager_fifo" &
+ exec > "$_pager_fifo" # dup2(pager_fifo.in, 1)
+
+ # this is needed so e.g. `git diff` will still colorize it's output if
+ # requested in ~/.gitconfig with color.diff=auto
+ export GIT_PAGER_IN_USE=1
+
+ # atexit(close(1); wait pager)
+ trap "exec >&-; rm $_pager_fifo; wait" EXIT
+}
## Startup
--
1.6.1.48.ge9b8
^ permalink raw reply related
* Re: BUG?? INSTALL MAKEFILE
From: Mike Ralphson @ 2009-01-06 15:22 UTC (permalink / raw)
To: Lars Sadau; +Cc: Matthieu Moy, git
In-Reply-To: <vpqiqosa3fc.fsf@bauges.imag.fr>
2009/1/6 Matthieu Moy <Matthieu.Moy@imag.fr>
> Lars Sadau <lars@sadau-online.de> writes:
> > i'm a brand-new git user. Just one minute ago I wanted to install git in
> > my home directory. The INSTALL file says type simply "make install", but
> > the makefile does a global installation.
>
> I was going to write:
>
> Either run ./configure --prefix=$HOME/wherever/you/want or edit the
> prefix variable in config.mak.
>
> but then realized that prefix is set to $(HOME) by default. Are you
> sure you didn't edit the Makefile or run any sort of ./configure
> before "make install" ?
Or run 'make' as root, as well as 'make install'?
Mike
^ permalink raw reply
* Re: Error: unable to unlink ... when using "git gc"
From: Sitaram Chamarty @ 2009-01-06 15:33 UTC (permalink / raw)
To: git
In-Reply-To: <488807870901060705m49419ec1he14aace5caaa3d89@mail.gmail.com>
On 2009-01-06, Johnny Lee <johnnylee194@gmail.com> wrote:
> On Tue, Jan 6, 2009 at 7:57 PM, Sitaram Chamarty <sitaramc@gmail.com> wrote:
>> If you're not worried about the finer-grained access control
>> that acl(5) gives you, just do what "git init
>> --shared=group" does:
>>
>> git config core.sharedrepository 1 # as mentioned above
>> chmod g+ws .git
>>
>> Now set the group to something (I use "gitpushers" ;-)
>>
>> chgrp -R gitpushers .git
>>
>> amd make sure all your users are part of that group.
> We also plan to do it in this way, just a small wondering that it
> looks a kind of workaround instead of a more graceful solution.
I wouldn't consider it a workaround. It uses normal Unix
permissions the way they were designed to, including setgid
for directories.
Actually, I am yet to come up with a situation where I
actually needed ACLs, though they are more generalised, and
fine-grained.
And the maint is all eminently scriptable.
^ permalink raw reply
* Re: how to track the history of a line in a file
From: Bernt Hansen @ 2009-01-06 15:48 UTC (permalink / raw)
To: david; +Cc: git
In-Reply-To: <alpine.DEB.1.10.0901021405460.21567@asgard.lang.hm>
david@lang.hm writes:
> I have a need to setup a repository where I'm storing config files,
> and I need to be able to search the history of a particular line, not
> just when the last edit of the line was (which is what I see from git
> blame)
>
> I'm not seeing a obvious way to do this, am I missing something or
> does it need a non-obvious approach?
>
> for example, if I do
>
> git blame -L /SUBLEVEL/,+1 -M Makefile
>
> on the linux kernel it currently shows
>
> 57f8f7b6 (Linus Torvalds 2008-10-23 20:06:52 -0700 3) SUBLEVEL = 28
>
> what I would want it to show would be a list of the commits that have
> changed this line.
>
> It looks like I can write a script to do this
>
> git blame -L /SUBLEVEL/,+1 -M Makefile 57f8f7b6^
> 6e86841d (Linus Torvalds 2008-07-28 19:40:31 -0700 3) SUBLEVEL = 27
> git blame -L /SUBLEVEL/,+1 -M Makefile 6e86841d^
> 2ddcca36 (Linus Torvalds 2008-05-03 11:59:44 -0700 3) SUBLEVEL = 26
>
> etc.
>
> is there a better way to do this?
>
> David Lang
I think you need a script to do what you want. I think this works...
Save the following script in ~/bin/git-rblame.sh, make it executable,
and then create a global git alias for it as follows:
$ git config --global alias.rblame '!~/bin/git-rblame.sh $*'
Then you can just use
$ git rblame -L /SUBLEVEL/,+1 -M Makefile
6e86841d (Linus Torvalds 2008-07-28 19:40:31 -0700 3) SUBLEVEL = 27
2ddcca36 (Linus Torvalds 2008-05-03 11:59:44 -0700 3) SUBLEVEL = 26
...
4c91aedb (Linus Torvalds 2005-06-28 22:57:29 -0700 3) SUBLEVEL = 13
^1da177e (Linus Torvalds 2005-04-16 15:20:36 -0700 3) SUBLEVEL = 12
------cut here ------ !/bin/git-rblame.sh ---
#!/bin/sh
PARAMS="$*"
LINE=$(git blame $PARAMS)
while test $? == 0
do
echo $LINE
COMMIT="${LINE:0:8}^"
LINE=$(git blame $PARAMS $COMMIT 2>/dev/null)
done
------cut here ------------------------------
Cheers,
Bernt
^ permalink raw reply
* Re: how to track the history of a line in a file
From: Miklos Vajna @ 2009-01-06 16:08 UTC (permalink / raw)
To: Bernt Hansen; +Cc: david, git
In-Reply-To: <87d4f01lmt.fsf@gollum.intra.norang.ca>
[-- Attachment #1: Type: text/plain, Size: 420 bytes --]
On Tue, Jan 06, 2009 at 10:48:10AM -0500, Bernt Hansen <bernt@norang.ca> wrote:
> Save the following script in ~/bin/git-rblame.sh, make it executable,
> and then create a global git alias for it as follows:
>
> $ git config --global alias.rblame '!~/bin/git-rblame.sh $*'
Given that you have ~/bin in PATH, just name the script ~/bin/git-rblame
and you won't even have to define an alias on each machine. ;-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [ANNOUNCE] Git homepage change
From: Boyd Lynn Gerber @ 2009-01-06 16:12 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Scott Chacon, David Bryson, Mike Hommey, git
In-Reply-To: <20090106085448.GF21154@genesis.frugalware.org>
On Tue, 6 Jan 2009, Miklos Vajna wrote:
> On Mon, Jan 05, 2009 at 09:24:16PM -0700, Boyd Lynn Gerber
> <gerberb@zenez.com> wrote:
>> http://dir.gmane.org/gmane.comp.version-control.git
>>
>> On this page the following...
>>
>> Other mailing list archives for this list:
>>
>> 1. The Mail Archive
>>
>> http://www.mail-archive.com/git@vger.kernel.org/
>>
>> And this states this link
>>
>> http://www.mail-archive.com/git@vger.kernel.org/
>>
>> And the lastest is 2005 and earlier.
>
> I don't think you should blame Scott for this, it seem to be a gmane vs
> mail-archive issue, and gmane is mentioned already in MaintNotes.
I was not sure who/what/where to make a not of this. I think it would be
good if we could get a link to the various archives. During an update of
my system, a file was changed that cause email to me to be bounced. I did
not relealize it. I was trying to find archived. I thought I would start
with our new main page. I had to do google searches to finally find an
archive. The only problem is I have not figured out how to download all
303 articles, quickly/easily. You would think one of the majordomo
commands to get articles would work. They do not.
I thought I should remport my finding and see if anyone knew or could make
changes to make it easier for us to find the archives.
Thanks,
--
Boyd Gerber <gerberb@zenez.com> 801 849-0213
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
^ permalink raw reply
* Re: how to track the history of a line in a file
From: Bernt Hansen @ 2009-01-06 16:21 UTC (permalink / raw)
To: Miklos Vajna; +Cc: david, git
In-Reply-To: <20090106160814.GI21154@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> On Tue, Jan 06, 2009 at 10:48:10AM -0500, Bernt Hansen <bernt@norang.ca> wrote:
>> Save the following script in ~/bin/git-rblame.sh, make it executable,
>> and then create a global git alias for it as follows:
>>
>> $ git config --global alias.rblame '!~/bin/git-rblame.sh $*'
>
> Given that you have ~/bin in PATH, just name the script ~/bin/git-rblame
> and you won't even have to define an alias on each machine. ;-)
Yes but I don't want to use 'git-rblame' as the command since I've
broken my habit of using the dashed versions of commands. 'git rblame'
just feels better to me.
Now I probably should have named the script something that won't ever
clash with possible future git commands (like my-git-rblame.sh or
something) but since it's in my ~/bin I'll just deal with that if it
ever happens in the future :)
-Bernt
^ permalink raw reply
* Re: BUG?? INSTALL MAKEFILE
From: Ted Pavlic @ 2009-01-06 16:26 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Lars Sadau, git
In-Reply-To: <vpqiqosa3fc.fsf@bauges.imag.fr>
> but then realized that prefix is set to $(HOME) by default. Are you
> sure you didn't edit the Makefile or run any sort of ./configure
> before "make install" ?
After doing a
git clean -f
in my local git repo, I notice that:
config.mak.autogen
still exists, and inside it:
prefix = /usr/local
That file is included in the Makefile *after* prefix is set, and so if
it's not updated, the Makefile will default to /usr/local.
According to the INSTALL doc, the default prefix should be ~. However,
this is certainly not the case. Either the INSTALL doc needs to be
updated or a new default config.mak.autogen needs to be checked in (or
perhaps config.mak.autogen needs to be omitted from the repo?).
--Ted
--
Ted Pavlic <ted@tedpavlic.com>
^ permalink raw reply
* Re: how to track the history of a line in a file
From: Bernt Hansen @ 2009-01-06 16:28 UTC (permalink / raw)
To: Miklos Vajna; +Cc: david, git
In-Reply-To: <878wpo1k2p.fsf@gollum.intra.norang.ca>
Bernt Hansen <bernt@norang.ca> writes:
> Miklos Vajna <vmiklos@frugalware.org> writes:
>
>> On Tue, Jan 06, 2009 at 10:48:10AM -0500, Bernt Hansen <bernt@norang.ca> wrote:
>>> Save the following script in ~/bin/git-rblame.sh, make it executable,
>>> and then create a global git alias for it as follows:
>>>
>>> $ git config --global alias.rblame '!~/bin/git-rblame.sh $*'
>>
>> Given that you have ~/bin in PATH, just name the script ~/bin/git-rblame
>> and you won't even have to define an alias on each machine. ;-)
>
> Yes but I don't want to use 'git-rblame' as the command since I've
> broken my habit of using the dashed versions of commands. 'git rblame'
> just feels better to me.
>
> Now I probably should have named the script something that won't ever
> clash with possible future git commands (like my-git-rblame.sh or
> something) but since it's in my ~/bin I'll just deal with that if it
> ever happens in the future :)
Oops. That actually does do what I want. Thanks for pointing that out
Miklos!
(sorry for replying to my own post - next time I'll try it first before
I post :)
-Bernt
^ permalink raw reply
* Re: BUG?? INSTALL MAKEFILE
From: Matthieu Moy @ 2009-01-06 17:17 UTC (permalink / raw)
To: Ted Pavlic; +Cc: Lars Sadau, git
In-Reply-To: <49638625.3090109@tedpavlic.com>
Ted Pavlic <ted@tedpavlic.com> writes:
> According to the INSTALL doc, the default prefix should be ~.
I didn't read that in INSTALL. What I read is that if I only run "make
install", the prefix is $HOME, which is true. Now, ./configure uses a
default value which is not the one of the Makefile, but that's another
point.
--
Matthieu
^ permalink raw reply
* Re: BUG?? INSTALL MAKEFILE
From: Daniel Barkalow @ 2009-01-06 17:24 UTC (permalink / raw)
To: Ted Pavlic; +Cc: Matthieu Moy, Lars Sadau, git
In-Reply-To: <49638625.3090109@tedpavlic.com>
On Tue, 6 Jan 2009, Ted Pavlic wrote:
> > but then realized that prefix is set to $(HOME) by default. Are you
> > sure you didn't edit the Makefile or run any sort of ./configure
> > before "make install" ?
>
> After doing a
>
> git clean -f
You need a "git clean -fx"
> According to the INSTALL doc, the default prefix should be ~. However, this is
> certainly not the case. Either the INSTALL doc needs to be updated or a new
> default config.mak.autogen needs to be checked in (or perhaps
> config.mak.autogen needs to be omitted from the repo?).
It's omitted from the repo, but it's in .gitignore so "git clean" doesn't
remove it unless you tell it to remove ignored files.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] gitweb: don't use pathinfo for global actions
From: Jakub Narebski @ 2009-01-06 17:37 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano, Devin Doucette
In-Reply-To: <1230896080-22801-1-git-send-email-giuseppe.bilotta@gmail.com>
On Fri, 2 Jan 2009, Giuseppe Bilotta wrote:
> With PATH_INFO urls, actions for the projects list (e.g. opml,
> project_index) were being put in the URL right after the base. The
> resulting URL is not properly parsed by gitweb itself, since it expects
> a project name as first component of the URL.
Therefore it really needs to be in, as df63fb also by Giuseppe
(gitweb: use href() when generating URLs in OPML) is already in,
and I think gitweb would generate broken OPML and TXT links without
this patch.
>
> Accepting global actions in use_pathinfo is not a very robust solution
> due to possible present and future conflicts between project names and
> global actions, therefore we just refuse to create PATH_INFO URLs when
> the project is not defined.
I think it is quite robust solution and it makes sense; we use
shortcuts http://git.example.com for projects_list page, and
http://git.example.com/path/to/repo.git for overview 'summary'
action for a project, therefore pathinfo has to look like the
following: http://git.example.com/repo/action/hash with "action"
_after_ "project". And there is also matter of backward compatibility
of URL (URLs shouldn't break).
Anyway, we have $home_link for default project_list page, which
is path_info without project, and query without query string...
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Acked-by: Jakub Narebski <jnareb@gmail.com>
> ---
> gitweb/gitweb.perl | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 99f71b4..fa7d8ad 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -830,7 +830,7 @@ sub href (%) {
> }
>
> my $use_pathinfo = gitweb_check_feature('pathinfo');
> - if ($use_pathinfo) {
> + if ($use_pathinfo and defined $params{'project'}) {
> # try to put as many parameters as possible in PATH_INFO:
> # - project name
> # - action
> @@ -845,7 +845,7 @@ sub href (%) {
> $href =~ s,/$,,;
>
> # Then add the project name, if present
> - $href .= "/".esc_url($params{'project'}) if defined $params{'project'};
> + $href .= "/".esc_url($params{'project'});
> delete $params{'project'};
>
> # since we destructively absorb parameters, we keep this
Nice.
> --
> 1.5.6.5
>
>
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: JGit vs. Git
From: Shawn O. Pearce @ 2009-01-06 18:45 UTC (permalink / raw)
To: Vagmi Mudumbai; +Cc: git
In-Reply-To: <a55cfe9d0901052250k2be203dfvb0b437a523f2cecc@mail.gmail.com>
Vagmi Mudumbai <vagmi.mudumbai@gmail.com> wrote:
> 1) Is JGit a drop in replacement of Git? In sense, if I were to pack
> in an SCM with my app, Can I pack jgit instead of C Git?
As Robin said, its not a full drop-in replacement. That said, its
getting there. We're now only really missing patch application,
diff generation, merge support, and submodule support. Most of
the JGit core can handle submodules by skipping over them during
object traversal, but the part that talks to the filesystem to do
a checkout doesn't recognize them.
JGit is mostly a library, not a command line replacement. But it
does have commands like "jgit init", "jgit clone", "jgit fetch",
"jgit push", even some server side tools like "jgit daemon",
"jgit receive-pack" and "jgit upload-pack".
To be honest I don't think anyone actually uses the command line
pgm stuff to work with Git. Anyone using JGit is actually running
it embedded in some type of application like an IDE plugin or a
server like Gerrit.
> 2) I noticed that there are no 'add' and 'commit' commands (at least
> from the source) in the org.spearce.git.pgm project. I am looking at
> the repo.or.cz/egit.git repo. I had a brief look at the
> lib/GitIndex.java and lib/Repository.java. GitIndex has the add
> methods to add files/entries to the index. I am still stumped on how
> commits can be done with JGit. Any help is hugely appreciated.
As Robin said, look at the unit tests. Basically you want to use
the Commit class to populate out the data fields, then pass it off to
an ObjectWriter instance to store it into the tree. Finally you'll
need to use a RefUpdate (obtained from Repository's updateRef method)
to store the new ObjectId of that Commit into a ref like HEAD.
Unfortunately we have two commit representations in JGit. If you
are trying to read data from a Repository the RevCommit (obtained
from a RevWalk) is orders of magnitude faster than the Commit class.
> I am working on Windows with msysGit behind a HTTP Proxy. (Life cant
> get worse, I guess.) . I planned on using grit via JRuby but grit uses
> fork which is not available on funny platforms like windows. And JRuby
> guys do not have any plan on supporting fork even on platforms on
> which for is supported. If JGit is a pure Java based implementation of
> Git with more or less the same functionality, then my work becomes a
> lot easier.
I plan on writing patch apply sometime this quarter I think. I have
most of what I need to rip a patch apart and inspect it prior to
application, now I just need to line it up onto the base object
and issue the output version.
Diff might also come in the next few months. Dscho has a nice
prototype working, but there's still some work to be done on it.
--
Shawn.
^ 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