* Re: A tour of git: the basics (and notes on some unfriendly messages)
From: Junio C Hamano @ 2007-09-29 22:25 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Git Mailing List, Carl Worth, Shawn O. Pearce
In-Reply-To: <E5C688F2-4A8D-402A-9757-5007BE4A8B25@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> Quite often git prints a lot of very technical information that
> is not very interesting as long as things succeed without error.
> Some examples are
> - git fetch (see above)
Probably.
> - git rebase: prints a lot of details that I'm not interested in
> unless the rebase fails.
Yes. Most of the clutter is coming from "am" which also should
be squelched.
Saying
Switched to branch <blah>
is good when the branch to rebase is specified.
"HEAD is now at ..."
is not useful -- it is a side effect of rewinding the head to
the --onto commit.
<blank line>
Applying <patch subject>
<blank line>
Wrote tree <tree object>
Committed: <commit object>
are coming from "am" for each patch. We could squelch these
into just one "Applying <patch subject>" and nothing else, which
would also help making "am" quieter.
> - git push: prints updates of remote heads. A message about
> failing to update a remote head may get lost.
Please do not remove the report of successful update, as people
often say "git push" or "git push $there" without explicitly
saying which refs to push. When pushing out to publish, I say
"git push ko" (to mean k.org) and I _want_ my positive feedback.
> - git merge: the fact that a merge is a fast forward merge gets
> printed at the very top, followed by (often a lot of) diffstat.
> I know diffstat can help to judge if the merge did what you
> expected. But even more important is the fact that the merge
> was just a fast forward, which may get buried under lots of output.
I do not think fast-forwardness is particularly interesting. If
you find fast-forwardness interesting, I suspect you would even
want to know what _your_ change that were not in the other side
of the merge, which is something that we do not even report
right now.
> Maybe git should become more quiet, as other unix tools are, and
> per default only report problems. Technical details and progress
> could be requested explicitly by '--verbose' or similar.
I'd agree with this sentiment in principle, and many of the
things you propose to remove above fall into the "unnecessary
clutter" category. But some of the existing output fall into
the "necessary info" category --- diffstart after merge and
report of successful remote ref updates are such things, so we
should be careful not to go overboard.
^ permalink raw reply
* Re: Stashing untracked files
From: Tom Prince @ 2007-09-29 22:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Benoit SIGOURE, Neil Macneale, git
In-Reply-To: <Pine.LNX.4.64.0709292248400.28395@racer.site>
> > You could stash untracked files that are not ignored (I personally
> > ignore *.o, *.a and the like).
>
> And what if you happen to forget to ignore that? Or if you happen to
> have an strace log in some file (which you did not ignore either)?
>
> Thanks, but I think the semantics of git stash is pretty well defined.
> And it means that you stash away _tracked_ content that was not yet
> committed.
>
> I mean, you can have your desired behaviour with
>
> $ git add .
> $ git stash
>
> but if we were to fulfil your wish and change the default behaviour, there
> is no way back to the current behaviour (which I happen to find pretty
> sane).
But
git add .
git stash
git stash apply
will not be a no-op any more.
It doesn't need to be a default, but there are certainly times when I would
find the option to stash untracked files convenient.
Tom
^ permalink raw reply
* [ANNOUNCE] tig-0.9.1
From: Jonas Fonseca @ 2007-09-29 22:14 UTC (permalink / raw)
To: git
Hello,
I would like to announce the next installment of tig, which mainly
brings a bunch of fixes. However, there was also room for a few new
features, such as support for cherry-picking to the current branch
(bound to 'C' by default), refreshing of the status view (bound to 'R'),
as well as better handling of unmerged entries in the status view by
suggesting users to launch git-mergetool (by default wired to 'M').
For tig-0.10, I hope to finally get time to finish splitting up the
tig.c file into more manageable pieces. It might also be the release
that will try to get handling of different encodings right by using
wchar_t.
What is tig?
------------
Tig is a ncurses-based text-mode interface for git. It can mainly
function as a git repository browser but can also additionally can act
as a pager for output from various git commands.
Homepage: http://jonas.nitro.dk/tig/
Manual: http://jonas.nitro.dk/tig/manual.html
Tarballs: http://jonas.nitro.dk/tig/releases/
Gitfeed: git://repo.or.cz/tig.git
Gitweb: http://repo.or.cz/w/tig.git
Changes in this release
-----------------------
Below is the diffstat and shortlog for changes made in this release.
.gitignore | 2 +
Makefile | 26 +++++---
SITES | 2 +-
VERSION | 2 +-
acinclude.m4 | 62 ++++++++++++++++++
configure.ac | 41 +------------
manual.txt | 4 +
tig.1.txt | 4 +
tig.c | 198 +++++++++++++++++++++++++++++++++++++++++++++++++---------
tigrc.5.txt | 3 +
10 files changed, 265 insertions(+), 79 deletions(-)
Jonas Fonseca (21):
tig-0.9.1.git
Use the more advanced iconv.m4 script from ELinks
Oops, always ensure that ICONV_CONST is defined
Support cherry-picking commits in main view to current branch
Handle REQ_NONE upfront in view_driver
Fix open_editor to make the file path relative to the project root
Fix out-of-range lineno when reloading the status view
Fix the clean rule to never remove generated doc files
Include autoconf file for 'make dist'
Remove unused 'view' argument from open_editor
Add support for refreshing/reloading the status view
Also ignore generated .md5 files for tarballs
Never put the release number in the tarball name for tagged versions
Ignore REQ_NONE in the help view and improve unbound request handling
Document the refresh request
Detect working trees and disable the status view when it is missing
Refactor code to open_external_viewer
Add support for launching git-mergetool from the status view
Cleanup status_request to make it reload the status view by default
SITES: 'Tarballs' is a bit more telling than 'Releases'
tig-0.9.1
--
Jonas Fonseca
^ permalink raw reply
* Re: [PATCH] WinGit: include html pages from official git.git's html branch
From: Junio C Hamano @ 2007-09-29 22:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steffen Prohaska, git
In-Reply-To: <Pine.LNX.4.64.0709292149280.28395@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Sat, 29 Sep 2007, Steffen Prohaska wrote:
>
>> It is assumed that a matching version of the html documentation
>> is available as the HEAD of /doc/git/html/.git. If not an error
>> will be reported.
>>
>> This patch doesn't include a mechanism to fetch the html pages
>> to /doc/git/html/.git. You should manually clone them. Maybe
>> this could handled as a submodule of msysgit?
>
> I'd rather handle it as in git.git, as another branch, and not check it
> out in /git/html/, but rather use "git read-tree
> --prefix=/tmp/WinGit/share/git/html origin/html", or some such.
This is starting to smell like an opportunity to use the gitlink
stuff, isn't it?
^ permalink raw reply
* Re: Fix revision log diff setup, avoid unnecessary diff generation
From: Junio C Hamano @ 2007-09-29 22:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Pierre Habouzit, Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0709290932040.3579@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sat, 29 Sep 2007, Pierre Habouzit wrote:
>>
>> - if (strcmp(argv[i], "-z"))
>> - revs->diff = 1;
>> + revs->diff = strcmp(argv[i], "-z")
>> + && strcmp(argv[i], "--color")
>> + && strcmp(argv[i], "--no-color");
>
> The old code was already pretty damn ugly, the new code is worse (never
> mind the bug).
>
> I don't think we should care *at*all* about the actual argument string, we
> should just look at what the diffopts end up being at the end.
Thanks, I think this is the sanest thing to do.
^ permalink raw reply
* Re: [PATCH] rebase -i: support single-letter abbreviations for the actions
From: Junio C Hamano @ 2007-09-29 22:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Avi Kivity, gitster, git
In-Reply-To: <Pine.LNX.4.64.0709292243280.28395@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Sat, 29 Sep 2007, Avi Kivity wrote:
>
>> > > Can we make "amend" like squash, except that it keeps the first
>> > > commit's authorship instead of the second? I often merge a commit
>> > > with some minor fix that comes later, and usually want to keep the
>> > > original author record.
>
> Thinking about this again... Maybe it is a better semantics anyway? What
> do others think?
I never thought about whose commit the squashed ones become
before this thread, but making squash quack as if "commit
--amend" was done after running "cherry-pick -n" the second and
later ones feels like the most natural semantics to me.
^ permalink raw reply
* Re: Stashing untracked files
From: Johannes Schindelin @ 2007-09-29 22:00 UTC (permalink / raw)
To: Neil Macneale; +Cc: git, Benoit SIGOURE
In-Reply-To: <46FEC799.30803@theory.org>
Hi,
[please do not cull me from the Cc: list, especially if you quote me.]
On Sat, 29 Sep 2007, Neil Macneale wrote:
> Performing an add would require me to remove those file from the index
> at a later date in the event that I don't want to commit them on the
> next commit.
Wrong.
If you "git add <new-file>" and then "git stash", it will no longer have
the file in the index. Instead, the index will agree with the HEAD (which
does not have <new-file>).
Ciao,
Dscho
^ permalink raw reply
* Re: Stashing untracked files
From: Johannes Schindelin @ 2007-09-29 21:51 UTC (permalink / raw)
To: Benoit SIGOURE; +Cc: Neil Macneale, git
In-Reply-To: <EEE8F630-AE62-4425-96A0-239D54724DF4@lrde.epita.fr>
Hi,
On Sat, 29 Sep 2007, Benoit SIGOURE wrote:
> On Sep 29, 2007, at 11:03 PM, Johannes Schindelin wrote:
>
> > Instead this is what you _should_ do:
> >
> > git add <the files that you care about>
> > git stash
>
> You could stash untracked files that are not ignored (I personally
> ignore *.o, *.a and the like).
And what if you happen to forget to ignore that? Or if you happen to
have an strace log in some file (which you did not ignore either)?
Thanks, but I think the semantics of git stash is pretty well defined.
And it means that you stash away _tracked_ content that was not yet
committed.
I mean, you can have your desired behaviour with
$ git add .
$ git stash
but if we were to fulfil your wish and change the default behaviour, there
is no way back to the current behaviour (which I happen to find pretty
sane).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] rebase -i: support single-letter abbreviations for the actions
From: Johannes Schindelin @ 2007-09-29 21:48 UTC (permalink / raw)
To: Avi Kivity; +Cc: gitster, git
In-Reply-To: <46FEC00B.7050208@qumranet.com>
Hi,
On Sat, 29 Sep 2007, Avi Kivity wrote:
> > > Can we make "amend" like squash, except that it keeps the first
> > > commit's authorship instead of the second? I often merge a commit
> > > with some minor fix that comes later, and usually want to keep the
> > > original author record.
Thinking about this again... Maybe it is a better semantics anyway? What
do others think?
Ciao,
Dscho
^ permalink raw reply
* Re: Stashing untracked files
From: Neil Macneale @ 2007-09-29 21:46 UTC (permalink / raw)
To: git; +Cc: Benoit SIGOURE
In-Reply-To: <EEE8F630-AE62-4425-96A0-239D54724DF4@lrde.epita.fr>
Benoit SIGOURE wrote:
> On Sep 29, 2007, at 11:03 PM, Johannes Schindelin wrote:
>
>> Hi,
>>
>> On Sat, 29 Sep 2007, Neil Macneale wrote:
>>
>>> When using "git stash," in some cases I'd like to stash away files that
>>> are currently untracked. It seems to me like there should be a way to
>>> stash everything in a working directory so that the end result is a
>>> pristine tree. Then applying the stash will reinstate those file as
>>> untracked.
>>
>> Funny how the same ideas always come in packs: I had the same discussions
>> a few nights ago on IRC.
>>
>> Here is why I think it is _wrong_ to stash untracked files: this would
>> include *.o and *.a, as well as all those binary files, too.
>>
>> Instead this is what you _should_ do:
>>
>> git add <the files that you care about>
>> git stash
>
> You could stash untracked files that are not ignored (I personally
> ignore *.o, *.a and the like).
>
Yeah, I wouldn't want the ignored files. I'm interested in the files
listed as untracked when I run git status.
Performing an add would require me to remove those file from the index
at a later date in the event that I don't want to commit them on the
next commit.
In the case I'm dealing with right now, I working on content files
(html/perl). It's not uncommon for me to have files which are untracked
and will remain that way for an extended period of time (a few commits,
say). When I need to do a stash, I generally don't want those files
around afterward.
( Here is the full story. I'm using git to make my life working with
perforce a little less painful. It's not uncommon for me to jump to my
master branch to do a perforce sync. When I do that, I want all of my
changes in working branches stashed away. I selectively add new files on
each commit so that what is committed to the working branch syncs up
with what I end up submitting to perforce. And to make my life even more
difficult, my co-workers are not using git. So it's not uncommon for
someone to send me a file for my sandbox which I will never submit to
perforce because it's their job to do so. I can't tell you how many
times I've told them "this would be a lot easier if we all just used
git" but I digress... )
Thanks,
Neil
^ permalink raw reply
* Re: A tour of git: the basics (and notes on some unfriendly messages)
From: Steffen Prohaska @ 2007-09-29 21:48 UTC (permalink / raw)
To: Git Mailing List; +Cc: Carl Worth, Shawn O. Pearce
In-Reply-To: <20070929000056.GZ3099@spearce.org>
On Sep 29, 2007, at 2:00 AM, Shawn O. Pearce wrote:
>> * There's a ton of extraneous output from git-fetch. I would
>> love to
>> see it reduced to a single-line progress bar, (even if a
>> multiple-staged progress bar). I'm imagining a final line
>> something like:
>>
>> Computing (100%) Transferring (100%)
>>
>> But you can imagine more accurate words than those, (I'm not even
>> sure what all of the things mean that git-fetch is currently
>> reporting progress on).
>
> Yea. About half of that output is from pack-objects and either
> unpack-objects or index-pack. The other part is from git-fetch
> itself as it updates the local tracking branches (if any are to be
> updated). Now that git-fetch is in C and reasonably stable maybe
> I can look into making this prettier. Few people really grok the
> pack-objects/index-pack output, nor do they care. They just want
> to know two things:
>
> - Is git working or frozen in limbo?
> - Is git frozen because my network sucks, or git sucks?
> - When will this be done? Please $DIETY, I want to go home!
> Make the fetch finish!
>
> The C based git-fetch made the http protocol almost totally silent.
> (No more got/walk messages.) But that's actually also bad as it
> now doesn't even let you know its transferring anything at all.
>
> There are serious issues here about getting the user the progress
> they really want. The last item ("When will this be done?") is
> actually not possible to determine under either the native git
> protocol or HTTP/FTP. We have no idea up front how much data must
> be transferred. In the native git case we do know how many objects,
> but we don't know how many bytes that will be. It could be under
> a kilobyte in one project. That same object count for a different
> set of objects fetch could be 500M. Radically different transfer
> times would be required.
Often you know that you have a good connection and you are not
interested in any progress reporting at all. _No_ output would be
perfect. A return code of 0 would already tell you all you need
to know. If you'd like to know more you could pass something like
'--verbose' or '--progress'.
Quite often git prints a lot of very technical information that
is not very interesting as long as things succeed without error.
Some examples are
- git fetch (see above)
- git rebase: prints a lot of details that I'm not interested in
unless the rebase fails.
- git push: prints updates of remote heads. A message about
failing to update a remote head may get lost.
- git merge: the fact that a merge is a fast forward merge gets
printed at the very top, followed by (often a lot of) diffstat.
I know diffstat can help to judge if the merge did what you
expected. But even more important is the fact that the merge
was just a fast forward, which may get buried under lots of output.
Maybe git should become more quiet, as other unix tools are, and
per default only report problems. Technical details and progress
could be requested explicitly by '--verbose' or similar. We could
pipe all the technical output to a per-repository logfile, which
can be consulted in case of errors. The log could be cropped
during 'git gc'.
Steffen
^ permalink raw reply
* Re: [PATCH] rebase -i: support single-letter abbreviations for the actions
From: Avi Kivity @ 2007-09-29 21:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: gitster, git
In-Reply-To: <Pine.LNX.4.64.0709292156090.28395@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Sat, 29 Sep 2007, Avi Kivity wrote:
>
>
>> Johannes Schindelin wrote:
>>
>>> When you do many rebases, you can get annoyed by having to type out
>>> the actions "edit" or "squash" in total.
>>>
>>> This commit helps that, by allowing you to enter "e" instead of
>>> "edit", or "s" instead of "squash", and it also plays nice with
>>> "merge" or "amend" as synonyms to "squash".
>>>
>> Can we make "amend" like squash, except that it keeps the first commit's
>> authorship instead of the second? I often merge a commit with some
>> minor fix that comes later, and usually want to keep the original author
>> record.
>>
>
> I do not necessarily think it is not doable, but I have different
> suggestion to you:
>
> If you amend the commit with a minor fix that comes later, why not do
> "rebase -i" _before_ applying the fix, and then using "edit" on the
> respective commit?
>
This is what I do now. Edit the commit, cherry-pick -n, and commit
--amend. But it's less pleasant than using the rebase --interactive
interface.
[This is part of the workflow to prepare a patchset for submitting
upstream; I don't edit commits on my master branch]
> That way you can even test the result easily, which you cannot do with
> "squash".
>
Usually these are trivial fixes, and have already been tested by being
included in my main branch.
--
Any sufficiently difficult bug is indistinguishable from a feature.
^ permalink raw reply
* Re: Stashing untracked files
From: Benoit SIGOURE @ 2007-09-29 21:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Neil Macneale, git
In-Reply-To: <Pine.LNX.4.64.0709292201400.28395@racer.site>
[-- Attachment #1: Type: text/plain, Size: 941 bytes --]
On Sep 29, 2007, at 11:03 PM, Johannes Schindelin wrote:
> Hi,
>
> On Sat, 29 Sep 2007, Neil Macneale wrote:
>
>> When using "git stash," in some cases I'd like to stash away files
>> that
>> are currently untracked. It seems to me like there should be a way to
>> stash everything in a working directory so that the end result is a
>> pristine tree. Then applying the stash will reinstate those file as
>> untracked.
>
> Funny how the same ideas always come in packs: I had the same
> discussions
> a few nights ago on IRC.
>
> Here is why I think it is _wrong_ to stash untracked files: this would
> include *.o and *.a, as well as all those binary files, too.
>
> Instead this is what you _should_ do:
>
> git add <the files that you care about>
> git stash
You could stash untracked files that are not ignored (I personally
ignore *.o, *.a and the like).
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: Stashing untracked files
From: Johannes Schindelin @ 2007-09-29 21:03 UTC (permalink / raw)
To: Neil Macneale; +Cc: git
In-Reply-To: <46FE9924.7080006@theory.org>
Hi,
On Sat, 29 Sep 2007, Neil Macneale wrote:
> When using "git stash," in some cases I'd like to stash away files that
> are currently untracked. It seems to me like there should be a way to
> stash everything in a working directory so that the end result is a
> pristine tree. Then applying the stash will reinstate those file as
> untracked.
Funny how the same ideas always come in packs: I had the same discussions
a few nights ago on IRC.
Here is why I think it is _wrong_ to stash untracked files: this would
include *.o and *.a, as well as all those binary files, too.
Instead this is what you _should_ do:
git add <the files that you care about>
git stash
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] rebase -i: support single-letter abbreviations for the actions
From: Johannes Schindelin @ 2007-09-29 20:58 UTC (permalink / raw)
To: Avi Kivity; +Cc: gitster, git
In-Reply-To: <46FE7D0B.4060806@qumranet.com>
Hi,
On Sat, 29 Sep 2007, Avi Kivity wrote:
> Johannes Schindelin wrote:
> > When you do many rebases, you can get annoyed by having to type out
> > the actions "edit" or "squash" in total.
> >
> > This commit helps that, by allowing you to enter "e" instead of
> > "edit", or "s" instead of "squash", and it also plays nice with
> > "merge" or "amend" as synonyms to "squash".
>
> Can we make "amend" like squash, except that it keeps the first commit's
> authorship instead of the second? I often merge a commit with some
> minor fix that comes later, and usually want to keep the original author
> record.
I do not necessarily think it is not doable, but I have different
suggestion to you:
If you amend the commit with a minor fix that comes later, why not do
"rebase -i" _before_ applying the fix, and then using "edit" on the
respective commit?
That way you can even test the result easily, which you cannot do with
"squash".
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] WinGit: include html pages from official git.git's html branch
From: Johannes Schindelin @ 2007-09-29 20:50 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <11910819542185-git-send-email-prohaska@zib.de>
Hi,
On Sat, 29 Sep 2007, Steffen Prohaska wrote:
> It is assumed that a matching version of the html documentation
> is available as the HEAD of /doc/git/html/.git. If not an error
> will be reported.
>
> This patch doesn't include a mechanism to fetch the html pages
> to /doc/git/html/.git. You should manually clone them. Maybe
> this could handled as a submodule of msysgit?
I'd rather handle it as in git.git, as another branch, and not check it
out in /git/html/, but rather use "git read-tree
--prefix=/tmp/WinGit/share/git/html origin/html", or some such.
Ciao,
Dscho
^ permalink raw reply
* Submodule idea
From: Daniel Barkalow @ 2007-09-29 19:04 UTC (permalink / raw)
To: git
I *think* that it would be a great benefit if "git submodule update" would
leave you on a branch if (a) you were on that branch before, and (b)
pulling on that branch would update it to the commit that the superproject
specifies for that submodule.
Or maybe there should be a "git submodule fetch" which fetches from the
remote, and replaces FETCH_HEAD with the superproject's index entry, and
"git submodule pull" would merge it? (With the model being that the entry
in the superproject is an additional remote that you both track and
publish to)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Submodule usability
From: Daniel Barkalow @ 2007-09-29 19:02 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: git
In-Reply-To: <20070929185238.GB19943@uranus.ravnborg.org>
On Sat, 29 Sep 2007, Sam Ravnborg wrote:
> Hi Daniel
> On Sat, Sep 29, 2007 at 01:24:53PM -0400, Daniel Barkalow wrote:
> >
> > Also, would it be reasonable to have a gitmodules option for submodules
> > that the supermodule doesn't make sense without? E.g., multiple projects
> > are now using kbuild as their build system,
>
> Out of couriosity...
> I know of busybox and klibc.
> Are there any others using kbuild these days?
>
> I see that several build system share some ideas with kbuild
> which I btw am glad to see.
> But if there are enough project taking benefit of kbuild I should
> maybe revisit my idea to factor out all the common stuff somehow.
I'm only sure of busybox and klibc (3 including the kernel is "multiple"),
but IIRC a number of linux-specific userspace projects seem awfully
similar. I wouldn't be surprised if the build systems that currently share
only ideas would share code if it were factored out.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Stashing untracked files
From: Neil Macneale @ 2007-09-29 18:27 UTC (permalink / raw)
To: git
Hi All,
I'm new to git, and I have a question regarding the best way to do
something.
When using "git stash," in some cases I'd like to stash away files that
are currently untracked. It seems to me like there should be a way to
stash everything in a working directory so that the end result is a
pristine tree. Then applying the stash will reinstate those file as
untracked.
I understand that is not always desired, but sometimes it is (for me
anyway). Perhaps an option like "git stash -u" could provide this behavior?
Is there some other approach that makes more sense? I don't want to
start looking into this until I have some idea if this is a sane idea :-)
Thanks,
Neil
^ permalink raw reply
* Re: Submodule usability
From: Sam Ravnborg @ 2007-09-29 18:52 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0709291302240.5926@iabervon.org>
Hi Daniel
On Sat, Sep 29, 2007 at 01:24:53PM -0400, Daniel Barkalow wrote:
>
> Also, would it be reasonable to have a gitmodules option for submodules
> that the supermodule doesn't make sense without? E.g., multiple projects
> are now using kbuild as their build system,
Out of couriosity...
I know of busybox and klibc.
Are there any others using kbuild these days?
I see that several build system share some ideas with kbuild
which I btw am glad to see.
But if there are enough project taking benefit of kbuild I should
maybe revisit my idea to factor out all the common stuff somehow.
Sam
^ permalink raw reply
* Re: [PATCH 2/2] Replace literal STRLEN_ #defines in refs.h with compiler evaluated expressions
From: Linus Torvalds @ 2007-09-29 18:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andy Parkins, git
In-Reply-To: <7vd4w1l872.fsf@gitster.siamese.dyndns.org>
On Sat, 29 Sep 2007, Junio C Hamano wrote:
>
> I do not think the above is wrong per se, but doesn't a good
> compiler optimize
>
> #define PATH_REMOTES "remotes/"
> #define STRLEN_PATH_REMOTES strlen(PATH_REMOTES)
Gcc does, yes.
HOWEVER.
Using "strlen()" may be optimized at compile-time, but it still ends up
resulting in illegal C code if the constant needs to be a constant in the
semantic sense.
IOW, the "sizeof()" trick can be portably used for things like array
declarations etc. But strlen() cannot. Ie
char array[sizeof("hello")-1];
is legal in non-function scope, but doing the same with "strlen()" is not.
(That said, gcc has been known to accept bad C code, and will in fact
accept this one too!)
Linus
^ permalink raw reply
* BUG: git remote show origin => error code 1
From: Jari Aalto @ 2007-09-29 18:13 UTC (permalink / raw)
To: git
Consider this:
$ git remote show origin
No such remote origin
$ echo $?
0
Perhaps the code should return non-zero in this case, so that shell
scripts could use construct:
git remote show origin; || <another action>
Jari
--
Welcome to FOSS revolution: we fix and modify until it shines
^ permalink raw reply
* Submodule usability
From: Daniel Barkalow @ 2007-09-29 17:24 UTC (permalink / raw)
To: git
Would it be feasible in general to have "git status" cascade into
submodules if they're checked out? As it is now, in a project with
submodules, a "git commit -a" at the top can create a commit that lacks
changes that are in the working tree and aren't mentioned to the user at
all, which is a sure recipe for a stream of "add the change I forgot to
add last time" follow-up commits.
While I'm on that topic, I think I want an "includesfile" config option
that specifies patterns that should never be present untracked (but only
as per-user configuration, since I think that's exclusively a matter of
personal taste). I'll probably code this up myself unless I've missed
somebody else doing it already. My first guess at effect is -a adds them,
and they appear as "not added" in the "modified" section of status output
instead of the "untracked" section.
Also, would it be reasonable to have a gitmodules option for submodules
that the supermodule doesn't make sense without? E.g., multiple projects
are now using kbuild as their build system, so, in order to share
improvements to kbuild between projects, it would be useful to have it as
a submodule. But, by default, the kernel wouldn't come with its build
system any more, which would be a pain. So have a tracked option for the
submodule that says that, when checking out the superproject, this
particular subproject should be updated automatically.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 1/1] --color and --no-color git-log options don't need diffs to be computed.
From: Junio C Hamano @ 2007-09-29 17:02 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <20070929123724.01BB045EC@madism.org>
Pierre Habouzit <madcoder@debian.org> writes:
> Signed-off-by: Pierre Habouzit <madcoder@debian.org>
> ---
>
> revision.c | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/revision.c b/revision.c
> index 33d092c..0dee835 100644
> --- a/revision.c
> +++ b/revision.c
> @@ -1209,8 +1209,9 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
>
> opts = diff_opt_parse(&revs->diffopt, argv+i, argc-i);
> if (opts > 0) {
> - if (strcmp(argv[i], "-z"))
> - revs->diff = 1;
> + revs->diff = strcmp(argv[i], "-z")
> + && strcmp(argv[i], "--color")
> + && strcmp(argv[i], "--no-color");
> i += opts - 1;
> continue;
> }
Aside from the "don't override the option that is already set"
comment from David, I am somewhat unhappy that this piece
already knows too much about which option to diff potentially
changes the output (but not commits us to produce the diff) and
which option causes us to actually produce output.
^ permalink raw reply
* Re: [PATCH 2/2] Replace literal STRLEN_ #defines in refs.h with compiler evaluated expressions
From: Junio C Hamano @ 2007-09-29 16:58 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200709291400.13880.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> Bill Lear pointed out that the following:
>
> #define PATH_REMOTES "remotes/"
> #define STRLEN_PATH_REMOTES 8
>
> Could be replaced by the less error-prone
>
> #define PATH_REMOTES "remotes/"
> #define LIT_STRLEN(S) ((sizeof(S) / sizeof(S[0])) -1)
> #define STRLEN_PATH_REMOTES LIT_STRLEN(PATH_REMOTES)
>
> which is what this patch does.
I do not think the above is wrong per se, but doesn't a good
compiler optimize
#define PATH_REMOTES "remotes/"
#define STRLEN_PATH_REMOTES strlen(PATH_REMOTES)
... and much later in some *.c file that includes the
... above and <string.h>
foo = strlen(PATH_REMOTES)
anyway?
^ permalink raw reply
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