On Mon, Aug 08, 2005 at 07:49:26PM -0700, Junio C Hamano wrote:
> Johannes Schindelin <[EMAIL PROTECTED]> writes:
>
> > Junio remarked that Jeff's git-changes-script still uses git-rev-tree, and
> > therefore it should not be removed. This patch changes git-changes-script
> > over to git-rev-lis
On Mon, 8 Aug 2005, Linus Torvalds wrote:
>
> It also cleans things up: it marks the text widget as no-wrap, which means
> that it doesn't need to truncate the commit description arbitrarily by
> hand.
Btw, in case anybody wondered: there is no x-axis scroll-bar. I don't
think one is needed, a
This adds "Child: " lines to the commit window, which tells what children
a commit has.
It also cleans things up: it marks the text widget as no-wrap, which means
that it doesn't need to truncate the commit description arbitrarily by
hand. Also, the description itself is now done by a common he
Johannes Schindelin <[EMAIL PROTECTED]> writes:
> Junio remarked that Jeff's git-changes-script still uses git-rev-tree, and
> therefore it should not be removed. This patch changes git-changes-script
> over to git-rev-list:
Just to make things clear, "Junio remarked" that Cogito also
seems to
Johannes Schindelin <[EMAIL PROTECTED]> writes:
> I, for one, like the layout. There are not yet enough files to merit a
> hierarchy, and what's more: I can add the source-directory to my PATH and
> be done by compiling every time I pull.
>
> But you're right in any case, it is post 1.0 discussi
Josef Weidendorfer <[EMAIL PROTECTED]> writes:
>> My point being that I still can say
>>
>> git pull x some_non_default_head
>>
>> with a file "x" in .git/branches.
>
> Is this currently possible?
Not right now, but that is the plan.
> My understanding of .git/branches was that Cogito uses
Catalin Marinas <[EMAIL PROTECTED]> writes:
> OK, I wasn't that clear. Currently git-fetch-script stores the fetched
> head in the FETCH_HEAD file and git-pull-script uses this file to do
> the merging (by passing its content to git-resolve-script).
Correct. I was not planning to change that arr
Johannes Schindelin <[EMAIL PROTECTED]> writes:
> Since there are not many users of git-commit's *-m* flag right now: Is it
> necessary to confuse CVS people, who expect to be able to write
>
> git commit -m "I did this and that"
>
> I do not want to be too intrusive, but I think up to now
Johannes Schindelin <[EMAIL PROTECTED]> writes:
> I'd prefer $GIT_DIR/remotes/. And I propose another extension: Since the
> files stored therein right now contain only one string, it should
> be possible to add the default head(s) to the file.
That makes sense. Currently my arrangement is:
On Tue, 9 Aug 2005, Johannes Schindelin wrote:
>
> Junio remarked that Jeff's git-changes-script still uses git-rev-tree, and
> therefore it should not be removed. This patch changes git-changes-script
> over to git-rev-list:
It really should be totally rewritten, to take advantage of git-rev
Hi,
Junio remarked that Jeff's git-changes-script still uses git-rev-tree, and
therefore it should not be removed. This patch changes git-changes-script
over to git-rev-list:
--- git-changes-script.orig Tue Aug 9 02:21:36 2005
+++ git-changes-script Tue Aug 9 02:20:53 2005
@@ -85,14 +85,
[PATCH] Adapt git-cherry and git-rebase-script to latest changes of git commit
Teach git-cherry and git-rebase-script to use the "-c" option, since
"-m" means something different to git-commit-script now.
Signed-off-by: Johannes Schindelin <[EMAIL PROTECTED]>
---
git-cherry|2 +-
g
Apparently I was under a rock sleeping when git-tag-script changed to no
longer take input from stdin. So my script which did:
TAG=$(echo "$TAG_MSG" | git-tag-script $RELEASE)
echo $TAG > .git/refs/tags/$RELEASE
Is broken in two ways. First it's no longer building an annotated tag,
second it cr
Hi,
On Mon, 8 Aug 2005, Junio C Hamano wrote:
> Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> > Or if you want to be more CVS-like, use "-F", and accept "-" for stdin?
>
> Yes my vote goes:
>
> -m "message"
> -c "from this commit, literally."
> -C "from this commit, but
Hi,
On Mon, 8 Aug 2005, Ryan Anderson wrote:
> [...]
>
> We should discuss (or just do) a reorganization of how we lay out the
> source tree.
>
> [...]
I, for one, like the layout. There are not yet enough files to merit a
hierarchy, and what's more: I can add the source-directory to my PATH an
Hi,
On Mon, 8 Aug 2005, Junio C Hamano wrote:
> We would need something like this.
>
> [...]
>
> +$(patsubst git-%,%.o,$(PROG)): $(LIB_H)
A short
for i in git-*; do \
c=$(echo $i|sed "s/git-\(.*\)/\1.c/g")
if [ -e $c ]; then \
if !
On Mon, Aug 08, 2005 at 01:53:24PM -0700, Junio C Hamano wrote:
> I do want to revisit Makefile issues after 0.99.4, along with
> the changes Pasky sent several days ago. Please remind me about
> them after Wednesday.
We should discuss (or just do) a reorganization of how we lay out the
source tr
Linus Torvalds <[EMAIL PROTECTED]> writes:
> Most of us don't use 300bps terminals any more, so typing a few extra
> characters is probably ok.
Again you are right.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
Chris Wright <[EMAIL PROTECTED]> writes:
>> I take it to mean that we do not have to explicitly list perl
>> module dependencies. If that is the case then I presume that
>> the current dependency list is fine.
>
> That's correct. The only benefit to itemzing the package level dependency in
> thi
Johannes Schindelin <[EMAIL PROTECTED]> writes:
> BTW, if you are lazy, like me, you just pull from Junio once in a while
> and do a "make test". Turns out there is a missing dependency though:
>
> peek-remote.o: cache.h
>
> which in my case lead to a git-peek-remote program which was unable to
Linus Torvalds <[EMAIL PROTECTED]> writes:
> Or if you want to be more CVS-like, use "-F", and accept "-" for stdin?
Yes my vote goes:
-m "message"
-c "from this commit, literally."
-C "from this commit, but let me edit the log further."
-F "from this file."
* Junio C Hamano ([EMAIL PROTECTED]) wrote:
> Chris Wright <[EMAIL PROTECTED]> writes:
>
> > ... Also, rpm is able to determine the perl dependencies
> > automatically (of course, ditto for shared libraries).
>
> I take it to mean that we do not have to explicitly list perl
> module dependencies
Chris Wright <[EMAIL PROTECTED]> writes:
> ... Also, rpm is able to determine the perl dependencies
> automatically (of course, ditto for shared libraries).
I take it to mean that we do not have to explicitly list perl
module dependencies. If that is the case then I presume that
the current dep
On Mon, 8 Aug 2005, Junio C Hamano wrote:
>
> Sure, what's the alternative spelling for the current -m,
> though? Would -c be OK for commit?
How about using long names?
git commit --reuse-message
looks a lot more intuitively understandable to me than something like "-c"
Most of us
On Mon, 8 Aug 2005, Junio C Hamano wrote:
>
> * git commit does not take commit message from stdin. I think
>we should do something like this:
Yes. Alteratively (or additionally), we should add a command line option
to set the commit message.
CVS uses "-m", but you already took that. I
Johannes Schindelin <[EMAIL PROTECTED]> writes:
> And could we rename the *-m* flag at the same time? Because I often catch
> myself typing
>
> git commit -m "Some_commit_message"
Sure, what's the alternative spelling for the current -m,
though? Would -c be OK for commit?
-
To unsubscrib
Hi,
On Mon, 8 Aug 2005, Junio C Hamano wrote:
> * git commit does not take commit message from stdin. I think
>we should do something like this:
>
> [...]
And could we rename the *-m* flag at the same time? Because I often catch
myself typing
git commit -m "Some_commit_message"
Hi list,
I mentioned in another mail that I needed the opposite of git-push, namely
getting all heads, and if they are strict parents of the local refs, just
update them.
Well, Junio pointed out that it's easy using the available tools, and he
was right. The result is attached (and tested...).
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Mon, 8 Aug 2005, Junio C Hamano wrote:
>>
>> Totally untested. I acquired your habit of coding in my e-mail
>> client ;-).
>
> Looks good. Although I also have this advanced testing habit of just
> reading the email and if it looks sane it tested
On Mon, 8 Aug 2005, Junio C Hamano wrote:
>
> Totally untested. I acquired your habit of coding in my e-mail
> client ;-).
Looks good. Although I also have this advanced testing habit of just
reading the email and if it looks sane it tested out ok ;)
But it strikes me that we could use the "
Pavel Roskin <[EMAIL PROTECTED]> writes:
> Quoting GNU Coding Standards ("info standards"):
>
> "If there are C compiler options that _must_ be used for proper
> compilation of certain files, do not include them in `CFLAGS'. Users
> expect to be able to specify `CFLAGS' freely themselves."
Quoti
Linus Torvalds <[EMAIL PROTECTED]> writes:
>> It may not have the nicest error messages: if you try to revert a merge
>> (which won't have a diff), git-apply will say something like
>>
>> fatal: No changes
>>
>> which isn't exactly being helpful. And the revert message could be made
>> mor
Hi,
attached is a bugfix for the newly introduced git_mkstemp() function.
/holger
git_mkstemp() bugfix
---
commit 8cccfa75e0095afd2dd4ec354f2786068c9e7a2f
tree 354e00b03039e0c42284442c9764dcd3bf8f608f
parent d59a6043a8a7aed97c684fb4f14fe5221df1fcaf
author Holger Eitzenberger <[EMAIL PROTECTED]>
Comments?
Linus
On Mon, 8 Aug 2005, Linus Torvalds wrote:
>
>
> On Mon, 8 Aug 2005, Greg KH wrote:
> >
> > Hm, how do you revert a git patch?
>
> Something like this?
>
> #!/bin/sh
> . git-sh-setup-script || die "Not a git archive"
> rev=$(git-rev-parse --v
* Junio C Hamano ([EMAIL PROTECTED]) wrote:
> For RPM, from my lack of RPM expertise (and RPM capable
> environment until recently), I have not updated the "Prereq:"
> field in git-core.spec.in at all. I would appreciate somebody
> to sanity check the list of dependencies. The dependency list
> D
[PATCH] Plug memory leak in git-pack-objects
find_deltas() should free its temporary objects before returning.
Signed-off-by: Sergey Vlasov <[EMAIL PROTECTED]>
---
pack-objects.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
8b38f80b97affd0d9808b8f276a9e2e04bf03464
diff --git a
[PATCH] Plug memory leak in sha1close()
sha1create() and sha1fd() malloc the returned struct sha1file;
sha1close() should free it.
Signed-off-by: Sergey Vlasov <[EMAIL PROTECTED]>
---
csum-file.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
2207ae4977cbaa84636487ca24bad9d1116f54e
[PATCH] Plug memory leak in write_sha1_to_fd()
If the object to write was packed, both its uncompressed and compressed
data were leaked. If the object was not packed, its file was not unmapped.
Signed-off-by: Sergey Vlasov <[EMAIL PROTECTED]>
---
sha1_file.c | 14 --
1 files chan
[PATCH] Plug memory leak in read_object_with_reference()
When following a reference, read_object_with_reference() did not free the
intermediate object data.
Signed-off-by: Sergey Vlasov <[EMAIL PROTECTED]>
---
sha1_file.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
f7d16d6b83698
Hello!
This set of patches fixes some more memory leaks which I have found in
git. Especially the write_sha1_to_fd() leak was noticeable when
running git-ssh-push.
--
Sergey Vlasov
pgpHMTIIDB3N1.pgp
Description: PGP signature
On Mon, 08 Aug 2005 10:38:44 -0700 Junio C Hamano wrote:
> For RPM, from my lack of RPM expertise (and RPM capable
> environment until recently), I have not updated the "Prereq:"
> field in git-core.spec.in at all.
That "Prereq:" should be "Requires:" instead. "Prereq:" also
enforces installatio
I need a bit more help from binary packaging people.
I have not heard from Darwin or BSD people for some time. Is
your portfile up to date? Do you have updates you want me to
include? Have we introduced non-Linux non-GNU incompatibilities
lately that you want to see fixed and/or worked around?
On Monday 08 August 2005 12:36, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 8 Aug 2005, Josef Weidendorfer wrote:
> > Your example defaults to the master head.
>
> My point being that I still can say
>
> git pull x some_non_default_head
>
> with a file "x" in .git/branches.
Is this currentl
Hi,
On Mon, 8 Aug 2005, Josef Weidendorfer wrote:
> Your example defaults to the master head.
My point being that I still can say
git pull x some_non_default_head
with a file "x" in .git/branches. Anyway, I don't care much either way, if
it be "remotes/" or "remoterefs/" or
"magic_ma
On Monday 08 August 2005 11:55, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 8 Aug 2005, Josef Weidendorfer wrote:
> > IMHO, $GIT_DIR/branches/ is really confusing.
> > Hmmm... in $GIT_DIR/branches/ there are named references to remote
> > (named) references.
>
> Not necessarily. The following is p
Junio C Hamano <[EMAIL PROTECTED]> wrote:
> Catalin Marinas <[EMAIL PROTECTED]> writes:
>> Is FETCH_HEAD going to be preserved by the git-fetch-script operation?
>> It should be, unless, git-pull-script removes it or it is changed to
>> do the fetch as well.
>
> I am not quite sure what is being as
Hi,
On Mon, 8 Aug 2005, Josef Weidendorfer wrote:
> IMHO, $GIT_DIR/branches/ is really confusing.
> Hmmm... in $GIT_DIR/branches/ there are named references to remote (named)
> references.
Not necessarily. The following is perfectly valid:
echo "rsync://rsync.kernel.org/pub/scm/git/git.git > .
Some http servers return an HTML error page and git reads it as normal
data. Adding -f option makes curl fail silently.
Signed-off-by: Catalin Marinas <[EMAIL PROTECTED]>
---
git-clone-dumb-http |2 +-
git-fetch-script |2 +-
git-ls-remote-script |2 +-
3 files changed, 3 insert
On Monday 08 August 2005 11:10, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 7 Aug 2005, Junio C Hamano wrote:
> > I hear a lot of people mention $GIT_DIR/branches/ is confusing.
> > Maybe we should rename it to $GIT_DIR/remote/ directory?
>
> I'd prefer $GIT_DIR/remotes/.
IMHO, $GIT_DIR/branches/
Hi,
On Mon, 8 Aug 2005, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 7 Aug 2005, Junio C Hamano wrote:
>
> > $ git commit -m ORIG_HEAD
>
> Since there are not many users of git-commit's *-m* flag right now: Is it
> necessary to confuse CVS people, who expect to be able to write
>
>
Hi,
On Sun, 7 Aug 2005, Junio C Hamano wrote:
> $ git commit -m ORIG_HEAD
Since there are not many users of git-commit's *-m* flag right now: Is it
necessary to confuse CVS people, who expect to be able to write
git commit -m "I did this and that"
I do not want to be too intrusive
Hi,
On Sun, 7 Aug 2005, Junio C Hamano wrote:
> I hear a lot of people mention $GIT_DIR/branches/ is confusing.
> Maybe we should rename it to $GIT_DIR/remote/ directory?
I'd prefer $GIT_DIR/remotes/. And I propose another extension: Since the
files stored therein right now contain only one st
Things are looking almost ready for a new release. The list at
the end of this message shows what went into the release
candidate branch since 0.99.3: Dan's commit walker updates to
deal with a packed repository, Johannes fixed quite a lot of
problems in the documentation, I did reference-renaming
Catalin Marinas <[EMAIL PROTECTED]> writes:
> gitk ORIG_HEAD..FETCH_HEAD
Yeah, Linus immediately corrected me when I said ORIG_HEAD
seemed useless.
> Is FETCH_HEAD going to be preserved by the git-fetch-script operation?
> It should be, unless, git-pull-script removes it or it is changed to
>
Junio C Hamano <[EMAIL PROTECTED]> wrote:
> Here is my understanding of various "temporary heads" left
> directly underneath $GIT_DIR:
>
> HEAD : updated only after successful auto merge.
>
> ORIG_HEAD : records the head value before resolve started.
> if automerge fail
55 matches
Mail list logo
