* Re: git svn teething problems - initial clone okay - fetches not working
From: Aaron Gray @ 2009-03-23 20:02 UTC (permalink / raw)
To: Tim Visher; +Cc: Git Mailing List
In-Reply-To: <c115fd3c0903231243n1cddf1f1ra88b00ca8db83044@mail.gmail.com>
>I had a lot of success when I was more actively using `git svn` with
>`git svn rebase`. Just be sure that you're doing your work in local
>branches and then merging back into the main trunk branches that are
>tracking the svn repo, that way you can always get the latest changes
>from your clean trunk branch.
I tried a rebase and filenames with 'needs update' after them flew by then
an error message :-
update-index --refresh: command returned error: 1
Aaron
On Mon, Mar 23, 2009 at 3:30 PM, Aaron Gray
<aaronngray.lists@googlemail.com> wrote:
> Hi,
>
> I am a newbie to git, so be warned :)
>
> I have installed git-daemon, and gitweb on an F10 server.
>
> Basically managed to do a 'git svn clone' on LLVM, it took 11 hours !
>
> Anyway I am having the problem that I can do a 'git svn fetch' and I see
> changes coming in. But the gitweb and another git clone from it do not
> reflect those changes. The repository is still showing its two days old.
>
> I am obviously missing something. The only documentation I could find on
> 'git svn' was the command line help and 'man git-svn'.
>
> Hope you can help,
>
> Aaron
>
> --
> 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
>
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* [PATCH] Add warning about known issues to documentation of cvsimport
From: Heiko Voigt @ 2009-03-23 19:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
The described issues are compiled from the tests by Michael Haggerty and me.
Because it is not apparent that these can be fixed anytime soon at least warn
unwary users not to rely on the inbuilt cvsimport to much.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
---
Documentation/git-cvsimport.txt | 34 ++++++++++++++++++++++++++++++++++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt
index b7a8c10..3123725 100644
--- a/Documentation/git-cvsimport.txt
+++ b/Documentation/git-cvsimport.txt
@@ -24,6 +24,9 @@ repository, or incrementally import into an existing one.
Splitting the CVS log into patch sets is done by 'cvsps'.
At least version 2.1 is required.
+*WARNING:* for certain situations the import leads to incorrect results.
+Please see the section <<issues,ISSUES>> for further reference.
+
You should *never* do any work of your own on the branches that are
created by 'git-cvsimport'. By default initial import will create and populate a
"master" branch from the CVS repository's main branch which you're free
@@ -164,6 +167,37 @@ If '-v' is specified, the script reports what it is doing.
Otherwise, success is indicated the Unix way, i.e. by simply exiting with
a zero exit status.
+[[issues]]
+ISSUES
+------
+Problems related to timestamps:
+
+ * If timestamps of commits in the cvs repository are not stable enough
+ to be used for ordering commits
+ * If any files were ever "cvs import"ed more than once (e.g., import of
+ more than one vendor release)
+ * If the timestamp order of different files cross the revision order
+ within the commit matching time window
+
+Problems related to branches:
+
+ * Branches on which no commits have been made are not imported
+ * All files from the branching point are added to a branch even if
+ never added in cvs
+ * files added to the source branch *after* a daughter branch was
+ created: If previously no commit was made on the daugther branch they
+ will erroneously be added to the daughter branch in git
+
+Problems related to tags:
+
+* Multiple tags on the same revision are not imported
+
+If you suspect that any of these issues may apply to the repository you
+want to import consider using these alternative tools which proved to be
+more stable in practise:
+
+* cvs2git (part of cvs2svn), `http://cvs2svn.tigris.org`
+* parsecvs, `http://cgit.freedesktop.org/~keithp/parsecvs`
Author
------
--
1.6.1.2.390.gba743
^ permalink raw reply related
* Re: git svn teething problems - initial clone okay - fetches not working
From: Tim Visher @ 2009-03-23 19:43 UTC (permalink / raw)
To: Aaron Gray; +Cc: Git Mailing List
In-Reply-To: <2BACA6CC2F9647C19C0463120219E694@HPLAPTOP>
I had a lot of success when I was more actively using `git svn` with
`git svn rebase`. Just be sure that you're doing your work in local
branches and then merging back into the main trunk branches that are
tracking the svn repo, that way you can always get the latest changes
from your clean trunk branch.
On Mon, Mar 23, 2009 at 3:30 PM, Aaron Gray
<aaronngray.lists@googlemail.com> wrote:
> Hi,
>
> I am a newbie to git, so be warned :)
>
> I have installed git-daemon, and gitweb on an F10 server.
>
> Basically managed to do a 'git svn clone' on LLVM, it took 11 hours !
>
> Anyway I am having the problem that I can do a 'git svn fetch' and I see
> changes coming in. But the gitweb and another git clone from it do not
> reflect those changes. The repository is still showing its two days old.
>
> I am obviously missing something. The only documentation I could find on
> 'git svn' was the command line help and 'man git-svn'.
>
> Hope you can help,
>
> Aaron
>
> --
> 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
>
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* git svn teething problems - initial clone okay - fetches not working
From: Aaron Gray @ 2009-03-23 19:30 UTC (permalink / raw)
To: Git Mailing List
Hi,
I am a newbie to git, so be warned :)
I have installed git-daemon, and gitweb on an F10 server.
Basically managed to do a 'git svn clone' on LLVM, it took 11 hours !
Anyway I am having the problem that I can do a 'git svn fetch' and I see
changes coming in. But the gitweb and another git clone from it do not
reflect those changes. The repository is still showing its two days old.
I am obviously missing something. The only documentation I could find on
'git svn' was the command line help and 'man git-svn'.
Hope you can help,
Aaron
^ permalink raw reply
* Re: started a cvsps testsuite Was: Re: [PATCH v3 0/2] cvsimport: add test illustrating a bug in cvsps
From: Martin Langhoff @ 2009-03-23 19:06 UTC (permalink / raw)
To: Heiko Voigt
Cc: Michael Haggerty, Michael J Gruber, Junio C Hamano, Heiko Voigt,
ydirson, git, CVSps
In-Reply-To: <20090323181110.GB26678@macbook.lan>
On Mon, Mar 23, 2009 at 7:11 PM, Heiko Voigt <hvoigt@hvoigt.net> wrote:
> I just started a very simple but hopefully effective testsuite to
> collect all the issues we found with cvsps.
Excellent effort. One thing I found when I was debugging (and trying
to understand) corner cases in cvs imports was the test suite for the
cvs2svn importer. It had a number of tiny cvs repositories that were
broken in various ways.
The test cvs repos, straight from the svn repo for cvs2svn are in
http://cvs2svn.tigris.org/svn/cvs2svn/trunk/test-data/ - access with
user:guest and an empty password.
...
> Hopefully we can collect some more specifics about the situations where
> cvsps fails and most importantly the amount of coding needed for fixing.
> From there on it should be easier to decide which route to follow for
> a robust inbuild git cvsimport.
Some cvs repos are ambiguous. Others are "impossible", fruits of
direct file manipulation. cvs2svn has a fairly robust (and
inordinately slow!) approach, but you cannot rerun it to get
incremental imports.
It is certainly possible... and bloody hard!
cheers,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* RE: How to go to git from svn without checkout
From: Samman, Bassel @ 2009-03-23 15:21 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20090322032008.GA9526@coredump.intra.peff.net>
Yes, unfortunately they do change occasionally and they grow with time. It's a product catalogue, so new products are added all the time, just not daily. That's part of why I want to move to Git, SVN has been giving me lots of trouble when adding files at deep levels and I like how Git does adding files and how each repository is really it's own repository. Also, I'm not really concerned about history as the main purpose of the repository is really to make the syncing job easier. The code is very minimal and I do the majority of the maintenance on the code, so I can easily jump back to svn if I need history. The main reason we even need to share the project is that the sales guys need to go without internet at times and they need to have the website locally on their machines so they can easily demo the latest products to their clients. Business requirements by sales guys can be crazy at times, but what can we do. Also, this is a far fetch, since all the projects are installed under the same directories and are really exact clones of each other in every way, can I copy the .git directory and hope to God that it will magically work. I really doubt it, but I figure it's worth asking.
-----Original Message-----
From: Jeff King [mailto:peff@peff.net]
Sent: Saturday, March 21, 2009 10:20 PM
To: Samman, Bassel
Cc: git@vger.kernel.org
Subject: Re: How to go to git from svn without checkout
On Sat, Mar 21, 2009 at 01:25:38PM -0700, Mercedes6s wrote:
> Hello. I've been falling more and more in love with git and I want to move
> our biggest project because it is my biggest pain over to git to make our
> lives easier. The problem is our project is about 50 gigs (A lot of media
> files involved). Also, we got developers all over the world that are
> running on slow connections. Some took a week to get the project up and
> running in the first place. Luckily, they are only isolated instances.
> What I'm wondering is can I have all of them turn their projects into git
> repositories locally and have all of them sync with a master repository once
> they are done. The actual project is only about 500 megs and the changes
> are probably only a few K since they keep their projects up to date, so
> that's more acceptable, but I don't want them to bring down all those media
> files again and I doubt they will be willing to do it. Is this possible,
> and how would I do it?
I'm not sure you can. "git svn clone" will give a stable commit ID in
git; that is, two runs of the same import will yield interoperable git
repositories. However, I'm not sure if that is actually useful to you;
the people with svn checkouts don't _have_ the history. So the clone
operation will have to talk to the server.
However, you should really consider whether you want those 50G in the
git repository at all. Git is pretty good at not looking at parts of the
repository that aren't necessary to an operation, but whole-repository
operations like packing and cloning are going to be absurdly slow.
Are those files actually changing? Would it be feasible to put the
"main" part of the project in git and just include something like
symlinks in the repository pointing to your media? Then each local
developer could clone the git project and just move their existing 50G
of media files into place.
-Peff
^ permalink raw reply
* started a cvsps testsuite Was: Re: [PATCH v3 0/2] cvsimport: add test illustrating a bug in cvsps
From: Heiko Voigt @ 2009-03-23 18:11 UTC (permalink / raw)
To: Michael Haggerty
Cc: Michael J Gruber, Junio C Hamano, Heiko Voigt, ydirson, git,
CVSps
In-Reply-To: <49C47DF7.9000601@alum.mit.edu>
Hallo,
I just started a very simple but hopefully effective testsuite to
collect all the issues we found with cvsps. Because I haven't heard
anything from Yann who where the last one to collect some patches I
forked his master and started from there.
http://repo.or.cz/w/cvsps-hv.git
The testsuite is on the pu branch so I can first get some feedback
before I will merge it to master.
Maybe Michael can add his tests as well. You should just need to
construct the expected cvsps output. I choose a similar naming
to the one from git. The suite is very simple:
for each test tXXXX-name should be a correspondingly named CVS module in
t/cvsroot and a directory t/tXXXX-name. In this directory a file named
'expect' contains the expected output of cvsps. If the test is known to
fail also an empty file: 'known_to_fail' is added to the test directory.
Thats it.
Hopefully we can collect some more specifics about the situations where
cvsps fails and most importantly the amount of coding needed for fixing.
From there on it should be easier to decide which route to follow for
a robust inbuild git cvsimport.
cheers Heiko
^ permalink raw reply
* [PATCH] gitk: Make more options easily accessible from Edit View dialog
From: newren @ 2009-03-23 17:57 UTC (permalink / raw)
To: paulus; +Cc: git, angavrilov, Elijah Newren
In-Reply-To: <18887.24393.595519.320173@cargo.ozlabs.ibm.com>
From: Elijah Newren <newren@gmail.com>
Commit 218a900bd8efd0d49f8a0d9491aa4786a998d4f4 added a number of new
individual fields for the Edit View dialog to make them more accessible
to end users, while still allowing all options to be specified in the
"arguments to git log" field. This patch extends the dialog further,
to include refs, author, committer, commit message, and patch contents.
As before everything still remains accessible from the "arguments to
git log" input field.
Additionally, this provides hints for the format of the various input
fields (for example, listing some sample date strings in different
formats), and puts related query items into subsections to make it
easier to digest the number of options that exist.
Signed-off-by: Elijah Newren <newren@gmail.com>
---
gitk-git/gitk | 131 +++++++++++++++++++++++++++++++++++++++++----------------
1 files changed, 94 insertions(+), 37 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 1773ae6..6c08031 100644
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -3631,17 +3631,35 @@ proc newview {ishighlight} {
}
set known_view_options {
- {perm b . {} {mc "Remember this view"}}
- {args t50= + {} {mc "Commits to include (arguments to git log):"}}
- {all b * "--all" {mc "Use all refs"}}
- {dorder b . {"--date-order" "-d"} {mc "Strictly sort by date"}}
- {lright b . "--left-right" {mc "Mark branch sides"}}
- {since t15 + {"--since=*" "--after=*"} {mc "Since date:"}}
- {until t15 . {"--until=*" "--before=*"} {mc "Until date:"}}
- {limit t10 + "--max-count=*" {mc "Max count:"}}
- {skip t10 . "--skip=*" {mc "Skip:"}}
- {first b . "--first-parent" {mc "Limit to first parent"}}
- {cmd t50= + {} {mc "Command to generate more commits to include:"}}
+ {perm b . {} {mc "Remember this view"}}
+ {reflabel l + {} {mc "References (space separated list):"}}
+ {refs t15 .. {} {mc "Branches & tags:"}}
+ {allrefs b *. "--all" {mc "All refs"}}
+ {branches b . "--branches" {mc "All (local) branches"}}
+ {tags b . "--tags" {mc "All tags"}}
+ {remotes b . "--remotes" {mc "All remote-tracking branches"}}
+ {commitlbl l + {} {mc "Commit Info (regular expressions):"}}
+ {author t15 .. "--author=*" {mc "Author:"}}
+ {committer t15 . "--committer=*" {mc "Committer:"}}
+ {loginfo t15 .. "--grep=*" {mc "Commit Message:"}}
+ {allmatch b .. "--all-match" {mc "Matches all Commit Info criteria"}}
+ {changes_l l + {} {mc "Changes to Files:"}}
+ {pickaxe_s r0 . {} {mc "Fixed String"}}
+ {pickaxe_t r1 . "--pickaxe-regex" {mc "Regular Expression"}}
+ {pickaxe t15 .. "-S*" {mc "Search string:"}}
+ {datelabel l + {} {mc "Commit Dates (\"2 weeks ago\", \"2009-03-17 15:27:38\", \"March 17, 2009 15:27:38\"):"}}
+ {since t15 .. {"--since=*" "--after=*"} {mc "Since:"}}
+ {until t15 . {"--until=*" "--before=*"} {mc "Until:"}}
+ {limit_lbl l + {} {mc "Limit and/or skip a number of revisions (positive integer):"}}
+ {limit t10 *. "--max-count=*" {mc "Number to show:"}}
+ {skip t10 . "--skip=*" {mc "Number to skip:"}}
+ {misc_lbl l + {} {mc "Miscellaneous options:"}}
+ {dorder b *. {"--date-order" "-d"} {mc "Strictly sort by date"}}
+ {lright b . "--left-right" {mc "Mark branch sides"}}
+ {first b . "--first-parent" {mc "Limit to first parent"}}
+ {args t50 *. {} {mc "Additional arguments to git log:"}}
+ {allpaths path + {} {mc "Enter files and directories to include, one per line:"}}
+ {cmd t50= + {} {mc "Command to generate more commits to include:"}}
}
proc encode_view_opts {n} {
@@ -3653,13 +3671,19 @@ proc encode_view_opts {n} {
if {$patterns eq {}} continue
set pattern [lindex $patterns 0]
- set val $newviewopts($n,[lindex $opt 0])
-
if {[lindex $opt 1] eq "b"} {
+ set val $newviewopts($n,[lindex $opt 0])
if {$val} {
lappend rargs $pattern
}
+ } elseif {[regexp {^r(\d+)$} [lindex $opt 1] type value]} {
+ regexp {^(.*_)} [lindex $opt 0] uselessvar button_id
+ set val $newviewopts($n,$button_id)
+ if {$val eq $value} {
+ lappend rargs $pattern
+ }
} else {
+ set val $newviewopts($n,[lindex $opt 0])
set val [string trim $val]
if {$val ne {}} {
set pfix [string range $pattern 0 end-1]
@@ -3667,6 +3691,7 @@ proc encode_view_opts {n} {
}
}
}
+ set rargs [concat $rargs [shellsplit $newviewopts($n,refs)]]
return [concat $rargs [shellsplit $newviewopts($n,args)]]
}
@@ -3674,14 +3699,22 @@ proc decode_view_opts {n view_args} {
global known_view_options newviewopts
foreach opt $known_view_options {
+ set id [lindex $opt 0]
if {[lindex $opt 1] eq "b"} {
+ # Checkboxes
+ set val 0
+ } elseif {[regexp {^r(\d+)$} [lindex $opt 1]]} {
+ # Radiobuttons
+ regexp {^(.*_)} $id uselessvar id
set val 0
} else {
+ # Text fields
set val {}
}
- set newviewopts($n,[lindex $opt 0]) $val
+ set newviewopts($n,$id) $val
}
set oargs [list]
+ set refargs [list]
foreach arg $view_args {
if {[regexp -- {^-([0-9]+)$} $arg arg cnt]
&& ![info exists found(limit)]} {
@@ -3695,11 +3728,17 @@ proc decode_view_opts {n view_args} {
if {[info exists found($id)]} continue
foreach pattern [lindex $opt 3] {
if {![string match $pattern $arg]} continue
- if {[lindex $opt 1] ne "b"} {
+ if {[lindex $opt 1] eq "b"} {
+ # Check buttons
+ set val 1
+ } elseif {[regexp {^r(\d+)$} [lindex $opt 1] match num]} {
+ # Radio buttons
+ regexp {^(.*_)} $id uselessvar id
+ set val $num
+ } else {
+ # Text input fields
set size [string length $pattern]
set val [string range $arg [expr {$size-1}] end]
- } else {
- set val 1
}
set newviewopts($n,$id) $val
set found($id) 1
@@ -3708,8 +3747,13 @@ proc decode_view_opts {n view_args} {
if {[info exists val]} break
}
if {[info exists val]} continue
- lappend oargs $arg
+ if {[regexp {^-} $arg]} {
+ lappend oargs $arg
+ } else {
+ lappend refargs $arg
+ }
}
+ set newviewopts($n,refs) [shellarglist $refargs]
set newviewopts($n,args) [shellarglist $oargs]
}
@@ -3745,16 +3789,16 @@ proc vieweditor {top n title} {
global known_view_options
toplevel $top
- wm title $top $title
+ wm title $top [concat $title "-- criteria for selecting revisions"]
make_transient $top .
# View name
frame $top.nfr
- label $top.nl -text [mc "Name"]
+ label $top.nl -text [mc "View Name:"]
entry $top.name -width 20 -textvariable newviewname($n)
pack $top.nfr -in $top -fill x -pady 5 -padx 3
- pack $top.nl -in $top.nfr -side left -padx {0 30}
- pack $top.name -in $top.nfr -side left
+ pack $top.nl -in $top.nfr -side left -padx {0 5}
+ pack $top.name -in $top.nfr -side left -padx {0 25}
# View options
set cframe $top.nfr
@@ -3773,14 +3817,28 @@ proc vieweditor {top n title} {
frame $cframe
pack $cframe -in $top -fill x -pady 3 -padx 3
set cexpand [expr {$flags eq "*"}]
+ } elseif {$flags eq ".." || $flags eq "*."} {
+ set cframe $top.fr$cnt
+ incr cnt
+ frame $cframe
+ pack $cframe -in $top -fill x -pady 3 -padx [list 15 3]
+ set cexpand [expr {$flags eq "*."}]
} else {
set lxpad 5
}
- if {$type eq "b"} {
+ if {$type eq "l"} {
+ label $cframe.l_$id -text $title
+ pack $cframe.l_$id -in $cframe -side left -pady [list 3 0] -anchor w
+ } elseif {$type eq "b"} {
checkbutton $cframe.c_$id -text $title -variable newviewopts($n,$id)
pack $cframe.c_$id -in $cframe -side left \
-padx [list $lxpad 0] -expand $cexpand -anchor w
+ } elseif {[regexp {^r(\d+)$} $type type sz]} {
+ regexp {^(.*_)} $id uselessvar button_id
+ radiobutton $cframe.c_$id -text $title -variable newviewopts($n,$button_id) -value $sz
+ pack $cframe.c_$id -in $cframe -side left \
+ -padx [list $lxpad 0] -expand $cexpand -anchor w
} elseif {[regexp {^t(\d+)$} $type type sz]} {
message $cframe.l_$id -aspect 1500 -text $title
entry $cframe.e_$id -width $sz -background $bgcolor \
@@ -3793,23 +3851,22 @@ proc vieweditor {top n title} {
-textvariable newviewopts($n,$id)
pack $cframe.l_$id -in $cframe -side top -pady [list 3 0] -anchor w
pack $cframe.e_$id -in $cframe -side top -fill x
+ } elseif {$type eq "path"} {
+ message $top.l -aspect 1500 -text $title
+ pack $top.l -in $top -side top -pady [list 3 0] -anchor w -padx 3
+ text $top.t -width 40 -height 5 -background $bgcolor -font uifont
+ if {[info exists viewfiles($n)]} {
+ foreach f $viewfiles($n) {
+ $top.t insert end $f
+ $top.t insert end "\n"
+ }
+ $top.t delete {end - 1c} end
+ $top.t mark set insert 0.0
+ }
+ pack $top.t -in $top -side top -pady [list 0 5] -fill both -expand 1 -padx 3
}
}
- # Path list
- message $top.l -aspect 1500 \
- -text [mc "Enter files and directories to include, one per line:"]
- pack $top.l -in $top -side top -pady [list 7 0] -anchor w -padx 3
- text $top.t -width 40 -height 5 -background $bgcolor -font uifont
- if {[info exists viewfiles($n)]} {
- foreach f $viewfiles($n) {
- $top.t insert end $f
- $top.t insert end "\n"
- }
- $top.t delete {end - 1c} end
- $top.t mark set insert 0.0
- }
- pack $top.t -in $top -side top -pady [list 0 5] -fill both -expand 1 -padx 3
frame $top.buts
button $top.buts.ok -text [mc "OK"] -command [list newviewok $top $n]
button $top.buts.apply -text [mc "Apply (F5)"] -command [list newviewok $top $n 1]
--
1.6.0.6
^ permalink raw reply related
* Re: [RFC with a proof of concept PATCH] Add Bonsai-like query options to gitk
From: Elijah Newren @ 2009-03-23 17:56 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Git Mailing List, Alexander Gavrilov
In-Reply-To: <51419b2c0903231054g621787b6i8537b8e0d5bf121d@mail.gmail.com>
(Sorry, resending my own email since I accidentally left of the cc's.)
On Mon, Mar 23, 2009 at 4:07 AM, Paul Mackerras <paulus@samba.org> wrote:
> Elijah Newren <newren@gmail.com> writes:
>
>> (If you like screenshots, I've got some before & after ones up at
>> http://www.gnome.org/~newren/temp/gitk/gitk-edit-view.html, but
>> remember that this is just a proof of concept and call for comments.)
>
> Looks reasonable... have you developed the patch any further?
Yes, I have. There was a cosmetic tweak or two, but the main change
was fixing the view remembering stuff that I noted I broke in the
original patch. I've also showed this modified dialog in two
different git presentations, to dozens of new and potential users of
git, and it seems to have been well received[1]. I'll send a
follow-up patch shortly (I'd copy it inline, but I'm afraid gmail will
screw it up).
Elijah
[1] For one of the two groups, a lack of a Bonsai replacement actually
derailed their conversion to svn about a year ago. This group was
very interested in git after my presentation and seemed satisfied with
gitk (with my proposed changes) as a replacement for Bonsai. There
was one minor question that did come up each time -- one person in
each presentation asked why it is that when you specify --author=smith
(at the command line or via the equivalent box in the gui), you also
see commits authored by e.g. "jones" in gitk; however, once I
mentioned the different colored dots in gitk and the fact that it's
showing the commits that the patches are relative to, there was no
more issue and everyone was happy. I'm guessing it'd be slightly more
intuitive to them to have gitk filter out these parent commits from
the graph unless they also meet the search criteria, but it's a pretty
minor issue.
^ permalink raw reply
* Re: [PATCH v3 0/2] cvsimport: add test illustrating a bug in cvsps
From: Heiko Voigt @ 2009-03-23 17:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Heiko Voigt, Michael Haggerty, ydirson, git
In-Reply-To: <7vfxhag07g.fsf@gitster.siamese.dyndns.org>
On Wed, Mar 18, 2009 at 11:22:43AM -0700, Junio C Hamano was talking about:
> Heiko Voigt <git-list@hvoigt.net> writes:
>
> > This is an updated version of the first patch and an addition to ensure
> > correct handling of branches in fixes.
>
> I've already merged the first one to 'next' so this needs to be turned
> into an incremental update if we were to continue building on top in the
> git project.
>
> I however have a bigger issue with this, perhaps because I do not have the
> feeling that I fully understand where these patches are going.
To explain my intentions a little more: I recently imported a huge
repository with ~11 years of history from a RCS based system.
The final step into git land was through CVS. Here I really struggled to
find the right tool and it costed me quite some time just to find a
robust tool for the job (and to figure out why the "standard" tool
failed).
So my main goal is to save some time and hassle for everyone else going
this route. There are really nicer things to spend time on than
importing and repairing RCS files.
I think many people when starting with git get the feeling: Oh look at
this SHA1 based database and stuff these people have written a really
neat robust system. Then you look at getting your history (from CVS)
into it and it becomes a nightmare. The command git cvsimport just does
not fit with the rest of the git tools quality.
>
> Your approach seems to me to:
>
> - add tests to git test suite that expose issues the current cvsimport
> that runs on an unpatched cvsps has;
>
> - diagnose and fix
>
> - the issues in cvsimport, if the problem is because cvsimport is
> mishandling correct output from cvsps; or
>
> - the issues in cvsps (and adjust cvsimport to patched cvsps if
> necessary), if the problem is because output from cvsps is incorrect.
>
> That all feels sane, and having the tests to verify the end result would
> help the people who collaborate on these tasks.
>
> But how much of the actual fix will be made to cvsps, and how much to
> cvsimport?
I can not answer this question at the moment. One thing would be fixing
cvsps, which just for one test (mine) seems like a lot of work. I
haven't even looked into the other issues.
After writing my last email it came to my mind that it could be a
simpler approach to take parsecvs (only because its already written in C
otherwise probably cvs2svn/cvs2git) and change the interface so it
matches the one of git cvsimport and integrate it with git.
To let this happen the question is how important various features of the
current cvsimport are:
* incremental import
* keyword substitution
* ...
> If the majority of the changes are to happen on cvsps (which
> is not unexpected, given that many people who tried and wrote various cvs
> importers put blame on the shortcomings of its output), I am afraid that
> it would not help majority of git users until the fixes to cvsps that come
> out of this effort hit their distros for me to keep these tests in the
> git.git repository. I do not build and install custom cvsps (because I
> haven't had to work with complex history in CVS that your improvements to
> cvsps are need to deal with correctly), and I suspect many others are in
> the same boat. In addition, if your tests are in the git.git repository,
> they need to say test_expect_success for people with patched cvsps and
> test_expect_failure for people without, and because I suspect that the
> majority of git developers do not run bleeding edge cvsps, it does not do
> anything but slowing down the test suite.
>
> It feels as if you are scratching my feet through my shoes while I still
> am wearing them. I wonder if it would be more direct and simpler approach
> to add tests to cvsps and handle these improvements as part of the cvsps
> maintenance/development effort, not as part of cvsimport fixes, at least
> initially.
>
> I think it is great that you started actively working on identifying and
> fixing issues with cvsps, that many others have gave up and gone to
> different avenues, and I certainly do not mind keeping the new tests in
> 'pu' for wider exposure, in order to make it easier for other people who
> use cvsimport and want to collaborate with you improving it through
> improving cvsps.
>
> But I am starting to think that it was a mistake on my part to have merged
> the initial set of tests to 'next'.
>
> Thoughts?
In the long run I think at least a basic test for the current issues
should be in git. Otherwise if cvsimport gets fixed you do not have a
way of making sure all tools (cvsps) in their right versions are
installed. Even with another non cvsps importer this property needs to
be ensured to handle non trivial repositories.
The only people who actually need to know about issues in cvsimport are
the ones who are trying to get away from CVS. So its probably best to
disable the "advanced" tests and have an environment variable e.g.:
"ALL_CVSIMPORT_TESTS" for enabling them.
cheers Heiko
^ permalink raw reply
* Re: [PATCH] difftool: add support for an extended revision syntax
From: Michael J Gruber @ 2009-03-23 16:46 UTC (permalink / raw)
To: David Aguilar; +Cc: gitster, git
In-Reply-To: <20090323163343.GB16258@gmail.com>
David Aguilar venit, vidit, dixit 23.03.2009 17:33:
> On 0, Michael J Gruber <git@drmicha.warpmail.net> wrote:
>> David Aguilar venit, vidit, dixit 23.03.2009 11:15:
>>>
>>> This makes answering that question considerably easier.
>>> Users can now simply say:
>>>
>>> $ git difftool <file>~
>>>
>>> to compare <file> in the worktree against its
>>> previous version, and:
>>>
>>> $ git difftool <file>~2 <file>~
>>>
>>> to compare <file> from 2 versions ago to <file>'s
>>> previous version, etc.
>>>
>>
>> I like the idea of having a shortcut like that a lot, but I'm sorry I'm
>> not supportive of a tool-specific rev syntax extension; for principal
>> reasons, but also because diff, checkout and maybe others could make
>> good use of it.
>
> I completely agree. I want a convenient shortcut to use everywhere.
>
>
>> Work is underway on clearing out the issue of forbidden characters in
>> revision specifiers. We already have commit:file. I think something like
>> ~2:file would be short enough as well as in line with the usual
>> semantics. Similarly,
>>
>> git diff ~3 ~2 file
>> git diff ~3 file
>>
>> would be short and simple as soon as ~3 is implemented to be a shortcut
>> for HEAD~3. (I'm not sure we can actually use ~, even though it would
>> fit in with the usual "if it's not specified it's HEAD".) This would
>> only need a shortcut for HEAD, such as not even specifying it (as above)
>> or c~ with c being our new fancy character for that.
>
>
> One of my ulterior motives for sending this patch was to
> start a discussion on this topic. I missed the discussion
> about clearing out forbidden characters so I'll see if I can
> find it in the archives. Do you happen to have a link?
>
> Keep in mind that the syntax that this patch added does
> not have file~3 = HEAD~3. file~3 means finding file as it
> existed 3 changes-to-file ago, which is != to HEAD~3 if file
> did not change in the last 3 commits.
>
> It basically runs 'git log -- file' so that only the commits
> that touch file are considered.
>
> Are you suggesting that ~3:file could be the shortcut for
> this, or would we need a different syntax since you just
> said that ~3 would be a shortcut for HEAD~3?
I think both would be useful. Depending on the way it's done, only
HEAD~3 maybe be realizable.
> If there's work on syntax-sugarfying diff/checkout/etc. with
> these kind of shortcuts then I would like to help out with
> patches, testing, etc.
http://article.gmane.org/gmane.comp.version-control.git/114257 is the
newest installment, although
http://article.gmane.org/gmane.comp.version-control.git/114076 and
especially
http://article.gmane.org/gmane.comp.version-control.git/113647 is very
worthwhile reading :)
[Isn't there a better way to link to posts? I think I used to take
message ids.]
> This is a feature that lots of users would enjoy--I know that
> for sure.
>
^ permalink raw reply
* Re: [bug?] git-format-patch produces a 0-byte long patch for the first commit
From: Guennadi Liakhovetski @ 2009-03-23 16:46 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <200903231729.08216.trast@student.ethz.ch>
On Mon, 23 Mar 2009, Thomas Rast wrote:
> Guennadi Liakhovetski wrote:
> > mkdir x
> > cd x
> > git-init
> > echo hi > greating
> > git-commit -a
> [...]
> > git-format-patch HEAD^ produces an error,
>
> There is no HEAD^ in this case. HEAD is always the currently checked
> out commit. Since it has a root commit, it has no parent, so you
> cannot apply ^ ("the first parent of") to it. Similarly, HEAD~2 will
> not work if HEAD~1 has no parent, etc.
Yes, I can understand this, still from the high-level PoV, this looks
inconsistent:
git-format-patch HEAD
never produces anything, which means for me, I'm trying to extract commits
for a 0-length range.
git-format-patch HEAD^
Usually produces the "current" or the "last" commit - except if you're
currently on the first commit... But I'm not insisting on this one - maybe
you're right, it just _does_ look weird.
Just try to forget about the meaning of the command. You are somewhere on
the commit timeline. You enter "some" command, which usually produces
exactly one - the most recent commit. So, I would expect this to work
always when there is at least one commit in the tree.
So, maybe it would make sense to refer to the point before-the-root-commit
every time root's parent is requested?
> > git-format-patch -1 produces a 0-byte long patch.
>
> That is admittedly weird and probably deserves a fix and/or suggestion
> to use --root.
>
> I'm not sure what else I can add to the explanations I gave on IRC.
Thanks for answering again, I just wanted to make sure this "weirdness"
doesn't get lost, and possibly gets fixed. I think, you suggested yourself
to post to the list, so I did.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
^ permalink raw reply
* Can't grok this: tracking 3rd party code (from git/svn repositories and/or snapshots)
From: Michiel Detailleur @ 2009-03-23 16:37 UTC (permalink / raw)
To: git
Hi,
I can't seem to grok the different solutions I've found and studied
for tracking external code. Let alone understand how to apply them to
my use case...
Would you guys be so kind to shed some light on this and help me with
my specific use case? What would be the best solution for the
following, concrete problem? (I'm not gonna attempt to generalize my
problem, since I might make wrong assumptions about stuff, especially
since I'm so new with all this...)
I'm building a website in Django (a web framework in Python). Now,
there are a lot of 3rd party plugins available for use with Django
(Django calls them 'apps'), that you can drop in your project. Some of
these apps might require a bit of modification to get working like I
want them. But if you start making modifications to 3rd party code you
introduce the problem of updating that code when newer versions appear
AND at the same time keeping your local modifications.
So, the way I would do that in Subversion is by using vendor branches.
My repository layout would look like this:
/trunk
...
/apps
/blog-app
...
/tags
...
/branches
...
/vendor
/django-apps
/blog-app
/1.2
/1.3
/current
/other-app
/3.2
/current
In this case /trunk/apps/blog-app would have been svn copy'd of one of
the tags in /vendor/django-apps/blog-app. Say that it was v1.2. And
that I now want to upgrade my version in trunk to v1.3. As you can
see, I have already updated /vendor/django-apps/blog-app/current
(using svn_load_dirs) and 'tagged' (svn copy) it as
/vendor/django-apps/blog-app/1.3.
Now I can update /trunk/apps/blog-app by svn merge'ing the changes
between /vendor/django-apps/blog-app/1.2 and
/vendor/django-apps/blog-app/1.3 on /trunk/apps/blog-app. This will
keep my local changes.
(for people unknown with this process, it is described in the
Subversion handbook:
http://svnbook.red-bean.com/en/1.5/svn.advanced.vendorbr.html)
Now I want to do this whole process in Git. How can I do this?
Let me re-iterate the requirements:
* I must be able to place the external code in an arbitrary position in the tree
* I must be able to modify the external code and keep (commit) these
modifications in my Git repos
* I must be able to easily update the external code, should a new
version be released, whilst keeping my changes
Extra (for bonus points ;-) ):
* Preferably I want to do this without something like svn_load_dirs. I
think it should be possible to track the apps and their updates
straight from their repository (most 3rd party Django apps are kept in
Subversion). Giving me the added benefit of being able to view
individual commit messages between releases. And fixing merge
conflicts more easily since I can deal with a lot of small commits
instead of the one artificial commit created by svn_load_dirs.
I think one would do this with svn:externals in Subversion, but I have
never worked with that before...
A solution where a combination of both methods could be used would be
even more preferable, since there might be app developers who don't
use source control or don't make their repos available publicly.
(Meaning both svn_load_dirs-like behavior and tracking straight from a
Subversion reposity (or another Git))
I'm eagerly awaiting your responses! Please be as verbose as possible
when replying, since I already had a hard time understanding other
examples found online.
Thanks in advance,
Michiel
^ permalink raw reply
* Re: [RFC/WIP 0/2] Documentation clean-up: git commands
From: Michael J Gruber @ 2009-03-23 16:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwsag5hva.fsf@gitster.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 23.03.2009 17:22:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> - Do we want it this way (`git command`)?
>
> That's my personal preference but other people may differ; wasn't there an
> issue with "man" backend losing the typesetting information?
Some man readers reconstruct links when they see something like
git-add[1], which is why I proposed not changing those for now. A while
ago I introduced a backend specific linkgit macro (git-command for man,
git command for others), but that was not so well received.
>> - How to prepare: 1 patch per file/per 5 files/per 50 changes?
>> - How to submit: single patch once ready or whole series at end (5 years
>> from now)?
>> - How to send: Bother the list or send pull requests only?
>
> How about a fork of git.git on repo.or.cz that branches from 1.6.2 and that:
>
> - does not pull from git.git/master unless absoletely necessary; and
> - contains only these clean-up changes and nothing else?
>
Whatever works for you. I have a fork there anyway but would need to
rebase to 1.6.2 as opposed to next. But somehow we would need to ensure
that new Documentation patches don't regress away from the consistent style.
> A bonus point would be for a publically reachable pages rendered out of
> the tip of this "documentation updates" repository, so that people can
> view it, compare it with www.kernel.org/pub/software/git/docs/.
I didn't plan on changing style, only making the usage of ` and such
more consistent. I find these are spotted most conveniently with diff
--color-words. Do you really think rendered versions are worthwhile for
that?
> I would love to have a separate "documentation maintainer" in the longer
> run, and it would be great if your tree becomes it. I can start pulling
> from you, forwarding any documentation patches your way.
>
> Thanks.
Uhm, ohm. Let's see how the quotation and dash thing goes first... I
don't want to make promises I can't keep (time-wise).
Michael
^ permalink raw reply
* Re: [StGit PATCH] Add the --merged option to goto
From: Catalin Marinas @ 2009-03-23 16:33 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20090323084507.GA6447@diana.vm.bytemark.co.uk>
2009/3/23 Karl Hasselström <kha@treskal.com>:
> On 2009-03-20 16:15:45 +0000, Catalin Marinas wrote:
>> @@ -752,12 +752,13 @@ class Index(RunWithEnv):
>> assert current == None or isinstance(current, Tree)
>>
>> # Take care of the really trivial cases.
>> - if base == ours:
>> - return (theirs, current)
>> - if base == theirs:
>> - return (ours, current)
>> - if ours == theirs:
>> - return (ours, current)
>> + if check_trivial:
>> + if base == ours:
>> + return (theirs, current)
>> + if base == theirs:
>> + return (ours, current)
>> + if ours == theirs:
>> + return (ours, current)
>
> Uh, what? What's the point of not doing this unconditionally?
There are a few cases where my algorithm failed because the reverse
applying of patches fell on one of those special cases (otherwise they
wouldn't apply). The check_merged() function assumes that if a patch
can be reversed in a given tree, it was already included in that tree.
Let's assume that the tree corresponding to the top patch is T1. We
have the following cases for reverse-applying a patch which fall under
the trivial cases above (patch expressed as bottom_tree..top_tree):
The empty patch cases should be ignored from such test (not done currently):
T1..T1 => merge(T1, T1, T1) == T1
T2..T2 => merge(T2, T1, T2) == T1
The non-empty patch situations:
T1..T2 => merge(T2, T1, T1) == T1
T2..T1 => merge(T1, T1, T2) == T2
The T1..T2 is pretty common and happens when the base of a patch
wasn't modified. Reverse-applying such patch should not normally
succeed but the merge() here uses one of those special cases. The
merge() result is correct since we want two trees merged, T1 and T1,
with a common base, T2, used a helper.
The T2..T1 cases would succeed with both trivial checks and
apply_treediff() and that's probably OK since if a patch generates the
same tree when applied, the changes it makes were probably already
included.
Now I understand it better :-). Reading my explanation above, it seems
that only the T1..T2 case matters and it can be taken care of in the
check_merged() function. Checking whether the tree returned by merge()
is different than "ours" should be enough for all the above cases.
>> @@ -379,3 +385,25 @@ class StackTransaction(object):
>> assert set(self.unapplied + self.hidden) == set(unapplied + hidden)
>> self.unapplied = unapplied
>> self.hidden = hidden
>> +
>> + def check_merged(self, patches):
>> + """Return a subset of patches already merged."""
>> + merged = []
>> + temp_index = self.__stack.repository.temp_index()
>> + temp_index_tree = None
>
> There's no need to create a new temp index here. The transaction
> object already has one.
I had the impression that an Index object would hold some state and
didn't want to break it. It seems OK to use as long as I don't touch
self.temp_index_tree. See below for an updated patch:
Add the --merged option to goto
From: Catalin Marinas <catalin.marinas@gmail.com>
This patch adds support for checking which patches were already merged
upstream. This checking is done by trying to reverse-apply the patches
in the index before pushing them onto the stack.
Signed-off-by: Catalin Marinas <catalin.marinas@gmail.com>
---
stgit/argparse.py | 4 ++++
stgit/commands/goto.py | 12 +++++++++---
stgit/lib/git.py | 2 +-
stgit/lib/transaction.py | 38 +++++++++++++++++++++++++++++++-------
4 files changed, 45 insertions(+), 11 deletions(-)
diff --git a/stgit/argparse.py b/stgit/argparse.py
index 85ee6e3..765579c 100644
--- a/stgit/argparse.py
+++ b/stgit/argparse.py
@@ -225,6 +225,10 @@ def keep_option():
short = 'Keep the local changes',
default = config.get('stgit.autokeep') == 'yes')]
+def merged_option():
+ return [opt('-m', '--merged', action = 'store_true',
+ short = 'Check for patches merged upstream')]
+
class CompgenBase(object):
def actions(self, var): return set()
def words(self, var): return set()
diff --git a/stgit/commands/goto.py b/stgit/commands/goto.py
index 66f49df..839b75c 100644
--- a/stgit/commands/goto.py
+++ b/stgit/commands/goto.py
@@ -28,7 +28,7 @@ Push/pop patches to/from the stack until the one
given on the command
line becomes current."""
args = [argparse.other_applied_patches, argparse.unapplied_patches]
-options = argparse.keep_option()
+options = argparse.keep_option() + argparse.merged_option()
directory = common.DirectoryHasRepositoryLib()
@@ -47,8 +47,14 @@ def func(parser, options, args):
assert not trans.pop_patches(lambda pn: pn in to_pop)
elif patch in trans.unapplied:
try:
- for pn in trans.unapplied[:trans.unapplied.index(patch)+1]:
- trans.push_patch(pn, iw, allow_interactive = True)
+ to_push = trans.unapplied[:trans.unapplied.index(patch)+1]
+ if options.merged:
+ merged = set(trans.check_merged(to_push))
+ else:
+ merged = set()
+ for pn in to_push:
+ trans.push_patch(pn, iw, allow_interactive = True,
+ already_merged = pn in merged)
except transaction.TransactionHalted:
pass
elif patch in trans.hidden:
diff --git a/stgit/lib/git.py b/stgit/lib/git.py
index e0a3c96..fcac918 100644
--- a/stgit/lib/git.py
+++ b/stgit/lib/git.py
@@ -732,7 +732,7 @@ class Index(RunWithEnv):
# to use --binary.
self.apply(self.__repository.diff_tree(tree1, tree2, ['--full-index']),
quiet)
- def merge(self, base, ours, theirs, current = None):
+ def merge(self, base, ours, theirs, current = None, check_trivial = True):
"""Use the index (and only the index) to do a 3-way merge of the
L{Tree}s C{base}, C{ours} and C{theirs}. The merge will either
succeed (in which case the first half of the return value is
diff --git a/stgit/lib/transaction.py b/stgit/lib/transaction.py
index b146648..9fa75c1 100644
--- a/stgit/lib/transaction.py
+++ b/stgit/lib/transaction.py
@@ -297,7 +297,8 @@ class StackTransaction(object):
out.info('Deleted %s%s' % (pn, s))
return popped
- def push_patch(self, pn, iw = None, allow_interactive = False):
+ def push_patch(self, pn, iw = None, allow_interactive = False,
+ already_merged = False):
"""Attempt to push the named patch. If this results in conflicts,
halts the transaction. If index+worktree are given, spill any
conflicts to them."""
@@ -305,11 +306,14 @@ class StackTransaction(object):
cd = orig_cd.set_committer(None)
oldparent = cd.parent
cd = cd.set_parent(self.top)
- base = oldparent.data.tree
- ours = cd.parent.data.tree
- theirs = cd.tree
- tree, self.temp_index_tree = self.temp_index.merge(
- base, ours, theirs, self.temp_index_tree)
+ if already_merged:
+ tree = cd.tree
+ else:
+ base = oldparent.data.tree
+ ours = cd.parent.data.tree
+ theirs = cd.tree
+ tree, self.temp_index_tree = self.temp_index.merge(
+ base, ours, theirs, self.temp_index_tree)
s = ''
merge_conflict = False
if not tree:
@@ -341,7 +345,9 @@ class StackTransaction(object):
else:
comm = None
s = ' (unmodified)'
- if not merge_conflict and cd.is_nochange():
+ if already_merged:
+ s = ' (merged)'
+ elif not merge_conflict and cd.is_nochange():
s = ' (empty)'
out.info('Pushed %s%s' % (pn, s))
def update():
@@ -379,3 +385,21 @@ class StackTransaction(object):
assert set(self.unapplied + self.hidden) == set(unapplied + hidden)
self.unapplied = unapplied
self.hidden = hidden
+
+ def check_merged(self, patches):
+ """Return a subset of patches already merged."""
+ merged = []
+ temp_index_tree = None
+ ours = self.stack.head.data.tree
+ for pn in reversed(patches):
+ # check whether patch changes can be reversed in the current tree
+ cd = self.patches[pn].data
+ base = cd.tree
+ theirs = cd.parent.data.tree
+ tree, temp_index_tree = \
+ self.temp_index.merge(base, ours, theirs, temp_index_tree,
+ check_trivial = False)
+ if tree and tree != ours:
+ merged.append(pn)
+ ours = tree
+ return merged
--
Catalin
^ permalink raw reply related
* Re: [PATCH] difftool: add support for an extended revision syntax
From: David Aguilar @ 2009-03-23 16:33 UTC (permalink / raw)
To: Michael J Gruber; +Cc: gitster, git
In-Reply-To: <49C7A20E.7060503@drmicha.warpmail.net>
On 0, Michael J Gruber <git@drmicha.warpmail.net> wrote:
> David Aguilar venit, vidit, dixit 23.03.2009 11:15:
> >
> > This makes answering that question considerably easier.
> > Users can now simply say:
> >
> > $ git difftool <file>~
> >
> > to compare <file> in the worktree against its
> > previous version, and:
> >
> > $ git difftool <file>~2 <file>~
> >
> > to compare <file> from 2 versions ago to <file>'s
> > previous version, etc.
> >
>
> I like the idea of having a shortcut like that a lot, but I'm sorry I'm
> not supportive of a tool-specific rev syntax extension; for principal
> reasons, but also because diff, checkout and maybe others could make
> good use of it.
I completely agree. I want a convenient shortcut to use everywhere.
> Work is underway on clearing out the issue of forbidden characters in
> revision specifiers. We already have commit:file. I think something like
> ~2:file would be short enough as well as in line with the usual
> semantics. Similarly,
>
> git diff ~3 ~2 file
> git diff ~3 file
>
> would be short and simple as soon as ~3 is implemented to be a shortcut
> for HEAD~3. (I'm not sure we can actually use ~, even though it would
> fit in with the usual "if it's not specified it's HEAD".) This would
> only need a shortcut for HEAD, such as not even specifying it (as above)
> or c~ with c being our new fancy character for that.
One of my ulterior motives for sending this patch was to
start a discussion on this topic. I missed the discussion
about clearing out forbidden characters so I'll see if I can
find it in the archives. Do you happen to have a link?
Keep in mind that the syntax that this patch added does
not have file~3 = HEAD~3. file~3 means finding file as it
existed 3 changes-to-file ago, which is != to HEAD~3 if file
did not change in the last 3 commits.
It basically runs 'git log -- file' so that only the commits
that touch file are considered.
Are you suggesting that ~3:file could be the shortcut for
this, or would we need a different syntax since you just
said that ~3 would be a shortcut for HEAD~3?
If there's work on syntax-sugarfying diff/checkout/etc. with
these kind of shortcuts then I would like to help out with
patches, testing, etc.
This is a feature that lots of users would enjoy--I know that
for sure.
--
David
^ permalink raw reply
* Re: [bug?] git-format-patch produces a 0-byte long patch for the first commit
From: Thomas Rast @ 2009-03-23 16:29 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0903231119110.4871@axis700.grange>
[-- Attachment #1: Type: text/plain, Size: 669 bytes --]
Guennadi Liakhovetski wrote:
> mkdir x
> cd x
> git-init
> echo hi > greating
> git-commit -a
[...]
> git-format-patch HEAD^ produces an error,
There is no HEAD^ in this case. HEAD is always the currently checked
out commit. Since it has a root commit, it has no parent, so you
cannot apply ^ ("the first parent of") to it. Similarly, HEAD~2 will
not work if HEAD~1 has no parent, etc.
> git-format-patch -1 produces a 0-byte long patch.
That is admittedly weird and probably deserves a fix and/or suggestion
to use --root.
I'm not sure what else I can add to the explanations I gave on IRC.
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [RFC/WIP 0/2] Documentation clean-up: git commands
From: Junio C Hamano @ 2009-03-23 16:22 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <1237818533-31577-1-git-send-email-git@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> - Do we want it this way (`git command`)?
That's my personal preference but other people may differ; wasn't there an
issue with "man" backend losing the typesetting information?
> - How to prepare: 1 patch per file/per 5 files/per 50 changes?
> - How to submit: single patch once ready or whole series at end (5 years
> from now)?
> - How to send: Bother the list or send pull requests only?
How about a fork of git.git on repo.or.cz that branches from 1.6.2 and that:
- does not pull from git.git/master unless absoletely necessary; and
- contains only these clean-up changes and nothing else?
A bonus point would be for a publically reachable pages rendered out of
the tip of this "documentation updates" repository, so that people can
view it, compare it with www.kernel.org/pub/software/git/docs/.
I would love to have a separate "documentation maintainer" in the longer
run, and it would be great if your tree becomes it. I can start pulling
from you, forwarding any documentation patches your way.
Thanks.
^ permalink raw reply
* Re: What's cooking in git.git (Mar 2009, #06; Sat, 21)
From: Junio C Hamano @ 2009-03-23 16:19 UTC (permalink / raw)
To: Finn Arne Gangstad; +Cc: git
In-Reply-To: <20090323144650.GA20058@pvv.org>
Finn Arne Gangstad <finnag@pvv.org> writes:
> On Sat, Mar 21, 2009 at 12:58:33AM -0700, Junio C Hamano wrote:
> [...]
>> * fg/push-default (Mon Mar 16 16:42:52 2009 +0100) 2 commits
>> - Display warning for default git push with no push.default config
>> + New config push.default to decide default behavior for push
>>
>> Replaced the old series with the first step to allow a smooth transition.
>> Some might argue that this should not give any warning but just give users
>> this new configuration to play with first, and after we know we are going
>> to switch default some day, start the warning.
>
> If you feel that talking about a possible future change is premature,
> you could omit that part of the second commit I guess, but I think
> printing some kind of warning is valuable. Are you waiting for more
> input? It seems that this topic is pretty dead now.
>
> Most people who get bitten by this directly are probably not active on
> this list so I don't think you will hear from many of them.
I have already judged that the cause of this series is good, and that is
why the series was even considered to be in git.git to begin with. I also
looked at the code change in them, and I found it Ok, and that is why the
first one is queued in 'next'.
At this point we do not need "Yes, it is a good idea" from people, even
though "No, it is a horrible change because of such and such reasons"
could reverse its course, if the argument is new.
The reason the patch has been sitting in 'next' is entirely unrelated to
the above. It is to hear from people about unintended side effects, if
any. It's only been a week, isn't it?
Unlike documentation reformatting and other kinds of patches in which
potential breakages will not cause a disaster, push is one of the things
we would want to keep working for people. In general, the more important
the area a patch touches, the patch needs to cook longer in 'next'.
^ permalink raw reply
* Re: [PATCH v2 6/7] check_ref_format(): tighten refname rules
From: Junio C Hamano @ 2009-03-23 16:03 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20090323135901.GB9732@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Junio C Hamano <gitster@pobox.com> wrote:
>> This changes the rules for refnames to forbid:
>>
>> (1) a refname that contains "@{" in it.
>> (2) a refname that ends with a dot.
>
> How about also "that end in .lock" ?
Yeah, people can add more as follow-up patches. The primary purpose of
this series is to clean-up places that the new %name notation (or ~name or
whatever) needs to hook into.
^ permalink raw reply
* Re: git rebase + fuzz = possible bad merge
From: Benny Halevy @ 2009-03-23 15:36 UTC (permalink / raw)
To: Thomas Rast; +Cc: Git List
In-Reply-To: <49C79780.20105@panasas.com>
On Mar. 23, 2009, 16:06 +0200, Benny Halevy <bhalevy@panasas.com> wrote:
> On Mar. 23, 2009, 15:54 +0200, Thomas Rast <trast@student.ethz.ch> wrote:
>> Benny Halevy wrote:
>>> I'm hitting bad merges with (non interactive) git rebase
>>> when a hunk is merged pre-maturely into an inexact match
>>> when there's fuzz.
>> [...]
>>> { for i in {1..10}; do echo fuzz $i; done; echo; cat test_file; } > fuzz_file
>> [...]
>>> git rebase --onto test_branch master^ master
>> git-am, and by extension rebase, by default doesn't take history into
>> account. It just applies the patches "blindly". ...
git am, in contrast to git rebase, errs on fuzz and you'll need to
apply the patch manually. It might be annoying, but it'd be safer
if git rebase would either stop on fuzz too or revert to using
merge strategies (same as using git rebase -m) by default.
>> ... Thus, there's no way
>> to know which series of 'line N' you really wanted it to go onto.
Well, there's the hunk header.
Benny
>>
>> To avoid this issue, use the -m option to git-rebase so that it uses a
>> "real" merge. (You can achieve similar effects for git-am with the -3
>> option.)
>>
>
> OK. -m indeed helps and I'm certainly going to adopt it for my rebase scripts.
> git rebase -i does too, BTW.
>
> I would expect though that the default mode for automatic rebase would be
> the strictest and safest...
>
> Benny
> --
> 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: [RFC/PATCH 2/8] docbook: improve css style
From: Michael J Gruber @ 2009-03-23 15:20 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Jeff King, git
In-Reply-To: <94a0d4530903230331g3b620f80h77e317a09dc5273f@mail.gmail.com>
Felipe Contreras venit, vidit, dixit 23.03.2009 11:31:
> On Mon, Mar 23, 2009 at 8:42 AM, Jeff King <peff@peff.net> wrote:
>> On Sun, Mar 22, 2009 at 08:05:15PM +0200, Felipe Contreras wrote:
>>
>>> tt.literal, code.literal {
>>> color: navy;
>>> + font-size: 1em;
>>> +}
>>
>> Isn't 1em already the default size? Or are you trying to override some
>> other size specification elsewhere? It's hard to tell what the goal is
>> because your commit message merely says "improve".
>
> That's correct.
>
> The problem is that when the user has a different size for the
> sans-serif and monospace fonts it looks horrible when they are on the
> same paragraph. I thought 1em did the trick, but you are right, it
> doesn't.
>
> It looks like the only way to fix this is to set absolute sizes.
>
Also, it seems that everything which is not black is blue, except for
terms, which are green and slanted. I don't think that looks nice
together. How about slanted blue?
Michael
^ permalink raw reply
* Re: Importing Bzr revisions
From: David Reitter @ 2009-03-23 15:18 UTC (permalink / raw)
To: Pieter de Bie; +Cc: Junio C Hamano, git
In-Reply-To: <4123DB23-39C4-4651-A3B5-C7876A781365@frim.nl>
[-- Attachment #1: Type: text/plain, Size: 961 bytes --]
On Mar 23, 2009, at 10:18 AM, Pieter de Bie wrote:
>
> You might want to take a look at git-bzr (http://github.com/pieter/git-bzr/tree/master
> ) it allows incremental bidirectional interaction between git and
> bzr using the fast-export/import, so it might just work in your
> case. There are some issues with it, so you might want to check the
> 'network' part on github and use one of the other variants.
>
> That said, it's a 100 line script that hasn't been used much, so
> good luck :)
Thanks, this appears to be useful.
AFter reading your script, I tried incremental exports on the bzr
side: It still supports --import-marks and this seems to work quickly
enough for my small test project.
Could you update the documentation as to how to install the git-bzr
script?
(I searched for "plugin" in the git user manual, and google, and
didn't find anything. I haven't used git much, so I'm a bit naive as
regards to such a question.)
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]
^ permalink raw reply
* Re: [RFC/WIP 1/2] Documentation: fix minor inconsistency
From: Michael J Gruber @ 2009-03-23 14:56 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, Junio C Hamano
In-Reply-To: <vpq7i2g9u4m.fsf@bauges.imag.fr>
Matthieu Moy venit, vidit, dixit 23.03.2009 15:44:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> While we don't always write out commands in full (`git command`) we
>> should do it consistently in adjacent paragraphs.
>
>> - If set to true or "refuse", receive-pack will deny a ref update
>> + If set to true or "refuse", git-receive-pack will deny a ref update
>
> Then, shouldn't this be `git receive-pack` ?
It should be git-receive-pack in the first patch (adding missing git in
the same style as used there), `git-receive-pack` in the second patch
(implementation of step 1) and `git receive-pack` in step 2 (the
un-dashifying step), which comes later, just as outlined in the cover
letter. Mixing these steps into one patch would be a reviewing
nightmare. Squashing those two patches (constituting step 1 for the
first few files) would be fine.
Michael
^ permalink raw reply
* Re: [PATCH] difftool: add support for an extended revision syntax
From: Michael J Gruber @ 2009-03-23 14:51 UTC (permalink / raw)
To: David Aguilar; +Cc: gitster, git
In-Reply-To: <1237803348-9329-1-git-send-email-davvid@gmail.com>
David Aguilar venit, vidit, dixit 23.03.2009 11:15:
> This adds an extended revision syntax to git-difftool.
> Users often ask "how do I compare a file against its
> previous version" and the answer is typically a combination
> of 'git log <file>' and 'git difftool <sha1> <sha1> <file>'.
>
> This makes answering that question considerably easier.
> Users can now simply say:
>
> $ git difftool <file>~
>
> to compare <file> in the worktree against its
> previous version, and:
>
> $ git difftool <file>~2 <file>~
>
> to compare <file> from 2 versions ago to <file>'s
> previous version, etc.
>
> The extended revision syntax also expands revisions
> that are suffixed with '!' as a convenient way to
> see commit diffs. Specifying only '!' is equivalent
> to specifying 'HEAD!'.
>
> This makes the following statements equivalent:
>
> $ git difftool !
> $ git difftool HEAD!
> $ git difftool HEAD~ HEAD
>
> Signed-off-by: David Aguilar <davvid@gmail.com>
> ---
>
> This patch is based on top of the "add tests to difftool"
> patch which itself is based upon the "move difftool out of contrib"
> patch currently in the "pu" and "da/difftool" branches.
>
> This feature is incredibly useful but it also adds a brand new
> way of specifying revisions that is only understood by git-difftool.
>
> This was specifically asked for by a git-difftool user
> who was disapointed to learn that they had to dig through
> git-log just to use git-difftool effectively.
>
> I do not think git-diff should know anything about the
> "extended revision syntax" which is why this behavior
> is best suited for a porcelain such as difftool.
> I can imagine that 'file~' would be a useful construct
> in core git, but changing the plumbing just for something
> like that seems both daunting and misguided.
>
> Some of the conditional expressions were modified to match
> the style used in git-add--interactive.perl. I can split
> this patch into two if needed, but I figured they were
> trivial and didn't warrant a separate patch.
>
> I had to escape some tilde characters in the documentation
> because asciidoc kept generating invalid html when the
> {tilde} notation was used within single quotes multiple times.
>
> In case anyone asks, git-diff understands this new syntax too
> (though we did have to twist its arm ;))
>
> $ git config alias.ddiff 'difftool --no-ext-diff'
> $ git ddiff Makefile~
>
> Any thoughts on whether adding this syntax to git-diff/rev-parse
> would be feasible/sane/worth it?
I like the idea of having a shortcut like that a lot, but I'm sorry I'm
not supportive of a tool-specific rev syntax extension; for principal
reasons, but also because diff, checkout and maybe others could make
good use of it.
Work is underway on clearing out the issue of forbidden characters in
revision specifiers. We already have commit:file. I think something like
~2:file would be short enough as well as in line with the usual
semantics. Similarly,
git diff ~3 ~2 file
git diff ~3 file
would be short and simple as soon as ~3 is implemented to be a shortcut
for HEAD~3. (I'm not sure we can actually use ~, even though it would
fit in with the usual "if it's not specified it's HEAD".) This would
only need a shortcut for HEAD, such as not even specifying it (as above)
or c~ with c being our new fancy character for that.
> Documentation/git-difftool.txt | 55 ++++++++++++++++++-
> git-difftool.perl | 119 ++++++++++++++++++++++++++++++++++++++--
> t/t7800-difftool.sh | 43 ++++++++++++++
> 3 files changed, 210 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt
> index 5ae02f8..2911b84 100644
> --- a/Documentation/git-difftool.txt
> +++ b/Documentation/git-difftool.txt
> @@ -7,7 +7,9 @@ git-difftool - Show changes using common diff tools
>
> SYNOPSIS
> --------
> -'git difftool' [--tool=<tool>] [--no-prompt] [<'git diff' options>]
> +'git difftool' [--tool=<tool>] [--no-prompt]
> + [<'git diff' options>]
> + [<extended revision syntax>]
>
> DESCRIPTION
> -----------
> @@ -54,6 +56,57 @@ with custom merge tool commands and has the same value as `$LOCAL`.
>
> See linkgit:git-diff[1] for the full list of supported options.
>
> +EXTENDED REVISION SYNTAX
> +------------------------
> +'git-difftool' understands an extended syntax for specifying revisions.
> +
> +* A suffix '{tilde}' to a file means the previous commit that touched file.
> +
> +* A suffix '{tilde}<n>' to a file means the <n>th previous commit that
> +touched file. E.g. 'file\~3' is equivalent to 'file\~\~\~'.
> +
> +* A revision suffixed with an exclamation mark '!' expands to
> +'revision\~..revision', i.e. the commit diff for that revision.
> +
> +'git-difftool' recognizes this syntax and passes the corresponding
> +commits to 'git-diff'.
> +
> +Examples
> +~~~~~~~~
> +
> +---------------------------------------------------
> +# File Revision Specifiers
> +$ git difftool Makefile~2 <1>
> +$ git difftool Makefile~4 Makefile~2 <2>
> +$ git difftool Makefile~~~~ Makefile~~ <3>
> +
> +# Commit Diff Specifiers
> +$ git difftool origin/next~! <4>
> +$ git difftool HEAD! <5>
> +$ git difftool ! <6>
> +---------------------------------------------------
> +
> +<1> compare 'Makefile' in the worktree against 'Makefile'
> +as it existed two `versions` ago. `Versions` here means
> +"changes to Makefile" such that only commits that touch
> +'Makefile' are considered when finding commits.
> +
> +<2> compare 'Makefile' as it existed four versions ago to
> +'Makefile' as it existed two versions ago.
> +
> +<3> equivalent to example 2 and illustrates what happens when
> +multiple '{tilde}' characters are used.
> +
> +<4> show the commit diff for 'origin/next\~'.
> +Specifying '!' expands 'origin/next\~' to
> +'origin/next\~\~..origin/next\~'.
> +
> +<5> show the commit diff for the most recent commit.
> +'HEAD!' is equivalent to 'HEAD\~..HEAD'.
> +
> +<6> '!' is a shorthand for 'HEAD!' and is equivalent to example 5.
> +
> +
> CONFIG VARIABLES
> ----------------
> 'git-difftool' falls back to 'git-mergetool' config variables when the
> diff --git a/git-difftool.perl b/git-difftool.perl
> index 0deda3a..4845f9b 100755
> --- a/git-difftool.perl
> +++ b/git-difftool.perl
> @@ -12,13 +12,17 @@ use warnings;
> use Cwd qw(abs_path);
> use File::Basename qw(dirname);
>
> +binmode(STDOUT, ":raw");
> +
> my $DIR = abs_path(dirname($0));
>
>
> sub usage
> {
> print << 'USAGE';
> -usage: git difftool [--tool=<tool>] [--no-prompt] ["git diff" options]
> +usage: git difftool [--tool=<tool>] [--no-prompt]
> + [<'git diff' options>]
> + [<extended revision specifier>]
> USAGE
> exit 1;
> }
> @@ -33,12 +37,18 @@ sub setup_environment
> sub exe
> {
> my $exe = shift;
> - return defined $ENV{COMSPEC} ? "$exe.exe" : $exe;
> + if ($^O eq 'MSWin32' || $^O eq 'msys') {
> + return "$exe.exe";
> + }
> + return $exe;
> }
>
> sub generate_command
> {
> + # Generate a git-diff command line and set environment
> + # variables recognized by git-difftool-helper
> my @command = (exe('git'), 'diff');
> + my @args = ();
> my $skip_next = 0;
> my $idx = -1;
> for my $arg (@ARGV) {
> @@ -47,7 +57,7 @@ sub generate_command
> $skip_next = 0;
> next;
> }
> - if ($arg eq '-t' or $arg eq '--tool') {
> + if ($arg eq '-t' || $arg eq '--tool') {
> usage() if $#ARGV <= $idx;
> $ENV{GIT_DIFF_TOOL} = $ARGV[$idx + 1];
> $skip_next = 1;
> @@ -61,12 +71,109 @@ sub generate_command
> $ENV{GIT_DIFFTOOL_NO_PROMPT} = 'true';
> next;
> }
> - if ($arg eq '-h' or $arg eq '--help') {
> + if ($arg eq '-h' || $arg eq '--help') {
> usage();
> }
> - push @command, $arg;
> + push @args, $arg;
> + }
> + return (@command, interpolate_args(@args));
> +}
> +
> +
> +sub interpolate_args
> +{
> + # Interpolates arguments that should be expanded out to
> + # corresponding commits, e.g. 'file~3' or 'master!'.
> + my @args = @_;
> + my $file = undef;
> + my @command = ();
> + for my $arg (@args) {
> + if (defined $file && $arg eq $file) {
> + # This allows 'git difftool file~ file'
> + next;
> + }
> + if ($arg =~ /^(.+?)(~+\d*)$/) {
> + # This arg might be a file-revision specifier
> + my $cur_file = $1;
> + my $rev_spec = $2;
> + if (defined $file && $file ne $cur_file) {
> + # We don't currently support comparing
> + # file~ to other_file~
> + usage();
> + }
> + if (!-e $cur_file) {
> + # This arg is a revision parameter and should
> + # be passed along to git-diff as-is
> + push @command, $arg;
> + next;
> + }
> + # This arg is a file-revision specifier so find the
> + # corresponding commits
> + $file = $cur_file;
> + push @command,
> + find_commit_for_file($cur_file, $rev_spec);
> + }
> + elsif ($arg =~ /^(.*?)!$/) {
> + # Expand 'sha1!' to 'sha1~ sha1'
> + my $head = $1;
> + if (length($head) == 0) {
> + # Expand '!' to 'HEAD~ HEAD'
> + $head = 'HEAD';
> + }
> + push @command, $head.'~';
> + push @command, $head;
> + }
> + else {
> + # This is a regular arg so just pass it along
> + push @command, $arg;
> + }
> + }
> + if (defined $file) {
> + # We're using a 'file~' revision specifier so
> + # automatically limit git-diff to just a single file
> + $ENV{GIT_DIFFTOOL_NO_PROMPT} = 'true';
> + push @command, '--', $file;
> + }
> + return @command;
> +}
> +
> +sub find_commit_for_file
> +{
> + # Searches back in $file's history according to $rev_spec
> + # and finds the corresponding commits.
> + # $rev_spec usually looks like '~' or '~2'.
> + my ($file, $rev_spec) = @_;
> + my $num = 0;
> + if ($rev_spec =~ /^(~+)(\d+)$/) {
> + $num = length($1);
> + $num += $2;
> + }
> + else {
> + $num = 1;
> + $num += length($rev_spec);
> + }
> + my @cmd = (exe('git'), 'log');
> + my @opts = ('--reverse', '--pretty=format:%H', '--max-count='.$num);
> + my @args = ('--', $file);
> + return read_first_line(@cmd, @opts, @args);
> +}
> +
> +sub read_first_line
> +{
> + # Runs a command in a child process and returns the first line
> + my @command = @_;
> + my $pid = open(CHILD, '-|');
> + if ($pid) {
> + # Grab the first line and loop over stdout until we're done
> + my $line = <CHILD>;
> + while(<CHILD>) {};
> + close(CHILD);
> + chomp $line;
> + return $line;
> + } else {
> + # Execute the command and pipe output to our parent
> + exec(@command) or exit 1;
> }
> - return @command
> }
>
> setup_environment();
> diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh
> index c7cd2b1..88af30a 100755
> --- a/t/t7800-difftool.sh
> +++ b/t/t7800-difftool.sh
> @@ -136,4 +136,47 @@ test_expect_success 'difftool + mergetool config variables' '
> restore_test_defaults
> '
>
> +test_expect_success 'extended file revision syntax' '
> + git checkout branch &&
> +
> + diff=$(git difftool file~) &&
> + test "$diff" = "master" &&
> +
> + diff=$(git difftool file~ file) &&
> + test "$diff" = "master" &&
> +
> + echo branch 2 >file &&
> + git commit -a -m "branch changes again" &&
> +
> + diff=$(git difftool file~~ file) &&
> + test "$diff" = "master" &&
> +
> + diff=$(git difftool file~2 file) &&
> + test "$diff" = "master" &&
> +
> + git reset --hard HEAD~ &&
> + git checkout master
> +'
> +
> +test_expect_success 'extended commit-ish revision syntax' '
> + git checkout branch &&
> +
> + diff=$(git difftool --no-prompt HEAD!) &&
> + test "$diff" = "master" &&
> +
> + diff=$(git difftool --no-prompt !) &&
> + test "$diff" = "master" &&
> +
> + echo branch again >file &&
> + git commit -a -m "branch again" &&
> + git checkout master &&
> +
> + diff=$(git difftool --no-prompt branch!) &&
> + test "$diff" = "branch" &&
> +
> + git checkout branch &&
> + git reset --hard HEAD~ &&
> + git checkout master
> +'
> +
> test_done
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox