* Re: git --version
From: Paolo Ciarrocchi @ 2006-05-31 19:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <4d8e3fd30605311249l6ba4ff74l72778ffe60462263@mail.gmail.com>
On 5/31/06, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
[...]
> And even more intersting:
> make clean && make && sudo make install
> git --version
> git version 1.3.GIT
>
> make install
> [...]
> mv git-cherry-pick+ git-cherry-pick
> mv: sovrascrivo `git-cherry-pick' ignorando il modo 0755?
> that in english is something like:
> mv: overwrite `git-cherry-pick' ignoring mod 0755?
>
> Wow...of course, make clean && make install fix everything
>
Thanks to loops on #git for asking me to do the following test:
<PaoloC> paolo@Italia:~/git$ sudo ./GIT-VERSION-GEN
<PaoloC> GIT_VERSION = 1.3.GIT
<PaoloC> paolo@Italia:~/git$ ./GIT-VERSION-GEN
<PaoloC> GIT_VERSION = 1.3.3.g2186
I don't know why it's happening...
--
Paolo
http://paolociarrocchi.googlepages.com
^ permalink raw reply
* Re: git --version
From: Paolo Ciarrocchi @ 2006-05-31 19:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <4d8e3fd30605311243q5a93a7a9l827c55827817602f@mail.gmail.com>
On 5/31/06, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
> On 5/31/06, Linus Torvalds <torvalds@osdl.org> wrote:
> > On Wed, 31 May 2006, Paolo Ciarrocchi wrote:
> > > >
> > > > git describe
> > >
> > > paolo@Italia:~/git$ git describe
> > > v1.3.3-g2186d56
> >
> > Ok.
> >
> > > > ./git --version
> > >
> > > paolo@Italia:~/git$ ./git --version
> > > git version 1.3.3.g2186
> > >
> > > Doh..
> >
> > Ok, that's also good.
> >
> > > > which git
> > >
> > > paolo@Italia:~/git$ which git
> > > /home/paolo/bin/git
> >
> > I think I know what's up.
> >
> > Your "sudo" made "$HOME" be /root. So by doing "sudo make install", you
> > installed the git in _roots_ ~/bin, ie /root/bin/.
> >
>
> Doh... not sure to follow you, just did:
> sudo make install
> paolo@Italia:~/git$ ls /root/
> paolo@Italia:~/git$ git --version
> git version 1.3.GIT
And even more intersting:
make clean && make && sudo make install
git --version
git version 1.3.GIT
make install
[...]
mv git-cherry-pick+ git-cherry-pick
mv: sovrascrivo `git-cherry-pick' ignorando il modo 0755?
that in english is something like:
mv: overwrite `git-cherry-pick' ignoring mod 0755?
Wow...of course, make clean && make install fix everything
Ciao,
--
Paolo
http://paolociarrocchi.googlepages.com
^ permalink raw reply
* Re: format-patch signoff argument no longer works
From: Seth Falcon @ 2006-05-31 19:43 UTC (permalink / raw)
To: git
In-Reply-To: <7vejyayq46.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Seth Falcon <sethfalcon@gmail.com> writes:
>> When should one commit _without_ signoff?
>
> Please, calm down and read Documentation/SubmittingPatches,
> item (6), to understand what sign-off means. It does not have
> anything to do with the result of the commit "working". I do
> not use -s when making commits during my day-job, for example.
Doh! In glancing through the Documentation dir I missed the
SubmittingPatches file. [weak excuse: there are many doc files in that
dir and most are for the commands themselves. I expected this to be
in howto/.]
Anyhow, much calmer now (apologies if I sounded un-calm, that wasn't
my intention). The SubmittingPatches doc was _exactly_ what I was
looking for when I posted my original question [*]. My bad for not
finding it when it was staring me in the face. Thanks for bearing
with me and pointing me to the fine manual :-)
[*] http://marc.theaimsgroup.com/?l=git&m=114884854119660&w=2
^ permalink raw reply
* Re: git --version
From: Paolo Ciarrocchi @ 2006-05-31 19:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0605311233030.24646@g5.osdl.org>
On 5/31/06, Linus Torvalds <torvalds@osdl.org> wrote:
> On Wed, 31 May 2006, Paolo Ciarrocchi wrote:
> > >
> > > git describe
> >
> > paolo@Italia:~/git$ git describe
> > v1.3.3-g2186d56
>
> Ok.
>
> > > ./git --version
> >
> > paolo@Italia:~/git$ ./git --version
> > git version 1.3.3.g2186
> >
> > Doh..
>
> Ok, that's also good.
>
> > > which git
> >
> > paolo@Italia:~/git$ which git
> > /home/paolo/bin/git
>
> I think I know what's up.
>
> Your "sudo" made "$HOME" be /root. So by doing "sudo make install", you
> installed the git in _roots_ ~/bin, ie /root/bin/.
>
Doh... not sure to follow you, just did:
sudo make install
paolo@Italia:~/git$ ls /root/
paolo@Italia:~/git$ git --version
git version 1.3.GIT
--
Paolo
http://paolociarrocchi.googlepages.com
^ permalink raw reply
* Re: git --version
From: Linus Torvalds @ 2006-05-31 19:35 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: Junio C Hamano, git
In-Reply-To: <4d8e3fd30605311230h53981e57x8a417b176bedba86@mail.gmail.com>
On Wed, 31 May 2006, Paolo Ciarrocchi wrote:
> >
> > git describe
>
> paolo@Italia:~/git$ git describe
> v1.3.3-g2186d56
Ok.
> > ./git --version
>
> paolo@Italia:~/git$ ./git --version
> git version 1.3.3.g2186
>
> Doh..
Ok, that's also good.
> > which git
>
> paolo@Italia:~/git$ which git
> /home/paolo/bin/git
I think I know what's up.
Your "sudo" made "$HOME" be /root. So by doing "sudo make install", you
installed the git in _roots_ ~/bin, ie /root/bin/.
Linus
^ permalink raw reply
* Re: git --version
From: Paolo Ciarrocchi @ 2006-05-31 19:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <4d8e3fd30605311230h53981e57x8a417b176bedba86@mail.gmail.com>
On 5/31/06, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
> On 5/31/06, Linus Torvalds <torvalds@osdl.org> wrote:
> >
> >
> > On Wed, 31 May 2006, Paolo Ciarrocchi wrote:
> > >
> > > Tried with:
> > > make clean
> > > make && sudo make install
> > > [...]
> > > paolo@Italia:~/git$ git --version
> > > git version 1.3.GIT
> > > paolo@Italia:~/git$ ./GIT-VERSION-GEN
> > > GIT_VERSION = 1.3.3.g2186
> >
> > What does
> >
> > git describe
>
> paolo@Italia:~/git$ git describe
> v1.3.3-g2186d56
>
> > ./git --version
>
> paolo@Italia:~/git$ ./git --version
> git version 1.3.3.g2186
>
> Doh..
>
> > which git
>
> paolo@Italia:~/git$ which git
> /home/paolo/bin/git
>
Ok...
make && make install
Now I get:
paolo@Italia:~$ git --version
git version 1.3.3.g2186
That is correct.
But I'm still wondering why doing sudo make install caused that
problem, git was correcly installed in /home/paolo/git
Really puzzled.
Ciao,
--
Paolo
http://paolociarrocchi.googlepages.com
^ permalink raw reply
* Re: git --version
From: Paolo Ciarrocchi @ 2006-05-31 19:30 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0605311224360.24646@g5.osdl.org>
On 5/31/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> On Wed, 31 May 2006, Paolo Ciarrocchi wrote:
> >
> > Tried with:
> > make clean
> > make && sudo make install
> > [...]
> > paolo@Italia:~/git$ git --version
> > git version 1.3.GIT
> > paolo@Italia:~/git$ ./GIT-VERSION-GEN
> > GIT_VERSION = 1.3.3.g2186
>
> What does
>
> git describe
paolo@Italia:~/git$ git describe
v1.3.3-g2186d56
> ./git --version
paolo@Italia:~/git$ ./git --version
git version 1.3.3.g2186
Doh..
> which git
paolo@Italia:~/git$ which git
/home/paolo/bin/git
Ciao,
--
Paolo
http://paolociarrocchi.googlepages.com
^ permalink raw reply
* Re: git --version
From: Paolo Ciarrocchi @ 2006-05-31 19:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0605311222010.24646@g5.osdl.org>
On 5/31/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> On Wed, 31 May 2006, Paolo Ciarrocchi wrote:
> > [...]
> > install git gitk '/home/paolo/bin'
>
> Why are you doing a "sudo" when you install in your own ~/bin (the default
> for git).
Good question :-)
Just because I'm used to do that but you are absolutelly right saying
that is wrong.
> The whole point of installing in ~/bin is to not need any elevated
> priorities.
>
> I get the feeling that you might have installed something in /usr/bin/ or
> /usr/local/bin earlier, and that they are before ~/bin in your PATH.
I don't think so since:
paolo@Italia:~/git$ which git
/home/paolo/bin/git
But I'll do a make && make install in a minute.
Thanks!
Ciao,
--
Paolo
http://paolociarrocchi.googlepages.com
^ permalink raw reply
* Re: git --version
From: Linus Torvalds @ 2006-05-31 19:25 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: Junio C Hamano, git
In-Reply-To: <4d8e3fd30605311220t17d319efyd5234dd4eb74fc96@mail.gmail.com>
On Wed, 31 May 2006, Paolo Ciarrocchi wrote:
>
> Tried with:
> make clean
> make && sudo make install
> [...]
> paolo@Italia:~/git$ git --version
> git version 1.3.GIT
> paolo@Italia:~/git$ ./GIT-VERSION-GEN
> GIT_VERSION = 1.3.3.g2186
What does
git describe
./git --version
which git
say?
Linus
^ permalink raw reply
* Re: git --version
From: Linus Torvalds @ 2006-05-31 19:23 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: Junio C Hamano, git
In-Reply-To: <4d8e3fd30605311213m6f2f2660u90701ad6bd5daabc@mail.gmail.com>
On Wed, 31 May 2006, Paolo Ciarrocchi wrote:
> [...]
> install git gitk '/home/paolo/bin'
Why are you doing a "sudo" when you install in your own ~/bin (the default
for git).
The whole point of installing in ~/bin is to not need any elevated
priorities.
I get the feeling that you might have installed something in /usr/bin/ or
/usr/local/bin earlier, and that they are before ~/bin in your PATH.
Linus
^ permalink raw reply
* Re: git --version
From: Paolo Ciarrocchi @ 2006-05-31 19:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <4d8e3fd30605311213m6f2f2660u90701ad6bd5daabc@mail.gmail.com>
On 5/31/06, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
> So yes, it's correctly installed (I pull, compile and install almost
> daily always without any problem).
>
Tried with:
make clean
make && sudo make install
[...]
paolo@Italia:~/git$ git --version
git version 1.3.GIT
paolo@Italia:~/git$ ./GIT-VERSION-GEN
GIT_VERSION = 1.3.3.g2186
Puzzled.
--
Paolo
http://paolociarrocchi.googlepages.com
^ permalink raw reply
* Re: format-patch signoff argument no longer works
From: J. Bruce Fields @ 2006-05-31 19:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Seth Falcon
In-Reply-To: <7vejyayq46.fsf@assigned-by-dhcp.cox.net>
On Wed, May 31, 2006 at 12:02:33PM -0700, Junio C Hamano wrote:
> Now, we could do that by re-adding "format-patch -s" option, or
> alternatively we could add that to "send-email". We might want
> to do both ;-)
Personally, just to give myself the best change of catching problems
with the outgoing email, I'd prefer to have as much as possible be done
*before* send-email, so whatever I review is as close to what's sent out
as possible.
--b.
^ permalink raw reply
* Re: git --version
From: Paolo Ciarrocchi @ 2006-05-31 19:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vac8yypxc.fsf@assigned-by-dhcp.cox.net>
On 5/31/06, Junio C Hamano <junkio@cox.net> wrote:
> "Paolo Ciarrocchi" <paolo.ciarrocchi@gmail.com> writes:
>
> > paolo@Italia:~$ cd git/
> > paolo@Italia:~/git$ git --version
> > git version 1.3.GIT
> > paolo@Italia:~/git$ make >/dev/null
> > paolo@Italia:~/git$ sudo make install >/dev/null
> > Password:
> > GIT_VERSION = 1.3.GIT
>
> Unfortunate is we cannot see what this "sudo" did -- does it
> successfully run (installed) git to check the "full" version and
> manage to store it in ./GIT-VERSION-FILE?
Just the few last lines:
install git-checkout-index git-clone-pack git-convert-objects
git-fetch-pack git-fsck-objects git-hash-object git-index-pack
git-local-fetch git-mailinfo git-merge-base git-merge-index git-mktag
git-mktree git-pack-objects git-patch-id git-peek-remote
git-prune-packed git-receive-pack git-rev-parse git-send-pack
git-shell git-show-index git-ssh-fetch git-ssh-upload git-unpack-file
git-unpack-objects git-update-index git-update-server-info
git-upload-pack git-verify-pack git-write-tree git-update-ref
git-symbolic-ref git-name-rev git-pack-redundant git-repo-config
git-var git-describe git-merge-tree git-blame git-imap-send
git-ssh-pull git-ssh-push git-http-fetch git-http-push
git-get-tar-commit-id git-mailsplit git-stripspace git-daemon
git-bisect git-branch git-checkout git-cherry git-clean git-clone
git-commit git-fetch git-ls-remote git-merge-one-file git-parse-remote
git-prune git-pull git-rebase git-repack git-request-pull git-reset
git-resolve git-revert git-sh-setup git-tag git-verify-tag
git-applymbox git-applypatch git-am git-merge git-merge-stupid
git-merge-octopus git-merge-resolve git-merge-ours git-lost-found
git-quiltimport git-archimport git-cvsimport git-relink git-shortlog
git-fmt-merge-msg git-rerere git-annotate git-cvsserver git-svnimport
git-mv git-cvsexportcommit git-send-email git-merge-recursive
git-cherry-pick git-status '/home/paolo/bin'
install git gitk '/home/paolo/bin'
make -C templates install
make[1]: Entering directory `/home/paolo/git/templates'
: no custom templates yet
install -d -m755 '/home/paolo/share/git-core/templates/'
(cd blt && tar cf - .) | \
(cd '/home/paolo/share/git-core/templates/' && tar xf -)
make[1]: Leaving directory `/home/paolo/git/templates'
install -d -m755 '/home/paolo/share/git-core/python'
install gitMergeCommon.py '/home/paolo/share/git-core/python'
if test 'z/home/paolo/bin' != 'z/home/paolo/bin'; \
then \
ln -f '/home/paolo/bin/git' \
'/home/paolo/bin/git' || \
cp '/home/paolo/bin/git' \
'/home/paolo/bin/git'; \
fi
rm -f '/home/paolo/bin/git-log' && ln '/home/paolo/bin/git'
'/home/paolo/bin/git-log' ; rm -f '/home/paolo/bin/git-whatchanged'
&& ln '/home/paolo/bin/git' '/home/paolo/bin/git-whatchanged' ; rm -f
'/home/paolo/bin/git-show' && ln '/home/paolo/bin/git'
'/home/paolo/bin/git-show' ; rm -f
'/home/paolo/bin/git-count-objects' && ln '/home/paolo/bin/git'
'/home/paolo/bin/git-count-objects' ; rm -f
'/home/paolo/bin/git-diff' && ln '/home/paolo/bin/git'
'/home/paolo/bin/git-diff' ; rm -f '/home/paolo/bin/git-push' && ln
'/home/paolo/bin/git' '/home/paolo/bin/git-push' ; rm -f
'/home/paolo/bin/git-grep' && ln '/home/paolo/bin/git'
'/home/paolo/bin/git-grep' ; rm -f '/home/paolo/bin/git-add' && ln
'/home/paolo/bin/git' '/home/paolo/bin/git-add' ; rm -f
'/home/paolo/bin/git-rm' && ln '/home/paolo/bin/git'
'/home/paolo/bin/git-rm' ; rm -f '/home/paolo/bin/git-rev-list' && ln
'/home/paolo/bin/git' '/home/paolo/bin/git-rev-list' ; rm -f
'/home/paolo/bin/git-check-ref-format' && ln '/home/paolo/bin/git'
'/home/paolo/bin/git-check-ref-format' ; rm -f
'/home/paolo/bin/git-init-db' && ln '/home/paolo/bin/git'
'/home/paolo/bin/git-init-db' ; rm -f '/home/paolo/bin/git-tar-tree'
&& ln '/home/paolo/bin/git' '/home/paolo/bin/git-tar-tree' ; rm -f
'/home/paolo/bin/git-upload-tar' && ln '/home/paolo/bin/git'
'/home/paolo/bin/git-upload-tar' ; rm -f
'/home/paolo/bin/git-format-patch' && ln '/home/paolo/bin/git'
'/home/paolo/bin/git-format-patch' ; rm -f
'/home/paolo/bin/git-ls-files' && ln '/home/paolo/bin/git'
'/home/paolo/bin/git-ls-files' ; rm -f '/home/paolo/bin/git-ls-tree'
&& ln '/home/paolo/bin/git' '/home/paolo/bin/git-ls-tree' ; rm -f
'/home/paolo/bin/git-read-tree' && ln '/home/paolo/bin/git'
'/home/paolo/bin/git-read-tree' ; rm -f
'/home/paolo/bin/git-commit-tree' && ln '/home/paolo/bin/git'
'/home/paolo/bin/git-commit-tree' ; rm -f '/home/paolo/bin/git-apply'
&& ln '/home/paolo/bin/git' '/home/paolo/bin/git-apply' ; rm -f
'/home/paolo/bin/git-show-branch' && ln '/home/paolo/bin/git'
'/home/paolo/bin/git-show-branch' ; rm -f
'/home/paolo/bin/git-diff-files' && ln '/home/paolo/bin/git'
'/home/paolo/bin/git-diff-files' ; rm -f
'/home/paolo/bin/git-diff-index' && ln '/home/paolo/bin/git'
'/home/paolo/bin/git-diff-index' ; rm -f
'/home/paolo/bin/git-diff-stages' && ln '/home/paolo/bin/git'
'/home/paolo/bin/git-diff-stages' ; rm -f
'/home/paolo/bin/git-diff-tree' && ln '/home/paolo/bin/git'
'/home/paolo/bin/git-diff-tree' ; rm -f
'/home/paolo/bin/git-cat-file' && ln '/home/paolo/bin/git'
'/home/paolo/bin/git-cat-file' ;
paolo@Italia:~/git$ git --version
So yes, it's correctly installed (I pull, compile and install almost
daily always without any problem).
Ciao and thanks!
--
Paolo
http://paolociarrocchi.googlepages.com
^ permalink raw reply
* Re: git --version
From: Junio C Hamano @ 2006-05-31 19:06 UTC (permalink / raw)
To: git
In-Reply-To: <4d8e3fd30605311158n9d669dgd6c392ee8d194b78@mail.gmail.com>
"Paolo Ciarrocchi" <paolo.ciarrocchi@gmail.com> writes:
> paolo@Italia:~$ cd git/
> paolo@Italia:~/git$ git --version
> git version 1.3.GIT
> paolo@Italia:~/git$ make >/dev/null
> paolo@Italia:~/git$ sudo make install >/dev/null
> Password:
> GIT_VERSION = 1.3.GIT
Unfortunate is we cannot see what this "sudo" did -- does it
successfully run (installed) git to check the "full" version and
manage to store it in ./GIT-VERSION-FILE?
^ permalink raw reply
* Re: format-patch signoff argument no longer works
From: Junio C Hamano @ 2006-05-31 19:02 UTC (permalink / raw)
To: git; +Cc: Seth Falcon
In-Reply-To: <m2mzcycn4f.fsf@ziti.fhcrc.org>
Seth Falcon <sethfalcon@gmail.com> writes:
> Matthias Kestenholz <lists@spinlock.ch> writes:
>
>> * Geoff Russell (geoffrey.russell@gmail.com) wrote:
>>> It appears to have got lost when the shell script got converted to C.
>>>
>> Yes, this was intentional. You should sign off your changes while
>> committing (git commit -s|--signoff)
A bit on this later, but first to clear one thing up...
> When should one commit _without_ signoff?
>
> The obvious answer is: when one doesn't approve of the changes in the
> commit... But in my usual workflow, commit means
> works-for-me-I-think-it-is-good. :-)
Please, calm down and read Documentation/SubmittingPatches,
item (6), to understand what sign-off means. It does not have
anything to do with the result of the commit "working". I do
not use -s when making commits during my day-job, for example.
We do not want to make sign-off the default. It has to be a
concious act on the signer's part to add one. Otherwise it
would not carry much weight.
About the droppage of "format-patch -s", I have come to think of
it as a mistake (yes, I can change my mind). Consider:
* You are the leader of a group of people who hack on a part of
the kernel, internally in your company. You and other
developers make improvements and make commits, with "git
commit -s".
* As the in-company integrator, you maintain the canonical
"company tree" by pulling from others in your group.
* It's time to send good pieces to Linus and/or Andrew and as
the group lead you are responsible for sending them out. The
commits would have Sign-off's by the original committers, but
as the contact person (representative) of your group, your
name is better recognizable in the outside community, and as
the leader of your group, it is a good practice for _you_ to
vouch for what your group did.
In that scenario, in addition to what "commit -s" gives us, it
is handy for the person who is sending the patches out via
e-mail to add his own sign-off.
Now, we could do that by re-adding "format-patch -s" option, or
alternatively we could add that to "send-email". We might want
to do both ;-)
^ permalink raw reply
* Re: git --version
From: Paolo Ciarrocchi @ 2006-05-31 18:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu077ywmw.fsf@assigned-by-dhcp.cox.net>
On 5/31/06, Junio C Hamano <junkio@cox.net> wrote:
> "Paolo Ciarrocchi" <paolo.ciarrocchi@gmail.com> writes:
>
> > I'm confused by the following:
> > paolo@Italia:~/git$ ./GIT-VERSION-GEN
> > GIT_VERSION = 1.3.3.g2186
> >
> > paolo@Italia:~/git$ git --version
> > git version 1.3.GIT
> >
> > Why git --version is not reporting the "full" version number?
>
> There is a bit of chicken and egg problem involved. The build
> procedure wants to have an already installed git to figure out
> the "full" version number. If you are bootstrapping, make clean
> and rebuild after you install git once would give you a git
> binary that knows what version it is.
Either I didn't understand your answer or something is wrong with my
git installation:
paolo@Italia:~$ cd git/
paolo@Italia:~/git$ git --version
git version 1.3.GIT
paolo@Italia:~/git$ make >/dev/null
paolo@Italia:~/git$ sudo make install >/dev/null
Password:
GIT_VERSION = 1.3.GIT
paolo@Italia:~/git$ git --version
git version 1.3.GIT
paolo@Italia:~/git$
--
Paolo
http://paolociarrocchi.googlepages.com
^ permalink raw reply
* Re: [PATCH] Update documentation for git-format-patch
From: Dennis Stosberg @ 2006-05-31 17:24 UTC (permalink / raw)
To: git
In-Reply-To: <e5kcfi$124$1@sea.gmane.org>
Jakub Narebski wrote:
> Dennis Stosberg wrote:
>
> > - Display suspicious lines in the patch. The definition
> > - of 'suspicious lines' is currently the lines that has
> > - trailing whitespaces, and the lines whose indentation
> > - has a SP character immediately followed by a TAB
> > - character.
>
> So is this option also lost in built-in git-format-patch?
Johannes Schindelin made that one a diff option, so it can be used in
other ways, too. I think it should be documented in diff-options.txt.
> > -CONFIGURATION
> > -You can specify extra mail header lines to be added to each
> > -message in the repository configuration as follows:
> > -
> > -[format]
> > - headers = "Organization: git-foo\n"
>
> So is this configuration option also lost in built-in git-format-patch?
Grep'ing the sources, I couldn't find any trace of it.
Regards,
Dennis
^ permalink raw reply
* No tags when cloing the Linux history tree
From: Marcel Holtmann @ 2006-05-31 17:23 UTC (permalink / raw)
To: git; +Cc: Thomas Gleixner
Hi guys,
when cloning the Linux history tree from Thomas Gleixner over HTTP or
GIT transports using cg-clone (instead of git-clone), I don't get the
tags. I checked on master.kernel.org and all tags are present there.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Remove possible segfault in http-fetch.
From: Nick Hengeveld @ 2006-05-31 16:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sean, git
In-Reply-To: <7vverzzukg.fsf@assigned-by-dhcp.cox.net>
On Sun, May 21, 2006 at 12:49:19AM -0700, Junio C Hamano wrote:
> curl_easy_cleanup() which is called from http_cleanup() says it
> is safe to remove the strings _after_ you call that function, so
> I think the change makes sense -- it was apparently unsafe to
> free them before calling cleanup.
>
> Knowing nothing about quirks in curl libraries, one thing that
> is mystery to me is that we slist_append() to other two lists
> (pragma_header and range_header) but we do not seem to ever free
> them. Another slist dav_headers is allocated and then freed
> inside a function, so that call-pattern seems well-formed.
>
> Nick, care to help us out?
I just got back from a trip to the midwest and am still getting caught
up. I was only gone for 10 days, you've all been quite busy...
You're correct wrt the other slists, I'll get to work on a patch for
that after I've caught up.
I'm also doing additional testing to see whether this fixes the DAV/405
segfault as I think there may be something else going on there.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: [PATCH] Update documentation for git-format-patch
From: Jakub Narebski @ 2006-05-31 15:24 UTC (permalink / raw)
To: git
In-Reply-To: <20060531141408.G366d89c7@leonov.stosberg.net>
Dennis Stosberg wrote:
> --c|--check::
> - Display suspicious lines in the patch. The definition
> - of 'suspicious lines' is currently the lines that has
> - trailing whitespaces, and the lines whose indentation
> - has a SP character immediately followed by a TAB
> - character.
So is this option also lost in built-in git-format-patch?
> -CONFIGURATION
> --------------
> -You can specify extra mail header lines to be added to each
> -message in the repository configuration as follows:
> -
> -[format]
> - headers = "Organization: git-foo\n"
So is this configuration option also lost in built-in git-format-patch?
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [RFC] git commit --branch
From: Martin Waitz @ 2006-05-31 15:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5dvyvkq.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 790 bytes --]
hoi :)
On Tue, May 30, 2006 at 03:52:21PM -0700, Junio C Hamano wrote:
> you can switch to another existing topic branch do with "git
> checkout", perhaps with the -m flag. While I was on the "master" to
> figure out why gitweb was not behaving for me, and figured out a mis-
> configuration that should be fixed in "newconf" topic, I switched to
> that topic and committed the fix there, after testing the change
> there. Then either merging it back to "master" or rebuilding "master"
> from scratch based on "origin" and merging my topics got me a working
> gitweb back.
So perhaps my real problem was that I did not know about checkout -m.
Your description of the workflow is of course much saver then
automatically committing to an other branch.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Update documentation for git-format-patch
From: Johannes Schindelin @ 2006-05-31 15:00 UTC (permalink / raw)
To: Dennis Stosberg; +Cc: Matthias Kestenholz, geoff, git
In-Reply-To: <20060531141408.G366d89c7@leonov.stosberg.net>
Hi,
On Wed, 31 May 2006, Dennis Stosberg wrote:
> Is there any "patch" program at all that understands git's rename
> patches?
Why, yes: git-apply!
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Update documentation for git-format-patch
From: Dennis Stosberg @ 2006-05-31 14:14 UTC (permalink / raw)
To: Matthias Kestenholz; +Cc: geoff, git
In-Reply-To: <20060531112803.GB3877@spinlock.ch>
Signed-off-by: Dennis Stosberg <dennis@stosberg.net>
---
This updates the documentation for git-format-patch to reflect the
changes that the built-in version brought.
In addition to the functional changes, I reworded a few expressions
which sounded suspicious or unclear to me. However, I'm not a
native English speaker, so corrections are welcome.
Is there any "patch" program at all that understands git's rename
patches?
Regards,
Dennis
Documentation/git-format-patch.txt | 82 +++++++++++++++---------------------
1 files changed, 35 insertions(+), 47 deletions(-)
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index 7cc7faf..64d3f1e 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -9,70 +9,58 @@ git-format-patch - Prepare patches for e
SYNOPSIS
--------
[verse]
-'git-format-patch' [-n | -k] [-o <dir> | --stdout] [--attach] [-s] [-c]
- [--diff-options] <his> [<mine>]
+'git-format-patch' [-n | -k] [-o <dir> | --stdout] [--attach]
+ [--diff-options] [--start-number <n>]
+ <since>[..<until>]
DESCRIPTION
-----------
-Prepare each commit with its patch since <mine> head forked from
-<his> head, one file per patch formatted to resemble UNIX mailbox
-format, for e-mail submission or use with gitlink:git-am[1].
+
+Prepare each commit between <since> and <until> with its patch in
+one file per commit, formatted to resemble UNIX mailbox format.
+If ..<until> is not specified, the head of the current working
+tree is implied.
+
+The output of this command is convenient for e-mail submission or
+for use with gitlink:git-am[1].
Each output file is numbered sequentially from 1, and uses the
-first line of the commit message (massaged for pathname safety)
-as the filename.
+first line of the commit message (checked for pathname safety) as
+the filename. The names of the output files are printed to standard
+output, unless the --stdout option is specified.
-When -o is specified, output files are created in <dir>; otherwise
-they are created in the current working directory. This option
-is ignored if --stdout is specified.
+If -o is specified, output files are created in <dir>. Otherwise
+they are created in the current working directory.
-When -n is specified, instead of "[PATCH] Subject", the first
-line is formatted as "[PATCH N/M] Subject", unless you have only
-one patch.
+If -n is specified, instead of "[PATCH] Subject", the first line
+is formatted as "[PATCH n/m] Subject".
OPTIONS
-------
-o|--output-directory <dir>::
Use <dir> to store the resulting files, instead of the
- current working directory.
+ current working directory. This option is ignored if
+ --stdout is specified.
-n|--numbered::
Name output in '[PATCH n/m]' format.
+--start-number <n>::
+ Start numbering the patches with <n> instead of 1.
+
-k|--keep-subject::
Do not strip/add '[PATCH]' from the first line of the
commit log message.
--s|--signoff::
- Add `Signed-off-by:` line to the commit message, using
- the committer identity of yourself.
-
--c|--check::
- Display suspicious lines in the patch. The definition
- of 'suspicious lines' is currently the lines that has
- trailing whitespaces, and the lines whose indentation
- has a SP character immediately followed by a TAB
- character.
-
--stdout::
- This flag generates the mbox formatted output to the
- standard output, instead of saving them into a file per
- patch and implies --mbox.
+ Print all commits to the standard output in mbox format,
+ instead of creating a file for each one.
--attach::
Create attachments instead of inlining patches.
-CONFIGURATION
--------------
-You can specify extra mail header lines to be added to each
-message in the repository configuration as follows:
-
-[format]
- headers = "Organization: git-foo\n"
-
-
EXAMPLES
--------
@@ -82,18 +70,18 @@ git-format-patch -k --stdout R1..R2 | gi
cherry-pick them.
git-format-patch origin::
- Extract commits the current branch accumulated since it
- pulled from origin the last time in a patch form for
- e-mail submission.
+ Extract all commits which are in the current branch but
+ not in the origin branch. For each commit a separate file
+ is created in the current directory.
git-format-patch -M -B origin::
- The same as the previous one, except detect and handle
- renames and complete rewrites intelligently to produce
- renaming patch. A renaming patch reduces the amount of
- text output, and generally makes it easier to review
- it. Note that the "patch" program does not understand
- renaming patch well, so use it only when you know the
- recipient uses git to apply your patch.
+ The same as the previous one. Additionally, it detects
+ and handles renames and complete rewrites intelligently to
+ produce a renaming patch. A renaming patch reduces the
+ amount of text output, and generally makes it easier to
+ review it. Note that the "patch" program does not
+ understand renaming patches, so use it only when you know
+ the recipient uses git to apply your patch.
See Also
--
1.3.3+git20060531-dest1
^ permalink raw reply related
* Re: format-patch signoff argument no longer works
From: Johannes Schindelin @ 2006-05-31 14:09 UTC (permalink / raw)
To: Seth Falcon; +Cc: git
In-Reply-To: <m2mzcycn4f.fsf@ziti.fhcrc.org>
Hi,
On Wed, 31 May 2006, Seth Falcon wrote:
> Matthias Kestenholz <lists@spinlock.ch> writes:
>
> > * Geoff Russell (geoffrey.russell@gmail.com) wrote:
> >> It appears to have got lost when the shell script got converted to C.
> >>
> > Yes, this was intentional. You should sign off your changes while
> > committing (git commit -s|--signoff)
>
> When should one commit _without_ signoff?
>
> The obvious answer is: when one doesn't approve of the changes in the
> commit... But in my usual workflow, commit means
> works-for-me-I-think-it-is-good. :-)
Well, there are often times when I commit something to a throw-away
branch, where I do not want to sign it off.
That was my original incentive to add this option BTW: I usually clean up
a patch series in a cycle of tests and fixes, and only want to sign off on
the final version.
If people need this option, I'll implement it, so speak up!
Ciao,
Dscho
^ permalink raw reply
* Re: format-patch signoff argument no longer works
From: Seth Falcon @ 2006-05-31 13:58 UTC (permalink / raw)
To: git
In-Reply-To: <20060531112803.GB3877@spinlock.ch>
Matthias Kestenholz <lists@spinlock.ch> writes:
> * Geoff Russell (geoffrey.russell@gmail.com) wrote:
>> It appears to have got lost when the shell script got converted to C.
>>
> Yes, this was intentional. You should sign off your changes while
> committing (git commit -s|--signoff)
When should one commit _without_ signoff?
The obvious answer is: when one doesn't approve of the changes in the
commit... But in my usual workflow, commit means
works-for-me-I-think-it-is-good. :-)
Also, here's a trivial patch to the git-format-patch doc. I recently
had the same confusion trying to get git-format-patch to add signoff
for me...
Remove reference to signoff option (-s) in git-format-patch
Signed-off-by: Seth Falcon <sethfalcon@gmail.com>
---
Documentation/git-format-patch.txt | 6 +-----
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index 7cc7faf..d13f463 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -9,7 +9,7 @@ git-format-patch - Prepare patches for e
SYNOPSIS
--------
[verse]
-'git-format-patch' [-n | -k] [-o <dir> | --stdout] [--attach] [-s] [-c]
+'git-format-patch' [-n | -k] [-o <dir> | --stdout] [--attach] [-c]
[--diff-options] <his> [<mine>]
DESCRIPTION
@@ -44,10 +44,6 @@ OPTIONS
Do not strip/add '[PATCH]' from the first line of the
commit log message.
--s|--signoff::
- Add `Signed-off-by:` line to the commit message, using
- the committer identity of yourself.
-
-c|--check::
Display suspicious lines in the patch. The definition
of 'suspicious lines' is currently the lines that has
--
1.3.3.gb931
^ 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