* Re: [PATCH] winansi: support ESC [ K (erase in line)
From: Johannes Schindelin @ 2009-03-10 11:31 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, gitster, Peter Harris, Sebastian Schuberth
In-Reply-To: <49B61377.90103@viscovery.net>
Hi,
On Tue, 10 Mar 2009, Johannes Sixt wrote:
> Johannes Schindelin schrieb:
> > This fixes the last bit of msysGit issue 124 for me:
> >
> > http://code.google.com/p/msysgit/issues/detail?id=124
> >
> > which annoyed me one time to many today.
> >
> > I had an earlier version which was smaller, but pretty hacky, in
> > that it checked if fprintf is #define'd in xwrite(), and had
> > special handling for that case.
> >
> > This patch is only slightly hacky, in that it assumes that you do
> > not try to output something that ends in an incomplete ESC [
> > sequence.
>
> Good that I read mail before I start hacking. I was about to do something
> about this in a moment. ;)
Heh...
> > To make use of it during a fetch, write() needs to be overridden, too.
>
> No, that's not necessary with the patch that I'm about to send in a
> moment. To replace write() for ANSI emulation really goes too far.
See my response to your patch...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/2] grep Added --blame so that grep can show result tagged with blame entries
From: pi song @ 2009-03-10 11:29 UTC (permalink / raw)
To: gitster, git, rene.scharfe
In-Reply-To: <7v7i2xaewh.fsf@gitster.siamese.dyndns.org>
OK, I'll move my work to "next" branch. BTW, can anyone tell me what
the "next" and "pu" branch are for ?
Pi Song
On Tue, Mar 10, 2009 at 8:46 PM, Junio C Hamano <gitster@pobox.com> wrote:
> pi song <pi.songs@gmail.com> writes:
>
>> This part:-
>> 1) Move reusable bits from builtin-blame.c into blame.c, blame.h
>> 2) Replace static variables with context struct
>>
>> Signed-off-by: Pi Song <pi.songs@gmail.com>
>> ---
>> Makefile | 2 +
>> blame.c | 1919 +++++++++++++++++++++++++++++++++++++++++++++++++++
>> blame.h | 222 ++++++
>> builtin-blame.c | 2072
>> +++----------------------------------------------------
>> 4 files changed, 2245 insertions(+), 1970 deletions(-)
>> create mode 100644 blame.c
>> create mode 100644 blame.h
>
> This is simply too big to ask anybody sane to review (besides as we can
> clearly see in the above the patch is severely whitespace damaged to be
> usable nor mechanically reviewable).
>
> I suspect that most of the file-scope static variables can be moved to the
> scoreboard, and when the reusable parts are made public, some structure
> and function names may need to become a bit more blame specific to avoid
> namespace contamination.
>
> Perhaps the first two patches in an equivalent series that is rerolled to
> be reviewable would look like:
>
> (1) move file-scope static variables to the scoreboard, and necessary
> code changes associated with it;
>
> renaming of some structures and functions (if needed---I didn't
> check);
>
> (2) create blame.c and blame.h, and move lines from builtin-blame.c *and*
> do NOTHING OTHER THAN
>
> - adding #include "blame.h" to builtin-blame.c,
>
> - adding necessary #include at the top of blame.c,
>
> - surrounding blame.h with necessary
>
> #ifndef BLAME_H
> #define BLAME_H
> ...
> #endif
>
> and finally
>
> - updating Makefile to add blame.c and blame.h
>
> This step will make a HUGE patch, and it is crucial for reviewability
> for it not to do anything other than line movement. Ideally, the
> patch shouldn't even reorder the structures and function definitions
> during this step.
>
> Then we can use "git blame" itself to make sure that no other changes
> were sneaked in by mistake. "git blame -C blame.h" and "git blame -C
> blame.c" would show everything came from builtin-blame.c.
>
> At this point, there shouldn't still be any behaviour change nor new
> feature. And the titles of these preparatory step will never say anything
> about "grep". They are only refactoring "blame".
>
> Once this becomes solid, you can start adding features to blame.c to
> support your new caller, and we can be reasonably sure that such patches
> can be reviewed to decide if its change breaks the existing (and so far
> the only) caller builtin_blame() or not.
>
^ permalink raw reply
* Re: [PATCH/RFC] recv_sideband: Band #2 always goes to stderr
From: Johannes Sixt @ 2009-03-10 11:17 UTC (permalink / raw)
To: Johannes Schindelin
Cc: git, gitster, Peter Harris, Sebastian Schuberth, Nicolas Pitre
In-Reply-To: <49B64ADC.2090406@viscovery.net>
Johannes Sixt schrieb:
> All data producers and data consumers *in git* use band #2 to transport
> error messages and progress report. GitTorrent cannot not talk to
> upload-pack or upload-archive and expect to get arbitrary binary data over
> band #2.
>
> For use-cases that you have in mind in GitTorrent, the *protocol* may be a
> good choice, but the current implementation is definitely a special case.
And it really is: Did you notice that stuff that recv_sideband sends over
the channel named 'err' (before my patch) has "remote: " prepended on
every line? That's certainly not an implementation that you want if you
send binary data over that band!
-- Hannes
^ permalink raw reply
* Re: [PATCH/RFC] recv_sideband: Band #2 always goes to stderr
From: Johannes Sixt @ 2009-03-10 11:11 UTC (permalink / raw)
To: Johannes Schindelin
Cc: git, gitster, Peter Harris, Sebastian Schuberth, Nicolas Pitre
In-Reply-To: <alpine.DEB.1.00.0903101153250.14295@intel-tinevez-2-302>
Johannes Schindelin schrieb:
> On Tue, 10 Mar 2009, Johannes Sixt wrote:
>> This removes the last parameter of recv_sideband, by which the callers
>> told which channel band #2 data should be written to. Since both callers
>> of the function passed 2 for the parameter, we hereby remove the
>> parameter and send band #2 to stderr explicitly using fprintf.
>
> To be honest, I considered this myself.
>
> But I think it is wrong. Just because the current callers happen to
> output to stderr does not mean that we would not like sidebands that
> exchange binary data for other uses in the future.
>
> I am thinking GitTorrent here.
Clearly, we are looking at git here, not GitTorrent. "Because we could" is
IMNSHO not a good justification keep code unnecessarily complicated.
> And clearly, sideband support was written with future uses like that in
> mind, as it goes out of its way to transmit packets instead of strings.
All data producers and data consumers *in git* use band #2 to transport
error messages and progress report. GitTorrent cannot not talk to
upload-pack or upload-archive and expect to get arbitrary binary data over
band #2.
For use-cases that you have in mind in GitTorrent, the *protocol* may be a
good choice, but the current implementation is definitely a special case.
-- Hannes
^ permalink raw reply
* Re: [RFC/PATCH] git push usability improvements and default change
From: Finn Arne Gangstad @ 2009-03-10 11:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0903101159530.14295@intel-tinevez-2-302>
On Tue, Mar 10, 2009 at 12:01:00PM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 10 Mar 2009, Finn Arne Gangstad wrote:
>
> > On Tue, Mar 10, 2009 at 12:35:12AM +0100, Johannes Schindelin wrote:
> >
> > > [...]
> > > At least without a proper way to prepare existing users for the end of
> > > the world.
> >
> > That is pretty much what patches 4 and 5 are about - add nice warnings,
> > but do not change behavior. 6 introduces the changed default.
>
> Ah, so you meant that 1-5 should be committed right away, and 6 in one
> year?
Yes, that was the intention.
- Finn Arne
^ permalink raw reply
* Re: [RFH Patch 2/2] http_init(): Fix config file parsing
From: Johannes Schindelin @ 2009-03-10 11:07 UTC (permalink / raw)
To: Jay Soffian; +Cc: Junio C Hamano, git
In-Reply-To: <76718490903092005n66bca743t67eb7f0ff830d9d7@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1392 bytes --]
Hi,
On Mon, 9 Mar 2009, Jay Soffian wrote:
> On Mon, Mar 9, 2009 at 10:19 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> > @@ -241,14 +221,18 @@ void http_init(struct remote *remote)
> > if (getenv("GIT_SSL_NO_VERIFY"))
> > curl_ssl_verify = 0;
> >
> > - ssl_cert = getenv("GIT_SSL_CERT");
> > + if (getenv("GIT_SSL_CERT"))
> > + ssl_cert = getenv("GIT_SSL_CERT");
> > #if LIBCURL_VERSION_NUM >= 0x070902
> > - ssl_key = getenv("GIT_SSL_KEY");
> > + if (getenv("GIT_SSL_KEY"))
> > + ssl_key = getenv("GIT_SSL_KEY");
> > #endif
> > #if LIBCURL_VERSION_NUM >= 0x070908
> > - ssl_capath = getenv("GIT_SSL_CAPATH");
> > + if (getenv("GIT_SSL_CAPATH"))
> > + ssl_capath = getenv("GIT_SSL_CAPATH");
> > #endif
> > - ssl_cainfo = getenv("GIT_SSL_CAINFO");
> > + if (getenv("GIT_SSL_CAINFO"))
> > + ssl_cainfo = getenv("GIT_SSL_CAINFO");
>
> Would these be a little cleaner with a temporary variable. e.g.
>
> char *value;
>
> if ((value = getenv("GIT_SSL_CERT")))
> ssl_cert = value;
Nah, you should go the full nine yards right away:
static void set_from_env(const char **variable, const char *name)
{
const char *value = getenv(name);
if (value)
*variable = value;
}
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC/PATCH] git push usability improvements and default change
From: Johannes Schindelin @ 2009-03-10 11:01 UTC (permalink / raw)
To: Finn Arne Gangstad; +Cc: git
In-Reply-To: <20090310084615.GA11448@pvv.org>
Hi,
On Tue, 10 Mar 2009, Finn Arne Gangstad wrote:
> On Tue, Mar 10, 2009 at 12:35:12AM +0100, Johannes Schindelin wrote:
>
> > On Mon, 9 Mar 2009, Finn Arne Gangstad wrote:
> >
> > > git push default change:
> > >
> > > git push will by default push "nothing" instead of "matching".
> >
> > Hasn't this been shot down already? I do not want that change. I
> > think it is harmful.
> >
> > At least without a proper way to prepare existing users for the end of
> > the world.
>
> That is pretty much what patches 4 and 5 are about - add nice warnings,
> but do not change behavior. 6 introduces the changed default.
Ah, so you meant that 1-5 should be committed right away, and 6 in one
year?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH/RFC] recv_sideband: Band #2 always goes to stderr
From: Johannes Schindelin @ 2009-03-10 10:56 UTC (permalink / raw)
To: Johannes Sixt
Cc: git, gitster, Peter Harris, Sebastian Schuberth, Nicolas Pitre
In-Reply-To: <49B61703.8030602@viscovery.net>
Hi,
On Tue, 10 Mar 2009, Johannes Sixt wrote:
> From: Johannes Sixt <j6t@kdbg.org>
>
> This removes the last parameter of recv_sideband, by which the callers
> told which channel band #2 data should be written to. Since both callers
> of the function passed 2 for the parameter, we hereby remove the
> parameter and send band #2 to stderr explicitly using fprintf.
To be honest, I considered this myself.
But I think it is wrong. Just because the current callers happen to
output to stderr does not mean that we would not like sidebands that
exchange binary data for other uses in the future.
I am thinking GitTorrent here.
And clearly, sideband support was written with future uses like that in
mind, as it goes out of its way to transmit packets instead of strings.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH][v2] http authentication via prompts (with correct line lengths)
From: Johannes Schindelin @ 2009-03-10 10:43 UTC (permalink / raw)
To: Mike Gaffney; +Cc: Junio C Hamano, git
In-Reply-To: <49B5DDA6.8070108@gmail.com>
Hi,
On Mon, 9 Mar 2009, Mike Gaffney wrote:
> I guess it makes sense to split the config out into two patches.
I guess, too, because it has been asked for. I guess that since nobody
contradicted that wish, it would make sense, I guess.
> I wanted both to help with automated builds, and as it's a read only
> account I wasn't worried about someone reading the password. I'm not
> very impressed with the permissions on the .netrc file actually
> providing security so I can see not allowing the password in the config
> either.
If Git were written for you, for that very specific setup, then yes, I can
see that one does not need to care about storing passwords in plaintext
files _there_.
However, in addition to you, Git was written for some others, too.
And $HOME/.netrc is a well established paradigm, many programs check the
permissions and flatly refuse to run with a big red warning if the
permissions are not set restrictively. So there is definitely a big,
huge, vast difference between storing passwords in $HOME/.netrc and
storing them in .git/config.
> In my system at work, we have shared machines but all developers have
> root access, so file permissions don't really secure anything for us.
> It's also why we can't really use keys (there is no way to enforce that
> a key is secured afaik).
Again, happily the Git team decided that in addition to you, we want to
support other users. For example us.
And we _do_ work on computers where only trustworthy people have root
access.
> I wanted to do a remote specific config as well but a global works well
> in many environments where your push repo is under http as you don't
> keep having to configure it.
IMHO in this case, "works well" does not mean the same as "makes sense" at
all.
Again, Git was written for other people, too.
It should not be necessary to say more, but here I go: on two projects I
have to push to multiple HTTP servers, and I do have different passwords
there.
However, I am pretty convinced that it is a good idea to have the
passwords in $HOME/.netrc where they belong instead of in a config where
it is all too easy to fsck up the permissions.
BTW that is another reason (in addition to it just being good style,
separating different issues into different patches) why I want you to
split the patch: to reject something insecure (storing passwords in
config) and to accept the secure part (reading passwords interactively
from the console).
> I also couldn't see a good way to do a remote specific config without
> changing the remote struct (which seemd like putting specific in a
> general). I would love some advice on this and where to put it.
Umm. Into the remote struct?
> I can see your security points but I would argue that if that's what we
> are worried about then we should not allow the netrc file at all.
See above.
> I added notes in the config documentation about this. I'm open to
> discussion on this point.
Oh, so you mean you will address my concerns? That's good, as I am
looking forward to your answers to them.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] rerere to recreate topic branches
From: Ingo Molnar @ 2009-03-10 10:18 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: git, Debian TopGit maintainers
In-Reply-To: <20090310093200.GA12931@pengutronix.de>
* Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote:
> Hello,
>
> Ingo sent a similar mail some time ago[1], that's why I Cc:
> him.
> [1] http://thread.gmane.org/gmane.comp.version-control.git/85176/
Just a few generic comments - i have written that mail 8 months
ago.
Since then our -tip workflow has shifted in the direction of
what i'd call an "append-mostly delta integration" workflow.
When i wrote that mail we used to do daily full reintegrations
of 100-200 topic branches using git-rerere, but that was not
really feasible in the long run for two reasons:
- back then a full integration took up to 30 minutes with over
a 100 branches and on a fast box - if it was all
problem-free.
[ It's much faster now both due to the speedups Git has done,
due to smarter scripting we do and due to me using an SSD
to host the -tip repo. ]
- the full integration itself 'locked' the whole repo for a
long time. The old integration branch was destroyed and a new
one constructued - with 1000-2000 commits. This was fragile
in a number of ways.
- if there was any problem during the integration (a bad
conflict resolution) it often had to be repeated which easily
pushed the time to do the integration to over an hour.
So full integration of 1000-2000 commits spread out into 100+
topic branches required a lot of concentration and even then it
was too fragile.
So now we do full reintegrations only about every two weeks,
plus we do finegrained per commit and per pull "delta
integrations" that is based on:
DELTA_BRANCHES=$(git branch --no-merged | cut -c3-)
git merge $DELTA_BRANCHES
Plus we have the same finegrained topical setup that allows the
specific isolation of gone-bad topics without the collateral
damage of them holding the full tree and other contributors
hostage.
So when a topic goes bad i dont revert nor do i destroy those
commits - i just rewind/reset the integration branch to before
the bad topic merge point, exclude the topic from
delta-integration (add it to a blacklist) and re-run the delta
integration and notify the people who caused the breakage. It's
about 30 seconds to do so there's no noticeable workflow hickup.
When the fix comes in 1-2 days later, the 'bad' topic branch is
reactivated and gets picked up by delta integration.
So all in one, delta integration is a lot less stressful in
practice, and undo is possible and easy, as most of the
breakages are in fresh commits.
It's also very fast:
earth4:~/tip> time todo-merge-all
searching for updated branches ...
excluded branches: core/kill-the-BKL tracing/dump-tracer
Updated branches: tracing/ftrace
merging tracing/ftrace ... Merge made by recursive.
kernel/trace/trace_workqueue.c | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
merging linus ... ... merge done.
real 0m5.402s
user 0m5.002s
sys 0m0.445s
Even though there are more than 400 branches it has to check,
100 of which are active (==carry new commits relative to Linus's
latest kernel tree).
Ingo
^ permalink raw reply
* Re: [RFC/PATCH] git push usability improvements and default change
From: Finn Arne Gangstad @ 2009-03-10 10:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfxhmdyvn.fsf@gitster.siamese.dyndns.org>
On Mon, Mar 09, 2009 at 05:07:08PM -0700, Junio C Hamano wrote:
> Finn Arne Gangstad <finnag@pvv.org> writes:
>
> I think the last four are more or less sane, but I am not sure about the
> first three, which makes it very unfortunate that the former depends on
> the latter.
No problem splitting them up, there is just a single function that is
shared between 1-3 and 4-7 really.
[...]
> * What's the point of having --matching option, when you can already say
> ':', i.e.
>
> $ git push origin :
If you have the name of your remote easily available, --matching is
identical to "git push remote :". As I believe I found out, getting
the name of the current remote is a bit more tedious than it should
be, which is why I also suggested being able to use "-" as the current
remote.
If a way to specify the default remote is possible, --matching would
not be necessary, but would probably be more obvious to the reader
than "git push - :" or whatever we can agree on.
> * What's the point of having --current option, when you can already
> say HEAD, i.e. $ git push origin HEAD
It does something very different. Maybe --tracking would be a better name.
--current does basically this:
branch=`git-symbolic-ref HEAD`
branch=${branch#refs/heads/}
remote=$(git config branch.$branch.remote)
for remotebranch in $(git config branch.$branch.merge); do
git push $remote $branch:$remotebranch
done
This is the shortest shell script sequence I could find to mimic the
behaviour, maybe I have missed something very obvious. All error
handling is removed for clarity.
The goal here is to be able to:
git checkout -b junios-next origin/next
git push --current <=> git push origin junios-next:next
git push origin HEAD would do git push origin junios-next:junios-next,
which was not the intention.
It seems that there is an assumption that branch names are identical
in different repositories, we find that that is not the case at all,
people choose local names that make sense to themselves. Or, from
another viewpoint, even if branches have the same name in two
repositories, they are not necessarily (strongly) related!
"A tracks B" can be a much stronger relation than "A has the same name
as B".
> * Is push.default still necessary if we had "remote.*.push" (where '*' is
> literally an "asterisk") that is used as a fall-back default when there
> is no "remote.<name>.push" for the remote we are about to push to?
The main reason for push.default is to be able to change the default
behaviour for git push to push nothing in a staged manner, and still
let people who are used to and fond of the old behavior continue as before.
You are thinking of something like this in .gitconfig?
[remote "*"]
push = __something__
Previously you indicated that there is no way to specify the current
matching rule in a remote push line I think?
- Finn Arne
^ permalink raw reply
* [PATCH JGIT] Add "compare with Git Index" action.
From: Yann Simon @ 2009-03-10 10:03 UTC (permalink / raw)
To: Robin Rosenberg, Shawn O. Pearce; +Cc: git
In the Compare With... menu, the "Git Index" action opens
a diff editor that compares the workspace version of a file and its
index version.
The local file can be modified and saved.
The staged version can be modified and saved. This updates the index.
For this, add methods into GitIndex to allow to specify a content
different from the file.
Signed-off-by: Yann Simon <yann.simon.fr@gmail.com>
---
Changed comapred to previous version:
- fix saving the index version.
.../core/internal/storage/GitFileRevision.java | 11 ++
org.spearce.egit.ui/plugin.properties | 3 +
org.spearce.egit.ui/plugin.xml | 7 +
.../spearce/egit/ui/internal/EditableRevision.java | 157 ++++++++++++++++++++
.../GitCompareFileRevisionEditorInput.java | 36 +++--
.../internal/actions/CompareWithIndexAction.java | 120 +++++++++++++++
.../src/org/spearce/jgit/lib/GitIndex.java | 65 ++++++++
7 files changed, 385 insertions(+), 14 deletions(-)
create mode 100644 org.spearce.egit.ui/src/org/spearce/egit/ui/internal/EditableRevision.java
create mode 100644 org.spearce.egit.ui/src/org/spearce/egit/ui/internal/actions/CompareWithIndexAction.java
diff --git a/org.spearce.egit.core/src/org/spearce/egit/core/internal/storage/GitFileRevision.java b/org.spearce.egit.core/src/org/spearce/egit/core/internal/storage/GitFileRevision.java
index 21ba19e..2f23c7d 100644
--- a/org.spearce.egit.core/src/org/spearce/egit/core/internal/storage/GitFileRevision.java
+++ b/org.spearce.egit.core/src/org/spearce/egit/core/internal/storage/GitFileRevision.java
@@ -49,6 +49,17 @@ public static GitFileRevision inCommit(final Repository db,
return new CommitFileRevision(db, commit, path, blobId);
}
+ /**
+ * @param db
+ * the repository which contains the index to use.
+ * @param path
+ * path of the resource in the index
+ * @return revision implementation for the given path in the index
+ */
+ public static GitFileRevision inIndex(final Repository db, final String path) {
+ return new IndexFileRevision(db, path);
+ }
+
private final String path;
GitFileRevision(final String fileName) {
diff --git a/org.spearce.egit.ui/plugin.properties b/org.spearce.egit.ui/plugin.properties
index 58b879f..07d7735 100644
--- a/org.spearce.egit.ui/plugin.properties
+++ b/org.spearce.egit.ui/plugin.properties
@@ -31,6 +31,9 @@ Decorator_description=Shows Git specific information on resources in projects un
CompareWithRevisionAction_label=Compare With Git Revision
CompareWithRevisionAction_tooltip=Compare With a Git Revision
+CompareWithIndexAction_label=Git Index
+CompareWithIndexAction_tooltip=Compare with Git's index version
+
ShowResourceInHistoryAction_label=Show in Resource History
ShowResourceInHistoryAction_tooltip=Show selected files in the resource history view.
diff --git a/org.spearce.egit.ui/plugin.xml b/org.spearce.egit.ui/plugin.xml
index 2f23559..678fd73 100644
--- a/org.spearce.egit.ui/plugin.xml
+++ b/org.spearce.egit.ui/plugin.xml
@@ -108,6 +108,13 @@
label="%CommitAction_label"
menubarPath="team.main/group1"
tooltip="%CommitAction_tooltip"/>
+ <action
+ class="org.spearce.egit.ui.internal.actions.CompareWithIndexAction"
+ id="org.spearce.egit.ui.internal.actions.CompareWithIndexAction"
+ label="%CompareWithIndexAction_label"
+ menubarPath="compareWithMenu/gitCompareWithGroup"
+ tooltip="&CompareWithIndexAction_tooltip">
+ </action>
</objectContribution>
<objectContribution
id="org.spearce.egit.ui.resetto"
diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/EditableRevision.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/EditableRevision.java
new file mode 100644
index 0000000..ee064ef
--- /dev/null
+++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/EditableRevision.java
@@ -0,0 +1,157 @@
+/*
+ * Copyright (C) 2009, Yann Simon <yann.simon.fr@gmail.com>
+ *
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ * copyright notice, this list of conditions and the following
+ * disclaimer in the documentation and/or other materials provided
+ * with the distribution.
+ *
+ * - Neither the name of the Git Development Community nor the
+ * names of its contributors may be used to endorse or promote
+ * products derived from this software without specific prior
+ * written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ * CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+ * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
+ * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+package org.spearce.egit.ui.internal;
+
+import java.io.ByteArrayInputStream;
+import java.io.InputStream;
+
+import org.eclipse.compare.IContentChangeListener;
+import org.eclipse.compare.IContentChangeNotifier;
+import org.eclipse.compare.IEditableContent;
+import org.eclipse.compare.ISharedDocumentAdapter;
+import org.eclipse.compare.ITypedElement;
+import org.eclipse.compare.internal.ContentChangeNotifier;
+import org.eclipse.core.runtime.CoreException;
+import org.eclipse.core.runtime.Platform;
+import org.eclipse.team.core.history.IFileRevision;
+import org.eclipse.team.internal.ui.history.FileRevisionTypedElement;
+import org.eclipse.team.internal.ui.synchronize.EditableSharedDocumentAdapter;
+
+/**
+ * @author simon
+ *
+ */
+public class EditableRevision extends FileRevisionTypedElement implements
+ ITypedElement, IEditableContent, IContentChangeNotifier {
+
+ private byte[] modifiedContent;
+
+ private ContentChangeNotifier fChangeNotifier;
+
+ private EditableSharedDocumentAdapter sharedDocumentAdapter;
+
+ /**
+ * @param fileRevision
+ */
+ public EditableRevision(IFileRevision fileRevision) {
+ super(fileRevision);
+ }
+
+ public boolean isEditable() {
+ return true;
+ }
+
+ public ITypedElement replace(ITypedElement dest, ITypedElement src) {
+ return null;
+ }
+
+ @Override
+ public InputStream getContents() throws CoreException {
+ if (modifiedContent != null) {
+ return new ByteArrayInputStream(modifiedContent);
+ }
+ return super.getContents();
+ }
+
+ public void setContent(byte[] newContent) {
+ modifiedContent = newContent;
+ fireContentChanged();
+ }
+
+ /**
+ * @return the modified content
+ */
+ public byte[] getModifiedContent() {
+ return modifiedContent;
+ }
+
+ public Object getAdapter(Class adapter) {
+ if (adapter == ISharedDocumentAdapter.class) {
+ return getSharedDocumentAdapter();
+ }
+ return Platform.getAdapterManager().getAdapter(this, adapter);
+ }
+
+ private synchronized ISharedDocumentAdapter getSharedDocumentAdapter() {
+ if (sharedDocumentAdapter == null)
+ sharedDocumentAdapter = new EditableSharedDocumentAdapter(
+ new EditableSharedDocumentAdapter.ISharedDocumentAdapterListener() {
+ public void handleDocumentConnected() {
+ }
+
+ public void handleDocumentFlushed() {
+ }
+
+ public void handleDocumentDeleted() {
+ }
+
+ public void handleDocumentSaved() {
+ }
+
+ public void handleDocumentDisconnected() {
+ }
+ });
+ return sharedDocumentAdapter;
+ }
+
+ public void addContentChangeListener(IContentChangeListener listener) {
+ if (fChangeNotifier == null)
+ fChangeNotifier = new ContentChangeNotifier(this);
+ fChangeNotifier.addContentChangeListener(listener);
+ }
+
+ public void removeContentChangeListener(IContentChangeListener listener) {
+ if (fChangeNotifier != null) {
+ fChangeNotifier.removeContentChangeListener(listener);
+ if (fChangeNotifier.isEmpty())
+ fChangeNotifier = null;
+ }
+ }
+
+ /**
+ * Notifies all registered <code>IContentChangeListener</code>s of a content
+ * change.
+ */
+ protected void fireContentChanged() {
+ if (fChangeNotifier == null || fChangeNotifier.isEmpty()) {
+ return;
+ }
+ fChangeNotifier.fireContentChanged();
+ }
+
+}
diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/GitCompareFileRevisionEditorInput.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/GitCompareFileRevisionEditorInput.java
index 8aa076f..49d4a42 100644
--- a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/GitCompareFileRevisionEditorInput.java
+++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/GitCompareFileRevisionEditorInput.java
@@ -11,7 +11,6 @@
import java.lang.reflect.InvocationTargetException;
import org.eclipse.compare.CompareConfiguration;
-import org.eclipse.compare.CompareEditorInput;
import org.eclipse.compare.IEditableContent;
import org.eclipse.compare.IResourceProvider;
import org.eclipse.compare.ITypedElement;
@@ -34,13 +33,14 @@
import org.eclipse.team.internal.ui.Utils;
import org.eclipse.team.internal.ui.history.FileRevisionTypedElement;
import org.eclipse.team.internal.ui.synchronize.LocalResourceTypedElement;
+import org.eclipse.team.ui.synchronize.SaveableCompareEditorInput;
import org.eclipse.ui.IWorkbenchPage;
/**
* The input provider for the compare editor when working on resources
* under Git control.
*/
-public class GitCompareFileRevisionEditorInput extends CompareEditorInput {
+public class GitCompareFileRevisionEditorInput extends SaveableCompareEditorInput {
private ITypedElement left;
private ITypedElement right;
@@ -52,7 +52,7 @@
* @param page
*/
public GitCompareFileRevisionEditorInput(ITypedElement left, ITypedElement right, IWorkbenchPage page) {
- super(new CompareConfiguration());
+ super(new CompareConfiguration(), page);
this.left = left;
this.right = right;
}
@@ -90,9 +90,18 @@ private static void ensureContentsCached(FileRevisionTypedElement left, FileRevi
}
private boolean isLeftEditable(ICompareInput input) {
- Object left = input.getLeft();
- if (left instanceof IEditableContent) {
- return ((IEditableContent) left).isEditable();
+ Object tmpLeft = input.getLeft();
+ return isEditable(tmpLeft);
+ }
+
+ private boolean isRightEditable(ICompareInput input) {
+ Object tmpRight = input.getRight();
+ return isEditable(tmpRight);
+ }
+
+ private boolean isEditable(Object object) {
+ if (object instanceof IEditableContent) {
+ return ((IEditableContent) object).isEditable();
}
return false;
}
@@ -326,12 +335,9 @@ private String getContentIdentifier(ITypedElement element){
return TeamUIMessages.CompareFileRevisionEditorInput_2;
}
-// /* (non-Javadoc)
-// * @see org.eclipse.team.ui.synchronize.LocalResourceCompareEditorInput#fireInputChange()
-// */
-// protected void fireInputChange() {
-// ((DiffNode)getCompareResult()).fireChange();
-// }
+ @Override
+ protected void fireInputChange() {
+ }
//
// /* (non-Javadoc)
// * @see org.eclipse.team.ui.synchronize.SaveableCompareEditorInput#contentsCreated()
@@ -359,10 +365,12 @@ private LocalResourceTypedElement getLocalElement() {
return null;
}
- protected Object prepareInput(IProgressMonitor monitor) throws InvocationTargetException, InterruptedException {
+ @Override
+ protected ICompareInput prepareCompareInput(IProgressMonitor monitor)
+ throws InvocationTargetException, InterruptedException {
ICompareInput input = createCompareInput();
getCompareConfiguration().setLeftEditable(isLeftEditable(input));
- getCompareConfiguration().setRightEditable(false);
+ getCompareConfiguration().setRightEditable(isRightEditable(input));
ensureContentsCached(getLeftRevision(), getRightRevision(), monitor);
initLabels(input);
setTitle(NLS.bind(TeamUIMessages.SyncInfoCompareInput_title, new String[] { input.getName() }));
diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/actions/CompareWithIndexAction.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/actions/CompareWithIndexAction.java
new file mode 100644
index 0000000..a9ca251
--- /dev/null
+++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/actions/CompareWithIndexAction.java
@@ -0,0 +1,120 @@
+/*
+ * Copyright (C) 2009, Yann Simon <yann.simon.fr@gmail.com>
+ *
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ * copyright notice, this list of conditions and the following
+ * disclaimer in the documentation and/or other materials provided
+ * with the distribution.
+ *
+ * - Neither the name of the Git Development Community nor the
+ * names of its contributors may be used to endorse or promote
+ * products derived from this software without specific prior
+ * written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ * CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+ * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
+ * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+package org.spearce.egit.ui.internal.actions;
+
+import java.io.File;
+import java.io.IOException;
+
+import org.eclipse.compare.CompareUI;
+import org.eclipse.compare.IContentChangeListener;
+import org.eclipse.compare.IContentChangeNotifier;
+import org.eclipse.compare.ITypedElement;
+import org.eclipse.core.resources.IFile;
+import org.eclipse.core.resources.IResource;
+import org.eclipse.jface.action.IAction;
+import org.eclipse.team.core.history.IFileRevision;
+import org.eclipse.team.internal.ui.Utils;
+import org.eclipse.team.ui.synchronize.SaveableCompareEditorInput;
+import org.spearce.egit.core.internal.storage.GitFileRevision;
+import org.spearce.egit.core.project.RepositoryMapping;
+import org.spearce.egit.ui.internal.EditableRevision;
+import org.spearce.egit.ui.internal.GitCompareFileRevisionEditorInput;
+import org.spearce.jgit.lib.GitIndex;
+import org.spearce.jgit.lib.Repository;
+
+/**
+ * The "compare with index" action. This action opens a diff editor comparing
+ * the file as found in the working directory and the version found in the index
+ * of the repository.
+ */
+@SuppressWarnings("restriction")
+public class CompareWithIndexAction extends RepositoryAction {
+
+ @Override
+ public void execute(IAction action) {
+ final IResource resource = getSelectedResources()[0];
+ final RepositoryMapping mapping = RepositoryMapping.getMapping(resource.getProject());
+ final Repository repository = mapping.getRepository();
+ final String gitPath = mapping.getRepoRelativePath(resource);
+
+ final IFileRevision nextFile = GitFileRevision.inIndex(repository, gitPath);
+
+ final IFile baseFile = (IFile) resource;
+ final ITypedElement base = SaveableCompareEditorInput.createFileElement(baseFile);
+
+ final EditableRevision next = new EditableRevision(nextFile);
+
+ IContentChangeListener listener = new IContentChangeListener() {
+ public void contentChanged(IContentChangeNotifier source) {
+ final byte[] newContent = next.getModifiedContent();
+ try {
+ final GitIndex index = repository.getIndex();
+ final File file = new File(baseFile.getLocation().toString());
+ index.add(mapping.getWorkDir(), file, newContent);
+ index.write();
+ } catch (IOException e) {
+ Utils.handleError(getTargetPart().getSite().getShell(), e,
+ "Error during adding to index",
+ "Error during adding to index");
+ return;
+ }
+ }
+ };
+
+ next.addContentChangeListener(listener);
+
+ final GitCompareFileRevisionEditorInput in = new GitCompareFileRevisionEditorInput(
+ base, next, null);
+ CompareUI.openCompareEditor(in);
+ }
+
+ @Override
+ public boolean isEnabled() {
+ final IResource[] selectedResources = getSelectedResources();
+ if (selectedResources.length != 1)
+ return false;
+
+ final IResource resource = selectedResources[0];
+ if (!(resource instanceof IFile)) {
+ return false;
+ }
+ final RepositoryMapping mapping = RepositoryMapping.getMapping(resource.getProject());
+ return mapping != null;
+ }
+
+}
\ No newline at end of file
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/GitIndex.java b/org.spearce.jgit/src/org/spearce/jgit/lib/GitIndex.java
index 920a9c9..21b495a 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/GitIndex.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/GitIndex.java
@@ -170,6 +170,30 @@ public Entry add(File wd, File f) throws IOException {
}
/**
+ * Add the content of a file to the index.
+ *
+ * @param wd
+ * workdir
+ * @param f
+ * the file
+ * @param content
+ * content of the file
+ * @return a new or updated index entry for the path represented by f
+ * @throws IOException
+ */
+ public Entry add(File wd, File f, byte[] content) throws IOException {
+ byte[] key = makeKey(wd, f);
+ Entry e = entries.get(key);
+ if (e == null) {
+ e = new Entry(key, f, 0, content);
+ entries.put(key, e);
+ } else {
+ e.update(f, content);
+ }
+ return e;
+ }
+
+ /**
* Remove a path from the index.
*
* @param wd
@@ -360,6 +384,25 @@ Entry(byte[] key, File f, int stage)
flags = (short) ((stage << 12) | name.length); // TODO: fix flags
}
+ Entry(byte[] key, File f, int stage, byte[] newContent)
+ throws IOException {
+ ctime = f.lastModified() * 1000000L;
+ mtime = ctime; // we use same here
+ dev = -1;
+ ino = -1;
+ if (config_filemode() && File_canExecute(f))
+ mode = FileMode.EXECUTABLE_FILE.getBits();
+ else
+ mode = FileMode.REGULAR_FILE.getBits();
+ uid = -1;
+ gid = -1;
+ size = newContent.length;
+ ObjectWriter writer = new ObjectWriter(db);
+ sha1 = writer.writeBlob(newContent);
+ name = key;
+ flags = (short) ((stage << 12) | name.length); // TODO: fix flags
+ }
+
Entry(TreeEntry f, int stage) {
ctime = -1; // hmm
mtime = -1;
@@ -433,6 +476,28 @@ public boolean update(File f) throws IOException {
return modified;
}
+ /**
+ * Update this index entry with stat and SHA-1 information if it looks
+ * like the file has been modified in the workdir.
+ *
+ * @param f
+ * file in work dir
+ * @param newContent
+ * the new content of the file
+ * @return true if a change occurred
+ * @throws IOException
+ */
+ public boolean update(File f, byte[] newContent) throws IOException {
+ boolean modified = false;
+ size = newContent.length;
+ ObjectWriter writer = new ObjectWriter(db);
+ ObjectId newsha1 = sha1 = writer.writeBlob(newContent);
+ if (!newsha1.equals(sha1))
+ modified = true;
+ sha1 = newsha1;
+ return modified;
+ }
+
void write(ByteBuffer buf) {
int startposition = buf.position();
buf.putInt((int) (ctime / 1000000000L));
--
1.6.1.2
^ permalink raw reply related
* Re: git-p4 workflow suggestions?
From: Sam Hocevar @ 2009-03-10 9:57 UTC (permalink / raw)
To: git
In-Reply-To: <200903100815.53847.chriscool@tuxfamily.org>
On Tue, Mar 10, 2009, Christian Couder wrote:
> > I have modified git and git-p4 to a point where they are usable in
> > my work environment. I am now faced with a new problem: Perforce's
> > composite workspaces. They allow you to "mount" parts of the repo onto
> > other directories, even nonempty ones.
>
> It looks like SVN externals. So I think you should read about "git
> submodule".
>
> There is this related link on the wiki:
>
> http://blog.alieniloquent.com/2008/03/08/git-svn-with-svnexternals/
Unfortunately submodules are considered separate repositories, so if
I have /include and /src as submodules, I cannot commit atomically to
both. Or can I? That's probably my strongest requirement.
> You may also want to search the mailing list as this subject has often been
> discussed.
I did skim through the archives, but couldn't find much. There was
this discussion: http://kerneltrap.org/mailarchive/git/2006/11/28/231515
where the idea of Perforce-like workspaces was apparently dismissed as
being "a mess".
Cheers,
--
Sam.
^ permalink raw reply
* Re: [PATCH 1/2] grep Added --blame so that grep can show result tagged with blame entries
From: Junio C Hamano @ 2009-03-10 9:46 UTC (permalink / raw)
To: pi song; +Cc: git
In-Reply-To: <49B51791.4030801@gmail.com>
pi song <pi.songs@gmail.com> writes:
> This part:-
> 1) Move reusable bits from builtin-blame.c into blame.c, blame.h
> 2) Replace static variables with context struct
>
> Signed-off-by: Pi Song <pi.songs@gmail.com>
> ---
> Makefile | 2 +
> blame.c | 1919 +++++++++++++++++++++++++++++++++++++++++++++++++++
> blame.h | 222 ++++++
> builtin-blame.c | 2072
> +++----------------------------------------------------
> 4 files changed, 2245 insertions(+), 1970 deletions(-)
> create mode 100644 blame.c
> create mode 100644 blame.h
This is simply too big to ask anybody sane to review (besides as we can
clearly see in the above the patch is severely whitespace damaged to be
usable nor mechanically reviewable).
I suspect that most of the file-scope static variables can be moved to the
scoreboard, and when the reusable parts are made public, some structure
and function names may need to become a bit more blame specific to avoid
namespace contamination.
Perhaps the first two patches in an equivalent series that is rerolled to
be reviewable would look like:
(1) move file-scope static variables to the scoreboard, and necessary
code changes associated with it;
renaming of some structures and functions (if needed---I didn't
check);
(2) create blame.c and blame.h, and move lines from builtin-blame.c *and*
do NOTHING OTHER THAN
- adding #include "blame.h" to builtin-blame.c,
- adding necessary #include at the top of blame.c,
- surrounding blame.h with necessary
#ifndef BLAME_H
#define BLAME_H
...
#endif
and finally
- updating Makefile to add blame.c and blame.h
This step will make a HUGE patch, and it is crucial for reviewability
for it not to do anything other than line movement. Ideally, the
patch shouldn't even reorder the structures and function definitions
during this step.
Then we can use "git blame" itself to make sure that no other changes
were sneaked in by mistake. "git blame -C blame.h" and "git blame -C
blame.c" would show everything came from builtin-blame.c.
At this point, there shouldn't still be any behaviour change nor new
feature. And the titles of these preparatory step will never say anything
about "grep". They are only refactoring "blame".
Once this becomes solid, you can start adding features to blame.c to
support your new caller, and we can be reasonably sure that such patches
can be reviewed to decide if its change breaks the existing (and so far
the only) caller builtin_blame() or not.
^ permalink raw reply
* [RFC] rerere to recreate topic branches
From: Uwe Kleine-König @ 2009-03-10 9:32 UTC (permalink / raw)
To: git; +Cc: Ingo Molnar, Debian TopGit maintainers
Hello,
Ingo sent a similar mail some time ago[1], that's why I Cc: him.
For TopGit I want something similar as Ingo for -tip (I think): recreate
a branch with a cleaned up history but without throwing away merge
resolutions.
I think most points from Ingo's mail are already addressed. Let's see
if my mail is equally successful :-)
One step that wasn't in Ingo's list, but I consider nice is the
following workflow:
export GIT_RR_CACHE=$(mktemp -d)
git rerere add-to-cache-from origin..$branch_to_rebuild
script doing the actual rebuild
together with rerere.autocommit=true. Even though rerere is not save in
general, this workflow seems fine. I think with this approach sharing
the rr-cache isn't an issue anymore and merge conflicts that need manual
work should be quite rare, even if you do it for the first time.
I just found contrib/rerere-train.sh, which already addresses a part of
my plan.
One of my further goals is to do as much transformation without touching
the working copy (to gain speed and comfort). For that I would need git
merge to operate on an index, only and only fall back to using the
working copy if manual intervention is needed.
I have to admit that up to now I didn't look into the corresponding
code, so consider this mail (only) as starter to collect ideas and
comments.
Best regards
Uwe
[1] http://thread.gmane.org/gmane.comp.version-control.git/85176/
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH 3/7] git push: New options --matching and --current
From: Finn Arne Gangstad @ 2009-03-10 8:54 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.1.00.0903091938150.19665@iabervon.org>
On Mon, Mar 09, 2009 at 07:49:47PM -0400, Daniel Barkalow wrote:
> On Mon, 9 Mar 2009, Finn Arne Gangstad wrote:
>
> > diff --git a/transport.h b/transport.h
> > index 6bbc1a8..b897d0c 100644
> > --- a/transport.h
> > +++ b/transport.h
> > @@ -34,6 +34,15 @@ struct transport {
> > #define TRANSPORT_PUSH_DRY_RUN 4
> > #define TRANSPORT_PUSH_MIRROR 8
> > #define TRANSPORT_PUSH_VERBOSE 16
> > +#define TRANSPORT_PUSH_MATCHING 32
> > +#define TRANSPORT_PUSH_CURRENT 64
> > +/**
> > + * All push flags that imply a certain set of refspecs to be pushed must
> > + * be combined into TRANSPORT_PUSH_MODE_MASK
> > + **/
> > +#define TRANSPORT_PUSH_MODE_MASK \
> > + (TRANSPORT_PUSH_ALL | TRANSPORT_PUSH_MIRROR | TRANSPORT_PUSH_MATCHING | \
> > + TRANSPORT_PUSH_CURRENT)
>
> It's kind of odd that you define these flags as TRANSPORT_PUSH_*, but
> implement them before entering transport_push(). I'm not sure which is
> right, but the combination is odd. I think just taking care of it in
> builtin-push with flags or options defined there is probably the best
> thing, currently.
True, this was not very beautiful. I will make something better.
- Finn Arne
^ permalink raw reply
* Re: [RFC/PATCH] git push usability improvements and default change
From: Finn Arne Gangstad @ 2009-03-10 8:46 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0903100033400.6358@intel-tinevez-2-302>
On Tue, Mar 10, 2009 at 12:35:12AM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 9 Mar 2009, Finn Arne Gangstad wrote:
>
> > git push default change:
> >
> > git push will by default push "nothing" instead of "matching".
>
> Hasn't this been shot down already? I do not want that change. I think
> it is harmful.
>
> At least without a proper way to prepare existing users for the end of the
> world.
That is pretty much what patches 4 and 5 are about - add nice
warnings, but do not change behavior. 6 introduces the changed default.
- Finn Arne
^ permalink raw reply
* Re: [PATCH][v2] http authentication via prompts (with correct line lengths)
From: Junio C Hamano @ 2009-03-10 8:35 UTC (permalink / raw)
To: Daniel Stenberg; +Cc: Mike Gaffney, git
In-Reply-To: <alpine.DEB.1.10.0903100905050.14797@yvahk2.pbagnpgbe.fr>
Daniel Stenberg <daniel@haxx.se> writes:
> On Mon, 9 Mar 2009, Junio C Hamano wrote:
>
>> The version of libcurl on my box is 7.18.something, and it does not
>> seem to ask for password when the URL has only username but not
>> colon-password. I also expected it to ask for password when
>> $HOME/.netrc has login but not password for a given machine, but
>> that does not seem to happen either. Perhaps the version is too old.
>
> No, that's entirely expected. libcurl has no "prompt the user if no
> password was given" logic but instead delegates that work to the
> application.
>
> There was once functionality for this (removed in October 2003) but it
> was broken and violated internal guidelines so we cut out and threw
> that code away.
>
> More recently there have been people interested in re-implementing
> this "the right way" but so far it hasn't been made and thus the
> application is left to perform this task.
It's always nice to find _the_ area expert around ;-)
I somehow misread the description on CURLOPT_NETRC that appears in
http://curl.haxx.se/libcurl/c/curl_easy_setopt.html:
libcurl uses a user name (and supplied or prompted password)
supplied with CURLOPT_USERPWD in preference to any of the options
controlled by this parameter.
especially the "or prompted password" part to mean that unless supplied to
the library by the caller the library would prompt the user and obtain the
password.
Thanks for clarification.
^ permalink raw reply
* [PATCH] Improve "git branch --tracking" output
From: Junio C Hamano @ 2009-03-10 8:20 UTC (permalink / raw)
To: Pat Notz; +Cc: git, Junio C Hamano
In-Reply-To: <7vab7tbxo0.fsf@gitster.siamese.dyndns.org>
An earlier patch always spelled the full name of the ref that we track
(e.g. "refs/heads/frotz" instead of just "frotz" when we mean the branch
whose name is "frotz"). Worse yet, because we now use the true name of
the ref at the original repository when talk about a tracking branch that
copies from a remote, such a full name alone still does not give enough
information.
This reorganizes the verbose codepath to:
- differentiate "refs/heads/something" and everything else; we say that
the branch tracks "branch <something>" if it begins with "refs/heads/",
and otherwise the branch tracks "ref refs/<someother>/<something>";
- report the name of the remote when we talk about a tracking branch, by
saying "branch frotz from origin";
- not say "by merging" at the end; it is the default and is not worth
reporting.
Signed-off-by: Junio C Hamano <junio@pobox.com>
---
branch.c | 23 +++++++++++++++++------
1 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/branch.c b/branch.c
index d20fb04..5f889fe 100644
--- a/branch.c
+++ b/branch.c
@@ -65,12 +65,23 @@ void install_branch_config(int flag, const char *local, const char *origin, cons
git_config_set(key.buf, "true");
}
- if (flag & BRANCH_CONFIG_VERBOSE)
- printf("Branch %s set up to track %s branch %s %s.\n",
- local,
- origin ? "remote" : "local",
- remote,
- rebasing ? "by rebasing" : "by merging");
+ if (flag & BRANCH_CONFIG_VERBOSE) {
+ strbuf_reset(&key);
+
+ strbuf_addstr(&key, origin ? "remote" : "local");
+
+ /* Are we tracking a proper "branch"? */
+ if (!prefixcmp(remote, "refs/heads/")) {
+ strbuf_addf(&key, " branch %s", remote + 11);
+ if (origin)
+ strbuf_addf(&key, " from %s", origin);
+ }
+ else
+ strbuf_addf(&key, " ref %s", remote);
+ printf("Branch %s set up to track %s%s.\n",
+ local, key.buf,
+ rebasing ? " by rebasing" : "");
+ }
strbuf_release(&key);
}
^ permalink raw reply related
* Re: [PATCHv6] Make git-clone respect branch.autosetuprebase
From: Junio C Hamano @ 2009-03-10 8:16 UTC (permalink / raw)
To: Pat Notz; +Cc: git, Junio C Hamano
In-Reply-To: <1236659098-14400-1-git-send-email-pknotz@sandia.gov>
"Pat Notz" <pknotz@sandia.gov> writes:
> This version fixes the verbose output to be more human friendly. Before,
> the branch being tracked was printed as 'refs/heads/frotz' regardless of
> wether that was a local or remote branch. Now, a local branch is just
> printed as 'frotz' and a remote branch is printed as 'origin/frotz'
Since I've already queued the previous round in 'next', I took the liberty
of making this into an incremental.
I do not think what you did is really correct. For clone, because we do
not create anything but the default "refs/remotes/<origin>/<branch>"
layout, always stripping out the first 11 bytes "refs/heads/" happens to
give a more intuitive result. But the helper function is shared with a
more general "git branch --track" that lets you mark the new branch to
track almost anything. For example, the version from v1.6.0 gives you
these:
$ git branch --track maint-1.6.0 v1.6.0
Branch maint-1.6.0 set up to track local branch refs/tags/v1.6.0
$ git branch --track frotz master
Branch frotz set up to track local branch refs/heads/master
Arguably, the former should say "track local ref refs/tags/v1.6.0" (or the
command should not even let you "track" a tag, which is supposed to be
immutable), and the latter would be helped by stripping "refs/heads/".
But the point is that stripping first 11 bytes unconditionally would be
wrong if you happen to start tracking a tag whose name is a single byte.
Also I do not think ("%s/%s", origin, remote+11) is correct in general.
You could very well configure your tracking to:
[remote "origin"]
fetch = refs/heads/*:refs/remotes/upstream/*
and I think the variable "remote" here refer to the name the ref is known
as in the remote repository, not the name we use to keep a copy of. IOW,
when we say "Branch frotz tracks remote 'master'", we should say "the
branch known as 'master' at the remote site, no matter what name we happen
to call its copy locally somewhere under our refs/remotes".
In that sense, both the version I queued and the original are lacking
a critical piece of information: which remote we are talking about.
In any case, here is your patch, made into an incremental. I'll send out
an alternative fix in a separate message.
branch.c | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/branch.c b/branch.c
index d20fb04..d586843 100644
--- a/branch.c
+++ b/branch.c
@@ -65,12 +65,18 @@ void install_branch_config(int flag, const char *local, const char *origin, cons
git_config_set(key.buf, "true");
}
- if (flag & BRANCH_CONFIG_VERBOSE)
+ if (flag & BRANCH_CONFIG_VERBOSE) {
+ strbuf_reset(&key);
+ if (origin)
+ strbuf_addf(&key, "%s/%s", origin, remote+11);
+ else
+ strbuf_addf(&key, "%s", remote+11);
printf("Branch %s set up to track %s branch %s %s.\n",
local,
origin ? "remote" : "local",
- remote,
+ key.buf,
rebasing ? "by rebasing" : "by merging");
+ }
strbuf_release(&key);
}
^ permalink raw reply related
* Re: [PATCH][v2] http authentication via prompts (with correct line lengths)
From: Daniel Stenberg @ 2009-03-10 8:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mike Gaffney, git
In-Reply-To: <7v63ihdgy6.fsf@gitster.siamese.dyndns.org>
On Mon, 9 Mar 2009, Junio C Hamano wrote:
> The version of libcurl on my box is 7.18.something, and it does not seem to
> ask for password when the URL has only username but not colon-password. I
> also expected it to ask for password when $HOME/.netrc has login but not
> password for a given machine, but that does not seem to happen either.
> Perhaps the version is too old.
No, that's entirely expected. libcurl has no "prompt the user if no password
was given" logic but instead delegates that work to the application.
There was once functionality for this (removed in October 2003) but it was
broken and violated internal guidelines so we cut out and threw that code
away.
More recently there have been people interested in re-implementing this "the
right way" but so far it hasn't been made and thus the application is left to
perform this task.
--
/ daniel.haxx.se
^ permalink raw reply
* Git BoF @ EclipseCon
From: Manuel Woelker @ 2009-03-10 8:10 UTC (permalink / raw)
To: git
Hi git list!
Just a quick heads-up for all interested parties: There is a git BoF
scheduled for EclipseCon 2009 (
http://www.eclipsecon.org/2009/sessions?id=776 ). The main focus is
going to be to discuss how we can make git (probably via jgit/egit) a
viable option in the Eclipse ecosystem. A little more info here:
http://eclipsesource.com/blogs/2009/03/02/git-bof-eclipsecon/
I think it would be great to have some of you experts present there
and I hope we can make some progress. It also looks like there will be
another VCS BoF on Tuesday, to discuss more general issues
(IP, infrastructure, work flows, etc).
Cheers
- Manuel
^ permalink raw reply
* [PATCH/RFC] recv_sideband: Band #2 always goes to stderr
From: Johannes Sixt @ 2009-03-10 7:30 UTC (permalink / raw)
To: Johannes Schindelin
Cc: git, gitster, Peter Harris, Sebastian Schuberth, Nicolas Pitre
In-Reply-To: <49B61377.90103@viscovery.net>
From: Johannes Sixt <j6t@kdbg.org>
This removes the last parameter of recv_sideband, by which the callers
told which channel band #2 data should be written to. Since both callers
of the function passed 2 for the parameter, we hereby remove the
parameter and send band #2 to stderr explicitly using fprintf.
This has the nice side-effect that the band #2 data (most importantly
progress reports during a fetch operation) passes through our ANSI
emulation layer on Windows.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
Johannes Sixt schrieb:
> Johannes Schindelin schrieb:
>> To make use of it during a fetch, write() needs to be overridden, too.
>
> No, that's not necessary with the patch that I'm about to send in a
> moment. To replace write() for ANSI emulation really goes too far.
Here it is. The patch is still RFC because I didn't have a chance, yet,
to test it in practice. It passes the test suite.
-- Hannes
builtin-archive.c | 2 +-
builtin-fetch-pack.c | 2 +-
sideband.c | 20 +++++++++-----------
sideband.h | 2 +-
4 files changed, 12 insertions(+), 14 deletions(-)
diff --git a/builtin-archive.c b/builtin-archive.c
index 60adef9..ab50ceb 100644
--- a/builtin-archive.c
+++ b/builtin-archive.c
@@ -52,7 +52,7 @@ static int run_remote_archiver(int argc, const char **argv,
die("git archive: expected a flush");
/* Now, start reading from fd[0] and spit it out to stdout */
- rv = recv_sideband("archive", fd[0], 1, 2);
+ rv = recv_sideband("archive", fd[0], 1);
close(fd[0]);
close(fd[1]);
rv |= finish_connect(conn);
diff --git a/builtin-fetch-pack.c b/builtin-fetch-pack.c
index c2e5adc..2b36099 100644
--- a/builtin-fetch-pack.c
+++ b/builtin-fetch-pack.c
@@ -482,7 +482,7 @@ static int sideband_demux(int fd, void *data)
{
int *xd = data;
- return recv_sideband("fetch-pack", xd[0], fd, 2);
+ return recv_sideband("fetch-pack", xd[0], fd);
}
static int get_pack(int xd[2], char **pack_lockfile)
diff --git a/sideband.c b/sideband.c
index cca3360..a706ac8 100644
--- a/sideband.c
+++ b/sideband.c
@@ -19,7 +19,7 @@
#define FIX_SIZE 10 /* large enough for any of the above */
-int recv_sideband(const char *me, int in_stream, int out, int err)
+int recv_sideband(const char *me, int in_stream, int out)
{
unsigned pf = strlen(PREFIX);
unsigned sf;
@@ -41,8 +41,7 @@ int recv_sideband(const char *me, int in_stream, int out, int err)
if (len == 0)
break;
if (len < 1) {
- len = sprintf(buf, "%s: protocol error: no band designator\n", me);
- safe_write(err, buf, len);
+ fprintf(stderr, "%s: protocol error: no band designator\n", me);
return SIDEBAND_PROTOCOL_ERROR;
}
band = buf[pf] & 0xff;
@@ -50,8 +49,8 @@ int recv_sideband(const char *me, int in_stream, int out, int err)
switch (band) {
case 3:
buf[pf] = ' ';
- buf[pf+1+len] = '\n';
- safe_write(err, buf, pf+1+len+1);
+ buf[pf+1+len] = '\0';
+ fprintf(stderr, "%s\n", buf);
return SIDEBAND_REMOTE_ERROR;
case 2:
buf[pf] = ' ';
@@ -95,12 +94,13 @@ int recv_sideband(const char *me, int in_stream, int out, int err)
memcpy(save, b + brk, sf);
b[brk + sf - 1] = b[brk - 1];
memcpy(b + brk - 1, suffix, sf);
- safe_write(err, b, brk + sf);
+ fprintf(stderr, "%.*s", brk + sf, b);
memcpy(b + brk, save, sf);
len -= brk;
} else {
int l = brk ? brk : len;
- safe_write(err, b, l);
+ if (l > 0)
+ fprintf(stderr, "%.*s", l, b);
len -= l;
}
@@ -112,10 +112,8 @@ int recv_sideband(const char *me, int in_stream, int out, int err)
safe_write(out, buf + pf+1, len);
continue;
default:
- len = sprintf(buf,
- "%s: protocol error: bad band #%d\n",
- me, band);
- safe_write(err, buf, len);
+ fprintf(stderr, "%s: protocol error: bad band #%d\n",
+ me, band);
return SIDEBAND_PROTOCOL_ERROR;
}
}
diff --git a/sideband.h b/sideband.h
index a84b691..d72db35 100644
--- a/sideband.h
+++ b/sideband.h
@@ -7,7 +7,7 @@
#define DEFAULT_PACKET_MAX 1000
#define LARGE_PACKET_MAX 65520
-int recv_sideband(const char *me, int in_stream, int out, int err);
+int recv_sideband(const char *me, int in_stream, int out);
ssize_t send_sideband(int fd, int band, const char *data, ssize_t sz, int packet_max);
#endif
--
1.6.2.987.g90c1d
^ permalink raw reply related
* Re: git-p4 workflow suggestions?
From: Christian Couder @ 2009-03-10 7:15 UTC (permalink / raw)
To: Sam Hocevar; +Cc: git
In-Reply-To: <20090309142108.GK12880@zoy.org>
Hi Sam,
Le lundi 9 mars 2009, Sam Hocevar a écrit :
> Dear list,
>
> I have modified git and git-p4 to a point where they are usable in
> my work environment. I am now faced with a new problem: Perforce's
> composite workspaces. They allow you to "mount" parts of the repo onto
> other directories, even nonempty ones.
It looks like SVN externals. So I think you should read about "git
submodule".
There is this related link on the wiki:
http://blog.alieniloquent.com/2008/03/08/git-svn-with-svnexternals/
You may also want to search the mailing list as this subject has often been
discussed.
Best regards,
Christian.
^ permalink raw reply
* Re: [PATCH] winansi: support ESC [ K (erase in line)
From: Johannes Sixt @ 2009-03-10 7:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster, Peter Harris, Sebastian Schuberth
In-Reply-To: <e2b19f6c7c50e5b0a652c40b0d8e4947134ed669.1236639280u.git.johannes.schindelin@gmx.de>
Johannes Schindelin schrieb:
> This fixes the last bit of msysGit issue 124 for me:
>
> http://code.google.com/p/msysgit/issues/detail?id=124
>
> which annoyed me one time to many today.
>
> I had an earlier version which was smaller, but pretty hacky, in
> that it checked if fprintf is #define'd in xwrite(), and had
> special handling for that case.
>
> This patch is only slightly hacky, in that it assumes that you do
> not try to output something that ends in an incomplete ESC [
> sequence.
Good that I read mail before I start hacking. I was about to do something
about this in a moment. ;)
> To make use of it during a fetch, write() needs to be overridden, too.
No, that's not necessary with the patch that I'm about to send in a
moment. To replace write() for ANSI emulation really goes too far.
-- Hannes
^ 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