* Re: quote in help code example
From: bill lam @ 2009-10-13 2:16 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20091012194016.GS23777@genesis.frugalware.org>
On Mon, 12 Oct 2009, Miklos Vajna wrote:
> On Mon, Oct 12, 2009 at 06:29:26PM +0800, bill lam <cbill.lam@gmail.com> wrote:
> > In git man, eg. git help filter-branch
> > The code examples for command line or shell scripts inside .ft pairs
> > use (smart?) quote instead of single quotes, like
> >
> > .ft C
> > git filter-branch --tree-filter ´rm filename´ HEAD
> > .ft
> >
> > Is this intentional or just some configuration problem during
> > compiling.
>
> Just a guess: do you have docbook-xsl >=1.73.0 and you did not set
> ASCIIDOC_NO_ROFF?
>
> Try rebuilding the documentation using 'make ASCIIDOC_NO_ROFF=YesPlease'.
I'm not familiar with how to twist git makefile. By adding a line to ./Makefile
# Platform specific tweaks
#
# We choose to avoid "if .. else if .. else .. endif endif"
# because maintaining the nesting to match is a pain. If
# we had "elif" things would have been much nicer...
ASCIIDOC_NO_ROFF = YesPlease # <--- this line added
ifeq ($(uname_S),Linux)
However, the man page still display the same
.ft C
git filter-branch --tree-filter ´rm filename´ HEAD
.ft
I use debian lenny 64bit with
Package: docbook-xsl
Version: 1.73.2.dfsg.1-5
Package: asciidoc
Version: 8.2.7-3~lenny1
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* Re: Git: "No you can't handle my root!" (?)
From: Jeff King @ 2009-10-13 1:43 UTC (permalink / raw)
To: Daniele Segato; +Cc: sylvain, git
In-Reply-To: <1255383459.15646.10.camel@localhost>
On Mon, Oct 12, 2009 at 11:37:39PM +0200, Daniele Segato wrote:
> I don't see the point of using git on the root directory :)
>
> but that made me think that it could actually be a good idea
> for /etc/ :)
> I happen to modify some configuration and then I forgot which one... and
> sometimes updates broke something
Take a look at:
http://joey.kitenet.net/code/etckeeper/
> can I have a git report of $HOME/.* (without . and ..)? (all user
> setting)
This seems to work:
$ cd ~
$ git init
$ echo '*' >.gitignore
$ echo '!.*' >.gitignore
> Or better: provide a list of directory under $HOME I want to track
Same thing, but make your ! pattern more specific.
-Peff
^ permalink raw reply
* Re: [JGit-io-RFC-PATCH v2 2/4] Add JGit IO SPI and default implementation
From: Imran M Yousuf @ 2009-10-13 1:30 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, egit-dev, Imran M Yousuf
In-Reply-To: <20091012145741.GM9261@spearce.org>
On Mon, Oct 12, 2009 at 9:57 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> imyousuf@gmail.com wrote:
>> The SPI mainly focus's in providing an API to JGit to be able to perform
>> similar operations to that of java.io.File. All direct I/O is based on the
>> java.io.Input/OutputStream classes.
>>
>> Different JGit IO SPI provider is designed to be URI scheme based and thus
>> the default implementation is that of "file" scheme. SPI provider will be
<snip />
> I think this may be a bit in the wrong direction for what we are
> trying to accomplish.
>
> A number of people really want to map Git onto what is essentially
> Google's BigTable schema. Aside from Google's own BigTable product
> (which I want to use Git on at work, because it would vastly simplfiy
> my system administration duties at $DAYJOB) there is Cassandra and
> Hadoop HBase which implement the same schema semantics.
>
> None of those systems implement file streams, they implement cell
> storage in a non-transactional system with a semi-dynamic schema.
>
> Some people have built transactional semantics on top of these
> storage layers, e.g. Google AppEngine provides multiple row
> transactions through some magic sauce layered on top of BigTable.
> I'm sure people will build similar tools on top of Cassandra
> and HBase.
>
> Where I'm trying to go with this is that things that are stored
> in files on the filesystem in traditional Git wouldn't normally be
> mapped into "byte streams" in a BigTable-ish system, or even the
> JDBC-ish system you were describing.
>
> For .git/config we might want to map config variable names into
> keys in the table, with values stored in cells. This makes it
> easier to query or edit the data.
>
> Fortunately, "Config" is abstract enough that we could subclass
> it with a CassandraConfig and simply use that instance when on a
> based Cassandra storage system. No file streams required. Ditto
> for a JdbcConfig.
>
Firstly, I am sorry but I am not intelligent enough to perceive, how
do the user decide which instance of Config to use? I personally think
that there is no API to achieve what you just mentioned :(; i.e. the
user will have know CassandraConfig directly. Secondly, I instead was
thinking of porting JGit for that matter to any system supporting
streams (not any specific sub-class of them), such HBase/BigTable or
HDFS anything.... Thirdly, I think we actually have several task in
hand and I would state them as -
1. First introduce the I/O API such that it completely replaces java.io.File
2. Secondly segregate persistence of for config (or config like
objects) and introduce a SPI for them for smarter storage.
I am not thinking of storing "only" the bare content of a git
repository, but I intent to be able to also store the versioned
contents it self as well. If we choose the above 2 steps I mentioned I
am of the opinion that we will be able
to achieve both our ideas. In addition I hope that if one day Git
itself introduces a similar I/O API then Git can also support the I/O
SPI implementations JGit will.
Waiting eagerly to learn what you think :).
Best regards,
Imran
> For RefDatabase, we'd want to do the same and avoid the concept of
> packed-refs altogether. Each Ref should go into its own row in a
> Cassandra storage system, and essentially act as a loose object.
> Ditto with JDBC.
>
> We'd probably never need to read-or-write the info/refs or
> objects/info/packs listings.
>
> And I think that's everything that a bare repository needs, aside
> from ObjectDatabase, which is already mostly abstract anyway.
>
> --
> Shawn.
>
--
Imran M Yousuf
Entrepreneur & Software Engineer
Smart IT Engineering
Dhaka, Bangladesh
Email: imran@smartitengineering.com
Blog: http://imyousuf-tech.blogs.smartitengineering.com/
Mobile: +880-1711402557
^ permalink raw reply
* Re: [RFC/PATCH] gitweb: linkify author/committer names with search
From: Stephen Boyd @ 2009-10-13 0:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski
In-Reply-To: <7vy6ng5gdr.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
>
> The intent makes sense to me, although I somehow suspect that with avatar
> support the user might be tempted to click on the icon not necessarily on
> the name string.
Ok if the utf8 thing can be solved I'll make sure to linkify the icon too.
^ permalink raw reply
* Re: [PATCH] git: add --no-replace-objects option to disable replacing
From: Junio C Hamano @ 2009-10-12 23:42 UTC (permalink / raw)
To: Christian Couder
Cc: git, Jakub Narebski, Johannes Sixt, bill lam, Andreas Schwab
In-Reply-To: <20091012203033.8939.43473.chriscool@tuxfamily.org>
Thanks.
I understand that the replace mechanism is lazily initialized so it would
be Ok to flip this variable as long as it is done before anybody makes the
first call to read_sha1_file(). I am guessing the assignment the patch
adds is early enough but I didn't audit the code.
^ permalink raw reply
* Re: [PATCH] git-add--interactive: never skip files included in index
From: Junio C Hamano @ 2009-10-12 23:42 UTC (permalink / raw)
To: Jeff King; +Cc: Pauli Virtanen, git
In-Reply-To: <20091012051157.GA23007@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Subject: [PATCH] ls-files: excludes should not impact tracked files
>
> In all parts of git, .gitignore and other exclude files
> impact only how we treat untracked files; they should have
> no effect on files listed in the index.
>
> This behavior was originally implemented very early on in
> 9ff768e, but only for --exclude-from. Later, commit 63d285c
> accidentally caused us to trigger the behavior for
> --exclude-per-directory.
>
> This patch totally ignores excludes for files found in the
> index. This means we are reversing the original intent of
> 9ff768e, while at the same time fixing the accidental
> behavior of 63d285c. This is a good thing, though, as the
> way that 9ff768e behaved does not really make sense with the
> way exclusions are used in modern git.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
Makes sense; thanks.
> I also still think that Pauli's patch makes sense; there is no point in
> passing --exclude-standard there. It should be a no-op.
Yeah, that is also queued independent from this one.
^ permalink raw reply
* Re: [RFC/PATCH] gitweb: linkify author/committer names with search
From: Junio C Hamano @ 2009-10-12 23:42 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git, Jakub Narebski
In-Reply-To: <1255328340-28449-1-git-send-email-bebarino@gmail.com>
Stephen Boyd <bebarino@gmail.com> writes:
> It's nice to search for an author by merely clicking on their name in
> gitweb. This is usually faster than selecting the name, copying the
> selection, pasting it into the search box, selecting between
> author/committer and then hitting enter.
The intent makes sense to me, although I somehow suspect that with avatar
support the user might be tempted to click on the icon not necessarily on
the name string.
> Signed-off-by: Stephen Boyd <bebarino@gmail.com>
> ---
>
> Cc'ed Jakub as he seems to be resident gitweb expert.
>
> I thought this might be a nice addition.
>
> The problem is I can't get it to work with UTF-8 characters. I'm not sure
> if it's my system or not, so I'm just posting here to see if others
> experience the same problem and if there's interest.
>
> gitweb/gitweb.perl | 18 ++++++++++++++----
> 1 files changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 24b2193..349e734 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -1604,7 +1604,10 @@ sub format_author_html {
> my $author = chop_and_escape_str($co->{'author_name'}, @_);
> return "<$tag class=\"author\">" .
> git_get_avatar($co->{'author_email'}, -pad_after => 1) .
> - $author . "</$tag>";
> + $cgi->a({-href => href(action=>"search", hash=>$hash,
> + searchtext=>$co->{'author_name'},
> + searchtype=>"author"), class=>"list"}, $author) .
> + "</$tag>";
> }
>
> # format git diff header line, i.e. "diff --(git|combined|cc) ..."
> @@ -3373,10 +3376,13 @@ sub git_print_authorship {
> my $co = shift;
> my %opts = @_;
> my $tag = $opts{-tag} || 'div';
> + my $author = $co->{'author_name'};
>
> my %ad = parse_date($co->{'author_epoch'}, $co->{'author_tz'});
> print "<$tag class=\"author_date\">" .
> - esc_html($co->{'author_name'}) .
> + $cgi->a({-href => href(action=>"search", searchtext=>$author,
> + searchtype=>"author"), class=>"list"},
> + esc_html($author)) .
> " [$ad{'rfc2822'}";
> print_local_time(%ad) if ($opts{-localtime});
> print "]" . git_get_avatar($co->{'author_email'}, -pad_before => 1)
> @@ -3395,8 +3401,12 @@ sub git_print_authorship_rows {
> @people = ('author', 'committer') unless @people;
> foreach my $who (@people) {
> my %wd = parse_date($co->{"${who}_epoch"}, $co->{"${who}_tz"});
> - print "<tr><td>$who</td><td>" . esc_html($co->{$who}) . "</td>" .
> - "<td rowspan=\"2\">" .
> + print "<tr><td>$who</td><td>" .
> + $cgi->a({-href => href(action=>"search",
> + searchtext=>$co->{"${who}_name"},
> + searchtype=>$who), class=>"list"},
> + esc_html($co->{$who})) .
> + "</td><td rowspan=\"2\">" .
> git_get_avatar($co->{"${who}_email"}, -size => 'double') .
> "</td></tr>\n" .
> "<tr>" .
> --
> 1.6.5.1.g53fd
^ permalink raw reply
* Re: [PATCH] bash completion: complete refs for git-grep
From: Junio C Hamano @ 2009-10-12 23:42 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Thomas Rast, git
In-Reply-To: <20091012142710.GI9261@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Thomas Rast <trast@student.ethz.ch> wrote:
>> > So I'll roll a simpler patch that just always (before --) completes
>> > refs instead, if that's ok.
>
> Hard to argue with that logic. :-)
>
> Acked-by: Shawn O. Pearce <spearce@spearce.org>
Thanks.
>
>> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
>> index 6fd7e1d..b08cd77 100755
>> --- a/contrib/completion/git-completion.bash
>> +++ b/contrib/completion/git-completion.bash
>> @@ -1048,7 +1048,8 @@ _git_grep ()
>> return
>> ;;
>> esac
>> - COMPREPLY=()
>> +
>> + __gitcomp "$(__git_refs)"
>> }
>
> --
> Shawn.
> --
> 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
^ permalink raw reply
* Re: [PATCH] bisect reset: Allow resetting to any commit, not just a branch
From: Junio C Hamano @ 2009-10-12 23:41 UTC (permalink / raw)
To: Anders Kaseorg; +Cc: git
In-Reply-To: <alpine.DEB.2.00.0910121708030.5105@dr-wily.mit.edu>
Anders Kaseorg <andersk@MIT.EDU> writes:
> I had in mind only one case where ‘git bisect reset <commit>’ would be
> useful. I often don’t even remember what commit I was on before I started
> a bisect, much less believe that I want to immediately switch back to it.
> I would prefer to be able to clean the bisection state without checking
> out another commit at all, because that takes forever and invalidates my
> compiled tree. This is what ‘git bisect reset HEAD’ would do if it
> worked.
I am not sure what "removing bisect states" really buys you.
If having bisect states somehow interferes what you need to do in order to
decide which commit you want to switch to, it may make sense to do 'git
bisect reset HEAD' or 'git bisect stop', before starting whatever you need
to do to make that decision.
But I do not know how it hurts to still have bisect states around, in
order to find where you want to go next. Could you elaborate?
But your explanation "I often don't even remember" makes sense to me.
I would understand it, if not agreeing that I also am often in that
situation myself", if somebody does not even care which commit he was on
before starting the bisection, but knows (or is willing to decide at that
point) which branch (or even a specific commit, while still being
detached) he wants to switch to. And it would make sense to avoid an
extra checkout that snaps back to the pre-bisection commit before
switching to the new state he has chosen.
So in that sense, I would agree with your original patch more than I would
agree with what you suggested as an alternative (i.e. "git bisect stop"
which is what "git bisect reset HEAD" would do if we do not verify the
argument is the name of an existing branch) in your response.
I am inclined to ask you to come up with a paragraph in the documentation
to discuss how the optional <branch> (now it will be <commit>) parameter
to the reset subcommand is meant to be used and re-submit the original
patch, perhaps with an updated commit log message. "Allow resetting to
any" said only what the patch does, without saying why such a mode of
operation was even a good thing to begin with.
Thanks.
^ permalink raw reply
* Re: [PATCH/RFC 3/4] git check-ref-format --print
From: Junio C Hamano @ 2009-10-12 23:36 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Jens Lehmann, git, Shawn O. Pearce
In-Reply-To: <20091012053141.GD11106@progeny.tock>
Jonathan Nieder <jrnieder@gmail.com> writes:
> In the future, it would be very nice if this command could be
> modified to transform Unicode ref names to some appropriate
> normalization form, to make Unicode ref names usable in Mac OS X,
> too, and less confusing everywhere.
I do not disagree with a desire to help fixing the unicode insanity on
that platform, but I suspect that check-ref-format is a wrong place to
tackle the issue. You would need a similar filter for outputs from the
likes of ls-files and "diff --name-only", iow, anything that deal with
pathnames, no?
It would have be something like "check-ref-format --print | iconv ..."
pipeline (conceptually, if not forcing the pipeline to the end users, that
is).
Also are people happy with "--print"? I was waiting for others to reword
it to "--normalize" or something like that. In your documentation you
explain it to "canonicalize", and in your tests you name the output
"normalized". I am fine with either wording, but would like to see us
using only one, not both.
Thanks.
^ permalink raw reply
* Re: [PATCH/RFC 3/4] git check-ref-format --print
From: Shawn O. Pearce @ 2009-10-12 23:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, Jens Lehmann, git
In-Reply-To: <7veip8e302.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> I understand that you prefer the latter between "there is no tool; the
> caller is responsibile to make sure it feeds us canonical representation"
> and "there is a tool that makes a slightly malformed string into canonical
> form for the callers to use before calling us." And that would be my
> preference between these two as well.
...
> But now I have spelled this out, I do not see much upside for rejecting,
> and more importantly, I think it would be an independent issue. We can
> reject or just keep normalizing silently, and a tool to show the
> normalized name would be useful and necessary regardless of that.
I agree with the last paragraph here, we shouldn't reject, but
instead keep the current state but encourage tools to use the new
canonical print tool to clean up a name if they want to hang onto the
string the user entered and it needs to exactly match for-each-ref
sort of output.
--
Shawn.
^ permalink raw reply
* Re: gitweb - bare repos integration - owner info in description file
From: Miklos Vajna @ 2009-10-12 23:19 UTC (permalink / raw)
To: Eugene Sajine; +Cc: Johannes Schindelin, Jakub Narebski, git
In-Reply-To: <76c5b8580910121448q67edd935wb189c8a6f9af2f2e@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 492 bytes --]
On Mon, Oct 12, 2009 at 05:48:14PM -0400, Eugene Sajine <euguess@gmail.com> wrote:
> Yes, I might be stubborn, but is just because i feel that i can
> contribute into making git better, although I'm not a developer.
In a distrubuted environment, there is no need to define who is a
developer and who is not. And contributing is allowed to anyone as long
as you sign the Develoer's Certificate of Origin. :)
(See
http://repo.or.cz/w/git.git?a=blob;f=Documentation/SubmittingPatches;hb=HEAD)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* git-pack-objects gitattributes?
From: Nasser Grainawi @ 2009-10-12 23:00 UTC (permalink / raw)
To: Git Mailing List
Hello,
I'm trying to avoid doing delta compression on a number of large binary files.
I got a suggestion to use $GIT_DIR/info/attributes and a line like this:
*.bin -delta
This doesn't seem to show a big improvement (and honestly I can't find where in
the git-pack-objects source the value of this attribute is used).
Could someone shed some light on this attribute and any other improvements I
could make for efficiently serving up a repo over git-daemon with near-weekly
revisions of 100MB+ files?
Thanks,
Nasser
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2009, #02; Sun, 11)
From: Junio C Hamano @ 2009-10-12 22:52 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091012051442.GB23007@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sun, Oct 11, 2009 at 08:18:17PM -0700, Junio C Hamano wrote:
>
>> * jk/1.7.0-status (2009-09-05) 5 commits.
>> - docs: note that status configuration affects only long format
>> (merged to 'next' on 2009-10-11 at 65c8513)
>> + commit: support alternate status formats
>> + status: add --porcelain output format
>> + status: refactor format option parsing
>> + status: refactor short-mode printing to its own function
>> (this branch uses jc/1.7.0-status.)
>>
>> Gives the --short output format to post 1.7.0 "git commit --dry-run" that
>> is similar to that of post 1.7.0 "git status".
>>
>> * jc/1.7.0-status (2009-09-05) 4 commits.
>> (merged to 'next' on 2009-10-11 at 9558627)
>> + status: typo fix in usage
>> + git status: not "commit --dry-run" anymore
>> + git stat -s: short status output
>> + git stat: the beginning of "status that is not a dry-run of commit"
>> (this branch is used by jk/1.7.0-status.)
>>
>> With this, "git status" is no longer "git commit --dry-run".
>
> Hmm. I thought you wanted to re-order some of these for to put the
> porcelain and short formats into v1.6.6, but leave the status switchover
> for v1.7.0.
We could build an alternate history between 3fa509d..46b77a6, revert the
merges 9558627 and 65c8513, and merge the alternate history. But is the
short format support so solid that it deserves to be in 1.6.6 in the
current shape?
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Junio C Hamano @ 2009-10-12 22:49 UTC (permalink / raw)
To: Thomas Rast
Cc: Johannes Schindelin, Euguess, Mikael Magnusson, Matthieu Moy,
Jeff King, Jay Soffian, git
In-Reply-To: <200910122340.13366.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Your idea is also a backwards incompatible change, so we can just as
> well implement the original suggestion and force scripts (or us) to
> use some other means when they want to detach. Say, why not just
> invent an option along the lines of
>
> git checkout {-d|--detach} $ref
>
> to make it explicit.
Or can't you go the other way, say
git checkout -t $remote_tracking
to create a local branch forking from the named remote tracking branch?
^ permalink raw reply
* Re: Filesystem has no item: Working copy path [...] does not exist in repository at /usr/bin/git-svn line 3856
From: Eric Wong @ 2009-10-12 22:45 UTC (permalink / raw)
To: Daniele Segato; +Cc: Git Mailing List
In-Reply-To: <1255382764.15646.5.camel@localhost>
Daniele Segato <daniele.bilug@gmail.com> wrote:
> In this case the repo was public, what should I do to debug some git-svn
> issue like that if I encounter a problem with a non-public repo?
> May be there is some debug flag I could enable? Or I had to
> guess/explore the svn tree?
I rely on the output of "svn log -v" extensively.
I'll also use strace, ltrace, tcpdump and/or put print statements
(combined with Data::Dumper) in various places of git-svn.
Unfortunately the git-svn code is quite ugly and I still haven't had the
time or energy to clean it up myself :<
--
Eric Wong
^ permalink raw reply
* Re: Git: "No you can't handle my root!" (?)
From: sylvain @ 2009-10-12 22:04 UTC (permalink / raw)
To: Daniele Segato; +Cc: git
In-Reply-To: <1255383459.15646.10.camel@localhost>
Quoting Daniele Segato <daniele.bilug@gmail.com>:
> Il giorno lun, 12/10/2009 alle 01.28 -0400, sylvain@demarque.qc.ca ha
> scritto:
>> localhost / # git init
>
> I don't see the point of using git on the root directory :)
>
> but that made me think that it could actually be a good idea
> for /etc/ :)
> I happen to modify some configuration and then I forgot which one... and
> sometimes updates broke something
>
>
> And that make me think of another question...
>
> is there a way to have a git repo for a subset of directory that match a
> pattern?
>
> for instance...
>
> can I have a git report of $HOME/.* (without . and ..)? (all user
> setting)
>
> Or better: provide a list of directory under $HOME I want to track
>
> Instead of providing the list of directory I want to ignore i would like
> to provide the list of the directory and files I want to track :)
>
> I probably am going out of topic here but I hope you forgive me :)
I am still a Git newbee, but I am using GNU/Linux for a long time now.
I have just reformatted my disk and installed Gentoo and I have to
setup all these little things all over again. Since I clean install
only every couple of years, I often forget some details, etc.
So I am trying something new. I have my "home Git" at "~/.git" and the
"root Git" at "/root/.git" with the GIT_WORK_TREE at "/". Both have
"*" in "info/exclude", so I do provide my list of directories and
files I want to track explicitly by adding them one by one.
My home Git takes care of .bash* .vim* .emacs*, firefox passwords and
bookmarks, etc. My root git takes care of some "/etc", "/var" configs,
etc. (That is the reason why I wanted it on "/", because some
configuration tweaks are done outside of "/etc". Oh, I forgot to
mention "/usr/src/linux/.config")
My hope is that next time I'll clean install my system, I won't have
to backup my whole disk and then mount it again to recover configs
pieces by pieces. I'll just copy my two Git repositories and I'll
should be OK.
All praise the Git. :-)
^ permalink raw reply
* Re: Git: "No you can't handle my root!" (?)
From: Avery Pennarun @ 2009-10-12 21:57 UTC (permalink / raw)
To: Daniele Segato; +Cc: Git Mailing List
In-Reply-To: <1255383459.15646.10.camel@localhost>
On Mon, Oct 12, 2009 at 5:37 PM, Daniele Segato <daniele.bilug@gmail.com> wrote:
> can I have a git report of $HOME/.* (without . and ..)? (all user
> setting)
>
> Or better: provide a list of directory under $HOME I want to track
>
> Instead of providing the list of directory I want to ignore i would like
> to provide the list of the directory and files I want to track :)
You can probably do pretty much anything you want by twiddling with
options in .gitignore. You should be able to add "don't ignore" names
by starting them with !, iirc.
Avery
^ permalink raw reply
* Re: [RFC PATCH 0/5] Pretty formats for reflog data
From: Thomas Rast @ 2009-10-12 21:52 UTC (permalink / raw)
To: Jeff King; +Cc: Jef Driesen, Nanako Shiraishi, git
In-Reply-To: <20091012213756.GA12166@coredump.intra.peff.net>
Jeff King wrote:
>
> I'm not sure if people will like having a longer [stash] list in a
> pager than a shorter list without one (I personally can't remember
> ever using "git stash list", so I have no strong opinion).
True. Then again we patched git-stash(1) to recommend stash/pop over
stash/apply, so we should actively show the user that s/he has a long
stash list and may want to apply them somewhere.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Questions about the new
From: Christian Couder @ 2009-10-12 21:54 UTC (permalink / raw)
To: Sergio Callegari; +Cc: Johannes Sixt, git
In-Reply-To: <4AD3619C.6010808@gmail.com>
On Monday 12 October 2009, Sergio Callegari wrote:
> Thanks Johannes for all the detailed explanations
>
> Johannes Sixt <j.sixt <at> viscovery.net> writes:
[...]
> > With grafts you can only change parenthood; with replace entries you
> > can change parenthood *and* all other aspects of a commit (message,
> > author, committer, dates).
> >
> > Hence, replace entries are more general than grafts.
>
> Limiting the discussion to commit objects, I think there are two
> possible scenarios.
>
> 1) You create new commits objects as needed
> 2) You do not.
>
> If you follow 1), I believe grafts and replace entries have exactly the
> same flexibility.
>
> If I happen not to like commit B in A---B---C and I want A---B'---C
> where B' has
> completely different aspects from B I can either replace B by B' or
> graft away
> B, pretending that the parent of A is B
You mean "pretending that the parent of C is A", right?
> But there are many things that can be done with grafts merely adding a
> graft (e.g. cutting away a part of history, joining history), that
> cannot be done with replace entries without creating new commits objects.
Yes, but when you create a graft, you add a new line in the graft file. You
don't get the grafts for free.
> I was asking because I was wandering whether replace entries were first
> or later
> meant to make grafts deprecated. I hope not, because for a few things
> working on
> arcs seems still nice.
I don't think they will be deprecated soon. And anyway there will probably
be a warning when a graft is used if it is deprecated.
[...]
> > > Conversely, I guess
> > > you can always simulate a replace entry with the graft mechanism,
>
> without the
>
> > > need to add any extra commit object. Am I overlooking something?
> >
> > You cannot; see above.
>
> Well, I meant for what regards commit objects only.
>
> If I want to replace some commit X by some commit X' I merely need to
> modify the
> parent information of all the commits that are child of X so that they
> pretend
> to be child of X', or am I missing something?
If you use git replace you just need to create commit X' and then use "git
replace X X'". If you use grafts, yes, you have to modify the parent
information of all the commits that are child of X.
> > You can even replace tree objects and blob objects
> > using replace entries, IIUC, but you cannot do that with grafts.
>
> Definitely right!
>
> > > 2) Is it currently possible to use a replace entry to replace a
>
> commit object
>
> > > with nothing? Namely if B has A as its sole parent, is it possible
>
> to have a
>
> > > replace entry such as A-sha1 becomes null, to pretend that B is a
>
> hierarchy
>
> > > root?
> >
> > Sure. Just make a commit object that does not have parents.
>
> OK, you need to create a new commit object. At the beginning for some
> reason I
> thought that you could replace an object
> with "nothing" or 00000000000000000000000000000000000000000000
>
> > > 3) If I remember correctly, there was a reason why grafts were not
>
> considered
>
> > > suitable for transferring across repos. Can someone remind me about
>
> it? How
>
> > > does the replace mechanism address this issue?
> >
> > The problem with grafts was that, for example, git-pack-objects
>
> obeyed the
>
> > graft, and could create a broken repository by removing grafted-away
> > objects. And since git-fsck also obeyed the graft, it did not notice
> > the breakage.
> >
> > OTOH, history walkers (upload-pack, send-pack, pack-objects) and fsck
> > never obey replace entries in the history. But they do keep track of
> > them (and the history that they reference) because they are referenced
>
> from the
>
> > refs/replace namespace.
>
> Thanks for the explanation. Can this be made possible for grafts too?
> Wouldn't
> it be a matter of having history walkers never obey grafts but keep track
> of them (i.e. of the history of the parenthood they reference)?
The problem is that grafts are special, so all the history walking commands
should be changed to deal with them specially. With the replace mechanism,
commits and refs are used, and all the commands already know how to deal
with them.
> Like we have "annotated" or heavyweight tags living as objects in the
> database,
> would it be possible or make sense to have annotated grafts or replace
> entries,
> so that one can express why, by whom and when history was changed?
There is a patch series about "notes" floating around that deals with
annotating any commit. So it could be used for that.
And anyway when you create the replacement commit, you can state in the
commit message that it is a replacement commit, who created it, etc.
Regards,
Christian.
^ permalink raw reply
* Re: gitweb - bare repos integration - owner info in description file
From: Eugene Sajine @ 2009-10-12 21:48 UTC (permalink / raw)
To: Johannes Schindelin, Jakub Narebski; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0910120201350.4985@pacific.mpi-cbg.de>
Hi,
Somebody from development camp recently complained here that there is
no many end users "chiming" about issues in the mailing list. Well,
don't tell i didn't try;)
First I tried to use gitweb.url, gitweb.description and gitweb.owner
files and none of them worked... gitweb is unable to pickup the info
from those files.
Although it successfully interactively picks up info from description
and cloneurl files. I didn't find a substitution for gitweb.owner...
I might be sent to RTFM again, but i would like to bring an attention
to the fact that setting up bare repo with these simplest parameters
as well as setting up gitweb is a USABILITY NIGHTMARE for beginners. I
would even say more: while gitweb is very flexible and powerful, all
its flexibility and power is hidden behind unusable management
interface, which IMHO requires a lot of improvements . Rebuilding to
configure? Perl look-and-feel for configuration variables? I think
this is not the way to configure web applications no matter how smart
and flexible application should be. There are some problems with XML,
I don't care. Let's use simple property file. 1 property file! and let
gitweb read it. don;t like this solution, propose yours..
But leaving the emotions aside and once again -
On Sun, 11 Oct 2009, Jakub Narebski wrote:
>And this would be best left for a custom script creating repositories
>and their git hosting related configuration. Such script of necessity
>would have to be site-specific, or at least contain site-specific
>configuration, like:
>* whether to use gitweb.owner or filesystem uid + GECOS is enough
>* whether to use gitweb.description or description file
>* whether to use gitweb.url, cloneurl file, or let gitweb autogenerate
>clone / fetch URL from base URL
I don't get it. I'm talking specifically about gitweb bundled into git
package by default. It was bundled as i understand to provide full
solution (I don't see any other reason). What the heck is wrong with
continuing to move in this direction? I'm not talking about to enforce
gitweb usage, but just simplify the setup and configuration of a tool
provided by default...
If the user chooses default solution, what is wrong with providing
some usable way of doing things?
Don't want to use git clone, fine. But, please, please save me from
rebuilding gitweb, creating manually those files and putting info
inside... It is 21st century or what?;)
>* gitosis / gitlite configuration, if needed, or setup of public keys
>for SSH authentication
Are they included into git bundle? I didn't see those tools there...
>* project README.html file, if used
>etc.
Yes, I might be stubborn, but is just because i feel that i can
contribute into making git better, although I'm not a developer. And i
think usability is the thing which all beginners would thank you
for... i understand that this issue is not the end of the world and i
will finally overcome the burden, i will develop my script and stuff,
I hope somebody would support me in this:)
Thanks,
Eugene
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Thomas Rast @ 2009-10-12 21:40 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Euguess, Mikael Magnusson, Matthieu Moy, Jeff King, Jay Soffian,
git
In-Reply-To: <alpine.DEB.1.00.0910120941150.4985@pacific.mpi-cbg.de>
Johannes Schindelin wrote:
> On Tue, 6 Oct 2009, Euguess@gmail.com wrote:
> > in case if you didn't do that and you try to checkout you will end up
> > having detached HEAD which is quite scary;) for non-experienced user and
> > as i see might lead to some unnecessary questions in this list or on IRC
> > channel...
[...]
> One thing one might add for the technically inclined folks (i.e. those who
> need to implement, and to see that Git is in dear need of some
> user-friendliness first): "git checkout" is a porcelain (i.e. a program
> meant for end-user consumption), and as such should not have a problem to
> react to isatty(0) (i.e. "is the input coming directly from the
> console?").
Sadly git-checkout seems to be stuck between being declared a
porcelain, but at the same time being an extremely important command
for scripts all over. (There are probably others in the same place:
reset comes to mind.)
Your idea is also a backwards incompatible change, so we can just as
well implement the original suggestion and force scripts (or us) to
use some other means when they want to detach. Say, why not just
invent an option along the lines of
git checkout {-d|--detach} $ref
to make it explicit. We have to resort to more arcane means to
*reliably* detach anyway, like 'git checkout master^0'. Then in some
future release, git-checkout will start making DWIM branches if the -d
is not given.
And while we're there, --attach would be a nice complement to force
refs/heads/foo to attach.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Git: "No you can't handle my root!" (?)
From: Daniele Segato @ 2009-10-12 21:37 UTC (permalink / raw)
To: sylvain; +Cc: git
In-Reply-To: <20091012012826.7sffggwmm8sk0cc8@webmail.demarque.qc.ca>
Il giorno lun, 12/10/2009 alle 01.28 -0400, sylvain@demarque.qc.ca ha
scritto:
> localhost / # git init
I don't see the point of using git on the root directory :)
but that made me think that it could actually be a good idea
for /etc/ :)
I happen to modify some configuration and then I forgot which one... and
sometimes updates broke something
And that make me think of another question...
is there a way to have a git repo for a subset of directory that match a
pattern?
for instance...
can I have a git report of $HOME/.* (without . and ..)? (all user
setting)
Or better: provide a list of directory under $HOME I want to track
Instead of providing the list of directory I want to ignore i would like
to provide the list of the directory and files I want to track :)
I probably am going out of topic here but I hope you forgive me :)
^ permalink raw reply
* Re: [RFC PATCH 0/5] Pretty formats for reflog data
From: Jeff King @ 2009-10-12 21:37 UTC (permalink / raw)
To: Thomas Rast; +Cc: Jef Driesen, Nanako Shiraishi, git
In-Reply-To: <cover.1255380039.git.trast@student.ethz.ch>
On Mon, Oct 12, 2009 at 11:02:29PM +0200, Thomas Rast wrote:
> > Stash listing is internally just "git log -g refs/stash", so you can
> > pass any formatting or limiting arguments you want there (see the git
> > log documentation for ideas). If no arguments are given, we pass "-10".
>
> This seems fairly arbitrary, doesn't it? My own working theory is
> that Nanako put it in because the git-log|sed construct inherently
> bars any way to a pager, so it needs to be cut short.
Yes, it's arbitrary, though it is probably a reasonable estimate for the
intended use of stash. It's a stack, so you generally are only
interested in the last couple of entries.
What's much worse though is that the logic is not "if you told me how
many to show, show that; otherwise, show 10". Instead it is "if you
gave me no options, default the size of the list. But if you gave me
any options, even if they have nothing whatsoever to do with limiting
the size of the list, then show all".
So something like "git stash list --date=relative" suddenly shows many more
stashes than just "git stash list". It would be nice to fix that.
> So suppose we could somehow get rid of the |sed... like if we had
> --pretty specifiers for the reflog information.
I'm not sure if people will like having a longer list in a pager than a
shorter list without one (I personally can't remember ever using "git
stash list", so I have no strong opinion).
But certainly the idea of adding pretty format specifiers to access
reflog data seems like a good idea on its own.
-Peff
^ permalink raw reply
* Re: [PATCH] bisect reset: Allow resetting to any commit, not just a branch
From: Anders Kaseorg @ 2009-10-12 21:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr5t8coex.fsf@alter.siamese.dyndns.org>
On Mon, 12 Oct 2009, Junio C Hamano wrote:
> I offhand do not see a good rationale for such a shortcut to finish
> bisect and switch to another branch (IOW, I understand "it is shorter to
> type", but I do not see "it is often done and very useful"), but I am
> open to be enlightened by a workflow where such a shortcut is useful.
I agree that ‘git bisect reset <branch>’ is a confusing shortcut. It only
really made sense before Git supported detached HEADs, and you needed to
be on a branch all the time. I think that lifting the arbitrary
restriction to branch names makes it less confusing, but if you want to
remove the argument altogether, that would eliminate the confusion
entirely.
I had in mind only one case where ‘git bisect reset <commit>’ would be
useful. I often don’t even remember what commit I was on before I started
a bisect, much less believe that I want to immediately switch back to it.
I would prefer to be able to clean the bisection state without checking
out another commit at all, because that takes forever and invalidates my
compiled tree. This is what ‘git bisect reset HEAD’ would do if it
worked.
Perhaps it makes sense to add a command that just clears the bisection
state. ‘git bisect stop’?
Anders
^ 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