* The patch documenting --pretty options (oops)
From: Chris Riddoch @ 2006-11-18 6:28 UTC (permalink / raw)
To: git
Hi, folks.
I'm terribly sorry about the repost of my old patch. I fixed it,
adding more information about the rest of the output formats and the
'Merge: ' line, but then accidentally reposted the original one. I
hope this new version addresses your original concerns with my patch,
Junio.
--
epistemological humility
^ permalink raw reply
* Re: [PATCH] Do not ignore hidden refs
From: Junio C Hamano @ 2006-11-18 7:27 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20061118045323.GK7201@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> I don't *need* but it might be nice to have also private heads, for
> possible setups when you declare heads namespace of two repositories
> matching 1:1 but would like to temporarily make a short-lived head in
> one of them or so.
I agree that different classes of heads and tags (not just
"public" vs "private") may come in handy in different workflows.
I think, however, if we (collectively as all the Porcelain
writers although I am not really one of them) are to support it,
they should not make distinction to the core, and it should be
handled with the agreed-upon convention. In other words, if
".bar" were a valid refname to the core then I would agree that
not packing them had definitely been a bug.
And we already have one such convention of using refs/remotes
for tracking branches, which is promoted to become the default
(thus an official BCP).
Personally I established a convention to treat heads/??/* as
"private namespace" while using heads/* as public refs for my
own work (I do that for git.git as people know, and I do that
for my day job project as well). I do not think it is a great
enough convention to be promoted as the official BCP, but it has
been good enough for me, especially commands like "show-branch"
and "tag -l" understands the shell-style filegrobs (e.g
"show-branch master heads/??/*" would show what's yet to be
polished and merged).
^ permalink raw reply
* Re: multi-project repos
From: Junio C Hamano @ 2006-11-18 7:31 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Linus Torvalds, Han-Wen Nienhuys, git
In-Reply-To: <20061118060243.GB2125@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> Junio C Hamano <junkio@cox.net> wrote:
>> Shawn Pearce <spearce@spearce.org> writes:
>> > Although if you have reflog enabled on your current branch there
>> > is a 1 character shorter syntax:
>> >
>> > gitk HEAD@{1}..
>>
>> Are you sure about this? I've seen "next@{1}" to look at
>> history of the named branch, but never history of "HEAD".
>
> Yes. :-)
>
> If the ref name is a symref then we resolve the symref all the
> way down to the real ref before we open and walk the reflog.
> Therefore this works.
True, except if you did:
$ git pull
$ git checkout otherbranch
$ git show HEAD@{1}
My real point was that I was wondering if it also makes sense
for ref-log to record switching branches for the symref itself.
But after sending that message I thought about it a bit more and
concluded that it is not an interesting information. It is more
code that affects unrelated places even if we were to implement
it and without real gain, so let's not log symref itself and
keep the current implementation.
^ permalink raw reply
* Re: [PATCH] Do not ignore hidden refs
From: Shawn Pearce @ 2006-11-18 7:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7vzmapdxki.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Personally I established a convention to treat heads/??/* as
> "private namespace" while using heads/* as public refs for my
> own work (I do that for git.git as people know, and I do that
> for my day job project as well). I do not think it is a great
> enough convention to be promoted as the official BCP, but it has
> been good enough for me, especially commands like "show-branch"
> and "tag -l" understands the shell-style filegrobs (e.g
> "show-branch master heads/??/*" would show what's yet to be
> polished and merged).
We use refs/heads/??/* as "developer specific" namespaces.
That is we use an update hook in our central repository to control
who can push into refs/heads/??/*. If ?? matches the unix account
holder's initials then they can push into that name, otherwise
they can't. This prevents any sort of naming collisions between
developers.
To make things slightly easier I've also suggested that people name
their local branches with the same ??/ prefix as they need to use
on the central repository, thereby making the branch name the same
everywhere. This is actually one reason why git-completion.bash
suggests "??/foo:??/foo" when completing a branch name to git-push.
:)
So I don't think its a great idea to assume by default that
refs/heads/??/* is private to this repository.
Though on second thought maybe we should be using developer private
repositories with object alternates pointing at a central repository.
But that means users have to manipulate URLs to fetch another
developer's branch vs. just using an existing remote.<nick>.url,
which is the main reason we put everything into one repository.
--
^ permalink raw reply
* Re: multi-project repos
From: Shawn Pearce @ 2006-11-18 7:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Han-Wen Nienhuys, git
In-Reply-To: <7vvelddxcx.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> True, except if you did:
>
> $ git pull
> $ git checkout otherbranch
> $ git show HEAD@{1}
>
> My real point was that I was wondering if it also makes sense
> for ref-log to record switching branches for the symref itself.
>
> But after sending that message I thought about it a bit more and
> concluded that it is not an interesting information. It is more
> code that affects unrelated places even if we were to implement
> it and without real gain, so let's not log symref itself and
> keep the current implementation.
I agree completely.
I have no interest in a history of what branches I've recently
been on. All I care about is the history of this branch. And I
consider HEAD to be nothing but a shortcut that always points to
the current branch... so its darn useful for that.
In retrospect CURR may have been a better name for the HEAD symref
but its far too late to even consider changing that, so lets not
go down that road. :-)
--
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Alan Chandler @ 2006-11-18 7:59 UTC (permalink / raw)
To: git
In-Reply-To: <7vr6w5y7to.fsf@assigned-by-dhcp.cox.net>
On Tuesday 14 November 2006 22:36, Junio C Hamano wrote:
...
>
> And I agree with Pasky that fixing UI is hard unless you are
> willing to get rid of historical warts. Syntax of the command
> line arguments the current set of Porcelain-ish takes are
> sometimes just horrible. It may not be a bad idea to start
> building the fixed UI from scratch, using different prefix than
> "git" (say "gu" that stands for "git UI" or "gh" that stands for
> "git for humans").
>
> Of course, it could even be "cg" ;-).
I have been away on business last week and have been following this thread
from the archives. There is a comment I want to make about split of
Porcelain and Plumbing namespaces that is not particularly an answer to this
particular post, but it does seem an appropriate place to insert it.
I think there were three (historic) mistakes in the development of git
- to split git and cogito so that some of the commands started git and some
cg (aided and abetted by putting them in separate repositories).
- to try and make the distinction between plumbing and porcelein a line in
the sand (after all this is exactly why git and cg separated) when in
practice it isn't that straight forward
- for cogito to (initially) not support the internal branches, but in fact
deal with them via cloned repositories
On the other hand, it was a good move to bring gitk and gitweb into the core
repository.
These were not technical mistakes, but social ones.
Much of the discussion on UI warts doesn't exist in the cogito world (not that
I use it at all anymore, despite its more user friendly interface - just
because I didn't want to learn two parallel sets of commands and I prefered
git's branch model so stuck with the slightly less friendly git command set)
but if you look at any of the SCM comparison discussions that happen now,
they are always comparing the core git with the other SCM, not git plus all
its porcelains.
So I think it would be a mistake (which hopefully does seem to be the
concensus reached in the list) to try and introduce new namespaces to the
command set.
--
Alan Chandler
^ permalink raw reply
* [WISH] Store also tag dereferences in packed-refs
From: Marco Costalba @ 2006-11-18 9:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
Time needed to execute git-peek-remote in my box with cold cache currently is:
- git tree 2.347 ms
- linux tree 2.144 ms
And refs are *already* packed in both repos.
Looking at packed-refs file, it contains something like:
d9b0f913ce0508fcc83e642e0241f373428368e5 refs/tags/v1.4.3
4314f5982d2aac08001a977fc0b1b611e858e025 refs/tags/v1.4.3-rc1
while I would need something like git-peek-remote output,
d9b0f913ce0508fcc83e642e0241f373428368e5 refs/tags/v1.4.3
e0b0830726286287744cc9e1a629a534bbe75452 refs/tags/v1.4.3^{}
4314f5982d2aac08001a977fc0b1b611e858e025 refs/tags/v1.4.3-rc1
1965efb1599f59b8e3380335d1fa395e2008a30b refs/tags/v1.4.3-rc1^{}
Because the sha value a tag points to is needed to match against
git-rev-list output so to identify tagged revisions.
Would be possible to store in packed-refs also the dereferenced tag
info, so that cold opening of a repository would be much faster?
Just to give an idea, with warmed up cache, refs reading times are:
- git tree 43 ms
- linux tree 28 ms
Thanks
Marco
P.S: In case it's not clear I don't suggest to read directly the
packed-refs file with the added info, but always to use
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Alan Chandler @ 2006-11-18 11:09 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0611151023160.2591@xanadu.home>
On Wednesday 15 November 2006 15:41, Nicolas Pitre wrote:
> On Wed, 15 Nov 2006, Andy Parkins wrote:
> > * Don't use the name "origin" twice. In fact, don't use it at all. In
> > a distributed system there is no such thing as a true origin.
>
> I agree, sort of. Not because"origin" is ambigous as a name. But
> rather because there is a magic translation from "master" to "origin",
> and I think this is wrong to do that.
>
> As mentioned elsewhere (and let's start using "get" instead of "pull" as
> suggested by Johannes), a "get" should probably always create a branch
> group even if it contains only one branch. This way the remote branch
> called "master" will still be called "master" locally, under the branch
> group used to represent the remote repository. And if a local name is
> not provided then let's just call it "default". This way, amongst the
> remote references, there would be a "default/master" that would be used
> when nothing else is provided by the user. So...
>
> git get repo.com/time_machine.git
>
> would create a local branch named "remotes/default/master" if the remote
> repo has only a master branch.
Why not call it remotes/repo.com/time_machine.git/master and have a
DEFAULT_ORIGIN that is a symref to it in the same way as HEAD is a symref to
a local branch
--
Alan Chandler
^ permalink raw reply
* [PATCH] sparse fix: non-ANSI function declaration
From: Rene Scharfe @ 2006-11-18 12:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
The declaration of discard_cache() in cache.h already has its "void".
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
index-pack.c | 2 +-
read-cache.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/index-pack.c b/index-pack.c
index 042aea8..8331d99 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -90,7 +90,7 @@ static SHA_CTX input_ctx;
static int input_fd, output_fd, mmap_fd;
/* Discard current buffer used content. */
-static void flush()
+static void flush(void)
{
if (input_offset) {
if (output_fd >= 0)
diff --git a/read-cache.c b/read-cache.c
index 97c3867..0f5fb5b 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -844,7 +844,7 @@ unmap:
die("index file corrupt");
}
-int discard_cache()
+int discard_cache(void)
{
int ret;
--
1.4.4
^ permalink raw reply related
* [PATCH] sparse fix: Using plain integer as NULL pointer
From: Rene Scharfe @ 2006-11-18 12:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
Z_NULL is defined as 0, use a proper NULL pointer in its stead.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
archive-zip.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/archive-zip.c b/archive-zip.c
index 28e7352..ae5572a 100644
--- a/archive-zip.c
+++ b/archive-zip.c
@@ -160,7 +160,7 @@ static int write_zip_entry(const unsigne
void *buffer = NULL;
void *deflated = NULL;
- crc = crc32(0, Z_NULL, 0);
+ crc = crc32(0, NULL, 0);
path = construct_path(base, baselen, filename, S_ISDIR(mode), &pathlen);
if (verbose)
--
1.4.4
^ permalink raw reply related
* [PATCH] git-apply: slightly clean up bitfield usage
From: Rene Scharfe @ 2006-11-18 12:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
This patch fixes a sparse warning about inaccurate_eof being a
"dubious one-bit signed bitfield", makes three more binary
variables members of this (now unsigned) bitfield and adds a
short comment to indicate the nature of two ternary variables.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
builtin-apply.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index aad5526..61f047f 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -140,12 +140,15 @@ struct fragment {
struct patch {
char *new_name, *old_name, *def_name;
unsigned int old_mode, new_mode;
- int is_rename, is_copy, is_new, is_delete, is_binary;
+ int is_new, is_delete; /* -1 = unknown, 0 = false, 1 = true */
int rejected;
unsigned long deflate_origlen;
int lines_added, lines_deleted;
int score;
- int inaccurate_eof:1;
+ unsigned int inaccurate_eof:1;
+ unsigned int is_binary:1;
+ unsigned int is_copy:1;
+ unsigned int is_rename:1;
struct fragment *fragments;
char *result;
unsigned long resultsize;
--
1.4.4
^ permalink raw reply related
* Re: [PATCH 4/5] allow deepening of a shallow repository
From: Johannes Schindelin @ 2006-11-18 12:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu00ymhk1.fsf@assigned-by-dhcp.cox.net>
Hi,
On Fri, 17 Nov 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> Although I am reasonably sure we can eventually make it work, it
> >> is very subtle and fragile -- somebody touching this code can
> >> easily break it.
> >
> > I fully agree. Even the OA did not understand the code fully ;-)
> >
> > How about adding "int force_reparse" to the signature of
> > unregister_shallow()? (Just like we added "int cleanup" to
> > get_merge_bases() to avoid pilot errors.)
>
> I do not think that's where its fragility lies. It is that any
> random place can later call parse_object() on the commit, after
> you elaborately pre-parsed it with shallow so that it appears to
> have fewer parents, with the expectation that nobody ever would
> clear the parsed bit and cause it to be reparsed again. With
> that assumption, find_common() manipulated the shallow entry
> after setting that scheme up. A mechanism to prevent the commit
> >from getting re-parsed would have made it more robust.
How about putting yet more meaning into nr_parents: if it is negative, it
is a shallow commit, but write_shallow_commits() only writes the SHA1 if
nr_parents is -1. Hmm?
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Document git-runstatus
From: Rene Scharfe @ 2006-11-18 14:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Johannes Schindelin, Jeff King
I copied most of the text from git-status.txt.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
Documentation/git-runstatus.txt | 66 +++++++++++++++++++++++++++++++++++++++
builtin-runstatus.c | 2 +-
2 files changed, 67 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-runstatus.txt b/Documentation/git-runstatus.txt
new file mode 100644
index 0000000..c144c7b
--- /dev/null
+++ b/Documentation/git-runstatus.txt
@@ -0,0 +1,66 @@
+git-runstatus(1)
+================
+
+NAME
+----
+git-runstatus - Show working tree status
+
+
+SYNOPSIS
+--------
+'git-runstatus' [--color|--nocolor] [--amend] [--verbose] [--untracked]
+
+
+DESCRIPTION
+-----------
+Examines paths in the working tree that has changes unrecorded
+to the index file, and changes between the index file and the
+current HEAD commit. The former paths are what you _could_
+commit by running 'git-update-index' before running 'git
+commit', and the latter paths are what you _would_ commit by
+running 'git commit'.
+
+If there is no path that is different between the index file and
+the current HEAD commit, the command exits with non-zero
+status.
+
+
+OPTIONS
+-------
+--color::
+ Show colored status, highlighting modified file names.
+
+--nocolor::
+ Turn off coloring.
+
+--amend::
+ Show status based on HEAD^1, not HEAD, i.e. show what
+ 'git-commit --amend' would do.
+
+--verbose::
+ Show unified diff of all file changes.
+
+--untracked::
+ Show files in untracked directories, too. Without this
+ option only its name and a trailing slash are displayed
+ for each untracked directory.
+
+
+OUTPUT
+------
+The output from this command is designed to be used as a commit
+template comments, and all the output lines are prefixed with '#'.
+
+
+Author
+------
+Written by Jeff King.
+
+Documentation
+--------------
+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/builtin-runstatus.c b/builtin-runstatus.c
index 303c556..0b63037 100644
--- a/builtin-runstatus.c
+++ b/builtin-runstatus.c
@@ -4,7 +4,7 @@
extern int wt_status_use_color;
static const char runstatus_usage[] =
-"git-runstatus [--color|--nocolor] [--amend] [--verbose]";
+"git-runstatus [--color|--nocolor] [--amend] [--verbose] [--untracked]";
int cmd_runstatus(int argc, const char **argv, const char *prefix)
{
--
1.4.4
^ permalink raw reply related
* Re: [PATCH] Document git-runstatus
From: Sean @ 2006-11-18 14:26 UTC (permalink / raw)
To: Rene Scharfe
Cc: Junio C Hamano, Git Mailing List, Johannes Schindelin, Jeff King
In-Reply-To: <455F1595.9020009@lsrfire.ath.cx>
On Sat, 18 Nov 2006 15:15:49 +0100
Rene Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:
> I copied most of the text from git-status.txt.
[...]
> +git-runstatus - Show working tree status
How is git-runstatus different from "git status"? Should this command be
viewed simply as plumbing, and if so does it deserve a man page or just
textual documentation in the source?
^ permalink raw reply
* Re: [PATCH] Document git-runstatus
From: Petr Baudis @ 2006-11-18 14:35 UTC (permalink / raw)
To: Sean
Cc: Rene Scharfe, Junio C Hamano, Git Mailing List,
Johannes Schindelin, Jeff King
In-Reply-To: <20061118092644.a9f15669.seanlkml@sympatico.ca>
On Sat, Nov 18, 2006 at 03:26:44PM CET, Sean wrote:
> On Sat, 18 Nov 2006 15:15:49 +0100
> Rene Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:
>
> > I copied most of the text from git-status.txt.
> [...]
> > +git-runstatus - Show working tree status
Don't forget to add it to the list of commands.
> How is git-runstatus different from "git status"?
I have the same question.
> Should this command be viewed simply as plumbing, and if so does it
> deserve a man page or just textual documentation in the source?
All commands deserve a man page.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
The meaning of Stonehenge in Traflamadorian, when viewed from above, is:
"Replacement part being rushed with all possible speed."
^ permalink raw reply
* Re: [PATCH] Document git-runstatus
From: Rene Scharfe @ 2006-11-18 15:04 UTC (permalink / raw)
To: Petr Baudis, Junio C Hamano
Cc: Sean, Git Mailing List, Johannes Schindelin, Jeff King
In-Reply-To: <20061118143511.GM7201@pasky.or.cz>
Petr Baudis schrieb:
> On Sat, Nov 18, 2006 at 03:26:44PM CET, Sean wrote:
>> On Sat, 18 Nov 2006 15:15:49 +0100
>> Rene Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:
>>
>>> I copied most of the text from git-status.txt.
>> [...]
>>> +git-runstatus - Show working tree status
>
> Don't forget to add it to the list of commands.
Good catch, thanks. An incremental patch follows below.
>> How is git-runstatus different from "git status"?
>
> I have the same question.
git-status is a wrapper around git-runstatus that takes the same
options as git-commit. It could have been named 'git-commit --dry-run'.
>> Should this command be viewed simply as plumbing, and if so does it
>> deserve a man page or just textual documentation in the source?
>
> All commands deserve a man page.
Exactly. Even plumbers read manuals ;-). Well, me at least.
René
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 52bc05a..63b1746 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -424,6 +424,9 @@ gitlink:git-pack-redundant[1]::
gitlink:git-rev-list[1]::
Lists commit objects in reverse chronological order.
+gitlink:git-runstatus[1]::
+ Show working tree status.
+
gitlink:git-show-index[1]::
Displays contents of a pack idx file.
^ permalink raw reply related
* Re: [PATCH] Document git-runstatus
From: Sean @ 2006-11-18 16:04 UTC (permalink / raw)
To: Rene Scharfe
Cc: Petr Baudis, Junio C Hamano, Git Mailing List,
Johannes Schindelin, Jeff King
In-Reply-To: <455F210B.8000107@lsrfire.ath.cx>
On Sat, 18 Nov 2006 16:04:43 +0100
Rene Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:
> git-status is a wrapper around git-runstatus that takes the same
> options as git-commit. It could have been named 'git-commit --dry-run'.
What could be said in the docs as to when the use of one is preferred
over the other?
> > All commands deserve a man page.
>
> Exactly. Even plumbers read manuals ;-). Well, me at least.
Heh, I suppose you and Petr are right. It's just that in recent
discussions the great number of commands provided by Git is seen
as a UI problem. Thus having two commands that seem to do the
exact same thing gives more such pain for no gain.
It's possible that plumbers should not be seen as "users" but
rather as coders capable of reading traditional text based
(non man-page) documentation for their purposes, and man pages
should only exist (or at least installed) for user level commands.
^ permalink raw reply
* Possible but in gitweb
From: Paolo Ciarrocchi @ 2006-11-18 16:58 UTC (permalink / raw)
To: Git Mailing List
Hi all,
I'm playing with a repo hosted by repos.os.cz and I think I faced a
bug (Pasky confirmed that this should be reported here as a bug).
My repo has two branches,
master
html
Master contains a text file while html contains his conversion in html
done via asciidoc.
I need to URLs that point to the top of the branches in order to have
an easy way for lnkind the documentation to external portals.
This link points to HEAD, so top of master:
http://repo.or.cz/w/LinuxKernelDevelopmentProcess.git?a=blob_plain;f=LinuxKernelDevelopmentProcess;hb=HEAD
Browsing the repo I reach the following URL
http://repo.or.cz/w/LinuxKernelDevelopmentProcess.git?a=blob;f=LinuxKernelDevelopmentProcess.html;hb=HEAD
that is not accessible.
Looks like is not possible to obtain a link to the top of a branch
different from master.
Regards,
--
Paolo
http://docs.google.com/View?docid=dhbdhs7d_4hsxqc8
http://www.linkedin.com/pub/0/132/9a3
Non credo nelle otto del mattino. Però esistono. Le otto del mattino
sono l'incontrovertibile prova della presenza del male nel mondo.
^ permalink raw reply
* Re: Possible but in gitweb
From: Jakub Narebski @ 2006-11-18 17:35 UTC (permalink / raw)
To: git
In-Reply-To: <4d8e3fd30611180858xf28e958g8511f2eb68d53848@mail.gmail.com>
Paolo Ciarrocchi wrote:
> Hi all,
> I'm playing with a repo hosted by repos.os.cz and I think I faced a
> bug (Pasky confirmed that this should be reported here as a bug).
>
> My repo has two branches,
> * master
> html
>
> Master contains a text file while html contains his conversion in html
> done via asciidoc.
>
> I need to URLs that point to the top of the branches in order to have
> an easy way for linking the documentation to external portals.
>
> This link points to HEAD, so top of master:
> http://repo.or.cz/w/LinuxKernelDevelopmentProcess.git?a=blob_plain;f=LinuxKernelDevelopmentProcess;hb=HEAD
>
> Browsing the repo I reach the following URL
> http://repo.or.cz/w/LinuxKernelDevelopmentProcess.git?a=blob;f=LinuxKernelDevelopmentProcess.html;hb=HEAD
> that is not accessible.
Because HEAD is master, not html, and there us no such file in master branch?
But all the following links
http://repo.or.cz/w/LinuxKernelDevelopmentProcess.git?a=blob;f=LinuxKernelDevelopmentProcess.html;hb=html
http://repo.or.cz/w/LinuxKernelDevelopmentProcess.git?a=blob;f=LinuxKernelDevelopmentProcess;hb=master
http://repo.or.cz/w/LinuxKernelDevelopmentProcess.git?a=blob;f=LinuxKernelDevelopmentProcess;hb=HEAD
works
You can use
http://repo.or.cz/w/LinuxKernelDevelopmentProcess.git/html:/LinuxKernelDevelopmentProcess.html
or
http://repo.or.cz/w/LinuxKernelDevelopmentProcess.git/html:LinuxKernelDevelopmentProcess.html
(and there is remote possibility that links would work, too)
> Looks like is not possible to obtain a link to the top of a branch
> different from master.
It is possible, but you must specify the branch.
P.S. Please reply also to git mailing list...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Do not ignore hidden refs
From: Linus Torvalds @ 2006-11-18 17:35 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20061118041137.6064.75827.stgit@machine.or.cz>
On Sat, 18 Nov 2006, Petr Baudis wrote:
>
> Some of the ref manipulation tools (git-for-each-ref and git-show-ref in
> particular) would not handle hidden (~ /^\./) refs. This may be an
> acceptable or possibly even desirable behaviour for the ref walkers and
> repackers, but git-show-ref hiddenrefname must work.
No.
Refnames MUST NOT start with a ".".
It's not even about the traditional unix "hidden file" thing. It's simply
a syntactic issue. A ref cannot start with a ".", because we use things
like ".." and "..." to separate them.
For the same reason, a ref must not contain - anywhere in its name - a "^"
or a ".." or the other magic characters.
If you want to hide refs, you should do so some other way.
^ permalink raw reply
* Re: Possible but in gitweb
From: Paolo Ciarrocchi @ 2006-11-18 17:42 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Git Mailing List
In-Reply-To: <ejng62$k2m$1@sea.gmane.org>
On 11/18/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Paolo Ciarrocchi wrote:
>
> > Hi all,
> > I'm playing with a repo hosted by repos.os.cz and I think I faced a
> > bug (Pasky confirmed that this should be reported here as a bug).
> >
> > My repo has two branches,
> > * master
> > html
> >
> > Master contains a text file while html contains his conversion in html
> > done via asciidoc.
> >
> > I need to URLs that point to the top of the branches in order to have
> > an easy way for linking the documentation to external portals.
> >
> > This link points to HEAD, so top of master:
> > http://repo.or.cz/w/LinuxKernelDevelopmentProcess.git?a=blob_plain;f=LinuxKernelDevelopmentProcess;hb=HEAD
> >
> > Browsing the repo I reach the following URL
> > http://repo.or.cz/w/LinuxKernelDevelopmentProcess.git?a=blob;f=LinuxKernelDevelopmentProcess.html;hb=HEAD
> > that is not accessible.
> Because HEAD is master, not html, and there us no such file in master branch?
Fair enoough but then there should be no link in the web interface.
That sounds like a bug in the interface.
> But all the following links
> http://repo.or.cz/w/LinuxKernelDevelopmentProcess.git?a=blob;f=LinuxKernelDevelopmentProcess.html;hb=html
>
Yeah, but I would like to see the interpreted page.
http://repo.or.cz/w/LinuxKernelDevelopmentProcess.git?a=blob;f=LinuxKernelDevelopmentProcess;hb=master
That is master not html
http://repo.or.cz/w/LinuxKernelDevelopmentProcess.git?a=blob;f=LinuxKernelDevelopmentProcess;hb=HEAD
> works
Same as above.
> You can use
> http://repo.or.cz/w/LinuxKernelDevelopmentProcess.git/html:/LinuxKernelDevelopmentProcess.html
Yes, thanks! Is it reachable via the web interface?
Is it always pointing to the top of the repo?
> or
> http://repo.or.cz/w/LinuxKernelDevelopmentProcess.git/html:LinuxKernelDevelopmentProcess.html
> (and there is remote possibility that links would work, too)
>
> > Looks like is not possible to obtain a link to the top of a branch
> > different from master.
>
> It is possible, but you must specify the branch.
Well, I don't see how it is possible just browsing with gitweb.
Am I wrong?
> P.S. Please reply also to git mailing list...
Ciao,
--
Paolo
http://docs.google.com/View?docid=dhbdhs7d_4hsxqc8
http://www.linkedin.com/pub/0/132/9a3
Non credo nelle otto del mattino. Però esistono. Le otto del mattino
sono l'incontrovertibile prova della presenza del male nel mondo.
^ permalink raw reply
* Re: Possible but in gitweb
From: Jakub Narebski @ 2006-11-18 18:01 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: git
In-Reply-To: <4d8e3fd30611180942p548a92d1ufc9e0dcfabedb59@mail.gmail.com>
Paolo Ciarrocchi wrote:
> On 11/18/06, Jakub Narebski <jnareb@gmail.com> wrote:
>> Paolo Ciarrocchi wrote:
>>>
>>> Browsing the repo I reach the following URL
>>> http://repo.or.cz/w/LinuxKernelDevelopmentProcess.git?a=blob;f=LinuxKernelDevelopmentProcess.html;hb=HEAD
>>> that is not accessible.
>>
>> Because HEAD is master, not html, and there us no such file in master branch?
>
> Fair enough but then there should be no link in the web interface.
> That sounds like a bug in the interface.
Where did you find this link? On what page?
"Browsing the repo" is not enough information to discover where
there is a bug.
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH] Document git-runstatus
From: A Large Angry SCM @ 2006-11-18 18:20 UTC (permalink / raw)
To: Sean
Cc: Rene Scharfe, Petr Baudis, Junio C Hamano, Git Mailing List,
Johannes Schindelin, Jeff King
In-Reply-To: <BAYC1-PASMTP06C814AB518D7544770C01AEEF0@CEZ.ICE>
Sean wrote:
> On Sat, 18 Nov 2006 16:04:43 +0100
> Rene Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:
>
>> git-status is a wrapper around git-runstatus that takes the same
>> options as git-commit. It could have been named 'git-commit --dry-run'.
>
> What could be said in the docs as to when the use of one is preferred
> over the other?
>
>>> All commands deserve a man page.
>> Exactly. Even plumbers read manuals ;-). Well, me at least.
>
> Heh, I suppose you and Petr are right. It's just that in recent
> discussions the great number of commands provided by Git is seen
> as a UI problem. Thus having two commands that seem to do the
> exact same thing gives more such pain for no gain.
>
> It's possible that plumbers should not be seen as "users" but
> rather as coders capable of reading traditional text based
> (non man-page) documentation for their purposes, and man pages
> should only exist (or at least installed) for user level commands.
^ permalink raw reply
* Re: Possible but in gitweb
From: Jakub Narebski @ 2006-11-18 18:21 UTC (permalink / raw)
To: Paolo Ciarrocchi
In-Reply-To: <4d8e3fd30611181003o6374f01cy504c0c058f374f1@mail.gmail.com>
Paolo Ciarrocchi wrote:
> On 11/18/06, Jakub Narebski <jnareb@gmail.com> wrote:
>> Paolo Ciarrocchi wrote:
>>> On 11/18/06, Jakub Narebski <jnareb@gmail.com> wrote:
>>>> Paolo Ciarrocchi wrote:
>>>>>
>>>>> Browsing the repo I reach the following URL
>>>>> http://repo.or.cz/w/LinuxKernelDevelopmentProcess.git?a=blob;f=LinuxKernelDevelopmentProcess.html;hb=HEAD
>>>>> that is not accessible.
>>>>
>>>> Because HEAD is master, not html, and there us no such file in master branch?
>>>
>>> Fair enough but then there should be no link in the web interface.
>>> That sounds like a bug in the interface.
>>
>> Where did you find this link? On what page?
>
> Here:
> http://repo.or.cz/w/LinuxKernelDevelopmentProcess.git?a=blob;f=LinuxKernelDevelopmentProcess.html;h=b5e39498997930cd14ecddfe120f62c577ce2e28;hb=html
>
> try now to press "HEAD"
Ah, well. This could be considered a bug... but it can be not.
The link is clearly marked "HEAD", so you are requesting HEAD
version of the file... which does not exist.
We could check if the file has HEAD version, but that is another
call to git commands.
What you want is the link to the tip of branch ("head", "top" or "tip")...
you are welcome to add that (or replace "HEAD" link with that).
Tip: href(...,hash_base => $hash_base,...)
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH] Do not ignore hidden refs
From: Junio C Hamano @ 2006-11-18 18:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, git
In-Reply-To: <Pine.LNX.4.64.0611180933360.3692@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Sat, 18 Nov 2006, Petr Baudis wrote:
>>
>> Some of the ref manipulation tools (git-for-each-ref and git-show-ref in
>> particular) would not handle hidden (~ /^\./) refs. This may be an
>> acceptable or possibly even desirable behaviour for the ref walkers and
>> repackers, but git-show-ref hiddenrefname must work.
>
> No.
>
> Refnames MUST NOT start with a ".".
>
> It's not even about the traditional unix "hidden file" thing. It's simply
> a syntactic issue. A ref cannot start with a ".", because we use things
> like ".." and "..." to separate them.
We do not forbid a refname that ends with a ".", but I think it
was a mistake. We _can_ disambiguate the ones that begin with a
"." by saying "whatever..heads/.I-begin-with-dot", but not the
ones that end with "heads/I-end-with-dot...end-of-range".
^ 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