* Re: [PATCH] transplant: move a series of commits to a different parent
From: Johannes Sixt @ 2007-06-25 7:16 UTC (permalink / raw)
To: git
In-Reply-To: <9C4338DC-0C4A-4981-9EC9-2417513F629D@zib.de>
Steffen Prohaska wrote:
>
> On Jun 23, 2007, at 11:04 PM, Alex Riesen wrote:
>
> >> git-transplant.sh <onto> <from> <to>
> >>
> >> transplant starts with the contents of <onto> and puts on top of
> >> it the contents of files if they are touched by the series of
> >> commits <from>..<to>. If a commit touches a file the content of
> >> this file is taken as it is in the commit. No merging is
> >> performed. Original authors, commiters, and commit messages are
> >> preserved.
> >>
> > [...]
> > # detached head
> > git checkout $(git rev-parse onto) && git format-patch --stdout
> > --full-index from..to|git am -3
>
> No. This one tries to apply the _changes_ between from..to. What I
> need is the resulting _content_ of files modified between from..to.
Install a graft that points the parent of "from" to "onto", then run
git-filter-branch. Like so:
$ echo "$(git-rev-parse from^0) $(git-rev-parse onto^0)" \
> .git/info/grafts
$ git-filter-branch new-to onto..to
(no filters necessary).
-- Hannes
^ permalink raw reply
* Re: [PATCH] Add git-save script
From: Johannes Schindelin @ 2007-06-25 7:45 UTC (permalink / raw)
To: しらいしななこ; +Cc: GIT
In-Reply-To: <200706250632.l5P6Wu6B028140@mi0.bluebottle.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 564 bytes --]
Hi,
On Mon, 25 Jun 2007, ã~A~Wã~B~Iã~A~Dã~A~Wã~Aªã~Aªã~A~S wrote:
> Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>
> > On Sat, 23 Jun 2007, Nanako Shiraishi wrote:
> >
> > > Here is how to use my script:
> > >
> > > $ git save
> > > $ git pull
> > > $ git save restore
> >
> > This use case has been discussed often, under the name "git-stash".
> >
> > Ciao,
> > Dscho
>
> Thank you for your comments. Do you suggest I rename the script to
> git-stash and re-submit after fixing according to Junio's comments?
Yes.
Ciao,
Dscho
^ permalink raw reply
* Re: most commonly used git commands?
From: Junio C Hamano @ 2007-06-25 7:48 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: git
In-Reply-To: <20070625071752.GB15343@mellanox.co.il>
"Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:
>> Quoting Junio C Hamano <gitster@pobox.com>:
>> Perhaps they are most commonly used by the person who came up
>> with that list first ;-)?
>>
>> I think "add" deserves to be there, I am not sure "apply" is.
>
> git add is supposed to be rare, no?
> That's why git commit lists file additions/removals ...
No. You are talking in terms of pre-1.5 git. The semantics of
"git add" has been clarified since then --- it adds contents,
and is not about telling git that there are new files it did not
know so far.
^ permalink raw reply
* Re: [PATCH] transplant: move a series of commits to a different parent
From: Steffen Prohaska @ 2007-06-25 7:49 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
In-Reply-To: <467F6BB0.4C7F041E@eudaptics.com>
On Jun 25, 2007, at 9:16 AM, Johannes Sixt wrote:
> Steffen Prohaska wrote:
>>
>> On Jun 23, 2007, at 11:04 PM, Alex Riesen wrote:
>>
>>>> git-transplant.sh <onto> <from> <to>
>>>>
>>>> transplant starts with the contents of <onto> and puts on top of
>>>> it the contents of files if they are touched by the series of
>>>> commits <from>..<to>. If a commit touches a file the content of
>>>> this file is taken as it is in the commit. No merging is
>>>> performed. Original authors, commiters, and commit messages are
>>>> preserved.
>>>>
>>> [...]
>>> # detached head
>>> git checkout $(git rev-parse onto) && git format-patch --stdout
>>> --full-index from..to|git am -3
>>
>> No. This one tries to apply the _changes_ between from..to. What I
>> need is the resulting _content_ of files modified between from..to.
>
> Install a graft that points the parent of "from" to "onto", then run
> git-filter-branch. Like so:
I stumbled over the grafts yesterday and thought that this may be a
way...
> $ echo "$(git-rev-parse from^0) $(git-rev-parse onto^0)" \
> > .git/info/grafts
> $ git-filter-branch new-to onto..to
... ok this is interesting: git-filter-branch will take the info from
grafts to create its new commits. The new commits will contain all
information independent of the grafts file, right?
... but, I'm not convinced that this is what I need. I need to mix the
tree of onto with the files _modified_ between from..to. Taking _all_
files from the commits between from..to is _wrong_. And I think that
is what the command you proposed would do.
My feeling is that repairing a repository resulting from a broken
cvsimport is a bit more complex than what the existing tools provide
out-of-the box.
Steffen
^ permalink raw reply
* Re: [PATCH] git-merge: record merge strategy in the log message on auto resolved merges
From: Junio C Hamano @ 2007-06-25 7:50 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git
In-Reply-To: <20070625071624.7919.qmail@82fa8ed4561cac.315fe32.mid.smarden.org>
Gerrit Pape <pape@smarden.org> writes:
> If a strategy module auto resolved the merge cleanly, record the used
> strategy in the log message, e.g.:
>
> Merge branch 'maint' using strategy ours
>
> Signed-off-by: Gerrit Pape <pape@smarden.org>
> ---
>
>> I personally find this useful especially for the 'ours' strategy.
I really do not think we want to do this, especially when the
user did not specify anything unusual like "ours".
At least, exclude recursive and octopus out of it, please.
^ permalink raw reply
* Re: most commonly used git commands?
From: Johannes Schindelin @ 2007-06-25 7:51 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Junio C Hamano, git
In-Reply-To: <20070625071752.GB15343@mellanox.co.il>
Hi,
On Mon, 25 Jun 2007, Michael S. Tsirkin wrote:
> Quoting Junio C Hamano <gitster@pobox.com>:
>
> > I think "add" deserves to be there, I am not sure "apply" is.
>
> git add is supposed to be rare, no?
No.
> That's why git commit lists file additions/removals ...
>
> My list is typically
> git checkout
> git commit
> git pull
> git push
> git rebase
> git reset
> git update-index
git update-index is really not user-friendly. That is why we have "git
add". It is commonly used as a porcelain _instead of_ update-index.
FWIW your list is lacking log and diff, the two commands which are my top
two. I do not use rebase all that often (before --interactive, that is).
status, grep, mv, gc, show and branch are others I use quite often
(although not as much as log and diff)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add git-save script
From: Junio C Hamano @ 2007-06-25 7:52 UTC (permalink / raw)
To: しらいしななこ
Cc: Johannes Schindelin, GIT
In-Reply-To: <200706250632.l5P6Wu6A028140@mi0.bluebottle.com>
しらいしななこ <nanako3@bluebottle.com> writes:
> Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>
>> On Sat, 23 Jun 2007, Nanako Shiraishi wrote:
>>
>> > Here is how to use my script:
>> >
>> > $ git save
>> > $ git pull
>> > $ git save restore
>>
>> This use case has been discussed often, under the name "git-stash".
>
> Thank you for your comments. Do you suggest I rename the
> script to git-stash and re-submit after fixing according to
> Junio's comments?
Side note: get into the habit of trimming the quote to
remove "Hi," and signatures, please.
Because many people on the list (not just me, as I was not
initially involved in the "wish: pulling into dirty tree"
discussion myself) already used the word "stash" for the concept
of the operation, I think it would give continuity to our
discussion if you used that word.
I have to also say that the "restore" subcommand had a certain
"Huh?" factor when I first saw the above "git save restore"
command line. I would have said "git stash" to save away, and
"git stash apply" to propagate the changes to updated HEAD.
That would make the set of subcommands to:
$ git stash -- to save away
$ git stash list -- to get the list
$ git stash show [$it] -- to view a single stash
$ git stash apply [$it] -- to apply changes from a stash
Right now you seem to use reflog so that "list" gives saved@{$n}
and the user is expected to pick from it and say something like
"git stash show saved@{2}", but I suspect that there is some
room for UI improvements.
* Is comandeering a branch name "saved" for the purpose of the
stash command a right thing to do?
Perhaps we would want to use refs/stash/ hierarchy;
* Is it more convenient to have a single stash that holds
changes you make anywhere, or is it better to have one stash
per branch?
Unlike StGIT and guilt, that are systems to manage patches
for longer term, I think the concept of stash is more geared
towards quickly stashing away local changes while you have to
'get distracted", as you described in your commit log
message. So in that sense, I think anything elaborate like
one stash per branch is a mistake, and a single stash that is
quickly aged and pruned automatically when reflog expires, as
you implemented, is the right approach. Taken together with
the previous point, I would actually suggest refs/stash as
the refname.
* If we settle on the design of having a single stash per
repository, the name of whatever the ref we use to implement
the stash should not have to be spelled out by the end user
(e.g. saved@{2} should not be necessary---the user should be
able to say "the stash marked with letter '2' in 'git stash
list' output).
So perhaps as a UI improvement, "git stash list" should show
them just numbered (strip away saved@{$N} part down to just
"$N:" or something), and "git stash show" and "git stash apply"
should take that number.
I think "git stash" is usable standalone, but in the particular
use case you mentioned, I was planning to follow Linus's
suggestion of stashing and unstashing automatically inside "git
pull" (most likely in "git merge", which is the underlying
command to do the actual merging part), when the pull results in
a fast-forward situation. But that would be a separate change
that uses "git stash" command.
^ permalink raw reply
* Re: [PATCH] git-merge: record merge strategy in the log message on auto resolved merges
From: Johannes Schindelin @ 2007-06-25 7:53 UTC (permalink / raw)
To: Gerrit Pape; +Cc: Junio C Hamano, git
In-Reply-To: <20070625071624.7919.qmail@82fa8ed4561cac.315fe32.mid.smarden.org>
Hi,
On Mon, 25 Jun 2007, Gerrit Pape wrote:
> If a strategy module auto resolved the merge cleanly, record the used
> strategy in the log message
Why only when it merged cleanly? If that information is useful, it is
_especially_ useful when you had conflicts, so that you know how to
recreate the merge?
Ciao,
Dscho
^ permalink raw reply
* Re: unexpected git-cherry-pick conflict
From: Johannes Schindelin @ 2007-06-25 7:55 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git
In-Reply-To: <20070625071819.8091.qmail@5e4088a43a10fd.315fe32.mid.smarden.org>
Hi,
On Mon, 25 Jun 2007, Gerrit Pape wrote:
> On Wed, Jun 13, 2007 at 03:43:48PM +0100, Johannes Schindelin wrote:
> > On Wed, 13 Jun 2007, Gerrit Pape wrote:
> > > On Wed, Jun 13, 2007 at 01:58:51PM +0100, Johannes Schindelin wrote:
> > > > On Wed, 13 Jun 2007, Gerrit Pape wrote:
> > > > > $ git checkout master
> > > > > Switched to branch "master"
> > > > > $ git cherry-pick 8ddc4d5
> > > > > CONFLICT (file/directory): There is a directory with name link in
> > > > > 8ddc4d5... file. Added link as link~HEAD
> > > >
> > > > Here you _still_ have the file in master. So that conflict is really
> > > > expected, since a cherry-pick will only do a three-way merge.
> > >
> > > git-cherry-pick(1) states
> > > Given one existing commit, apply the change the patch introduces, and
> > > record a new commit that records it. This requires your working tree to
> > > be clean (no modifications from the HEAD commit).
> > >
> > > The patch introduced by the commit that's cherry-pick'ed has nothing to
> > > do with the link or new directory, it just changes 'file'
> > >
> > > $ git show 8ddc4d5
> > > commit 8ddc4d59444a362261e10a3b22324818f5dd2fa7
> > > Author: Gerrit Pape <pape@smarden.org>
> > > Date: Wed Jun 13 09:10:30 2007 +0000
> > >
> > > file
> > >
> > > diff --git a/file b/file
> > > index 257cc56..3bd1f0e 100644
> > > --- a/file
> > > +++ b/file
> > > @@ -1 +1,2 @@
> > > foo
> > > +bar
> > > $
> > >
> > > The patch applies to master just fine. Where's my thinking wrong?
> >
> > Hmm. Indeed. Thanks for clearing that up. Will work on it later.
>
> Hi, did you get to this yet?, not to stress you, just to make sure we
> don't forget about it.
I did not have time yet. Thanks for the reminder.
Just for the record, if you send a reply to my message to the list, but
without Cc: to me, I am very likely to miss it. Just by chance I did not,
this time.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] transplant: move a series of commits to a different parent
From: Johannes Sixt @ 2007-06-25 8:03 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Git Mailing List
In-Reply-To: <21FC6948-6969-47A4-9D6E-EFD9D98FC361@zib.de>
Steffen Prohaska wrote:
>
> On Jun 25, 2007, at 9:16 AM, Johannes Sixt wrote:
> > $ echo "$(git-rev-parse from^0) $(git-rev-parse onto^0)" \
> > > .git/info/grafts
> > $ git-filter-branch new-to onto..to
>
> ... ok this is interesting: git-filter-branch will take the info from
> grafts to create its new commits. The new commits will contain all
> information independent of the grafts file, right?
Yes.
> ... but, I'm not convinced that this is what I need. I need to mix the
> tree of onto with the files _modified_ between from..to. Taking _all_
> files from the commits between from..to is _wrong_. And I think that
> is what the command you proposed would do.
My proposed commands won't do what you need. They just change
parenthood, but not the tree snapshots that they represent.
-- Hannes
^ permalink raw reply
* Re: [PATCH] git-svnimport: added explicit merge graph option -G
From: Peter Baumann @ 2007-06-25 8:54 UTC (permalink / raw)
To: Stas Maximov; +Cc: git, Junio C Hamano
In-Reply-To: <20070624084427.GA7715@xp.machine.xx>
On Sun, Jun 24, 2007 at 10:44:27AM +0200, Peter Baumann wrote:
> On Sun, Jun 24, 2007 at 12:06:20AM -0700, Junio C Hamano wrote:
> > From: Stas Maximov <smaximov@yahoo.com>
> > Date: Sat, 23 Jun 2007 09:06:30 -0700
> >
> > Allows explicit merge graph information to be provided. Each line
> > of merge graph file must contain a pair of SVN revision numbers
> > separated by space. The first number is child (merged to) SVN rev
> > number and the second is the parent (merged from) SVN rev number.
> > Comments can be started with '#' and continue to the end of line.
> > Empty and space-only lines are allowed and will be ignored.
> > ---
> >
> > * Stas, please give a "Signed-off-by" line, and get in the
> > habit of always CC the list.
> >
> > I received a format-patch output as attachment from Stas. As
> > I cannot comment on the patch in that format, I am making a
> > verbatim forward to the list.
> >
> > I'll comment on the patch separately when I am through it,
> > but would appreciate comments from people who were involved
> > in git-svnimport in the past, and still use it.
> >
> > "You should use git-svn instead" people can repeat that as
> > usual, but at the same time it might be worth realizing that
> > there are people who maintain git-svnimport being better for
> > one-short importing.
> >
>
> [exchanging To:/Cc: as Junio just forwarded the message from Stas]
>
> Not commenting on the patch per se, but wouldn't it make more
> sense to have such functionality in a history rewriting tool like
> e.g. git-branch-filter?
>
> I had an svn import (git-svn) where I wanted to give correct
> branch/merge points, too, and so I manually created a grafts file
> annotating all the svn merges. Having such a thing as a _generic_ tool
> which operates on grafts would be much more usefull because you get one
> implementation which could be used for each and every importer out
> there. Sure, you have to transform the native revision specifieres into
> the GIT commit id's if you only have e.g. "merged r4711:4720 into trunk",
> but these functionality is much more common to have in importers
> than whats implemented in the above mentioned patch.
>
> Another bonus point of using the grafts mechanism you'll get for free is
> that you could _look_ at the commit graph in gitk *before* doing the
> often expensive reimport of your project, so could be sure you haven't
> forgotten to mark a merge.
>
There was a message that git-filter-branch already could to this, which
I didn't know:
http://thread.gmane.org/gmane.comp.version-control.git/50736/focus=50872
-Peter
^ permalink raw reply
* [PATCH] fast-import.c: detect fclose- and fflush-induced write failure
From: Jim Meyering @ 2007-06-25 9:39 UTC (permalink / raw)
To: git
There are potentially ignored write errors in fast-import.c.
Here's a proof-of-concept patch.
Something like close_stream might be worth making more generally
accessible, but rather than close_wstream_or_die, I'd prefer general
purpose die-like functions that take an errno value, e.g.,
die_errno (errno, fmt_str, arg1, ...)
that would work just like die, with this change:
- when errno is nonzero,
append the concatenation of ": " and strerror(errno)
between the format-string-denoted output and the final newline
- when errno is zero
work just like "die" currently does.
This functionality is like that provided by the error, warn*,
err, verr, etc. functions that have been in glibc forever.
With such a function (and an error_errno analog), the nearly-identical
uses of "error" added below and the nearly identical uses of "die" that
might end up in git.c could be factored out.
Here's a ChangeLog-style entry:
(end_packfile): Die upon fflush failure.
(close_stream, close_wstream_or_die): New functions.
(dump_marks): Upon fclose failure, rollback the lock and give a diagnostic.
(main): Die upon fclose failure. Record pack_edges file name for use in diagnostics.
Signed-off-by: Jim Meyering <jim@meyering.net>
---
fast-import.c | 54 ++++++++++++++++++++++++++++++++++++++++++++++++------
1 files changed, 48 insertions(+), 6 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index f9bfcc7..7941839 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -793,7 +793,9 @@ static void end_packfile(void)
fprintf(pack_edges, " %s", sha1_to_hex(t->sha1));
}
fputc('\n', pack_edges);
- fflush(pack_edges);
+ if (fflush(pack_edges))
+ die("failed to write pack-edges file: %s",
+ strerror(errno));
}
pack_id++;
@@ -1344,6 +1346,31 @@ static void dump_marks_helper(FILE *f,
}
}
+static int
+close_stream(FILE *stream)
+{
+ int prev_fail = (ferror(stream) != 0);
+ int fclose_fail = (fclose(stream) != 0);
+
+ if (prev_fail || fclose_fail) {
+ if (! fclose_fail)
+ errno = 0;
+ return EOF;
+ }
+ return 0;
+}
+
+static void
+close_wstream_or_die(FILE *stream, const char *file_name)
+{
+ if (close_stream(stream)) {
+ if (errno == 0)
+ die ("%s: write failed: %s", file_name, strerror(errno));
+ else
+ die ("%s: write failed", file_name);
+ }
+}
+
static void dump_marks(void)
{
static struct lock_file mark_lock;
@@ -1369,7 +1396,18 @@ static void dump_marks(void)
}
dump_marks_helper(f, 0, marks);
- fclose(f);
+ if (close_stream(f) != 0) {
+ int close_errno = errno;
+ rollback_lock_file(&mark_lock);
+ failure |=
+ (close_errno == 0
+ ? error("Failed to write temporary marks file %s.lock",
+ mark_file)
+ : error("Failed to write temporary marks file %s.lock: %s",
+ mark_file, strerror(close_errno)));
+ return;
+ }
+
if (commit_lock_file(&mark_lock))
failure |= error("Unable to write marks file %s: %s",
mark_file, strerror(errno));
@@ -2015,6 +2053,7 @@ static const char fast_import_usage[] =
int main(int argc, const char **argv)
{
int i, show_stats = 1;
+ const char *pack_edges_file = NULL;
git_config(git_default_config);
alloc_objects(object_entry_alloc);
@@ -2052,10 +2091,13 @@ int main(int argc, const char **argv)
mark_file = a + 15;
else if (!prefixcmp(a, "--export-pack-edges=")) {
if (pack_edges)
- fclose(pack_edges);
- pack_edges = fopen(a + 20, "a");
+ close_wstream_or_die(pack_edges,
+ pack_edges_file);
+ pack_edges_file = a + 20;
+ pack_edges = fopen(pack_edges_file, "a");
if (!pack_edges)
- die("Cannot open %s: %s", a + 20, strerror(errno));
+ die("Cannot open %s: %s", pack_edges_file,
+ strerror(errno));
} else if (!strcmp(a, "--force"))
force_update = 1;
else if (!strcmp(a, "--quiet"))
@@ -2095,7 +2137,7 @@ int main(int argc, const char **argv)
dump_marks();
if (pack_edges)
- fclose(pack_edges);
+ close_wstream_or_die(pack_edges, pack_edges_file);
if (show_stats) {
uintmax_t total_count = 0, duplicate_count = 0;
^ permalink raw reply related
* What's in git.git (stable)
From: Junio C Hamano @ 2007-06-25 9:43 UTC (permalink / raw)
To: git
In-Reply-To: <7vy7idydqa.fsf@assigned-by-dhcp.pobox.com>
Among many small fixes and some code churns, there are a few
notable topics from 'next'.
- git-filter-branch to rewrite history;
- git-add "Huh?" factor fix when attempting to add an empty directory;
- git-log and friends do not have the 16kB size limit for
commit log messages anymore;
- git-log and friends' --pretty=oneline treats the first
paragraph of a commit log message as the title line;
- "git-log --follow -- single-file";
Simon Hausmann and Shawn Pearce have shepherded a fast-import
based Perforce importer into contrib/fast-import area.
* The 'master' branch has these since the last announcement
Dave O'Neill (1):
Generate tags with correct timestamp (git-svnimport)
Gerrit Pape (1):
git-svn: trailing slash in prefix is mandatory with --branches/-b
Jeff King (4):
dir_struct: add collect_ignored option
builtin-add: simplify (and increase accuracy of) exclude handling
Fix ALLOC_GROW off-by-one
Fix ALLOC_GROW calls with obsolete semantics
Johannes Schindelin (7):
Add git-filter-branch
filter-branch: use $(($i+1)) instead of $((i+1))
filter-branch: fix behaviour of '-k'
Teach filter-branch about subdirectory filtering
pp_header(): work around possible memory corruption
diffcore-rename: favour identical basenames
filter-branch: add example to move everything into a subdirectory
Johannes Sixt (4):
filter-branch: Use rev-list arguments to specify revision ranges.
filter-branch: also don't fail in map() if a commit cannot be
mapped
filter-branch: Simplify parent computation.
filter-branch: subdirectory filter needs --full-history
Julian Phillips (1):
new-workdir: handle rev-parse --git-dir not always giving full path
Junio C Hamano (5):
t7003: make test repeatable
Lift 16kB limit of log message output
Extend --pretty=oneline to cover the first paragraph,
Two trivial -Wcast-qual fixes
git-send-email: Do not make @-less message ID
Linus Torvalds (2):
Finally implement "git log --follow"
Fix up "git log --follow" a bit..
Matthias Lederhofer (3):
filter-branch: prevent filters from reading from stdin
chmod +x git-filter-branch.sh
make dist: include configure script in tarball
Nanako Shiraishi (1):
Cloning from a repo without "current branch"
Shawn O. Pearce (2):
Avoid src:dst syntax as default bash completion for git push
Document git-gui, git-citool as mainporcelain manual pages
Sven Verdoolaege (1):
t9500: skip gitweb tests if perl version is too old
-- p4 --
Benjamin Sergeant (1):
git-p4 fails when cloning a p4 depo.
Han-Wen Nienhuys (28):
Cleanups
reformatting: break long lines.
rename apply() to applyCommit(); apply is a python builtin
add .dotest to .gitignore
Robustness fixes for pipes
cleanup
minor cleanups
clone and sync --keep-path to keep perforce path to module.
use string.strip() iso. slicing.
use strip() iso. slicing for removing \n
add --verbose to all commands.
Extract multiple paths concurrently.
Diverse cleanups
remove global .gitdir
Read p4 files in one batch.
Thinko, fix buglet.
store p4 user cache in home directory.
thinko.
read files before creating the commit.
don't p4 print deleted files.
only run p4 print if necessary
use p4CmdList() to get file contents in Python dicts. This is more
robust.
Cleanups & import into p4/master for local import
remove debug print
thinko: really ignore deleted files.
look for 'text' and 'binary' files.
print error message when p4 print fails (eg. due to permission
problems)
also strip p4/ from local imports.
Kevin Green (1):
git-p4: check for existence of repo dir before trying to create
Marius Storm-Olsen (7):
Make the command call silent
Replace \r\n with \n when importing from p4 on Windows
Ensure that the commit message is Windows formated (CRLF) before
invoking the editor.
Fix git-p4 clone (defaultDestination)
Fix single branch import into remotes
Exclude the HEAD symbolic ref from the list of known branches
Only use double quotes on Windows
Simon Hausmann (222):
Initial import of a python script to import changesets from
Perforce into git.
Added basic support for specifying the depot path to import from as
well as the range of perforce changes.
Slightly improved help usage output and made specifying the
trailing slash for the depot path optional.
Implemented basic support for converting the date of the perforce
change to the git format. The timezone isn't correctly set up
yet though.
Some fixes to the timezone conversion between the date of a
perforce change and the git commit.
Speed up the import of individual files from Perforce into git by
passing the output of "p4 print" directly to git fast-import.
Also try to set the mode of the file in git correctly based on
file type heuristics.
Removed unused p4cat function and added helper function for the
perforce python interface (p4Cmd).
Changed the import mechanism to write to git fast-import through a
pipe instead of having p4-fast-export write to stdout and let
the caller connect it to git fast-import.
Minor code cleanups and ported some p4 interfacing code over to the
p4 python mode.
Instead of parsing the output of "p4 users" use the python objects
of "p4 -G users".
Ported the remaining functions that parsed p4 shell output over to
the p4 python interface.
Avoid calling fstat for every imported file (slow!) and instead
read the file data first into the python process and use the
length of the bytes read for the size field of git fast-import.
Permit calling p4-fast-export with a depot path that has the
typical ... wildcard at the end.
Fixed displaying import progress by calling flush on stdout.
Create a git tag for every changeset imported from perforce.
Fix file permissions of p4-fast-export.py to be executable.
Started working on incremental imports from Perforce.
Simplify the incremental import by elimination the need for a
temporary import branch.
Code cleanups, move the code to create a commit with fast-import
into a separate function out of the main loop.
Initial support for importing a directory from Perforce at a
specified revision.
Minor cleanups and print an error message of git fast-import if it
fails.
Fixed incremental imports by using the correct "from" command
instead of "merge" with git fast-import.
Make incremental imports easier to use by storing the p4 depot path
after an import in .git/config and re-using it when we're
invoked again later.
Make specifying the revision ranges more convenient.
Fix calculation of the newest imported revision for #head imports.
Catch io exceptions from git fast-import again and print the error
message.
Made the name of the git branch used for the perforce import
configurable through a new --branch=<name> commandline option.
Added a little helper script to debug the output of the p4 python
interface.
Minor code cleanups.
Avoid the excessive use of git tags for every perforce change and
instead just create one git tag for the last imported change.
Changed the default git import branch from "p4" to "master".
Added a little helper script to remove unused tags from the
perforce import.
Create lightweight git tags (using the "reset" trick) for the
incremental import instead of full-blown ones. Also fix parsing
the output of git name-rev for figuring out the last imported
p4 change number.
Cleanups, remove unused variable.
Code cleanups.
Started work on p4 branch detection (experimental!).
More fixes in heuristic p4 branch detection based on common path
components.
After marking a p4 branch as merged don't ever merge it in git
again.
Set git fast-import marks for every imported change for future use.
When trying to map p4 integrations to git merges just record it as
a single merge with the newest p4 change as secondary parent.
Make it possible to specify the p4 changes to import through a text
file (for debugging) and made various improvements to the
branch/merge heuristic detection.
Use sets.Set() instead of set() to run also with older versions of
Python.
Fix single-branch imports by skipping the branch/merge detection
correctly.
Added p4 delete behavioural emulation as todo item.
Added support for --silent so that p4-fast-export can be called
from cronjobs.
More work in --silent support.
Don't print a plain newline at the end of the execution (avoids
bogus cron error mails).
Adjust the output parsing of git name-rev to handle the output of
the latest git version.
Work in progress on detecting branches.
Changed --known-branches to take a file as argument instead of a
comma separated list.
Fixed p4-debug file extension.
Make the p4 data/command cache configurable through the
--cache-debug commandline option.
Minor code cleanups.
More code cleanups and preparations for more branch detection
heuristics.
More work on branch detection by implementing
changeIsBranchMerge().
Reduce the number of false "merges" by skipping "branch from"
entries in the integrated output as well as by ignoring
integrations of future (newer) changes.
Split up the cache commandline options into (command) cache and
data cache.
First version of a new script to submit changes back to perforce
from git repositories.
Fix git-dir option and allow reading log substitutions from a file
Lots of bugfixes to p4-git-sync.
Automatically operate on a temporary branch, needed for cherry-pick
to work when applying changes to
Be nice and use /usr/bin/env python for the git-p4 scripts
Ignore Apple resource files when importing from perforce to git.
Auto-detect the current git branch before submitting back to
perforce.
Use p4 revert ... instead of revert -a ... after submitting, to
make sure the p4 checkout is clean.
Default to interactive syncing
Improved the git dir detection.
Pass the right number of arguments to commit, fixes single-branch
imports.
Start moving the git-p4 tools into one single script.
Provide a little bit of help description for the git-p4 "tools".
First (untested) attempt at migrating p4-git-sync into the final
git-p4 script
Part of the code is copyright by Trolltech ASA.
sync-to-perforce is now called submit and fixed the gitdir check a
little bit
Completely untested "merge" of p4-fast-export.py into git-p4.py
Added missing "self"s to make the script evaluate correctly.
Fixed the initial version import by getting the file index correct
by correctly skipping deleted files.
Removed p4-fast-export and p4-git-sync as they've been integrated
into git-p4 now.
Start of the git-p4 documentation.
Documentation enhancements.
Added experimental but super-fast --apply-as-patch option to git-p4
submit
Fix support for deletions in git-p4 submit when using
--apply-as-patch by filtering out deletions in the diff-tree
output.
Made --apply-as-patch the default for git-p4 submit as it's
significantly faster.
Make it possible to invoke git-p4 from within subdirectories of a
git working tree.
Don't show the submit template and the diff first in less but show
it in $editor right away
Removed the .py extension from git-p4 as it's annoying to type
every time.
Changed the format of the imported log message slightly, so that
it's easier to parse again.
Changed the default branch for imports from "master" to "p4"
Added some helper function(s) to parse the depot path and change
number from the log message
Helper function to check the existance of a revision
Set the default branch in run, not in the constructor
Brand new smart incremental import that doesn't need tags or git
repo-config :)
Make it possible to run git-p4 submit from within the git
repository
Use the new incremental import style by default
Different versions of p4 have different output for the where
command ;(
Minor cosmetic fixlet for the git-p4 submit sync question.
Prefer git command over git-command.
Don't try to parse any options with git-p4 debug but pass it
straight on to p4
git-p4 debug doesn't need a git repository
Added support for mapping p4 labels to git tags
Fix variable usage in tag import
Fix the docs for git-p4 submit and turn git-p4 submit --master=foo
into
Fix "compilation" :)
Clean up python class names.
Added git-p4 rebase convenience
Provide a tree summary after git-p4 rebase
Turn off potentially slow label detection by default
Honor --silent for labels
Added git-p4 clone convenience command
Fix file determination for #head imports
fix variable usage (oops)
Added a simple example of usage to the "documentation" :)
Allow for convenient rebasing after git-p4 submit
Print an error message of some sort if git fast-import fails.
Fix the timezone formatting. Now qgit also displays (parses) it
correctly.
Removed the old patch apply code from git-p4 submit.
Slightly improved formatting of the raw_input questions.
A new attempt at fixing the child-fast-import-process-not-finished
race condition
Handle patch errors in git-p4 submit better.
Doc cleanups.
Micro cleanup
cleanup, renamed self.globalPrefix to self.depotPath
Cleanup, removed the old tagging code
Document some implementation details, for the curious... :)
Use the subprocess module instead of popen2 to make it work on
Windows.
Added a little .bat wrapper from Marius
Make sure all popen calls use binary mode (for Windows) and
Make submitting work on Windows.
Converted to unix newlines
Fix git-p4 clone //depot/project (head import)
Make git-p4 work with bare repositories.
Added the possibility of skipping patches during git-p4 submit
Give a better hint if git-p4 submit fails
Fix calling git-p4 rebase from within a subdirectory (git rebase
wants to be in toplevel)
A little todo note before I forget it :), based on a suggestion
from Lars.
Fixing syncing (gitdir discovery / cd) for bare repositories
Always pass a sha1 for the initial parent so that git-fast-import
doesn't think
Clean up code duplication for revision parsing and fix previous
commit to not
Removed cleantags command. It doesn't have any meaning anymore.
Removed ancient and unused code to find the last imported revision
from previous imports
Create the origin based import branch using git update-ref instead
of git branch
Changed the default p4 import branch to be
refs/remotes/p4/{HEAD,master}
Bite the bullet and automatically convert old style refs/heads/p4
repositories
Added support for git-p4 sync/rebase --with-origin. See git-p4.txt
for details :)
Removed todo item that is implemented :)
Fix branch setup after initial clone.
Removed unused cache variables.
Started rewriting the branch detection, based on "p4 branches" and
"p4 branch -o foo".
Give branches a nice project prefix and don't bail out on clone if
we failed
More work on the incremental importing of multiple branches.
Cleanup/speed up the branch<> file split and removed change range
limitation that I added
More cleanups and speedups for labels and branches
Removed unused variable, more cleanups
Cache the output of "p4 users" for faster syncs on high latency
links.
Fix gitdir not being set when cloning. Needed for writing the p4
users cache.
Oops, not only /set/ gitdir on clone, also set it /correctly/ :)
Use git format-patch and git apply --apply when extracting patches
from git and
Added support for git-p4 submit --direct (experimental)
Specifying --detect-branches is now only needed for the initial
clone/sync.
Had an idea for debugging, record it :)
Another (potentially life-saving) idea for submit --direct
Improved output for multi branch imports and noted another little
todo item
Fix conversion from old style heads/p4 to remotes/p4/master
Fix error detection with git-p4 submit when the requested depot
path is not in the client view.
Fix git symbolic-ref warning on initial clone
Detect with git-p4 submit --direct when there are no changes in the
working directory
Make git-p4 submit --direct safer by also creating a git commit
Added a rollback command for debugging. It sets back the heads of
the p4 branches to the specified p4 change number or earlier.
Fix branch detection in multi-branch imports
Fixes for rollback, delete branches that did not exist at the
specified p4 change
Added support for importing multiple branches into refs/heads
instead of just refs/remotes
Added support for --max-changes=<count> to ease import debugging
Use refs/heads/* instead of refs/heads/p4/* for local imports
Doc updates
Avoid calling git symbolic-ref refs/heads/p4//HEAD (double slash)
Make rollback work with locally imported branches
Don't make len(p4Cmd("p4 changes -m 1 //foo/...")) == 0 succeed
when the p4 command itself failed.
Oops, fill the /list/ correct with the p4 exit code.
Catch p4 errors in rollback early enough (before deleting refs!)
Fix p4 execution in git-p4 rollback.
Fix multi-branch import with --silent.
Load the user map from p4 only once at run-time.
Fix creating the remotes/p4 branches based on origin/* for the
multi-branch import
Forgot to remove this return statement from debugging
Added support for --with-origin with multi-branch imports
Oops, fix --with-origin to /really/ also call git fetch :)
Avoid creating non-p4 branches in remotes/p4 off of remotes/origin
Make git-p4 work with packed refs (don't use os.path.exists to
check for the
Make --with-origin also work without origin :)
Make --with-origin the default for syncing.
Shortcut the case where we have no origin branch
Forgot to remove this TODO item when I made --with-origin the
default :)
Added git-p4 submit --trust-me-like-a-fool for the adventurous
users :)
Fix creation of refs/remotes/p4/HEAD symbolic ref
Fix my email address, this isn't really KDE related :)
In *_pipe print the command that failed if it fails.
Fix typo in listExistingP4Branches that broke sync.
Fix support for "depot-path" in older git-p4 imports
Fix common path "calculation" from logs of multiple branches.
Don't attempt to set the initialParent on multi-branch imports
(useless).
Hack to make the multi-branch import work again with
self.depotPaths now that
Fix git-p4 rebase
Fix git-p4 submit
Fix depot-path determination for git-p4 submit
Make clone behave like git clone by default again.
Make git-p4 submit detect the correct reference (origin) branch
when
Only get the expensive branch mapping from the p4 server when not
Fixed the check to make sure to exclude the HEAD symbolic refs when
updating
Fix updating/creating remotes/p4/* heads from origin/p4/*
Fix project name guessing
Fix depot-paths encoding for multi-path imports (don't split up
//depot/path/foo)
Fix support for explicit disabling of syncing with the origin
Write out the options tag in the log message of imports only if we
actually have
Provide some information for single branch imports where the
commits go
Mention remotes/p4/master also in the documentation.
git-p4 submit: Fix missing quotes around p4 commands to make them
work with spaces in filenames
Moved the code from git-p4 submit to figure out the upstream branch
point
Fix git-p4 rebase to detect the correct upstream branch instead of
unconditionally
Fix initial multi-branch import.
Fix the branch mapping detection to be independent from the order
of the "p4 branches" output.
Warn about conflicting p4 branch mappings and use the first one
found.
Added git-p4 branches command that shows the mapping of perforce
depot paths to imported git branches.
Make it possible to specify the HEAD for the internal
findUpstreamBranchPoint function.
^ permalink raw reply
* What's cooking in git.git (topics)
From: Junio C Hamano @ 2007-06-25 9:43 UTC (permalink / raw)
To: git
In-Reply-To: <7v4pl1zsd7.fsf@assigned-by-dhcp.pobox.com>
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'. The topics list the commits in reverse chronological
order.
* js/rebase (Mon Jun 25 01:11:14 2007 +0100) 2 commits
+ Teach rebase an interactive mode
+ Move the pick_author code to git-sh-setup
Will merge.
* rs/diff (Mon Jun 25 00:23:34 2007 +0200) 2 commits
+ diff: round down similarity index
+ diffcore-rename: don't change similarity index based on basename
equality
Will merge.
* lt/run (Sun Jun 24 10:29:33 2007 -0700) 2 commits
+ Check for IO errors after running a command
+ Clean up internal command handling
Will merge.
* ew/svn (Wed Jun 13 02:23:28 2007 -0700) 1 commit
+ git-svn: allow dcommit to retain local merge information
Haven't heard major breakage report, so hopefully can merge by
the end of the month.
* mk/svn (Fri Jun 22 11:15:03 2007 +0200) 1 commit
- git-svn: honor ~/.subversion/ client cert file settings.
Waiting for ACK from git-svn people.
* ml/worktree (Fri Jun 8 22:57:55 2007 +0200) 9 commits
+ make git barf when an alias changes environment variables
+ setup_git_directory: fix segfault if repository is found in cwd
+ test GIT_WORK_TREE
+ extend rev-parse test for --is-inside-work-tree
+ Use new semantics of is_bare/inside_git_dir/inside_work_tree
+ introduce GIT_WORK_TREE to specify the work tree
+ test git rev-parse
+ rev-parse: introduce --is-bare-repository
+ rev-parse: document --is-inside-git-dir
* ei/worktree+filter (Wed Jun 6 09:16:56 2007 +0200) 9 commits
+ filter-branch: always export GIT_DIR if it is set
I've been resisting these due to the size of the series, but I
think the definition of is-bare is a bit saner than what we have
in 'master', and I think it is the right direction in the longer
term. HOWEVER, I am not sure about the implementation and
corner cases, e.g. what should it do in receive-pack? You
cannot rely on user setting GIT_WORK_TREE environment -- rather,
receive-pack is responsible for setting up a sane environment
for other commands to work in.
* jc/quote (Sun Jun 24 15:11:24 2007 -0700) 1 commit
+ Add core.quotepath configuration variable.
This will get rid of "Why is my UTF-8 pathnames are munged"
complaints. Will wait for a while, maybe merge after 1.5.3. I
believe the output from this is still readable by an unpatched
git-apply, but I would want to be absolutely sure.
* jo/init (Thu Jun 7 07:50:30 2007 -0500) 2 commits
- Quiet the output from git-init when cloning, if requested.
- Add an option to quiet git-init.
I am not very much interested in this but I do not have any
strong or otherwise feeling against it either.
* dh/repack (Fri May 25 14:40:24 2007 -0700) 1 commit
- Enhance unpack-objects for live repo and large objects
* jc/blame (Fri Apr 20 16:25:50 2007 -0700) 4 commits
- blame: show log as it goes
- git-blame: optimize get_origin() from linear search to hash-
lookup.
- git-blame: pass "struct scoreboard *" pointers around.
- blame: lift structure definitions up
* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits
- test-para: combined diff between HEAD, index and working tree.
- para-walk: walk n trees, index and working tree in parallel
Backburnered.
^ permalink raw reply
* Re: [PATCH 2/2] Check for IO errors after running a command
From: Junio C Hamano @ 2007-06-25 9:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jim Meyering, git, Matthias Lederhofer
In-Reply-To: <alpine.LFD.0.98.0706241010480.3593@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> Side note: I think I made a mistake in making the run_command() a NORETURN
> function and putting the exit() into it. It's probably better to instead
> just make it return "int", and make the caller do
>
> exit(run_command(...));
>
> and that makes it much prettier to have "run_command()" just return early
> if an error happens (or doesn't happen).
>
> For example, then we could just do
>
> status = p->fn(...);
> if (status)
> return status;
> /* Somebody closed stdout? */
> if (fstat(fileno(stdout), &st))
> return 0;
> /* Ignore write errors for pipes and sockets.. */
> if (S_ISFIFO(st.st_mode) || S_ISSOCK(st.st_mode))
> return 0;
>
> which makes it easy to explain what's going on, and avoids having any deep
> indentation at all.
I took the liberty of munging your two patches to follow your
comments above (it was a perfect guinea-pig opportunity for
Johannes's "rebase -i").
The changes to git.c (run_command) conflicted with GIT_WORK_TREE
changes in a minor way. Matthias, could you sanity check the
result once I push it out to 'next', please?
^ permalink raw reply
* Re: [PATCH] diff: round down similarity index
From: René Scharfe @ 2007-06-25 10:34 UTC (permalink / raw)
To: David Kastrup; +Cc: Junio C Hamano, Johannes Schindelin, Git Mailing List
In-Reply-To: <86k5tsh761.fsf@lola.quinscape.zz>
David Kastrup schrieb:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
>>
>>> +static int similarity_index(struct diff_filepair *p)
>>> +{
>>> + int result = p->score * 100.0 / MAX_SCORE;
>>> +
>>> + /* Paranoia: guard against floating point rounding errors. */
>>> + if (p->score == MAX_SCORE)
>>> + result = 100;
>>> + else if (result == 100)
>>> + result = 99;
>>> +
>>> + return result;
>>> +}
>> Why not simply do this?
>>
>> static int similarity_index(struct diff_filepair *p)
>> {
>> if (p->score == MAX_SCORE)
>> return 100;
>> return p->score * 100 / MAX_SCORE;
>> }
>>
>> MAX_SCORE and p->score run up to 60000 and we assume int is at
>> least 32-bit, so I do not think there is no risk of overflowing.
Good idea! *smacks himself against the forehead*
I just copied the old code (sans the addition of 0.5) and then tried
to work around it's rounding problem (which I'm not even certain
exists and matters). Look out for an updated patch..
> You bet me to it on the way to work. Anyway, when working with
> integers, the first two lines are definitely not required (I am
> assuming that p->score is integer as well but have not checked).
Right.
> What probably requires more thought is the calculation of p->score
> itself: if one has large numbers as a ratio (original vs changes
> lines), multiplying by 60000 before dividing by the second large
> numbers might exceed the size of the integers.
MAX_SCORE is defined as 60000.0, which makes it a double. AFAICS all
the multiplications with MAX_SCORE are done using floating point
arithmetic for that reason.
René
^ permalink raw reply
* [PATCH] diff: round down similarity index, take 2
From: René Scharfe @ 2007-06-25 10:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Kastrup, Johannes Schindelin, Git Mailing List
In-Reply-To: <7vir9co8ue.fsf@assigned-by-dhcp.cox.net>
Rounding down the printed (dis)similarity index allows us to use
"100%" as a special value that indicates complete rewrites and
fully equal file contents, respectively.
While at it, switch index calculation to integer arithmetic as
suggested by Junio and David Kastrup.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
The added documentation is only correct if you apply the
diffcore-rename patch, too.
Documentation/diff-format.txt | 7 +++++++
diff.c | 22 +++++++++++-----------
2 files changed, 18 insertions(+), 11 deletions(-)
diff --git a/Documentation/diff-format.txt b/Documentation/diff-format.txt
index 18d49d2..0015032 100644
--- a/Documentation/diff-format.txt
+++ b/Documentation/diff-format.txt
@@ -126,6 +126,13 @@ the file that rename/copy produces, respectively.
If there is need for such substitution then the whole
pathname is put in double quotes.
+The similarity index is the percentage of unchanged lines, and
+the dissimilarity index is the percentage of changed lines. It
+is a rounded down integer, followed by a percent sign. The
+similarity index value of 100% is thus reserved for two equal
+files, while 100% dissimilarity means that no line from the old
+file made it into the new one.
+
combined diff format
--------------------
diff --git a/diff.c b/diff.c
index 9938969..81527bf 100644
--- a/diff.c
+++ b/diff.c
@@ -1813,6 +1813,11 @@ static void diff_fill_sha1_info(struct diff_filespec *one)
hashclr(one->sha1);
}
+static int similarity_index(struct diff_filepair *p)
+{
+ return p->score * 100 / (int)MAX_SCORE;
+}
+
static void run_diff(struct diff_filepair *p, struct diff_options *o)
{
const char *pgm = external_diff();
@@ -1847,23 +1852,20 @@ static void run_diff(struct diff_filepair *p, struct diff_options *o)
"similarity index %d%%\n"
"copy from %s\n"
"copy to %s\n",
- (int)(0.5 + p->score * 100.0/MAX_SCORE),
- name_munged, other_munged);
+ similarity_index(p), name_munged, other_munged);
break;
case DIFF_STATUS_RENAMED:
len += snprintf(msg + len, sizeof(msg) - len,
"similarity index %d%%\n"
"rename from %s\n"
"rename to %s\n",
- (int)(0.5 + p->score * 100.0/MAX_SCORE),
- name_munged, other_munged);
+ similarity_index(p), name_munged, other_munged);
break;
case DIFF_STATUS_MODIFIED:
if (p->score) {
len += snprintf(msg + len, sizeof(msg) - len,
"dissimilarity index %d%%\n",
- (int)(0.5 + p->score *
- 100.0/MAX_SCORE));
+ similarity_index(p));
complete_rewrite = 1;
break;
}
@@ -2387,8 +2389,7 @@ static void diff_flush_raw(struct diff_filepair *p,
}
if (p->score)
- sprintf(status, "%c%03d", p->status,
- (int)(0.5 + p->score * 100.0/MAX_SCORE));
+ sprintf(status, "%c%03d", p->status, similarity_index(p));
else {
status[0] = p->status;
status[1] = 0;
@@ -2670,8 +2671,7 @@ static void show_rename_copy(const char *renamecopy, struct diff_filepair *p)
{
char *names = pprint_rename(p->one->path, p->two->path);
- printf(" %s %s (%d%%)\n", renamecopy, names,
- (int)(0.5 + p->score * 100.0/MAX_SCORE));
+ printf(" %s %s (%d%%)\n", renamecopy, names, similarity_index(p));
free(names);
show_mode_change(p, 0);
}
@@ -2695,7 +2695,7 @@ static void diff_summary(struct diff_filepair *p)
if (p->score) {
char *name = quote_one(p->two->path);
printf(" rewrite %s (%d%%)\n", name,
- (int)(0.5 + p->score * 100.0/MAX_SCORE));
+ similarity_index(p));
free(name);
show_mode_change(p, 0);
} else show_mode_change(p, 1);
^ permalink raw reply related
* [PATCH] git-new-workdir: Fix shell warning about operator == used with test.
From: Simon Hausmann @ 2007-06-25 11:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Use = instead of == with test to test for equality.
Signed-off-by: Simon Hausmann <simon@lst.de>
---
contrib/workdir/git-new-workdir | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/workdir/git-new-workdir b/contrib/workdir/git-new-workdir
index 709b2a3..3ff6bd1 100755
--- a/contrib/workdir/git-new-workdir
+++ b/contrib/workdir/git-new-workdir
@@ -24,7 +24,7 @@ git_dir=$(cd "$orig_git" 2>/dev/null &&
git rev-parse --git-dir 2>/dev/null) ||
die "\"$orig_git\" is not a git repository!"
-if test "$git_dir" == ".git"
+if test "$git_dir" = ".git"
then
git_dir="$orig_git/.git"
fi
--
1.5.2.2.549.gaeb59
^ permalink raw reply related
* Re: qgit: Annotate hundreds of files at terrific speed ;-)
From: Marco Costalba @ 2007-06-25 11:20 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: GIT
In-Reply-To: <200706250638.l5P6crkS026564@mi1.bluebottle.com>
On 6/25/07, Nanako Shiraishi <nanako3@bluebottle.com> wrote:
>
> >> Marco Costalba <mcostalba@gmail.com> wrote:
> >
> > - filtering, ie selecting with the mouse some lines and getting a
> > subset of the file history that modified at least one of that lines is
> > not possible.
>
> I often use "git blame -L'/regexp/,/regexp/'" (you can use line
> numbers there, too). Is this different from what you talk above?
>
Yes it.
Suppose you have selected file lines from 20 to 23 in revision A.
Revision history it's the following, in cronological order:
A (oldest) -> B - > C (newest)
Say that in revision B the patch removed 5 lines from 5 to 10 and
added 2 new lines instead.
Now when you jump from A to revision C you may want to see selected
the lines (-5 + 2 = -3) from 17 to 20 and no more the lines from 20 to
23 that will point to a different content.
In a general case jumping from a revision A to a revision N you have to:
- get the list of intermediate revision
- for each revision calculate deleted/ added content that is before
the selected lines range.
- for each revision calculate deleted/ added content that CROSSES the
selected range, so that if in our example revision B adds also 2 new
lines in position 21 the selection in C will not be 17 to 20 but 17 to
22! The same logic in case of deleted lines in selected range.
So to keep a "consistent" mouse selection when jumping to different
file revisions you really need to know all the annotate history in
between.
Marco
^ permalink raw reply
* Re: Darcs
From: Florian Weimer @ 2007-06-25 11:36 UTC (permalink / raw)
To: git
In-Reply-To: <cecbdd220706232232w77a609faxf0e6b2dc37f0d1f4@mail.gmail.com>
* Bu Bacoo:
> What do you think about darcs?
The UI is nice, but darcs is quite slow (even if you don't hit the
exponentional corner case in the merge algorithm).
My main gripe with darcs, and the prime reason why I'm moving away
from it, is its lack of support for software archaeology. If you
haven't tagged a tree at some point, you'll face lots of trouble when
you try to restore something that resembles the tree you had back
then. This is a direct consequence of the "heap of patches" approach,
but it's a real nuisance, and the benefits of the increased
flexibility don't make up for it, IMHO.
^ permalink raw reply
* Re: [PATCH 2/2] Check for IO errors after running a command
From: Johannes Schindelin @ 2007-06-25 13:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7i8xtap.fsf@assigned-by-dhcp.pobox.com>
Hi Junio,
On Mon, 25 Jun 2007, Junio C Hamano wrote:
> I took the liberty of munging your two patches to follow your comments
> above (it was a perfect guinea-pig opportunity for Johannes's "rebase
> -i").
And? How was that experience?
I am actually quite pleased how it worked out in the end; I never
understood the syntax of rebase, and stayed away from it for that reason.
By reworking patch-series into rebase -i, I learnt it on the way, and find
it actually quite useful.
One thing we might consider, however: when rebasing, the current branch
gets updated at each step. Some might consider this a bug, and prefer
rebase to work on a detached HEAD, and only update the branch at the end,
so that <branchname>@{1} refers to the state _before_ rebase.
Thoughts?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] Check for IO errors after running a command
From: Johannes Sixt @ 2007-06-25 13:42 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0706251413530.4059@racer.site>
Johannes Schindelin wrote:
> One thing we might consider, however: when rebasing, the current branch
> gets updated at each step. Some might consider this a bug, and prefer
> rebase to work on a detached HEAD, and only update the branch at the end,
> so that <branchname>@{1} refers to the state _before_ rebase.
YESSSS!
Finding the commit before the rebase in the reflog is a nightmare.
-- Hannes
^ permalink raw reply
* [PATCH] config: add support for --bool and --int while setting values
From: Frank Lichtenheld @ 2007-06-25 14:00 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Frank Lichtenheld
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
---
Documentation/git-config.txt | 9 +++---
builtin-config.c | 54 +++++++++++++++++++++++++++++---------
t/t1300-repo-config.sh | 48 +++++++++++++++++++++++++++++++++-
t/t9400-git-cvsserver-server.sh | 4 +-
4 files changed, 94 insertions(+), 21 deletions(-)
There are probably more elegant ways to do this...
But it seems to work.
diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
index f2c6717..ddb1dea 100644
--- a/Documentation/git-config.txt
+++ b/Documentation/git-config.txt
@@ -9,9 +9,9 @@ git-config - Get and set repository or global options
SYNOPSIS
--------
[verse]
-'git-config' [--system | --global] name [value [value_regex]]
-'git-config' [--system | --global] --add name value
-'git-config' [--system | --global] --replace-all name [value [value_regex]]
+'git-config' [--system | --global] [type] name [value [value_regex]]
+'git-config' [--system | --global] [type] --add name value
+'git-config' [--system | --global] [type] --replace-all name [value [value_regex]]
'git-config' [--system | --global] [type] --get name [value_regex]
'git-config' [--system | --global] [type] --get-all name [value_regex]
'git-config' [--system | --global] --unset name [value_regex]
@@ -36,8 +36,7 @@ prepend a single exclamation mark in front (see also <<EXAMPLES>>).
The type specifier can be either '--int' or '--bool', which will make
'git-config' ensure that the variable(s) are of the given type and
convert the value to the canonical form (simple decimal number for int,
-a "true" or "false" string for bool). Type specifiers currently only
-take effect for reading operations. If no type specifier is passed,
+a "true" or "false" string for bool). If no type specifier is passed,
no checks or transformations are performed on the value.
This command will fail if:
diff --git a/builtin-config.c b/builtin-config.c
index b2515f7..3aa4645 100644
--- a/builtin-config.c
+++ b/builtin-config.c
@@ -131,9 +131,32 @@ free_strings:
return ret;
}
+char* normalize_value(const char* key, const char* value)
+{
+ char* normalized;
+
+ if (!value)
+ return NULL;
+
+ if (type == T_RAW)
+ normalized = xstrdup(value);
+ else {
+ normalized = xmalloc(64);
+ if (type == T_INT)
+ sprintf(normalized, "%d",
+ git_config_int(key, value?value:""));
+ else if (type == T_BOOL)
+ sprintf(normalized, "%s",
+ git_config_bool(key, value) ? "true" : "false");
+ }
+
+ return normalized;
+}
+
int cmd_config(int argc, const char **argv, const char *prefix)
{
int nongit = 0;
+ char* value;
setup_git_directory_gently(&nongit);
while (1 < argc) {
@@ -205,9 +228,10 @@ int cmd_config(int argc, const char **argv, const char *prefix)
use_key_regexp = 1;
do_all = 1;
return get_value(argv[2], NULL);
- } else
-
- return git_config_set(argv[1], argv[2]);
+ } else {
+ value = normalize_value(argv[1], argv[2]);
+ return git_config_set(argv[1], value);
+ }
case 4:
if (!strcmp(argv[1], "--unset"))
return git_config_set_multivar(argv[2], NULL, argv[3], 0);
@@ -223,17 +247,21 @@ int cmd_config(int argc, const char **argv, const char *prefix)
use_key_regexp = 1;
do_all = 1;
return get_value(argv[2], argv[3]);
- } else if (!strcmp(argv[1], "--add"))
- return git_config_set_multivar(argv[2], argv[3], "^$", 0);
- else if (!strcmp(argv[1], "--replace-all"))
-
- return git_config_set_multivar(argv[2], argv[3], NULL, 1);
- else
-
- return git_config_set_multivar(argv[1], argv[2], argv[3], 0);
+ } else if (!strcmp(argv[1], "--add")) {
+ value = normalize_value(argv[2], argv[3]);
+ return git_config_set_multivar(argv[2], value, "^$", 0);
+ } else if (!strcmp(argv[1], "--replace-all")) {
+ value = normalize_value(argv[2], argv[3]);
+ return git_config_set_multivar(argv[2], value, NULL, 1);
+ } else {
+ value = normalize_value(argv[1], argv[2]);
+ return git_config_set_multivar(argv[1], value, argv[3], 0);
+ }
case 5:
- if (!strcmp(argv[1], "--replace-all"))
- return git_config_set_multivar(argv[2], argv[3], argv[4], 1);
+ if (!strcmp(argv[1], "--replace-all")) {
+ value = normalize_value(argv[2], argv[3]);
+ return git_config_set_multivar(argv[2], value, argv[4], 1);
+ }
case 1:
default:
usage(git_config_set_usage);
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 7731fa7..4234d83 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -465,11 +465,57 @@ test_expect_success bool '
done &&
cmp expect result'
-test_expect_failure 'invalid bool' '
+test_expect_failure 'invalid bool (--get)' '
git-config bool.nobool foobar &&
git-config --bool --get bool.nobool'
+test_expect_failure 'invalid bool (set)' '
+
+ git-config --bool bool.nobool foobar'
+
+rm .git/config
+
+cat > expect <<\EOF
+[bool]
+ true1 = true
+ true2 = true
+ true3 = true
+ true4 = true
+ false1 = false
+ false2 = false
+ false3 = false
+ false4 = false
+EOF
+
+test_expect_success 'set --bool' '
+
+ git-config --bool bool.true1 01 &&
+ git-config --bool bool.true2 -1 &&
+ git-config --bool bool.true3 YeS &&
+ git-config --bool bool.true4 true &&
+ git-config --bool bool.false1 000 &&
+ git-config --bool bool.false2 "" &&
+ git-config --bool bool.false3 nO &&
+ git-config --bool bool.false4 FALSE &&
+ cmp expect .git/config'
+
+rm .git/config
+
+cat > expect <<\EOF
+[int]
+ val1 = 1
+ val2 = -1
+ val3 = 5242880
+EOF
+
+test_expect_success 'set --int' '
+
+ git-config --int int.val1 01 &&
+ git-config --int int.val2 -1 &&
+ git-config --int int.val3 5m &&
+ cmp expect .git/config'
+
rm .git/config
git-config quote.leading " test"
diff --git a/t/t9400-git-cvsserver-server.sh b/t/t9400-git-cvsserver-server.sh
index 0331770..641303e 100755
--- a/t/t9400-git-cvsserver-server.sh
+++ b/t/t9400-git-cvsserver-server.sh
@@ -38,7 +38,7 @@ echo >empty &&
git commit -q -m "First Commit" &&
git clone -q --local --bare "$WORKDIR/.git" "$SERVERDIR" >/dev/null 2>&1 &&
GIT_DIR="$SERVERDIR" git config --bool gitcvs.enabled true &&
- GIT_DIR="$SERVERDIR" git config --bool gitcvs.logfile "$SERVERDIR/gitcvs.log" ||
+ GIT_DIR="$SERVERDIR" git config gitcvs.logfile "$SERVERDIR/gitcvs.log" ||
exit 1
# note that cvs doesn't accept absolute pathnames
@@ -255,7 +255,7 @@ rm -fr "$SERVERDIR"
cd "$WORKDIR" &&
git clone -q --local --bare "$WORKDIR/.git" "$SERVERDIR" >/dev/null 2>&1 &&
GIT_DIR="$SERVERDIR" git config --bool gitcvs.enabled true &&
-GIT_DIR="$SERVERDIR" git config --bool gitcvs.logfile "$SERVERDIR/gitcvs.log" ||
+GIT_DIR="$SERVERDIR" git config gitcvs.logfile "$SERVERDIR/gitcvs.log" ||
exit 1
test_expect_success 'cvs update (create new file)' \
--
1.5.2.1
^ permalink raw reply related
* Re: [PATCH 2/2] Check for IO errors after running a command
From: Jim Meyering @ 2007-06-25 14:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git, Matthias Lederhofer
In-Reply-To: <7vy7i8xtap.fsf@assigned-by-dhcp.pobox.com>
Junio C Hamano <gitster@pobox.com> wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
...
>> For example, then we could just do
>>
>> status = p->fn(...);
>> if (status)
>> return status;
>> /* Somebody closed stdout? */
>> if (fstat(fileno(stdout), &st))
>> return 0;
>> /* Ignore write errors for pipes and sockets.. */
>> if (S_ISFIFO(st.st_mode) || S_ISSOCK(st.st_mode))
>> return 0;
>>
>> which makes it easy to explain what's going on, and avoids having any deep
>> indentation at all.
>
> I took the liberty of munging your two patches to follow your
> comments above
That has the disadvantage of ignoring *all* pipe and socket write errors.
IMHO, git would be better served if it didn't do that, since writing to
those can fail with EIO and even a new one: EACCES (though this latter
is only for sockets). Also possible, according to POSIX: ENOBUFS.
Of course, one can probably argue that those are all unlikely.
They may be even less likely than an actual EPIPE, but the point is
that people and tools using git plumbing should be able to rely on
it to report such write failures, no matter how unusual they are.
^ permalink raw reply
* [PATCH 1/3] config: Complete documentation of --get-regexp
From: Frank Lichtenheld @ 2007-06-25 14:03 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Jakub Narebski, Frank Lichtenheld
In-Reply-To: <200706220156.01175.jnareb@gmail.com>
The asciidoc documentation of the --get-regexp option was
incomplete. Add some missing pieces:
- List the option in SYNOPSIS
- Mention that key names are printed
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
---
Documentation/git-config.txt | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
index f2c6717..bb6dbb0 100644
--- a/Documentation/git-config.txt
+++ b/Documentation/git-config.txt
@@ -14,6 +14,7 @@ SYNOPSIS
'git-config' [--system | --global] --replace-all name [value [value_regex]]
'git-config' [--system | --global] [type] --get name [value_regex]
'git-config' [--system | --global] [type] --get-all name [value_regex]
+'git-config' [--system | --global] [type] --get-regexp name_regex [value_regex]
'git-config' [--system | --global] --unset name [value_regex]
'git-config' [--system | --global] --unset-all name [value_regex]
'git-config' [--system | --global] --rename-section old_name new_name
@@ -73,6 +74,7 @@ OPTIONS
--get-regexp::
Like --get-all, but interprets the name as a regular expression.
+ Also outputs the key names.
--global::
For writing options: write to global ~/.gitconfig file rather than
--
1.5.2.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox