* [StGit PATCH 5/6] Refresh the main stg man page
From: Karl Hasselström @ 2008-10-05 16:01 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20081005155450.19886.43748.stgit@yoghurt>
Update the text to reflect what's happened in StGit in the last few
releases. Also, consistently capitalize the names "Git" and "StGit".
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
Documentation/asciidoc.conf | 22 +++++-
Documentation/stg.txt | 150 +++++++++++++++++++++++++------------------
stgit/argparse.py | 2 -
3 files changed, 107 insertions(+), 67 deletions(-)
diff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf
index 5f7a7af..f2c0ede 100644
--- a/Documentation/asciidoc.conf
+++ b/Documentation/asciidoc.conf
@@ -44,9 +44,23 @@ template::[header-declarations]
endif::backend-docbook[]
endif::doctype-manpage[]
-## link: macro
+## htmllink: macro
#
-# Usage: link:command[manpage-section]
+# Usage: htmllink:url[text]
+
+ifdef::backend-docbook[]
+[htmllink-inlinemacro]
+{0}
+endif::backend-docbook[]
+
+ifdef::backend-xhtml11[]
+[htmllink-inlinemacro]
+<a href="{target}">{0}</a>
+endif::backend-xhtml11[]
+
+## manlink: macro
+#
+# Usage: manlink:command[manpage-section]
#
# Note, {0} is the manpage section, while {target} is the command.
#
@@ -54,7 +68,7 @@ endif::doctype-manpage[]
# show the command.
ifdef::backend-docbook[]
-[link-inlinemacro]
+[manlink-inlinemacro]
{0%{target}}
{0#<citerefentry>}
{0#<refentrytitle>{target}</refentrytitle><manvolnum>{0}</manvolnum>}
@@ -62,7 +76,7 @@ ifdef::backend-docbook[]
endif::backend-docbook[]
ifdef::backend-xhtml11[]
-[link-inlinemacro]
+[manlink-inlinemacro]
<a href="{target}.html">{target}{0?({0})}</a>
endif::backend-xhtml11[]
diff --git a/Documentation/stg.txt b/Documentation/stg.txt
index d8f7d01..9c6b267 100644
--- a/Documentation/stg.txt
+++ b/Documentation/stg.txt
@@ -1,11 +1,10 @@
stg(1)
======
Yann Dirson <ydirson@altern.org>
-v0.12.1, February 2007
NAME
----
-stg - manage stacks of patches using the GIT content tracker
+stg - Manage stacks of patches using the Git content tracker
SYNOPSIS
--------
@@ -17,86 +16,113 @@ SYNOPSIS
DESCRIPTION
-----------
-StGIT (Stacked GIT) is an application providing similar functionality
-to Quilt (i.e. pushing/popping patches to/from a stack), on top of
-GIT. These operations are performed using GIT commands and the patches
-are stored as GIT commit objects, allowing easy merging of the StGIT
-patches into other repositories using standard GIT functionality.
+StGit (Stacked Git) is an application that provides a convenient way
+to maintain a 'patch stack' on top of a Git branch:
-An StGIT stack is a GIT branch with additional information to help
-making changes to individual patches you already committed, rather
-than making changes by adding new commits. It is thus a
-non-forwarding, or rewinding branch: the old head of the branch is
-often not reachable as one of the new head's ancestors.
+ * The topmost (most recent) commits of a branch are given names.
+ Such a named commit is called a 'patch'.
-Typical uses of StGIT include:
+ * After making changes to the worktree, you can incorporate the
+ changes into an existing patch; this is called 'refreshing'. You
+ may refresh any patch, not just the topmost one.
+
+ * You can 'pop' a patch: temporarily putting it aside, so that the
+ patch below it becomes the topmost patch. Later you may 'push' it
+ onto the stack again. Pushing and popping can be used to reorder
+ patches.
+
+ * You can easily 'rebase' your patch stack on top of any other Git
+ branch. (The 'base' of a patch stack is the most recent Git commit
+ that is not an StGit patch.) For example, if you started making
+ patches on top of someone else's branch, and that person publishes
+ an updated branch, you can take all your patches and apply them on
+ top of the updated branch.
+
+ * The patch stack is just some extra metadata attached to regular
+ Git commits, so you can continue to use Git tools along with
+ StGit.
+
+Typical uses
+~~~~~~~~~~~~
Tracking branch::
- Tracking changes from a remote branch, while maintaining local
- modifications against that branch, possibly with the intent of
- sending some patches upstream. StGIT assists in preparing and
- cleaning up patches until they are acceptable upstream, as
- well as maintaining local patches not meant to be sent
- upstream.
+
+ Tracking changes from a remote branch, while maintaining local
+ modifications against that branch, possibly with the intent of
+ sending some patches upstream. You can modify your patch stack as
+ much as you want, and when your patches are finally accepted
+ upstream, the permanent recorded Git history will contain just the
+ final sequence of patches, and not the messy sequence of edits that
+ produced them.
+
-In such a setup, typically all commits on your branch are StGIT
-patches; the stack base is the branch point where your changes "fork"
-off their parent branch.
+Commands of interest in this workflow are e.g. stgsublink:rebase[] and
+stgsublink:mail[].
Development branch::
- Preparing and testing your commits before publishing them,
- separating your features from unrelated bugfixes collected
- while developping.
+
+ Even if you have no "upstream" to send patches to, you can use StGit
+ as a convenient way to modify the recent history of a Git branch.
+ For example, instead of first committing change 'A', then change
+ 'B', and then 'A2' to fix 'A' because it wasn't quite right, you
+ could incorporate the fix directly into 'A'. This way of working
+ results in a much more readable Git history than if you had
+ immortalized every misstep you made on your way to the right
+ solution.
+
-In such a setup, not all commits on your branch need to be StGIT
-patches; there may be regular GIT commits below your stack base.
+Commands of interest in this workflow are e.g. stgsublink:uncommit[],
+which can be used to move the patch stack base downwards -- i.e., turn
+Git commits into StGit patches after the fact -- and
+stgsublink:commit[], its inverse.
+
+For more information, see htmllink:tutorial.html[the tutorial].
-Patches
-~~~~~~~
+Specifying patches
+~~~~~~~~~~~~~~~~~~
-Many StGIT commands take references to StGIT patches as arguments.
+Many StGit commands take references to StGit patches as arguments.
Patches in the stack are identified with short names, each of which
must be unique in the stack.
-Patches in the current stack are just referred to by their name. Some
-commands allow you to specify a patch in another stack of the repository;
-this is done by suffixing the patch name with an '@' sign followed by the
-branch name (eg. 'thispatch@otherbranch').
+Patches in the current branch are simply referred to by their name.
+Some commands allow you to specify a patch in another branch of the
+repository; this is done by prefixing the patch name with the branch
+name and a colon (e.g. +otherbranch:thatpatch+).
+
+Specifying commits
+~~~~~~~~~~~~~~~~~~
+
+Some StGit commands take Git commits as arguments. StGit accepts all
+commit expressions that Git does; and in addition, a patch name
+(optionally prefixed by a branch name and a colon) is allowed in this
+context. The usual Git modifiers $$^$$ and $$~$$ are also allowed;
+e.g., +abranch:apatch~2+ is the grandparent of the commit that is the
+patch +apatch+ on branch +abranch+.
-A number of positions in the stack related to the patch are also
-accessible through '//' suffixes. For example, 'patch//top' is
-equivalent to 'patch', and 'patch//bottom' refers to the commit below
-'patch' (i.e. the patch below, or the stack base if this is the
-bottom-most patch). Similarly '//top.old' and '//bottom.old'
-refer to the previous version of the patch (before the last
-stglink:push[] or stglink:refresh[] operation). When referring to the
-current patch, its name can be omitted (eg. 'currentpatch//bottom.old'
-can be abbreviated as 'bottom.old').
+Instead of a patch name, you can say +$${base}$$+ to refer to the
+stack base (the commit just below the bottommost patch); so,
++abranch:$${base}$$+ is the base of the stack in branch +abranch+.
-If you need to pass a given StGIT reference to a git command,
-stglink:id[] will convert it to a git commit id.
+If you need to pass a given StGit reference to a Git command,
+stglink:id[] will convert it to a Git commit id for you.
OPTIONS
-------
-The following generic option flags are available. Additional options
-are available per-command, and documented in the command-specific
-documentation.
+The following generic option flags are available. Additional options
+are available for (and documented with) the different subcommands.
--version::
- Prints the StGIT suite version that the 'stg' program came
- from, as well as version of other components used, such as GIT
- and Python.
+ Prints the StGit version, as well as version of other components
+ used, such as Git and Python.
--help::
- Prints the synopsis and a list of all commands. If a git
- command is given this option will display the specific help
- for that command.
+ Prints the synopsis and a list of all subcommands. If an StGit
+ subcommand is given, prints the synposis for that subcommand.
STGIT COMMANDS
--------------
-We divide StGIT commands in thematic groups, according to the primary
+We divide StGit commands in thematic groups, according to the primary
type of object they create or change.
ifdef::backend-docbook[]
@@ -110,16 +136,16 @@ include::command-list.txt[]
CONFIGURATION MECHANISM
-----------------------
-Starting with 0.12, StGIT uses the same configuration mechanism as
-GIT. See link:git[7] for more details.
+StGit uses the same configuration mechanism as Git. See manlink:git[7]
+for more details.
TEMPLATES
---------
-A number of StGIT commands make use of template files to provide
-useful default texts to be edited by the user. These '<name>.tmpl'
+A number of StGit commands make use of template files to provide
+useful default texts to be edited by the user. These +<name>.tmpl+
template files are searched in the following directories:
- $GITDIR/
- $HOME/.stgit/templates/
- /usr/share/stgit/templates/
+ . +$GITDIR/+ (in practice, the +.git/+ directory in your repository)
+ . +$HOME/.stgit/templates/+
+ . +/usr/share/stgit/templates/+
diff --git a/stgit/argparse.py b/stgit/argparse.py
index 406ada3..0adb8ff 100644
--- a/stgit/argparse.py
+++ b/stgit/argparse.py
@@ -103,7 +103,7 @@ def write_asciidoc(cmd, f):
o.write_asciidoc(f)
f.write('\n')
_write_underlined('StGit', '-', f)
- f.write('Part of the StGit suite - see link:stg[1]\n')
+ f.write('Part of the StGit suite - see manlink:stg[1]\n')
def sign_options():
def callback(option, opt_str, value, parser, sign_str):
^ permalink raw reply related
* [StGit PATCH 4/6] Add 1.0 TODO items from recent discussion by private mail
From: Karl Hasselström @ 2008-10-05 16:01 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20081005155450.19886.43748.stgit@yoghurt>
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
TODO | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/TODO b/TODO
index 267e17e..a01daef 100644
--- a/TODO
+++ b/TODO
@@ -2,6 +2,16 @@ The TODO list before 1.0:
- more regression tests
+- Convert the remaining commands to the new infrastructure.
+
+- Go through the design of the UI and make sure there's nothing hard
+ to change in there that we'll regret later.
+
+- Write a user guide. I'm thinking a document on the order of 10-30
+ pages that'll explain why one would want to use StGit, and how.
+
+- Make sure the rest of the documentation is in good shape.
+
- use a separate index for some commands (refresh, fold etc.) so that
files already added/removed are not automatically checked in
@@ -9,7 +19,6 @@ The TODO list before 1.0:
uses a separate index when appropriate. fold has not yet been
converted.
-- document the workflow on the StGIT wiki
- release 1.0
^ permalink raw reply related
* [StGit PATCH 3/6] We're half-way there with the separate indexes
From: Karl Hasselström @ 2008-10-05 16:01 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20081005155450.19886.43748.stgit@yoghurt>
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
TODO | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/TODO b/TODO
index 3570345..267e17e 100644
--- a/TODO
+++ b/TODO
@@ -1,8 +1,14 @@
The TODO list before 1.0:
- more regression tests
+
- use a separate index for some commands (refresh, fold etc.) so that
files already added/removed are not automatically checked in
+
+ + This is easily done with the new infrastructure. refresh now
+ uses a separate index when appropriate. fold has not yet been
+ converted.
+
- document the workflow on the StGIT wiki
- release 1.0
^ permalink raw reply related
* [StGit PATCH 2/6] Remove TODO items that have already been addressed
From: Karl Hasselström @ 2008-10-05 16:01 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20081005155450.19886.43748.stgit@yoghurt>
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
TODO | 9 ---------
1 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/TODO b/TODO
index ff52a95..3570345 100644
--- a/TODO
+++ b/TODO
@@ -1,14 +1,9 @@
The TODO list before 1.0:
- more regression tests
-- stg help should probably pipe through the $PAGER
-- fix StGIT to run correctly in subdirectories
- use a separate index for some commands (refresh, fold etc.) so that
files already added/removed are not automatically checked in
-- debian package support
-- man page
- document the workflow on the StGIT wiki
-- use same configuration file as GIT
- release 1.0
@@ -18,9 +13,5 @@ The future, when time allows or if someone else does them:
- multiple heads in a patch - useful for forking a patch,
synchronising with other patches (diff format or in other
repositories)
-- commit directly to a patch which is not top
-- patch synchronisation between between branches (as some people,
- including me have the same patches based on different branches and
- they have scripts for moving the changes in one to the others)
- numeric shortcuts for naming patches near top (eg. +1, -2)
- (config?) parameter for number of patches included by "series -s"
^ permalink raw reply related
* [StGit PATCH 1/6] Remove unused variable
From: Karl Hasselström @ 2008-10-05 16:01 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20081005155450.19886.43748.stgit@yoghurt>
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
Documentation/Makefile | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 165e222..37df9ee 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -5,12 +5,10 @@ MAN1_TXT= stg.txt $(COMMANDS_TXT)
DOC_HTML=$(patsubst %.txt,%.html,$(MAN1_TXT))
-ARTICLES =
-# with their own formatting rules.
-SP_ARTICLES = tutorial
+ARTICLES = tutorial
-DOC_HTML += $(patsubst %,%.html,$(ARTICLES) $(SP_ARTICLES))
-DOC_PDF += $(patsubst %,%.pdf,$(ARTICLES) $(SP_ARTICLES))
+DOC_HTML += $(patsubst %,%.html,$(ARTICLES))
+DOC_PDF += $(patsubst %,%.pdf,$(ARTICLES))
DOC_MAN1=$(patsubst %.txt,%.1,$(MAN1_TXT))
^ permalink raw reply related
* [StGit PATCH 0/6] Documentation updates
From: Karl Hasselström @ 2008-10-05 16:01 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
We're approaching a new StGit release (yay!), and the docs are rather
outdated. This is an attempt to refresh the main stg man page and the
tutorial (but I ran out of time for this weekend, so the second half
of the tutorial is incomplete).
Comments & helping hands much appreciated.
Since I touch almost every line, the patches are kind of a nuisance to
read. It's probably easiest to just fetch the branch:
git://repo.or.cz/stgit/kha.git doc
---
Karl Hasselström (6):
Refresh and expand the tutorial (not finished)
Refresh the main stg man page
Add 1.0 TODO items from recent discussion by private mail
We're half-way there with the separate indexes
Remove TODO items that have already been addressed
Remove unused variable
Documentation/Makefile | 11 -
Documentation/asciidoc.conf | 22 +
Documentation/stg.txt | 150 +++++---
Documentation/tutorial.txt | 794 ++++++++++++++++++++++++++-----------------
TODO | 26 +
stgit/argparse.py | 2
6 files changed, 603 insertions(+), 402 deletions(-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* gitweb improvements
From: Tjernlund @ 2008-10-05 15:45 UTC (permalink / raw)
To: 'git'
When I browse a repo using gitweb, I miss two things:
1) looking at the history for a file or directory I really want
to see the tags there too.
2) looking at a merge like:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=66120005e65eed8a05b14a36ab448bdec42f0d6b
is somewhat confusing. It really doesn't tell you which commits that is
included in the merge.
Jocke
^ permalink raw reply
* git rebase -i -p broken?
From: Avi Kivity @ 2008-10-05 15:30 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1009 bytes --]
Consider this scenario:
- commit some patch (named 'a')
- merge a random branch
- commit a fix to patch a
- since I haven't pushed yet, I want to squash a and a-fix together, to
prevent bisect problems
- fire up 'git rebase -i -p a^'
Now the problems begin:
- the todo list shows up the branch's commits as well as my current
branch. But I don't want to commit the branch's commits in my own
branch. Replaying the merge should be enough. Looks like a missing
--first-parent somewhere.
- removing the spurious commit from the todo, and moving a-fix after a
and marking it as a squash action, I get
Refusing to squash a merge: 51ca22d7afb7433332ae41d0c2e3bab598048c21
even though that's not a merge
- using git commit --amend instead of squash confuses git in some other way
Attached is a script that generates a test case. With some $EDITOR
hacks it can even be convinced to be an automated test case.
All this using 1.6.0.2.
--
error compiling committee.c: too many arguments to function
[-- Attachment #2: rebase-merge --]
[-- Type: text/plain, Size: 385 bytes --]
!#/bin/sh -e
git --version
mkdir repo
cd repo
git init
touch a
touch 0
git add 0
git commit -m 'zeroth commit'
git add a
git commit -m 'first commit'
git checkout -b branch
touch b
git add b
git commit -m 'second commit (branch)'
git checkout master
touch c
git add c
git commit -m 'third commit'
git merge branch
touch d
git add d
git commit -m 'fifth commit'
git rebase -i -p HEAD~4
^ permalink raw reply
* What about renaming ga -i [r]evert to [r]eset ?
From: Marc Weber @ 2008-10-05 15:26 UTC (permalink / raw)
To: git
Hi,
Some time ago I told a friend to use ga -i [r](evert).. and I thought
it would do the same as svn revert (set the working copy back to the
state recorded in repo (which git checkout does)..
The ga -i help display reveals that reverting does reset the index
(cache to be comitted) instead.
I think it's better to rename the command [r]evert to [r]eset ?
I've also added the command [c]heckout last.
You can get the patch from git://mawercer.de/git_my_patches branch
revert_to_reset_renaming
Maybe someone of you beeing more familiar with perl,
git-add--interactive and git can review it maybe telling me what should
be done so that it can be committed upstream?
Thanks
Marc
^ permalink raw reply
* Re: teamGit v0.0.3
From: bain @ 2008-10-05 15:13 UTC (permalink / raw)
To: git
In-Reply-To: <m38wt3qrij.fsf@localhost.localdomain>
> Could you please add info about teamGit to the git wiki pagehttp://git.or.cz/gitwiki/InterfacesFrontendsAndTools? I think
> just below now defunct and unmaintained KGit (or just above) would
> be best.
Will do ASAP
> P.S. How it differs from othe Git GUIs, like gitk+git-gui, qgit
> or git-cola?It differs from
1. gitk and git-gui : its not as ugly :p, well actually neither of
them fulfilled speed requirements on my 'not so old' but 'ancient by
computer standards' p4 laptop.
2. qgit4 : actually its not very different except that i don't find
interface of qgit too friendly. Neway i would have used qgit instead
if it was at the stage its now two years back. i also tried to base my
code off qgit's plumbing unfortunately it wasn't easy to rip it. I
didn't like the complicated unreadable typical c++ code design so
chose not to participate in there. (to make things clear qgit is
excellent, and wonderfully coded. Marc has done real good job of using
c++ to its fullest and this is not a comment on his coding
capabilities. Its only that i am just too poor a c++ developer and
consider c++ too confusing for active contirbution in core design by
others.) So one of the aims i have in teamGit is to keep it as clean
and simple as possible (not easy goal i must add and i might already
be off).
3. git-cola: i hate scirpting used as mainstay applications.
Besides all of the above teamGit differes drastically in its end
roadmap.
It will ultimately be complete project management tool. A developer
should be able to completely manage his coding activities from inside
teamGit, plus a team collaberation added as an advantage.
But these are reallllyyyyyy lloooonnngg term goals, if it ever gets
there.
Thanks,
BAIN
^ permalink raw reply
* Re: git rebase -- a suggestion
From: Nanako Shiraishi @ 2008-10-05 13:26 UTC (permalink / raw)
To: Robin Burchell, Shawn O. Pearce; +Cc: git
In-Reply-To: <b19eae4e0810021710v14a3901an1f793de00c439ba1@mail.gmail.com>
Documentation/git-rebase.txt talks about pre-rebase hook, but
it appears that Documentation/git-hooks.txt does not have corresponding
entry for it.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
"Robin Burchell" <w00t@inspircd.org> writes:
> would it perhaps be an idea to have a way to mark a tree 'public', and
> disallow rebase *unless* --force was passed, or it was a public tree?
Documentation/githooks.txt | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
index 046a2a7..567ec03 100644
--- a/Documentation/githooks.txt
+++ b/Documentation/githooks.txt
@@ -130,6 +130,13 @@ parameter, and is invoked after a commit is made.
This hook is meant primarily for notification, and cannot affect
the outcome of 'git-commit'.
+pre-rebase
+----------
+
+This hook is called by 'git-rebase' and can be used to prevent a branch
+from getting rebased.
+
+
post-checkout
-----------
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* Re: [Announce] teamGit v0.0.3
From: Jakub Narebski @ 2008-10-05 10:14 UTC (permalink / raw)
To: bain; +Cc: git
In-Reply-To: <8ce0dfd6-2bd7-4e94-901f-b7c9bbd114aa@w39g2000prb.googlegroups.com>
bain <bain@devslashzero.com> writes:
> This is an announcement for a small project to create a functional
> git gui. This project was born as KGit a couple of years back when
> i needed a ui commit tool and none other were mature. My ambitions
> have grown since then and I recoded it in pure QT4.
Could you please add info about teamGit to the git wiki page
http://git.or.cz/gitwiki/InterfacesFrontendsAndTools ? I think
just below now defunct and unmaintained KGit (or just above) would
be best.
TIA.
P.S. How it differs from othe Git GUIs, like gitk+git-gui, qgit
or git-cola?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* [Announce] teamGit v0.0.3
From: bain @ 2008-10-05 9:39 UTC (permalink / raw)
To: git; +Cc: bain
Hi all,
This is an announcement for a small project to create a functional git
gui.
This project was born as kgit a couple of years back when i needed a
ui commit tool and none other were mature.
My ambitions have grown since then and I recoded it in pure QT4.
The short description of the application :-
Currently it is of course in very early alpha stage.
It works stable to do following things,
1. Its a pretty good commit tool. Just double click on unstaged files
to stage them. It supports staging hunks (just double click on the
hunk you want to stage in diff pane) and the related stuff. You can
optionally view untracked files and stage them for inclusion as well.
2. Its a preliminary repository viewer, it does not support graphical
representation for want of performance.
3. It has few other git command implemented, a quick issue of pull/
push, a reset command, cherry pick command and some branch management
implemented.
Known problems,
1. Icons make no sense i just dumped kde icons dir to the project
resources and picked the ones i could match or just at random (e.g.
checkout is a smilie)
2. No documentation, will be addressed soon.
3. All git commands can not be canceled in between. But with git thats
not usually a big issue.
Long description:
You can find the info on
http://www.devslashzero.com/teamgit
Download
http://www.devslashzero.com/teamgit/download (you will need qt-dev >
4.4)
This is so far tested only on ubuntu 8.04 with backports repo enabled
and qt update installed.
Ultimate goal of the project is to add much more than just version
control on top of git. But giving git a ui will always remain an
important goal.
You can view continually evolving roadmap at
http://www.devslashzero.com/teamgit/roadmap
With this announcement i am looking for feedback on the overall
interface design (commit procedure dialogs etc.) and feature requests.
WARNING: never been used out side controlled environment. Use at your
own risk.
Abhijit Bhopatkar - BAIN
^ permalink raw reply
* Re: Build bug report: 'make check' needs sparse, but configure doesn't check it
From: Ed Avis @ 2008-10-05 9:46 UTC (permalink / raw)
To: git
In-Reply-To: <20081005003446.GN21650@dpotapov.dyndns.org>
Dmitry Potapov <dpotapov <at> gmail.com> writes:
>The whole point of 'make check' is to run 'sparce' on all files.
>If you want to build
>and to test the resulting binaries then you run 'make test'.
Thanks, I didn't realize that. I assumed that 'make check' was to run the test
suite.
That is the convention used by most autoconf-based programs: for example if you
download coreutils then 'make check' runs the tests, so the normal way to build
and install is something like 'configure && make check && make install'.
To reduce confusion I suggest renaming the target to 'make sparse'. Then it's
obvious what it does and it can't get confused with the more common usage of
'make check'.
--
Ed Avis <eda@waniasset.com>
^ permalink raw reply
* Re: Files with colons under Cygwin
From: Giovanni Funchal @ 2008-10-05 9:28 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: git, Shawn O. Pearce
In-Reply-To: <20081004233945.GM21650@dpotapov.dyndns.org>
> Strange... What version of Cygwin did you use? When I tried this with
> Cygwin 1.5.25, I got the following error:
>
> error: git checkout-index: unable to create file a:b (No medium found)
I'm on 1.5.25-15 on WinXP over a mounted network file system, but no
errors/warnings here...
Thanks for the clarifications and the patch,
-- Giovanni
On Sun, Oct 5, 2008 at 1:39 AM, Dmitry Potapov <dpotapov@gmail.com> wrote:
> On Thu, Oct 02, 2008 at 04:02:23PM +0200, Giovanni Funchal wrote:
>>
>> Cygwin does not allow files with colons, I think this is Windows stuff
>> one just can't avoid.
>
> At least, you cannot use colon in Win32 API. They say Windows "native"
> API has less restrictions over what symbols are not allowed in file
> names, but I guess it is still not allowed.
>
>> If you have files with colons in a git
>> repository and try pulling them on cygwin, the file is empty, its name
>> is truncated and the status is wrong.
>>
>> linux $ date > a:b
>> linux $ git init
>> linux $ git add a:b
>> linux $ git commit -m test
>> linux $ git push
>> cygwin $ git pull
>
> Strange... What version of Cygwin did you use? When I tried this with
> Cygwin 1.5.25, I got the following error:
>
> error: git checkout-index: unable to create file a:b (No medium found)
>
> Apparently, Git tried to create 'b' file on the drive 'a', and creating
> files outside of the working tree is not a very good thing to do from
> the security point of view, as it can easily overwrite anything in
> c:/windows/.
>
> So, here is a patch. It basically disallow backslashes and colons in
> file names on Windows (whether it is MinGW or Cygwin).
>
> I wonder if the problem exists on Mac OS X too. From what I heard, it
> does not treat ':' as a normal symbol. But I have no access to Mac OS X,
> so here is a patch for Windows only.
>
> -- >8 --
> From: Dmitry Potapov <dpotapov@gmail.com>
> Date: Sat, 4 Oct 2008 22:57:19 +0400
> Subject: [PATCH] correct verify_path for Windows
>
> Colon and backslash in names may be used on Windows to overwrite files
> outside of the working directory.
>
> Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
> ---
> read-cache.c | 10 ++++++++++
> 1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/read-cache.c b/read-cache.c
> index 901064b..972592e 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -701,6 +701,16 @@ inside:
> }
> return 0;
> }
> +#if defined(_WIN32) || defined(__CYGWIN__)
> + /*
> + * There is a bunch of other characters that are not allowed
> + * in Win32 API, but the following two create a security hole
> + * by allowing to overwrite files outside of the working tree,
> + * therefore they are explicitly prohibited.
> + */
> + else if (c == ':' || c == '\\')
> + return 0;
> +#endif
> c = *path++;
> }
> }
> --
> 1.6.0.2.445.g1198
>
> -- >8 --
>
^ permalink raw reply
* Re: Numeric Revision Names?
From: Alex Riesen @ 2008-10-05 9:19 UTC (permalink / raw)
To: André Goddard Rosa
Cc: Stephen Haberman, Thomas Rast, Jakub Narebski, marceloribeiro,
git
In-Reply-To: <b8bf37780810042013g57fc7073xd638e44bb666bf@mail.gmail.com>
2008/10/5 André Goddard Rosa <andre.goddard@gmail.com>:
> This is so true in a corporate environment with centralized
> repositories, then I completely agree
> that in the case git is being used in this model (many companies are
> really used to that), the
> monotonic revision number is helpful and sometimes is showstopper to
> not have them.
But you do have them, even now. With that simple hook script.
And outside of your small corporation noone needs them
(and your company doesn't need them either, they just can't
get over the mindset of rcs or vms native versioning or whatever
else they're plainly used to).
^ permalink raw reply
* Re: Files with colons under Cygwin
From: Alex Riesen @ 2008-10-05 9:14 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Giovanni Funchal, git, Shawn O. Pearce
In-Reply-To: <20081004233945.GM21650@dpotapov.dyndns.org>
2008/10/5 Dmitry Potapov <dpotapov@gmail.com>:
> So, here is a patch. It basically disallow backslashes and colons in
> file names on Windows (whether it is MinGW or Cygwin).
With this and sparse checkout patch combined it maybe possible
to make Git work on these backward filesystems in a saner way:
just never checkout the names which the filesystems cannot support
on disk and mark them correspondingly in the index. If at all needed,
the user can fallback to git-show and git-update-index to see the data
and update them in repo. Assumption is that the cases are rare...
^ permalink raw reply
* Re: How to list versioned files with modification status
From: Mark Burton @ 2008-10-05 9:04 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LFD.2.00.0810041608150.3208@nehalem.linux-foundation.org>
Linus Torvalds <torvalds <at> linux-foundation.org> writes:
> Nobody has ever asked for such a crazy thing, but here's a test-patch to
> teach 'git ls-files' the '--unmodified' flag.
>
> ...
Many thanks for the patch, it does exactly what I wanted. Thanks also to the
other people who contributed suggestions.
Mark
^ permalink raw reply
* Re: Files with colons under Cygwin
From: Alex Riesen @ 2008-10-05 9:04 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Giovanni Funchal, git, Shawn O. Pearce
In-Reply-To: <20081004233945.GM21650@dpotapov.dyndns.org>
2008/10/5 Dmitry Potapov <dpotapov@gmail.com>:
> On Thu, Oct 02, 2008 at 04:02:23PM +0200, Giovanni Funchal wrote:
>>
>> Cygwin does not allow files with colons, I think this is Windows stuff
>> one just can't avoid.
>
> At least, you cannot use colon in Win32 API. They say Windows "native"
> API has less restrictions over what symbols are not allowed in file
> names, but I guess it is still not allowed.
The part after colon in the file name specifies the identifier of an
alternative data stream (so there can be multiple data sets under one name).
Just another microsoft stupidity no one uses and knows about.
^ permalink raw reply
* Re: [PATCHv4] gitweb: parse parent..current syntax from pathinfo
From: Jakub Narebski @ 2008-10-05 8:19 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano, Shawn O. Pearce
In-Reply-To: <200810040331.27605.jnareb@gmail.com>
On Sun, 4 Oct 2008, Jakub Narebski wrote:
> On Thu, 2 Oct 2008, Giuseppe Bilotta wrote:
> > diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> > index 3e5b2b7..89e360f 100755
> > --- a/gitweb/gitweb.perl
> > +++ b/gitweb/gitweb.perl
> > @@ -534,7 +534,9 @@ if ($path_info && !defined $action) {
> >
> > # we can now parse ref and pathnames in PATH_INFO
> > if ($path_info) {
> > - my ($refname, $pathname) = split(/:/, $path_info, 2);
> > + $path_info =~ /^((.+?)(:(.+))?\.\.)?(.+?)(:(.+))?$/;
> > + my ($parentrefname, $parentpathname, $refname, $pathname) = (
> > + $2, $4, $5, $7);
>
> Style: I would use (but that is perhaps matter of taste)
>
> + my ($parentrefname, $parentpathname, $refname, $pathname) =
> + ($2, $4, $5, $7);
>
> Also it would be I think simpler to use instead non-catching grouping,
> i.e. (?: xxx ) extended pattern (see perlre(1)), and use
> ($1, $2, $3, $4), or even simpler 'list = (string =~ regexp)' form.
Alternate solution would be to use split(..., ..., 2), but I think you
got the regular expression right. Just mentioning...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [QGit] [PATCH] Modify Highlight Color at File Context View.
From: Marco Costalba @ 2008-10-05 7:34 UTC (permalink / raw)
To: Li Frank-B20596; +Cc: git
In-Reply-To: <7FD1F85C96D70C4A89DA1DF7667EAE9607A45A@zch01exm23.fsl.freescale.net>
On Sat, Oct 4, 2008 at 4:32 PM, Li Frank-B20596 <Frank.Li@freescale.com> wrote:
>
> It should be setBackground(back), not setForeground(back);
>
Ahaaaa! My bad!
Sorry for this. Fix pushed.
Thanks
Marco
^ permalink raw reply
* [PATCH 0/3] Change timestamps to time_t not unsigned long
From: David Bryson @ 2008-10-05 4:29 UTC (permalink / raw)
To: git
This patch does not change very many lines, but it does it in several
different files. Per the Janitor page on the wiki it changes the
unsigned long values returned by approxidate() to time_t.
Feedback and comments welcome.
David Bryson (3):
Changed timestamps to time_t instead of unsigned
Changed timestamps to time_t instead of unsigned
Changed timestamps to time_t in header files
builtin-prune.c | 2 +-
builtin-reflog.c | 8 ++++----
builtin-show-branch.c | 4 ++--
cache.h | 2 +-
date.c | 2 +-
parse-options.c | 2 +-
reflog-walk.c | 2 +-
refs.c | 4 ++--
refs.h | 2 +-
revision.h | 4 ++--
sha1_name.c | 4 ++--
11 files changed, 18 insertions(+), 18 deletions(-)
^ permalink raw reply
* Re: Numeric Revision Names?
From: André Goddard Rosa @ 2008-10-05 3:13 UTC (permalink / raw)
To: Stephen Haberman; +Cc: Thomas Rast, Jakub Narebski, marceloribeiro, git
In-Reply-To: <20081003124224.843a5a21.stephen@exigencecorp.com>
> For projects that do have a central authority (e.g. internal corporate
> projects), revision numbers make more sense.
Surely!
> Granted, they are on separate branches (like svn), but the nice thing
> about them is that they are monotonically increasing. E.g. our qa
> people love numbers--the bug fix ticket says dev just put in
> r100...qa/production box says it is on r95. Doesn't matter the
> branch/whatever, they know the box doesn't have r100. Now, right, if
> its r105, it is trickier, although we also throw in branch name (e.g.
> topica-r100) which means no false positives but can lead to false
> negatives.
Yes
> haven't gotten to it yet. For now I've just attached the commit
> numbers script.
It would be good to have this feature in git.
> For our team, lack of monotonic version numbers was a big deal--as in
> can't use git sort of big deal. I wouldn't be surprised if it is a
Yes, it's true that this is a big deal for many people out there.
> contributing factor that keeps other people, especially internal teams,
> from git. I understand all of the reasons it can't be in git proper,
> but an FAQ entry about the hook/tag hack or link to a contrib script
> might be useful (not necessarily the one attached, given its
> functions/etc. baggage).
That would be helpful, if it cannot go in git proper for real in the
centralized model.
> (I also face/faced a situation where "monotonic revision numbers" were
> essentially a check box item on a required list of SCM features, so
> despite whatever I/the-git-team/etc. thought about their technical
> inferiority, it was a criteria that could have ruled git out for us.
> Hence my mentioning an FAQ entry for others faced with my same
> political situation.)
>
This is so true in a corporate environment with centralized
repositories, then I completely agree
that in the case git is being used in this model (many companies are
really used to that), the
monotonic revision number is helpful and sometimes is showstopper to
not have them.
Regards,
--
[]s,
André Goddard
^ permalink raw reply
* Re: [PATCH v3] Add git-svn branch to allow branch creation in SVN repositories
From: Eric Wong @ 2008-10-05 2:35 UTC (permalink / raw)
To: Deskin Miller; +Cc: rafl, spearce, git
In-Reply-To: <20081004142444.GC3052@riemann.deskinm.fdns.net>
Thanks Deskin, one small fix to quiet the warning that was
making t9108 fail.
>From c7e48f128865823a4c5024eb4f67b69231d1d5dc Mon Sep 17 00:00:00 2001
From: Florian Ragwitz <rafl@debian.org>
Date: Tue, 2 Sep 2008 14:20:39 +0000
Subject: [PATCH] Add git-svn branch to allow branch creation in SVN repositories
[ew: fixed a warning to stderr causing t9108 to fail]
Signed-off-by: Florian Ragwitz <rafl@debian.org>
Signed-off-by: Deskin Miller <deskinm@umich.edu>
Acked-by: Eric Wong <normalperson@yhbt.net>
---
Documentation/git-svn.txt | 24 ++++++++++++++++-
git-svn.perl | 47 ++++++++++++++++++++++++++++++++-
t/t9128-git-svn-cmd-branch.sh | 59 +++++++++++++++++++++++++++++++++++++++++
3 files changed, 128 insertions(+), 2 deletions(-)
create mode 100755 t/t9128-git-svn-cmd-branch.sh
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 82d03b4..84c8f3c 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -149,6 +149,22 @@ and have no uncommitted changes.
is very strongly discouraged.
--
+'branch'::
+ Create a branch in the SVN repository.
+
+-m;;
+--message;;
+ Allows to specify the commit message.
+
+-t;;
+--tag;;
+ Create a tag by using the tags_subdir instead of the branches_subdir
+ specified during git svn init.
+
+'tag'::
+ Create a tag in the SVN repository. This is a shorthand for
+ 'branch -t'.
+
'log'::
This should make it easy to look up svn log messages when svn
users refer to -r/--revision numbers.
@@ -372,7 +388,8 @@ Passed directly to 'git-rebase' when using 'dcommit' if a
-n::
--dry-run::
-This can be used with the 'dcommit' and 'rebase' commands.
+This can be used with the 'dcommit', 'rebase', 'branch' and 'tag'
+commands.
For 'dcommit', print out the series of git arguments that would show
which diffs would be committed to SVN.
@@ -381,6 +398,9 @@ For 'rebase', display the local branch associated with the upstream svn
repository associated with the current branch and the URL of svn
repository that will be fetched from.
+For 'branch' and 'tag', display the urls that will be used for copying when
+creating the branch or tag.
+
--
ADVANCED OPTIONS
@@ -498,6 +518,8 @@ Tracking and contributing to an entire Subversion-managed project
git svn clone http://svn.example.com/project -T trunk -b branches -t tags
# View all branches and tags you have cloned:
git branch -r
+# Create a new branch in SVN
+ git svn branch waldo
# Reset your master to trunk (or any other branch, replacing 'trunk'
# with the appropriate name):
git reset --hard remotes/trunk
diff --git a/git-svn.perl b/git-svn.perl
index 7609a83..ef6d773 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -66,7 +66,7 @@ my ($_stdin, $_help, $_edit,
$_version, $_fetch_all, $_no_rebase,
$_merge, $_strategy, $_dry_run, $_local,
$_prefix, $_no_checkout, $_url, $_verbose,
- $_git_format, $_commit_url);
+ $_git_format, $_commit_url, $_tag);
$Git::SVN::_follow_parent = 1;
my %remote_opts = ( 'username=s' => \$Git::SVN::Prompt::_username,
'config-dir=s' => \$Git::SVN::Ra::config_dir,
@@ -131,6 +131,15 @@ my %cmd = (
'revision|r=i' => \$_revision,
'no-rebase' => \$_no_rebase,
%cmt_opts, %fc_opts } ],
+ branch => [ \&cmd_branch,
+ 'Create a branch in the SVN repository',
+ { 'message|m=s' => \$_message,
+ 'dry-run|n' => \$_dry_run,
+ 'tag|t' => \$_tag } ],
+ tag => [ sub { $_tag = 1; cmd_branch(@_) },
+ 'Create a tag in the SVN repository',
+ { 'message|m=s' => \$_message,
+ 'dry-run|n' => \$_dry_run } ],
'set-tree' => [ \&cmd_set_tree,
"Set an SVN repository to a git tree-ish",
{ 'stdin|' => \$_stdin, %cmt_opts, %fc_opts, } ],
@@ -537,6 +546,42 @@ sub cmd_dcommit {
unlink $gs->{index};
}
+sub cmd_branch {
+ my ($branch_name, $head) = @_;
+
+ unless (defined $branch_name && length $branch_name) {
+ die(($_tag ? "tag" : "branch") . " name required\n");
+ }
+ $head ||= 'HEAD';
+
+ my ($src, $rev, undef, $gs) = working_head_info($head);
+
+ my $remote = Git::SVN::read_all_remotes()->{svn};
+ my $glob = $remote->{ $_tag ? 'tags' : 'branches' };
+ my ($lft, $rgt) = @{ $glob->{path} }{qw/left right/};
+ my $dst = join '/', $remote->{url}, $lft, $branch_name, ($rgt || ());
+
+ my $ctx = SVN::Client->new(
+ auth => Git::SVN::Ra::_auth_providers(),
+ log_msg => sub {
+ ${ $_[0] } = defined $_message
+ ? $_message
+ : 'Create ' . ($_tag ? 'tag ' : 'branch ' )
+ . $branch_name;
+ },
+ );
+
+ eval {
+ $ctx->ls($dst, 'HEAD', 0);
+ } and die "branch ${branch_name} already exists\n";
+
+ print "Copying ${src} at r${rev} to ${dst}...\n";
+ $ctx->copy($src, $rev, $dst)
+ unless $_dry_run;
+
+ $gs->fetch_all;
+}
+
sub cmd_find_rev {
my $revision_or_hash = shift or die "SVN or git revision required ",
"as a command-line argument\n";
diff --git a/t/t9128-git-svn-cmd-branch.sh b/t/t9128-git-svn-cmd-branch.sh
new file mode 100755
index 0000000..47c4d4d
--- /dev/null
+++ b/t/t9128-git-svn-cmd-branch.sh
@@ -0,0 +1,59 @@
+#!/bin/sh
+#
+# Copyright (c) 2008 Deskin Miller
+#
+
+test_description='git svn partial-rebuild tests'
+. ./lib-git-svn.sh
+
+test_expect_success 'initialize svnrepo' '
+ mkdir import &&
+ (
+ cd import &&
+ mkdir trunk branches tags &&
+ cd trunk &&
+ echo foo > foo &&
+ cd .. &&
+ svn import -m "import for git-svn" . "$svnrepo" >/dev/null &&
+ cd .. &&
+ rm -rf import &&
+ svn co "$svnrepo"/trunk trunk &&
+ cd trunk &&
+ echo bar >> foo &&
+ svn ci -m "updated trunk" &&
+ cd .. &&
+ rm -rf trunk
+ )
+'
+
+test_expect_success 'import into git' '
+ git svn init --stdlayout "$svnrepo" &&
+ git svn fetch &&
+ git checkout remotes/trunk
+'
+
+test_expect_success 'git svn branch tests' '
+ git svn branch a &&
+ base=$(git rev-parse HEAD:) &&
+ test $base = $(git rev-parse remotes/a:) &&
+ git svn branch -m "created branch b blah" b &&
+ test $base = $(git rev-parse remotes/b:) &&
+ test_must_fail git branch -m "no branchname" &&
+ git svn branch -n c &&
+ test_must_fail git rev-parse remotes/c &&
+ test_must_fail git svn branch a &&
+ git svn branch -t tag1 &&
+ test $base = $(git rev-parse remotes/tags/tag1:) &&
+ git svn branch --tag tag2 &&
+ test $base = $(git rev-parse remotes/tags/tag2:) &&
+ git svn tag tag3 &&
+ test $base = $(git rev-parse remotes/tags/tag3:) &&
+ git svn tag -m "created tag4 foo" tag4 &&
+ test $base = $(git rev-parse remotes/tags/tag4:) &&
+ test_must_fail git svn tag -m "no tagname" &&
+ git svn tag -n tag5 &&
+ test_must_fail git rev-parse remotes/tags/tag5 &&
+ test_must_fail git svn tag tag1
+'
+
+test_done
--
Eric Wong
^ permalink raw reply related
* [PATCH 2/2] check-attr: Add --stdin-paths option
From: Dmitry Potapov @ 2008-10-05 2:30 UTC (permalink / raw)
To: Alexander Gavrilov, git; +Cc: Shawn O. Pearce, Paul Mackerras, Dmitry Potapov
In-Reply-To: <1223173855-6173-1-git-send-email-dpotapov@gmail.com>
This allows multiple paths to be specified on stdin.
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
---
Documentation/git-check-attr.txt | 4 ++
builtin-check-attr.c | 66 ++++++++++++++++++++++++++++++++------
t/t0003-attributes.sh | 17 ++++++++++
3 files changed, 77 insertions(+), 10 deletions(-)
diff --git a/Documentation/git-check-attr.txt b/Documentation/git-check-attr.txt
index 2b821f2..0839a57 100644
--- a/Documentation/git-check-attr.txt
+++ b/Documentation/git-check-attr.txt
@@ -9,6 +9,7 @@ git-check-attr - Display gitattributes information.
SYNOPSIS
--------
'git check-attr' attr... [--] pathname...
+'git check-attr' --stdin-paths attr... < <list-of-paths
DESCRIPTION
-----------
@@ -17,6 +18,9 @@ For every pathname, this command will list if each attr is 'unspecified',
OPTIONS
-------
+--stdin-paths::
+ Read file names from stdin instead of from the command-line.
+
\--::
Interpret all preceding arguments as attributes, and all following
arguments as path names. If not supplied, only the first argument will
diff --git a/builtin-check-attr.c b/builtin-check-attr.c
index 5a2e329..821eb5e 100644
--- a/builtin-check-attr.c
+++ b/builtin-check-attr.c
@@ -2,9 +2,19 @@
#include "cache.h"
#include "attr.h"
#include "quote.h"
+#include "parse-options.h"
-static const char check_attr_usage[] =
-"git check-attr attr... [--] pathname...";
+static int stdin_paths;
+static const char * const check_attr_usage[] = {
+"git check-attr attr... [--] pathname...",
+"git check-attr --stdin-paths attr... < <list-of-paths>",
+NULL
+};
+
+static const struct option check_attr_options[] = {
+ OPT_BOOLEAN(0 , "stdin-paths", &stdin_paths, "read file names from stdin"),
+ OPT_END()
+};
static void check_attr(int cnt, struct git_attr_check *check,
const char** name, const char *file)
@@ -27,17 +37,43 @@ static void check_attr(int cnt, struct git_attr_check *check,
}
}
+static void check_attr_stdin_paths(int cnt, struct git_attr_check *check,
+ const char** name)
+{
+ struct strbuf buf, nbuf;
+
+ strbuf_init(&buf, 0);
+ strbuf_init(&nbuf, 0);
+ while (strbuf_getline(&buf, stdin, '\n') != EOF) {
+ if (buf.buf[0] == '"') {
+ strbuf_reset(&nbuf);
+ if (unquote_c_style(&nbuf, buf.buf, NULL))
+ die("line is badly quoted");
+ strbuf_swap(&buf, &nbuf);
+ }
+ check_attr(cnt, check, name, buf.buf);
+ }
+ strbuf_release(&buf);
+ strbuf_release(&nbuf);
+}
+
int cmd_check_attr(int argc, const char **argv, const char *prefix)
{
struct git_attr_check *check;
int cnt, i, doubledash;
+ const char *errstr = NULL;
+
+ argc = parse_options(argc, argv, check_attr_options, check_attr_usage,
+ PARSE_OPT_KEEP_DASHDASH);
+ if (!argc)
+ usage_with_options(check_attr_usage, check_attr_options);
if (read_cache() < 0) {
die("invalid cache");
}
doubledash = -1;
- for (i = 1; doubledash < 0 && i < argc; i++) {
+ for (i = 0; doubledash < 0 && i < argc; i++) {
if (!strcmp(argv[i], "--"))
doubledash = i;
}
@@ -45,25 +81,35 @@ int cmd_check_attr(int argc, const char **argv, const char *prefix)
/* If there is no double dash, we handle only one attribute */
if (doubledash < 0) {
cnt = 1;
- doubledash = 1;
+ doubledash = 0;
} else
- cnt = doubledash - 1;
+ cnt = doubledash;
doubledash++;
- if (cnt <= 0 || argc < doubledash)
- usage(check_attr_usage);
+ if (cnt <= 0)
+ errstr = "No attribute specified";
+ else if (stdin_paths && doubledash < argc)
+ errstr = "Can't specify files with --stdin-paths";
+ if (errstr) {
+ error (errstr);
+ usage_with_options(check_attr_usage, check_attr_options);
+ }
+
check = xcalloc(cnt, sizeof(*check));
for (i = 0; i < cnt; i++) {
const char *name;
struct git_attr *a;
- name = argv[i + 1];
+ name = argv[i];
a = git_attr(name, strlen(name));
if (!a)
return error("%s: not a valid attribute name", name);
check[i].attr = a;
}
- for (i = doubledash; i < argc; i++)
- check_attr(cnt, check, argv+1, argv[i]);
+ if (stdin_paths)
+ check_attr_stdin_paths(cnt, check, argv);
+ else
+ for (i = doubledash; i < argc; i++)
+ check_attr(cnt, check, argv, argv[i]);
return 0;
}
diff --git a/t/t0003-attributes.sh b/t/t0003-attributes.sh
index 3d8e06a..f6901b4 100755
--- a/t/t0003-attributes.sh
+++ b/t/t0003-attributes.sh
@@ -47,6 +47,23 @@ test_expect_success 'attribute test' '
'
+test_expect_success 'attribute test: read paths from stdin' '
+
+ cat <<EOF > expect
+f: test: f
+a/f: test: f
+a/c/f: test: f
+a/g: test: a/g
+a/b/g: test: a/b/g
+b/g: test: unspecified
+a/b/h: test: a/b/h
+a/b/d/g: test: a/b/d/*
+EOF
+
+ sed -e "s/:.*//" < expect | git check-attr --stdin-paths test > actual &&
+ test_cmp expect actual
+'
+
test_expect_success 'root subdir attribute test' '
attr_check a/i a/i &&
--
1.6.0.2.447.g3befd
^ 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