* [JGIT PATCH] Add support for ~/.ssh/config PreferredAuthentications
From: Shawn O. Pearce @ 2008-09-16 5:48 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
Some configurations may wish to disable interactive methods of
authentication, such as when running from automated cron or batch
style jobs that have no user available.
Typically in an OpenSSH based system this would be configured on a
per-host basis in the current user's ~/.ssh/config file, by setting
PreferredAuthentications to the list of authentication methods
(e.g. just "publickey") that are reasonable.
JSch honors this configuration setting, but we need to transfer it
from our own OpenSshConfig class, otherwise it has no knowledge of
the setting.
http://code.google.com/p/egit/issues/detail?id=33
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../spearce/egit/ui/EclipseSshSessionFactory.java | 4 ++++
.../jgit/transport/DefaultSshSessionFactory.java | 4 ++++
.../org/spearce/jgit/transport/OpenSshConfig.java | 12 ++++++++++++
3 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/EclipseSshSessionFactory.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/EclipseSshSessionFactory.java
index 640a165..67c5f16 100644
--- a/org.spearce.egit.ui/src/org/spearce/egit/ui/EclipseSshSessionFactory.java
+++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/EclipseSshSessionFactory.java
@@ -50,6 +50,10 @@ if (pass != null)
session.setPassword(pass);
else
new UserInfoPrompter(session);
+
+ final String pauth = hc.getPreferredAuthentications();
+ if (pauth != null)
+ session.setConfig("PreferredAuthentications", pauth);
return session;
}
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/DefaultSshSessionFactory.java b/org.spearce.jgit/src/org/spearce/jgit/transport/DefaultSshSessionFactory.java
index 74fca66..b6f58f0 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/DefaultSshSessionFactory.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/DefaultSshSessionFactory.java
@@ -103,6 +103,10 @@ if (pass != null)
session.setPassword(pass);
else
session.setUserInfo(new AWT_UserInfo());
+
+ final String pauth = hc.getPreferredAuthentications();
+ if (pauth != null)
+ session.setConfig("PreferredAuthentications", pauth);
return session;
}
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/OpenSshConfig.java b/org.spearce.jgit/src/org/spearce/jgit/transport/OpenSshConfig.java
index cf7c388..748199c 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/OpenSshConfig.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/OpenSshConfig.java
@@ -278,6 +278,8 @@ if (ret.isAbsolute())
String user;
+ String preferredAuthentications;
+
void copyFrom(final Host src) {
if (hostName == null)
hostName = src.hostName;
@@ -287,6 +289,8 @@ if (identityFile == null)
identityFile = src.identityFile;
if (user == null)
user = src.user;
+ if (preferredAuthentications == null)
+ preferredAuthentications = src.preferredAuthentications;
}
/**
@@ -317,5 +321,13 @@ public File getIdentityFile() {
public String getUser() {
return user;
}
+
+ /**
+ * @return return the preferred authentication methods, separated by
+ * commas if more than one authentication method is preferred.
+ */
+ public String getPreferredAuthentications() {
+ return preferredAuthentications;
+ }
}
}
--
1.6.0.1.337.g5c7d67
^ permalink raw reply related
* [JGIT PATCH] Fix push to empty repository
From: Shawn O. Pearce @ 2008-09-16 5:38 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
If the remote repository has no commits we received an exception
about "capabilities^{} coming before capabilities". This happens
because we didn't correctly ignore the dummy capability ref line.
http://code.google.com/p/egit/issues/detail?id=34
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../spearce/jgit/transport/BasePackConnection.java | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/BasePackConnection.java b/org.spearce.jgit/src/org/spearce/jgit/transport/BasePackConnection.java
index 184a5fd..2d145a6 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/BasePackConnection.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/BasePackConnection.java
@@ -147,18 +147,18 @@ for (String c : line.substring(nul + 1).split(" "))
remoteCapablities.add(c);
line = line.substring(0, nul);
}
-
- if (line.equals("capabilities^{}")) {
- // special line from git-receive-pack to show
- // capabilities when there are no refs to advertise
- continue;
- }
}
if (line.length() == 0)
break;
String name = line.substring(41, line.length());
+ if (avail.isEmpty() && name.equals("capabilities^{}")) {
+ // special line from git-receive-pack to show
+ // capabilities when there are no refs to advertise
+ continue;
+ }
+
final ObjectId id = ObjectId.fromString(line.substring(0, 40));
if (name.endsWith("^{}")) {
name = name.substring(0, name.length() - 3);
--
1.6.0.1.337.g5c7d67
^ permalink raw reply related
* Re: Grafts workflow for a "shallow" repository...?
From: Shawn O. Pearce @ 2008-09-16 5:24 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Git Mailing List
In-Reply-To: <46a038f90809152209l2230d9e3o442dac1f5047d2bd@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> wrote:
> Here is my attempt at a "let's publish a shallow repository for branch
> of moodle". Let me show you what I did...
...
> # 1.7 was a significant release, anything earlier than that
> # is just not interesting -- even for pickaxe/annotate purposes
> # so add a graft point right at the branching point.
...
> Is this kind of workflow (or a variation of it) supported? For this to
> work, we should communicate the grafts in some push operations and
> read them in clone ops - and perhaps in fetch too.
Currently the grafts file isn't transferred over any transport
protocol as it is considered to be local only to the repository.
For one thing, grafts are a security risk. Any user can graft
anything in at any position and log/blame operations will honor
the graft, rather than what is stored in the signed commit chain.
Its a low risk, but it allows a peer to lie to you and give you
something other than what you asked for.
Pushing (or fetching) a graft just seems ugly. You don't want
to fetch a graft if you have no grafts because you have the full
history. Nor do you want to fetch a graft that might possibly
overwrite/replace a graft you already have. You might not want to
push all of your available grafts to a remote. Etc.
I think that in this case the best thing to do is give users
a shell script that does roughly:
git init
echo $BASE >.git/info/grafts
git remote add -f origin $url
git checkout -b master origin/master
Sign the script, and let users verify it before executing. You may
also want a script to drag in the history behind by removing the
graft and fetching $BASE^, but that is hard because your repository
already "has" that.
--
Shawn.
^ permalink raw reply
* Grafts workflow for a "shallow" repository...?
From: Martin Langhoff @ 2008-09-16 5:09 UTC (permalink / raw)
To: Git Mailing List
Here is my attempt at a "let's publish a shallow repository for branch
of moodle". Let me show you what I did...
# before we start
git --version
git version 1.5.5.1
cat /etc/redhat-release
Fedora release 9 (Sulphur)
# clone the 'full' repo ~200MB fully packed
git clone git://git.catalyst.net.nz/moodle-r2.git
# 1.7 was a significant release, anything earlier than that
# is just not interesting -- even for pickaxe/annotate purposes
# so add a graft point right at the branching point.
cd moodle-r2
echo `git merge-base origin/cvshead origin/MOODLE_17_STABLE` >>
.git/info/grafts
# push the branches I care about to a newly created repo on a different server
# this is approx 50MB... (as opposed to 200MB)
git push git+ssh://dev.laptop.org/home/martin/public_git/moodle.git \
origin/MOODLE_19_STABLE:refs/heads/MOODLE_19_STABLE
git push git+ssh://dev.laptop.org/home/martin/public_git/moodle.git \
origin/cvshead:refs/heads/cvshead
# fixed up the server-side repo to have HEAD pointing to a new branch...
# clone to see it works...
git clone git://dev.laptop.org/git/users/martin/moodle.git
# and now gitk bails out on me. Not entirely unexpected...
gitk --all
Is this kind of workflow (or a variation of it) supported? For this to
work, we should communicate the grafts in some push operations and
read them in clone ops - and perhaps in fetch too.
cheers,
martin
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: [PATCH] Optional shrinking of RCS keywords in git-p4
From: dhruva @ 2008-09-16 4:53 UTC (permalink / raw)
To: David Brown, Daniel Barkalow; +Cc: Junio C Hamano, GIT SCM, Simon Hausmann
Hi,
----- Original Message ----
> From: David Brown <git@davidb.org>
> Part of the problem is that p4 isn't very good at knowing whether
> files have changed or not. 'p4 sync' will update the file _if_ if
> thinks your version is out of date, but it does nothing if someone has
> locally modified the file, hence the need for the 'p4 sync -f'.
If you have modified a file without doing a 'p4 edit' and if there is a new version of the edited file on p4 (from what you have got from a previous 'p4 sync'), 'p4 sync' will overwrite your changes (if the file does not have write perm set or if you have enabled clobbering of writable files). Whereas 'p4 sync -f' will always overwrite all unopened files if a newer version is available.
-dhruva
Unlimited freedom, unlimited storage. Get it now, on http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html/
^ permalink raw reply
* Re: [PATCH] Optional shrinking of RCS keywords in git-p4
From: David Brown @ 2008-09-16 4:12 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, dhruva, GIT SCM, Simon Hausmann
In-Reply-To: <alpine.LNX.1.00.0809151354040.19665@iabervon.org>
On Mon, Sep 15, 2008 at 03:22:33PM -0400, Daniel Barkalow wrote:
>Actually, the problem seems to be that git-p4 tries to create the modified
>file by applying the git-generated diff to the p4-provided file, and this
>fails if the context for the git-generated diff contains a keyword, since
>the p4-provided file has it expanded and git has it collapsed.
It is very likely that I've never made a change within context-lines
of a RCS header. The files we have with these headers tend to also
comment blocks at the top that don't change after the file is created.
>I think the right solution is for git-p4 to check that p4 thinks the file
>is the correct file and then simply replace it rather than trying to
>generate the right result by patching. To be a bit more careful, git-p4
>could check that the contents it's replacing actually would exactly match
>the git contents if the keywords were callapsed (if the p4 setting is to
>use keywords in this file).
Part of the problem is that p4 isn't very good at knowing whether
files have changed or not. 'p4 sync' will update the file _if_ if
thinks your version is out of date, but it does nothing if someone has
locally modified the file, hence the need for the 'p4 sync -f'.
A simple way to be paranoid would be something (shell-ish) like:
p4 print filename | collapse-keywords | git hash-object --stdin
and make sure that is the version we think the file should have
started with. I think we're really just making sure we didn't miss a
P4 change that someone else made underneath, and we're about to back
out.
Even this isn't robust from p4's point of view. The p4 model is to do
a 'p4 edit' on the file, and then the later 'p4 submit' will give an
error if someone else has updated the file. This would require using
p4's conflict resolution, and I'm guessing someone using git-p4 would
rather abort the submit and rebase.
David
^ permalink raw reply
* Re: [PATCH] Start conforming code to "git subcmd" style part 3
From: Junio C Hamano @ 2008-09-16 4:09 UTC (permalink / raw)
To: Heikki Orsila
Cc: git, Jakub Narebski, Christian Couder, Andreas Ericsson,
Thomas Rast
In-Reply-To: <20080913171836.GA5597@zakalwe.fi>
Heikki Orsila <heikki.orsila@iki.fi> writes:
> User notifications are presented as 'git cmd', and code comments
> are presented as '"cmd"' or 'git's cmd', rather than 'git-cmd'.
>
> Signed-off-by: Heikki Orsila <heikki.orsila@iki.fi>
> ---
> Part 3 resent. A small fix from Thomas Rast for builtin-tar-tree.c.
I did not see anything wrong in the patch; thanks.
^ permalink raw reply
* Re: [PATCH] Optional shrinking of RCS keywords in git-p4
From: dhruva @ 2008-09-16 2:51 UTC (permalink / raw)
To: Tor Arvid Lund; +Cc: Junio C Hamano, David Brown, GIT SCM, Simon Hausmann
Hello,
----- Original Message ----
> On Mon, Sep 15, 2008 at 1:46 PM, dhruva wrote:
> > ----- Original Message ----
> >> From: Tor Arvid Lund
> ------ >8 ------
> >> Hmm.. I thought this was not a p4 problem. I think however, that
> >> "git-p4 submit" tries to do git format-patch and then git apply that
> >> patch to the p4 directory. In other words, I believe that git apply
> >> fails since the file in the p4 dir has the keywords expanded, while
> >> the patch does not. I haven't done any careful investigation, but If
> >> my assumption is true, it sounds like dhruvas patch should work...
> >
> > Your assumption is true (from my understanding of the code). My doubt is, even
> the files in p4 folder will be from git with no RCS keyword expanded. The patch
> application must ideally be clean! I am confused here.
>
> Hmm, regarding the p4 folder - I'm pretty sure git-p4 calls "p4 sync
> /..." in that folder before applying the patch. So those
> files are whatever p4 says they are - which is with keywords
> expanded...
I went through the script more closely, you are correct in your analysis. There is a call to 'p4 sync' (around line 797) before applying the commit patches (around line 809). Hence, the current patch would fix this problem of missing hunks with RCS keywords. The other approach of overwriting instead of applying the patch would also work but I feel that is a bit dangerous. It is better to fail if something goes minutely wrong than submit the wrong file (just being a paranoid defensive programmer).
-dhruva
Get an email ID as yourname@ymail.com or yourname@rocketmail.com. Click here http://in.promos.yahoo.com/address
^ permalink raw reply
* You don't exist, Go away! although user.name has been set
From: Marc Weber @ 2008-09-16 1:05 UTC (permalink / raw)
To: git
Today I was glad. I 've been able to compile git on a maanged server.
git clone did work as well however running
git fetch <remote location> caused the line
die("You don't exist. Go away!");
to be executed. (the first one)
Before examining that I asked at #git and got the tip to set
user.name and user.email which I did. Then I verified that git
git var GIT_AUTHOR_IDENT and
git var GIT_COMMITTER_IDENT
both printed some values.
I still got the failure above.
I've fixed it for my case by setting
git_default_name and git_default_email just before the check within the
ident.c file (line 76)..
However I want to ask wether I've hit a known problem and wether you
would appreciate me debggung this issue any further?
Maybe I should add that I've been running that git from the build
directory if that matters. The version is 1.6.0 from the official
mirror site.
Marc Weber
^ permalink raw reply
* Re: [IRC/patches] Failed octopus merge does not clean up
From: Junio C Hamano @ 2008-09-16 0:20 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Miklos Vajna, Jakub Narebski
In-Reply-To: <7v63ox9e20.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Thomas Rast <trast@student.ethz.ch> writes:
>
>> The merge says
>>
>> Trying simple merge with 5b3e4bb1c2d88d6967fb575729fbfc86df5eaec9
>> Simple merge did not work, trying automatic merge.
>> Auto-merging foo
>> ERROR: Merge conflict in foo
>> fatal: merge program failed
>> Automated merge did not work.
>> Should not be doing an Octopus.
>> Merge with strategy octopus failed.
> ...
> Read the second from the last line of what you were told by git. Run "git
> reset --hard" after that, perhaps.
By the way, there are three failure modes in Octopus.
(0) your index (not work tree) is dirty; this is not limited to octopus
merge but any merge will be refused;
(1) while it merges other heads one-by-one, it gets conflicts on an
earlier one, before it even attempts to merge all of them. Recording
the heads that it so far attempted to merge in MERGE_HEAD is wrong
(the result won't be an Octopus the end user wanted to carete), and
recording all the heads the user gave in MERGE_HEAD is even more
wrong (it hasn't even looked at the later heads yet, so there is no
way for the index or work tree to contain anything from them).
The above is hitting this case.
(2) it gets conflicts while merging the _last_ head. It records
MERGE_HEAD and allows you to record the resolved result.
I think originally we treated (1) and (2) the same way, because an Octopus
is to record the most trivial merge with more than 2 legs, and a rough
definition of "the most trivial" is "tracks of totally independent works;
you could merge them one by one and _in any order_, and the result won't
matter because they are logically independent. However if they are _so_
independent, why not record them as merged in one step (i.e. octopus),
instead of insisting on recording in what order you merged them".
Obviously, if you get a conflict during Octopus creation, they were not
tracks of totally independent works, and that is where the "Should not" in
the message comes from.
We later relaxed it to allow a conflict at the last step, not because
recording an Octopus with nontrivial merge is particuarly a good idea we
should encourage, but because there simply weren't reason not to.
^ permalink raw reply
* Re: [PATCH] Documentation: replace [^~] with escapes everywhere
From: Avery Pennarun @ 2008-09-16 0:10 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano
In-Reply-To: <200809160205.23371.trast@student.ethz.ch>
On Mon, Sep 15, 2008 at 8:05 PM, Thomas Rast <trast@student.ethz.ch> wrote:
> Avery Pennarun wrote:
>> Rather than uglifying all the documentation to work around the syntax,
>> perhaps we just want to disable subscripts and superscripts
>> altogether? I can't really imagine the git documentation needing
>> them.
>>
>> To do so, we can add these lines to asciidoc.conf (I just did this on
>> another project yesterday, but I haven't tested in git.git):
>>
>> [replacements]
>> # Disable superscripts.
>> \^(.+?)\^=^\1^
>> # Disable subscripts.
>> ~(.+?)~=~\1~
>
> That's indeed a far superior solution. I withdraw my patches in
> favour of this.
Er, do you mind submitting (and testing :)) a new patch that does it?
I don't have time right now.
Avery
^ permalink raw reply
* Re: [PATCH] Documentation: warn against merging in a dirty tree
From: Junio C Hamano @ 2008-09-16 0:06 UTC (permalink / raw)
To: Avery Pennarun
Cc: Junio C Hamano, Thomas Rast, git, Jakub Narebski, Miklos Vajna
In-Reply-To: <32541b130809151653w27d7876fp35e0967d597ae2a9@mail.gmail.com>
"Avery Pennarun" <apenwarr@gmail.com> writes:
> But how do you abort a *failed* merge in a situation like Linus's
> example? "git reset --hard HEAD" would destroy the unstaged Makefile
> change.
"All of your work tree changes are easily reproducible" implies you do not
mind losing them, Ok?
Also "git reset HEAD" (that is, without --hard) would not touch the work
tree changes. You need to remove the work-tree cruft left by new files
yourself, if you go this route, though. New files are rare enough so it
may be more appropriate (and you can "git clean -n $that_subdirectory" to
enumerate them).
It all depends on your workflow.
^ permalink raw reply
* Re: [PATCH] Documentation: replace [^~] with escapes everywhere
From: Thomas Rast @ 2008-09-16 0:05 UTC (permalink / raw)
To: Avery Pennarun; +Cc: git, Junio C Hamano
In-Reply-To: <32541b130809151656n4f39018fu2045eb6280d6da00@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 617 bytes --]
Avery Pennarun wrote:
> Rather than uglifying all the documentation to work around the syntax,
> perhaps we just want to disable subscripts and superscripts
> altogether? I can't really imagine the git documentation needing
> them.
>
> To do so, we can add these lines to asciidoc.conf (I just did this on
> another project yesterday, but I haven't tested in git.git):
>
> [replacements]
> # Disable superscripts.
> \^(.+?)\^=^\1^
> # Disable subscripts.
> ~(.+?)~=~\1~
That's indeed a far superior solution. I withdraw my patches in
favour of this.
--
Thomas Rast
trast@student.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Documentation: replace [^~] with escapes everywhere
From: Avery Pennarun @ 2008-09-15 23:56 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano
In-Reply-To: <1221470398-8698-3-git-send-email-trast@student.ethz.ch>
On Mon, Sep 15, 2008 at 5:19 AM, Thomas Rast <trast@student.ethz.ch> wrote:
> Replaces all ^ and ~ that are not part of a "literal" paragraph with
> {caret} and {tilde}.
>
> Tildes and carets are ordinarily used for ~sub~ and ^super^scripts.
> This only triggers if a suitable chunk of text is found within the
> current paragraph, so in most cases nothing happens (and the
> tilde/caret is taken literally). However, it is a pitfall for anyone
> who later adds more text to the same paragraph, so we might as well do
> it right.
Rather than uglifying all the documentation to work around the syntax,
perhaps we just want to disable subscripts and superscripts
altogether? I can't really imagine the git documentation needing
them.
To do so, we can add these lines to asciidoc.conf (I just did this on
another project yesterday, but I haven't tested in git.git):
[replacements]
# Disable superscripts.
\^(.+?)\^=^\1^
# Disable subscripts.
~(.+?)~=~\1~
(For reference, the regexes on the left side of the equal sign came
from a file in /etc/asciidoc somewhere.)
Have fun,
Avery
^ permalink raw reply
* Re: [PATCH] Documentation: warn against merging in a dirty tree
From: Avery Pennarun @ 2008-09-15 23:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, git, Jakub Narebski, Miklos Vajna
In-Reply-To: <7vtzch7z7u.fsf@gitster.siamese.dyndns.org>
On Mon, Sep 15, 2008 at 7:42 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Thomas Rast <trast@student.ethz.ch> writes:
>
>> Merging in a dirty tree is usually a bad idea because you need to
>> reset --hard to abort; but the docs didn't say anything about it.
>
> Strictly speaking, you do not have to worry about anything if (1) all of
> your work tree changes are easily reproducible (Linus's keeping a new
> EXTRAVERSION in his Makefile, never staged nor committed is an often cited
> example), or (2) you know beforehand that a merge with the other party
> will not touch the part you have local changes that you care about.
>
> In other words, you need to know what you are doing, and a warning with
> "usually it is a bad idea" would be an appropriate thing to do.
But how do you abort a *failed* merge in a situation like Linus's
example? "git reset --hard HEAD" would destroy the unstaged Makefile
change.
I would love to know the answer to this for my own work, and I guess
it would be relevant to the documentation too.
Have fun,
Avery
^ permalink raw reply
* Re: [IRC/patches] Failed octopus merge does not clean up
From: Thomas Rast @ 2008-09-15 23:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Miklos Vajna, Jakub Narebski
In-Reply-To: <7v63ox9e20.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 701 bytes --]
Junio C Hamano wrote:
> Thomas Rast <trast@student.ethz.ch> writes:
[...]
> > Should not be doing an Octopus.
[...]
> > Shouldn't it either really clean up, or really
> > leave the repo in a conflicted merge state?
[...]
> Your analysis is correct --- this has been the correct/established
> behaviour of Octopus from day one.
Including not cleaning up the half-merged state? If the answer is
"yes", then so be it, merge-octopus has been on this project longer
than I have ;-)
However,
> Run "git reset --hard" after that, perhaps.
wasn't immediately obvious to the end-user (jammyd in this case),
which started the discussion.
--
Thomas Rast
trast@student.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Documentation: warn against merging in a dirty tree
From: Junio C Hamano @ 2008-09-15 23:42 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Jakub Narebski, Miklos Vajna
In-Reply-To: <1221518994-26111-2-git-send-email-trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Merging in a dirty tree is usually a bad idea because you need to
> reset --hard to abort; but the docs didn't say anything about it.
Strictly speaking, you do not have to worry about anything if (1) all of
your work tree changes are easily reproducible (Linus's keeping a new
EXTRAVERSION in his Makefile, never staged nor committed is an often cited
example), or (2) you know beforehand that a merge with the other party
will not touch the part you have local changes that you care about.
In other words, you need to know what you are doing, and a warning with
"usually it is a bad idea" would be an appropriate thing to do.
^ permalink raw reply
* Re: [IRC/patches] Failed octopus merge does not clean up
From: Junio C Hamano @ 2008-09-15 23:36 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Miklos Vajna, Jakub Narebski
In-Reply-To: <200809160048.31443.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> The merge says
>
> Trying simple merge with 5b3e4bb1c2d88d6967fb575729fbfc86df5eaec9
> Simple merge did not work, trying automatic merge.
> Auto-merging foo
> ERROR: Merge conflict in foo
> fatal: merge program failed
> Automated merge did not work.
> Should not be doing an Octopus.
> Merge with strategy octopus failed.
>
> So far so good. However, 'git status' claims
> ... This behaviour is
> identical for 1.5.6 and 1.6.0.2, so it is not caused by the merge
> rewrite as a builtin. Shouldn't it either really clean up, or really
> leave the repo in a conflicted merge state? (I'm following up with a
> patch that turns the above into a test. Octopus doesn't really have
> many tests, does it?)
Your analysis is correct --- this has been the correct/established
behaviour of Octopus from day one.
Read the second from the last line of what you were told by git. Run "git
reset --hard" after that, perhaps.
^ permalink raw reply
* Re: Help using Git(-svn) for specific use case
From: Pico Geyer @ 2008-09-15 22:53 UTC (permalink / raw)
To: git
In-Reply-To: <20080915214740.GI28210@dpotapov.dyndns.org>
Thanks guys for your replies and advice.
I'm going to be trying to configure such a setup tomorrow.
I'll probably have more questions :-)
Regards,
Pico Geyer
On Mon, Sep 15, 2008 at 11:47 PM, Dmitry Potapov <dpotapov@gmail.com> wrote:
> On Mon, Sep 15, 2008 at 11:15:59PM +0200, Michael J Gruber wrote:
>> Sverre Rabbelier venit, vidit, dixit 15.09.2008 22:59:
>> >
>> > I thought this was fixed in a more recent version of git-svn? Didn't
>> > it even work both ways?
>>
>> Kind of. You can't fake a different author when committing to svn.
>
> This is not exactly correct as you can fake author if you have the right
> to change the svn:author property (or what is its name?), but by default
> this is not allowed to anyone, and git-svn does not support this method
> anyway.
>
>> But
>> "--add-author-from" makes dcommit embed the author in the svn commit
>> message (if there's no from nor sob), and "--use-log-author" makes fetch
>> look for that info and use it.
>
> Yes, it works. And it is very useful especially you are going eventually
> convert your SVN repository in Git (so all authorship information will
> be retain). Probably, I should have mentioned this possibility.
>
> Thanks,
> Dmitry
>
^ permalink raw reply
* [PATCH] Documentation: warn against merging in a dirty tree
From: Thomas Rast @ 2008-09-15 22:49 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Miklos Vajna
In-Reply-To: <1221518994-26111-1-git-send-email-trast@student.ethz.ch>
Merging in a dirty tree is usually a bad idea because you need to
reset --hard to abort; but the docs didn't say anything about it.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Documentation/git-merge.txt | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index 685e1fe..3798e16 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -22,6 +22,11 @@ The second syntax (<msg> `HEAD` <remote>) is supported for
historical reasons. Do not use it from the command line or in
new scripts. It is the same as `git merge -m <msg> <remote>`.
+NOTE: Usually it is a bad idea to merge with a dirty tree or index.
+ If you get conflicts and want to abort (instead of resolving),
+ you need to `git reset \--hard` which loses the uncommitted
+ changes.
+
OPTIONS
-------
--
tg: (1293c95..) t/doc-merge-reset (depends on: origin/master)
^ permalink raw reply related
* [PATCH] Add test that checks octopus merge cleanup
From: Thomas Rast @ 2008-09-15 22:49 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Miklos Vajna
In-Reply-To: <200809160048.31443.trast@student.ethz.ch>
Currently, a conflicted octopus merge leaves the repository in a
"halfway into the merge state", where .git/MERGE_HEAD is missing but
the files are listed as conflicted in the index and have conflict
markers in them. It should either clean up everything, or add a
MERGE_HEAD.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
t/t7607-merge-octopus-cleanup.sh | 31 +++++++++++++++++++++++++++++++
1 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/t/t7607-merge-octopus-cleanup.sh b/t/t7607-merge-octopus-cleanup.sh
new file mode 100755
index 0000000..4d82867
--- /dev/null
+++ b/t/t7607-merge-octopus-cleanup.sh
@@ -0,0 +1,31 @@
+#!/bin/sh
+
+test_description='git merge
+
+Testing that conflicting octopus merge fails cleanly.'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+ echo initial > foo &&
+ git add foo &&
+ git commit -m initial &&
+ echo a > foo &&
+ git commit -m a foo &&
+ git checkout -b b HEAD^ &&
+ echo b > foo &&
+ git commit -m b foo &&
+ git checkout -b c HEAD^ &&
+ echo c > foo &&
+ git commit -m c foo &&
+ git checkout master
+'
+
+test_expect_failure 'conflicted octopus merge' '
+ test_must_fail git merge b c &&
+ test -z "$(git ls-files --unmerged)" &&
+ test "$(cat foo)" == a &&
+ test ! -f .git/MERGE_HEAD
+'
+
+test_done
--
tg: (1293c95..) t/test-octopus-cleanup (depends on: origin/master)
^ permalink raw reply related
* [IRC/patches] Failed octopus merge does not clean up
From: Thomas Rast @ 2008-09-15 22:48 UTC (permalink / raw)
To: git; +Cc: Miklos Vajna, Jakub Narebski
[-- Attachment #1: Type: text/plain, Size: 2024 bytes --]
Hi *
James "jammyd" Mulcahy pointed out on IRC that the octopus merge
strategy doesn't properly clean up behind itself. To wit:
git init
echo initial > foo
git add foo
git commit -m initial
echo a > foo
git commit -m a foo
git checkout -b b HEAD^
echo b > foo
git commit -m b foo
git checkout -b c HEAD^
echo c > foo
git commit -m c foo
git checkout master
git merge b c
The merge says
Trying simple merge with 5b3e4bb1c2d88d6967fb575729fbfc86df5eaec9
Simple merge did not work, trying automatic merge.
Auto-merging foo
ERROR: Merge conflict in foo
fatal: merge program failed
Automated merge did not work.
Should not be doing an Octopus.
Merge with strategy octopus failed.
So far so good. However, 'git status' claims
# unmerged: foo
and indeed the contents of 'foo' are the conflicted merge between
'master' and 'b', yet there is no .git/MERGE_HEAD. This behaviour is
identical for 1.5.6 and 1.6.0.2, so it is not caused by the merge
rewrite as a builtin. Shouldn't it either really clean up, or really
leave the repo in a conflicted merge state? (I'm following up with a
patch that turns the above into a test. Octopus doesn't really have
many tests, does it?)
On the code path to the "Merge with strategy %s failed" message,
builtin-merge.c:1134 runs restore_state() which runs reset_hard().
But (as Miklos pointed out) that cannot actually do 'git reset --hard'
because it is possible (though not recommended, see below) to start a
merge with a dirty index.
Jakub mentioned that there are only three index stages for a three-way
merge, so a conflicted n-way (simultaneous) merge is not really
possible.
The merge manpage should warn about merging with uncommitted changes.
It recommends 'git rebase --hard' to abort during conflicts, but does
not mention that this throws away said changes. I'm following up with
a patch for this.
- Thomas
--
Thomas Rast
trast@student.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Management of opendocument (openoffice.org) files in git
From: Sergio Callegari @ 2008-09-15 22:40 UTC (permalink / raw)
To: git
Hi,
Management of opendocument files in git has been discussed a short time ago.
Here is an helper script that may help achieving better density in git packs
containg blobs from openoffice files.
To try it, save the following as "rezip" with execution permission:
-----8<-----------------------
#! /bin/bash
#
# (c) 2008 Sergio Callegari
#
# Rewrites a zip archive, possibly changing the compression level
USAGE='Usage: rezip [options] [file]
with options:
[-h | --help] Gives help
[-p ?] Lists known profiles
[--unzip_opts options] Pass options to unzip helper to read zip file
[--zip_opts options] Pass options to zip helper to write zip file
[-p | --profile profile] Get options for helpers from profile
Rewrites a zip archive, possibily changing the compression level.
If the archive name is unspecified, then the command operates like a filter,
reading from standard input and writing to standard output.
Options can be manually provided to the unzip process doing the read and to
the zip process doing the write. Alternatively a profile can be used to set
options automatically.'
PROFILES="ODF_UNCOMPRESS ODF_COMPRESS"
PROFILE_UNZIP_ODF_UNCOMPRESS='-b -qq -X'
PROFILE_ZIP_ODF_UNCOMPRESS='-q -r -D -0'
PROFILE_UNZIP_ODF_COMPRESS='-b -qq -X'
PROFILE_ZIP_ODF_COMPRESS='-q -r -D -6'
die()
{
echo "$1" >&$2
exit $3
}
UNZIP_OPTS=""
ZIP_OPTS=""
while true ; do
case "$1" in
-h | --help)
die "$USAGE" 1 0 ;;
-p | --profile)
if [ "$2" = "?" ] ; then
die "Avalilable profiles: ${PROFILES}" 1 0 ;
else
profile=$2
shift
profile_unzip=PROFILE_UNZIP_${profile}
profile_zip=PROFILE_ZIP_${profile}
UNZIP_OPTS=${!profile_unzip}
ZIP_OPTS=${!profile_zip}
fi ;;
--unzip_opts)
UNZIP_OPTS=${UNZIP_OPTS} $2
shift ;;
--zip_opts)
ZIP_OPTS=${ZIP_OPTS} $2
shift ;;
-*)
die "$USAGE" 2 1 ;;
*)
break ;;
esac
shift
done
if [ $# = 0 ] ; then
tmpcopy=$(mktemp rezip.zip.XXXXXX)
cat > $tmpcopy
filename="$tmpcopy"
else
tmpcopy=""
filename="$1"
fi
workdir=$(mktemp -d -t rezip.workdir.XXXXXX)
curdir=$(pwd)
cd $workdir
unzip $UNZIP_OPTS "$curdir/$filename"
zip $ZIP_OPTS "$curdir/$filename" .
cd $curdir
rm -fr $workdir
if [ ! -z "$tmpcopy" ] ; then
cat $filename
rm $tmpcopy
fi
--------8<------------------------
then put in your .git/config something like
[filter "opendocument"]
clean = "rezip -p ODF_UNCOMPRESS"
smudge = "rezip -p ODF_COMPRESS"
and finally set gitattributes as
*.odt filter=opendocument
*.ods filter=opendocument
*.odp filter=opendocument
Note:
with this you might experience some delay on operations like
git status
git add
git commit -a
git checkout
depending on the size of the opendocument files being tracked.
Before using on anything sensitive, please test that it does what it should.
The script should probably be made more robust against unexpected situations.
Hope it can be useful to someone.
Sergio
^ permalink raw reply
* Re: git-clone: path or ssh problem with git-upload-pack in 1.6.0?
From: Michael Wookey @ 2008-09-15 22:39 UTC (permalink / raw)
To: Paul Johnston; +Cc: git
In-Reply-To: <d3a045300809091929h18c3c447gb3d4e79131f66986@mail.gmail.com>
> I'm having trouble with git-clone and I'm wondering if there's
> something I'm doing wrong or something wrong with git. Probably the
> former, hopefully someone can set me straight.
>
> I'm an admittedly novice git user. I'm trying to clone a repository
> over ssh. The host machine 'imac' is my mac osx 10.4 with git 1.6.0
> installed from a macports package. This installs into /opt/local/bin.
> I also cloned git from HEAD and 'make; make install'ed into ~/bin,
> this is the version shown below. Either way, these are
> nonstandard/non-system-wide installation locations, and it requires
> that my shell PATH reflect this, obviously.
The following might help..
http://marc.info/?l=git&m=121378876831164&w=2
^ permalink raw reply
* Re: Diff-tree does not work for initial commit
From: Jeff King @ 2008-09-15 22:34 UTC (permalink / raw)
To: sverre; +Cc: Michael J Gruber, Anatol Pomozov, Git Mailing List
In-Reply-To: <bd6139dc0809151411p49f5adeaq4beff452574ca980@mail.gmail.com>
On Mon, Sep 15, 2008 at 11:11:30PM +0200, Sverre Rabbelier wrote:
> Some of my code uses "git rev-parse" on "HEAD^" to see if a commit has
> a parent; I wouldn't be surprised if someone else has a script that
> uses "git diff-tree" or such for that purpose, or at least assumes
> that for a root commit it will complain. Anyway, as Junio said, for
> "diff-tree" you can use the "--root" option. A better RFE would
> perhaps be that "--root" be supported in more places.
I posted this a week or so ago, but I am sure it is incomplete. If there
is interest I can clean it up and do a proper submission.
---
diff --git a/builtin-diff.c b/builtin-diff.c
index 76651bd..4151900 100644
--- a/builtin-diff.c
+++ b/builtin-diff.c
@@ -332,8 +332,11 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
break;
else if (!strcmp(arg, "--cached")) {
add_head_to_pending(&rev);
- if (!rev.pending.nr)
- die("No HEAD commit to compare with (yet)");
+ if (!rev.pending.nr) {
+ if (!rev.show_root_diff)
+ die("No HEAD commit to compare with (yet)");
+ add_empty_to_pending(&rev);
+ }
break;
}
}
diff --git a/revision.c b/revision.c
index 2f646de..7ec3990 100644
--- a/revision.c
+++ b/revision.c
@@ -145,16 +145,27 @@ void add_pending_object(struct rev_info *revs, struct object *obj, const char *n
add_pending_object_with_mode(revs, obj, name, S_IFINVALID);
}
-void add_head_to_pending(struct rev_info *revs)
+static void add_to_pending_by_name(struct rev_info *revs, const char *name)
{
unsigned char sha1[20];
struct object *obj;
- if (get_sha1("HEAD", sha1))
+ if (get_sha1(name, sha1))
return;
obj = parse_object(sha1);
if (!obj)
return;
- add_pending_object(revs, obj, "HEAD");
+ add_pending_object(revs, obj, name);
+}
+
+void add_head_to_pending(struct rev_info *revs)
+{
+ add_to_pending_by_name(revs, "HEAD");
+}
+
+void add_empty_to_pending(struct rev_info *revs)
+{
+ add_to_pending_by_name(revs,
+ "4b825dc642cb6eb9a060e54bf8d69288fbee4904");
}
static struct object *get_reference(struct rev_info *revs, const char *name, const unsigned char *sha1, unsigned int flags)
diff --git a/revision.h b/revision.h
index 2fdb2dd..8c990d5 100644
--- a/revision.h
+++ b/revision.h
@@ -152,6 +152,7 @@ extern void add_object(struct object *obj,
extern void add_pending_object(struct rev_info *revs, struct object *obj, const char *name);
extern void add_head_to_pending(struct rev_info *);
+extern void add_empty_to_pending(struct rev_info *);
enum commit_action {
commit_ignore,
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox