Git development
 help / color / mirror / Atom feed
* [PATCH 7/7] gitk: Explicitly position popup windows.
From: Alexander Gavrilov @ 2008-10-08  7:05 UTC (permalink / raw)
  To: git; +Cc: Paul Mackerras
In-Reply-To: <1223449540-20457-7-git-send-email-angavrilov@gmail.com>

For some reason, on Windows all transient windows are placed
in the upper left corner of the screen. Thus, it is necessary
to explicitly position the windows using the tk::PlaceWindow
function.

Reference list and the Edit View dialog are positioned under
the mouse cursor, thus allowing the user to create them in a
convenient place using keyboard shortcuts, and providing a
sane position when opened through the menu.

Other popups are centered on the main window.

Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
 gitk |   19 +++++++++++++++++--
 1 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/gitk b/gitk
index c7dd487..9e580a6 100755
--- a/gitk
+++ b/gitk
@@ -1703,7 +1703,7 @@ proc removehead {id name} {
     unset headids($name)
 }
 
-proc show_error {w top msg} {
+proc show_error {w top msg {owner {}}} {
     message $w.m -text $msg -justify center -aspect 400
     pack $w.m -side top -fill x -padx 20 -pady 20
     button $w.ok -text [mc OK] -command "destroy $top"
@@ -1712,6 +1712,9 @@ proc show_error {w top msg} {
     bind $top <Key-Return> "destroy $top"
     bind $top <Key-space>  "destroy $top"
     bind $top <Key-Escape> "destroy $top"
+    if {$owner ne {}} {
+	tk::PlaceWindow $top widget $owner
+    }
     tkwait window $top
 }
 
@@ -1719,7 +1722,7 @@ proc error_popup {msg {owner .}} {
     set w .error
     toplevel $w
     wm transient $w $owner
-    show_error $w $w $msg
+    show_error $w $w $msg $owner
 }
 
 proc confirm_popup {msg {owner .}} {
@@ -1738,6 +1741,7 @@ proc confirm_popup {msg {owner .}} {
     bind $w <Key-Return> "set confirm_ok 1; destroy $w"
     bind $w <Key-space>  "set confirm_ok 1; destroy $w"
     bind $w <Key-Escape> "destroy $w"
+    tk::PlaceWindow $w widget $owner
     tkwait window $w
     return $confirm_ok
 }
@@ -2493,6 +2497,7 @@ Use and redistribute under the terms of the GNU General Public License"] \
     bind $w <Visibility> "focus $w.ok"
     bind $w <Key-Escape> "destroy $w"
     bind $w <Key-Return> "destroy $w"
+    tk::PlaceWindow $w widget .
 }
 
 proc keys {} {
@@ -2554,6 +2559,7 @@ proc keys {} {
     bind $w <Visibility> "focus $w.ok"
     bind $w <Key-Escape> "destroy $w"
     bind $w <Key-Return> "destroy $w"
+    tk::PlaceWindow $w widget .
 }
 
 # Procedures for manipulating the file list window at the
@@ -3497,6 +3503,7 @@ proc vieweditor {top n title} {
     grid columnconfigure $top.buts 1 -weight 1 -uniform a
     grid columnconfigure $top.buts 2 -weight 1 -uniform a
     pack $top.buts -in $top -side top -fill x
+    tk::PlaceWindow $top pointer .
     focus $top.t
 }
 
@@ -7684,6 +7691,7 @@ proc mkpatch {} {
     grid columnconfigure $top.buts 1 -weight 1 -uniform a
     grid $top.buts - -pady 10 -sticky ew
     focus $top.fname
+    tk::PlaceWindow $top widget .
 }
 
 proc mkpatchrev {} {
@@ -7758,6 +7766,7 @@ proc mktag {} {
     grid columnconfigure $top.buts 1 -weight 1 -uniform a
     grid $top.buts - -pady 10 -sticky ew
     focus $top.tag
+    tk::PlaceWindow $top widget .
 }
 
 proc domktag {} {
@@ -7865,6 +7874,7 @@ proc writecommit {} {
     grid columnconfigure $top.buts 1 -weight 1 -uniform a
     grid $top.buts - -pady 10 -sticky ew
     focus $top.fname
+    tk::PlaceWindow $top widget .
 }
 
 proc wrcomgo {} {
@@ -7914,6 +7924,7 @@ proc mkbranch {} {
     grid columnconfigure $top.buts 1 -weight 1 -uniform a
     grid $top.buts - -pady 10 -sticky ew
     focus $top.name
+    tk::PlaceWindow $top widget .
 }
 
 proc mkbrgo {top} {
@@ -8093,6 +8104,7 @@ proc resethead {} {
     bind $w <Key-Escape> [list destroy $w]
     pack $w.cancel -side right -fill x -padx 20 -pady 20
     bind $w <Visibility> "grab $w; focus $w"
+    tk::PlaceWindow $w widget .
     tkwait window $w
     if {!$confirm_ok} return
     if {[catch {set fd [open \
@@ -8278,6 +8290,7 @@ proc showrefs {} {
     bind $top.list <ButtonRelease-1> {sel_reflist %W %x %y; break}
     set reflist {}
     refill_reflist
+    tk::PlaceWindow $top pointer .
 }
 
 proc sel_reflist {w x y} {
@@ -9630,6 +9643,7 @@ proc choosefont {font which} {
 	grid columnconfigure $top.buts 1 -weight 1 -uniform a
 	pack $top.buts -side bottom -fill x
 	trace add variable fontparam write chg_fontparam
+	tk::PlaceWindow $top widget $prefstop
     } else {
 	raise $top
 	$top.c itemconf text -text $which
@@ -9801,6 +9815,7 @@ proc doprefs {} {
     grid columnconfigure $top.buts 1 -weight 1 -uniform a
     grid $top.buts - - -pady 10 -sticky ew
     bind $top <Visibility> "focus $top.buts.ok"
+    tk::PlaceWindow $top widget .
 }
 
 proc choose_extdiff {} {
-- 
1.6.0.20.g6148bc

^ permalink raw reply related

* Re: [PATCH v2 RFC] rebase-i-p: squashing and limiting todo
From: Stephen Haberman @ 2008-10-08  7:15 UTC (permalink / raw)
  To: git; +Cc: spearce
In-Reply-To: <cover.1223445353.git.stephen@exigencecorp.com>


> This is v2 of my attempt at keeping commits with
> no-parents-being-rewritten off the rebase-i-p todo list. 

I forgot to mention, this series almost certainly conflicts with pu's
sh/maint-rebase3. Given that pu is not next, I think I did the right
thing by keeping this series separate, but I can merge them into one
series if that is preferable.

Thanks,
Stephen

^ permalink raw reply

* Re: [PATCH v2 RFC] rebase-i-p: test to exclude commits from todo based on its parents
From: Junio C Hamano @ 2008-10-08  7:24 UTC (permalink / raw)
  To: Stephen Haberman; +Cc: git, spearce
In-Reply-To: <e5ababa1de420b6460fd856679990c9dd2caf1d1.1223445353.git.stephen@exigencecorp.com>

Stephen Haberman <stephen@exigencecorp.com> writes:

> +# set up two branches like this:
> +#
> +# A1 - B1 - D1 - E1 - F1
> +#       \        /
> +#        -- C1 --
> ...
> +test_expect_success 'setup' '
> ...
> +'
> +
> +# Should result in:
> +#
> +# A1 - B1 - D2 - E2
> +#       \        /
> +#        -- C1 --
> +#
> +test_expect_success 'squash F1 into D1' '
> +	FAKE_LINES="1 squash 3 2" git rebase -i -p B1 &&
> +	test "$(git rev-parse HEAD^2)" = "$(git rev-parse branch)" &&
> +	test "$(git rev-parse HEAD~2)" = "$(git rev-parse B1)" &&
> +	git tag E2
> +'

Very nicely written test sequence with pictures.  I wish all the tests
were written like this.

> +# Start with:
> +#
> +# A1 - B1 - D2 - E2
> +#  \
> +#   G1 ---- L1 ---- M1
> +#    \             /
> +#     H1 -- J1 -- K1
> +#      \         /
> +#        -- I1 --
> +#
> +# And rebase G1..M1 onto E3

I think s/E3/E2/ is what you meant.

If this is the first one in the series, you may want to mark these tests
with test_expect_failure and make a later patch that changes the behaviour
of rebase-i-p include updates to the test script to turn expect-failure
into expect-success.

^ permalink raw reply

* Re: [msysGit] Re: [FYI][PATCH] Customizing the WinGit installer
From: Junio C Hamano @ 2008-10-08  7:38 UTC (permalink / raw)
  To: Petr Baudis
  Cc: Linus Torvalds, Dmitry Potapov, Johannes Schindelin,
	Jakub Narebski, msysgit, git
In-Reply-To: <20081007092819.GW10360@machine.or.cz>

Petr Baudis <pasky@suse.cz> writes:

> Note that as mentioned in the original mail, my patch was not meant
> for application upstream, just as an example for others who would like
> to customize the Git installer for a particular environment. We wanted
> to make Git installation/usage as simple as possible, reducing any
> unnecessary steps we could - and this was an easy one.

I do not personally think showing the license is necessary in the
installer, but unlike the earlier one that refused to proceed until the
user says "I Accept" (which was just plain silly), I think the current one
is Ok.

The details are entirely up to people who have actually been involved in
msysgit packaging work, but it may be possible to package an installer
that can be used for installing multiple machines with minimum
interaction, and make the process of extracting that installer show
notices on licensing and legalese.

^ permalink raw reply

* [PATCH] git-gui: Fix switch statement in lib/merge.tcl
From: Johannes Sixt @ 2008-10-08  8:03 UTC (permalink / raw)
  To: Shawn O. Pearce; +Cc: Alexander Gavrilov, Git Mailing List

From: Johannes Sixt <johannes.sixt@telecom.at>

0aea2842 (Make Ctrl-T safe to use for conflicting files) introduced a new
case, but forgot the '-' to indicate that it shares the body with the
subsequent case label.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
 lib/merge.tcl |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/lib/merge.tcl b/lib/merge.tcl
index ac4c7de..283e491 100644
--- a/lib/merge.tcl
+++ b/lib/merge.tcl
@@ -40,7 +40,7 @@ The rescan will be automatically started now.
 		_O {
 			continue; # and pray it works!
 		}
-		_U
+		_U -
 		U? {
 			error_popup [mc "You are in the middle of a conflicted merge.

-- 
1.6.0.2.1596.g729fb

^ permalink raw reply related

* Re: [PATCH/RFC] Add post-init hook
From: Jonathan del Strother @ 2008-10-08  8:16 UTC (permalink / raw)
  To: Jeff King; +Cc: git
In-Reply-To: <20081008015352.GA29313@coredump.intra.peff.net>

On Wed, Oct 8, 2008 at 2:53 AM, Jeff King <peff@peff.net> wrote:
> On Wed, Oct 08, 2008 at 12:10:33AM +0100, Jonathan del Strother wrote:
>
>> I have a number of hooks that I have to install every time I
>> create/clone a repository.  This patch adds a post-init hook that's
>> perfect for setting up that sort of stuff.
>
> Why is the --template parameter to clone and init not sufficient?
>
 Partly that I never remember to include the --template parameter,
partly that I wanted to customize its behaviour (it copies the files,
I want symlinks so I only have to edit my hooks in one place whenever
I change them)

^ permalink raw reply

* Re: Different svn-id URLs in history
From: Michael J Gruber @ 2008-10-08  8:32 UTC (permalink / raw)
  To: Knut Eldhuset; +Cc: git
In-Reply-To: <48EC546F.7060106@3d-radar.com>

Knut Eldhuset venit, vidit, dixit 08.10.2008 08:34:
> Michael J Gruber wrote:
>> Knut Eldhuset venit, vidit, dixit 07.10.2008 12:58:
>>> Hi,
>>>
>>> After cloning my svn repository, I notice that the svn-id URL is 
>>> different when going back in history:
>>>
>>> git-svn-id: https://server/trunk@300
>>>
>>> vs
>>>
>>> git-svn-id: https://server/trunk/some_folder/project/src@250
>>>
>> I take this is as an invitation for guesswork (given the amount of
>> details)...
> 
> Sorry about that... I'm confused.
>> You probably have commits which don't follow your usual svn repo layout
>> (trunk/some_folder/project/src) but commit to trunk/ directly. The output of
>>
>> svn log -v -r300 https://server/trunk@300
>> svn log -v -r250 https://server/trunk/some_folder/project/src@250
>>
>> should give some clues.
>>
> 
> Svn log shows that the same path has been modified in both cases. I see 

Does "same path" mean:
- same relative to the above paths or
- same absolute path?

> something strange in git, though. Our svn repository has about 6500 
> commits, but git shows over 10.000. Further investigation shows that a 
> lot of svn commits have two entries in git. Some branches off of trunk 
> do not start at r1, but off of a duplicate rNNNN. Could this be due to 
> our unhealthy practice of creating branches off of subtrees in svn? By 
> this I mean create a branch off of 
> https://server/trunk/some_folder/project/src instead of 
> https://server/trunk. If so, what can be done to fix this?
> 
> As a sidenote, during git svn clone, I noticed that each time a new 
> branch or tag was discovered, the "scanning" started back at r1. Is this 
> normal? I would think the history before the branch was already 
> imported. Of course, this could maybe be due to the bad branching 
> practice described above.

svn is typically "abused" in the sense that one svn repo is used for
separate projects (your subtrees). git-svn can deal with non-standard
repo layouts.

I assume you can't share the svn repo publically, can you?
So, in order to help you, we would need to know

- the layout of your svn repo: where are trunk, branches and tags, how
did you create branches and tags in svn, are "projects" entirely separate
- your incarnation of git-svn

Michael

^ permalink raw reply

* Re: [PATCH] gitweb: refactor input parameters parse/validation
From: Giuseppe Bilotta @ 2008-10-08  9:10 UTC (permalink / raw)
  To: Jakub Narebski; +Cc: git, Shawn O. Pearce
In-Reply-To: <200810071639.25324.jnareb@gmail.com>

On Tue, Oct 7, 2008 at 4:39 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> Giuseppe Bilotta wrote:
>> On Tue, Oct 7, 2008 at 12:57 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>>> On Fri, 3 Oct 2008, Giuseppe Bilotta wrote:
>
>>>> +     # find which part of PATH_INFO is project
>>>> +     my $project = $path_info;
>>>
>>> Hmmm... now $project is local (lexically) here.
>>
>> Yes, itt's only used temporarily here, to see if  a proper $project
>> can be defined. It gets redefined outside. It just made sense to name
>> it like this 8-)
>
> Well, if $project is local in evaluate_path_info(), so could be
> $path_info...

But $path_info in evaluate_path_info() has the same purpose and the
same (initial) data as $path_info outside of evaluate_path_info(), the
same is not true for $project.

>>>> +     $project =~ s,/+$,,;
>>>> +     while ($project && !check_head_link("$projectroot/$project")) {
>>>> +             $project =~ s,/*[^/]*$,,;
>>>> +     }
>>>> +     # validate project
>>>> +     $project = validate_project($project);
>>>
>>> I'm not sure if it is worth worrying over, but I think you repeat
>>> check_head_link() check here.
>>>
>>> [After examining code further].  But I think you do double validation;
>>> once you do it here, and once you do it copying to global variables
>>> such as $action or $project, and double checking check_head_link()
>>> won't be easy to avoid; fortunately it is cheap filesystem-level check
>>> (might be slow only when stat is extremely slow, and is not cached).
>>
>> I know. This is actually the reason why I had interleaved path_info
>> definition and global validation in my previous version of the patch.
>> The big issue here is that path_info evaluation _needs_ (partial)
>> validation.
>>
>> A possible alternative could be to only put validated parameters into
>> %input_params. This would completely separate the validation for cgi
>> and path_info (modulo shared subs).
>>
>> Of course, the check_head_link would still be repeated inside
>> evaluate_path_info, but the other params could skip a double
>> validation.
>
> Wouldn't it be simpler and as good solution to just leave validation
> off evaluate_path_info() (well, of course except check_head_link() test),
> and allow it to be validated when assigning global 'params' variables?
> check_head_link() would be repeated for path_info links, but that
> should not affect performance much.

Well, it does have a performance hit in the case of invalid $project
since it spends time working on the rest of the URL before bailing
out, but it's probably the cleanest solution. I'll do it this way.

-- 
Giuseppe "Oblomov" Bilotta

^ permalink raw reply

* Re: Different svn-id URLs in history
From: Knut Eldhuset @ 2008-10-08  9:20 UTC (permalink / raw)
  To: git
In-Reply-To: <48EC7022.7030707@drmicha.warpmail.net>

Michael J Gruber wrote:
> Knut Eldhuset venit, vidit, dixit 08.10.2008 08:34:
>> Michael J Gruber wrote:
>>> Knut Eldhuset venit, vidit, dixit 07.10.2008 12:58:
>>>> Hi,
>>>>
>>>> After cloning my svn repository, I notice that the svn-id URL is 
>>>> different when going back in history:
>>>>
>>>> git-svn-id: https://server/trunk@300
>>>>
>>>> vs
>>>>
>>>> git-svn-id: https://server/trunk/some_folder/project/src@250
>>>>
>>> I take this is as an invitation for guesswork (given the amount of
>>> details)...
>> Sorry about that... I'm confused.
>>> You probably have commits which don't follow your usual svn repo layout
>>> (trunk/some_folder/project/src) but commit to trunk/ directly. The output of
>>>
>>> svn log -v -r300 https://server/trunk@300
>>> svn log -v -r250 https://server/trunk/some_folder/project/src@250
>>>
>>> should give some clues.
>>>
>> Svn log shows that the same path has been modified in both cases. I see 
> 
> Does "same path" mean:
> - same relative to the above paths or
> - same absolute path?

Both say "/trunk/some_folder/project/src/some_file".

> 
>> something strange in git, though. Our svn repository has about 6500 
>> commits, but git shows over 10.000. Further investigation shows that a 
>> lot of svn commits have two entries in git. Some branches off of trunk 
>> do not start at r1, but off of a duplicate rNNNN. Could this be due to 
>> our unhealthy practice of creating branches off of subtrees in svn? By 
>> this I mean create a branch off of 
>> https://server/trunk/some_folder/project/src instead of 
>> https://server/trunk. If so, what can be done to fix this?
>>
>> As a sidenote, during git svn clone, I noticed that each time a new 
>> branch or tag was discovered, the "scanning" started back at r1. Is this 
>> normal? I would think the history before the branch was already 
>> imported. Of course, this could maybe be due to the bad branching 
>> practice described above.
> 
> svn is typically "abused" in the sense that one svn repo is used for
> separate projects (your subtrees). git-svn can deal with non-standard
> repo layouts.
> 
> I assume you can't share the svn repo publically, can you?

Sorry, no.

> So, in order to help you, we would need to know
> 
> - the layout of your svn repo: where are trunk, branches and tags, how
> did you create branches and tags in svn, are "projects" entirely separate

https://server/trunk
https://server/branches
https://server/tags

We really only have one "project" source tree at 
https://server/trunk/some_folder/project/src

However, once the sources were at
https://server/trunk/some_folder/project/old_source

Therefore we have the following:

$ svn log -v -r4871 https://server/
------------------------------------------------------------------------
r4871 | nn | 2007-09-25 13:36:25 +0200 (Tue, 25 Sep 2007) | 3 lines
Changed paths:
    M /trunk/project
    D /trunk/project/old_source/some_file
    A /trunk/project/src/client/some_file (from 
/trunk/project/old_source/some_file:4795)

  commit-message
------------------------------------------------------------------------

$ svn log -v -r4869 https://server/
------------------------------------------------------------------------
r4869 | nn | 2007-09-25 13:14:34 +0200 (Tue, 25 Sep 2007) | 3 lines
Changed paths:
    M /trunk/project
    A /trunk/project/src
    A /trunk/project/src/client

  commit-message

------------------------------------------------------------------------

$ svn log -v -r4868 https://server/
------------------------------------------------------------------------
r4868 | nn | 2007-09-25 13:14:28 +0200 (Tue, 25 Sep 2007) | 3 lines
Changed paths:
    M /trunk/project

  commit-message

------------------------------------------------------------------------

$ svn log -v -r4867 https://server/
------------------------------------------------------------------------
r4867 | nn | 2007-09-25 12:04:58 +0200 (Tue, 25 Sep 2007) | 3 lines
Changed paths:
    M /trunk/project
    A /trunk/project/some_file

  commit-message
------------------------------------------------------------------------

r4868 appears twice in git. One commit is on master/trunk and has parent 
and child, while the other is on a branch and has no parent.

> - your incarnation of git-svn
> 

# git --version
git version 1.6.0.2


Regards,
Knut

^ permalink raw reply

* Re: Different svn-id URLs in history
From: Knut Eldhuset @ 2008-10-08  9:23 UTC (permalink / raw)
  To: git
In-Reply-To: <48EC7B52.4000100@3d-radar.com>

Knut Eldhuset wrote:
> Michael J Gruber wrote:
>> Knut Eldhuset venit, vidit, dixit 08.10.2008 08:34:
>>> Michael J Gruber wrote:
>>>> Knut Eldhuset venit, vidit, dixit 07.10.2008 12:58:
>>>>> Hi,
>>>>>
>>>>> After cloning my svn repository, I notice that the svn-id URL is 
>>>>> different when going back in history:
>>>>>
>>>>> git-svn-id: https://server/trunk@300
>>>>>
>>>>> vs
>>>>>
>>>>> git-svn-id: https://server/trunk/some_folder/project/src@250
>>>>>
>>>> I take this is as an invitation for guesswork (given the amount of
>>>> details)...
>>> Sorry about that... I'm confused.
>>>> You probably have commits which don't follow your usual svn repo layout
>>>> (trunk/some_folder/project/src) but commit to trunk/ directly. The 
>>>> output of
>>>>
>>>> svn log -v -r300 https://server/trunk@300
>>>> svn log -v -r250 https://server/trunk/some_folder/project/src@250
>>>>
>>>> should give some clues.
>>>>
>>> Svn log shows that the same path has been modified in both cases. I see 
>>
>> Does "same path" mean:
>> - same relative to the above paths or
>> - same absolute path?
> 
> Both say "/trunk/some_folder/project/src/some_file".
> 
>>
>>> something strange in git, though. Our svn repository has about 6500 
>>> commits, but git shows over 10.000. Further investigation shows that 
>>> a lot of svn commits have two entries in git. Some branches off of 
>>> trunk do not start at r1, but off of a duplicate rNNNN. Could this be 
>>> due to our unhealthy practice of creating branches off of subtrees in 
>>> svn? By this I mean create a branch off of 
>>> https://server/trunk/some_folder/project/src instead of 
>>> https://server/trunk. If so, what can be done to fix this?
>>>
>>> As a sidenote, during git svn clone, I noticed that each time a new 
>>> branch or tag was discovered, the "scanning" started back at r1. Is 
>>> this normal? I would think the history before the branch was already 
>>> imported. Of course, this could maybe be due to the bad branching 
>>> practice described above.
>>
>> svn is typically "abused" in the sense that one svn repo is used for
>> separate projects (your subtrees). git-svn can deal with non-standard
>> repo layouts.
>>
>> I assume you can't share the svn repo publically, can you?
> 
> Sorry, no.
> 
>> So, in order to help you, we would need to know
>>
>> - the layout of your svn repo: where are trunk, branches and tags, how
>> did you create branches and tags in svn, are "projects" entirely separate
> 
> https://server/trunk
> https://server/branches
> https://server/tags
> 
> We really only have one "project" source tree at 
> https://server/trunk/some_folder/project/src
> 
> However, once the sources were at
> https://server/trunk/some_folder/project/old_source
> 
> Therefore we have the following:
> 
> $ svn log -v -r4871 https://server/
> ------------------------------------------------------------------------
> r4871 | nn | 2007-09-25 13:36:25 +0200 (Tue, 25 Sep 2007) | 3 lines
> Changed paths:
>    M /trunk/project
>    D /trunk/project/old_source/some_file
>    A /trunk/project/src/client/some_file (from 
> /trunk/project/old_source/some_file:4795)
> 
>  commit-message
> ------------------------------------------------------------------------
> 
> $ svn log -v -r4869 https://server/
> ------------------------------------------------------------------------
> r4869 | nn | 2007-09-25 13:14:34 +0200 (Tue, 25 Sep 2007) | 3 lines
> Changed paths:
>    M /trunk/project
>    A /trunk/project/src
>    A /trunk/project/src/client
> 
>  commit-message
> 
> ------------------------------------------------------------------------
> 
> $ svn log -v -r4868 https://server/
> ------------------------------------------------------------------------
> r4868 | nn | 2007-09-25 13:14:28 +0200 (Tue, 25 Sep 2007) | 3 lines
> Changed paths:
>    M /trunk/project
> 
>  commit-message
> 
> ------------------------------------------------------------------------
> 
> $ svn log -v -r4867 https://server/
> ------------------------------------------------------------------------
> r4867 | nn | 2007-09-25 12:04:58 +0200 (Tue, 25 Sep 2007) | 3 lines
> Changed paths:
>    M /trunk/project
>    A /trunk/project/some_file
> 
>  commit-message
> ------------------------------------------------------------------------
> 
> r4868 appears twice in git. One commit is on master/trunk and has parent 
> and child, while the other is on a branch and has no parent.
> 

Sorry, that should be r4869.

>> - your incarnation of git-svn
>>
> 
> # git --version
> git version 1.6.0.2
> 
> 

Regards,
Knut

^ permalink raw reply

* Re: [StGit PATCH 6/6] Refresh and expand the tutorial (not finished)
From: Karl Hasselström @ 2008-10-08  9:24 UTC (permalink / raw)
  To: Catalin Marinas; +Cc: git
In-Reply-To: <20081007071223.GC31332@diana.vm.bytemark.co.uk>

On 2008-10-07 09:12:23 +0200, Karl Hasselström wrote:

> On 2008-10-06 22:25:45 +0100, Catalin Marinas wrote:
>
> > Do you plan to do more work on the tutorial (so that we don't
> > duplicate)?
>
> I was planning to finish it if nobody else stepped up. But it'd be
> great if I didn't have to do it alone. :-)
>
> I guess we can avoid duplicate work if we send out a mail saying
> "I'll now be working on part XXX" before we start writing.

This means that the tutorial patch needs to be pretty much immutable,
so you can merge it right away. I'll address your comments in
follow-up patches.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

^ permalink raw reply

* [PATCHv2] gitweb: refactor input parameters parse/validation
From: Giuseppe Bilotta @ 2008-10-08  9:26 UTC (permalink / raw)
  To: git; +Cc: Jakub Narebski, Shawn O. Pearce, Giuseppe Bilotta
In-Reply-To: <200810071257.38423.jnareb@gmail.com>

Since input parameters can be obtained both from CGI parameters and
PATH_INFO, we would like most of the code to be agnostic about the way
parameters were retrieved. We thus collect all the parameters into the
new %input_params hash, delaying validation after the collection is
completed.

Although the kludge removal is minimal at the moment, it makes life much
easier for future expansions such as more extensive PATH_INFO use or
other form of input such as command-line support.

Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---

Some cleanups and clarifications suggested by Jakub were merged in this
revised version of the patch, although I'm keeping $path_info global

 gitweb/gitweb.perl |  315 +++++++++++++++++++++++++++++-----------------------
 1 files changed, 178 insertions(+), 137 deletions(-)

diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 83f810a..c54d82b 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -29,7 +29,9 @@ our $my_uri = $cgi->url(-absolute => 1);
 
 # if we're called with PATH_INFO, we have to strip that
 # from the URL to find our real URL
-if (my $path_info = $ENV{"PATH_INFO"}) {
+# we make $path_info global because it's also used later on
+my $path_info = $ENV{"PATH_INFO"};
+if ($path_info) {
 	$my_url =~ s,\Q$path_info\E$,,;
 	$my_uri =~ s,\Q$path_info\E$,,;
 }
@@ -390,34 +392,155 @@ $projects_list ||= $projectroot;
 
 # ======================================================================
 # input validation and dispatch
-our $action = $cgi->param('a');
+
+# input parameters can be collected from a variety of sources (presently, CGI
+# and PATH_INFO), so we define an %input_params hash that collects them all
+# together during validation: this allows subsequent uses (e.g. href()) to be
+# agnostic of the parameter origin
+
+my %input_params = ();
+
+# input parameters are stored with the long parameter name as key. This will
+# also be used in the href subroutine to convert parameters to their CGI
+# equivalent, and since the href() usage is the most frequent one, we store
+# the name -> CGI key mapping here, instead of the reverse.
+#
+# XXX: Warning: If you touch this, check the search form for updating,
+# too.
+
+my @cgi_param_mapping = (
+	project => "p",
+	action => "a",
+	file_name => "f",
+	file_parent => "fp",
+	hash => "h",
+	hash_parent => "hp",
+	hash_base => "hb",
+	hash_parent_base => "hpb",
+	page => "pg",
+	order => "o",
+	searchtext => "s",
+	searchtype => "st",
+	snapshot_format => "sf",
+	extra_options => "opt",
+	search_use_regexp => "sr",
+);
+my %cgi_param_mapping = @cgi_param_mapping;
+
+# we will also need to know the possible actions, for validation
+my %actions = (
+	"blame" => \&git_blame,
+	"blobdiff" => \&git_blobdiff,
+	"blobdiff_plain" => \&git_blobdiff_plain,
+	"blob" => \&git_blob,
+	"blob_plain" => \&git_blob_plain,
+	"commitdiff" => \&git_commitdiff,
+	"commitdiff_plain" => \&git_commitdiff_plain,
+	"commit" => \&git_commit,
+	"forks" => \&git_forks,
+	"heads" => \&git_heads,
+	"history" => \&git_history,
+	"log" => \&git_log,
+	"rss" => \&git_rss,
+	"atom" => \&git_atom,
+	"search" => \&git_search,
+	"search_help" => \&git_search_help,
+	"shortlog" => \&git_shortlog,
+	"summary" => \&git_summary,
+	"tag" => \&git_tag,
+	"tags" => \&git_tags,
+	"tree" => \&git_tree,
+	"snapshot" => \&git_snapshot,
+	"object" => \&git_object,
+	# those below don't need $project
+	"opml" => \&git_opml,
+	"project_list" => \&git_project_list,
+	"project_index" => \&git_project_index,
+);
+
+# finally, we have the hash of allowed extra_options for the commands that
+# allow them
+my %allowed_options = (
+	"--no-merges" => [ qw(rss atom log shortlog history) ],
+);
+
+# fill %input_params with the CGI parameters. All values except for 'opt'
+# should be single values, but opt can be an array. We should probably
+# build an array of parameters that can be multi-valued, but since for the time
+# being it's only this one, we just single it out
+while (my ($name, $symbol) = each %cgi_param_mapping) {
+	if ($symbol eq 'opt') {
+		$input_params{$name} = [ $cgi->param($symbol) ];
+	} else {
+		$input_params{$name} = $cgi->param($symbol);
+	}
+}
+
+# now read PATH_INFO and update the parameter list for missing parameters
+sub evaluate_path_info {
+	return if defined $input_params{'project'};
+	return if !$path_info;
+	$path_info =~ s,^/+,,;
+	return if !$path_info;
+
+	# find which part of PATH_INFO is project
+	my $project = $path_info;
+	$project =~ s,/+$,,;
+	while ($project && !check_head_link("$projectroot/$project")) {
+		$project =~ s,/*[^/]*$,,;
+	}
+	return unless $project;
+	$input_params{'project'} = $project;
+
+	# do not change any parameters if an action is given using the query string
+	return if $input_params{'action'};
+	$path_info =~ s,^\Q$project\E/*,,;
+
+	my ($refname, $pathname) = split(/:/, $path_info, 2);
+	if (defined $pathname) {
+		# we got "project.git/branch:filename" or "project.git/branch:dir/"
+		# we could use git_get_type(branch:pathname), but it needs $git_dir
+		$pathname =~ s,^/+,,;
+		if (!$pathname || substr($pathname, -1) eq "/") {
+			$input_params{'action'} = "tree";
+			$pathname =~ s,/$,,;
+		} else {
+			$input_params{'action'} = "blob_plain";
+		}
+		$input_params{'hash_base'} ||= $refname;
+		$input_params{'file_name'} ||= $pathname;
+	} elsif (defined $refname) {
+		# we got "project.git/branch"
+		$input_params{'action'} = "shortlog";
+		$input_params{'hash'} ||= $refname;
+	}
+}
+evaluate_path_info();
+
+our $action = $input_params{'action'};
 if (defined $action) {
-	if ($action =~ m/[^0-9a-zA-Z\.\-_]/) {
+	if (!validate_action($action)) {
 		die_error(400, "Invalid action parameter");
 	}
 }
 
 # parameters which are pathnames
-our $project = $cgi->param('p');
+our $project = $input_params{'project'};
 if (defined $project) {
-	if (!validate_pathname($project) ||
-	    !(-d "$projectroot/$project") ||
-	    !check_head_link("$projectroot/$project") ||
-	    ($export_ok && !(-e "$projectroot/$project/$export_ok")) ||
-	    ($strict_export && !project_in_list($project))) {
+	if (!validate_project($project)) {
 		undef $project;
 		die_error(404, "No such project");
 	}
 }
 
-our $file_name = $cgi->param('f');
+our $file_name = $input_params{'file_name'};
 if (defined $file_name) {
 	if (!validate_pathname($file_name)) {
 		die_error(400, "Invalid file parameter");
 	}
 }
 
-our $file_parent = $cgi->param('fp');
+our $file_parent = $input_params{'file_parent'};
 if (defined $file_parent) {
 	if (!validate_pathname($file_parent)) {
 		die_error(400, "Invalid file parent parameter");
@@ -425,44 +548,41 @@ if (defined $file_parent) {
 }
 
 # parameters which are refnames
-our $hash = $cgi->param('h');
+our $hash = $input_params{'hash'};
 if (defined $hash) {
 	if (!validate_refname($hash)) {
 		die_error(400, "Invalid hash parameter");
 	}
 }
 
-our $hash_parent = $cgi->param('hp');
+our $hash_parent = $input_params{'hash_parent'};
 if (defined $hash_parent) {
 	if (!validate_refname($hash_parent)) {
 		die_error(400, "Invalid hash parent parameter");
 	}
 }
 
-our $hash_base = $cgi->param('hb');
+our $hash_base = $input_params{'hash_base'};
 if (defined $hash_base) {
 	if (!validate_refname($hash_base)) {
 		die_error(400, "Invalid hash base parameter");
 	}
 }
 
-my %allowed_options = (
-	"--no-merges" => [ qw(rss atom log shortlog history) ],
-);
-
-our @extra_options = $cgi->param('opt');
-if (defined @extra_options) {
-	foreach my $opt (@extra_options) {
-		if (not exists $allowed_options{$opt}) {
-			die_error(400, "Invalid option parameter");
-		}
-		if (not grep(/^$action$/, @{$allowed_options{$opt}})) {
-			die_error(400, "Invalid option parameter for this action");
-		}
+our @extra_options = @{$input_params{'extra_options'}};
+# @extra_options is always defined, since it can only be (currently) set from
+# CGI, and $cgi->param() returns the empty array in array context if the param
+# is not set
+foreach my $opt (@extra_options) {
+	if (not exists $allowed_options{$opt}) {
+		die_error(400, "Invalid option parameter");
+	}
+	if (not grep(/^$action$/, @{$allowed_options{$opt}})) {
+		die_error(400, "Invalid option parameter for this action");
 	}
 }
 
-our $hash_parent_base = $cgi->param('hpb');
+our $hash_parent_base = $input_params{'hash_parent_base'};
 if (defined $hash_parent_base) {
 	if (!validate_refname($hash_parent_base)) {
 		die_error(400, "Invalid hash parent base parameter");
@@ -470,23 +590,23 @@ if (defined $hash_parent_base) {
 }
 
 # other parameters
-our $page = $cgi->param('pg');
+our $page = $input_params{'page'};
 if (defined $page) {
 	if ($page =~ m/[^0-9]/) {
 		die_error(400, "Invalid page parameter");
 	}
 }
 
-our $searchtype = $cgi->param('st');
+our $searchtype = $input_params{'searchtype'};
 if (defined $searchtype) {
 	if ($searchtype =~ m/[^a-z]/) {
 		die_error(400, "Invalid searchtype parameter");
 	}
 }
 
-our $search_use_regexp = $cgi->param('sr');
+our $search_use_regexp = $input_params{'search_use_regexp'};
 
-our $searchtext = $cgi->param('s');
+our $searchtext = $input_params{'searchtext'};
 our $search_regexp;
 if (defined $searchtext) {
 	if (length($searchtext) < 2) {
@@ -495,86 +615,11 @@ if (defined $searchtext) {
 	$search_regexp = $search_use_regexp ? $searchtext : quotemeta $searchtext;
 }
 
-# now read PATH_INFO and use it as alternative to parameters
-sub evaluate_path_info {
-	return if defined $project;
-	my $path_info = $ENV{"PATH_INFO"};
-	return if !$path_info;
-	$path_info =~ s,^/+,,;
-	return if !$path_info;
-	# find which part of PATH_INFO is project
-	$project = $path_info;
-	$project =~ s,/+$,,;
-	while ($project && !check_head_link("$projectroot/$project")) {
-		$project =~ s,/*[^/]*$,,;
-	}
-	# validate project
-	$project = validate_pathname($project);
-	if (!$project ||
-	    ($export_ok && !-e "$projectroot/$project/$export_ok") ||
-	    ($strict_export && !project_in_list($project))) {
-		undef $project;
-		return;
-	}
-	# do not change any parameters if an action is given using the query string
-	return if $action;
-	$path_info =~ s,^\Q$project\E/*,,;
-	my ($refname, $pathname) = split(/:/, $path_info, 2);
-	if (defined $pathname) {
-		# we got "project.git/branch:filename" or "project.git/branch:dir/"
-		# we could use git_get_type(branch:pathname), but it needs $git_dir
-		$pathname =~ s,^/+,,;
-		if (!$pathname || substr($pathname, -1) eq "/") {
-			$action  ||= "tree";
-			$pathname =~ s,/$,,;
-		} else {
-			$action  ||= "blob_plain";
-		}
-		$hash_base ||= validate_refname($refname);
-		$file_name ||= validate_pathname($pathname);
-	} elsif (defined $refname) {
-		# we got "project.git/branch"
-		$action ||= "shortlog";
-		$hash   ||= validate_refname($refname);
-	}
-}
-evaluate_path_info();
-
 # path to the current git repository
 our $git_dir;
 $git_dir = "$projectroot/$project" if $project;
 
 # dispatch
-my %actions = (
-	"blame" => \&git_blame,
-	"blobdiff" => \&git_blobdiff,
-	"blobdiff_plain" => \&git_blobdiff_plain,
-	"blob" => \&git_blob,
-	"blob_plain" => \&git_blob_plain,
-	"commitdiff" => \&git_commitdiff,
-	"commitdiff_plain" => \&git_commitdiff_plain,
-	"commit" => \&git_commit,
-	"forks" => \&git_forks,
-	"heads" => \&git_heads,
-	"history" => \&git_history,
-	"log" => \&git_log,
-	"rss" => \&git_rss,
-	"atom" => \&git_atom,
-	"search" => \&git_search,
-	"search_help" => \&git_search_help,
-	"shortlog" => \&git_shortlog,
-	"summary" => \&git_summary,
-	"tag" => \&git_tag,
-	"tags" => \&git_tags,
-	"tree" => \&git_tree,
-	"snapshot" => \&git_snapshot,
-	"object" => \&git_object,
-	# those below don't need $project
-	"opml" => \&git_opml,
-	"project_list" => \&git_project_list,
-	"project_index" => \&git_project_index,
-);
-
 if (!defined $action) {
 	if (defined $hash) {
 		$action = git_get_type($hash);
@@ -604,35 +649,12 @@ sub href (%) {
 	# default is to use -absolute url() i.e. $my_uri
 	my $href = $params{-full} ? $my_url : $my_uri;
 
-	# XXX: Warning: If you touch this, check the search form for updating,
-	# too.
-
-	my @mapping = (
-		project => "p",
-		action => "a",
-		file_name => "f",
-		file_parent => "fp",
-		hash => "h",
-		hash_parent => "hp",
-		hash_base => "hb",
-		hash_parent_base => "hpb",
-		page => "pg",
-		order => "o",
-		searchtext => "s",
-		searchtype => "st",
-		snapshot_format => "sf",
-		extra_options => "opt",
-		search_use_regexp => "sr",
-	);
-	my %mapping = @mapping;
-
 	$params{'project'} = $project unless exists $params{'project'};
 
 	if ($params{-replay}) {
-		while (my ($name, $symbol) = each %mapping) {
+		while (my ($name, $symbol) = each %cgi_param_mapping) {
 			if (!exists $params{$name}) {
-				# to allow for multivalued params we use arrayref form
-				$params{$name} = [ $cgi->param($symbol) ];
+				$params{$name} = $input_params{$name};
 			}
 		}
 	}
@@ -651,8 +673,8 @@ sub href (%) {
 
 	# now encode the parameters explicitly
 	my @result = ();
-	for (my $i = 0; $i < @mapping; $i += 2) {
-		my ($name, $symbol) = ($mapping[$i], $mapping[$i+1]);
+	for (my $i = 0; $i < @cgi_param_mapping; $i += 2) {
+		my ($name, $symbol) = ($cgi_param_mapping[$i], $cgi_param_mapping[$i+1]);
 		if (defined $params{$name}) {
 			if (ref($params{$name}) eq "ARRAY") {
 				foreach my $par (@{$params{$name}}) {
@@ -672,6 +694,25 @@ sub href (%) {
 ## ======================================================================
 ## validation, quoting/unquoting and escaping
 
+sub validate_action {
+	my $input = shift || return undef;
+	return undef unless exists $actions{$action};
+	return $action;
+}
+
+sub validate_project {
+	my $input = shift || return undef;
+	if (!validate_pathname($input) ||
+		!(-d "$projectroot/$input") ||
+		!check_head_link("$projectroot/$input") ||
+		($export_ok && !(-e "$projectroot/$input/$export_ok")) ||
+		($strict_export && !project_in_list($input))) {
+		return undef;
+	} else {
+		return $input;
+	}
+}
+
 sub validate_pathname {
 	my $input = shift || return undef;
 
@@ -3988,7 +4029,7 @@ sub git_search_grep_body {
 ## actions
 
 sub git_project_list {
-	my $order = $cgi->param('o');
+	my $order = $input_params{'order'};
 	if (defined $order && $order !~ m/none|project|descr|owner|age/) {
 		die_error(400, "Unknown order parameter");
 	}
@@ -4011,7 +4052,7 @@ sub git_project_list {
 }
 
 sub git_forks {
-	my $order = $cgi->param('o');
+	my $order = $input_params{'order'};
 	if (defined $order && $order !~ m/none|project|descr|owner|age/) {
 		die_error(400, "Unknown order parameter");
 	}
@@ -4545,7 +4586,7 @@ sub git_snapshot {
 	my @supported_fmts = gitweb_check_feature('snapshot');
 	@supported_fmts = filter_snapshot_fmts(@supported_fmts);
 
-	my $format = $cgi->param('sf');
+	my $format = $input_params{'snapshot_format'};
 	if (!@supported_fmts) {
 		die_error(403, "Snapshots not allowed");
 	}
-- 
1.5.6.5

^ permalink raw reply related

* Re: [PATCH] gitweb: refactor input parameters parse/validation
From: Jakub Narebski @ 2008-10-08  9:45 UTC (permalink / raw)
  To: Giuseppe Bilotta; +Cc: git, Shawn O. Pearce
In-Reply-To: <cb7bb73a0810080210s49d1683dj4e2fef8072522abd@mail.gmail.com>

Giuseppe Bilotta wrote:
> On Tue, Oct 7, 2008 at 4:39 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> > Giuseppe Bilotta wrote:

> > Wouldn't it be simpler and as good solution to just leave validation
> > off evaluate_path_info() (well, of course except check_head_link() test),
> > and allow it to be validated when assigning global 'params' variables?
> > check_head_link() would be repeated for path_info links, but that
> > should not affect performance much.
> 
> Well, it does have a performance hit in the case of invalid $project
> since it spends time working on the rest of the URL before bailing
> out, but it's probably the cleanest solution. I'll do it this way.

I have forgot about this fact, that parameter validation serves also
as early escape. But I don't think it is much performance hit in
practice; it is performance (optimization) vs. maintability tradeoff.

-- 
Jakub Narebski
Poland

^ permalink raw reply

* Feature Request: Branch Annotations
From: Rotem Yaari @ 2008-10-08 10:49 UTC (permalink / raw)
  To: git
In-Reply-To: <d2115f4f0810080348t62e18b14x1dfe798974332b05@mail.gmail.com>

Hi,

I usually work with many branches in git, each of which represents a
different state of development/stability, but also development tasks
assigned to me.
Sometimes, besides the name of the branch, it could be useful to have
a short description of a branch which quickly reminds me what that
branch is intended for.

Currently I see no way in git to achieve this (there's a description
for a repository, but not for individual branches).

Any opinions on this?


Thanks in advance,

--
Rotem

^ permalink raw reply

* Re: Feature Request: Branch Annotations
From: Thomas Adam @ 2008-10-08 10:55 UTC (permalink / raw)
  To: Rotem Yaari; +Cc: git
In-Reply-To: <d2115f4f0810080349o30b6bc2labc2745b8d981e0d@mail.gmail.com>

2008/10/8 Rotem Yaari <vmalloc@gmail.com>:
> Hi,
>
> I usually work with many branches in git, each of which represents a
> different state of development/stability, but also development tasks
> assigned to me.
> Sometimes, besides the name of the branch, it could be useful to have
> a short description of a branch which quickly reminds me what that
> branch is intended for.
>
> Currently I see no way in git to achieve this (there's a description
> for a repository, but not for individual branches).
>
> Any opinions on this?

Wasn't this discussed here before, with a prototype?  ISTR it was, but
dropped due to lack of interest?  Have a look through the archives.

-- Thomas Adam

^ permalink raw reply

* Re: Feature Request: Branch Annotations
From: Baz @ 2008-10-08 11:41 UTC (permalink / raw)
  To: Thomas Adam; +Cc: Rotem Yaari, git
In-Reply-To: <18071eea0810080355g743c7bbfq9d7d39c9a76eb59d@mail.gmail.com>

2008/10/8 Thomas Adam <thomas.adam22@gmail.com>:
> 2008/10/8 Rotem Yaari <vmalloc@gmail.com>:
>> Hi,
>>
>> I usually work with many branches in git, each of which represents a
>> different state of development/stability, but also development tasks
>> assigned to me.
>> Sometimes, besides the name of the branch, it could be useful to have
>> a short description of a branch which quickly reminds me what that
>> branch is intended for.
>>
>> Currently I see no way in git to achieve this (there's a description
>> for a repository, but not for individual branches).
>>
>> Any opinions on this?
>
> Wasn't this discussed here before, with a prototype?  ISTR it was, but
> dropped due to lack of interest?  Have a look through the archives.

The most recent thread was 'branch description' back in April, which
discussed alternatives, but petered out:
http://kerneltrap.org/mailarchive/git/2008/4/15/1442684/thread

An older thread on 'topic descriptions' where Junio described his use
of the config file for this:
http://kerneltrap.org/mailarchive/git/2006/12/6/232466/thread

And there's a similar feature in stgit, which uses the same config
setting that Junio did:
http://kerneltrap.org/mailarchive/git/2007/5/14/246358
http://kerneltrap.org/mailarchive/git/2007/4/12/243404

-Baz

>
> -- Thomas Adam
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

^ permalink raw reply

* Re: Feature Request: Branch Annotations
From: Marc Weber @ 2008-10-08 12:08 UTC (permalink / raw)
  To: git
In-Reply-To: <2faad3050810080441sdb1b29bxe92c467c2dd9a908@mail.gmail.com>

On Wed, Oct 08, 2008 at 12:41:43PM +0100, Baz wrote:
> 2008/10/8 Thomas Adam <thomas.adam22@gmail.com>:
> > 2008/10/8 Rotem Yaari <vmalloc@gmail.com>:
> >> Hi,
> >>
> >> I usually work with many branches in git, each of which represents a
> >> different state of development/stability, but also development tasks
> >> assigned to me.
> >> Sometimes, besides the name of the branch, it could be useful to have
> >> a short description of a branch which quickly reminds me what that
> >> branch is intended for.
> >>
> >> Currently I see no way in git to achieve this (there's a description
> >> for a repository, but not for individual branches).
> >>
> >> Any opinions on this?
[...]
Probably I've missed something. but doesn't top git add some special
files to remember branch relations?
I guess it removes them before merging upstream ?
I would have to reread the README or topGit source to confirm this.

Marc Weber

^ permalink raw reply

* [ANNOUNCE] tig-0.12.1
From: Jonas Fonseca @ 2008-10-08 13:14 UTC (permalink / raw)
  To: git

Hello,

It's time for another release of tig, this one tagged as a minor update
focusing mainly on bug fixes. There are, however, also a few nice
usability improvements, such as support for reverting uncommitted and
unstaged changes and reloading of repository references when refreshing
the views using them.  Note that this version of tig depends on git
version 1.5.4 or newer!

In the pipeline, I have a scary patch containing 859 insertions and 462
deletions, which I plan to release as the equally scary version 0.13.
The patch imports git's run-command.c module, which should remove
problems related to using stdio and will also remove the need to do
nasty things such as shell quoting. This is still a work in progress and
needs some more polishing and testing, but should anybody be interested,
it is available in the wip/run-command branch (to be rebased at will).

What is tig?
------------
Tig is an ncurses-based text-mode interface for git. It functions mainly
as a git repository browser, but can also assist in staging changes for
commit at chunk level and act as a pager for output from various git
commands.

 - Homepage:	http://jonas.nitro.dk/tig/
 - Manual:	http://jonas.nitro.dk/tig/manual.html
 - Tarballs:	http://jonas.nitro.dk/tig/releases/
 - Git URL:	git://repo.or.cz/tig.git 
 - Gitweb:	http://repo.or.cz/w/tig.git

Release notes
-------------
Improvements:

 - Status view: revert uncommitted diff chunks and unstaged files with
   changes. Bound to '!' by default.
 - Main view: use --topo-order also when rev-list arguments are given on
   the command line.
 - Log view: support for refreshing.

Bug fixes:

 - Status view: use ls-files' --exclude-standard so user specific ignore
   rules are effective. The option was added in git version 1.5.4.
 - Stage view: fix assertion failure triggered when updating while
   status view is not displayed.
 - Help view: avoid confusion by showing "(no key)" instead of "'?'" for
   unbound requests.
 - Reload repository references when refreshing the main (and log) view.
 - Do not maximize views when refreshing.

Change summary
--------------
The diffstat and log summary for changes made in this release.

 NEWS                    |   22 +++
 TODO                    |    9 +-
 VERSION                 |    2 +-
 configure.ac            |    8 +-
 contrib/announcement.sh |   53 ++++++
 manual.txt              |    2 +
 tig.c                   |  381 +++++++++++++++++++++++++++------------
 7 files changed, 351 insertions(+), 126 deletions(-)

Jonas Fonseca (25):
      Add script for preparing release announcements
      TODO: support for jumping to parents' blame in the blame view
      status: add support for checking out files with unstaged changes
      main: automatically refresh after run requests
      Main: use --topo-order when arguments are given on the command line
      Cleanup exclude rule setup by using ls-files --exclude-standard flag
      Also allow files to be checked out from stage view
      Avoid refreshing views when checkout is canceled by user
      Reload repository references when refreshing the main view
      Make GIT_CONFIG only contain the config subcommand
      Improve handling of unmatched quotes in ~/.tigrc
      Cleanup and make option argument strings const
      Improve checkout error reporting
      Show complete shortlog for small releases
      Simplify view refreshing by adding new OPEN_REFRESH flag for open_view
      Make OPEN_REFRESH imply OPEN_NOMAXIMIZE
      Add support for refreshing the log view
      Fix bug introduced in commit for using --exclude-standard flag
      Clear the status line when closing a view
      Help view: use "(no key)" instead of "'?'" to not confuse unbound actions
      Help view: move requests from the Misc group into separate groups
      Consolidate and share view resetting via new reset_view()
      Avoid triggering assertion failure when reloading the status view
      Rename checkout to revert and support individual diff chunks reverts
      tig-0.12.1

-- 
Jonas Fonseca

^ permalink raw reply

* git-am: can't apply to an empty repository
From: Imre Deak @ 2008-10-08 13:24 UTC (permalink / raw)
  To: git

When trying to build a repository from mbox format patches I have the
following problem:

Creating a hypothetical mbox patch:

$ echo "From: imre deak <imre.deak@gmail.com>" > 1.patch
$ touch a
$ git diff --no-index /dev/null a >> 1.patch
$ cat 1.patch
From: imre deak <imre.deak@gmail.com>
diff --git a/a b/a
new file mode 100644
index 0000000..e69de29

Apply it to a newly created repository:

$ git init
Initialized empty Git repository in /home/imde/conv/git/.git/
$ git am 1.patch
fatal: HEAD: not a valid SHA1
fatal: bad revision 'HEAD'

Is this supposed to work at all?

--Imre

^ permalink raw reply

* Re: Feature Request: Branch Annotations
From: David Soria Parra @ 2008-10-08 13:29 UTC (permalink / raw)
  To: Rotem Yaari; +Cc: git
In-Reply-To: <d2115f4f0810080349o30b6bc2labc2745b8d981e0d@mail.gmail.com>


> Any opinions on this?

would be great to have something like that build in git-core like

git branch -i 'Fix bla' ds/fix next
git branch -i
  ds/fix (Fix Bla)

david

^ permalink raw reply

* Re: git-who
From: Rhodes, Kate @ 2008-10-08 13:48 UTC (permalink / raw)
  To: Johannes Sixt; +Cc: git
In-Reply-To: <48EC4F9D.4020202@viscovery.net>


No. No, that's far too simple.


;)

-Kate

On Oct 8, 2008, at 2:13 AM, Johannes Sixt wrote:
> Rhodes, Kate schrieb:
>> Once upon a someone asked about seeing who had touched some files.  
>> Petr
>> Baudis responded with a quickie script that did the job.
>
> Wouldn't
>
>   git shortlog -s -- path/to/file
>
> solve your problem?
>
> -- Hannes
>

^ permalink raw reply

* Re: [RFC] git rev-contains [Was: merge -s ffonly]
From: Deskin Miller @ 2008-10-08 14:30 UTC (permalink / raw)
  To: =?ISO-8859-1?Q?Uwe_Kleine-K=F6nig_
  Cc: Shawn O. Pearce, git, Randal L. Schwartz
In-Reply-To: <20081007185815.GA10744@strlen.de>

On Tue, Oct 07, 2008 at 08:58:15PM +0200, =?ISO-8859-1?Q?Uwe_Kleine-K=F6nig_ wrote:
> > +	if test -n "$(git rev-list $1..HEAD)"
> I already wrote similar tests and I wonder if this couldn't be done in a
> new builtin command more effectively.  Something like
> 
> 	git rev-contains HEAD "$1"
> 
> .  I expect it to be faster and maybe it prevents a command line
> overflow?! [...]
 
I'm not sure this warrants a builtin; seems like test is perfectly capable of
doing what you want:

if test '(' -n "$(git rev-list --max-count=1 $1..HEAD)" ')' -a \
	'(' -z "$(git rev-list --max-count=1 HEAD..$1)" ')'

The second check is needed to ensure that the commits actually have an
ancestor-descendant relationship.  And --max-count means your command line
won't overflow.

Or what about this:

if test "$(git merge-base $1 HEAD)" = "$(git rev-parse $1)"

My $0.02,
Deskin Miller

^ permalink raw reply

* Re: [PATCH 2/2 v2] check-attr: Add --stdin-paths option
From: Shawn O. Pearce @ 2008-10-08 15:24 UTC (permalink / raw)
  To: Dmitry Potapov; +Cc: Johannes Sixt, Alexander Gavrilov, git, Paul Mackerras
In-Reply-To: <20081007001652.GR21650@dpotapov.dyndns.org>

Dmitry Potapov <dpotapov@gmail.com> wrote:
> This allows multiple paths to be specified on stdin.

> 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

I wonder if the option should just be "--stdin".  And since its being
used mostly by automated tools (gitk/git-gui) I wonder if a -z should
also be supported for input termination with NUL instead of LF.

> 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' '

A test case for the quoting might also be good.

> +
> +	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

-- 
Shawn.

^ permalink raw reply

* Re: [RFC] git rev-contains [Was: merge -s ffonly]
From: Uwe Kleine-König @ 2008-10-08 15:41 UTC (permalink / raw)
  To: Deskin Miller; +Cc: Shawn O. Pearce, git, Randal L. Schwartz
In-Reply-To: <20081008143050.GG3052@riemann.deskinm.fdns.net>

Hello Deskin,

On Wed, Oct 08, 2008 at 10:30:50AM -0400, Deskin Miller wrote:
> On Tue, Oct 07, 2008 at 08:58:15PM +0200, =?ISO-8859-1?Q?Uwe_Kleine-K=F6nig_ wrote:
> > > +	if test -n "$(git rev-list $1..HEAD)"
> > I already wrote similar tests and I wonder if this couldn't be done in a
> > new builtin command more effectively.  Something like
> > 
> > 	git rev-contains HEAD "$1"
> > 
> > .  I expect it to be faster and maybe it prevents a command line
> > overflow?! [...]
>  
> I'm not sure this warrants a builtin; seems like test is perfectly capable of
> doing what you want:
> 
> if test '(' -n "$(git rev-list --max-count=1 $1..HEAD)" ')' -a \
> 	'(' -z "$(git rev-list --max-count=1 HEAD..$1)" ')'
> 
> The second check is needed to ensure that the commits actually have an
> ancestor-descendant relationship.
This is needed for the original patch, too, isn't it.

>                                    And --max-count means your command line
> won't overflow.
ah, --max-count is a nice idea.  Topgit could benefit from it.
 
> Or what about this:
> 
> if test "$(git merge-base $1 HEAD)" = "$(git rev-parse $1)"

It's not entirely clear to me, this works in general, because a
merge-base isn't unique.  It should work in this case, though.

Best regards
Uwe

^ permalink raw reply

* Re: Git and tagging hook
From: Kristis Makris @ 2008-10-08 16:47 UTC (permalink / raw)
  To: Jakub Narebski
  Cc: git-u79uwXL29TY76Z2rM5mHXA, scmbug-users-G8y9j4K4DsPiwOUmbS1EgQ
In-Reply-To: <gcg67d$4o2$1@ger.gmane.org>


[-- Attachment #1.1: Type: text/plain, Size: 791 bytes --]

On Tue, 2008-10-07 at 19:28 +0200, Jakub Narebski wrote:
> Kristis Makris wrote:
> 
> > But the post-receive is NOT executed when I apply a tag.
> > 
> > I want the integration when I apply the tag to a local repository, NOT
> > only when I push/pull.
> 
> If you are talking about taging locally, you can simply make an alias
> or do something after tagging. Search archives for description when
> it is worth to add a hook, and when it is not.

I am looking for a guarantee that is better than casually saying
"simply". I will be providing the integration work to users that may not
be as comfortable with making aliases. 

I still don't see why a hook on local tagging is not available. Is it
possible to add support in Git for such a hook ? Both pre-tag and
post-tag.

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 188 bytes --]

_______________________________________________
scmbug-users mailing list
scmbug-users-G8y9j4K4DsPiwOUmbS1EgQ@public.gmane.org
http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox