* Re: [RFCv4 2/3] gitweb: add patches view
From: Jakub Narebski @ 2008-12-16 10:16 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <cb7bb73a0812160149j1dcaefccv1caf4a2e589ffebb@mail.gmail.com>
Giuseppe Bilotta wrote:
> On Tue, Dec 16, 2008 at 4:14 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>> On Sat, 6 Dec 2008 16:02, Giuseppe Bilotta wrote:
>>
>>> The only difference between patch and patches view is in the treatement
>>> of single commits: the former only displays a single patch, whereas the
>>> latter displays a patchset leading to the specified commit.
>>
>> I like that fact that we have "patches" action which intent is to
>> show series of patches, and "patch" action which intent is to show
>> single patch. I'm just not sure if "patch" view should not simply
>> ignore $hash_parent...
>
> I had doubts on this myself. In the end I decided to make patch
> consider hash_parent if present because IMO it's what a user would
> expect in case e.g. of hand-crafted URLs.
Ah. I can understand that.
[...]
>>> sub git_commitdiff {
>>> my $format = shift || 'html';
>>> + # for patch view: should we limit ourselves to a single patch
>>> + # if only a single commit is passed?
>>> + my $single_patch = shift && 1;
>>
>> What does this "shift && 1" does? Equivalent of "!!shift"?
>> Is it really needed?
>>
>> Perhaps it would be better to use %opts trick, like for some other
>> gitweb subroutines (-single=>1, or -single_patch=>1, or -nmax=>1)?
>> Or perhaps not...
>
> It would be MUCH better, I'll do it this way. I'll pass the -single
> param in both cases, having value true/false, even though the false
> case is not needed since undef is false in perl anyway. (I like
> symmetry.)
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFCv4 3/3] gitweb: link to patch(es) view from commit and log views
From: Giuseppe Bilotta @ 2008-12-16 11:14 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200812161114.35336.jnareb@gmail.com>
On Tue, Dec 16, 2008 at 11:14 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> You lost CC, somehow...
Duh, clicked the wrong button.
>>> I wonder if it would make sense to pass
>>>
>>> href(..., hash_parent => $commitlist[-1]{'id'}, ...)
>>>
>>> here. But I think having separate "patches" action, with intent being
>>> displaying series of patches, is a better solution. This way you can
>>> see in URL and in the page title (thus also in window title, or in
>>> bookmark name) if it is single patch or patch series (perhaps consisting
>>> of single patch).
>>
>> I'm not sure I'm following you here. Do you mean as in manually adding
>> the parent endpoint to the URL when it's not specified in the log view
>> itself? I think that would change the behaviour for > 100 patches.
>
> First, I meant here that having separate "patches" action is a good
> idea in itself, whether we pass explicitly and always $hash_parent
> parameter here or not.
I'm not too sure about that. Do we pass the actual hash parent, or
just the last patch that would be included due to the patch limit?
This, btw, is an issue that should resolved with patch view: it should
warn when the patch limit is reached before all intended patches are
output. I'm just not sure about how to do it.
> Second, I haven't thought about interaction with (short)log
> pagination; in $patch_max < 0, i.e. unlimited patches, and most
> common case of running 'shortlog' action without 'hp' (hash_parent)
> limiter used, one would make 'patches' limited to page size,
> other unlimited. On one hand side limiting to page size makes
> "patches" be more of equivalent of current "shortlog" view; on the
> other hand it makes 'unlimited' actually be limited to page size,
> at least in this situation...
Consider that switching from log to shortlog view doesn't respect
pagination (e.g. if you're on page 3 of shortlog and click on log you
go to page 1 of log) I would be inclined to keep patches behaviour
independent of log view pagination.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: git-scm.com transition
From: Petr Baudis @ 2008-12-16 11:41 UTC (permalink / raw)
To: Scott Chacon; +Cc: git
In-Reply-To: <d411cc4a0812151007n1be9ce95h92c8c11592ea5f9d@mail.gmail.com>
Hi,
On Mon, Dec 15, 2008 at 10:07:05AM -0800, Scott Chacon wrote:
> I've been working on some docs, like an easy reference, that I could
> put up at git-scm.com. I was wondering if we were still planning on
> transitioning the site from git.or.cz -> git-scm.com?
sure - I just need to be prodded about it, as I said. ;-)
> Is there anything I need to do to help you with that? Are there any
> elements missing still?
hmm... I'm really busy before the end of the year, but this should
take just a really short while by now, so let's see if there are still
some nits:
"$ git clone git://github.com/git/hello-world.git" on the
frontpage overflows from the box for me, and so does "git commit -m
'Initial commit'" in the other box. I work on smallish notebook with
1024x768 resolution, but there are still wide white stripes on the
sides.
Mention FAQ in the "Got a question?" box?
Migrate the SVN crash course to git-scm.com too? Would make
sense, imho. Or maybe we can just throw it on the wiki.
Has anyone reviewed " Pragmatic Version Control Using Git by
Travis Swicegood " if we advertise it on the homepage? I remember
looking at some very early preview and feeling quite uncomfortable
about it. Mentioning a book on the homepage is some kind of an
endorsement.
Merge "Multimedia" into "Videos"?
I'm wondering if the "Related Tools" section shouldn't get a
kind of facelift (as e.g. by now imho people are perceiving gitk,
git-gui and gitweb all as integral git components, you might want to
mention TopGit instead of Cogito, etc.) and the 4x4 format is probably
not too appropriate (the hosting sites aren't a natural fit there, and I
chose it originally only to reduce the vertical length of the
single-page homepage). But that's certainly not a blocking issue for the
redirect.
--
Petr "Pasky" Baudis
The average, healthy, well-adjusted adult gets up at seven-thirty
in the morning feeling just terrible. -- Jean Kerr
^ permalink raw reply
* git filter-branch and superproject
From: Sergio Callegari @ 2008-12-16 11:56 UTC (permalink / raw)
To: git
Hi,
once a sub-project has been rewritten by filter branch, there is a problem with
references in superproject.
This is obviously a case where something "has been published" so filter-branch
is not a good idea. However, super-projects are a very special case of
publication since they might be "in full control" of whom did the rewriting of
their submodules.
Is there a way to filter branch the superproject so that whatever commit is
referenced that is in refs/original/something in the subproject gets updated to
the corresponding rewritten commit (or an error is given if such a
correspondance does not exist)?
Namely, can filter-branch on the subproject deliver a "commit conversion table"
that can then be fed to a filter-branch in a superproject?
^ permalink raw reply
* Undo a git stash clear
From: Alexander Gladysh @ 2008-12-16 12:07 UTC (permalink / raw)
To: git, git-users
Hi, list!
I've stashed some valuable changes and then I accidentally did git
stash clear. (Yes, today is not my day).
Is it possible to restore stashed changes?
Alexander.
^ permalink raw reply
* Re: Undo a git stash clear
From: Johannes Schindelin @ 2008-12-16 12:10 UTC (permalink / raw)
To: Alexander Gladysh; +Cc: git, git-users
In-Reply-To: <c6c947f60812160407l1b2593e1pde817f5cfb091d59@mail.gmail.com>
Hi,
On Tue, 16 Dec 2008, Alexander Gladysh wrote:
> I've stashed some valuable changes and then I accidentally did git stash
> clear. (Yes, today is not my day).
>
> Is it possible to restore stashed changes?
You might find them with "git fsck --lost-found".
Hth,
Dscho
^ permalink raw reply
* Re: Undo a git stash clear
From: Jeff King @ 2008-12-16 12:12 UTC (permalink / raw)
To: Alexander Gladysh; +Cc: git, git-users
In-Reply-To: <c6c947f60812160407l1b2593e1pde817f5cfb091d59@mail.gmail.com>
On Tue, Dec 16, 2008 at 03:07:28PM +0300, Alexander Gladysh wrote:
> I've stashed some valuable changes and then I accidentally did git
> stash clear. (Yes, today is not my day).
>
> Is it possible to restore stashed changes?
Try git-fsck; it should report some dangling commits (i.e., commits that
are in the object db but aren't reachable by any refs). Then you can
either pull the changes out directly (try git cherry-pick -m1 $sha1) or you
can even restore it as a stash (git update-ref -m oops refs/stash
$sha1).
-Peff
^ permalink raw reply
* Re: Undo a git stash clear
From: Jonathan del Strother @ 2008-12-16 12:12 UTC (permalink / raw)
To: Alexander Gladysh; +Cc: git, git-users
In-Reply-To: <c6c947f60812160407l1b2593e1pde817f5cfb091d59@mail.gmail.com>
On Tue, Dec 16, 2008 at 12:07 PM, Alexander Gladysh <agladysh@gmail.com> wrote:
> Hi, list!
>
> I've stashed some valuable changes and then I accidentally did git
> stash clear. (Yes, today is not my day).
>
> Is it possible to restore stashed changes?
I ran into this exact problem on Friday. Some helpful person on IRC
suggested using
git fsck | grep commit | cut -d' ' -f3 | while read hash; do git
rev-parse --verify --quiet $hash^2 && echo $hash; done | xargs git
show
Which will show a huge list of lost changes. Once you find the change
you're interested in, you can cherry-pick its sha1.
^ permalink raw reply
* Re: Undo a git stash clear
From: Matthieu Moy @ 2008-12-16 12:20 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Alexander Gladysh, git, git-users
In-Reply-To: <57518fd10812160412j1edc2ea0mff732825f1f6c4a2@mail.gmail.com>
"Jonathan del Strother" <maillist@steelskies.com> writes:
> On Tue, Dec 16, 2008 at 12:07 PM, Alexander Gladysh <agladysh@gmail.com> wrote:
>> Hi, list!
>>
>> I've stashed some valuable changes and then I accidentally did git
>> stash clear. (Yes, today is not my day).
>>
>> Is it possible to restore stashed changes?
>
> I ran into this exact problem on Friday. Some helpful person on IRC
> suggested using
(and the obvious advice before anything else : don't "git gc", don't
"git prune", and if possible back-up the repository before anything
else)
--
Matthieu
^ permalink raw reply
* git-svn and empty directories
From: Thomas Jarosch @ 2008-12-16 12:53 UTC (permalink / raw)
To: Eric Wong, Deskin Miller; +Cc: git
Hello Eric and Deskin,
I'm currently looking into preserving empty directories from a SVN repository
by automatically creating empty .gitignore files for them.
The control flow of the git-svn code is still a jungle to me,
maybe you have a hint how to implement a proof-of-concept code?
I don't think I can just touch a .gitignore file in get_untracked()
and those files will magically turn up in git's index...
Thanks,
Thomas
^ permalink raw reply
* Re: git filter-branch and superproject
From: Boaz Harrosh @ 2008-12-16 13:01 UTC (permalink / raw)
To: Sergio Callegari; +Cc: git
In-Reply-To: <loom.20081216T114923-354@post.gmane.org>
Sergio Callegari wrote:
> Hi,
>
> once a sub-project has been rewritten by filter branch, there is a problem with
> references in superproject.
>
> This is obviously a case where something "has been published" so filter-branch
> is not a good idea. However, super-projects are a very special case of
> publication since they might be "in full control" of whom did the rewriting of
> their submodules.
>
> Is there a way to filter branch the superproject so that whatever commit is
> referenced that is in refs/original/something in the subproject gets updated to
> the corresponding rewritten commit (or an error is given if such a
> correspondance does not exist)?
>
> Namely, can filter-branch on the subproject deliver a "commit conversion table"
> that can then be fed to a filter-branch in a superproject?
>
> --
> 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
>
If I recall correctly, submodule was recently enabled to reference
a soft label, like a branch name, instead of an hard UID. Look it up
in the newest git.
But your post brings up another concern. The HEAD referenced by the
superproject does not have any hold in the subproject. So if the
subproject under-gone a git-gc the reference UID might disappear, as
in your case. I wish the git-submodule command would create a TAG or BRANCH
in the subproject of all referenced HEADs, so they will not disappear
in future maintenance of the subproject tree. (And it could be very
informative when viewing in gitweb). The subproject TAG name could, for
example, be the commit and date of the superproject's submodule commit.
Boaz
^ permalink raw reply
* Re: [PATCH v3] git-svn: Make following parents atomic
From: Thomas Jarosch @ 2008-12-16 13:22 UTC (permalink / raw)
To: Deskin Miller
Cc: Eric Wong, git, Junio C Hamano, Thomas Leonard,
Björn Steinbrink
In-Reply-To: <20081208233523.GB21675@hand.yhbt.net>
On Tuesday, 9. December 2008 00:35:23 you wrote:
> > To fix this, when we initialise the Git::SVN object $gs to search for
> > and perhaps fetch history, we check if there are any commits in SVN in
> > the range between the current revision $gs is at, and the top revision
> > for which we were asked to fill history. If there are commits we're
> > missing in that range, we continue the fetch from the current revision
> > to the top, properly getting all history before using it as the parent
> > for the branch we're trying to create.
> >
> > Signed-off-by: Deskin Miller <deskinm@umich.edu>
>
> Looks good Deskin, thanks
This patch has a very nice side effect, it seems to fix a long standing
problem with subversion imports. Here's the original report:
https://kerneltrap.org/mailarchive/git/2008/4/8/1377514/thread
Many of the 121 tags in my SVN tree were created by cvs2svn,
which often created tags by copying older revisions
of sub paths into the current tree.
I've written a small script that checks out the same tag via git and SVN.
It runs a diff against those two trees and saves the result to a file
so I can manually check it. With git-svn from 1.6.0.5, the results are
horrible: Over 30% of the tags didn't match the code in SVN.
With git-svn from 1.6.1rc3, my first two manual probes look very good.
Right now I'm reimporting the svn tree and will have the results
of the complete "checkout comparison" tomorrow.
Cheers,
Thomas
^ permalink raw reply
* Re: [TortoiseGit]: Anyone seen this challenge?
From: Tim Visher @ 2008-12-16 13:24 UTC (permalink / raw)
To: Frank Li; +Cc: Geoffrey Lee, Scott Chacon, git
In-Reply-To: <1976ea660812152006y7ae79a1bhfdcdb730c6a687a5@mail.gmail.com>
On Mon, Dec 15, 2008 at 11:06 PM, Frank Li <lznuaa@gmail.com> wrote:
> Scott, you help set up account on github for TortoiseGit project.
I guess you'll notify the rest of us when this project gets set up, Li?
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* Re: [PATCH] gitweb: unify boolean feature subroutines
From: Matt Kraai @ 2008-12-16 14:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski
In-Reply-To: <7vmyewqypk.fsf@gitster.siamese.dyndns.org>
On Tue, Dec 16, 2008 at 01:03:03AM -0800, Junio C Hamano wrote:
> But a change to the function signature of feature subroutines is not
> something I'd like to apply while other series that want to add new
> features are still cooking. How about doing these two patches as the
> first thing that goes to 'next' after 1.6.1, and then force other series
> rebase on top of your change? Alternatively, we could make you wait until
> other series do settle in 'next' and then apply your change rebased on
> them, but I think that is probably less optimal.
OK, I'll resubmit the patches on top of 'next' once 1.6.1 is
released. Thanks for your help,
--
Matt http://ftbfs.org/
^ permalink raw reply
* [PATCH] git-daemon documentation: use {tilde}
From: Miklos Vajna @ 2008-12-16 15:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Use '{tilde}' instead of '~', becase the later does not appear in the
manpage version, just in the HTML one.
Noticed by gonzzor on IRC.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
Documentation/git-daemon.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt
index f1a570a..36f00ae 100644
--- a/Documentation/git-daemon.txt
+++ b/Documentation/git-daemon.txt
@@ -110,9 +110,9 @@ OPTIONS
--user-path::
--user-path=path::
- Allow ~user notation to be used in requests. When
+ Allow {tilde}user notation to be used in requests. When
specified with no parameter, requests to
- git://host/~alice/foo is taken as a request to access
+ git://host/{tilde}alice/foo is taken as a request to access
'foo' repository in the home directory of user `alice`.
If `--user-path=path` is specified, the same request is
taken as a request to access `path/foo` repository in
--
1.6.1.rc1.35.gae26e.dirty
^ permalink raw reply related
* Re: git-diff should not fire up $PAGER if there is no diff
From: jidanni @ 2008-12-16 17:38 UTC (permalink / raw)
To: peff; +Cc: git
In-Reply-To: <20081216040722.GA4551@coredump.intra.peff.net>
Oh barf, having LESS=F in one's environment messes up less +G:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508919
^ permalink raw reply
* Re: [PATCH] git-daemon documentation: use {tilde}
From: Michael J Gruber @ 2008-12-16 17:38 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, git
In-Reply-To: <1229442492-11993-1-git-send-email-vmiklos@frugalware.org>
Miklos Vajna venit, vidit, dixit 16.12.2008 16:48:
> Use '{tilde}' instead of '~', becase the later does not appear in the
> manpage version, just in the HTML one.
Curiously, "git help daemon" (which execs "man git-daemon") displays the
tilde but "man git-daemon" does not (nor does "konqueror
man:git-daemon"). Humh?
Michael
^ permalink raw reply
* Re: [PATCH] git-daemon documentation: use {tilde}
From: Miklos Vajna @ 2008-12-16 17:50 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Junio C Hamano, git
In-Reply-To: <4947E7B1.2090608@drmicha.warpmail.net>
[-- Attachment #1: Type: text/plain, Size: 364 bytes --]
On Tue, Dec 16, 2008 at 06:38:57PM +0100, Michael J Gruber <git@drmicha.warpmail.net> wrote:
> Curiously, "git help daemon" (which execs "man git-daemon") displays the
> tilde but "man git-daemon" does not (nor does "konqueror
> man:git-daemon"). Humh?
'git help daemon' is wrong for me - without the patch - as well.
(Though I never use the git help foo form.)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Git Notes idea.
From: Govind Salinas @ 2008-12-16 18:43 UTC (permalink / raw)
To: Jeff King; +Cc: Git Mailing List
In-Reply-To: <20081216085108.GA3031@coredump.intra.peff.net>
On Tue, Dec 16, 2008 at 2:51 AM, Jeff King <peff@peff.net> wrote:
> On Tue, Dec 16, 2008 at 02:15:47AM -0600, Govind Salinas wrote:
>
>> I was thinking about possible ideas for my little pet project and I
>> had and idea for way to tack on notes to a commit, or any object
>> really. I know that the idea has been flying around for a long time
>> but there has never been any implementation or a concept that people
>> liked enough to use (unless I have missed something).
>
> I think you look at the previous suggestions, because yours is very
> similar. Which is good, I think, because the current status is that the
> design is good, but nobody has gotten around to working on it yet. So
> maybe you can fix that. :)
>
I was thinking I would do my first implementation in pyrite and if I find
that it works well I will port it.
>> .git/refs/notes contains a tree-id (assuming that using a tree-id
>> will not cause any problems, otherwise a commit object can be used.
>> it does not *need* a history, but it *could* have one).
>
> That is the same as the current proposal, except:
>
> - the proposal is to use a commit, so your notes are version-controlled
>
> - I have suggested supporting multiple note "bases" in the refs/notes
> namespace. This would allow you to share some notes but not others
> (e.g., if you had some automated notes related to a build/test
> system, you might not want to mix those with your human-written
> notes).
>
>> That tree has a structure similar to the layout of .git/objects, where
>> it is 2 letter subdirectories for the notes objects.
>
> I don't think this has been suggested yet, but I'm not sure it is a good
> idea. The usual reason for this split is that many filesystems handle
> large directories badly; that isn't a problem here.
>
I just read the proposal from Johannes, he seems to want to use a
similar layout. However, I would like to modify my proposal slightly
to make it work better when a gc is run. I would modify the tree to
look like this...
let 1234567890123456789012345678901234567890 be the
id of the item that is annotated.
let abcdef7890123456789012345678901234567890 be the
id of the note to be attached
root/
12/
34567890123456789012345678901234567890/
abcdef7890123456789012345678901234567890
This way all the notes are attached to a tree, so that gc won't
think they are unreferenced objects.
> It does reduce the size of the resulting tree objects when a note is
> modified (we make updates to two smaller trees instead of one big tree).
> I don't know if this really matters all that much, since the trees
> will end up deltified in a pack anyway.
>
> And it does make the implementation slightly less simple, since we have
> to deal with two levels of trees.
>
>> Given a git object (commit, tree, blob, tag), use its sha as the
>> path/filename in this tree.
>> If I have a commit 1234567890123456789012345678901234567890 then
>> the notes tree will have a file
>> 12/34567890123456789012345678901234567890
>>
>> That file has a list of sha1s (one per line). These shas are object
>> IDs for blobs that have the notes or whatever that you want attached
>> to the item.
>
> This is slightly different than the current proposal. You are proposing
> that each item have a "list of notes". My thinking was to have "named
> notes" using a tree for each entry full of blobs. So you could look up
> the "foo" note for a given commit, but that note would be a single
> scalar (which could, of course, be interpreted according to its name).
>
>> I think you get the idea. When looking up an item, it should be
>> fairly easy to have the notes tree and subtrees available for doing
>> lookups. And as far as I know stuff under .git/refs can be
>
> It is easy, but it's slow because we have to do a linear search in the
> (potentially huge) notes tree. And that's what held up the initial
> implementation. I did a proof-of-concept a month or so ago that
> pre-seeded an in-memory hash using the tree contents and got pretty
> reasonable performance.
>
Perhaps I am missing something, how is it a linear search?. Since we
are keying off of the sha of the annotated object, using a hashtable for
a cache should be a fairly quick binary search. If you just wanted to
use the tree objects, that should work almost as well since the first tree
will split them up nicely for you.
Also, how large do you expect the list to be under reasonable
circumstances.
>> pushed/pulled even if its not under heads or remotes or tags using
>> already existing machinery. I am not sure, but I think that would
>> satisfy gc operations as well. Also, these trees and blobs never have
>> to be put in the working directory.
>
> Right, though I think one of the benefits of this approach is that you
> _could_ do a checkout on the notes tree if you wanted to do very
> flexible editing.
>
Sure, why not.
>> Does this sound like something that is workable? I thought it might
>> appeal since it uses only features that are already present.
>
> Yes, it sounds workable, though if you diverge from what has already
> been discussed, I think you should make an argument about why your
> approach is better.
>
Well after reading Johannes proposal, I find it to be surprisingly similar
since I had not seen it before. However I think mine is a win in a few ways.
One, it allows multiple notes per object. Two, it plays well with gc. From
what I could follow, the files in his layout just have a ref to the note object
but gc would be required to know about this feature and not remove those
note blobs. Third it allows multiple sets of notes. Although it seems that
at least 1 and 3 have been discussed at some length.
>> This could be extended so that you have different sets of notes under
>> .git/refs/notes/<my note set> or whatever. So that you can have some
>> notes you keep private and some that you publish or whatever.
>
> Oops, I should have read your whole mail. Yes, that is a good idea. :)
>
> For reference, here are the previous discussions that I think are
> relevant:
>
Thanks for the pointers, a couple quick thoughts...
> Some discussion of the interaction of notes and rebase:
> http://thread.gmane.org/gmane.comp.version-control.git/100533
>
On rebasing, I have a couple thoughts. 1) I think it only really makes
sense to make a public annotation to a commit that is public, and
once a commit is public it should not be rebased. 2) We could also
annotate the commit's tree instead of the commit. That would make
it somewhat resistant to rebases, cherry-picks and amends. And
once a tree has changed, the notes are probably less reliable
although the user should be able to force a note or notes to be
carried along.
> Some thoughts from me on naming issues:
> http://article.gmane.org/gmane.comp.version-control.git/100402
>
On naming. I strongly support a ref/notes/sha1/sha1 approach. If
having a type to the note is important, then perhaps the first line of
a note could be considered a type or a set of "tags". This way you
have both naming/typing and one lookup per sha. The only
drawback is that you have to open the blob to see the type. A hybrid
approach that uses refs/notes/acked/sha/sha which is one lookup if
you know the type and the sha of the annotated object before hand
might be worth considering. This would be similar to the public or
private notes that i mentioned before.
> Some thoughts from me on the tree speedup:
> http://article.gmane.org/gmane.comp.version-control.git/101460
>
I guess I must be missing something. I have seen several references
to this not being a binary search several times in the links that you have
here. But I fail to see why a binary search cannot be done. That said, I
would still think that the existing hash table would be the way to go.
> which I think should bring you up to speed. :)
Thanks again.
-Govind
^ permalink raw reply
* Re: [PATCH] git-daemon documentation: use {tilde}
From: Matthieu Moy @ 2008-12-16 18:05 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Miklos Vajna, Junio C Hamano, git
In-Reply-To: <4947E7B1.2090608@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> Miklos Vajna venit, vidit, dixit 16.12.2008 16:48:
>> Use '{tilde}' instead of '~', becase the later does not appear in the
>> manpage version, just in the HTML one.
>
> Curiously, "git help daemon" (which execs "man git-daemon") displays the
> tilde but "man git-daemon" does not (nor does "konqueror
> man:git-daemon"). Humh?
You probably have two manpages because of two git installations. "man"
will take the one in your manpath, and git will try to find the one
corresponding to the version of git you actually launched.
--
Matthieu
^ permalink raw reply
* Re: Git weekly news: 2008-50
From: Felipe Contreras @ 2008-12-16 19:49 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git list
In-Reply-To: <m38wqjg1n1.fsf@localhost.localdomain>
On Sun, Dec 14, 2008 at 12:18 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> "Felipe Contreras" <felipe.contreras@gmail.com> writes:
>
>> This week I'm trying to address some of the issues mentioned here. I
>> still would like people to request user accounts to this blog if they
>> wish to make some git related posts.
>>
>> http://gitlog.wordpress.com/2008/12/13/git-weekly-links-2008-50/
>>
>> == Articles ==
>>
>> Why Subversion does not suck
>> http://blog.assembla.com/assemblablog/tabid/12618/bid/7437/Why-Subversion-does-not-suck.aspx
> [...]
>
> Thanks a lot. I quite like the new format, both HTML version on blog,
> and the format used here in this email.
Cool :)
> P.S. Small nitpick: you have changed the title of blog post, but not
> subject of email.
Ah, thanks, I didn't notice.
--
Felipe Contreras
^ permalink raw reply
* how to work in hirarchical git model?
From: Gili Pearl @ 2008-12-16 22:26 UTC (permalink / raw)
To: git
[Not sure I'm posting to the right mailing list; sorry in advance]
I’m working in a small company with about 15 developers. So far we were all
rebasing our local repos on a single main repo. When one had some new commits,
he rebased them on the main-repo/master and asked the main-repo maintainer to
pull them in. So far so good, but we now considering moving into a three level
model, where we’ll have sub-maintainers that will handle local merges before
they hit the main-repo. I’m not sure I understand how this is supposed to work
and I’d be thankful to get some advice.
Here is one problem I saw when trying to work in the three-level model.
At some point, I had the following setup:
top-level : A----B----C----D
\
\
mid-level1: K----L----M
\
\
low-level1: X----Y
The maintainer of mid-level1 has decided that commits K L M are ready to be
merged into the top-level repo. So he rebased on top-level before asking 'please
pull', but after that the low-level was not able to rebase on the mid-level
any more.
I can understand that the problem is because commit L had become L', and now
low-level1 cannot find L anymore, i.e. now it looks like this:
top-level : A----B----C----D
\
\
mid-level1: K'----L'----M'
\
\
low-level1: X----Y
... but I guess this is not how it should work. So what is the right working
flow for us?
Thanks.
^ permalink raw reply
* git ignore
From: Max Power @ 2008-12-16 22:43 UTC (permalink / raw)
To: git
So I understand how to use the .gitignore file to ignore specific
files/directories that I put in there... is there a way to ignore everything
BUT a given file extension?
--
View this message in context: http://www.nabble.com/git-ignore-tp21043430p21043430.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: git-diff should not fire up $PAGER if there is no diff
From: Stefan Karpinski @ 2008-12-16 22:43 UTC (permalink / raw)
To: Jeff King; +Cc: jidanni, git
In-Reply-To: <20081216074414.GB2468@coredump.intra.peff.net>
On Tue, Dec 16, 2008 at 2:44 AM, Jeff King <peff@peff.net> wrote:
> On Tue, Dec 16, 2008 at 01:35:53AM -0500, Stefan Karpinski wrote:
>
>> > On Mon, Dec 15, 2008 at 7:56 PM, Jeff King <peff@peff.net> wrote:
>> > 2. detect EOF before starting the pager. We in fact already delay
>> > running the pager in the forked process until we have some activity
>> > on the pipe, but I don't know if there is a portable way of
>> > detecting that that activity is EOF without performing an actual
>> > read() call (which is undesirable, since it eats the first byte of
>> > output that should go to the pager).
>>
>> Wouldn't ungetc work? Or is that not portable enough? (It would only
>> work here because the EOF has to be the first character.)
>
> No, it won't work. ungetc works on the buffered stdio object, so it is
> useful for pushing back characters onto the buffer to be read later in
> the program from the same buffer. But in this case, we are going to
> execv() (or on Windows, spawn) the pager, meaning it will throw away
> anything that has been read() from the pipe and put in the buffer.
>
> So we would need a system call to push a character back to the OS, so
> that it was available for read() by the pager process.
Yeah, I realized that after I sent the message. Late night sending bad!
^ permalink raw reply
* Re: git ignore
From: Linus Torvalds @ 2008-12-16 22:53 UTC (permalink / raw)
To: Max Power; +Cc: git
In-Reply-To: <21043430.post@talk.nabble.com>
On Tue, 16 Dec 2008, Max Power wrote:
>
> So I understand how to use the .gitignore file to ignore specific
> files/directories that I put in there... is there a way to ignore everything
> BUT a given file extension?
Something like
*
!*.jpg
to only save the jpegs in your pr0n collection?
The first rule says "ignore everything". The second one says "don't
ignore *.jpg files".
Untested.
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