* [PATCH 2/2] Swap the porcelain and plumbing commands in the git man page
From: Robin Rosenberg @ 2006-10-29 20:09 UTC (permalink / raw)
To: git
In-Reply-To: <20061029200940.11233.20277.stgit@lathund.dewire.com>
From: Robin Rosenberg <robin.rosenberg@dewire.com>
This makes the documentation less confusing to newcomers.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
Documentation/git.txt | 364 +++++++++++++++++++++++++------------------------
1 files changed, 182 insertions(+), 182 deletions(-)
diff --git a/Documentation/git.txt b/Documentation/git.txt
index fff07e1..0679e3c 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -72,188 +72,6 @@ GIT COMMANDS
We divide git into high level ("porcelain") commands and low level
("plumbing") commands.
-Low-level commands (plumbing)
------------------------------
-
-Although git includes its
-own porcelain layer, its low-level commands are sufficient to support
-development of alternative porcelains. Developers of such porcelains
-might start by reading about gitlink:git-update-index[1] and
-gitlink:git-read-tree[1].
-
-We divide the low-level commands into commands that manipulate objects (in
-the repository, index, and working tree), commands that interrogate and
-compare objects, and commands that move objects and references between
-repositories.
-
-Manipulation commands
-~~~~~~~~~~~~~~~~~~~~~
-gitlink:git-apply[1]::
- Reads a "diff -up1" or git generated patch file and
- applies it to the working tree.
-
-gitlink:git-checkout-index[1]::
- Copy files from the index to the working tree.
-
-gitlink:git-commit-tree[1]::
- Creates a new commit object.
-
-gitlink:git-hash-object[1]::
- Computes the object ID from a file.
-
-gitlink:git-index-pack[1]::
- Build pack idx file for an existing packed archive.
-
-gitlink:git-init-db[1]::
- Creates an empty git object database, or reinitialize an
- existing one.
-
-gitlink:git-merge-index[1]::
- Runs a merge for files needing merging.
-
-gitlink:git-mktag[1]::
- Creates a tag object.
-
-gitlink:git-mktree[1]::
- Build a tree-object from ls-tree formatted text.
-
-gitlink:git-pack-objects[1]::
- Creates a packed archive of objects.
-
-gitlink:git-prune-packed[1]::
- Remove extra objects that are already in pack files.
-
-gitlink:git-read-tree[1]::
- Reads tree information into the index.
-
-gitlink:git-repo-config[1]::
- Get and set options in .git/config.
-
-gitlink:git-unpack-objects[1]::
- Unpacks objects out of a packed archive.
-
-gitlink:git-update-index[1]::
- Registers files in the working tree to the index.
-
-gitlink:git-write-tree[1]::
- Creates a tree from the index.
-
-
-Interrogation commands
-~~~~~~~~~~~~~~~~~~~~~~
-
-gitlink:git-cat-file[1]::
- Provide content or type/size information for repository objects.
-
-gitlink:git-describe[1]::
- Show the most recent tag that is reachable from a commit.
-
-gitlink:git-diff-index[1]::
- Compares content and mode of blobs between the index and repository.
-
-gitlink:git-diff-files[1]::
- Compares files in the working tree and the index.
-
-gitlink:git-diff-stages[1]::
- Compares two "merge stages" in the index.
-
-gitlink:git-diff-tree[1]::
- Compares the content and mode of blobs found via two tree objects.
-
-gitlink:git-for-each-ref[1]::
- Output information on each ref.
-
-gitlink:git-fsck-objects[1]::
- Verifies the connectivity and validity of the objects in the database.
-
-gitlink:git-ls-files[1]::
- Information about files in the index and the working tree.
-
-gitlink:git-ls-tree[1]::
- Displays a tree object in human readable form.
-
-gitlink:git-merge-base[1]::
- Finds as good common ancestors as possible for a merge.
-
-gitlink:git-name-rev[1]::
- Find symbolic names for given revs.
-
-gitlink:git-pack-redundant[1]::
- Find redundant pack files.
-
-gitlink:git-rev-list[1]::
- Lists commit objects in reverse chronological order.
-
-gitlink:git-show-index[1]::
- Displays contents of a pack idx file.
-
-gitlink:git-tar-tree[1]::
- Creates a tar archive of the files in the named tree object.
-
-gitlink:git-unpack-file[1]::
- Creates a temporary file with a blob's contents.
-
-gitlink:git-var[1]::
- Displays a git logical variable.
-
-gitlink:git-verify-pack[1]::
- Validates packed git archive files.
-
-In general, the interrogate commands do not touch the files in
-the working tree.
-
-
-Synching repositories
-~~~~~~~~~~~~~~~~~~~~~
-
-gitlink:git-fetch-pack[1]::
- Updates from a remote repository (engine for ssh and
- local transport).
-
-gitlink:git-http-fetch[1]::
- Downloads a remote git repository via HTTP by walking
- commit chain.
-
-gitlink:git-local-fetch[1]::
- Duplicates another git repository on a local system by
- walking commit chain.
-
-gitlink:git-peek-remote[1]::
- Lists references on a remote repository using
- upload-pack protocol (engine for ssh and local
- transport).
-
-gitlink:git-receive-pack[1]::
- Invoked by 'git-send-pack' to receive what is pushed to it.
-
-gitlink:git-send-pack[1]::
- Pushes to a remote repository, intelligently.
-
-gitlink:git-http-push[1]::
- Push missing objects using HTTP/DAV.
-
-gitlink:git-shell[1]::
- Restricted shell for GIT-only SSH access.
-
-gitlink:git-ssh-fetch[1]::
- Pulls from a remote repository over ssh connection by
- walking commit chain.
-
-gitlink:git-ssh-upload[1]::
- Helper "server-side" program used by git-ssh-fetch.
-
-gitlink:git-update-server-info[1]::
- Updates auxiliary information on a dumb server to help
- clients discover references and packs on it.
-
-gitlink:git-upload-archive[1]::
- Invoked by 'git-archive' to send a generated archive.
-
-gitlink:git-upload-pack[1]::
- Invoked by 'git-fetch-pack' to push
- what are asked for.
-
-
High-level commands (porcelain)
-------------------------------
@@ -491,6 +309,188 @@ gitlink:git-stripspace[1]::
Filter out empty lines.
+Low-level commands (plumbing)
+-----------------------------
+
+Although git includes its
+own porcelain layer, its low-level commands are sufficient to support
+development of alternative porcelains. Developers of such porcelains
+might start by reading about gitlink:git-update-index[1] and
+gitlink:git-read-tree[1].
+
+We divide the low-level commands into commands that manipulate objects (in
+the repository, index, and working tree), commands that interrogate and
+compare objects, and commands that move objects and references between
+repositories.
+
+Manipulation commands
+~~~~~~~~~~~~~~~~~~~~~
+gitlink:git-apply[1]::
+ Reads a "diff -up1" or git generated patch file and
+ applies it to the working tree.
+
+gitlink:git-checkout-index[1]::
+ Copy files from the index to the working tree.
+
+gitlink:git-commit-tree[1]::
+ Creates a new commit object.
+
+gitlink:git-hash-object[1]::
+ Computes the object ID from a file.
+
+gitlink:git-index-pack[1]::
+ Build pack idx file for an existing packed archive.
+
+gitlink:git-init-db[1]::
+ Creates an empty git object database, or reinitialize an
+ existing one.
+
+gitlink:git-merge-index[1]::
+ Runs a merge for files needing merging.
+
+gitlink:git-mktag[1]::
+ Creates a tag object.
+
+gitlink:git-mktree[1]::
+ Build a tree-object from ls-tree formatted text.
+
+gitlink:git-pack-objects[1]::
+ Creates a packed archive of objects.
+
+gitlink:git-prune-packed[1]::
+ Remove extra objects that are already in pack files.
+
+gitlink:git-read-tree[1]::
+ Reads tree information into the index.
+
+gitlink:git-repo-config[1]::
+ Get and set options in .git/config.
+
+gitlink:git-unpack-objects[1]::
+ Unpacks objects out of a packed archive.
+
+gitlink:git-update-index[1]::
+ Registers files in the working tree to the index.
+
+gitlink:git-write-tree[1]::
+ Creates a tree from the index.
+
+
+Interrogation commands
+~~~~~~~~~~~~~~~~~~~~~~
+
+gitlink:git-cat-file[1]::
+ Provide content or type/size information for repository objects.
+
+gitlink:git-describe[1]::
+ Show the most recent tag that is reachable from a commit.
+
+gitlink:git-diff-index[1]::
+ Compares content and mode of blobs between the index and repository.
+
+gitlink:git-diff-files[1]::
+ Compares files in the working tree and the index.
+
+gitlink:git-diff-stages[1]::
+ Compares two "merge stages" in the index.
+
+gitlink:git-diff-tree[1]::
+ Compares the content and mode of blobs found via two tree objects.
+
+gitlink:git-for-each-ref[1]::
+ Output information on each ref.
+
+gitlink:git-fsck-objects[1]::
+ Verifies the connectivity and validity of the objects in the database.
+
+gitlink:git-ls-files[1]::
+ Information about files in the index and the working tree.
+
+gitlink:git-ls-tree[1]::
+ Displays a tree object in human readable form.
+
+gitlink:git-merge-base[1]::
+ Finds as good common ancestors as possible for a merge.
+
+gitlink:git-name-rev[1]::
+ Find symbolic names for given revs.
+
+gitlink:git-pack-redundant[1]::
+ Find redundant pack files.
+
+gitlink:git-rev-list[1]::
+ Lists commit objects in reverse chronological order.
+
+gitlink:git-show-index[1]::
+ Displays contents of a pack idx file.
+
+gitlink:git-tar-tree[1]::
+ Creates a tar archive of the files in the named tree object.
+
+gitlink:git-unpack-file[1]::
+ Creates a temporary file with a blob's contents.
+
+gitlink:git-var[1]::
+ Displays a git logical variable.
+
+gitlink:git-verify-pack[1]::
+ Validates packed git archive files.
+
+In general, the interrogate commands do not touch the files in
+the working tree.
+
+
+Synching repositories
+~~~~~~~~~~~~~~~~~~~~~
+
+gitlink:git-fetch-pack[1]::
+ Updates from a remote repository (engine for ssh and
+ local transport).
+
+gitlink:git-http-fetch[1]::
+ Downloads a remote git repository via HTTP by walking
+ commit chain.
+
+gitlink:git-local-fetch[1]::
+ Duplicates another git repository on a local system by
+ walking commit chain.
+
+gitlink:git-peek-remote[1]::
+ Lists references on a remote repository using
+ upload-pack protocol (engine for ssh and local
+ transport).
+
+gitlink:git-receive-pack[1]::
+ Invoked by 'git-send-pack' to receive what is pushed to it.
+
+gitlink:git-send-pack[1]::
+ Pushes to a remote repository, intelligently.
+
+gitlink:git-http-push[1]::
+ Push missing objects using HTTP/DAV.
+
+gitlink:git-shell[1]::
+ Restricted shell for GIT-only SSH access.
+
+gitlink:git-ssh-fetch[1]::
+ Pulls from a remote repository over ssh connection by
+ walking commit chain.
+
+gitlink:git-ssh-upload[1]::
+ Helper "server-side" program used by git-ssh-fetch.
+
+gitlink:git-update-server-info[1]::
+ Updates auxiliary information on a dumb server to help
+ clients discover references and packs on it.
+
+gitlink:git-upload-archive[1]::
+ Invoked by 'git-archive' to send a generated archive.
+
+gitlink:git-upload-pack[1]::
+ Invoked by 'git-fetch-pack' to push
+ what are asked for.
+
+
Configuration Mechanism
-----------------------
^ permalink raw reply related
* [PATCH 1/2] Mention that pull can work locally in the synopsis
From: Robin Rosenberg @ 2006-10-29 20:09 UTC (permalink / raw)
To: git
From: Robin Rosenberg <robin.rosenberg@dewire.com>
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
Documentation/git-pull.txt | 2 +-
Documentation/git.txt | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index 51577fc..2a5aea7 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -3,7 +3,7 @@ git-pull(1)
NAME
----
-git-pull - Pull and merge from another repository
+git-pull - Pull and merge from another repository or a local branch
SYNOPSIS
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 595cca1..fff07e1 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -324,7 +324,7 @@ gitlink:git-mv[1]::
Move or rename a file, a directory, or a symlink.
gitlink:git-pull[1]::
- Fetch from and merge with a remote repository.
+ Fetch from and merge with a remote repository or a local branch.
gitlink:git-push[1]::
^ permalink raw reply related
* Re: [PATCH/RFC] gitweb: New improved patchset view
From: Jakub Narebski @ 2006-10-29 20:19 UTC (permalink / raw)
To: Junio C Hamano, Luben Tuikov; +Cc: git
In-Reply-To: <539418.62803.qm@web31807.mail.mud.yahoo.com>
Luben Tuikov wrote:
> --- Jakub Narebski <jnareb@gmail.com> wrote:
>>
>> By the way, should we use quoted or unquoted filename?
>
> For dear life, I cannot understand *WTF* is this argument about
> "quoted" and "unquoted". Can this stop please? PLEASE?
>
> Unquoted, natural, normal.
>
> Luben
> P.S. I don't want to punish the good people who do not put \n or \r or whatnot
> in their filenames, just for this one ... "person" who does. UTF8 is a different
> story.
The filenames which don't need quoting are not quoted. Only filenames
which need quoting (which have LF ('\n'), TAB ('\t'), \ ('\\') and " (\"))
are quoted and surronded in quotes to mark as quoted.
The only thing that is questionable is quoting files which have \ and "
and no other strange names.
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH/RFC] gitweb: New improved patchset view
From: Junio C Hamano @ 2006-10-29 20:29 UTC (permalink / raw)
To: ltuikov; +Cc: Jakub Narebski, git
In-Reply-To: <539418.62803.qm@web31807.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> For dear life, I cannot understand *WTF* is this argument about
> "quoted" and "unquoted". Can this stop please? PLEASE?
>
> Unquoted, natural, normal.
I do not think Jakub is talking about quoting normal filenames a/foo
that is not quoted by "git diff" into "a/foo" with his code.
I think when "git diff" quotes because of unusual characters
gitweb should show it quoted, i.e. as it receives from "git diff".
^ permalink raw reply
* Re: [PATCH/RFC] gitweb: New improved patchset view
From: Jakub Narebski @ 2006-10-29 20:29 UTC (permalink / raw)
To: Luben Tuikov; +Cc: git
In-Reply-To: <20061029195554.77410.qmail@web31813.mail.mud.yahoo.com>
Luben Tuikov wrote:
> --- Jakub Narebski <jnareb@gmail.com> wrote:
> > A couple of questions regarding new patchset/diff look for gitweb.
> > Currently patch starts with "git diff" header
> >
> > diff --git a/file1 b/file2
> >
> > then we have a couple of extended header lines
> >
> > old|new|deleted file|new file mode <mode>
> > copy|rename from|to <path>
> > (dis)?similarity index <percent>
> > index <hash>..<hash> [<mode>]
> >
> > then we have two-line from-file/to-file header
>
> First revert back to monospace in the commit message.
> As I mentioned in that other email, where the person
> didn't CC you and thus so I didn't, see commit
> 4b7ce6e2d6ba088da50de1df38b040ea2c0b8f18.
This regression was caused by the not-accepted (I think) patch
"gitweb: Slight visual improvements to commitdiff view",
and is not caused by _this_ patch.
I'll redo abovementioned patch correctly later.
> Can you please hyperlink what you had intended to
> quote? I.e. filenames which can lead the user browsing to a
> state (pre-rename, post-rename, etc). Thanks.
I don't understand this comment. The above is pre-changes git-diff
patch output. The changes are/were mentioned below.
> >
> > --- a/file1
> > +++ b/file2
> >
> > then patch itself.
> >
> >
> > 1. Which parts to convert to hyperlinks, and which to do not? Which
> > links have visible and which hidden (underline on mouseover, the same
> > color as neighbouring text)?
>
> I think the current state of your patch is good, sans the comments
> received so far: monospace, that bug in the index links, etc.
> Lets get that in, and then you can RFC another improvement on top of this.
O.K. I send the corrected version (as "take 2") in a while.
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH 1/2] git-send-email: Document support for local sendmail instead of SMTP server
From: Ryan Anderson @ 2006-10-29 20:34 UTC (permalink / raw)
To: Sergey Vlasov; +Cc: Junio C Hamano, git
In-Reply-To: <11621502993406-git-send-email-vsu@altlinux.ru>
On 10/29/06, Sergey Vlasov <vsu@altlinux.ru> wrote:
> Fix the --smtp-server option description to match reality.
>
> Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
Acked-by: Ryan Anderson <rda@google.com> (or ryan@michonline.com,
^ permalink raw reply
* Re: Merging five months of Linux kernel history
From: Junio C Hamano @ 2006-10-29 20:34 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: git
In-Reply-To: <20061029193228.GR26271@lug-owl.de>
Jan-Benedict Glaw <jbglaw@lug-owl.de> writes:
> Hi!
>
> Due to a move to a new flat and other reasons, I wasn't able to
> do daily merges from Linus's tree into our vax-linux tree.
> My time situation has improved and I want to merge all the new
> and shiny stuff, but it seems a straight "git pull" isn't the
> best way to do that.
>
> What I'd actually love to do is to go through all commits since the
> last merge and pull/accept/cherry-pick then one by one. That way I'll
> learn about new stuff. I'll specifically see generic changes that
> imply arch-specific stuff, things I'll need to implement later on.
>
> Is there any sane way to cluse such a large gap? I don't mind looking
> through tenthousands of commits, as long as I get a chance to spot
> "important" ones.
I think the best way is:
git pull
git log ORIG_HEAD..
The latter would give your ten thousands of commits to inspect.
If the pull results in a conflict, then
git pull
git log --merge
... fix conflicts ...
git commit
git log ORIG_HEAD..
Since ORIG_HEAD is transient, and you probably would want to
revisit the list of these ten thousands of commits later, it
might make sense to do
git tag WHERE_WE_WERE
before "git pull" in either case.
^ permalink raw reply
* Re: [PATCH 2/2] git-send-email: Read the default SMTP server from the GIT config file
From: Ryan Anderson @ 2006-10-29 20:37 UTC (permalink / raw)
To: Sergey Vlasov; +Cc: Junio C Hamano, git
In-Reply-To: <11621503001930-git-send-email-vsu@altlinux.ru>
On 10/29/06, Sergey Vlasov <vsu@altlinux.ru> wrote:
> Make the default value for --smtp-server configurable through the
> 'sendemail.smtpserver' option in .git/config (or $HOME/.gitconfig).
>
> Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
^ permalink raw reply
* Re: [PATCH 2/2] Swap the porcelain and plumbing commands in the git man page
From: Junio C Hamano @ 2006-10-29 20:47 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <20061029200948.11233.27482.stgit@lathund.dewire.com>
Thanks for these two. Applied.
By the way, people who run "next" may want to view:
git pickaxe -M v1.4.0.. -- Documentaiton/git.txt
and marvel at Linus's genius ;-).
^ permalink raw reply
* master and origin
From: Paolo Ciarrocchi @ 2006-10-29 20:53 UTC (permalink / raw)
To: Git Mailing List
Hi all,
I went trough the docs I found on the web but I still don't fully
understand why if I clone a remote repository my local copy has two
branches, origin (that is always a exact copy of the remote
repository) and master which is... what? The branch supposed to be
used for local development?
I'm used to just checkout to a new branch, do my own development and
then diff against origin so I'm missing why I see the master branch.
I'm sure I'm missing something very fundamental but I cannot figure
out what is it :-)
Thanks!
regards,
--
Paolo
^ permalink raw reply
* Re: master and origin
From: Jakub Narebski @ 2006-10-29 21:01 UTC (permalink / raw)
To: git
In-Reply-To: <4d8e3fd30610291253s2d8000dfx942e0fa20e0057f6@mail.gmail.com>
Paolo Ciarrocchi wrote:
> I went trough the docs I found on the web but I still don't fully
> understand why if I clone a remote repository my local copy has two
> branches, origin (that is always a exact copy of the remote
> repository) and master which is... what? The branch supposed to be
> used for local development?
>
> I'm used to just checkout to a new branch, do my own development and
> then diff against origin so I'm missing why I see the master branch.
>
> I'm sure I'm missing something very fundamental but I cannot figure
> out what is it :-)
Nothing very fundamental. The 'master' branch is (as name indicates)
default branch on which you do your own development. The 'origin' branch
is used to track 'master' branch in the repository you cloned from.
If you don't do your development on 'master', but use other branches,
the 'master'/'origin' is unnecessary; you could fetch 'master' into
'master'...
By the way, if you clone with --use-separate-remote you would get
separate namespace for tracking branches; additionally they would
be treated read-only (can't commit to).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Overwriting bare repositories' master
From: Sylvain Beucler @ 2006-10-29 21:03 UTC (permalink / raw)
To: git; +Cc: savannah-hackers-public
Hello,
I'm trying to setup a git hosting facility, such as repo.or.cz. The
facility provides a pre-initialized git repository only accessible
through git-shell.
The goal is to minimise the system admins' intervention, and I have a
question about a branch 'overwriting'. For example, let's say the user
makes an initial import to refs/heads/master for testing purposes,
then wants to start over and import the real project. Can he put a
wholy different git repository in place of the other one, at the same
destination?
I tried and I found something that doesn't seem to follow the
documentation:
repo_one$ git push Beuc@cvs.sv.gnu.org:/srv/git/sources/administration.git \
master:refs/heads/master
# [OK]
repo_two$ git push --force Beuc@cvs.sv.gnu.org:/srv/git/administration.git \
+refs/heads/master:refs/heads/master
updating 'refs/heads/master'
from ee3bda653dfabaf0f78f2a9977abec180f2b19dc
to c9a726b610bafc82142a16af80b83d28375ca619
Generating pack...
Done counting 0 objects.
Total 0, written 0 (delta 0), reused 0 (delta 0)
Unpacking 0 objects
error: denying non-fast forward; you should pull first
From man git-push:
"If the optional plus + is used, the remote ref is updated even if it
does not result in a fast forward update."
This also makes one wonder how the 'pu' git branch is updated.
One the one hand, this means that sysadmin intervention is required to
reset such a repository, which is bad. One the other hand, this is
also a security because users cannot erase history, even if there a
cron job to prune&pack the git repositories, which is good.
Is this by design? Or should it work?
--
^ permalink raw reply
* Re: master and origin
From: Jakub Narebski @ 2006-10-29 21:19 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: git
In-Reply-To: <4d8e3fd30610291307v24f5aab8l3f447a1bfdf86ab4@mail.gmail.com>
Paolo Ciarrocchi wrote:
> On 10/29/06, Jakub Narebski <jnareb@gmail.com> wrote:
>> Paolo Ciarrocchi wrote:
>>
>>> I went trough the docs I found on the web but I still don't fully
>>> understand why if I clone a remote repository my local copy has two
>>> branches, origin (that is always a exact copy of the remote
>>> repository) and master which is... what? The branch supposed to be
>>> used for local development?
>>>
>>> I'm used to just checkout to a new branch, do my own development and
>>> then diff against origin so I'm missing why I see the master branch.
[...]
>> If you don't do your development on 'master', but use other branches,
>> the 'master'/'origin' is unnecessary; you could fetch 'master' into
>> 'master'...
>>
>> By the way, if you clone with --use-separate-remote you would get
>> separate namespace for tracking branches; additionally they would
>> be treated read-only (can't commit to).
>
> There is still one thing I don't understand, if I pull the git or
> kernel repository all the local branches are updated according to the
> remote branches, right? If I'm hacking on master what will happen to
> my local changes?
With the default setup (git clone without --use-separate-remote), then
all local branches are updated according to remote branches... with the
exception of remote 'master' branch which updates local 'origin' branch.
pull = fetch + merge, so if you pull when you are on your local 'master'
branch (and 'master' branch is first in the .git/remotes/origin file I think)
you would fetch remote 'master' into local 'origin' and merge what you
have in 'origin' into your 'master' (or merge remote 'master' into
your local 'master' if you want to think like that).
If you have uncommitted changes git would probably refuse the merge.
If you made changes to one of the tracking branches (e.g. 'next' or
'origin'), git would refuse to fetch into this branch (unless forced).
HTH
--
Jakub Narebski
^ permalink raw reply
* Re: master and origin
From: Paolo Ciarrocchi @ 2006-10-29 21:29 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200610292219.21823.jnareb@gmail.com>
On 10/29/06, Jakub Narebski <jnareb@gmail.com> wrote:
> > There is still one thing I don't understand, if I pull the git or
> > kernel repository all the local branches are updated according to the
> > remote branches, right? If I'm hacking on master what will happen to
> > my local changes?
>
> With the default setup (git clone without --use-separate-remote), then
> all local branches are updated according to remote branches... with the
> exception of remote 'master' branch which updates local 'origin' branch.
OK, I see.
> pull = fetch + merge, so if you pull when you are on your local 'master'
> branch (and 'master' branch is first in the .git/remotes/origin file I think)
> you would fetch remote 'master' into local 'origin' and merge what you
> have in 'origin' into your 'master' (or merge remote 'master' into
> your local 'master' if you want to think like that).
So in this case, there is a difference between doing my local
development under master or myownlocalbranch. Right?
I mean, if I do my own development under master and I pull, the master
branch will include origin and my local changes. Corret?
While if I work in my local branch the datas are not modified with a
pull, because pull will update only the local copy of the remote
branch. Correct?
> If you have uncommitted changes git would probably refuse the merge.
> If you made changes to one of the tracking branches (e.g. 'next' or
> 'origin'), git would refuse to fetch into this branch (unless forced).
>
> HTH
It does, a lot!
Ciao,
--
Paolo
http://docs.google.com/View?docid=dhbdhs7d_4hsxqc8
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: master and origin
From: Jakub Narebski @ 2006-10-29 21:40 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: git
In-Reply-To: <4d8e3fd30610291329n7fe59873r87cbee9ccbd4b720@mail.gmail.com>
Paolo Ciarrocchi wrote:
> On 10/29/06, Jakub Narebski <jnareb@gmail.com> wrote:
[...]
>> pull = fetch + merge, so if you pull when you are on your local 'master'
>> branch (and 'master' branch is first in the .git/remotes/origin file I think)
>> you would fetch remote 'master' into local 'origin' and merge what you
>> have in 'origin' into your 'master' (or merge remote 'master' into
>> your local 'master' if you want to think like that).
>
> So in this case, there is a difference between doing my local
> development under master or myownlocalbranch. Right?
> I mean, if I do my own development under master and I pull, the master
> branch will include origin and my local changes. Corret?
> While if I work in my local branch the datas are not modified with a
> pull, because pull will update only the local copy of the remote
> branch. Correct?
To be more exact (sorry for the confusion) "git pull" means first do
the "git fetch", i.e. update local 'tracking' branches with the contents
of remote branches. For ordinary clone this means:
remote (origin) | local
------------------+------------------
master | origin
next | next
... | ...
For --use-separate-remote this means
remote (origin) | local
-------------------+-------------------
master | refs/remotes/origin/master
next | refs/remotes/origin/next
... | ...
Then it does "merge". It takes the remote branch from first Pull: line in
remotes/origin file, or first in remote.origin.fetch configuration variable,
and merges it with _current_ branch.
So if you always work on local branches, and newer want to merge
automatically, you probably should use "git fetch" for fetching changes.
What is not obvious (and is PITA for first-timers) that to merge
some <sidebranch> into your <branch>, it is simplest to first switch
to <branch> using
git checkout <branch>
and then merge <sidebranch> using
git pull . <sidebranch>
(where '.' means local repository).
HTH
--
Jakub Narebski
^ permalink raw reply
* Re: Overwriting bare repositories' master
From: Sylvain Beucler @ 2006-10-29 21:57 UTC (permalink / raw)
To: git; +Cc: savannah-hackers-public
In-Reply-To: <20061029210333.GG12285@localhost.localdomain>
ShadeHawk at #git noticed that this does not apply for a local
directory.
I reproduced the two successive push-es both to a local git
repository, and then to a remote git-shell'd one, and indeed, it works
locally but it is rejected remotely ("error: denying non-fast forward;
you should pull first").
So this is probably caused by git-shell restrictions.
Feature? :)
--
Sylvain
On Sun, Oct 29, 2006 at 10:03:33PM +0100, Sylvain Beucler wrote:
> Hello,
>
> I'm trying to setup a git hosting facility, such as repo.or.cz. The
> facility provides a pre-initialized git repository only accessible
> through git-shell.
>
> The goal is to minimise the system admins' intervention, and I have a
> question about a branch 'overwriting'. For example, let's say the user
> makes an initial import to refs/heads/master for testing purposes,
> then wants to start over and import the real project. Can he put a
> wholy different git repository in place of the other one, at the same
> destination?
>
> I tried and I found something that doesn't seem to follow the
> documentation:
>
> repo_one$ git push Beuc@cvs.sv.gnu.org:/srv/git/sources/administration.git \
> master:refs/heads/master
> # [OK]
> repo_two$ git push --force Beuc@cvs.sv.gnu.org:/srv/git/administration.git \
> +refs/heads/master:refs/heads/master
> updating 'refs/heads/master'
> from ee3bda653dfabaf0f78f2a9977abec180f2b19dc
> to c9a726b610bafc82142a16af80b83d28375ca619
> Generating pack...
> Done counting 0 objects.
> Total 0, written 0 (delta 0), reused 0 (delta 0)
> Unpacking 0 objects
> error: denying non-fast forward; you should pull first
>
> From man git-push:
> "If the optional plus + is used, the remote ref is updated even if it
> does not result in a fast forward update."
>
> This also makes one wonder how the 'pu' git branch is updated.
>
>
> One the one hand, this means that sysadmin intervention is required to
> reset such a repository, which is bad. One the other hand, this is
> also a security because users cannot erase history, even if there a
> cron job to prune&pack the git repositories, which is good.
>
^ permalink raw reply
* Re: Overwriting bare repositories' master
From: Junio C Hamano @ 2006-10-29 21:59 UTC (permalink / raw)
To: Sylvain Beucler; +Cc: git, Johannes Schindelin
In-Reply-To: <20061029210333.GG12285@localhost.localdomain>
Sylvain Beucler <beuc@gnu.org> writes:
> I tried and I found something that doesn't seem to follow the
> documentation:
>
> repo_one$ git push Beuc@cvs.sv.gnu.org:/srv/git/sources/administration.git \
> master:refs/heads/master
> # [OK]
> repo_two$ git push --force Beuc@cvs.sv.gnu.org:/srv/git/administration.git \
> +refs/heads/master:refs/heads/master
> updating 'refs/heads/master'
> from ee3bda653dfabaf0f78f2a9977abec180f2b19dc
> to c9a726b610bafc82142a16af80b83d28375ca619
> Generating pack...
> Done counting 0 objects.
> Total 0, written 0 (delta 0), reused 0 (delta 0)
> Unpacking 0 objects
> error: denying non-fast forward; you should pull first
>
> From man git-push:
> "If the optional plus + is used, the remote ref is updated even if it
> does not result in a fast forward update."
>
> This also makes one wonder how the 'pu' git branch is updated.
>
> One the one hand, this means that sysadmin intervention is required to
> reset such a repository, which is bad. One the other hand, this is
> also a security because users cannot erase history, even if there a
> cron job to prune&pack the git repositories, which is good.
>
> Is this by design? Or should it work?
I suspect (because I cannot see your .git/config in the
repository; which would say "[core] sharedrepository = 1" if my
suspicion is correct) that this is fairly new heavyhanded safety
valve added by the list around mid September, with this:
commit 11031d7e9f34f6a20ff4a4bd4fa3e5e3c0024a57
Author: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Date: Thu Sep 21 01:07:54 2006 +0200
add receive.denyNonFastforwards config variable
If receive.denyNonFastforwards is set to true,
git-receive-pack will deny non fast-forwards, i.e. forced
updates. Most notably, a push to a repository which has that
flag set will fail.
As a first user, 'git-init-db --shared' sets this flag,
since in a shared setup, you are most unlikely to want
forced pushes to succeed.
The reasoning is exactly as you guessed.
I think the intention of the patch is that the repository
administrators are expected to either (1) adjust the
non-fast-forwarding branch to fast-forward (by reset --hard to
an ancestor of what you are trying to push into), (2)
temporarily disable the safety value by editing .git/config, or
(3) instead of pushing into it, force fetching into it from the
repository machine.
It is doing what it was designed to do. It is a different issue
if the design is good, but rewinding the public branch is not
something even a repository administrator should take lightly
and not expected to happen often (except in cases like yours
where the administrator is tipping his toe into the water), so I
think overall the current behaviour is an acceptable balance
between safety and convenience.
My public repository is not shared (only I can push into it) so
this is a non-issue for my 'pu' branch.
^ permalink raw reply
* Re: Overwriting bare repositories' master
From: Junio C Hamano @ 2006-10-29 22:05 UTC (permalink / raw)
To: Sylvain Beucler; +Cc: git
In-Reply-To: <20061029215758.GA24385@localhost.localdomain>
Sylvain Beucler <beuc@gnu.org> writes:
> ShadeHawk at #git noticed that this does not apply for a local
> directory.
Do not top-post please.
> I reproduced the two successive push-es both to a local git
> repository, and then to a remote git-shell'd one, and indeed, it works
> locally but it is rejected remotely ("error: denying non-fast forward;
> you should pull first").
>
> So this is probably caused by git-shell restrictions.
I do not think so. Have you checked your config to see if you
have receive.denyNonFastforwards set?
I suspect Jakub (ShadeHawk)'s test does not have it.
^ permalink raw reply
* Re: [PATCH/RFC] gitweb: New improved patchset view
From: Jakub Narebski @ 2006-10-29 22:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Luben Tuikov, git
In-Reply-To: <200610292119.05626.jnareb@gmail.com>
Jakub Narebski wrote:
> The filenames which don't need quoting are not quoted. Only filenames
> which need quoting (which have LF ('\n'), TAB ('\t'), \ ('\\') and " (\"))
> are quoted and surronded in quotes to mark as quoted.
By the way, I think that unquote subroutine in gitweb is broken.
I think I'll try for new patchser view to work for ordinary filenames
(perhaps with metacharacters in them), and only then try to debug
for filenames which need quoting.
--
Jakub Narebski
^ permalink raw reply
* Re: Overwriting bare repositories' master
From: Sylvain Beucler @ 2006-10-29 22:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <7vslh6zstt.fsf@assigned-by-dhcp.cox.net>
On Sun, Oct 29, 2006 at 01:59:42PM -0800, Junio C Hamano wrote:
> Sylvain Beucler <beuc@gnu.org> writes:
>
> > I tried and I found something that doesn't seem to follow the
> > documentation:
> >
> > repo_one$ git push Beuc@cvs.sv.gnu.org:/srv/git/sources/administration.git \
> > master:refs/heads/master
> > # [OK]
> > repo_two$ git push --force Beuc@cvs.sv.gnu.org:/srv/git/administration.git \
> > +refs/heads/master:refs/heads/master
> > updating 'refs/heads/master'
> > from ee3bda653dfabaf0f78f2a9977abec180f2b19dc
> > to c9a726b610bafc82142a16af80b83d28375ca619
> > Generating pack...
> > Done counting 0 objects.
> > Total 0, written 0 (delta 0), reused 0 (delta 0)
> > Unpacking 0 objects
> > error: denying non-fast forward; you should pull first
> >
> > From man git-push:
> > "If the optional plus + is used, the remote ref is updated even if it
> > does not result in a fast forward update."
> >
> > This also makes one wonder how the 'pu' git branch is updated.
> >
> > One the one hand, this means that sysadmin intervention is required to
> > reset such a repository, which is bad. One the other hand, this is
> > also a security because users cannot erase history, even if there a
> > cron job to prune&pack the git repositories, which is good.
> >
> > Is this by design? Or should it work?
>
> I suspect (because I cannot see your .git/config in the
> repository; which would say "[core] sharedrepository = 1" if my
> suspicion is correct) that this is fairly new heavyhanded safety
> valve added by the list around mid September, with this:
>
> commit 11031d7e9f34f6a20ff4a4bd4fa3e5e3c0024a57
> Author: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> Date: Thu Sep 21 01:07:54 2006 +0200
>
> add receive.denyNonFastforwards config variable
>
> If receive.denyNonFastforwards is set to true,
> git-receive-pack will deny non fast-forwards, i.e. forced
> updates. Most notably, a push to a repository which has that
> flag set will fail.
>
> As a first user, 'git-init-db --shared' sets this flag,
> since in a shared setup, you are most unlikely to want
> forced pushes to succeed.
>
> The reasoning is exactly as you guessed.
>
> I think the intention of the patch is that the repository
> administrators are expected to either (1) adjust the
> non-fast-forwarding branch to fast-forward (by reset --hard to
> an ancestor of what you are trying to push into), (2)
> temporarily disable the safety value by editing .git/config, or
> (3) instead of pushing into it, force fetching into it from the
> repository machine.
>
> It is doing what it was designed to do. It is a different issue
> if the design is good, but rewinding the public branch is not
> something even a repository administrator should take lightly
> and not expected to happen often (except in cases like yours
> where the administrator is tipping his toe into the water), so I
> think overall the current behaviour is an acceptable balance
> between safety and convenience.
>
> My public repository is not shared (only I can push into it) so
> this is a non-issue for my 'pu' branch.
You perfectly guessed the situation.
Setting denyNonFastforwards=false allowed the forced push to succeed.
For reference the config file was
(http://cvs.sv.gnu.org/r/test.git/config):
[core]
repositoryformatversion = 0
filemode = true
sharedrepository = 1
[receive]
denyNonFastforwards = true
This sounds like a sound design :)
--
^ permalink raw reply
* Re: Overwriting bare repositories' master
From: Johannes Schindelin @ 2006-10-29 22:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sylvain Beucler, git
In-Reply-To: <7vslh6zstt.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sun, 29 Oct 2006, Junio C Hamano wrote:
> Sylvain Beucler <beuc@gnu.org> writes:
>
> > I tried and I found something that doesn't seem to follow the
> > documentation:
> >
> > [...]
> > error: denying non-fast forward; you should pull first
> >
> > From man git-push:
> > "If the optional plus + is used, the remote ref is updated even if it
> > does not result in a fast forward update."
> >
> > [...]
> >
> > Is this by design? Or should it work?
>
> I suspect (because I cannot see your .git/config in the
> repository; which would say "[core] sharedrepository = 1" if my
> suspicion is correct) that this is fairly new heavyhanded safety
> valve added by the list around mid September, with this:
>
> commit 11031d7e9f34f6a20ff4a4bd4fa3e5e3c0024a57
> Author: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> Date: Thu Sep 21 01:07:54 2006 +0200
>
> add receive.denyNonFastforwards config variable
> [...]
I still think the forced updates of pu still lose too many useful bits in
git's history.
Having said that, if receive.denyNonFastforwards indeed is the culprit:
git-shell allows you to do something like this:
ssh user@git.gnu.org \
"git-repo-config --unset receive.denyNonFastforwards"
After that, forced pushes should succeed. By the same account,
ssh user@git.gnu.org \
"git-repo-config --bool receive.denyNonFastforwards"
should tell you if Junio's suggestion is right (in this case, it will
output "true").
Hth,
Dscho
^ permalink raw reply
* Re: master and origin
From: Luben Tuikov @ 2006-10-29 22:58 UTC (permalink / raw)
To: Paolo Ciarrocchi, Git Mailing List
In-Reply-To: <4d8e3fd30610291253s2d8000dfx942e0fa20e0057f6@mail.gmail.com>
--- Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
> Hi all,
> I went trough the docs I found on the web but I still don't fully
> understand why if I clone a remote repository my local copy has two
> branches, origin (that is always a exact copy of the remote
> repository) and master which is... what? The branch supposed to be
> used for local development?
>
> I'm used to just checkout to a new branch, do my own development and
> then diff against origin so I'm missing why I see the master branch.
>
> I'm sure I'm missing something very fundamental but I cannot figure
> out what is it :-)
Read the documentation of git-fetch and especially the second
"Note" therein.
Luben
^ permalink raw reply
* Re: master and origin
From: Luben Tuikov @ 2006-10-29 23:19 UTC (permalink / raw)
To: Paolo Ciarrocchi, Jakub Narebski; +Cc: git
In-Reply-To: <4d8e3fd30610291329n7fe59873r87cbee9ccbd4b720@mail.gmail.com>
--- Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
>
> So in this case, there is a difference between doing my local
> development under master or myownlocalbranch. Right?
> I mean, if I do my own development under master and I pull, the master
> branch will include origin and my local changes. Corret?
> While if I work in my local branch the datas are not modified with a
> pull, because pull will update only the local copy of the remote
> branch. Correct?
Following GIT's working flow isn't that much different than
other SCM's workflow.
Leave master and origin branches alone. Imagine they are your
local copy of that imaginary "root" repo.
If you want to do development, create your own branch off of
master at some point, say HEAD, using git-branch, call it my-branch.
Then do your development in my-branch, occasionally pulling from
master, all the while you update master on a regular basis
from the remote repo. That pull into my-branch would schedule
the merge for you and if it cannot auto-merge, it will leave it
up to you do _resolve_ and then commit. Eventually
you get into the habit of following the same commands in the
same steps.
Note the key words here: pull, merge, commit. Pull and merge is
is done by git-pull, and if there's things to resolve you do that
manually, in most simplistic ways.
If you're coming from another SCM, picking up git is a snap.
I think the only "hurdle" coming from another SCM especially
centralized is the decentralized nature of git.
Reading git-fetch, git-pull documentation very carefully
should clear things up.
Luben
^ permalink raw reply
* [StGIT PATCH] Bash snippet to show branch and patch in bash prompt
From: Robin Rosenberg @ 2006-10-29 23:37 UTC (permalink / raw)
To: catalin.marinas; +Cc: git
From: Robin Rosenberg <robin.rosenberg@dewire.com>
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
contrib/stgbashprompt.sh | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/contrib/stgbashprompt.sh b/contrib/stgbashprompt.sh
new file mode 100755
index 0000000..792da53
--- /dev/null
+++ b/contrib/stgbashprompt.sh
@@ -0,0 +1,16 @@
+# include this in your bashrc or copy to /etc/bash_completions.d
+
+if [ "$PS1" ]; then
+ # trap 'PS1="\u@\h [$(stg top)] \w]\$ "' DEBUG
+ function stgtag
+ {
+ br=$(stg branch 2>/dev/null)
+ top=$(stg top 2>/dev/null)
+ if [[ -n "$br$top" ]];then
+ echo "[$top@$br]"
+ return
+ fi
+ }
+ PS1='\u@\h$(stgtag)\w\$ '
+
^ permalink raw reply related
* [PATCH/RFC (take 2)] gitweb: New improved patchset view
From: Jakub Narebski @ 2006-10-29 23:51 UTC (permalink / raw)
To: git
In-Reply-To: <200610291122.30852.jnareb@gmail.com>
Replace "gitweb diff header" with its full sha1 of blobs and replace
it by "git diff" header and extended diff header. Change also somewhat
highlighting of diffs.
Changes:
* "gitweb diff header" which looked for example like below:
file:_<sha1 before>_ -> file:_<sha1 after>_
where 'file' is file type and '<sha1>' is full sha1 of blob is
changed to
diff --git _a/<file before>_ _b/<file after>_
In both cases links are visible and use default link style. If file
is added, a/<file> is not hyperlinked, if file is deleted, b/<file>
is not hyperlinked.
* there is added "extended diff header", with <path> and <hash>
hyperlinked (and <hash> shortened to 7 characters), and <mode>
explained: '<mode>' is extended to '<mode> (<file type>)'.
* <file> hyperlinking should work also when <file> is originally
quoted. For now we present filename quoted. This needed changes to
parse_difftree_raw_line subroutine. And doesn't work: perhaps
unquote is broken.
* from-file/to-file two-line header lines have slightly darker color
than removed/added lines.
* chunk header has now delicate line above for easier finding chunk
boundary, and top margin of 1px.
WORK IN PROGRESS: might not work (and actually doesn't work correctly)
for strange filenames, i.e. filenames contaning either metacharacters
or having TAB, LF, backslash or doublequote in them.
Code should be much more clean, by the way.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.css | 46 +++++++++++---
gitweb/gitweb.perl | 178 +++++++++++++++++++++++++++++++++-------------------
2 files changed, 151 insertions(+), 73 deletions(-)
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index 83d900d..3aeceed 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -303,6 +303,33 @@ td.mode {
font-family: monospace;
}
+
+div.diff.header,
+div.diff.extended_header {
+ white-space: normal;
+}
+
+div.diff.header {
+ font-weight: bold;
+
+ background-color: #edece6;
+
+ margin-top: 4px;
+ padding: 4px 0px 2px 0px;
+ border: solid #d9d8d1;
+ border-width: 1px 0px 1px 0px;
+}
+
+div.diff.extended_header,
+div.diff.extended_header a.list {
+ color: #777777;
+}
+
+div.diff.extended_header {
+ background-color: #f6f5ee;
+ padding: 2px 0px 2px 0px;
+}
+
div.diff a.list {
text-decoration: none;
}
@@ -312,31 +339,34 @@ div.diff a.list:hover {
}
div.diff.to_file a.list,
-div.diff.to_file,
+div.diff.to_file {
+ color: #007000;
+}
+
div.diff.add {
color: #008800;
}
div.diff.from_file a.list,
-div.diff.from_file,
+div.diff.from_file {
+ color: #aa0000;
+}
+
div.diff.rem {
color: #cc0000;
}
div.diff.chunk_header {
color: #990099;
+ border: dotted #ffbbff;
+ border-width: 1px 0px 0px 0px;
+ margin-top: 1px;
}
div.diff.incomplete {
color: #cccccc;
}
-div.diff_info {
- font-family: monospace;
- color: #000099;
- background-color: #edece6;
- font-style: italic;
-}
div.index_include {
border: solid #d9d8d1;
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index cbab3c9..a5a140c 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1255,9 +1255,12 @@ sub parse_difftree_raw_line {
$res{'status'} = $5;
$res{'similarity'} = $6;
if ($res{'status'} eq 'R' || $res{'status'} eq 'C') { # renamed or copied
- ($res{'from_file'}, $res{'to_file'}) = map { unquote($_) } split("\t", $7);
+ ($res{'from_file_raw'}, $res{'to_file_raw'}) = split("\t", $7);
+ $res{'from_file'} = unquote($res{'from_file_raw'});
+ $res{'to_file'} = unquote($res{'to_file_raw'});
} else {
- $res{'file'} = unquote($7);
+ $res{'file_raw'} = $7;
+ $res{'file'} = unquote($res{'file_raw'});
}
}
# 'c512b523472485aef4fff9e57b229d9d243c967f'
@@ -2023,7 +2026,9 @@ sub git_patchset_body {
my $patch_idx = 0;
my $in_header = 0;
my $patch_found = 0;
+ my $skip_patch = 0;
my $diffinfo;
+ my (%from, %to);
print "<div class=\"patchset\">\n";
@@ -2033,6 +2038,8 @@ sub git_patchset_body {
if ($patch_line =~ m/^diff /) { # "git diff" header
# beginning of patch (in patchset)
+ $skip_patch = 0;
+
if ($patch_found) {
# close previous patch
print "</div>\n"; # class="patch"
@@ -2042,96 +2049,137 @@ sub git_patchset_body {
}
print "<div class=\"patch\" id=\"patch". ($patch_idx+1) ."\">\n";
+ # read and prepare patch information
if (ref($difftree->[$patch_idx]) eq "HASH") {
+ # pre-parsed (or generated by hand)
$diffinfo = $difftree->[$patch_idx];
} else {
$diffinfo = parse_difftree_raw_line($difftree->[$patch_idx]);
}
+ if ($diffinfo->{'status'} ne "A") { # not new (added) file
+ $from{'name'} = $diffinfo->{'from_file_raw'} || $diffinfo->{'file_raw'};
+ # because of "a/file" not a/"file"
+ $from{'quoted'} = ($from{'name'} =~ s/^"(.*)"$/$1/);
+
+ my $file = $diffinfo->{'from_file'} || $diffinfo->{'file'};
+ $from{'href'} = href(action=>"blob", hash_base=>$hash_parent,
+ hash=>$diffinfo->{'from_id'}, file_name=>$file);
+ }
+ if ($diffinfo->{'status'} ne "D") { # not deleted file
+ $to{'name'} = $diffinfo->{'to_file_raw'} || $diffinfo->{'file_raw'};
+ # because of "b/file" not b/"file"
+ $to{'quoted'} = ($to{'name'} =~ s/^"(.*)"$/$1/);
+
+ my $file = $diffinfo->{'to_file'} || $diffinfo->{'file'};
+ $to{'href'} = href(action=>"blob", hash_base=>$hash,
+ hash=>$diffinfo->{'to_id'}, file_name=>$file);
+ }
$patch_idx++;
# for now we skip empty patches
if ($diffinfo->{'from_id'} eq $diffinfo->{'to_id'}) {
# no change, empty patch
$in_header = 1;
+ $skip_patch = 0;
next LINE;
}
- if ($diffinfo->{'status'} eq "A") { # added
- print "<div class=\"diff_info\">" . file_type($diffinfo->{'to_mode'}) . ":" .
- $cgi->a({-href => href(action=>"blob", hash_base=>$hash,
- hash=>$diffinfo->{'to_id'}, file_name=>$diffinfo->{'file'})},
- $diffinfo->{'to_id'}) . " (new)" .
- "</div>\n"; # class="diff_info"
-
- } elsif ($diffinfo->{'status'} eq "D") { # deleted
- print "<div class=\"diff_info\">" . file_type($diffinfo->{'from_mode'}) . ":" .
- $cgi->a({-href => href(action=>"blob", hash_base=>$hash_parent,
- hash=>$diffinfo->{'from_id'}, file_name=>$diffinfo->{'file'})},
- $diffinfo->{'from_id'}) . " (deleted)" .
- "</div>\n"; # class="diff_info"
-
- } elsif ($diffinfo->{'status'} eq "R" || # renamed
- $diffinfo->{'status'} eq "C" || # copied
- $diffinfo->{'status'} eq "2") { # with two filenames (from git_blobdiff)
- print "<div class=\"diff_info\">" .
- file_type($diffinfo->{'from_mode'}) . ":" .
- $cgi->a({-href => href(action=>"blob", hash_base=>$hash_parent,
- hash=>$diffinfo->{'from_id'}, file_name=>$diffinfo->{'from_file'})},
- $diffinfo->{'from_id'}) .
- " -> " .
- file_type($diffinfo->{'to_mode'}) . ":" .
- $cgi->a({-href => href(action=>"blob", hash_base=>$hash,
- hash=>$diffinfo->{'to_id'}, file_name=>$diffinfo->{'to_file'})},
- $diffinfo->{'to_id'});
- print "</div>\n"; # class="diff_info"
-
- } else { # modified, mode changed, ...
- print "<div class=\"diff_info\">" .
- file_type($diffinfo->{'from_mode'}) . ":" .
- $cgi->a({-href => href(action=>"blob", hash_base=>$hash_parent,
- hash=>$diffinfo->{'from_id'}, file_name=>$diffinfo->{'file'})},
- $diffinfo->{'from_id'}) .
- " -> " .
- file_type($diffinfo->{'to_mode'}) . ":" .
- $cgi->a({-href => href(action=>"blob", hash_base=>$hash,
- hash=>$diffinfo->{'to_id'}, file_name=>$diffinfo->{'file'})},
- $diffinfo->{'to_id'});
- print "</div>\n"; # class="diff_info"
+ # print "git diff" header
+ if ($from{'name'}) {
+ my $from_link = $cgi->a({-href => $from{'href'}, -class => "path"},
+ 'a/' . esc_html($from{'name'}));
+ my ($q, $qq) = $from{'quoted'} ? ('"', '"') : ('', '');
+ $patch_line =~ s|${q}a/\Q$from{'name'}\E${q}|${qq}$from_link${qq}|;
+ } else {
+ # at least one of %from and %to must be set
+ $patch_line =~ s|(["]?a/\Q$to{'name'}\E["]?)|esc_html($1)|e;
+ }
+ if ($to{'name'}) {
+ my $to_link = $cgi->a({-href => $to{'href'}, -class => "path"},
+ 'b/' . esc_html($to{'name'}));
+ my ($q, $qq) = $to{'quoted'} ? ('"', '"') : ('', '');
+ $patch_line =~ s|${q}b/\Q$to{'name'}\E${q}$|${qq}$to_link${qq}|;
+ } else {
+ # at least one of %from and %to must be set
+ $patch_line =~ s|(["]?b/\Q$from{'name'}\E["]?)$|esc_html($1)|e;
}
- #print "<div class=\"diff extended_header\">\n";
+ print "<div class=\"diff header\">$patch_line</div>\n";
+ print "<div class=\"diff extended_header\">\n";
$in_header = 1;
next LINE;
+ } else {
+ next LINE if $skip_patch;
} # start of patch in patchset
+ if ($in_header) {
+ if ($patch_line !~ m/^---/) {
+ # match <path>
+ if ($patch_line =~ m!^(copy|rename) from ! && $from{'name'}) {
+ my $qq = $from{'quoted'} ? '"' : '';
+ my $from_link = $cgi->a({-href=>$from{'href'},-class=>"list"},
+ esc_html($from{'name'}));
+ $patch_line =~ s!from .*$!from $qq$from_link$qq!;
+ }
+ if ($patch_line =~ m!^(copy|rename) to ! && $to{'name'}) {
+ my $qq = $to{'quoted'} ? '"' : '';
+ my $to_link = $cgi->a({-href=>$to{'href'},-class=>"list"},
+ esc_html($to{'name'}));
+ $patch_line =~ s!to .*$!to $qq$to_link$qq!;
+ }
+ # match <mode>
+ if ($patch_line =~ m/\s(\d{6})$/) {
+ $patch_line .= '<span class="info"> (' . file_type($1) . ')</span>';
+ }
+ # match <hash>
+ if ($patch_line =~ m/^index/) {
+ my ($from_link, $to_link);
+ if ($from{'href'}) {
+ $from_link = $cgi->a({-href=>$from{'href'},-class=>"list"},
+ substr($diffinfo->{'from_id'},0,7));
+ } else {
+ $from_link = '0' x 7;
+ }
+ if ($to{'href'}) {
+ $to_link = $cgi->a({-href=>$to{'href'},-class=>"list"},
+ substr($diffinfo->{'to_id'},0,7));
+ } else {
+ $to_link = '0' x 7;
+ }
+ my ($from_id, $to_id) = ($diffinfo->{'from_id'}, $diffinfo->{'to_id'});
+ $patch_line =~ s!$from_id\.\.$to_id!$from_link..$to_link!;
+ }
+ print $patch_line . "<br/>\n";
- if ($in_header && $patch_line =~ m/^---/) {
- #print "</div>\n"; # class="diff extended_header"
- $in_header = 0;
+ } else {
+ #$patch_line =~ m/^---/;
+ print "</div>\n"; # class="diff extended_header"
+ $in_header = 0;
+
+ if ($from{'name'}) {
+ my $qq = $from{'quoted'} ? '"' : '';
+ my $from_link = $cgi->a({-href=>$from{'href'},-class=>"list"},
+ esc_html($from{'name'}));
+ $patch_line =~ s!["]?a/.*$!${qq}a/$from_link${qq}!;
+ }
+ print "<div class=\"diff from_file\">$patch_line</div>\n";
- my $file = $diffinfo->{'from_file'};
- $file ||= $diffinfo->{'file'};
- $file = $cgi->a({-href => href(action=>"blob", hash_base=>$hash_parent,
- hash=>$diffinfo->{'from_id'}, file_name=>$file),
- -class => "list"}, esc_html($file));
- $patch_line =~ s|a/.*$|a/$file|g;
- print "<div class=\"diff from_file\">$patch_line</div>\n";
+ $patch_line = <$fd>;
+ chomp $patch_line;
- $patch_line = <$fd>;
- chomp $patch_line;
+ #$patch_line =~ m/^+++/;
+ if ($to{'name'}) {
+ my $qq = $to{'quoted'} ? '"' : '';
+ my $from_link = $cgi->a({-href=>$to{'href'},-class=>"list"},
+ esc_html($to{'name'}));
+ $patch_line =~ s!["]?b/.*$!${qq}b/$from_link${qq}!;
+ }
+ print "<div class=\"diff to_file\">$patch_line</div>\n";
- #$patch_line =~ m/^+++/;
- $file = $diffinfo->{'to_file'};
- $file ||= $diffinfo->{'file'};
- $file = $cgi->a({-href => href(action=>"blob", hash_base=>$hash,
- hash=>$diffinfo->{'to_id'}, file_name=>$file),
- -class => "list"}, esc_html($file));
- $patch_line =~ s|b/.*|b/$file|g;
- print "<div class=\"diff to_file\">$patch_line</div>\n";
+ }
next LINE;
}
- next LINE if $in_header;
print format_diff_line($patch_line);
}
--
1.4.3.3
^ permalink raw reply related
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