From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
Date: 1121951436 -0400
Try all addresses for given remote name until it succeeds.
Also supports IPv6.
Signed-off-by: Hideaki YOSHIFUJI <[EMAIL PROTECTED]>
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
*** Linus, I am not ACKing Hideaki's other c
From: Ryan Anderson <[EMAIL PROTECTED]>
Date: 1122014167 -0400
The deb package building needs these two new files to work correctly.
debian/compat sets the rules under which the debhelper scripts (dh_*) operate.
debian/git-core.install tells dh_install what files to install in each package
that
From: Ryan Anderson <[EMAIL PROTECTED]>
Date: 1122011756 -0400
The Deb packages were missing a dependency on "build install" from the
binary target - this fixes that, and cleans up some inconsistencies
elsewhere in the rulesets.
Traditionally, Debian packaging uses a file called "build-stamp" (or
Update the recommended workflow for individual developers.
While they are tracking the origin, refs/heads/origin is updated
by "git fetch", so there is no need to manually copy FETCH_HEAD
to refs/heads/ anywhere.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
Documentation/tutorial.txt |
A bit more usability enhancement, while retaining Cogito
compatibility.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
*** Just after sending I noticed that the first hunk is a pure
*** bugfix. Hope you do not mind...
git-clone-script | 41 +++--
1 f
Match the main Makefile by separating COPTS from CFLAGS,
defining INSTALL, prefix, and bin. Add a new target 'install-tools'
to the main Makefile to install them.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
Makefile |4
tools/Makefile | 13 +++--
2 files chang
This patch changes rev-parse users that pass a single argument
that is supposed to be a rev parameter to use "--verify".
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
git-checkout-script |2 +-
git-cherry |8
git-commit-script |2 +-
git-rebase-script |
The output from a failure case had the test description message
and the first line of the actual test script concatenated on the
same line, which was ugly. Correct the output routine a bit to
make it more readable.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
t/test-lib.sh |4 +++-
When not specifying the start point explicitly, we ended up
emitting ^0 in addition to the default HEAD. Be careful to see
if we have "$2" before finding out which commit to base the new
branch on.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
git-branch-script |8 +++-
1 files
The git-rev-parse command uses LF to separate each argument it
parses, so its users at least need to set IFS to LF to be able
to handle filenames with embedded SPs and TABs. Some commands,
however, can take and do expect arguments with embedded LF,
notably, "-S" (pickaxe) of diff family, so even t
I'll be sending these next:
[PATCH] Help scripts that use git-rev-parse to grok args with SP/TAB/LF
[PATCH] git-branch: avoid getting confused by empty or nonexisting branches.
[PATCH] Audit rev-parse users.
[PATCH] Install tools with "make install-tools".
[PATCH] Test framework: prettyp
From: Darrin Thompson <[EMAIL PROTECTED]>
Date: 1121220760 -0500
Cause setting environment variable GIT_SSL_NO_VERIFY to turn off
curl's ssl peer verification.
Only use curl for http transfers, instead of curl and wget.
Make curl check ~/.netrc for credentials.
Signed-off-by: Junio C Hamano <[E
From: Jan Veldeman <[EMAIL PROTECTED]>
Date: 1121810349 -0700
Fix a typo in git-unpack-objects documentation.
Signed-off-by: Jan Veldeman <[EMAIL PROTECTED]>
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
Documentation/git-unpack-objects.txt |2 +-
1 files changed, 1 insertions(+), 1
From: Eric W. Biederman <[EMAIL PROTECTED]>
Date: 1121545164 -0600
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
Makefile |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
858d9f99d6ff1946c82e0dd191c4bb6a0d737d39
diff --git
From: Ryan Anderson <[EMAIL PROTECTED]>
Date: 1121822267 -0400
Make debian/rules executable, and correct the spelling of rsync in
debian/control.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
debian/control |2 +-
debian/rules |0
2 files changed, 1 insertions(+), 1 deletions
From: Eric W. Biederman <[EMAIL PROTECTED]>
Date: 1121545120 -0600
- Use git-rev-parse to allow sha1 tags references
- When the tag does not verify set an appropriate exit status
- Use git-sh-setup-script to verify the .git directory
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
Signed-off
Not just libcurl, but now we require curl executable as well.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
INSTALL |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
b300e6d28fc160ddc6685bde96b6bc9a710e01c3
diff --git a/INSTALL b/INSTALL
--- a/INSTALL
+++ b/INSTALL
@@ -41,
Linus Torvalds <[EMAIL PROTECTED]> writes:
> In other words, if it's per-project, then that implies that every single
> developer has to agree on the same thing. Which just not possible - it
> makes no sense.
I agree 75%. See the bottom for the rest 25%.
> In contrast, if you have a separate
Dear diary, on Sat, Jul 23, 2005 at 01:50:09AM CEST, I got a letter
where Linus Torvalds <[EMAIL PROTECTED]> told me that...
>
>
> On Sat, 23 Jul 2005, Petr Baudis wrote:
> >
> > Yes, but this stuff is not for personal preferences. It is for
> > project-wide preferences and policies, which can b
Dear diary, on Sat, Jul 23, 2005 at 01:24:35AM CEST, I got a letter
where Junio C Hamano <[EMAIL PROTECTED]> told me that...
> Petr Baudis <[EMAIL PROTECTED]> writes:
>
> > Cogito shows '[NMD] filename' in place of @[EMAIL PROTECTED]
>
> Sounds sensible. Does it parse it to limit the files to be
On Sat, 23 Jul 2005, Petr Baudis wrote:
>
> Yes, but this stuff is not for personal preferences. It is for
> project-wide preferences and policies, which can be still normally
> overridden or altered locally in each repository.
What you are describing is a nightmare.
Let's assume that a user a
Dear diary, on Sat, Jul 23, 2005 at 01:26:07AM CEST, I got a letter
where Linus Torvalds <[EMAIL PROTECTED]> told me that...
> On Fri, 22 Jul 2005, Junio C Hamano wrote:
> > Linus Torvalds <[EMAIL PROTECTED]> writes:
> >
> > > I'd _really_ prefer to not have any preferences or other metadata files
Dear diary, on Fri, Jul 22, 2005 at 11:53:41PM CEST, I got a letter
where Linus Torvalds <[EMAIL PROTECTED]> told me that...
> On Fri, 22 Jul 2005, Junio C Hamano wrote:
> >
> > And the file would obviously be per-project, so according to
> > Pasky's suggestion that would be ".gitinfo/fake_parents
On Fri, 22 Jul 2005, Junio C Hamano wrote:
> Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> > I'd _really_ prefer to not have any preferences or other metadata files
> > under version control within that same project.
>
> Don't you think that would be a per-project decision? Is it
> acceptable
Petr Baudis <[EMAIL PROTECTED]> writes:
> Cogito shows '[NMD] filename' in place of @[EMAIL PROTECTED]
Sounds sensible. Does it parse it to limit the files to be
committed?
> This brings me to another subject, M and N are pretty hard to
> distinguish visually without close inspection of the out
Dear diary, on Thu, Jul 14, 2005 at 12:12:25PM CEST, I got a letter
where Russell King <[EMAIL PROTECTED]> told me that...
> Last time this was discussed, someone suggested -f, which solved the
> problem. Can we please modify the cg-pull script to use -f ?
Thanks, done.
> Secondly, can I suggest
Catalin Marinas <[EMAIL PROTECTED]> writes:
> Would such a template only have 'GIT:' prefixed lines? I usually put
> another line like 'Signed-off-by:', for convenience. The problem with
> StGIT appears when one wants to re-edit the patch description (stg
> refresh -e), in which case the existing
Add --mbox option to export patches in a format resembling UNIX
mbox, so that later they can be concatenated and fed to
applymbox.
Add --check to look for lines that introduce bogus whitespaces.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
git-format-patch-script | 49 +++
- avoid duplicating [PATCH] in the commit message body if the
original commit has it already (happens for commits done from
mails via applymbox).
- check if the commit author is different from the one who is
running the script, and emit an appropriate "From:" and
"Date: " lines to t
With "-c .dotest/0002" flag, the applymbox command can be told
to use existing .dotest/patch file after hand-fixing the patch
conflicts for the second patch in the mailbox, and continue on
from that message, skipping the already applied first patch in
.dotest/0001.
Signed-off-by: Junio C Hamano <[
(Resend after you said you prefer people resending).
I was experimenting with applypatch and applymbox to see how it
feels like being Linus ;-) and also I saw some trivially correct
patches on the list floating unmerged during KS/OLS.
Since I rebase my repostitory to fix up the history often, I
n
Linus Torvalds <[EMAIL PROTECTED]> writes:
> I'd _really_ prefer to not have any preferences or other metadata files
> under version control within that same project.
Don't you think that would be a per-project decision? Is it
acceptable if I make sure that .gitinfo/* is _optional_ and
things do
On Fri, Jul 22, 2005 at 05:26:29PM -0400, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
> In article <[EMAIL PROTECTED]> (at Fri, 22 Jul 2005 23:09:13 +0200), Petr
> Baudis <[EMAIL PROTECTED]> says:
>
> > > -}
> > > +#define STR_(s) # s
> > > +#define STR(s) STR_(s)
> >
> > Uh-huh? Why two macros? W
Linus Torvalds <[EMAIL PROTECTED]> writes:
> Think of something like a collection of projects, each under their own
> subdirectory. We could eventually literally make them _look_ like one big
> project, with cross-project commits grafted together, but they'd
> technically be totally independent
Hello,
I don't expect anyone but myself to actually follow git-pb, but just
in case - I rebased it against the latest Linus' HEAD since its history
was becoming rather dirty, rusty and generally undesirable to merge for
anyone. So if you will try to update, you will end up with tree merge
and
On Sat, 23 Jul 2005, Petr Baudis wrote:
>
> Dear diary, on Wed, Jul 20, 2005 at 03:17:47AM CEST, I got a letter
> where Ryan Anderson <[EMAIL PROTECTED]> told me that...
> > Make debian/rules executable, and correct the spelling of rsync in
> > debian/control
>
> Any progress with applying of th
Dear diary, on Wed, Jul 20, 2005 at 03:17:47AM CEST, I got a letter
where Ryan Anderson <[EMAIL PROTECTED]> told me that...
> Make debian/rules executable, and correct the spelling of rsync in
> debian/control
Any progress with applying of this one? Linus, do you want me to ack
even trivial patche
Dear diary, on Fri, Jul 22, 2005 at 11:35:17PM CEST, I got a letter
where "YOSHIFUJI Hideaki / ?$B5HF#1QL@" <[EMAIL PROTECTED]> told me that...
> In article <[EMAIL PROTECTED]> (at Fri, 22 Jul 2005 23:21:51 +0200), Petr
> Baudis <[EMAIL PROTECTED]> says:
> > this whole getaddrinfo() magic looks ho
On Fri, 22 Jul 2005, Junio C Hamano wrote:
>
> And the file would obviously be per-project, so according to
> Pasky's suggestion that would be ".gitinfo/fake_parents" ;-).
I'd _really_ prefer to not have any preferences or other metadata files
under version control within that same project.
If
On Fri, 2005-07-22 at 13:39 -0700, Junio C Hamano wrote:
> I would like to see Porcelains stay compatible when the do not
> have to differ. The commit template [*2*] is one example of
> such.
For StGIT it is not a problem to use any commit template with any
prefix. It doesn't generate extra lin
Dear diary, on Fri, Jul 22, 2005 at 11:26:29PM CEST, I got a letter
where "YOSHIFUJI Hideaki / ?$B5HF#1QL@" <[EMAIL PROTECTED]> told me that...
> In article <[EMAIL PROTECTED]> (at Fri, 22 Jul 2005 23:09:13 +0200), Petr
> Baudis <[EMAIL PROTECTED]> says:
>
> > > -}
> > > +#define STR_(s) # s
> >
In article <[EMAIL PROTECTED]> (at Fri, 22 Jul 2005 23:21:51 +0200), Petr
Baudis <[EMAIL PROTECTED]> says:
> this whole getaddrinfo() magic looks horribly complicated. What's wrong
> on just adding a similar code (or factoring it out to a function) for
> IPv6 as there is for IPv4, just s/INET/IN
In article <[EMAIL PROTECTED]> (at Fri, 22 Jul 2005 23:09:13 +0200), Petr
Baudis <[EMAIL PROTECTED]> says:
> > -}
> > +#define STR_(s)# s
> > +#define STR(s) STR_(s)
>
> Uh-huh? Why two macros? Well, why any macros at all?
>
:
> > + char *colon, *end;
> > + char *port = STR(DEFAULT_
Dear diary, on Fri, Jul 22, 2005 at 11:16:51PM CEST, I got a letter
where Junio C Hamano <[EMAIL PROTECTED]> told me that...
> Wonderful start.
>
> Later on, Porcelains could agree on what @TOKEN@ are generally
> available, and even start using a common script to pre-fill the
> templates, like:
>
Dear diary, on Thu, Jul 21, 2005 at 03:10:49PM CEST, I got a letter
where "YOSHIFUJI Hideaki / ?$B5HF#1QL@" <[EMAIL PROTECTED]> told me that...
> Hello.
Hello from an IPv6 fan,
> Listen on IPv6 as well, if available.
>
> Signed-off-by: Hideaki YOSHIFUJI <[EMAIL PROTECTED]>
>
> diff --git a/daem
Linus Torvalds <[EMAIL PROTECTED]> writes:
> Just teach "parse_commit()" to look at a ".git/fake_parents" file, and
> insert fake extra parents for commits that way - you can graft any tree on
> top of any other tree that way, and it's probably a nice idea for testing
> things out.
Nicely put,
Wonderful start.
Later on, Porcelains could agree on what @TOKEN@ are generally
available, and even start using a common script to pre-fill the
templates, like:
$ git-fill-template-script var=val var=val...
In your example, I see AUTHOR_NAME, AUTHOR_EMAIL, and
AUTHOR_DATE (I'd use GIT_AUTHOR
Dear diary, on Thu, Jul 21, 2005 at 03:10:36PM CEST, I got a letter
where "YOSHIFUJI Hideaki / ?$B5HF#1QL@" <[EMAIL PROTECTED]> told me that...
> Hello.
Hello,
> Try all addresses for given remote name until it succeeds.
> Also supports IPv6.
>
> Signed-of-by: Hideaki YOSHIFUJI <[EMAIL PROTECTED
Dear diary, on Thu, Jul 21, 2005 at 01:49:04AM CEST, I got a letter
where Wolfgang Denk <[EMAIL PROTECTED]> told me that...
> I wander what I should do with "cg-mkpatch" generated output; I had
> the impression that this should be usable with "cg-patch", but these
> are incompatible with each ot
Dear diary, on Thu, Jul 21, 2005 at 05:57:49AM CEST, I got a letter
where Junio C Hamano <[EMAIL PROTECTED]> told me that...
> I only briefly looked at cg-patch, but I suspect that it can
> lose 90% lines of its code by just using "git-apply --index".
Can git-apply already deal with fuzzy patches?
Dear diary, on Fri, Jul 22, 2005 at 10:39:06PM CEST, I got a letter
where Junio C Hamano <[EMAIL PROTECTED]> told me that...
> Porcelains need to agree on what is placed where and used in
> what way.
Yes, I always try to make things as Cogito-unspecific as possible.
> - Per user. A user may wa
On Fri, 2005-07-22 at 19:24 +, Sam Ravnborg wrote:
> > I would use a neutral commit template, only that it should have a
> > neutral prefix as well for the lines to be removed (neither STG nor CG
> > but GIT maybe). The $GIT_DIR/commit-template is fine as a file name.
>
> How about $GIT_DIR/co
On Fri, 22 Jul 2005, A Large Angry SCM wrote:
>
> To do it without the history rewrite, create an alternate_history
> directory under .git with it's own objects tree. And populate that
> object tree with "alternative" content for the objects in the normal
> trees. Then teach the things the lo
Dear diary, on Fri, Jul 22, 2005 at 12:37:05PM CEST, I got a letter
where Catalin Marinas <[EMAIL PROTECTED]> told me that...
> > Cogito seems to use $GIT_DIR/commit-template for that purpose.
> > Can't users put that "vim:" hint there, and if StGIT does not
> > use a commit template, patch it to u
Sam Ravnborg <[EMAIL PROTECTED]> writes:
>> I would use a neutral commit template, only that it should have a
>> neutral prefix as well for the lines to be removed (neither STG nor CG
>> but GIT maybe). The $GIT_DIR/commit-template is fine as a file name.
>
> How about $GIT_DIR/commit-template-`ba
Junio C Hamano wrote:
Ryan Anderson <[EMAIL PROTECTED]> writes:
On Fri, Jul 22, 2005 at 09:56:19AM -0700, Junio C Hamano wrote:
Now if we had a mechanism to graft a later history which starts
at 2.6.12-rc2 on top of this earlier history leading up to
it,... ;-)
We do - it's not even very har
On Fri, Jul 22, 2005 at 12:46:36PM -0700, Junio C Hamano wrote:
> Ryan Anderson <[EMAIL PROTECTED]> writes:
>
> > On Fri, Jul 22, 2005 at 09:56:19AM -0700, Junio C Hamano wrote:
> >> Now if we had a mechanism to graft a later history which starts
> >> at 2.6.12-rc2 on top of this earlier history l
Ryan Anderson <[EMAIL PROTECTED]> writes:
> On Fri, Jul 22, 2005 at 09:56:19AM -0700, Junio C Hamano wrote:
>> Now if we had a mechanism to graft a later history which starts
>> at 2.6.12-rc2 on top of this earlier history leading up to
>> it,... ;-)
>
> We do - it's not even very hard, we just e
Hi,
here is qgit-0.8:
http://prdownloads.sourceforge.net/qgit/qgit-0.8.tar.bz2?download
This release shows a big GUI rewrite with added menus,
buttons, help, settings page, etc.
Some new features:
- Possibility to view diffs against current checked-out tree, i.e
GUI interface to git-
On Fri, Jul 22, 2005 at 09:56:19AM -0700, Junio C Hamano wrote:
> Now if we had a mechanism to graft a later history which starts
> at 2.6.12-rc2 on top of this earlier history leading up to
> it,... ;-)
We do - it's not even very hard, we just end up with 2 commits for every
change/merge that's
>
> I would use a neutral commit template, only that it should have a
> neutral prefix as well for the lines to be removed (neither STG nor CG
> but GIT maybe). The $GIT_DIR/commit-template is fine as a file name.
How about $GIT_DIR/commit-template-`basename $EDITOR`
Then we could have different
Adds --exclude=pattern option to the "git-apply" command. This
was useful while reimporting the BKCVS patchset dump of the
Linux kernel, starting at 2.4.0 and ending at 2.6.12-rc2 Ingo
announced some time ago to exclude BitKeeper directory.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
The parsing code had a bug that failed to recognize an
incomplete line at the end of a fragment, and the fragment
application code had a comparison bug to recognize such. Fix
them to handle incomplete lines correctly.
Add a test script for patches with various combinations of
complete and incompl
In mid April, Ingo announced availability of his conversion from
CVS to a flat patchset format:
From: Ingo Molnar <[EMAIL PROTECTED]>
Subject: full kernel history, in patchset format
Message-ID: <[EMAIL PROTECTED]>
the history data starts at 2.4.0 and ends at 2.6.12-rc2. I've incl
Junio C Hamano <[EMAIL PROTECTED]> wrote:
> I do not do Porcelain, but wouldn't it be nicer if we had a
> Porcelain neutral "commit log template file" under $GIT_DIR
> somewhere? 'vim: textwidth=75' is completely useless for
> somebody like me (I almost always work inside Emacs).
StGIT uses .git/
65 matches
Mail list logo
