* Re: git over rsync+ssh
From: Teemu Likonen @ 2008-07-09 17:17 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Michael J Gruber, git
In-Reply-To: <32541b130807090902q2cdc9fcbg6f685dcb96407644@mail.gmail.com>
Avery Pennarun wrote (2008-07-09 12:02 -0400):
> I don't know if this will help in your case, but if it will be only
> you pushing to this repository, one option is to simply create a bare
> push repository on your local machine, and then manually just
> rsync+ssh it to the remote machine from the command line as
> a so-called "push" operation.
Again, I don't know if this is helpful for Michael, but this "manual"
rsyncing can be done automatically via hooks/post-receive. Just like
Avery said, "git push" to a bare repository in a local machine and this
bare repo has post-receive hook which does "git update-server-info" and
the rsyncing (or "sitecopy --update" or similar).
^ permalink raw reply
* Re: Idea: "live branches"?
From: Johannes Schindelin @ 2008-07-09 17:00 UTC (permalink / raw)
To: Jan Rychter; +Cc: git
In-Reply-To: <m28wwbz8h7.fsf@tnuctip.rychter.com>
Hi,
On Wed, 9 Jul 2008, Jan Rychter wrote:
> Which brings me to my point. I think we need a system that can maintain
> "live branches". We already have impressive systems for dealing with
> patches and we have made the patch into a first-class citizen of our
> software development world. Now, instead of statically tracking commits
> and following a one-way development history, let's have live branches --
> branches that can change, causing code that depends on them to change.
>
> The way this would work is I would have one or two long-term development
> branches, and each of those would depend on a list of "live branches",
> managed by a tool similar to StGIT. I should be able to commit to either
> the main development branch, or to one of the "live branches", in which
> case I should be able to easily "resync" the main development branch (do
> a merge or a rebase, but I would prefer the tool to first remove old
> merge commits, so as not to clutter history).
It should be very easy to write a small shell script which expects some
config variable
branch.<currentBranchName>.liveBranches
which contains a list of (local) branches. It would then just look which
of those branches contains newer commits, finds the merges that pulled
those branches in, and redoes those merges (and the commits). It would
rely heavily on "git reset" and on an untampered-with merge message.
The main loop would look a little bit like this:
git rev-list --parents <first-merge-to-be-replaced>^ |
while read commit parent otherparents
do
case "$otherparents" in
'')
git cherry-pick $commit
;;
*)
case " $commit " in
" $mergestoberedone ")
;;
*)
message="$(git cat-file commit $commit |
sed '/^$/q')"
git merge -m "$message" $otherparents
;;
esac
done
# merge changes branches
No wizardry required.
> The tool should also let me pick a commit I've made and move it to one
> of the live branches easily (similar to stgit).
That is relatively simple, using "git checkout <branch> && git cherry-pick
<commit> && git checkout <formerBranch> && git resync-live-branches".
I strongly suggest writing that script, and seeing if it is useful for
you. If it is, just submit it and earn all the glory.
Hth,
Dscho
^ permalink raw reply
* Re: Idea: "live branches"?
From: Avery Pennarun @ 2008-07-09 16:48 UTC (permalink / raw)
To: Jan Rychter; +Cc: git
In-Reply-To: <m28wwbz8h7.fsf@tnuctip.rychter.com>
On 7/9/08, Jan Rychter <jan@rychter.com> wrote:
> The way this would work is I would have one or two long-term development
> branches, and each of those would depend on a list of "live branches",
> managed by a tool similar to StGIT. I should be able to commit to either
> the main development branch, or to one of the "live branches", in which
> case I should be able to easily "resync" the main development branch (do
> a merge or a rebase, but I would prefer the tool to first remove old
> merge commits, so as not to clutter history).
Hmm, git rebase already removes old merge commits. In my own
workflow, I tend to do repeated merges of the "live branch" into my
feature branches during development, then do a rebase occasionally to
clean up the patch set, especially right before merging it into
master. This seems pretty painless to me. What specific problem are
you having that prevents this from working?
Have fun,
Avery
^ permalink raw reply
* Re: Merging a foreign tree into a bare repository.
From: Alejandro Riveira @ 2008-07-09 14:25 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.0807090238561.5277@eeepc-johanness>
El Wed, 09 Jul 2008 02:40:52 +0200, Johannes Schindelin escribió:
>
> Hth,
> Dscho "who wonders what No Such Agency does with Git..."
SELinux development ?? :P
^ permalink raw reply
* Idea: "live branches"?
From: Jan Rychter @ 2008-07-09 9:56 UTC (permalink / raw)
To: git
I've been trying out a number of DVCS tools recently and finally found
that git is the best fit for me. There is one thing I found missing,
though.
The problem is that there are usually two distinct concepts:
-- topic branches, representing longer-term ongoing development in a
certain direction, large-scale features, etc,
-- patches that represent complete functionality, to be committed
upstream, but continuously improved.
My local repositories are usually a combination of both. I will often
have a number of feature patches that I don't want to push upstream just
yet. These patches change often. My topic branches will all want to use
them, in their latest form/revision. This is not a workflow that you can
easily represent with any of today's DVCS tools. One can do this with
careful cherry-picking and merging, but it is a lot of manual work and
clutters up history with lots of merge commits.
StGIT is *almost* there. It lets you manage a pile of patches, modify
them, apply them selectively, as well as update the mainstream
repository and reapply local patches. It fails in two ways: 1) when you
want to reuse the same patches on multiple branches. One-way migration
is doable (not pleasant, but doable), but if you modify a patch in one
of your branches, your other branches which use the same patch will not
see the change. And 2) StGIT patches are simple by design, and you can't
have internal commit history within a patch, which is a problem for
larger features.
Which brings me to my point. I think we need a system that can maintain
"live branches". We already have impressive systems for dealing with
patches and we have made the patch into a first-class citizen of our
software development world. Now, instead of statically tracking commits
and following a one-way development history, let's have live branches --
branches that can change, causing code that depends on them to change.
The way this would work is I would have one or two long-term development
branches, and each of those would depend on a list of "live branches",
managed by a tool similar to StGIT. I should be able to commit to either
the main development branch, or to one of the "live branches", in which
case I should be able to easily "resync" the main development branch (do
a merge or a rebase, but I would prefer the tool to first remove old
merge commits, so as not to clutter history).
The tool should also let me pick a commit I've made and move it to one
of the live branches easily (similar to stgit).
Does this make sense, or am I missing something very obvious?
--J.
PS: I am obviously aware that this is something which is suitable for
local development work only.
^ permalink raw reply
* Re: [RFC/PATCH (WIP)] Git.pm: Add get_config() method and related subroutines
From: Petr Baudis @ 2008-07-09 16:03 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Lea Wiemann
In-Reply-To: <200807031824.55958.jnareb@gmail.com>
Hi!
On Thu, Jul 03, 2008 at 06:24:53PM +0200, Jakub Narebski wrote:
> There are also a few things which I'd like some comments about:
>
> * Do config_val_to_bool and config_val_to_int should be exported
> by default?
Yes with the current API, not with object API (see below). But if
exported by default, there should be definitely a git_ prefix.
> * Should config_val_to_bool and config_val_to_int throw error or
> just return 'undef' on invalid values? One can check if variable
> is defined using "exists($config_hash{'varname'})".
I think that it's more reasonable to throw an error here (as long as
you don't throw an error on undef argument). This particular case is
clearly a misconfiguration by the user and you rarely need to handle
this more gracefully, I believe.
> * How config_val_to_bool etc. should be named? Perhaps just
> config_to_bool, like in gitweb?
What about Git::Config::bool()? ;-) (See below.)
> * Is "return wantarray ? %config : \%config;" DWIM-mery good style?
> I am _not_ a Perl hacker...
I maybe wouldn't be as liberal myself, but I can't tell if it's a bad
style either.
> * Should ->get_config() use ->command_output_pipe, or simpler
> ->command() method, reading whole config into array?
You have the code written already, I'd stick with it.
> * What should ->get_config() have as an optional parameter:
> PREFIX (/^$prefix/o), or simply SECTION (/^(?:$section)\./o)?
Do we even _need_ a parameter like that? I don't understand what is
this interface trying to address.
> * Should we perltie hash?
I agree with Lea that we should actually bless it. :-) Returning a
Git::Config object provides a more flexible interface, and you can also
do $repo->get_config()->bool('key') which is quite more elegant way than
the val_ functions, I think. Also, having accessors for special types
lets you return undef when the type really isn't defined, instead of
e.g. true with current config_val_bool, which is clearly bogus and
requires complicated code on the user side.
> As this is an RFC I have not checked if manpage (generated from
> embedded POD documentation) renders correctly.
By the way, unless you know already, you can do that trivially by
issuing:
perldoc perl/Git.pm
--
Petr "Pasky" Baudis
The last good thing written in C++ was the Pachelbel Canon. -- J. Olson
^ permalink raw reply
* Re: git over rsync+ssh
From: Avery Pennarun @ 2008-07-09 16:02 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <g52gbg$si9$1@ger.gmane.org>
On 7/9/08, Michael J Gruber <michaeljgruber+gmane@fastmail.fm> wrote:
> I want to put a git repo on a server where I have ssh access but failed to
> compile git (AIX 5.1, has libz.a but no .so nor headers; compiling
> prerequisite zlib failed, probably due to a botched build environment).
>
> As far as I can see my only option for a private repo is using rsync over
> ssh.
>
> Alas, the rsync:// transport of git seems to imply an rsync daemon
> connection.
>
> How can I specify rsync over ssh as the git transport?
I don't know if this will help in your case, but if it will be only
you pushing to this repository, one option is to simply create a bare
push repository on your local machine, and then manually just
rsync+ssh it to the remote machine from the command line as a
so-called "push" operation.
You would then make the repo available to others over http or
something, which presumably you have available.
Would that work?
Have fun,
Avery
^ permalink raw reply
* Re: [RFC/PATCH (WIP)] Git.pm: Add get_config() method and related subroutines
From: Petr Baudis @ 2008-07-09 15:23 UTC (permalink / raw)
To: Lea Wiemann; +Cc: Jakub Narebski, git
In-Reply-To: <48726D5C.9080801@gmail.com>
On Mon, Jul 07, 2008 at 09:24:12PM +0200, Lea Wiemann wrote:
> Jakub Narebski wrote:
> > Git::Repo / Git::Config could use methods / subroutines from Git.pm;
>
> I don't think that's possible, since Git.pm has a pretty long-running
> (and complicated) instantiation method, whereas Git::Repo has (and must
> have) instantaneous instantiation (without system calls).
There can be an alternative instantiation method that is faster.
> Also, Git.pm is so strange (design-wise) that I'm not very happy with
> depending on it as it is. I'll write more about that later though.
I'm curious to hear about your reservations to Git.pm design when you
get to writing up something. But I think you should have _very_ good
reasons for introducing a completely separate alternative API and show
convincingly why the current one cannot be extended and build upon,
since going that way is bound to get quite messy. Please avoid the NIH
syndrome and don't reinvent the wheel needlessly. ;-)
--
Petr "Pasky" Baudis
The last good thing written in C++ was the Pachelbel Canon. -- J. Olson
^ permalink raw reply
* Re: [PATCH 2/4] git-imap-send: Add support for SSL.
From: Josh Triplett @ 2008-07-09 15:14 UTC (permalink / raw)
To: Robert Shearman; +Cc: git
In-Reply-To: <1215555496-21335-2-git-send-email-robertshearman@gmail.com>
On Tue, 2008-07-08 at 23:18 +0100, Robert Shearman wrote:
> --- a/Documentation/git-imap-send.txt
> +++ b/Documentation/git-imap-send.txt
> @@ -37,10 +37,11 @@ configuration file (shown with examples):
> Tunnel = "ssh -q user@server.com /usr/bin/imapd ./Maildir 2> /dev/null"
>
> [imap]
> - Host = imap.server.com
> + Host = imaps://imap.example.com
> User = bob
> Pass = pwd
> - Port = 143
> + Port = 993
> + sslverify = false
[...]
> @@ -1280,6 +1411,8 @@ git_imap_config(const char *key, const char *val, void *cb)
> server.port = git_config_int( key, val );
> else if (!strcmp( "tunnel", key ))
> server.tunnel = xstrdup( val );
> + else if (!strcmp( "ssl_verify", key ))
> + server.ssl_verify = git_config_bool( key, val );
The example and the code disagree on the name of the
sslverify/ssl_verify option. Also, ssl_verify needs explanation.
- Josh Triplett
^ permalink raw reply
* Re: git over rsync+ssh
From: Mike Ralphson @ 2008-07-09 15:02 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <g52gbg$si9$1@ger.gmane.org>
2008/7/9 Michael J Gruber <michaeljgruber+gmane@fastmail.fm>:
> I want to put a git repo on a server where I have ssh access but failed to
> compile git (AIX 5.1, has libz.a but no .so nor headers; compiling
> prerequisite zlib failed, probably due to a botched build environment).
I can send you a binary to try if you'd like. It would be compiled on
AIX 5.3 but I have to jump through hoops on several non-identically
set-up servers here, so one might work for you.
# ldd /usr/local/bin/git
/usr/local/bin/git needs:
/usr/lib/libc.a(shr.o)
/usr/lib/libz.a(libz.so.1)
/usr/lib/libiconv.a(shr4.o)
/unix
/usr/lib/libcrypt.a(shr.o)
# ar -t /usr/lib/libz.a
libz.so.1
shr.o
Alternatively I can send you what gets installed from zlib-devel.rpm
[1] which you might be able to install in your account's home
directory, and then ./configure --with-zlib=PATH ; gmake might work
for you.
> As far as I can see my only option for a private repo is using rsync over
> ssh.
>
> ... [snipped the bits I know not]
>
> Alternatively, can I maybe compile the bits that git over ssh needs on the
> server side without zlib?
I don't think any git is going to get very far without zlib, as it
won't understand (be able to verify) the object/pack format at all. I
might be wrong about that though.
Mike
[1] ftp://ftp.software.ibm.com/aix/freeSoftware/aixtoolbox/RPMS/ppc/zlib/zlib-1.2.3-4.aix5.2.ppc.rpm
^ permalink raw reply
* git over rsync+ssh
From: Michael J Gruber @ 2008-07-09 14:01 UTC (permalink / raw)
To: git
I want to put a git repo on a server where I have ssh access but failed
to compile git (AIX 5.1, has libz.a but no .so nor headers; compiling
prerequisite zlib failed, probably due to a botched build environment).
As far as I can see my only option for a private repo is using rsync
over ssh.
Alas, the rsync:// transport of git seems to imply an rsync daemon
connection.
How can I specify rsync over ssh as the git transport?
Alternatively, can I maybe compile the bits that git over ssh needs on
the server side without zlib?
Michael
^ permalink raw reply
* Re: [PATCH] better git-submodule status output
From: Johannes Schindelin @ 2008-07-09 13:54 UTC (permalink / raw)
To: Sylvain Joyeux; +Cc: git
In-Reply-To: <20080709134629.GA3848@joyeux>
Hi,
On Wed, 9 Jul 2008, Sylvain Joyeux wrote:
> [Sylvain quoted somebody, but found it funny to let the reader guess]
>
> > On a related note, the long commit name has been a constant nuisance
> > for me. A short commit name is perfectly enough, methinks.
>
> I also think so. The commit ID is completely useless for humans.
> Nonetheless, that would change the git-submodules output which
> (according to someone-that-I-dont-remember) would be a Bad Thing(tm).
Is git-submodule supposed to be plumbing? I don't think so.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] better git-submodule status output
From: Sylvain Joyeux @ 2008-07-09 13:46 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807091427270.5277@eeepc-johanness>
> > On the symbols side, I propose:
> > > submodule commit is a direct descendant of the commit in the
> > superproject
> > < submodule commit is a direct ancestor of the commit in the
> > superproject
> > + no direct relation between submodule commit and commit in the
> > superproject
> > ? the commit in the superproject cannot be found in the submodule
> > (replaces the initial '!' in my patch)
>
> I like the output of "git checkout" when your local branch is not agreeing
> with the tracked branch. Maybe it would be more user-friendly to have
> submodule use that type of message, instead of cryptic single letter?
Mmmm ... Yes that could be a great idea. I'll try it.
> On a related note, the long commit name has been a constant nuisance for
> me. A short commit name is perfectly enough, methinks.
I also think so. The commit ID is completely useless for humans.
Nonetheless, that would change the git-submodules output which
(according to someone-that-I-dont-remember) would be a Bad Thing(tm).
> > - define a git-submodule 'fetch' subcommand which call fetch in each
> > submodule and runs the verbose mode of git-status (can be disabled by
> > a --quiet option).
>
> I like it.
>
> You probably can refactor the code for "update" to do that nicely.
OK
Sylvain
^ permalink raw reply
* Re: GiT and CentOS 5.2
From: David Voit @ 2008-07-09 13:25 UTC (permalink / raw)
To: git
In-Reply-To: <49523.216.185.71.22.1215539200.squirrel@webmail.harte-lyne.ca>
Hi all,
Just use the EPEL packages:
http://wiki.centos.org/AdditionalResources/Repositories?action=show&redirect=Repositories
Maybe not alwaya the newest version, but it works.
David
^ permalink raw reply
* clever(er) file merging tools?
From: Nigel Magnay @ 2008-07-09 13:16 UTC (permalink / raw)
To: Git Mailing List
This isn't git-specific, but since git users tend to merge more often
there might be some good knowledge here.
My usual practice in merging is to issue the merge, then use 'git
mergetool' to cope with conflicts. On my mac, that fires up opendiff,
which does a reasonable (I guess) attempt at unpicking the changes and
allowing me to choose.
Sometimes, however, probably due to complexity, it spits out a huge
section of the file as being in conflict. Examining it, I always end
up getting annoyed, since for a lot of the file, the changes aren't in
conflict at all - whole (java) functions are in the conflict area
where they're actually the same.
I have wondered if I could pre-filter the sourcecode through something
like Jalopy to re-order all the blocks into a common ordering. But I
also wondered if there were any merge tools that (say) understand the
structure of Java and use it to compare at a method declaration level
rather than as a big text document? Maybe just opendiff isn't the best
(though I quite like the interface as it's easy to understand and the
price is right...)
^ permalink raw reply
* submodules and interaction with GIT
From: Pierre Habouzit @ 2008-07-09 13:07 UTC (permalink / raw)
To: Git ML; +Cc: Junio C Hamano, Lars Hjemli
[-- Attachment #1: Type: text/plain, Size: 4995 bytes --]
Let's start with a bit of context. We have this __huge__ "put everything
in it"-repository at work, and we want to strip out core modules and
integrate them in our different projects through submodules. We moved
away one of our core libraries into its separate git repository, and it
became a submodule in our big fat repository. I believe it's the kind of
things we said people should do when they need partial checkouts
(tree-wise) so I assume the workflow I describe here is decent.
Just to make things clearer, we have two branches in this repository,
'maint' and 'master'. Maint is the branch for the production product,
master is the one where devel happens. 'maint' is obviously merged into
'master' on a regular basis.
Problem 1: directory/submodule conflicts (aka D/S)
---------
Our first problem was that git doesn't deal with D/S conflicts well. To
migrate our repository, I went into 'maint' and did:
$ git rm -rf corelib
$ git submodule add -b corelib/master -- <our-repo> corelib
$ git commit -asm'replace corelib with a submodule'
Then I went into 'master' and did:
$ git merge maint
Here it failed horribly because it claimed that the merge would clobber
untracked files like corelib/.gitignore which was a previously tracked
file in the huge repository and is now tracked in the submodule.
I worked that around by having an intermediate commit that removes
'corelib' in 'master'. Unpretty, but works. Later, when other
developers updated their trees, they had all kinds of really distateful
issues related to D/S conflicts.
Problem 2: integration with git-checkout
---------
When using submodules, when I do updates to the corelib, like fixing a
bug, hence I want it to appear in 'maint', I go to maint and basically
do:
$ cd corelib
$ git fetch
$ git reset --hard origin/corelib/master # so that I have the fix
$ cd ..
$ git commit -asm'update corelib for bug#nnn'
When then I `git checkout master`, the corelib submodule had no
modifications in 'maint' but remains in its 'maint' state when I go to
master instead of what I would like: see it be checkout to its 'master'
state, and refuse to checkout if the submodule cannot perform the
checkout.
I'd really like git checkout -m to also perform a git checkout -m in
submodules.
And along the road, one has a lot of frightening errors:
fatal: cannot read object b8f1177da31281682feb79c9d4290a88edf067ae 'corelib~Updated upstream': It is a submodule!
I quite understand that in presence of submodules git checkout works
becomes quite harder as you have to check for every submodule plus
yourself to know if you can perform the checkout, but I don't really see
why it can't be done.
Problem 3: similar problem with git-reset
---------
Really, I type git reset --hard all the time to undo my local changes.
And I know while typing that it destroys local changes. Really, it
should reset the submodules to their supposed state as well.
Problem 4: merging
---------
When merging two branches, there is a strategy that I believe is
applicable for submodules. If one of the two submodules states is a
direct ancestor from the other, then the merge result shall be the
descendant.
When revisions are not in direct line, then it shall be a conflict.
Problem 5: fetching
---------
`git fetch` should fetch submodules too. Arguably, if you type `git
fetch REMOTE` then any submodule that has a corresponding "REMOTE"
configured should fetch it.
Notes:
-----
When you cannot know something required for conflicts handling e.g.,
(because you haven't enough history for the submodules) the command
shall fail asking the user to fetch the incriminated submodules. IOW
when you perform any action that involves submodules, each submodules
must be queried to know if it can performs the action, and git shall
fail if it's not the case and do nothing.
Wrt most of the behaviours I described, I would be fine if those were
enabled only by a configuration flag in the .gitmodules, and that user
can override in their .git/config. We could have a
submodule.<module>.commandsMustRecurse setting to tell
fetch/reset/checkout/... to behave like I said with this module. I
believe that true should be the default.
Non initialized submodules should be considered as always up to date for
all of this, so that people that don't want to waste bandwidth for this
or this submodule can work peacefully.
Okay, I'm sure there are tons of other uses of submodules out there for
which this is an overkill, but if we really intend seriously to tell
people "do use submodules to avoid having incredibly huge repositories"
like we did in the past, we should really improve the overall usability.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCHv2] rerere: Separate libgit and builtin functions
From: Stephan Beyer @ 2008-07-09 12:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git, Stephan Beyer
In-Reply-To: <20080709120030.GA10528@leksak.fem-net>
This patch moves rerere()-related functions into a newly created
rerere.c file.
The setup_rerere() function is needed by both rerere() and cmd_rerere(),
so this function is moved to rerere.c and declared non-static (and "extern")
in newly created rerere.h file.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
---
Hi again,
so now it should apply cleanly.
Seems that I had not built the topic branch of the former patch
on top of the latest master by accident.
Regards,
Stephan
Makefile | 2 +
builtin-commit.c | 1 +
builtin-rerere.c | 362 ++---------------------------------------
commit.h | 1 -
builtin-rerere.c => rerere.c | 129 +---------------
rerere.h | 9 +
6 files changed, 33 insertions(+), 471 deletions(-)
copy builtin-rerere.c => rerere.c (71%)
create mode 100644 rerere.h
diff --git a/Makefile b/Makefile
index 4796565..de15163 100644
--- a/Makefile
+++ b/Makefile
@@ -363,6 +363,7 @@ LIB_H += quote.h
LIB_H += reflog-walk.h
LIB_H += refs.h
LIB_H += remote.h
+LIB_H += rerere.h
LIB_H += revision.h
LIB_H += run-command.h
LIB_H += sha1-lookup.h
@@ -447,6 +448,7 @@ LIB_OBJS += read-cache.o
LIB_OBJS += reflog-walk.o
LIB_OBJS += refs.o
LIB_OBJS += remote.o
+LIB_OBJS += rerere.o
LIB_OBJS += revision.o
LIB_OBJS += run-command.o
LIB_OBJS += server-info.o
diff --git a/builtin-commit.c b/builtin-commit.c
index 745c11e..bdc83df 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -22,6 +22,7 @@
#include "utf8.h"
#include "parse-options.h"
#include "path-list.h"
+#include "rerere.h"
#include "unpack-trees.h"
static const char * const builtin_commit_usage[] = {
diff --git a/builtin-rerere.c b/builtin-rerere.c
index 839b26e..5d40e16 100644
--- a/builtin-rerere.c
+++ b/builtin-rerere.c
@@ -1,11 +1,10 @@
#include "builtin.h"
#include "cache.h"
#include "path-list.h"
+#include "rerere.h"
#include "xdiff/xdiff.h"
#include "xdiff-interface.h"
-#include <time.h>
-
static const char git_rerere_usage[] =
"git-rerere [clear | status | diff | gc]";
@@ -13,14 +12,6 @@ static const char git_rerere_usage[] =
static int cutoff_noresolve = 15;
static int cutoff_resolve = 60;
-/* if rerere_enabled == -1, fall back to detection of .git/rr-cache */
-static int rerere_enabled = -1;
-
-/* automatically update cleanly resolved paths to the index */
-static int rerere_autoupdate;
-
-static char *merge_rr_path;
-
static const char *rr_path(const char *name, const char *file)
{
return git_path("rr-cache/%s/%s", name, file);
@@ -38,179 +29,6 @@ static int has_resolution(const char *name)
return !stat(rr_path(name, "postimage"), &st);
}
-static void read_rr(struct path_list *rr)
-{
- unsigned char sha1[20];
- char buf[PATH_MAX];
- FILE *in = fopen(merge_rr_path, "r");
- if (!in)
- return;
- while (fread(buf, 40, 1, in) == 1) {
- int i;
- char *name;
- if (get_sha1_hex(buf, sha1))
- die("corrupt MERGE_RR");
- buf[40] = '\0';
- name = xstrdup(buf);
- if (fgetc(in) != '\t')
- die("corrupt MERGE_RR");
- for (i = 0; i < sizeof(buf) && (buf[i] = fgetc(in)); i++)
- ; /* do nothing */
- if (i == sizeof(buf))
- die("filename too long");
- path_list_insert(buf, rr)->util = name;
- }
- fclose(in);
-}
-
-static struct lock_file write_lock;
-
-static int write_rr(struct path_list *rr, int out_fd)
-{
- int i;
- for (i = 0; i < rr->nr; i++) {
- const char *path;
- int length;
- if (!rr->items[i].util)
- continue;
- path = rr->items[i].path;
- length = strlen(path) + 1;
- if (write_in_full(out_fd, rr->items[i].util, 40) != 40 ||
- write_in_full(out_fd, "\t", 1) != 1 ||
- write_in_full(out_fd, path, length) != length)
- die("unable to write rerere record");
- }
- if (commit_lock_file(&write_lock) != 0)
- die("unable to write rerere record");
- return 0;
-}
-
-static int handle_file(const char *path,
- unsigned char *sha1, const char *output)
-{
- SHA_CTX ctx;
- char buf[1024];
- int hunk = 0, hunk_no = 0;
- struct strbuf one, two;
- FILE *f = fopen(path, "r");
- FILE *out = NULL;
-
- if (!f)
- return error("Could not open %s", path);
-
- if (output) {
- out = fopen(output, "w");
- if (!out) {
- fclose(f);
- return error("Could not write %s", output);
- }
- }
-
- if (sha1)
- SHA1_Init(&ctx);
-
- strbuf_init(&one, 0);
- strbuf_init(&two, 0);
- while (fgets(buf, sizeof(buf), f)) {
- if (!prefixcmp(buf, "<<<<<<< "))
- hunk = 1;
- else if (!prefixcmp(buf, "======="))
- hunk = 2;
- else if (!prefixcmp(buf, ">>>>>>> ")) {
- if (strbuf_cmp(&one, &two) > 0)
- strbuf_swap(&one, &two);
- hunk_no++;
- hunk = 0;
- if (out) {
- fputs("<<<<<<<\n", out);
- fwrite(one.buf, one.len, 1, out);
- fputs("=======\n", out);
- fwrite(two.buf, two.len, 1, out);
- fputs(">>>>>>>\n", out);
- }
- if (sha1) {
- SHA1_Update(&ctx, one.buf ? one.buf : "",
- one.len + 1);
- SHA1_Update(&ctx, two.buf ? two.buf : "",
- two.len + 1);
- }
- strbuf_reset(&one);
- strbuf_reset(&two);
- } else if (hunk == 1)
- strbuf_addstr(&one, buf);
- else if (hunk == 2)
- strbuf_addstr(&two, buf);
- else if (out)
- fputs(buf, out);
- }
- strbuf_release(&one);
- strbuf_release(&two);
-
- fclose(f);
- if (out)
- fclose(out);
- if (sha1)
- SHA1_Final(sha1, &ctx);
- if (hunk) {
- if (output)
- unlink(output);
- return error("Could not parse conflict hunks in %s", path);
- }
- return hunk_no;
-}
-
-static int find_conflict(struct path_list *conflict)
-{
- int i;
- if (read_cache() < 0)
- return error("Could not read index");
- for (i = 0; i+1 < active_nr; i++) {
- struct cache_entry *e2 = active_cache[i];
- struct cache_entry *e3 = active_cache[i+1];
- if (ce_stage(e2) == 2 &&
- ce_stage(e3) == 3 &&
- ce_same_name(e2, e3) &&
- S_ISREG(e2->ce_mode) &&
- S_ISREG(e3->ce_mode)) {
- path_list_insert((const char *)e2->name, conflict);
- i++; /* skip over both #2 and #3 */
- }
- }
- return 0;
-}
-
-static int merge(const char *name, const char *path)
-{
- int ret;
- mmfile_t cur, base, other;
- mmbuffer_t result = {NULL, 0};
- xpparam_t xpp = {XDF_NEED_MINIMAL};
-
- if (handle_file(path, NULL, rr_path(name, "thisimage")) < 0)
- return 1;
-
- if (read_mmfile(&cur, rr_path(name, "thisimage")) ||
- read_mmfile(&base, rr_path(name, "preimage")) ||
- read_mmfile(&other, rr_path(name, "postimage")))
- return 1;
- ret = xdl_merge(&base, &cur, "", &other, "",
- &xpp, XDL_MERGE_ZEALOUS, &result);
- if (!ret) {
- FILE *f = fopen(path, "w");
- if (!f)
- return error("Could not write to %s", path);
- fwrite(result.ptr, result.size, 1, f);
- fclose(f);
- }
-
- free(cur.ptr);
- free(base.ptr);
- free(other.ptr);
- free(result.ptr);
-
- return ret;
-}
-
static void unlink_rr_item(const char *name)
{
unlink(rr_path(name, "thisimage"));
@@ -219,6 +37,17 @@ static void unlink_rr_item(const char *name)
rmdir(git_path("rr-cache/%s", name));
}
+static int git_rerere_gc_config(const char *var, const char *value, void *cb)
+{
+ if (!strcmp(var, "gc.rerereresolved"))
+ cutoff_resolve = git_config_int(var, value);
+ else if (!strcmp(var, "gc.rerereunresolved"))
+ cutoff_noresolve = git_config_int(var, value);
+ else
+ return git_default_config(var, value, cb);
+ return 0;
+}
+
static void garbage_collect(struct path_list *rr)
{
struct path_list to_remove = { NULL, 0, 0, 1 };
@@ -227,6 +56,7 @@ static void garbage_collect(struct path_list *rr)
int i, cutoff;
time_t now = time(NULL), then;
+ git_config(git_rerere_gc_config, NULL);
dir = opendir(git_path("rr-cache"));
while ((e = readdir(dir))) {
const char *name = e->d_name;
@@ -279,181 +109,25 @@ static int diff_two(const char *file1, const char *label1,
return 0;
}
-static struct lock_file index_lock;
-
-static int update_paths(struct path_list *update)
-{
- int i;
- int fd = hold_locked_index(&index_lock, 0);
- int status = 0;
-
- if (fd < 0)
- return -1;
-
- for (i = 0; i < update->nr; i++) {
- struct path_list_item *item = &update->items[i];
- if (add_file_to_cache(item->path, ADD_CACHE_IGNORE_ERRORS))
- status = -1;
- }
-
- if (!status && active_cache_changed) {
- if (write_cache(fd, active_cache, active_nr) ||
- commit_locked_index(&index_lock))
- die("Unable to write new index file");
- } else if (fd >= 0)
- rollback_lock_file(&index_lock);
- return status;
-}
-
-static int do_plain_rerere(struct path_list *rr, int fd)
-{
- struct path_list conflict = { NULL, 0, 0, 1 };
- struct path_list update = { NULL, 0, 0, 1 };
- int i;
-
- find_conflict(&conflict);
-
- /*
- * MERGE_RR records paths with conflicts immediately after merge
- * failed. Some of the conflicted paths might have been hand resolved
- * in the working tree since then, but the initial run would catch all
- * and register their preimages.
- */
-
- for (i = 0; i < conflict.nr; i++) {
- const char *path = conflict.items[i].path;
- if (!path_list_has_path(rr, path)) {
- unsigned char sha1[20];
- char *hex;
- int ret;
- ret = handle_file(path, sha1, NULL);
- if (ret < 1)
- continue;
- hex = xstrdup(sha1_to_hex(sha1));
- path_list_insert(path, rr)->util = hex;
- if (mkdir(git_path("rr-cache/%s", hex), 0755))
- continue;;
- handle_file(path, NULL, rr_path(hex, "preimage"));
- fprintf(stderr, "Recorded preimage for '%s'\n", path);
- }
- }
-
- /*
- * Now some of the paths that had conflicts earlier might have been
- * hand resolved. Others may be similar to a conflict already that
- * was resolved before.
- */
-
- for (i = 0; i < rr->nr; i++) {
- int ret;
- const char *path = rr->items[i].path;
- const char *name = (const char *)rr->items[i].util;
-
- if (has_resolution(name)) {
- if (!merge(name, path)) {
- fprintf(stderr, "Resolved '%s' using "
- "previous resolution.\n", path);
- if (rerere_autoupdate)
- path_list_insert(path, &update);
- goto mark_resolved;
- }
- }
-
- /* Let's see if we have resolved it. */
- ret = handle_file(path, NULL, NULL);
- if (ret)
- continue;
-
- fprintf(stderr, "Recorded resolution for '%s'.\n", path);
- copy_file(rr_path(name, "postimage"), path, 0666);
- mark_resolved:
- rr->items[i].util = NULL;
- }
-
- if (update.nr)
- update_paths(&update);
-
- return write_rr(rr, fd);
-}
-
-static int git_rerere_config(const char *var, const char *value, void *cb)
-{
- if (!strcmp(var, "gc.rerereresolved"))
- cutoff_resolve = git_config_int(var, value);
- else if (!strcmp(var, "gc.rerereunresolved"))
- cutoff_noresolve = git_config_int(var, value);
- else if (!strcmp(var, "rerere.enabled"))
- rerere_enabled = git_config_bool(var, value);
- else if (!strcmp(var, "rerere.autoupdate"))
- rerere_autoupdate = git_config_bool(var, value);
- else
- return git_default_config(var, value, cb);
- return 0;
-}
-
-static int is_rerere_enabled(void)
-{
- struct stat st;
- const char *rr_cache;
- int rr_cache_exists;
-
- if (!rerere_enabled)
- return 0;
-
- rr_cache = git_path("rr-cache");
- rr_cache_exists = !stat(rr_cache, &st) && S_ISDIR(st.st_mode);
- if (rerere_enabled < 0)
- return rr_cache_exists;
-
- if (!rr_cache_exists &&
- (mkdir(rr_cache, 0777) || adjust_shared_perm(rr_cache)))
- die("Could not create directory %s", rr_cache);
- return 1;
-}
-
-static int setup_rerere(struct path_list *merge_rr)
-{
- int fd;
-
- git_config(git_rerere_config, NULL);
- if (!is_rerere_enabled())
- return -1;
-
- merge_rr_path = xstrdup(git_path("rr-cache/MERGE_RR"));
- fd = hold_lock_file_for_update(&write_lock, merge_rr_path, 1);
- read_rr(merge_rr);
- return fd;
-}
-
-int rerere(void)
-{
- struct path_list merge_rr = { NULL, 0, 0, 1 };
- int fd;
-
- fd = setup_rerere(&merge_rr);
- if (fd < 0)
- return 0;
- return do_plain_rerere(&merge_rr, fd);
-}
-
int cmd_rerere(int argc, const char **argv, const char *prefix)
{
struct path_list merge_rr = { NULL, 0, 0, 1 };
int i, fd;
+ if (argc < 2)
+ return rerere();
+
fd = setup_rerere(&merge_rr);
if (fd < 0)
return 0;
- if (argc < 2)
- return do_plain_rerere(&merge_rr, fd);
- else if (!strcmp(argv[1], "clear")) {
+ if (!strcmp(argv[1], "clear")) {
for (i = 0; i < merge_rr.nr; i++) {
const char *name = (const char *)merge_rr.items[i].util;
if (!has_resolution(name))
unlink_rr_item(name);
}
- unlink(merge_rr_path);
+ unlink(git_path("rr-cache/MERGE_RR"));
} else if (!strcmp(argv[1], "gc"))
garbage_collect(&merge_rr);
else if (!strcmp(argv[1], "status"))
diff --git a/commit.h b/commit.h
index 2d94d41..fda7ad0 100644
--- a/commit.h
+++ b/commit.h
@@ -131,7 +131,6 @@ extern struct commit_list *get_shallow_commits(struct object_array *heads,
int in_merge_bases(struct commit *, struct commit **, int);
extern int interactive_add(int argc, const char **argv, const char *prefix);
-extern int rerere(void);
static inline int single_parent(struct commit *commit)
{
diff --git a/builtin-rerere.c b/rerere.c
similarity index 71%
copy from builtin-rerere.c
copy to rerere.c
index 839b26e..bbd8c00 100644
--- a/builtin-rerere.c
+++ b/rerere.c
@@ -1,18 +1,9 @@
-#include "builtin.h"
#include "cache.h"
#include "path-list.h"
+#include "rerere.h"
#include "xdiff/xdiff.h"
#include "xdiff-interface.h"
-#include <time.h>
-
-static const char git_rerere_usage[] =
-"git-rerere [clear | status | diff | gc]";
-
-/* these values are days */
-static int cutoff_noresolve = 15;
-static int cutoff_resolve = 60;
-
/* if rerere_enabled == -1, fall back to detection of .git/rr-cache */
static int rerere_enabled = -1;
@@ -26,12 +17,6 @@ static const char *rr_path(const char *name, const char *file)
return git_path("rr-cache/%s/%s", name, file);
}
-static time_t rerere_created_at(const char *name)
-{
- struct stat st;
- return stat(rr_path(name, "preimage"), &st) ? (time_t) 0 : st.st_mtime;
-}
-
static int has_resolution(const char *name)
{
struct stat st;
@@ -211,74 +196,6 @@ static int merge(const char *name, const char *path)
return ret;
}
-static void unlink_rr_item(const char *name)
-{
- unlink(rr_path(name, "thisimage"));
- unlink(rr_path(name, "preimage"));
- unlink(rr_path(name, "postimage"));
- rmdir(git_path("rr-cache/%s", name));
-}
-
-static void garbage_collect(struct path_list *rr)
-{
- struct path_list to_remove = { NULL, 0, 0, 1 };
- DIR *dir;
- struct dirent *e;
- int i, cutoff;
- time_t now = time(NULL), then;
-
- dir = opendir(git_path("rr-cache"));
- while ((e = readdir(dir))) {
- const char *name = e->d_name;
- if (name[0] == '.' &&
- (name[1] == '\0' || (name[1] == '.' && name[2] == '\0')))
- continue;
- then = rerere_created_at(name);
- if (!then)
- continue;
- cutoff = (has_resolution(name)
- ? cutoff_resolve : cutoff_noresolve);
- if (then < now - cutoff * 86400)
- path_list_append(name, &to_remove);
- }
- for (i = 0; i < to_remove.nr; i++)
- unlink_rr_item(to_remove.items[i].path);
- path_list_clear(&to_remove, 0);
-}
-
-static int outf(void *dummy, mmbuffer_t *ptr, int nbuf)
-{
- int i;
- for (i = 0; i < nbuf; i++)
- if (write_in_full(1, ptr[i].ptr, ptr[i].size) != ptr[i].size)
- return -1;
- return 0;
-}
-
-static int diff_two(const char *file1, const char *label1,
- const char *file2, const char *label2)
-{
- xpparam_t xpp;
- xdemitconf_t xecfg;
- xdemitcb_t ecb;
- mmfile_t minus, plus;
-
- if (read_mmfile(&minus, file1) || read_mmfile(&plus, file2))
- return 1;
-
- printf("--- a/%s\n+++ b/%s\n", label1, label2);
- fflush(stdout);
- xpp.flags = XDF_NEED_MINIMAL;
- memset(&xecfg, 0, sizeof(xecfg));
- xecfg.ctxlen = 3;
- ecb.outf = outf;
- xdi_diff(&minus, &plus, &xpp, &xecfg, &ecb);
-
- free(minus.ptr);
- free(plus.ptr);
- return 0;
-}
-
static struct lock_file index_lock;
static int update_paths(struct path_list *update)
@@ -378,11 +295,7 @@ static int do_plain_rerere(struct path_list *rr, int fd)
static int git_rerere_config(const char *var, const char *value, void *cb)
{
- if (!strcmp(var, "gc.rerereresolved"))
- cutoff_resolve = git_config_int(var, value);
- else if (!strcmp(var, "gc.rerereunresolved"))
- cutoff_noresolve = git_config_int(var, value);
- else if (!strcmp(var, "rerere.enabled"))
+ if (!strcmp(var, "rerere.enabled"))
rerere_enabled = git_config_bool(var, value);
else if (!strcmp(var, "rerere.autoupdate"))
rerere_autoupdate = git_config_bool(var, value);
@@ -411,7 +324,7 @@ static int is_rerere_enabled(void)
return 1;
}
-static int setup_rerere(struct path_list *merge_rr)
+int setup_rerere(struct path_list *merge_rr)
{
int fd;
@@ -435,39 +348,3 @@ int rerere(void)
return 0;
return do_plain_rerere(&merge_rr, fd);
}
-
-int cmd_rerere(int argc, const char **argv, const char *prefix)
-{
- struct path_list merge_rr = { NULL, 0, 0, 1 };
- int i, fd;
-
- fd = setup_rerere(&merge_rr);
- if (fd < 0)
- return 0;
-
- if (argc < 2)
- return do_plain_rerere(&merge_rr, fd);
- else if (!strcmp(argv[1], "clear")) {
- for (i = 0; i < merge_rr.nr; i++) {
- const char *name = (const char *)merge_rr.items[i].util;
- if (!has_resolution(name))
- unlink_rr_item(name);
- }
- unlink(merge_rr_path);
- } else if (!strcmp(argv[1], "gc"))
- garbage_collect(&merge_rr);
- else if (!strcmp(argv[1], "status"))
- for (i = 0; i < merge_rr.nr; i++)
- printf("%s\n", merge_rr.items[i].path);
- else if (!strcmp(argv[1], "diff"))
- for (i = 0; i < merge_rr.nr; i++) {
- const char *path = merge_rr.items[i].path;
- const char *name = (const char *)merge_rr.items[i].util;
- diff_two(rr_path(name, "preimage"), path, path, path);
- }
- else
- usage(git_rerere_usage);
-
- path_list_clear(&merge_rr, 1);
- return 0;
-}
diff --git a/rerere.h b/rerere.h
new file mode 100644
index 0000000..35b0fa8
--- /dev/null
+++ b/rerere.h
@@ -0,0 +1,9 @@
+#ifndef RERERE_H
+#define RERERE_H
+
+#include "path-list.h"
+
+extern int setup_rerere(struct path_list *);
+extern int rerere(void);
+
+#endif
--
1.5.6
^ permalink raw reply related
* Re: [PATCH] better git-submodule status output
From: Johannes Schindelin @ 2008-07-09 12:31 UTC (permalink / raw)
To: Sylvain Joyeux; +Cc: git
In-Reply-To: <20080709101330.GA3525@joyeux>
Hi,
On Wed, 9 Jul 2008, Sylvain Joyeux wrote:
> On the symbols side, I propose:
> > submodule commit is a direct descendant of the commit in the
> superproject
> < submodule commit is a direct ancestor of the commit in the
> superproject
> + no direct relation between submodule commit and commit in the
> superproject
> ? the commit in the superproject cannot be found in the submodule
> (replaces the initial '!' in my patch)
I like the output of "git checkout" when your local branch is not agreeing
with the tracked branch. Maybe it would be more user-friendly to have
submodule use that type of message, instead of cryptic single letter?
On a related note, the long commit name has been a constant nuisance for
me. A short commit name is perfectly enough, methinks.
> - define a git-submodule 'fetch' subcommand which call fetch in each
> submodule and runs the verbose mode of git-status (can be disabled by
> a --quiet option).
I like it.
You probably can refactor the code for "update" to do that nicely.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/3] cherry: cache patch-ids to avoid repeating work
From: Johannes Schindelin @ 2008-07-09 12:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Geoffrey Irving, git@vger.kernel.org
In-Reply-To: <7vprpnlglh.fsf@gitster.siamese.dyndns.org>
Hi,
On Tue, 8 Jul 2008, Junio C Hamano wrote:
> Think of this procedure as giving a chance for you to hide early
> embarrassment under the rug ;-)
Further, as Shawn pointed out to me (and you will all be able to hear it
for yourselves soon), these patch iterations give you the chance to apply
all the wisdom of the combined developers on this list to your patch, and
in the end put your name on it :-)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/4] git-imap-send: Allow the program to be run from subdirectories of a git tree.
From: Rob Shearman @ 2008-07-09 12:08 UTC (permalink / raw)
To: Jay Soffian; +Cc: Junio C Hamano, git
In-Reply-To: <76718490807081828k7640d07bp547a69d05a6e07c4@mail.gmail.com>
2008/7/9 Jay Soffian <jaysoffian@gmail.com>:
> On Tue, Jul 8, 2008 at 9:15 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> I thought Jeff already explained why this NULL was a bad idea, but perhaps
>> I was dreaming...
>
> http://article.gmane.org/gmane.comp.version-control.git/87701
Sorry, I missed that message. I'll resend the patch with his suggestion.
--
Rob Shearman
^ permalink raw reply
* Re: [PATCH 4/4] Documentation: Improve documentation for git-imap-send(1).
From: Rob Shearman @ 2008-07-09 12:05 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: git
In-Reply-To: <19AD9080-74BE-4147-8DF5-8A2937129B6D@silverinsanity.com>
2008/7/9 Brian Gernhardt <benji@silverinsanity.com>:
>
> On Jul 8, 2008, at 6:18 PM, Robert Shearman wrote:
>
>> +Using direct mode:
>>
>> +.........................
>> [imap]
>> - Host = imaps://imap.example.com
>> - User = bob
>> - Pass = pwd
>> - Port = 993
>> + folder = "[Gmail]/Drafts"
>> + host = imaps://imap.example.com
>> + user = bob
>> + pass = p4ssw0rd
>> + port = 123
>> sslverify = false
>> ..........................
>
> If you're going to use [Gmail]/Drafts as the example folder, shouldn't you
> just use mail.google.com as your example? Google themselves use
> username@gmail.com as an example[1], so that should be safe. So:
I'll fix it not to use "[Gmail]/Drafts" in the example as that is the
exception rather than the norm.
> And I also assume that someone has tried this with Gmail and it doesn't
> mangle the Drafts.
Yes, as specified in my previous email I tested with two different
IMAP servers, one of which was Gmail.
> I'd also move the sslverify option into the tunneling
> example, as it's more likely to be needed there.
Actually, the sslverify option is ignored in tunnel mode (since you're
likely to be using your own encryption with the tunnel). I'll document
this and other ignored options in a revised patch.
--
Rob Shearman
^ permalink raw reply
* Re: [PATCH] rerere: Separate libgit and builtin functions
From: Johannes Schindelin @ 2008-07-09 12:03 UTC (permalink / raw)
To: Stephan Beyer; +Cc: git, Junio C Hamano
In-Reply-To: <1215598683-9685-1-git-send-email-s-beyer@gmx.net>
Hi,
On Wed, 9 Jul 2008, Stephan Beyer wrote:
> Makefile | 2 +
> builtin-rerere.c | 324 +++---------------------------------------
> builtin-rerere.c => rerere.c | 133 +-----------------
> rerere.h | 9 ++
> 4 files changed, 32 insertions(+), 436 deletions(-)
Heh, that sounds nice! Deleting way more lines than adding! :-)
> copy builtin-rerere.c => rerere.c (66%)
Oh, well :-)
> diff --git a/builtin-rerere.c b/rerere.c
> similarity index 66%
> copy from builtin-rerere.c
> copy to rerere.c
> index 85222d9..5c22bed 100644
> --- a/builtin-rerere.c
> +++ b/rerere.c
> @@ -1,18 +1,11 @@
> -#include "builtin.h"
> #include "cache.h"
> #include "path-list.h"
> +#include "rerere.h"
> #include "xdiff/xdiff.h"
> #include "xdiff-interface.h"
>
> #include <time.h>
No longer necessary, is it?
> diff --git a/rerere.h b/rerere.h
> new file mode 100644
> index 0000000..35b0fa8
> --- /dev/null
> +++ b/rerere.h
> @@ -0,0 +1,9 @@
> +#ifndef RERERE_H
> +#define RERERE_H
> +
> +#include "path-list.h"
> +
> +extern int setup_rerere(struct path_list *);
Why?
Ah, it is needed for "gc". Maybe this needs documentation, since it cause
some minutes of head scratching with yours truly.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/4] git-imap-send: Add support for SSL.
From: Rob Shearman @ 2008-07-09 12:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbq18q7yk.fsf@gitster.siamese.dyndns.org>
2008/7/9 Junio C Hamano <gitster@pobox.com>:
> Robert Shearman <robertshearman@gmail.com> writes:
>> diff --git a/Documentation/git-imap-send.txt b/Documentation/git-imap-send.txt
>> index b3d8da3..e4a5873 100644
>> --- a/Documentation/git-imap-send.txt
>> +++ b/Documentation/git-imap-send.txt
>> @@ -37,10 +37,11 @@ configuration file (shown with examples):
>> Tunnel = "ssh -q user@server.com /usr/bin/imapd ./Maildir 2> /dev/null"
>>
>> [imap]
>> - Host = imap.server.com
>> + Host = imaps://imap.example.com
>> User = bob
>> Pass = pwd
>> - Port = 143
>> + Port = 993
>> + sslverify = false
>> ..........................
>
> Don't we also want to keep a vanilla configuration in the example, or is
> imaps the norm and unencrypted imap is exception these days?
Good point. I'll fix the documentation to use imap:// instead of
imaps:// and not change the port number. However, I'm not sure the
examples should be telling the user what they should do, but rather
what they can do.
> Don't we need to support custom certificates, keys and CAs, just like our
> code that supports https does, by honoring GIT_SSL_* environment variables
> and configuration file entries?
Yes, eventually we will want that support in imap-send too. It should
be fairly trivial to do, although testing will be more difficult.
> The patch itself looks fairly clean, and
> I'd like to queue this for wider testing, initially even without GIT_SSL_*
> support. But I'd like to see any patch with substantial amount of changes
> properly signed off.
Great. I'll resend the series later with changes from the comments
I've received and properly signed-off.
--
Rob Shearman
^ permalink raw reply
* Re: [PATCH] rerere: Separate libgit and builtin functions
From: Stephan Beyer @ 2008-07-09 12:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0807091355220.5277@eeepc-johanness>
> > This patch moves rerere()-related functions into a newly created
> > rerere.c file. Also setup_rerere() is moved into rerere.c to decrease
> > code duplications for rerere.c and builtin-rerere.c.
>
> It is not moved to decrease code duplication, but because it is needed by
> rerere().
Right.
And btw the patch seems to be broken. (At least I can't apply it
here...) Sorry :( Usually I test applying before sending but this time
lunch was eliciting.
Well, I'm going to fix that.
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [PATCH] rerere: Separate libgit and builtin functions
From: Johannes Schindelin @ 2008-07-09 11:55 UTC (permalink / raw)
To: Stephan Beyer; +Cc: git, Junio C Hamano
In-Reply-To: <1215598683-9685-1-git-send-email-s-beyer@gmx.net>
Hi,
On Wed, 9 Jul 2008, Stephan Beyer wrote:
> This patch moves rerere()-related functions into a newly created
> rerere.c file. Also setup_rerere() is moved into rerere.c to decrease
> code duplications for rerere.c and builtin-rerere.c.
It is not moved to decrease code duplication, but because it is needed by
rerere().
Ciao,
Dscho
^ 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