* Re: [RFC] Git User's Survey 2007
From: David Kastrup @ 2007-07-30 19:26 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: Jakub Narebski, git
In-Reply-To: <4d8e3fd30707300044l79133442of45b37a8192f7bca@mail.gmail.com>
"Paolo Ciarrocchi" <paolo.ciarrocchi@gmail.com> writes:
> Fine with me. Thanks for you work Jakub.
>
> Just a general comment, let's try to avoid as much as possible
> multiple questions in a single question. It tends to confuse people
> when they are answering to the survey.
I find that the survey lacking in community questions, like
Do you frequently read the mailing list?
Frequently post?
Other sources of information?
How helpful are the answers you get there?
How pleasant is the atmosphere?
And so on.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [GUILT PATCH 0/4] Add guards to guilt
From: Josef Sipek @ 2007-07-30 19:20 UTC (permalink / raw)
To: Eric Lesh; +Cc: jsipek, git
In-Reply-To: <873az6cmve.fsf@hubert.paunchy.net>
On Mon, Jul 30, 2007 at 01:32:53AM -0700, Eric Lesh wrote:
> Josef Sipek <jsipek@fsl.cs.sunysb.edu> writes:
>
> >
> > I know I've been bad about forcing even myself to write new regression
> > tests. Your patches modify things significantly enough, that I'd like to see
> > some regression tests cases to make sure that user's data is not eaten
> > (e.g., a bug in the guard setting code could blow away the series file =>
> > very bad).
> >
>
> Yeah, I'll try and make one. 070-guards.sh to test guilt-guard and
> guilt-select plus pushing and popping?
Sounds good.
> There's also sed -i in a few places. For integrity purposes, are a cp
> and sed better?
I like the fact that sed -i makes the code cleaner, BUT I don't want the
users to come after me if they patches disappear. Perhaps having a wrapper
(a function) for sed that's nicely paranoid and handles errors as well as
possible would be in order:
safe_sed [<sed options...>]
> > Is this a problem with other projects' implementations of guards as well?
> > Perhaps printing a warning if a new guard is set when there are applied
> > patches would be in order?
> >
>
> Yeah, they have this problem too,
Good :)
> but tell you so when you select, so guilt should too.
Agreed.
> Mercurial also has two options which do the popping and reapplying for
> you, which I'll try and implement also.
As in:
t=`guilt-top`
guilt-pop -a
guilt-push "$t"
? Beware that "$t" might not be in the new guarded series.
> Thanks a lot for the review. Things were pretty ugly, but with your
> help it should look much better.
Nah...just a few nit-picks, that's all :)
Josef 'Jeff' Sipek.
--
I think there is a world market for maybe five computers.
- Thomas Watson, chairman of IBM, 1943.
^ permalink raw reply
* Re: [GUILT PATCH] guilt-header: Add -e option for editing
From: Josef Sipek @ 2007-07-30 19:09 UTC (permalink / raw)
To: Eric Lesh; +Cc: Josef Sipek, Git mailing list
In-Reply-To: <87r6mqarkb.fsf@hubert.paunchy.net>
On Mon, Jul 30, 2007 at 07:34:28AM -0700, Eric Lesh wrote:
> Signed-off-by: Eric Lesh <eclesh@ucla.edu>
> ---
> Documentation/guilt-header.txt | 6 ++++--
> guilt | 9 +++++++++
> guilt-header | 20 +++++++++++++++++---
> 3 files changed, 30 insertions(+), 5 deletions(-)
Applied. Right after applying your patch, I decided to clean things up a
bit. This includes removal of the scan of the series => not needed as we
already know the patch name anyway.
Thanks,
Josef 'Jeff' Sipek.
--
I already backed up the [server] once, I can do it again.
^ permalink raw reply
* Re: Efficient way to import snapshots?
From: Linus Torvalds @ 2007-07-30 18:56 UTC (permalink / raw)
To: Craig Boston; +Cc: git
In-Reply-To: <20070730180710.GA64467@nowhere>
On Mon, 30 Jul 2007, Craig Boston wrote:
>
> So far the main snag I've found is that AFAIK there's no equivalent to
> "svk import" to load a big tree (~37000 files) into a branch and commit
> the changes. Here's the procedure I've come up with:
>
> cd /path/to/git/repo
> git checkout vendor_branch_X
> git rm -r .
> cp -R /path/to/cvs/checkout_X/* ./
> git add .
> git commit -m"Import yyyymmdd snapshot"
Ouch.
What you want to do should fit git very well, but doing it that way is
quite expensive.
Might I suggest just doing the .git thing *directly* in the CVS checkout
instead?
It should literally be as easy as doing something like
cd /path/to/cvs/checkout_X
export GIT_DIR=/path/to/git/repo
git add .
git commit -m"Import yyyymmdd snapshot"
and you never copy anything around, and git will just notice on its own
what CVS has changed.
You'd have to make sure that you have the CVS directories ignored, of
course, and if you don't want to change the CVS directory at all (which is
a good idea!) you'd need to do that by using the "ignore" file in your
GIT_DIR, and just having the CVS entry there, instead of adding a
".gitignore" file to the working tree and checking it in.
The first time you do this it will be expensive, since it will re-compute
all the SHA1's in the .git/index file, but afterwards, it will be able to
use the index file to speed up operation, which is what is going to make
this all *much* cheaper than removing the old files and copying all the
files around anew.
(You can just force the re-indexing by doing a "git status" once, ie do
cd /path/to/cvs/checkout_X
export GIT_DIR=/path/to/git/repo
git status
which will do it for you, and now all the subsequent snapshot generation
should be trivial and very fast).
The above is totally untested, of course, but I think that's the easiest
way to do things like this. In general, it should be *trivial* to do
snapshots with git using just about _any_ legacy SCM, exactly because you
can keep the whole git setup away from the legacy SCM directories with
that "GIT_DIR=.." thing.
(Of course, you could just move the .git directory into the CVS checkout
too - and then CVS will just ignore it. But it may be a good idea to just
keep them explicitly separate).
Linus
^ permalink raw reply
* Re: [PATCH] add series editor support.
From: Josef Sipek @ 2007-07-30 18:27 UTC (permalink / raw)
To: Dmitry Monakhov; +Cc: Josef Jeff Sipek, git
In-Reply-To: <20070730100512.GA14637@dnb.sw.ru>
On Mon, Jul 30, 2007 at 02:05:12PM +0400, Dmitry Monakhov wrote:
> Usually we have to edit series file directly (via editor).
> I think it is not bad idea to let guilt export this service.
> IMHO "guilt-series -e" it the best way to do it.
>
> Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Applied with a small cleanup to make things a little bit more consistent (
[ ! -z "$edit" ] vs. [ "$edit" = "t" ] ).
Thanks,
Josef 'Jeff' Sipek.
--
Failure is not an option,
It comes bundled with your Microsoft product.
^ permalink raw reply
* Efficient way to import snapshots?
From: Craig Boston @ 2007-07-30 18:07 UTC (permalink / raw)
To: git
Hello, I'm seeking some input from git users/developers to try and solve
a problem I'm encountering. I'm new with git, having used quite a bit
of Subversion and SVK in the past, but have heard good things and
decided to give it a try.
First, a little bit about what I'm trying to accomplish. There is a
large source tree -- FreeBSD to be specific -- which is maintained in
CVS. I want to have several local branches where I can develop specific
projects. Each of these branches should derive from either the HEAD of
the CVS tree, or from one of the release branches (known as the -STABLE
branch for a particular version of the OS).
That said, I really don't want to have to import the entire CVS
repository. It has many, many branches and tags that I'm not interested
in, and I really don't need the entire history of the project. I don't
even really need individual commit history. I can see that easily enough
on cvsweb. Repo size is a big factor as I need to replicate it between
several different work machines, some of which don't have unlimited disk
space.
What I'm currently doing (using SVK) is nightly, taking a snapshot using
cvsup of each of the 3 branches that I care about, then using "svk
import" to pull the snapshot into a local branch that I treat as a
vendor branch. My projects are branched off those and I regularly
smerge changes over. It works pretty well for me, the only downside is
that svk isn't exactly fast, having to load lots of perl modules for
every command.
I'd like to do something similar with git -- I like the idea of it
having many less dependencies that must be installed, and it's supposed
to be quite a bit faster when dealing with working copies. From reading
about it I think it may also be easier to generate diffs of my branches
from their origins.
So far the main snag I've found is that AFAIK there's no equivalent to
"svk import" to load a big tree (~37000 files) into a branch and commit
the changes. Here's the procedure I've come up with:
cd /path/to/git/repo
git checkout vendor_branch_X
git rm -r .
cp -R /path/to/cvs/checkout_X/* ./
git add .
git commit -m"Import yyyymmdd snapshot"
However this has quite a few disadvantages when compared to svk. The
first is that I have to checkout into a working directory and then copy
the files from the cvs checkout. It is also considerably slower than
svk import, about 7-8 times on average. When there are a lot of
changes I've seen the git process use upwards of 1GB of memory; it
actually died the first time I tried it because I didn't have any swap
configured.
Now, I don't have very much experience with git, so for my question: Is
there a better way to do this? Either importing a lot of files into
git, or a better solution for that I'm trying to do.
Any pointers would be much appreciated.
Thanks!
Craig
^ permalink raw reply
* Re: "git stash" is not known to git
From: Junio C Hamano @ 2007-07-30 17:52 UTC (permalink / raw)
To: Jeff King; +Cc: git, David Kastrup, Linus Torvalds
In-Reply-To: <20070730100408.GA8829@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On a related note, is it just me, or is the following comment and related code
> in git.c (introduced by Linus in 231af832) totally bogus:
>
> /*
> * We search for git commands in the following order:
> * - git_exec_path()
> * - the path of the "git" command if we could find it
> * in $0
> * - the regular PATH.
> */
>
> We never actually look in the regular PATH since we call execv_git_cmd
> (although we do still munge the PATH, apparently so shell scripts can
> use git-foo syntax; see 77cb17e9). This means you can't drop "git-foo"
> into your PATH and have it work as "git foo".
>
> What is the desired behavior?
I failed to spot patches to the area without updating the
comment. What the code does is fine, the comment is stale.
^ permalink raw reply
* Re: merge time
From: Linus Torvalds @ 2007-07-30 17:42 UTC (permalink / raw)
To: Jeff King
Cc: david, Steffen Prohaska, Shawn O. Pearce, Junio C Hamano,
Matthew L Foster, git
In-Reply-To: <20070730084138.GA4100@coredump.intra.peff.net>
On Mon, 30 Jul 2007, Jeff King wrote:
>
> If you followed a strict policy of always merging topics to a "base"
> branch as your first parent, then never allowing fast forwards should
> allow a very easy-to-read history in gitk.
Only if only *one* person ever does any merges.
Immediately when you have other people merging code, you're now back in
the same boat.
This is why I personally think the whole policy of "no fast forward" is
totally broken. It's only usable in a non-distributed environment, where
there is one central person who does everythng (a so-called "star
topology").
Linus
^ permalink raw reply
* Re: merge time
From: david @ 2007-07-30 17:33 UTC (permalink / raw)
To: Matthew L Foster; +Cc: Linus Torvalds, git
In-Reply-To: <104942.93033.qm@web51008.mail.re2.yahoo.com>
On Mon, 30 Jul 2007, Matthew L Foster wrote:
> --- david@lang.hm wrote:
>
>> On Mon, 30 Jul 2007, Matthew L Foster wrote:
>>> Local commit order is stored locally right?
>>
>> not normally. you could enable reflogs and then mine through the reflogs
>> to find the info, but it's not stored in any easy to access fashion.
>
> Local merge order can be extracted from git?
if you have reflogs enabled on your copy of the git repository then you
can look at when things were merged into your copy.
David Lang
^ permalink raw reply
* Re: merge time
From: david @ 2007-07-30 17:13 UTC (permalink / raw)
To: Matthew L Foster; +Cc: Rogan Dawes, Git Mailing List
In-Reply-To: <28948.8052.qm@web51002.mail.re2.yahoo.com>
On Mon, 30 Jul 2007, Matthew L Foster wrote:
> --- Rogan Dawes <lists@dawes.za.net> wrote:
>
>> And also keep in mind that on the command line you can invoke a lot of
>> "plumbing commands" that you certainly wouldn't expect to be exposed in
>> a web interface.
>
> If the web interface requires logins over https why can't plumbing commands be exposed to the web?
> Though I agree not everything needs to be webified. What I envision is a wikipedia style interface
> front end with git remaining the backend so you can more easily browse the file system and see
> history and diff the way you can on Wikipedia. But that idea is very separate from my concern that
> right now gitweb.cgi effectively has a bug in it because it sorts using external/superset commit
> order/time rather than local commit order which causes changes to appear as if they were made
> before they were really merged locally.
what you are asking for would be a very useful piece of software, but
that's very different from the current gitweb. you are fileing a bug about
the software doing what it was designed to do. yes, it could be done
differently. yes, that would be useful. but the software to do so is
mostly a new product, not a simple tweak to the existing gitweb software.
right now gitweb isn't designed for figuring out what was merged when,
it's just for retreiving specific versions.
if someone really wanted to do this, the right answer may be to take the
concept of gitk and webify it (think SVG for the graphics and AJAX
interfaces to retreive the info as needed). I think this would be a very
useful tool, but it would be a lot of work to implement.
but without the graph showing the commits and how they are related to each
other, you really are crippled in your ability to figure out how things
are related to each other. Date order just doesn't cut it.
David Lang
^ permalink raw reply
* Re: merge time
From: Matthew L Foster @ 2007-07-30 17:11 UTC (permalink / raw)
To: david; +Cc: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.64.0707300922420.11330@asgard.lang.hm>
--- david@lang.hm wrote:
> On Mon, 30 Jul 2007, Matthew L Foster wrote:
> > Local commit order is stored locally right?
>
> not normally. you could enable reflogs and then mine through the reflogs
> to find the info, but it's not stored in any easy to access fashion.
Local merge order can be extracted from git?
-Matt
____________________________________________________________________________________
Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list&sid=396545433
^ permalink raw reply
* Re: merge time
From: Matthew L Foster @ 2007-07-30 17:06 UTC (permalink / raw)
To: Rogan Dawes; +Cc: Git Mailing List
In-Reply-To: <46AE1100.2020005@dawes.za.net>
--- Rogan Dawes <lists@dawes.za.net> wrote:
> And also keep in mind that on the command line you can invoke a lot of
> "plumbing commands" that you certainly wouldn't expect to be exposed in
> a web interface.
If the web interface requires logins over https why can't plumbing commands be exposed to the web?
Though I agree not everything needs to be webified. What I envision is a wikipedia style interface
front end with git remaining the backend so you can more easily browse the file system and see
history and diff the way you can on Wikipedia. But that idea is very separate from my concern that
right now gitweb.cgi effectively has a bug in it because it sorts using external/superset commit
order/time rather than local commit order which causes changes to appear as if they were made
before they were really merged locally.
-Matt
____________________________________________________________________________________
Pinpoint customers who are looking for what you sell.
http://searchmarketing.yahoo.com/
^ permalink raw reply
* Re: merge time
From: Rogan Dawes @ 2007-07-30 16:25 UTC (permalink / raw)
To: Matthew L Foster; +Cc: Git Mailing List
In-Reply-To: <78813.86273.qm@web51002.mail.re2.yahoo.com>
Matthew L Foster wrote:
> Maybe I am the only one that thinks the web interface should be just as feature rich as the
> command line interface?
>
> -Matt
>
Well, having said that "Use reflogs" was the general response, I don't
think that anyone ever really followed through and made it a readily
accessible feature, even on the command line.
That is, the reflogs are readily accessible, but noone made it possible
to link them to the commits in such a way that the dates/times change as
you seem to desire.
Of course, you can do things like:
$ git show HEAD@{2.days.ago}
to see what HEAD looked like 2 days ago, but you can't do things like
get gitk to show you that this tag only appeared in your repo 2 days ago.
(Keep in mind, of course, that reflogs are referring to YOUR local copy
of the git repo, not what HEAD was on the server that you cloned from.)
And also keep in mind that on the command line you can invoke a lot of
"plumbing commands" that you certainly wouldn't expect to be exposed in
a web interface.
Rogan
^ permalink raw reply
* Re: merge time
From: david @ 2007-07-30 16:23 UTC (permalink / raw)
To: Matthew L Foster; +Cc: Linus Torvalds, git
In-Reply-To: <153733.59721.qm@web51006.mail.re2.yahoo.com>
On Mon, 30 Jul 2007, Matthew L Foster wrote:
> --- david@lang.hm wrote:
>
>> if you clone your tree and merge from mine, and I clone my tree and merge
>> from yours, the result of both merges _must_ be the same there will be
>> trouble when we both try and merge with tree C later on.
>>
>> another thing is that a given commit cannot be changed once it's created
>> (if it was changed it wouldn't have the same sha1 value) so you can't just
>> go around changeing dates on commits that took place elsewhere.
>
> Local commit order is stored locally right?
not normally. you could enable reflogs and then mine through the reflogs
to find the info, but it's not stored in any easy to access fashion.
David Lang
> From looking at gitweb on kernel.org it seems all the
> info is already there, a merge has a list of commits in that merge and they should be displayed in
> local commit order rather than external creation time order.
>
> -Matt
>
>
>
>
> ____________________________________________________________________________________Ready for the edge of your seat?
> Check out tonight's top picks on Yahoo! TV.
> http://tv.yahoo.com/
>
^ permalink raw reply
* Re: merge time
From: Matthew L Foster @ 2007-07-30 16:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Rogan Dawes, git
In-Reply-To: <Pine.LNX.4.64.0707301719450.14781@racer.site>
--- Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Maybe I am the only one that thinks the web interface should be just as
> > feature rich as the command line interface?
>
> *lol* I would be _nice_. But frankly, how do you want to get the power
> of the command line into a website, _without_ reproducing a command line?
> I can _script_ the command line, for example.
Creating a webified command line is a perfectly fine solution towards making gitweb.cgi as full
featured as git is.
-Matt
____________________________________________________________________________________
Shape Yahoo! in your own image. Join our Network Research Panel today! http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7
^ permalink raw reply
* Re: merge time
From: Johannes Schindelin @ 2007-07-30 16:20 UTC (permalink / raw)
To: Matthew L Foster; +Cc: Rogan Dawes, git
In-Reply-To: <78813.86273.qm@web51002.mail.re2.yahoo.com>
Hi,
On Mon, 30 Jul 2007, Matthew L Foster wrote:
> Maybe I am the only one that thinks the web interface should be just as
> feature rich as the command line interface?
*lol* I would be _nice_. But frankly, how do you want to get the power
of the command line into a website, _without_ reproducing a command line?
I can _script_ the command line, for example.
Ciao,
Dscho
^ permalink raw reply
* Re: merge time
From: Matthew L Foster @ 2007-07-30 16:20 UTC (permalink / raw)
To: david; +Cc: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.64.0707292114120.6510@asgard.lang.hm>
--- david@lang.hm wrote:
> if you clone your tree and merge from mine, and I clone my tree and merge
> from yours, the result of both merges _must_ be the same there will be
> trouble when we both try and merge with tree C later on.
>
> another thing is that a given commit cannot be changed once it's created
> (if it was changed it wouldn't have the same sha1 value) so you can't just
> go around changeing dates on commits that took place elsewhere.
Local commit order is stored locally right? From looking at gitweb on kernel.org it seems all the
info is already there, a merge has a list of commits in that merge and they should be displayed in
local commit order rather than external creation time order.
-Matt
____________________________________________________________________________________Ready for the edge of your seat?
Check out tonight's top picks on Yahoo! TV.
http://tv.yahoo.com/
^ permalink raw reply
* Re: merge time
From: Matthew L Foster @ 2007-07-30 16:14 UTC (permalink / raw)
To: Rogan Dawes; +Cc: git
In-Reply-To: <46ADDD3B.3000806@dawes.za.net>
Maybe I am the only one that thinks the web interface should be just as feature rich as the
command line interface?
-Matt
____________________________________________________________________________________
Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games.
http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow
^ permalink raw reply
* [PATCH] user-manual: mention git gui citool (commit, amend)
From: Steffen Prohaska @ 2007-07-30 16:11 UTC (permalink / raw)
To: git; +Cc: Steffen Prohaska
git gui is especially useful because it allows to select diff hunks.
Now it is at least mentioned in the user-manual.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
Documentation/user-manual.txt | 21 ++++++++++++++++++++-
1 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 0071cd0..de4ec0b 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1079,6 +1079,24 @@ $ git diff HEAD # difference between HEAD and working tree; what
$ git status # a brief per-file summary of the above.
-------------------------------------------------
+Another approach for creating commits is git gui:
+
+-------------------------------------------------
+$ git gui citool
+-------------------------------------------------
+
+starts the commit tool (Note, "`git gui`" starts the full gui, which
+provides more options).
+
+Beyond the basic operation of staging and unstaging complete files,
+git gui can also selectively stage diff hunks. You can do so by
+selecting a modified or staged file and right-click on the diff view
+in the lower part of the gui. A pop-up will appear that lets you
+select a specific hunk and stage or unstage it for the next commit.
+This is particular useful for slicing large, ugly commits into smaller
+pieces, for example when cherry-picking (see
+<<reordering-patch-series>>).
+
[[creating-good-commit-messages]]
Creating good commit messages
-----------------------------
@@ -2480,7 +2498,8 @@ $ gitk origin..mywork &
And browse through the list of patches in the mywork branch using gitk,
applying them (possibly in a different order) to mywork-new using
cherry-pick, and possibly modifying them as you go using commit
---amend.
+--amend. git gui may be especially useful to amend commits as it
+lets you selectively stage and unstage single diff hunks.
Another technique is to use git-format-patch to create a series of
patches, then reset the state to before the patches:
--
1.5.3.rc3.122.g4978
^ permalink raw reply related
* [GUILT PATCH] guilt-header: Add -e option for editing
From: Eric Lesh @ 2007-07-30 14:34 UTC (permalink / raw)
To: Josef Sipek; +Cc: Git mailing list
Signed-off-by: Eric Lesh <eclesh@ucla.edu>
---
| 6 ++++--
guilt | 9 +++++++++
| 20 +++++++++++++++++---
3 files changed, 30 insertions(+), 5 deletions(-)
--git a/Documentation/guilt-header.txt b/Documentation/guilt-header.txt
index ed9ab34..d432959 100644
--- a/Documentation/guilt-header.txt
+++ b/Documentation/guilt-header.txt
@@ -11,10 +11,12 @@ include::usage-guilt-header.txt[]
DESCRIPTION
-----------
-Prints either the topmost patches' header or the header of a specified patch.
+Prints either the topmost patch's header or the header of a specified patch.
+-e::
+ Open the header in an editor, instead of printing it.
<patchname>::
- Name of the patch.
+ Name of the patch.
Author
------
diff --git a/guilt b/guilt
index f67bfb5..7f2b93c 100755
--- a/guilt
+++ b/guilt
@@ -209,6 +209,15 @@ do_make_header()
'
}
+# usage: do_get_patch patchfile
+do_get_patch()
+{
+ cat "$1" | awk '
+BEGIN{}
+/^(diff|---)/,/END{}/
+'
+}
+
# usage: do_get_header patchfile
do_get_header()
{
--git a/guilt-header b/guilt-header
index d07e2be..496cb5b 100755
--- a/guilt-header
+++ b/guilt-header
@@ -3,13 +3,18 @@
# Copyright (c) Josef "Jeff" Sipek, 2006, 2007
#
-USAGE="[<patchname>]"
+USAGE="[-e] [<patchname>]"
. `dirname $0`/guilt
-if [ $# -gt 1 ]; then
+if [ $# -gt 2 ]; then
usage
fi
+if [ "$1" = "-e" ]; then
+ edit=t
+ shift
+fi
+
patch="$1"
if [ -z "$patch" ]; then
@@ -34,6 +39,15 @@ for p in `get_series`; do
[ $idx -lt $eidx ] && continue
[ $idx -gt $eidx ] && break
- do_get_header $GUILT_DIR/$branch/$p
+ if [ -z "$edit" ]; then
+ do_get_header $GUILT_DIR/$branch/$p
+ else
+ do_get_full_header $GUILT_DIR/$branch/$p > /tmp/guilt.msg.$$
+ do_get_patch $GUILT_DIR/$branch/$p > /tmp/guilt.diff.$$
+ $editor "/tmp/guilt.msg.$$"
+ mv $GUILT_DIR/$branch/$p $GUILT_DIR/$branch/$p~
+ cat /tmp/guilt.msg.$$ > $GUILT_DIR/$branch/$p
+ cat /tmp/guilt.diff.$$ >> $GUILT_DIR/$branch/$p
+ fi
done
--
1.5.2
^ permalink raw reply related
* Re: [git gui] Update to it.po pushed to the mob branch
From: Paolo Ciarrocchi @ 2007-07-30 13:51 UTC (permalink / raw)
To: Michael; +Cc: git
In-Reply-To: <200707301057.08078.barra_cuda@katamail.com>
On 7/30/07, Michael <barra_cuda@katamail.com> wrote:
> On Sunday 29 July 2007 20:26, Paolo Ciarrocchi wrote:
> > I've just updated the Italian translation of git-gui
> > and pushed it into mob branch.
>
> I've just updated your update :). The translation is mostly
> complete (although quite rough). The only things left
> are related to "fast forward merge" and "tracking branch":
> I don't know how to translate these...
Thank you Michael, very appreciated!
I'll pull and check your work.
As you noticed there are some sentences that probably should remain in
english, I'll polish the translation using git gui in Italian ;-)
> I hope I didn't mess up some of your translations... :)
I don't think so ;-)
Again, thank you!
Ciao,
--
Paolo
"Tutto cio' che merita di essere fatto,merita di essere fatto bene"
Philip Stanhope IV conte di Chesterfield
^ permalink raw reply
* Re: (Resend)[PATCH] git-svn: Translate invalid characters in refname
From: Robert Ewald @ 2007-07-30 13:33 UTC (permalink / raw)
To: git
In-Reply-To: <7v6442kxvu.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Robert Ewald <robert.ewald@nov.com> writes:
>
>> +sub refname {
>> + my ($refname) = "refs/remotes/$_[0]->{ref_id}" ;
>> +
>> + # It cannot end with a slash /, we'll throw up on this because
>> + # SVN can't have directories with a slash in their name, either:
>> + if ($refname =~ m{/$}) {
>> + die "ref: '$refname' ends with a trailing slash, this is ",
>> + "not permitted by git nor Subversion\n";
>> + }
>> +
>> + # It cannot have ASCII control character space, tilde ~, caret ^,
>> + # colon :, question-mark ?, asterisk *, space, or open bracket [
>> + # anywhere.
>> + #
>> + # Additionally, % must be escaped because it is used for escaping
>> + # and we want our escaped refname to be reversible
>> + $refname =~ s{([ \%~\^:\?\*\[\t])}{uc sprintf('%%%02x',ord($1))}eg;
>
> uc of sprintf()? You meant "%%%02X"?
You are right. Being a total Perl noob I just took Eric's suggestion from an
earlier post without really understanding everything.
> Other than that, looks sane to me. I presume that SVN branches
> whose name would be mangled with this patch would not have been
> successfully imported with older git-svn anyway, so this won't
> introduce any regressions?
Now that you mention it, I am not entirely sure. We introduce the % which is
mangled as well. It wasn't mangled before.
I now could think of a case that someone has a git-svn branch with a % in the
name checked out.
When updates are fetched a new branch head would be created. It wouldn't
destroy anything, but a script might break. On the other hand, the script needs
to be updated anyway. So I am not sure if % should be handled separately.
> Eric?
Yes, Eric, please comment.
--
Robert Ewald
^ permalink raw reply
* Re: Arbitrary long file lists?
From: David Kastrup @ 2007-07-30 13:18 UTC (permalink / raw)
To: git
In-Reply-To: <81b0412b0707300543p48964b73o5f972405645e70e9@mail.gmail.com>
"Alex Riesen" <raa.lkml@gmail.com> writes:
> On 7/30/07, David Kastrup <dak@gnu.org> wrote:
>> commands like git-archive take a file list on the command line. If
>> the number of files does no longer fit the argv limitations, this
>> causes a problem.
>>
>> So it might be nice to be able to treat some "filenames" in a file
>> list special:
>>
>> -@=filename (read LF-lines with filenames from filename)
>> -@=- (read lines with filenames from stdin)
>> -@z=filename (read NUL-terminated list with filenames from filename)
>> -@z=- (same from stdin)
>
> git-update-index and the like use --stdin and -z.
> What do you need the one with filename for?
Uh, git-archive?
I was thinking that -z could conflict with other uses for in/output,
but indeed git-archive does not seem to have any other area that would
be affected by -z.
So this request at the current point of time can be reduced to let
git-archive have --stdin and -z options. That is actually important
as one can't concatenate zip-files, and so xargs does not help.
But file lists are also important for things like git-diff (for which
the NUL-endedness of input is a separate issue from its output). So
instead of adding stdin piecemeal, it was some sort of idea to have
this generally available in file lists.
If somebody can come up with a nice syntax.
--
David Kastrup
^ permalink raw reply
* Re: merge time
From: Rogan Dawes @ 2007-07-30 12:44 UTC (permalink / raw)
To: Matthew L Foster; +Cc: git
In-Reply-To: <630183.45851.qm@web51001.mail.re2.yahoo.com>
Matthew L Foster wrote:
> Sorry to bring up the time issue again [that I am perhaps still confused about] but I have been
> playing around with git more and I think I can phrase my question/observation better.
>
> From viewing gitweb.cgi I have observed a situation where Linus creates a tag, say rc1, and then
> he later merges changes but some subset of those changes/commits show up in the list in time order
> as taking place _before_ the rc1 tag was made even though they were merged after. Do I describe a
> real or possible phenomenon? And does this happen because the developer that made the subset of
> changes in question commit them to his/her local repository in time order before the rc1 tag was
> made? So an external repository had the change before the rc1 tag was made but Linus' repository
> didn't? But internally git on Linus' machine knows that the gitweb.cgi displayed time order is
> wrong as far as the state is concerned because each repository's index file keeps local track of
> the true local state [just time isn't reconcilable], or am I missing something(s)?
>
> Is it possible for gitweb.cgi to have a new view mode that sorts/displays the list based on merge
> time for commits (the time merged into Linus' or whatever repository) so the above situation
> doesn't happen? The actual time of a local commit should be the time it was merged locally not the
> time it was created externally/originally, right? Where can I find the gitweb.cgi source/package?
> I could maybe hack gitweb.cgi myself.
>
> Please CC me on any replies since I am not subscribed to the list.
>
> -Matt
The last time this topic came up, folks either created (or pointed to)
reflogs as a way to determine the changes to the local state of a repo.
i.e. by checking the reflog for a ref, you could say that that ref was
changed from v2.6.20 to v2.6.21 at such and such date and time.
That would allow you to determine what commits were available via that
ref at a particular time, regardless of the actual commit dates.
To the best of my knowledge, though, reflogs are not enabled by default
on bare repos, and gitweb makes no use of the reflogs anyway.
Rogan
^ permalink raw reply
* Re: Arbitrary long file lists?
From: Alex Riesen @ 2007-07-30 12:43 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <866442t6j5.fsf@lola.quinscape.zz>
On 7/30/07, David Kastrup <dak@gnu.org> wrote:
> commands like git-archive take a file list on the command line. If
> the number of files does no longer fit the argv limitations, this
> causes a problem.
>
> So it might be nice to be able to treat some "filenames" in a file
> list special:
>
> -@=filename (read LF-lines with filenames from filename)
> -@=- (read lines with filenames from stdin)
> -@z=filename (read NUL-terminated list with filenames from filename)
> -@z=- (same from stdin)
git-update-index and the like use --stdin and -z.
What do you need the one with filename for?
^ 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