* Re: How can I access remote branches in a cloned repository on my local machine?
From: Jan Hudec @ 2007-10-20 14:09 UTC (permalink / raw)
To: Erich Ocean; +Cc: git
In-Reply-To: <05B1B470-1C86-40E6-9E33-968809414537@atlasocean.com>
[-- Attachment #1: Type: text/plain, Size: 2851 bytes --]
On Sat, Oct 20, 2007 at 06:15:21 -0700, Erich Ocean wrote:
> Our developer group has a shared git repository at
> git@git.1kstudios.lan:dev.
>
> Each developer has established their own local repository by running:
>
> git clone git@git.1kstudios.lan:dev
> git config remote.origin.push master:refs/remotes/<username>/master
The paths on server are refs/remotes/<userame>/master.
It's more common to publish (push to public or shared repository) to
refs/heads. The refs/remotes namespace is normally only used when fetching.
There's nothing in git saying you can't do it your way, but there are things
that make the common way more convenient.
> Each developer then does a `git pull` to update their master branch, merges
> their changes from their local topic branches, and then does `git push` to
> make the results available at git@git.1kstudios.lan:dev.
>
> As the integrator, I have then been ssh'ing into the git@git.1kstudios.lan
> machine, cd'ing to "dev" and doing:
>
> git merge <username>/master
Yes, because locally refs/remotes is searched when looking for unqualified
ref. But if you checked that out, git would complain it's not a branch and
created a detached head.
> to incorporate their changes after running `git diff` to see what the
> changes are.
>
> My own development repository is set up identically to the other
> developers.
>
> What I would like to do now is clone the git@git.1kstudios.lan:dev
> repository on my local machine a second time, checkout a <username>/master
> branch in that repository, and then use BBEdit's graphical diff to visually
> see the changes between my own repository and what another developer has
> pushed to the shared repository. I'll then merge them into my own developer
> repository and push that to the shared repository for the rest of the
> developers to pull from, so no longer will I merge by ssh'ing into the
> machine with the shared repository.
>
> The problem is, when I clone git@git.1kstudios.lan:dev, the various
> <username>/master's aren't there. I have tried a bunch of different ways,
> but they all give me errors. For example:
By default clone only compies refs from refs/heads to refs/remotes/origin and
from refs/tags to refs/tags.
You have two options here:
- Move the branches on server to refs/heads. Then the various
<username>/master will be visible locally as origin/<username>/master
(qualified names refs/remotes/origin/<username>/master -- you can of
course call the remote differently if you want).
- Add +refs/remotes/*:refs/remotes/origin/* to remote.origin.fetch config
key in your local repository (I am not sure it will work properly with
multiple source patterns with the same destination pattern, though).
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [Solved] How can I access remote branches in a cloned repository on my local machine?
From: Erich Ocean @ 2007-10-20 14:18 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0710201455540.8248@beast.quantumfyre.co.uk>
Per Julian Phillips' suggestion:
> logan-2:~ ocean$ cd commiters/
> logan-2:~/commiters ocean$ git config remote.origin.fetch +refs/
remotes/*:refs/remotes/*
> logan-2:~/commiters ocean$ git fetch
> git@git.1kstudios.lan's password:
> * refs/remotes/eocean/master: storing remote branch 'eocean/
master' of git@git.1kstudios.lan:dev
> commit: 06b4b2e
> * refs/remotes/gt/master: storing remote branch 'gt/master' of
git@git.1kstudios.lan:dev
> commit: 889a585
> * refs/remotes/jchumley/master: storing remote branch 'jchumley/
master' of git@git.1kstudios.lan:dev
> commit: 18cead3
> logan-2:~/commiters ocean$ git branch
> +refs/remotes/eocean/master
> +refs/remotes/gt/master
> +refs/remotes/jchumley/master
> * master
> logan-2:~/commiters ocean$ git checkout +refs/remotes/jchumley/
master
> Switched to branch "+refs/remotes/jchumley/master"
Best, Erich
On Oct 20, 2007, at 6:56 AM, Julian Phillips wrote:
> On Sat, 20 Oct 2007, Julian Phillips wrote:
>
>>> The problem is, when I clone git@git.1kstudios.lan:dev, the various
>>> <username>/master's aren't there. I have tried a bunch of
>>> different ways,
>>> but they all give me errors. For example:
>>
>> The default fetch refspec doesn't include the remotes - after all,
>> you normally don't want the origin for your origin ...
>>
>>> How can I access remote branches in a cloned repository on my local
>>> machine?
>>
>> Try something like:
>>
>> git config remote.origin.fetch +refs/remotes/*:+refs/remotes/*
>
> sorry, that should have been:
> git config remote.origin.fetch +refs/remotes/*:refs/remotes/*
>
>> git fetch
>
> --
> Julian
>
> ---
> "The National Association of Theater Concessionaires reported that in
> 1986, 60% of all candy sold in movie theaters was sold to Roger
> Ebert."
> -- D. Letterman
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* git-p4 pull request
From: Simon Hausmann @ 2007-10-20 15:17 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Chris Pettitt
[-- Attachment #1: Type: text/plain, Size: 645 bytes --]
Hi,
The following changes since commit 7840ce6cb24a9d65152d45e08f5d7cf7dc97a2e3:
Shawn O. Pearce (1):
Merge branch 'maint'
are available in the git repository at:
git://repo.or.cz/git/git-p4.git git-p4
Chris Pettitt (1):
git-p4 support for perforce renames.
Simon Hausmann (1):
git-p4: When skipping a patch as part of "git-p4 submit" make sure we
correctly revert to the previous state of the files using "p4 revert".
contrib/fast-import/git-p4 | 16 +++++++++++++++-
1 files changed, 15 insertions(+), 1 deletions(-)
These changes fit nicely into master I would say.
Thanks,
Simon
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: gitk patch collection pull request
From: Jan Hudec @ 2007-10-20 15:32 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Paul Mackerras, Shawn O. Pearce, git
In-Reply-To: <B3349B61-995B-42D0-B777-CEA618943848@steelskies.com>
[-- Attachment #1: Type: text/plain, Size: 2079 bytes --]
On Sat, Oct 20, 2007 at 14:00:20 +0100, Jonathan del Strother wrote:
>
> On 20 Oct 2007, at 12:46, Paul Mackerras wrote:
>
>> Jonathan del Strother writes:
>>
>>> In my defense, most of that file is space indented, and the places
>>
>> Only the lines that are indented 1 level start with spaces. Any line
>> that is indented 2 or more levels should start with a tab.
>
>>> It seems to have the whole 'tabs for code
>>> indentation, with space for alignment' rule back-to-front.
>>
>> I don't recall signing up to that rule. :) I use 4-column indentation
>> and 8-column tabs, and my editor (emacs) handles it all automatically
>> for me.
>
>
> Ugh... I don't usually get involved in tab/space wars, but I'm curious...
> why on earth would you choose this style?
Because that's default behaviour of both emacs and vi when you set
indentation different from tabstop. Actually most of GNU software, whether it
uses the GNU standard indent of 2, or more, uses tabs for any indents
over 8. Probably even most unix software uses this.
Actually, even if the indent is 8, function arguments are often aligned under
the open parenthesis and a tabs + spaces combination is normally used for
that as well (because, again, that's what most editors will by default do!).
> With space indentation you can make sure that everyone sees the indentation
> as it was intended. With tab indentation, you save space, add semantic
> meaning, and let people control how wide they want their indents to appear.
> This approach seems to take the worst parts of each and combine them.
> What's the benefit?
Tab stops are every 8 characters. No more, no less. Ever. This makes the text
with whatever formating you want the shortest.
> I appreciate I'm not going to convert you - this is an honest question.
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH-resent] gitk: fix in procedure drawcommits
From: Michele Ballabio @ 2007-10-20 16:02 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Shawn O. Pearce, pdmef
In-Reply-To: <18201.54648.707559.480169@cargo.ozlabs.ibm.com>
[Rocco Rutte added on CC:, since he wrote the hg-fast-export scripts]
On Saturday 20 October 2007, Paul Mackerras wrote:
> Well no. I'd rather understand why this is happening, in case the
> error indicates that I'm not handling a corner case correctly. Can
> you make a copy of the repo that triggers the bug available to me?
IIRC, I just cloned mutt's hg repo:
hg clone http://dev.mutt.org/hg/mutt
then imported it in git with the scripts at
http://repo.or.cz/w/fast-export.git
with
hg-fast-export.sh -r ../mutt
After that, I've done the usual maintenance repack.
Then, running gitk and keeping pressed pgdown triggers that
"Error: can't unset..."
window.
Uh-oh. I think I just found the issue. That's probably a bug
somewhere in the import (either fast-export or fast-import or
the original repo, I don't know), so I'm not sure if gitk
should be patched, but since the resulting repo seems correct
as far as git is concerned (i.e. git fsck --full --strict
doesn't complain), I guess something should be done.
Here is the culprit (or so I think). One of the guilty commits is:
commit a3b4383d69e0754346578c85ba8ff7c05bd88705
tree 1bf99cd22abe97c59f8c0b7ad6b8244f0854b8af
parent 6d919fccf603aba995035fa0fb507aa2bd3bf0ae
parent 6d919fccf603aba995035fa0fb507aa2bd3bf0ae
author Brendan Cully <brendan@kublai.com> 1179646159 -0700
committer Brendan Cully <brendan@kublai.com> 1179646159 -0700
Forget SMTP password if authentication fails.
Thanks to Gregory Shapiro for the initial patch (I've moved the reset
from smtp_auth_sasl up to smtp_auth, and used the account API
instead of twiddling account bits by hand). Closes #2872.
This commit (and many others) has two parents, but the two parents
have the same hash. So gitk tries to unset the same variable twice,
hence the error. At this point, the fix for gitk should be either to
check if the parents have the same hash when reading the commit or
avoiding to unset two times the same variable.
This explanation makes sense to me, now the problem is: have I messed
up the import myself, the scripts/commands used are to blame, or is
it entirely the original repo's fault?
Since I've redone the import and the error remains, I guess
that's not my fault :)
^ permalink raw reply
* RE: git push bug?
From: Joakim Tjernlund @ 2007-10-20 17:38 UTC (permalink / raw)
To: spearce, 'Steffen Prohaska'; +Cc: 'git'
In-Reply-To: <20071019002451.GQ14735@spearce.org>
> -----Original Message-----
> From: spearce@spearce.org [mailto:spearce@spearce.org]
> Sent: den 19 oktober 2007 02:25
> To: Steffen Prohaska
> Cc: joakim.tjernlund@transmode.se; git
> Subject: Re: git push bug?
>
> Steffen Prohaska <prohaska@zib.de> wrote:
> > On Oct 18, 2007, at 4:50 PM, Joakim Tjernlund wrote:
> > >
> > ># > git push ssh://devsrv/var/git/os2kernel.git linus:refs/linus
> ...
> > >error: refusing to create funny ref 'refs/linus' locally
> > >ng refs/linus funny refname
> > >error: failed to push to 'ssh://devsrv/var/git/os2kernel.git'
> ...
> > You may need to cleanup though. I'm not sure if the remote side
> > already created 'refs/linus'. The error message only indicates that
> > locally git refused to create the "funny refname".
>
> Cute. The error message "error: refusing to create .. locally"
> is actually coming from the remote site. Locally here is
> actually remotely. We *really* should change that. Its l.169 of
> receive-pack.c, which is only running on the remote side. :)
>
> Anyone game to improve that error message? Should be a pretty
> simple patch. One of the may low-hanging fruits in Git.
Just gave it a try, using git sendmail. Hopefully it will
reach the list :)
^ permalink raw reply
* RE: [PATCH] Fix receive-pack error msg.
From: Joakim Tjernlund @ 2007-10-20 17:44 UTC (permalink / raw)
To: git
In-Reply-To: <1192901822-20431-1-git-send-email-Joakim.Tjernlund@transmode.se>
ehh, git sendmail didn't send the whole commit msg, just the subject.
Trying again.
> -----Original Message-----
> From: Joackim Tjernlund [mailto:jocke@gentoo-jocke]
> Sent: den 20 oktober 2007 19:37
> To: git@vger.kernel.org
> Cc: Joakim Tjernlund
> Subject: [PATCH] Fix receive-pack error msg.
>
>
> Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> ---
> receive-pack.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/receive-pack.c b/receive-pack.c
> index d3c422b..1521d0b 100644
> --- a/receive-pack.c
> +++ b/receive-pack.c
> @@ -166,7 +166,7 @@ static const char *update(struct command *cmd)
> struct ref_lock *lock;
>
> if (!prefixcmp(name, "refs/") && check_ref_format(name + 5)) {
> - error("refusing to create funny ref '%s'
> locally", name);
> + error("refusing to create funny ref '%s'
> remotely", name);
> return "funny refname";
> }
>
> --
> 1.5.3.4
>
>
^ permalink raw reply
* Re: [msysGit] Re: Fourth incarnation of the msysGit herald
From: Steffen Prohaska @ 2007-10-20 18:04 UTC (permalink / raw)
To: Jan Hudec; +Cc: Johannes Schindelin, msysgit, git
In-Reply-To: <20071020133359.GB19521@efreet.light.src>
On Oct 20, 2007, at 3:33 PM, Jan Hudec wrote:
> On Sat, Oct 20, 2007 at 00:25:49 +0100, Johannes Schindelin wrote:
>> git gui
>> =======
>>
>> git gui is a really nice program, and as I often said, I consider it
>> more porcelain than a gui, since it uses the git core directly,
>> instead
>> of wrapping around porcelain commands.
>>
>> The user experience I had with git gui made me think that this should
>> be the primary interface Windows users should be confronted with, not
>> the command line.
>>
>> The major problem we had in msysGit is that git-gui was to be
>> launched
>> from the Start Menu, or a QuickLaunch icon. This is in contrast to
>> the shell, where you usually start git gui in a working directory.
>
> It would be nice to install an entry in the explorer menu to run
> git-gui in
> a selected directory. It can be done by just writing something like
> to the
> registry (completely untested -- I just looked it up on the internet):
What you propose is already there!
Did you try the most recent setup?
http://msysgit.googlecode.com/files/Git-1.5.3-preview20071019.exe
Steffen
^ permalink raw reply
* Re: [msysGit] Re: Fourth incarnation of the msysGit herald
From: Jan Hudec @ 2007-10-20 18:19 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Johannes Schindelin, msysgit, git
In-Reply-To: <A24982F6-40B2-4897-904E-99A135EC9D41@zib.de>
[-- Attachment #1: Type: text/plain, Size: 1484 bytes --]
On Sat, Oct 20, 2007 at 20:04:20 +0200, Steffen Prohaska wrote:
>
> On Oct 20, 2007, at 3:33 PM, Jan Hudec wrote:
>
>> On Sat, Oct 20, 2007 at 00:25:49 +0100, Johannes Schindelin wrote:
>>> git gui
>>> =======
>>>
>>> git gui is a really nice program, and as I often said, I consider it
>>> more porcelain than a gui, since it uses the git core directly, instead
>>> of wrapping around porcelain commands.
>>>
>>> The user experience I had with git gui made me think that this should
>>> be the primary interface Windows users should be confronted with, not
>>> the command line.
>>>
>>> The major problem we had in msysGit is that git-gui was to be launched
>>> from the Start Menu, or a QuickLaunch icon. This is in contrast to
>>> the shell, where you usually start git gui in a working directory.
>>
>> It would be nice to install an entry in the explorer menu to run git-gui
>> in
>> a selected directory. It can be done by just writing something like to the
>> registry (completely untested -- I just looked it up on the internet):
>
> What you propose is already there!
Nice. Thanks. Unfortunately I didn't yet have time to try out, and I didn't
see it mentioned.
> Did you try the most recent setup?
>
> http://msysgit.googlecode.com/files/Git-1.5.3-preview20071019.exe
No; I don't have loosedows here (at home), so I'll have to try it at work
when I have a little time. I certainly will.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 09/14] Use the asyncronous function infrastructure in builtin-fetch-pack.c.
From: Johannes Sixt @ 2007-10-20 18:22 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce
In-Reply-To: <20071020025352.GA6569@spearce.org>
On Saturday 20 October 2007 04:53, Shawn O. Pearce wrote:
> > diff --git a/builtin-fetch-pack.c b/builtin-fetch-pack.c
> > index 871b704..51d8a32 100644
> > --- a/builtin-fetch-pack.c
> > +++ b/builtin-fetch-pack.c
> > @@ -457,42 +457,37 @@ static int everything_local(struct ref **refs, int
> > nr_match, char **match) return retval;
> > }
> >
> > -static pid_t setup_sideband(int fd[2], int xd[2])
> > +static int sideband_demux(int fd, void *data)
> > {
> > - pid_t side_pid;
> > + int *xd = data;
> >
> > + close(xd[1]);
>
> If this is a threaded start_async() system this close is going
> to impact the caller.
Yes, I noticed this, too. I think that a solution calls for a member .in of
struct async analogous to .in of struct child_process.
How do we continue from here? Could you park the series in pu so that I don't
have to resend if it turns out that the fix is just another followup patch
(which is how I'd prefer to solve the issue)? Then I tell you no or go after
I have it tested on mingw.git.
-- Hannes
^ permalink raw reply
* Re: [PATCH-resent] gitk: fix in procedure drawcommits
From: Jan Hudec @ 2007-10-20 18:35 UTC (permalink / raw)
To: Michele Ballabio; +Cc: Paul Mackerras, git, Shawn O. Pearce, pdmef
In-Reply-To: <200710201802.48111.barra_cuda@katamail.com>
[-- Attachment #1: Type: text/plain, Size: 1915 bytes --]
On Sat, Oct 20, 2007 at 18:02:47 +0200, Michele Ballabio wrote:
> IIRC, I just cloned mutt's hg repo:
> hg clone http://dev.mutt.org/hg/mutt
> then imported it in git with the scripts at
> http://repo.or.cz/w/fast-export.git
> with
> hg-fast-export.sh -r ../mutt
> [...]
>
> Here is the culprit (or so I think). One of the guilty commits is:
>
> commit a3b4383d69e0754346578c85ba8ff7c05bd88705
> tree 1bf99cd22abe97c59f8c0b7ad6b8244f0854b8af
> parent 6d919fccf603aba995035fa0fb507aa2bd3bf0ae
> parent 6d919fccf603aba995035fa0fb507aa2bd3bf0ae
> author Brendan Cully <brendan@kublai.com> 1179646159 -0700
> committer Brendan Cully <brendan@kublai.com> 1179646159 -0700
>
> Forget SMTP password if authentication fails.
> Thanks to Gregory Shapiro for the initial patch (I've moved the reset
> from smtp_auth_sasl up to smtp_auth, and used the account API
> instead of twiddling account bits by hand). Closes #2872.
Judging from the symptoms, I would suspect hg-fast-export. Either mercurial
sometimes stores two same hashes instead of the hash and 0 (in which case
hg-fast-import should probably be ready to deal with it), or hg-fast-import
does something wrong when it sees the 0 parent.
> This commit (and many others) has two parents, but the two parents
> have the same hash. So gitk tries to unset the same variable twice,
> hence the error. At this point, the fix for gitk should be either to
> check if the parents have the same hash when reading the commit or
> avoiding to unset two times the same variable.
>
> This explanation makes sense to me, now the problem is: have I messed
> up the import myself, the scripts/commands used are to blame, or is
> it entirely the original repo's fault?
>
> Since I've redone the import and the error remains, I guess
> that's not my fault :)
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Allow gitk to start on Cygwin with native Win32 Tcl/Tk
From: Mark Levedahl @ 2007-10-20 18:47 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Shawn O. Pearce, Junio C Hamano, git
In-Reply-To: <18201.59649.800748.780690@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> Shawn O. Pearce writes:
>
>
>> Yes, I admit this is an odd patch. I can certainly carry it in
>> my own tree (I already carry some other patches) but I wonder if
>> we shouldn't include it as some users may actually try to do this,
>> just like I did. Latest git-gui `master` already has changes to its
>> Makefile and shell startup boilerplate to handle this weird case.
>>
>
> Why do you need to change gitk itself? If you're going to modify it
> with sed, why can't you change the $0 on the 3rd line to the installed
> path of the gitk script?
>
>
While gitk is most likely installed as /usr/bin/gitk in Cygwin's
filespace, that could resolve to anything in the Windows file system. It
might be c:\cygwin\usr\bin\gitk, but could also be "d:\Documents and
Settings\Bill\Programs\cygwin\usr\bin\gitk" depending upon who installed
it and with what options. Both are seen as /usr/bin/gitk by Cygwin.
Thus, Shawn is correct in using cygpath to resolve the name.
Also, as Cygwin's tcl/tk package is bound to the port of the insight
debugger to Cygwin, and that project is stuck for years on 8.4.1, this
patch (or something like it) may be the only way to allow gitk to access
a more recent version on Cygwin in the foreseeable future. So, I think
this is a good idea.
Mark
^ permalink raw reply
* [PATCH] Mention split command in git-add manpage
From: Bram Schoenmakers @ 2007-10-20 19:15 UTC (permalink / raw)
To: git, gitster
Hello,
A little patch for the git-add manpage which mentions the 's' option for
splitting hunks in git-add -i mode.
---
Documentation/git-add.txt | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 2fe7355..032957a 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -210,6 +210,7 @@ patch::
k - do not decide on this hunk now, and view the previous
undecided hunk
K - do not decide on this hunk now, and view the previous hunk
+ s - split large hunks at context lines in the middle
+
After deciding the fate for all hunks, if there is any hunk
that was chosen, the index is updated with the selected hunks.
--
1.5.2.5
Kind regards,
--
Bram Schoenmakers
You can contact me directly on ICQ with #153817629
^ permalink raw reply related
* Re: [PATCH] Deduce exec_path also from calls to git with a relative path
From: Johannes Schindelin @ 2007-10-20 21:31 UTC (permalink / raw)
To: Scott R Parish; +Cc: git, spearce, gitster
In-Reply-To: <1192868006.v2.fusewebmail-240137@f>
Hi,
On Sat, 20 Oct 2007, Scott R Parish wrote:
> Wow, that sure cleaned up nicely! :)
Heh.
BTW I did not mean to discourage you... Rather, I wanted to show you that
this list is a wonderful place to learn, as I did, do, and will do many
times here. (Just to clarify, since somebody said that I am usually not
nice to newbies... cannot understand that at all ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: Announcement of Git wikibook
From: Johannes Schindelin @ 2007-10-20 21:34 UTC (permalink / raw)
To: Ciprian Dorin Craciun; +Cc: Steffen Prohaska, Evan Carroll, git
In-Reply-To: <8e04b5820710200040q76301c58j33e5d0895956b150@mail.gmail.com>
Hi,
[please do not top post]
On Sat, 20 Oct 2007, Ciprian Dorin Craciun wrote:
> There is nothing wrong with either of the two approaches. They
> could both coexist but address different needs:
> -- the manual should be more oriented on technical issues and
> addresses only the most recent versions;
The problem: it is not just "the manual". It is the "user manual".
> -- the book should be more user-oriented, and more general,
> explaining how source management should be addressed by using git, and
> maybe make comparisons with may other versioning systems. Also the
> book could relate to many versions -- both old and new.
>
> Also I would note that the wiki book is more easy to edit... If
> you spot errors or want to add something you just go and edit it and
> the effect is immediate. But in contrast sending patches involves some
> overhead...
I am torn. On one side I like the Wiki approach. On the other hand, the
Wiki will get less review by git oldtimers, whereas the patches to
user-manual are usually reviewed as thoroughly as the code patches.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] On error, do not list all commands, but point to --help option.
From: Jari Aalto @ 2007-10-20 22:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710202126430.25221@racer.site>
* Sat 2007-10-20 Johannes Schindelin <Johannes.Schindelin@gmx.de> INBOX
> Hi,
>
> On Sat, 20 Oct 2007, Jari Aalto wrote:
>
>> - commented out call to list_common_cmds_help()
>
> If you're really sure that this is desired, do not comment it out. Delete
> it.
I'm sure.
There is no point of reminding *every* time you make a typo during
writing the commands. It fills half of the screen and obscures the
previous commands that were running. It's much more polite and elegant
in shorted form.
Jari
New patch follows.
--
Welcome to FOSS revolution: we fix and modify until it shines
^ permalink raw reply
* [PATCH] Fix diffcore-break total breakage
From: Linus Torvalds @ 2007-10-20 19:31 UTC (permalink / raw)
To: Git Mailing List, Junio C Hamano, Shawn O. Pearce
Ok, so on the kernel list, some people noticed that "git log --follow"
doesn't work too well with some files in the x86 merge, because a lot of
files got renamed in very special ways.
In particular, there was a pattern of doing single commits with renames
that looked basically like
- rename "filename.h" -> "filename_64.h"
- create new "filename.c" that includes "filename_32.h" or
"filename_64.h" depending on whether we're 32-bit or 64-bit.
which was preparatory for smushing the two trees together.
Now, there's two issues here:
- "filename.c" *remained*. Yes, it was a rename, but there was a new file
created with the old name in the same commit. This was important,
because we wanted each commit to compile properly, so that it was
bisectable, so splitting the rename into one commit and the "create
helper file" into another was *not* an option.
So we need to break associations where the contents change too much.
Fine. We have the -B flag for that. When we break things up, then the
rename detection will be able to figure out whether there are better
alternatives.
- "git log --follow" didn't with with -B.
Now, the second case was really simple: we use a different "diffopt"
structure for the rename detection than the basic one (which we use for
showing the diffs). So that second case is trivially fixed by a trivial
one-liner that just copies the break_opt values from the "real" diffopts
to the one used for rename following. So now "git log -B --follow" works
fine:
diff --git a/tree-diff.c b/tree-diff.c
index 26bdbdd..7c261fd 100644
--- a/tree-diff.c
+++ b/tree-diff.c
@@ -319,6 +319,7 @@ static void try_to_follow_renames(struct tree_desc *t1, struct tree_desc *t2, co
diff_opts.detect_rename = DIFF_DETECT_RENAME;
diff_opts.output_format = DIFF_FORMAT_NO_OUTPUT;
diff_opts.single_follow = opt->paths[0];
+ diff_opts.break_opt = opt->break_opt;
paths[0] = NULL;
diff_tree_setup_paths(paths, &diff_opts);
if (diff_setup_done(&diff_opts) < 0)
however, the end result does *not* work. Because our diffcore-break.c
logic is totally bogus!
In particular:
- it used to do
if (base_size < MINIMUM_BREAK_SIZE)
return 0; /* we do not break too small filepair */
which basically says "don't bother to break small files". But that
"base_size" is the *smaller* of the two sizes, which means that if some
large file was rewritten into one that just includes another file, we
would look at the (small) result, and decide that it's smaller than the
break size, so it cannot be worth it to break it up! Even if the other
side was ten times bigger and looked *nothing* like the samell file!
That's clearly bogus. I replaced "base_size" with "max_size", so that
we compare the *bigger* of the filepair with the break size.
- It calculated a "merge_score", which was the score needed to merge it
back together if nothing else wanted it. But even if it was *so*
different that we would never want to merge it back, we wouldn't
consider it a break! That makes no sense. So I added
if (*merge_score_p > break_score)
return 1;
to make it clear that if we wouldn't want to merge it at the end, it
was *definitely* a break.
- It compared the whole "extent of damage", counting all inserts and
deletes, but it based this score on the "base_size", and generated the
damage score with
delta_size = src_removed + literal_added;
damage_score = delta_size * MAX_SCORE / base_size;
but that makes no sense either, since quite often, this will result in
a number that is *bigger* than MAX_SCORE! Why? Because base_size is
(again) the smaller of the two files we compare, and when you start out
from a small file and add a lot (or start out from a large file and
remove a lot), the base_size is going to be much smaller than the
damage!
Again, the fix was to replace "base_size" with "max_size", at which
point the damage actually becomes a sane percentage of the whole.
With these changes in place, not only does "git log -B --follow" work for
the case that triggered this in the first place, ie now
git log -B --follow arch/x86/kernel/vmlinux_64.lds.S
actually gives reasonable resulys. But I also wanted to verify it in
general, by doing a full-history
git log --stat -B -C
on my kernel tree with the old code and the new code.
There's some tweaking to be done, but generally, the new code generates
much better results wrt breaking up files (and then finding better rename
candidates). Here's a few examples of the "--stat" output:
- This:
include/asm-x86/Kbuild | 2 -
include/asm-x86/debugreg.h | 79 +++++++++++++++++++++++++++++++++++------
include/asm-x86/debugreg_32.h | 64 ---------------------------------
include/asm-x86/debugreg_64.h | 65 ---------------------------------
4 files changed, 68 insertions(+), 142 deletions(-)
Becomes:
include/asm-x86/Kbuild | 2 -
include/asm-x86/{debugreg_64.h => debugreg.h} | 9 +++-
include/asm-x86/debugreg_32.h | 64 -------------------------
3 files changed, 7 insertions(+), 68 deletions(-)
- This:
include/asm-x86/bug.h | 41 +++++++++++++++++++++++++++++++++++++++--
include/asm-x86/bug_32.h | 37 -------------------------------------
include/asm-x86/bug_64.h | 34 ----------------------------------
3 files changed, 39 insertions(+), 73 deletions(-)
Becomes
include/asm-x86/{bug_64.h => bug.h} | 20 +++++++++++++-----
include/asm-x86/bug_32.h | 37 -----------------------------------
2 files changed, 14 insertions(+), 43 deletions(-)
Now, in some other cases, it does actually turn a rename into a real
"delete+create" pair, and then the diff is usually bigger, so truth in
advertizing: it doesn't always generate a nicer diff. But for what -B was
meant for, I think this is a big improvement, and I suspect those cases
where it generates a bigger diff are tweakable.
So I think this diff fixes a real bug, but we might still want to tweak
the default values and perhaps the exact rules for when a break happens.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
Hmm? At least the "should_break()" tests seem to make some amount of sense
now, I think.
Linus
----
diffcore-break.c | 11 +++++++----
tree-diff.c | 1 +
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/diffcore-break.c b/diffcore-break.c
index ae8a7d0..c71a226 100644
--- a/diffcore-break.c
+++ b/diffcore-break.c
@@ -45,8 +45,8 @@ static int should_break(struct diff_filespec *src,
* The value we return is 1 if we want the pair to be broken,
* or 0 if we do not.
*/
- unsigned long delta_size, base_size, src_copied, literal_added,
- src_removed;
+ unsigned long delta_size, base_size, max_size;
+ unsigned long src_copied, literal_added, src_removed;
*merge_score_p = 0; /* assume no deletion --- "do not break"
* is the default.
@@ -63,7 +63,8 @@ static int should_break(struct diff_filespec *src,
return 0; /* error but caught downstream */
base_size = ((src->size < dst->size) ? src->size : dst->size);
- if (base_size < MINIMUM_BREAK_SIZE)
+ max_size = ((src->size > dst->size) ? src->size : dst->size);
+ if (max_size < MINIMUM_BREAK_SIZE)
return 0; /* we do not break too small filepair */
if (diffcore_count_changes(src, dst,
@@ -89,12 +90,14 @@ static int should_break(struct diff_filespec *src,
* less than the minimum, after rename/copy runs.
*/
*merge_score_p = (int)(src_removed * MAX_SCORE / src->size);
+ if (*merge_score_p > break_score)
+ return 1;
/* Extent of damage, which counts both inserts and
* deletes.
*/
delta_size = src_removed + literal_added;
- if (delta_size * MAX_SCORE / base_size < break_score)
+ if (delta_size * MAX_SCORE / max_size < break_score)
return 0;
/* If you removed a lot without adding new material, that is
diff --git a/tree-diff.c b/tree-diff.c
index 26bdbdd..7c261fd 100644
--- a/tree-diff.c
+++ b/tree-diff.c
@@ -319,6 +319,7 @@ static void try_to_follow_renames(struct tree_desc *t1, struct tree_desc *t2, co
diff_opts.detect_rename = DIFF_DETECT_RENAME;
diff_opts.output_format = DIFF_FORMAT_NO_OUTPUT;
diff_opts.single_follow = opt->paths[0];
+ diff_opts.break_opt = opt->break_opt;
paths[0] = NULL;
diff_tree_setup_paths(paths, &diff_opts);
if (diff_setup_done(&diff_opts) < 0)
^ permalink raw reply related
* Re: [PATCH 09/14] Use the asyncronous function infrastructure in builtin-fetch-pack.c.
From: Shawn O. Pearce @ 2007-10-21 0:29 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <200710202022.33782.johannes.sixt@telecom.at>
Johannes Sixt <johannes.sixt@telecom.at> wrote:
> On Saturday 20 October 2007 04:53, Shawn O. Pearce wrote:
> >
> > If this is a threaded start_async() system this close is going
> > to impact the caller.
>
> Yes, I noticed this, too. I think that a solution calls for a member .in of
> struct async analogous to .in of struct child_process.
Probably.
> How do we continue from here? Could you park the series in pu so that I don't
> have to resend if it turns out that the fix is just another followup patch
> (which is how I'd prefer to solve the issue)? Then I tell you no or go after
> I have it tested on mingw.git.
Yes, this series is already queued for pu. I built the branch last
night but didn't push anything out. I will be doing a push tonight
and this branch will be included in pu.
I think I would also rather receive a follow up patch than a
replacement/resend.
--
Shawn.
^ permalink raw reply
* [PATCH] Fix receive-pack error msg.
From: Joakim Tjernlund @ 2007-10-20 19:31 UTC (permalink / raw)
To: git; +Cc: Joakim Tjernlund
receive-pack is only executed remotely so when
reporting errors, say so.
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
receive-pack.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/receive-pack.c b/receive-pack.c
index d3c422b..1521d0b 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -166,7 +166,7 @@ static const char *update(struct command *cmd)
struct ref_lock *lock;
if (!prefixcmp(name, "refs/") && check_ref_format(name + 5)) {
- error("refusing to create funny ref '%s' locally", name);
+ error("refusing to create funny ref '%s' remotely", name);
return "funny refname";
}
--
1.5.3.4
^ permalink raw reply related
* Re: [PATCH] On error, do not list all commands, but point to --help option.
From: Johannes Schindelin @ 2007-10-20 23:02 UTC (permalink / raw)
To: Jari Aalto; +Cc: git
In-Reply-To: <odetifoh.fsf@blue.sea.net>
Hi,
On Sun, 21 Oct 2007, Jari Aalto wrote:
> * Sat 2007-10-20 Johannes Schindelin <Johannes.Schindelin@gmx.de> INBOX
>
> > On Sat, 20 Oct 2007, Jari Aalto wrote:
> >
> >> - commented out call to list_common_cmds_help()
> >
> > If you're really sure that this is desired, do not comment it out. Delete
> > it.
>
> I'm sure.
Well, I'm almost sure of the opposite. One of the big results of the Git
Survey was that git is still not user-friendly enough. Your patch would
only make this issue worse.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] When exec'ing sub-commands, fall back on execvp (thePATH)
From: Johannes Schindelin @ 2007-10-20 20:25 UTC (permalink / raw)
To: Scott R Parish; +Cc: git
In-Reply-To: <1192867937.v2.fusewebmail-240137@f>
Hi,
[please do not top post. Just delete everything you do not reply to, and
put your answers below the text you are replying to. This spares others
so much time.]
On Sat, 20 Oct 2007, Scott R Parish wrote:
> The theoretical drawback to this approach is that it could possibly
> effect the order in which the paths are tried. For instance, if a user
> did "export GIT_EXEC_PATH=", then the builtin_exec_path wouldn't be
> tried before the PATH. (i doubt that it would be a problem, but thought
> i should note it)
In that respect, my code does not change anything from your code.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] When exec'ing sub-commands, fall back on execvp (thePATH)
From: Scott Parish @ 2007-10-20 20:57 UTC (permalink / raw)
To: Johannes Schindelin, git
In-Reply-To: <1192867937.v2.fusewebmail-240137@f>
Actually, i didn't test it right, execve() were using the files in
my cwd. In addition to you patch, you'd need to use execvp() instead
of execve().
sRp
On Sat, Oct 20, 2007 at 03:12:17AM -0500, Scott R Parish wrote:
> Yeah, that seems to work fine. The theoretical drawback to this approach
> is that it could possibly effect the order in which the paths are tried.
> For instance, if a user did "export GIT_EXEC_PATH=", then the
> builtin_exec_path wouldn't be tried before the PATH. (i doubt that it
> would be a problem, but thought i should note it)
>
> sRp
>
>
> ----- Original Message -----
> Subject: Re: [PATCH] When exec'ing sub-commands, fall back on execvp
> (thePATH)
> Date: Sat, October 20, 2007 0:30
> From: "Johannes Schindelin" <Johannes.Schindelin@gmx.de>
>
> > Hi,
> >
> > On Fri, 19 Oct 2007, Scott Parish wrote:
> >
> > > diff --git a/exec_cmd.c b/exec_cmd.c
> > > index 9b74ed2..674c9f3 100644
> > > --- a/exec_cmd.c
> > > +++ b/exec_cmd.c
> > > @@ -34,15 +34,15 @@ int execv_git_cmd(const char **argv)
> > > {
> > > char git_command[PATH_MAX + 1];
> > > int i;
> > > + int rc;
> > > const char *paths[] = { current_exec_path,
> > > getenv(EXEC_PATH_ENVIRONMENT),
> > > builtin_exec_path };
> > > + const char *tmp;
> > > + size_t len;
> > >
> > > for (i = 0; i < ARRAY_SIZE(paths); ++i) {
> > > - size_t len;
> > > - int rc;
> > > const char *exec_dir = paths[i];
> > > - const char *tmp;
> > >
> > > if (!exec_dir || !*exec_dir) continue;
> > >
> > > @@ -106,8 +106,26 @@ int execv_git_cmd(const char **argv)
> > >
> > > argv[0] = tmp;
> > > }
> > > - return -1;
> > >
> > > + rc = snprintf(git_command, sizeof(git_command), "git-%s",
> argv[0]);
> > > + if (rc < 0 || rc >= sizeof(git_command) - len) {
> > > + fprintf(stderr, "git: command name given is too
> long.\n");
> > > + return -1;
> > > + }
> > > +
> > > + tmp = argv[0];
> > > + argv[0] = git_command;
> > > +
> > > + trace_argv_printf(argv, -1, "trace: exec:");
> > > +
> > > + /* execve() can only ever return if it fails */
> > > + execvp(git_command, (char **)argv);
> > > +
> > > + trace_printf("trace: exec failed: %s\n", strerror(errno));
> > > +
> > > + argv[0] = tmp;
> > > +
> > > + return -1;
> > > }
> >
> > I am not sure that this is elegant enough: Something like this (completely
> > untested) might be better:
> >
> > diff --git a/exec_cmd.c b/exec_cmd.c
> > index 9b74ed2..c928f37 100644
> > --- a/exec_cmd.c
> > +++ b/exec_cmd.c
> > @@ -36,7 +36,8 @@ int execv_git_cmd(const char **argv)
> > int i;
> > const char *paths[] = { current_exec_path,
> > getenv(EXEC_PATH_ENVIRONMENT),
> > - builtin_exec_path };
> > + builtin_exec_path,
> > + "" };
> >
> > for (i = 0; i < ARRAY_SIZE(paths); ++i) {
> > size_t len;
> > @@ -44,9 +45,12 @@ int execv_git_cmd(const char **argv)
> > const char *exec_dir = paths[i];
> > const char *tmp;
> >
> > - if (!exec_dir || !*exec_dir) continue;
> > + if (!exec_dir) continue;
> >
> > - if (*exec_dir != '/') {
> > + if (!*exec_dir)
> > + /* try PATH */
> > + *git_command = '\0';
> > + else if (*exec_dir != '/') {
> > if (!getcwd(git_command, sizeof(git_command))) {
> > fprintf(stderr, "git: cannot determine "
> > "current directory: %s\n",
> > @@ -81,7 +85,7 @@ int execv_git_cmd(const char **argv)
> >
> > len = strlen(git_command);
> > rc = snprintf(git_command + len, sizeof(git_command) -
> len,
> > - "/git-%s", argv[0]);
> > + "%sgit-%s", *exec_dir ? "/" : "", argv[0]);
> > if (rc < 0 || rc >= sizeof(git_command) - len) {
> > fprintf(stderr,
> > "git: command name given is too long.\n");
> >
> > Ciao,
> > Dscho
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe git" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
> >
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Scott Parish
http://srparish.net/
^ permalink raw reply
* Re: [PATCH] Deduce exec_path also from calls to git with a relative path
From: Scott Parish @ 2007-10-20 23:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, spearce, gitster
In-Reply-To: <Pine.LNX.4.64.0710202225520.25221@racer.site>
On Sat, Oct 20, 2007 at 10:31:47PM +0100, Johannes Schindelin wrote:
> BTW I did not mean to discourage you... Rather, I wanted to show you that
> this list is a wonderful place to learn, as I did, do, and will do many
> times here. (Just to clarify, since somebody said that I am usually not
> nice to newbies... cannot understand that at all ;-)
Nah, i'm actually rather encouraged that people have shown interest
in my patches and are so quick to find ways to improve on them!
Sorry about the top posting earlier; i've been away from active
open source participation for a while and have been forgetting my
etiquette.
sRp
--
Scott Parish
http://srparish.net/
^ permalink raw reply
* Re: [PATCH] On error, do not list all commands, but point to --help option.
From: Johannes Schindelin @ 2007-10-20 20:28 UTC (permalink / raw)
To: Jari Aalto; +Cc: git
In-Reply-To: <bqaujirk.fsf@blue.sea.net>
Hi,
On Sat, 20 Oct 2007, Jari Aalto wrote:
> - commented out call to list_common_cmds_help()
If you're really sure that this is desired, do not comment it out. Delete
it.
But am not at all sure that this is the way to go. Rather, I like it that
the most common commands are listed. It would be better to find out what
commands are really the most helpful to users who are likely to benefit
from the list, and to present them better (such as showing them in
categories).
Ciao,
Dscho
^ permalink raw reply
* [PATCH] execv_git_cmd(): also try PATH if everything else fails.
From: Johannes Schindelin @ 2007-10-20 22:00 UTC (permalink / raw)
To: Scott Parish; +Cc: git
In-Reply-To: <20071020205721.GA16291@srparish.net>
Earlier, we tried to find the git commands in several possible exec
dirs. Now, if all of these failed, try to find the git command in
PATH.
This allows you to install the git programs somewhere else than
originally specified when building git, as long as you add that location
to the PATH.
Initial implementation by Scott R Parish.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Sat, 20 Oct 2007, Scott Parish wrote:
> Actually, i didn't test it right, execve() were using the files
> in my cwd. In addition to you patch, you'd need to use execvp()
> instead of execve().
Ah, right. I missed that one ;-)
How about this instead?
exec_cmd.c | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/exec_cmd.c b/exec_cmd.c
index 9b74ed2..c928f37 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -36,7 +36,8 @@ int execv_git_cmd(const char **argv)
int i;
const char *paths[] = { current_exec_path,
getenv(EXEC_PATH_ENVIRONMENT),
- builtin_exec_path };
+ builtin_exec_path,
+ "" };
for (i = 0; i < ARRAY_SIZE(paths); ++i) {
size_t len;
@@ -44,9 +45,12 @@ int execv_git_cmd(const char **argv)
const char *exec_dir = paths[i];
const char *tmp;
- if (!exec_dir || !*exec_dir) continue;
+ if (!exec_dir) continue;
- if (*exec_dir != '/') {
+ if (!*exec_dir)
+ /* try PATH */
+ *git_command = '\0';
+ else if (*exec_dir != '/') {
if (!getcwd(git_command, sizeof(git_command))) {
fprintf(stderr, "git: cannot determine "
"current directory: %s\n",
@@ -81,7 +85,7 @@ int execv_git_cmd(const char **argv)
len = strlen(git_command);
rc = snprintf(git_command + len, sizeof(git_command) - len,
- "/git-%s", argv[0]);
+ "%sgit-%s", *exec_dir ? "/" : "", argv[0]);
if (rc < 0 || rc >= sizeof(git_command) - len) {
fprintf(stderr,
"git: command name given is too long.\n");
--
1.5.3.4.1287.g8b31e
^ 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