* Re: is it possible filter the revision history of a single file into another repository?
From: Whit Armstrong @ 2008-12-18 14:19 UTC (permalink / raw)
To: Thomas Jarosch; +Cc: git
In-Reply-To: <200812181504.02105.thomas.jarosch@intra2net.com>
thanks, I will give this a try.
On Thu, Dec 18, 2008 at 9:04 AM, Thomas Jarosch
<thomas.jarosch@intra2net.com> wrote:
> On Thursday, 18. December 2008 14:51:12 Whit Armstrong wrote:
>> For instance, if my repository contains foo.c, and 100 other files.
>>
>> I would like to create a new and separate repository containing only
>> the revision history of foo.c.
>>
>> Would someone mind pointing me at some documentation for this
>> procedure if it exists?
>
> This worked for me:
>
> git filter-branch --tag-name-filter cat --index-filter \
> 'git ls-files -s |grep -P "\t(DIR1|DIR2)" \
> |GIT_INDEX_FILE=$GIT_INDEX_FILE.new git update-index --index-info &&
> mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE' -- --all
>
> Run "git ls-files -s" to see the output format.
> Replace the "DIR1|DIR2" with "foo.c".
>
> Later on you might want to remove empty commits from the history:
> git filter-branch --tag-name-filter cat --commit-filter 'if [ z$1 = z`git rev-parse $3^{tree}` ]; then skip_commit "$@"; else git commit-tree "$@"; fi' "$@" -- --all
>
> If you want to run two filter-branch commands in a row
> or you want to free up the space in .git afterwards:
>
> - git for-each-ref --format='%(refname)' refs/original | xargs -i git update-ref -d {}
> - git reflog expire --expire=0 --all
> - git repack -a -d
> - git prune
>
> Cheers,
> Thomas
>
>
^ permalink raw reply
* Re: is it possible filter the revision history of a single file into another repository?
From: Sverre Rabbelier @ 2008-12-18 14:15 UTC (permalink / raw)
To: Whit Armstrong; +Cc: git
In-Reply-To: <8ec76080812180551p8c97a0dqa2025e67792946c7@mail.gmail.com>
On Thu, Dec 18, 2008 at 14:51, Whit Armstrong <armstrong.whit@gmail.com> wrote:
> For instance, if my repository contains foo.c, and 100 other files.
>
> I would like to create a new and separate repository containing only
> the revision history of foo.c.
>
> Would someone mind pointing me at some documentation for this
> procedure if it exists?
I think "git filter-branch" is what you need. Have it filter out
changes to files but foo.c, and then remove all empty commits.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] Add git-edit-index.perl
From: Jeff King @ 2008-12-18 14:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Neil Roberts, git
In-Reply-To: <alpine.DEB.1.00.0812181446430.6952@intel-tinevez-2-302>
On Thu, Dec 18, 2008 at 02:48:39PM +0100, Johannes Schindelin wrote:
> Yes, it is a neat idea. But I always keep in mind what Junio had to say
> about my "add -e" thing (that I use pretty frequently myself): you will
> put something into the index that has _never_ been tested.
>
> Would we really want to bless such a workflow with "official" support?
That is definitely something to be concerned about. Which is why my
workflow is something like:
$ hack hack hack
$ while ! git diff; do
git add -p
git commit
done
$ for i in `git rev-list origin..`; do
git checkout $i && make test || barf
done
That is, it is not inherently a problem to put something untested into
the index as long as you are doing it so that you can go back and test
later.
It _would_ be a nicer workflow to say "I don't want these changes yet"
and selectively put them elsewhere, test what's in the working tree,
commit, and then grab some more changes from your stash. But we don't
have interactive stashing and unstashing yet, which would be required
for that.
-Peff
^ permalink raw reply
* Re: is it possible filter the revision history of a single file into another repository?
From: Thomas Jarosch @ 2008-12-18 14:04 UTC (permalink / raw)
To: Whit Armstrong; +Cc: git
In-Reply-To: <8ec76080812180551p8c97a0dqa2025e67792946c7@mail.gmail.com>
On Thursday, 18. December 2008 14:51:12 Whit Armstrong wrote:
> For instance, if my repository contains foo.c, and 100 other files.
>
> I would like to create a new and separate repository containing only
> the revision history of foo.c.
>
> Would someone mind pointing me at some documentation for this
> procedure if it exists?
This worked for me:
git filter-branch --tag-name-filter cat --index-filter \
'git ls-files -s |grep -P "\t(DIR1|DIR2)" \
|GIT_INDEX_FILE=$GIT_INDEX_FILE.new git update-index --index-info &&
mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE' -- --all
Run "git ls-files -s" to see the output format.
Replace the "DIR1|DIR2" with "foo.c".
Later on you might want to remove empty commits from the history:
git filter-branch --tag-name-filter cat --commit-filter 'if [ z$1 = z`git rev-parse $3^{tree}` ]; then skip_commit "$@"; else git commit-tree "$@"; fi' "$@" -- --all
If you want to run two filter-branch commands in a row
or you want to free up the space in .git afterwards:
- git for-each-ref --format='%(refname)' refs/original | xargs -i git update-ref -d {}
- git reflog expire --expire=0 --all
- git repack -a -d
- git prune
Cheers,
Thomas
^ permalink raw reply
* Re: Git Notes idea.
From: Jeff King @ 2008-12-18 13:54 UTC (permalink / raw)
To: Govind Salinas; +Cc: Git Mailing List, Johannes Schindelin
In-Reply-To: <5d46db230812170906h7fdcac03o60386504c8df1083@mail.gmail.com>
On Wed, Dec 17, 2008 at 11:06:15AM -0600, Govind Salinas wrote:
> Yes, I was thinking that this is the natural way to do things, save that I
> would be lazy loading the trees into a cache instead of caching them
> all up front. This is one of the reasons that I think the fan out will
> help.
I was working under the assumption that you are going to do multiple
note lookups. If you are, then the fan-out isn't really going to help,
as you're going to end up pulling in all of the subtrees anyway. It
helps some if you're only doing a single lookup, but I don't know if
that is measurable.
> Yes, I completely agree that I want it to have the same scheme as what
> git will use. That is the reason I posted this here. Since no method
> has been formally accepted (checked into master) I wanted to see if
> I could nudge things along. I wasn't aware that you and Dscho had
> a (very similar) plan. Please, if you guys are decided on the format
> then I can just go off and start working on it. But it sounds like there
> isn't consensus yet.
This is probably not the answer you want, but I think the final design
depends on some C experiments. For example, whether or not there should
be fan-out depends on how it affects performance, which means we need to
do at least partial implementations to compare. So it really is just
waiting for somebody to sit down and do it.
> I like the overall plan, but I would suggest that --notes[=default] and
> --note-type=whatever would be a little friendlier and less error prone.
But keeping it as a single string means there is no ambiguity when you
specify multiple notes at once. For example:
git log \
--note-filter='test:status == "fail" && importance > 3' \
--pretty=format:%h%n%N(test:errors)
would do something like:
foreach commit $C
compare refs/notes/test:$C/status against the string "fail"
compare refs/notes/default:$C/importance against the number 3
if either don't match, skip the commit
show the hash and the contents of refs/notes/test:$C/errors
and obviously that filter language is totally made up and we may or may
not want to do something that complex. But my point is that we are
defining a namespace of notes, and we want to be able to refer to a
multiple fully qualified names.
-Peff
^ permalink raw reply
* is it possible filter the revision history of a single file into another repository?
From: Whit Armstrong @ 2008-12-18 13:51 UTC (permalink / raw)
To: git
For instance, if my repository contains foo.c, and 100 other files.
I would like to create a new and separate repository containing only
the revision history of foo.c.
Would someone mind pointing me at some documentation for this
procedure if it exists?
Thanks very much,
Whit
^ permalink raw reply
* Re: [PATCH] Add git-edit-index.perl
From: Johannes Schindelin @ 2008-12-18 13:48 UTC (permalink / raw)
To: Jeff King; +Cc: Neil Roberts, git
In-Reply-To: <20081218043734.GD20749@coredump.intra.peff.net>
Hi,
On Wed, 17 Dec 2008, Jeff King wrote:
> On Wed, Dec 17, 2008 at 08:47:49PM +0000, Neil Roberts wrote:
>
> > This script can be used to edit a file in the index without affecting
> > your working tree. It checkouts a copy of the file to a temporary file
> > and runs an editor on it. If the editor completes successfully with a
> > non-empty file then it updates the index with the new data.
>
> Hmm. Neat idea.
Yes, it is a neat idea. But I always keep in mind what Junio had to say
about my "add -e" thing (that I use pretty frequently myself): you will
put something into the index that has _never_ been tested.
Would we really want to bless such a workflow with "official" support?
Ciao,
Dscho
^ permalink raw reply
* Re: Announcement: Git Extensions stable (windows shell extensions)
From: Sverre Rabbelier @ 2008-12-18 13:44 UTC (permalink / raw)
To: Frank Li; +Cc: Henk, git
In-Reply-To: <1976ea660812180540g5efbcb42oe498503216d8a3c9@mail.gmail.com>
On Thu, Dec 18, 2008 at 14:40, Frank Li <lznuaa@gmail.com> wrote:
> I am considerring how to implement clone.
>
> I hope Git can provide a client library like SVN.
> I see libgit2 project. I hope git itself should use the same library.
The goal of libgit2 is to provide a library that git will use itself
for basic object manipulation. I do not know if operations like clone
are planned.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Is it possible to roll back unstaged changes while leaving the staged ones for the next commit?
From: Tim Visher @ 2008-12-18 12:24 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, git
In-Reply-To: <20081218123456.6117@nanako3.lavabit.com>
On Wed, Dec 17, 2008 at 10:34 PM, Nanako Shiraishi <nanako3@lavabit.com> wrote:
> A short answer is "no it is not the case."
Thanks.
> I was about to quote "git checkout" documentation to you because I was reasonably sure that Junio won't respond to people who ask a question whose answer is plainly described in the manual pages, but I think the description of the command is a little confusing especially for people who read it for the first time.
Agreed.
> When <paths> are given, this command does *not* switch
> branches. It updates the named paths in the working tree from
> the index file, or from a named <tree-ish> (most often a commit). In
> this case, the `-b` options is meaningless and giving
> either of them results in an error. <tree-ish> argument can be
> used to specify a specific tree-ish (i.e. commit, tag or tree)
Works a lot better.
Thanks for the help!
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* Re: [PATCH 4/5] Make 'diff_populate_filespec()' use the new 'strbuf_readlink()'
From: Mark Burton @ 2008-12-18 12:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0812171043440.14014@localhost.localdomain>
Howdy folks,
When I compile this latest version of diff.c on a i686 dual-core Pentium box
I see:
diff.c: In function ‘diff_populate_filespec’:
diff.c:1781: warning: passing argument 2 of ‘strbuf_detach’ from incompatible pointer type
The same code compiles without warning on a x86_64 AMD box. Both
machines are running stock Ubuntu 8.04.
Does it need a cast on some architectures?
Cheers,
Mark
^ permalink raw reply
* Retrieving last tag of a working tree
From: the_jack @ 2008-12-18 12:07 UTC (permalink / raw)
To: git
I'm using msys git on Windows XP for version tracking embedded design project
in C. I mostly work with GUIs (git-gui and qgit), I use bash only when I
have to.
I need to be able to access version from software. To do that, I use tags to
mark all released versions, and that version string is written to file
version.h (the file is not tracked) by pre-build command:
#define KDK_SOFTWARE_VERSION "0.72"
Precompiler assigns this string to a variable. At this moment, version.h is
filled by python script that calls "git-describe --tag HEAD" and parses the
output. This works, but it's not quite reliable. There has to be a better
way for getting the last tag of current working tree. If I checkout an
earlier tagged version (0.70), I would need to automatically get 0.70 inside
version.h
Can anyone shed any light on this?
--
View this message in context: http://www.nabble.com/Retrieving-last-tag-of-a-working-tree-tp21071491p21071491.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* [PATCH] guilt doc: use literal paragraphs for example commands
From: Wu Fengguang @ 2008-12-18 11:39 UTC (permalink / raw)
To: Josef Jeff Sipek; +Cc: git@vger.kernel.org
Display example commands verbatim by indenting the paragraphs.
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
---
Documentation/guilt-add.txt | 4 ++--
Documentation/guilt-delete.txt | 2 +-
Documentation/guilt-diff.txt | 2 +-
Documentation/guilt-help.txt | 4 ++--
Documentation/guilt-init.txt | 7 +++----
Documentation/guilt-new.txt | 6 +++---
Documentation/guilt-rebase.txt | 5 ++---
7 files changed, 14 insertions(+), 16 deletions(-)
--- guilt.orig/Documentation/guilt-add.txt
+++ guilt/Documentation/guilt-add.txt
@@ -23,8 +23,8 @@ EXAMPLES
Create and add a new file example.c
-$ touch example.c
-$ guilt-add example.c
+ $ touch example.c
+ $ guilt-add example.c
Author
------
--- guilt.orig/Documentation/guilt-delete.txt
+++ guilt/Documentation/guilt-delete.txt
@@ -25,7 +25,7 @@ EXAMPLES
--------
Delete a patch called 'foobar':
-$ guilt-delete foobar
+ $ guilt-delete foobar
Author
------
--- guilt.orig/Documentation/guilt-diff.txt
+++ guilt/Documentation/guilt-diff.txt
@@ -18,7 +18,7 @@ OPTIONS
-------
-z::
Output a interdiff against the top-most applied patch. This should
- produce the same diff as "guilt-new -f foo".
+ produce the same diff as "+guilt-new -f foo+".
<path>...::
Restrict diff output to a given set of files.
--- guilt.orig/Documentation/guilt-help.txt
+++ guilt/Documentation/guilt-help.txt
@@ -18,11 +18,11 @@ EXAMPLES
Open the guilt-status man page
-$ guilt-help status
+ $ guilt-help status
Open the guilt man page
-$ guilt-help
+ $ guilt-help
Author
------
--- guilt.orig/Documentation/guilt-init.txt
+++ guilt/Documentation/guilt-init.txt
@@ -17,13 +17,12 @@ EXAMPLES
--------
First, get a repository to work on. Here's one that we'll use as an example:
-$ git-clone git://git.kernel.org/pub/scm/linux/kernel/jsipek/guilt-hello.git
+ $ git-clone git://git.kernel.org/pub/scm/linux/kernel/jsipek/guilt-hello.git
Now, it initialize the patches directory using guilt's init command:
-$ cd hello
-
-$ guilt-init
+ $ cd hello
+ $ guilt-init
Author
------
--- guilt.orig/Documentation/guilt-new.txt
+++ guilt/Documentation/guilt-new.txt
@@ -42,16 +42,16 @@ EXAMPLES
Create a new patch called 'foobar':
-$ guilt-new foobar
+ $ guilt-new foobar
Create a patch called 'foo' and supply a patch description interactively:
-$ guilt-new -e foo
+ $ guilt-new -e foo
Create a patch called 'bar' with a provided patch description and sign off
on the patch:
-$ guilt-new -s -m patch-fu bar
+ $ guilt-new -s -m patch-fu bar
Author
------
--- guilt.orig/Documentation/guilt-rebase.txt
+++ guilt/Documentation/guilt-rebase.txt
@@ -24,9 +24,8 @@ EXAMPLES
Rebase current tree against Linus's 2.6 tree
-$ git-fetch git://git.kernel.org/pub/scm/linux/kernel/git/tovalds/linux-2.6.git
-
-$ guilt-rebase FETCH_HEAD
+ $ git-fetch git://git.kernel.org/pub/scm/linux/kernel/git/tovalds/linux-2.6.git
+ $ guilt-rebase FETCH_HEAD
Author
------
^ permalink raw reply
* [PATCH][RESEND] guilt: add option guilt.diffstat
From: Wu Fengguang @ 2008-12-18 11:26 UTC (permalink / raw)
To: Josef Jeff Sipek; +Cc: git@vger.kernel.org, Boyd Stephen Smith Jr.
In-Reply-To: <20081213131700.GA8649@localhost>
Introduce option guilt.diffstat so that we don't have to type
"guilt refresh --diffstat" in its full form every time.
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
---
Jeff: This patch is against the latest guilt v0.32-rc1.
Documentation/guilt-refresh.txt | 10 ++++++++--
guilt | 9 ++++++++-
2 files changed, 16 insertions(+), 3 deletions(-)
--- guilt.orig/guilt
+++ guilt/guilt
@@ -646,7 +646,7 @@ __refresh_patch()
[ ! -z "$4" ] && diffopts="-C -M --find-copies-harder"
- if [ ! -z "$5" ]; then
+ if [ -n "$5" -o $diffstat = "true" ]; then
(
echo "---"
git diff --stat $diffopts "$2"
@@ -737,10 +737,17 @@ guilt_hook()
# used for: git apply -C <val>
guilt_push_diff_context=1
+# default diffstat value: true or false
+DIFFSTAT_DEFAULT="false"
+
#
# Parse any part of .git/config that belongs to us
#
+# generate diffstat?
+diffstat=`git config --bool guilt.diffstat`
+[ -z "$diffstat" ] && diffstat=$DIFFSTAT_DEFAULT
+
#
# The following gets run every time this file is source'd
#
--- guilt.orig/Documentation/guilt-refresh.txt
+++ guilt/Documentation/guilt-refresh.txt
@@ -20,8 +20,14 @@ OPTIONS
format (e.g., rename and copy detection).
--diffstat::
- Include a diffstat output in the patch file. Useful for cases where
- patches will be submitted with other tools.
+Include a diffstat output in the patch file. Useful for cases where
+patches will be submitted with other tools.
++
+If the command line option is omitted, the corresponding git-config
+option "guilt.diffstat" will be queried. So this would enable diffstat
+output by default:
+
+ git config --global guilt.diffstat true
Author
------
^ permalink raw reply
* Re: [PATCH] gitk: Ensure that "Reset branch" menu entry is enabled
From: Johannes Sixt @ 2008-12-18 10:42 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Git Mailing List
In-Reply-To: <1228308200-28693-1-git-send-email-j6t@kdbg.org>
Johannes Sixt schrieb:
> Consider this sequence of events:
>
> 1. Detach HEAD and fire up gitk
> 2. Call the context menu on some commit. Notice that the last menu entry
> says "Detached HEAD: can't reset" and it is disabled.
> 3. Now checkout some regular branch (e.g. 'master') using the context menu.
> 4. Call the context menu again on some commit.
>
> Previously, at this point the last menu entry said "Reset master branch
> to here", but it was still disabled. With this fix it is now enabled again.
Did you consider this patch?
-- Hannes
>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
> gitk | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/gitk b/gitk
> index f7f1776..6c4022a 100755
> --- a/gitk
> +++ b/gitk
> @@ -7950,7 +7950,7 @@ proc rowmenu {x y id} {
> if {$id ne $nullid && $id ne $nullid2} {
> set menu $rowctxmenu
> if {$mainhead ne {}} {
> - $menu entryconfigure 7 -label [mc "Reset %s branch to here" $mainhead]
> + $menu entryconfigure 7 -label [mc "Reset %s branch to here" $mainhead] -state normal
> } else {
> $menu entryconfigure 7 -label [mc "Detached head: can't reset" $mainhead] -state disabled
> }
^ permalink raw reply
* Re: [PATCH] gitk: Use check-buttons' -text property instead of separate labels
From: Johannes Sixt @ 2008-12-18 10:41 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <200812022142.16095.j6t@kdbg.org>
Johannes Sixt schrieb:
> Previously the check-buttons' labels in the Preferences were separate
> widgets. This had the disadvantage that in order to toggle the check-button
> with the mouse the check-box had to be clicked. With this change the
> check-box can also be toggled by clicking the label.
Did you consider this patch?
-- Hannes
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
> gitk | 30 ++++++++++--------------------
> 1 files changed, 10 insertions(+), 20 deletions(-)
>
> diff --git a/gitk b/gitk
> index 64a873d..ee1941c 100755
> --- a/gitk
> +++ b/gitk
> @@ -10079,15 +10079,11 @@ proc doprefs {} {
> -font optionfont
> spinbox $top.maxpct -from 1 -to 100 -width 4 -textvariable maxgraphpct
> grid x $top.maxpctl $top.maxpct -sticky w
> - frame $top.showlocal
> - label $top.showlocal.l -text [mc "Show local changes"] -font optionfont
> - checkbutton $top.showlocal.b -variable showlocalchanges
> - pack $top.showlocal.b $top.showlocal.l -side left
> + checkbutton $top.showlocal -text [mc "Show local changes"] \
> + -font optionfont -variable showlocalchanges
> grid x $top.showlocal -sticky w
> - frame $top.autoselect
> - label $top.autoselect.l -text [mc "Auto-select SHA1"] -font optionfont
> - checkbutton $top.autoselect.b -variable autoselect
> - pack $top.autoselect.b $top.autoselect.l -side left
> + checkbutton $top.autoselect -text [mc "Auto-select SHA1"] \
> + -font optionfont -variable autoselect
> grid x $top.autoselect -sticky w
>
> label $top.ddisp -text [mc "Diff display options"]
> @@ -10095,20 +10091,14 @@ proc doprefs {} {
> label $top.tabstopl -text [mc "Tab spacing"] -font optionfont
> spinbox $top.tabstop -from 1 -to 20 -width 4 -textvariable tabstop
> grid x $top.tabstopl $top.tabstop -sticky w
> - frame $top.ntag
> - label $top.ntag.l -text [mc "Display nearby tags"] -font optionfont
> - checkbutton $top.ntag.b -variable showneartags
> - pack $top.ntag.b $top.ntag.l -side left
> + checkbutton $top.ntag -text [mc "Display nearby tags"] \
> + -font optionfont -variable showneartags
> grid x $top.ntag -sticky w
> - frame $top.ldiff
> - label $top.ldiff.l -text [mc "Limit diffs to listed paths"] -font optionfont
> - checkbutton $top.ldiff.b -variable limitdiffs
> - pack $top.ldiff.b $top.ldiff.l -side left
> + checkbutton $top.ldiff -text [mc "Limit diffs to listed paths"] \
> + -font optionfont -variable limitdiffs
> grid x $top.ldiff -sticky w
> - frame $top.lattr
> - label $top.lattr.l -text [mc "Support per-file encodings"] -font optionfont
> - checkbutton $top.lattr.b -variable perfile_attrs
> - pack $top.lattr.b $top.lattr.l -side left
> + checkbutton $top.lattr -text [mc "Support per-file encodings"] \
> + -font optionfont -variable perfile_attrs
> grid x $top.lattr -sticky w
>
> entry $top.extdifft -textvariable extdifftool
--
DI Johannes Sixt
Leiter Softwareentwicklung
Viscovery Software GmbH
Landstrasse 11
A-4020 Linz, Austria
T: +43-1-532 0570-51
M: +43-676-8494 9571
F: +43-1-532 0570-33
j.sixt@viscovery.net
www.viscovery.net
t u r n y o u r d a t a i n t o r e a l v a l u e !
^ permalink raw reply
* Re: [PATCHv5 2/3] gitweb: add patches view
From: Jakub Narebski @ 2008-12-18 9:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Giuseppe Bilotta, git, Petr Baudis
In-Reply-To: <7v4p12hv5q.fsf@gitster.siamese.dyndns.org>
On Thu, 18 Dec 2008, Junio C Hamano wrote:
> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
>
> > sub git_commitdiff {
> > my $format = shift || 'html';
> > + my %params = @_;
> > ...
> > + if ($params{-single}) {
> > + push @commit_spec, '-1';
> > + } else {
> > + if ($patch_max > 0) {
> > ...
> > + }
> > @@ -5625,6 +5635,10 @@ sub git_commitdiff_plain {
> >
> > # format-patch-style patches
> > sub git_patch {
> > + git_commitdiff('patch', -single=> 1);
> > +}
>
> Hmm, if you are changing the interface this way, wouldn't it make more
> sense to also do this?
>
> git_commitdiff(--format => 'patch', --single => 1);
> git_commitdiff(--format => 'html');
The first argument (format) is _required_, second is _optional_;
I'd rather use named parameters trick only for optional parameters.
Because with more than one optional parameter function call begins
to be cryptic; also flag (boolean) parameters are more readable
when used as named parameters.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] gitk: Allow unbalanced quotes/braces in commit headers
From: Kevin Ballard @ 2008-12-18 9:26 UTC (permalink / raw)
To: Paul Mackerras, demerphq, git; +Cc: Kevin Ballard
When parsing commits, gitk treats the headers of the commit as tcl lists.
This causes errors if the header contains an unbalanced quote or open brace.
Splitting the line on spaces allows us to treat it as a set of words instead
of as a tcl list, which prevents errors.
Signed-off-by: Kevin Ballard <kevin@sb.org>
---
gitk | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/gitk b/gitk
index a5e24e4..83b45cd 100755
--- a/gitk
+++ b/gitk
@@ -1601,13 +1601,14 @@ proc parsecommit {id contents listed} {
set header [string range $contents 0 [expr {$hdrend - 1}]]
set comment [string range $contents [expr {$hdrend + 2}] end]
foreach line [split $header "\n"] {
+ set line [split $line " "]
set tag [lindex $line 0]
if {$tag == "author"} {
set audate [lindex $line end-1]
- set auname [lrange $line 1 end-2]
+ set auname [join [lrange $line 1 end-2] " "]
} elseif {$tag == "committer"} {
set comdate [lindex $line end-1]
- set comname [lrange $line 1 end-2]
+ set comname [join [lrange $line 1 end-2] " "]
}
}
set headline {}
--
1.6.1.rc3.334.g7365d
^ permalink raw reply related
* Re: git-format-patch patch
From: Junio C Hamano @ 2008-12-18 8:42 UTC (permalink / raw)
To: Jeff King; +Cc: jidanni, git
In-Reply-To: <20081218083515.GB29356@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> ... Besides the format not being applicable by regular git tools:
>
> - there is no commit message describing the changes, nor the reasoning
> behind them
>
> - it was not sent to the maintainer (who does read the list, but does
> not always read every message).
Actually, it would probably be a good idea not to send your first patch to
me and instead to request for comments from the list ;-)n
The worst offence of the message was the choice of bad Subject that
strongly encouraged anyone to skip it. Consider:
Subject: [PATCH] document "format-patch --in-reply-to" better
or something like that.
^ permalink raw reply
* Re: Announcement: Git Extensions stable (windows shell extensions)
From: Sverre Rabbelier @ 2008-12-18 8:36 UTC (permalink / raw)
To: Henk; +Cc: git
In-Reply-To: <1229587749729-1672012.post@n2.nabble.com>
On Thu, Dec 18, 2008 at 09:09, Henk <henk_westhuis@hotmail.com> wrote:
> If you have problems during development, please ask, I might allready
> encountered some. Especially when you are starting on the features that need
> userinteraction like push/pull/clone/mergetool. These cannot just be run as
> a command and catching the standard output. In the version of GitExtensions
> I published I just run the commands, but I allready have a prototype build
> in c# combined with some c++ that directly calls some (exported) Git
> functions. Just executing git.exe is the fastest way of creating a gui, but
> its not the best way of doiing things.
Perhaps you could consider contributing to libgit2 for this purpose, I
reckon C# has some way to import C libraries, yes?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: git-format-patch patch
From: Jeff King @ 2008-12-18 8:35 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <877i5yy149.fsf@jidanni.org>
On Thu, Dec 18, 2008 at 04:53:42AM +0800, jidanni@jidanni.org wrote:
> I'm still reading the manpage about submitting proper patches, so for now:
It looks like you didn't even use git to create it (since it is a
context diff and the filenames are obviously bogus). If you are
committed to improving git, then surely using it is not so bad? :)
Try cloning git://git.kernel.org/pub/scm/git/git.git, or if you just
have a tarball, at least do "cd /path/to/git && git init && git add . &&
git commit -m 'import from git version $whatever'". Then you can make
your changes and have git track them and prepare them for submission.
Then read Documentation/SubmittingPatches, which covers some of the
basics. Besides the format not being applicable by regular git tools:
- there is no commit message describing the changes, nor the reasoning
behind them
- it was not sent to the maintainer (who does read the list, but does
not always read every message).
> --in-reply-to=Message-Id::
> Make the first mail (or all the mails with --no-thread) appear as a
> reply to the given Message-Id, which avoids breaking threads to
> ! provide a new patch series. Generates coresponding References and
> ! In-Reply-To headers. Angle brackets around <Message-Id> are optional.
As for the change itself, it looks reasonable to me.
-Peff
^ permalink raw reply
* Re: Suggestion: better error reporting when setting HEAD
From: Jeff King @ 2008-12-18 8:25 UTC (permalink / raw)
To: Francois Marier; +Cc: Junio C Hamano, git, sam.vilain
In-Reply-To: <20081218055825.GQ6708@isafjordur.dyndns.org>
[Junio cc'd, as I think he may have comments on the patch at the end]
On Thu, Dec 18, 2008 at 06:58:25PM +1300, Francois Marier wrote:
> If you take any valid git repo and then do the following:
>
> git symbolic-ref HEAD master
> (instead of "git symbolic-ref HEAD refs/heads/master")
>
> then other git commands (e.g. "git log") will return this error message:
>
> fatal: Not a git repository
I've done this exact same thing, and it is very annoying.
> I'd like to suggest two "usability" improvements:
>
> 1- changing the error message to explain why the directory is no longer
> considered a git repo. Maybe something along the lines of:
>
> fatal: Invalid reference in .git/HEAD
This can be done, but is more complex than you might hope; the test for
"is this is a git directory" may get run multiple times while trying to
find out if we are in a repo. So giving a reason why we aren't in a git
repo is going to end up something like:
I tried X, but its HEAD ref had cruft in it;
then I tried Y, but it had no HEAD file;
then I gave up
Obviously with a working tree, the first directory with the '.git' repo
is a likely candidate for being the right thing, but with an error. But
if you are looking for a bare repository, then it could be any parent
directory. Maybe it is worth just spewing "there is a HEAD file here,
but it doesn't look right" when it fails to validate. It would give a
false positive if you had a file named HEAD (and you weren't actually in
a git repo), but that is unlikely to happen. And if you get multiple
ones, so be it.
> 2- To prevent this error from happening in the first place, git-symbolic-ref
> could refuse to change HEAD to a non-existent ref.
Actually, we sometimes need to point to non-existent refs; these are
"branches yet to be born". The reason that the new HEAD doesn't validate
is that it is supposed to start with "refs/".
We could fix it like this:
diff --git a/builtin-symbolic-ref.c b/builtin-symbolic-ref.c
index bfc78bb..08fa3ce 100644
--- a/builtin-symbolic-ref.c
+++ b/builtin-symbolic-ref.c
@@ -44,6 +44,8 @@ int cmd_symbolic_ref(int argc, const char **argv, const char *prefix)
check_symref(argv[0], quiet);
break;
case 2:
+ if (prefixcmp(argv[1], "refs/"))
+ die("Refusing to point %s outside of refs/", argv[0]);
create_symref(argv[0], argv[1], msg);
break;
default:
which tries to match the behavior used by validate_headref, but there
are a few open questions:
- Should it require this of _all_ symbolic refs, or just HEAD?
- Should there be a "-f" force option?
- Should it be moved to the create_symref library function. It gets
called in several places, and I didn't audit all of them.
- I looked at trying to share validate_headref's logic (so they don't
get out of sync), but really the only thing that applies is the
"refs" check. The rest is about checking parts of the symref that are
outside of the actual content.
- This doesn't allow a sha1 for detached HEAD. However, that currently
doesn't work _anyway_, as it creates a HEAD with "ref: $SHA1", which
is totally bogus.
-Peff
^ permalink raw reply related
* Re: Announcement: Git Extensions stable (windows shell extensions)
From: Henk @ 2008-12-18 8:09 UTC (permalink / raw)
To: git
In-Reply-To: <1976ea660812171757s37e8435cxc4d34ade04635b81@mail.gmail.com>
If you have problems during development, please ask, I might allready
encountered some. Especially when you are starting on the features that need
userinteraction like push/pull/clone/mergetool. These cannot just be run as
a command and catching the standard output. In the version of GitExtensions
I published I just run the commands, but I allready have a prototype build
in c# combined with some c++ that directly calls some (exported) Git
functions. Just executing git.exe is the fastest way of creating a gui, but
its not the best way of doiing things.
Li Frank wrote:
>
> Great Work!
> TortoiseGit start late. But it reuse many TortoiseSVN work.
> I believe TortoiseGit can catch.
>
--
View this message in context: http://n2.nabble.com/Announcement%3A-Git-Extensions-stable-%28windows-shell-extensions%29-tp1669264p1672012.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: How to maintain private/secret/confidential branch.
From: Daniel Barkalow @ 2008-12-18 8:03 UTC (permalink / raw)
To: Łukasz Lew; +Cc: Alexander Potashev, Nick Andrew, git
In-Reply-To: <c55009e70812171431l7eab33b2x28c5b4360118880b@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 5090 bytes --]
On Wed, 17 Dec 2008, Łukasz Lew wrote:
> >> > Often, resolve easy conflicts where my mixed-work branch introduced bugs
> >> > that I fixed later and have now adopted the fixed code
> >> >
> >> > Then I repeat until I don't have any more good changes in mixed-work
> >> > (either I have nothing, only debugging cruft, or only stuff I haven't
> >> > gotten to work yet). If there's nothing but cruft, I've fully merged the
> >> > topic, and I delete the branch.
> >> >
> >> > Eventually, I'm satisfied with what I've cleaned up, and I do:
> >> > $ git push origin submit:master
> >> >
> >> > Also, I generally have a bunch of "mixed-work" branches, each containing
> >> > different stuff that isn't ready. I'll periodicly go through all of them
> >> > and rebase onto "submit" or "origin/master" (or, sometimes, give up on
> >> > them and delete them).
> >> >
> >> > (One thing that would be nice to have is a "git apply --interactive" which
> >> > applies the user's choice of hunks, like "git add -i" adds them)
> >>
> >> I totally agree.
> >>
> >> I would appriciate rebase --copy option, which doesn't move, but copy
> >> the changelists like cherry-pick.
> >
> > There's work in progress on a generalization of "rebase -i" that could be
> > seeded with the "cherry-pick" operations instead of the "rebase"
> > operations. I think that's what you'd like.
>
> I always wanted to have system that would allow me manipulation of
> patches as features.
> I.e: I have one patch for feature X, one for Y, one for debugging X,
> one for debugging Y, etc.
> Then I would just pick some of them, work with them to create new ones.
>
> The basic operations would be use/unuse patch, combine sequence of
> patches into one (with commit messages of subpatches saved somewhere),
> uncombine patch into sequence of patches.
> Easy way of spliting atomic patch (diff) into several more so I can
> add more commit messages.
>
> Now this would resemble directory structure, I could copy/move/remove
> patches from/to various bigger packs of patches. Merging would detect
> duplicates of course.
>
> Git took me for the first time close to this ideal.
Git works from the point of view of a developer producing the ideal
development history that doesn;t (necessarily) include false starts, bugs
fixed in private, and changes mixed together. Or rather, git allows a
developer to make commits again knowing the full outcome of the series.
It also works from the point of view of a maintainer who merges or does
not merge the output of developers working in this mode.
It doesn't really quite handle the work of an integrator whose work is to
manage a patch queue. I think it needs some additional tools which allow
the user do work which consists of operations like "replace this
patch/branch with a new version", "suppress this patch/branch", "reorder
these patches/branches", and the main thing: "produce a version of my
current series with conflict resolutions"
This would actually be really helpful to have explicitly represented, so
that people could actually bisect the -mm series to find the operation
that Andrew did that caused a problem to enter the series, which would be
something like adding a patch that doesn't work with other patches in the
series. Note that this is different from bisecting within the failing
state of the -mm tree, which finds where the series seen as a difference
from mainline, fails; if you know that -mm yesterday works and -mm today
fails, the difference might be that a branch merged early in the series
was updated to a version incompatible with a branch later in the series
that hasn't changed, and you'd want to finger the update rather than the
point in the series where kernels start failing.
> > On the other hand, remember
> > that you can just make a new branch based on your endpoint and rebase it
> > on your upstream; there's no reason that you can't "unzip" the history
> > past the point where the branch you're modifying was created.
>
> I never thought about that. It works indeed.
There's a lot you can do when branches are as cheap and flexible as git's
branches are.
> >> Then we could use rebase -i (with edit) instead of apply.
> >>
> >> PS
> >> Why after edit in rebase -i the change is already commited? I always
> >> have to reset;add -i
> >
> > There's (currently) no equivalent of the index (storing the contents of
> > the commit in progress) for the message (and author info, etc). On the
> > other hand, you can use "git commit --amend" to alter the commit on top
> > (including the files), and you can do "git diff HEAD HEAD^ | git apply" to
> > get reverts into your worktree that you can add (or not add).
>
> Good idea, thanks.
> BTW is it diff | apply the same as revert --no-commit?
Largely, although you can give the diff/apply pair paths you want to
revert, and not revert the whole thing. And the second commit can be
anything with the diff/apply pair, not just HEAD^, which is what revert
does, so it's a worthwhile generalization to understand.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH v2] gitk: force the focus to the main window on Windows
From: Johannes Sixt @ 2008-12-18 7:30 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Git Mailing List, Johannes Schindelin
In-Reply-To: <18761.29020.237388.687560@cargo.ozlabs.ibm.com>
From: Johannes Sixt <j6t@kdbg.org>
On msysGit, the focus is first on the (Tk) console. This console is then
hidden, but keeps the focus. Work around that by forcing the focus onto
the gitk window.
This fixes msysGit issue 14. Diagnosed and originally fixed by
Johannes Schindelin.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
Paul Mackerras schrieb:
> At least put a if {[tk windowingsystem] eq "win32"} in there.
> (msysGit is a windows thing, isn't it?)
I did that.
-- Hannes
gitk | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/gitk b/gitk
index b63109b..121b621 100644
--- a/gitk
+++ b/gitk
@@ -10898,4 +10898,9 @@ if {[info exists permviews]} {
addviewmenu $n
}
}
+
+if {[tk windowingsystem] eq "win32"} {
+ focus -force .
+}
+
getcommits {}
--
1.6.1.rc3.950.g5dd2
^ permalink raw reply related
* [PATCHv6 4/4] gitweb: link to patch(es) view in commit(diff) and (short)log view
From: Giuseppe Bilotta @ 2008-12-18 7:13 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1229584399-23879-4-git-send-email-giuseppe.bilotta@gmail.com>
We link to patch view in commit and commitdiff view, and to patches view
in log and shortlog view.
In (short)log view, the link is only offered when the number of commits
shown is no more than the allowed maximum number of patches.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 30 ++++++++++++++++++++++++++++--
1 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 78aaebe..fd8bc29 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -5024,6 +5024,15 @@ sub git_log {
my $paging_nav = format_paging_nav('log', $hash, $head, $page, $#commitlist >= 100);
+ my ($patch_max) = gitweb_get_feature('patches');
+ if ($patch_max) {
+ if ($patch_max < 0 || @commitlist <= $patch_max) {
+ $paging_nav .= " ⋅ " .
+ $cgi->a({-href => href(action=>"patches", -replay=>1)},
+ "patches");
+ }
+ }
+
git_header_html();
git_print_page_nav('log','', $hash,undef,undef, $paging_nav);
@@ -5103,6 +5112,11 @@ sub git_commit {
} @$parents ) .
')';
}
+ if (gitweb_check_feature('patches')) {
+ $formats_nav .= " | " .
+ $cgi->a({-href => href(action=>"patch", -replay=>1)},
+ "patch");
+ }
if (!defined $parent) {
$parent = "--root";
@@ -5416,9 +5430,8 @@ sub git_commitdiff {
my %params = @_;
my $format = $params{-format} || 'html';
- my $patch_max;
+ my ($patch_max) = gitweb_get_feature('patches');
if ($format eq 'patch') {
- ($patch_max) = gitweb_get_feature('patches');
die_error(403, "Patch view not allowed") unless $patch_max;
}
@@ -5436,6 +5449,11 @@ sub git_commitdiff {
$formats_nav =
$cgi->a({-href => href(action=>"commitdiff_plain", -replay=>1)},
"raw");
+ if ($patch_max) {
+ $formats_nav .= " | " .
+ $cgi->a({-href => href(action=>"patch", -replay=>1)},
+ "patch");
+ }
if (defined $hash_parent &&
$hash_parent ne '-c' && $hash_parent ne '--cc') {
@@ -5992,6 +6010,14 @@ sub git_shortlog {
$cgi->a({-href => href(-replay=>1, page=>$page+1),
-accesskey => "n", -title => "Alt-n"}, "next");
}
+ my $patch_max = gitweb_check_feature('patches');
+ if ($patch_max) {
+ if ($patch_max < 0 || @commitlist <= $patch_max) {
+ $paging_nav .= " ⋅ " .
+ $cgi->a({-href => href(action=>"patches", -replay=>1)},
+ "patches");
+ }
+ }
git_header_html();
git_print_page_nav('shortlog','', $hash,$hash,$hash, $paging_nav);
--
1.5.6.5
^ 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