Paul Mackerras <[EMAIL PROTECTED]> writes:
> My reasoning is that it is the local short-range connections which are
> interesting and informative. The long-range connections aren't really
> visually informative; if you want to know about the long-range
> connections, the parent and child lists in
I track a CVS project which has a branch with a '/' in the branch name.
Since git wants the branch name to be a file name at the same time,
translate that character to a '-'. This should work well, despite the
fact that a division and a difference are completely different :-)
Signed-off-by: Johann
On 8/17/05, Dave Jones <[EMAIL PROTECTED]> wrote:
> In my case, at least the most recent of those cvs tag operations
> was just a 'cvs tag x86info-1_14'. Nothing fancy. I'm fairly sure
> there was nothing fancy about the earlier instance either.
> So sure in fact, I had to look up that -F flag in
Yes, using the same format for the file and the environment variable
was a big mistake. This uses LF as the path separator, and allows
lines that begin with '#' to be comments. ':' is no longer a separator
in objects/info/alternates file.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
s
This is a companion patch to the previous format-patch fix.
With "-k", format-patch can be told not to remove the [PATCH] in
the original commit, nor to add the [PATCH] on its own.
However, applymbox toolchain has a code to remove [PATCH] (among
other things) from the Subject: line, which is the r
When running "git commit" with explicit path arguments, allow it to
take directory name. This makes "git commit Documentation/" to commit
everything that is changed under Documentation/ directory.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
git-commit-script | 11 ---
1 file
This lets you say "git show-branches --max-count=30".
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
And this is how --symbolic is used to pick out the named rev
parameters.
git-show-branches-script | 24
1 files changed, 16 insertions(+), 8 deletions(-
This is most useful with --all, --revs-only, --no-flags and --verify.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
With this, "git-rev-parse --symbolic master pu" would output
"master pu". Why would this be useful? The next one uses it.
rev-parse.c | 30 ++--
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Tue, 16 Aug 2005, Junio C Hamano wrote:
>>
>> Merged, pushed out, and tested. Ouch. Fails on t test.
>
> It's because the new git-diff-files expects there to be a valid readable
> .git/HEAD, and is unhappy since the test hasn't updated HEAD.
Hello!
Tag names don't work with current cogito because commit-id and tree-id
don't parse the cg-Xnormid output properly.
Namely, if $type is empty (which is the case for tags), $normid is used
before the trailing space is stripped from it.
Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
diff -
On Tue, 16 Aug 2005, Linus Torvalds wrote:
>
> This fixes up usage of ".." (without an ending slash) and "." (with or
> without the ending slash) in the git diff family.
Btw, if it wasn't clear, with this patch you can now do
git diff .
and it will show the diffs for everything under
This fixes up usage of ".." (without an ending slash) and "." (with or
without the ending slash) in the git diff family.
It also fixes pathspec matching for the case of an empty pathspec, since a
"." in the top-level directory (or enough ".." under subdirectories) will
result in an empty paths
Hello!
cg-diff reports error when comparing identical trees. It's not as
useless as it may seem. For example, I make local changes, e-mail them
upstream and then get them back via cg-update with minor changes. I
revert the minor differences between master and origin. Here's what I
get when I w
On Wed, 17 Aug 2005, Paul Mackerras wrote:
>
> I would like to get some feedback about what people think of the
> visual effect of this new approach, and in particular whether having
> the lines jump into hyperspace loses information that people find
> useful.
Me likee. Maybe some knob to tune
The _remote_name variable used for messages does not need the
refs/heads/ prefix included.
Signed-off-by: Kris Shannon <[EMAIL PROTECTED]>
---
git-parse-remote |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
9e7a4358b1792be188df87debf564e46acdb39d4
diff --git a/git-parse-remote b/gi
On Tue, 16 Aug 2005, Junio C Hamano wrote:
>
> Merged, pushed out, and tested. Ouch. Fails on t test.
It's because the new git-diff-files expects there to be a valid readable
.git/HEAD, and is unhappy since the test hasn't updated HEAD.
This trivial patch fixes it.
Linu
On Wed, Aug 17, 2005 at 12:55:18PM +1200, Martin Langhoff wrote:
> On 8/17/05, Dave Jones <[EMAIL PROTECTED]> wrote:
> > I've no idea what I did when I tagged those trees, but according
> > to a google search, cvsps does that when it find patchsets which
> > are chronologically (and thus by pat
On Sun, 2005-08-14 at 22:12 -0700, Junio C Hamano wrote:
> I would like to know
> a use case or two to illustrate why there are symlinks pointing
> at real files outside .git/refs/ hierarchy, and how that
> arrangement is useful.
I've clearly laid out my case very badly.
Here is the patch via sed
Linus Torvalds <[EMAIL PROTECTED]> writes:
> Mostly done. It actually works from inside subdirectories, but "." at the
> top-level is still not done. Small detail. Will fix later. But it would
> help if you would apply this, since I'm going to be off for dinner..
Merged, pushed out, and tested.
On Tue, 16 Aug 2005, Junio C Hamano wrote:
>
> The developement history would look nicer if you did the latter,
> but I am easy and can go either way.
Here is.
> > I'd do at least the "git-diff-tree" part and the "./" and "../" handling,
> > and convert at least the "git diff" thing to the new
On 8/17/05, Dave Jones <[EMAIL PROTECTED]> wrote:
> I've no idea what I did when I tagged those trees, but according
> to a google search, cvsps does that when it find patchsets which
> are chronologically (and thus by patchset id) earlier than the tag,
> but are tagwise after. Spooky.
It's proba
Wolfgang Denk <[EMAIL PROTECTED]> writes:
> external diff died, stopping at common/cmd_nand.c.
> Some commits could not be rebased, check by hand:
> 67a002cbe2b2850d76d797e679bc290a7df6
>
> OK, I can edit the file to resolve the conflicts. But what do I do
> then to contin
On Tue, 16 Aug 2005, Linus Torvalds wrote:
> If you use the GIT_DIR environment variable approach, it assumes that all
> filenames you give it are absolute and acts the way it always did before.
>
> Comments? Like? Dislike?
I'm all in favor, at least in the general case. I suspect there'll be som
I have been trying a new approach to drawing the commit graph in gitk.
This involves sending a lot of the really long lines into
"hyperspace", by terminating them with an arrow pointing down when the
graph gets too wide, and then reintroducing them later with an arrow
pointing up, as though they ha
Linus Torvalds <[EMAIL PROTECTED]> writes:
> Do you want to take the current patch (which buys you very little because
> not a lot of stuff has been set up to deal with it, but is the basis for
> all future work anyway) or do you want me to polish it up a bit and
> re-submit the whole thing?
T
Hello,
in message <[EMAIL PROTECTED]> you wrote:
>
> This is the kind of situation I used to have all the time when
> Linus was the maintainer and I was a contributor, when you look
> at "master" branch being the "maintainer" branch, and "pu"
> branch being the "contributor" branch. Your work st
On Tue, 16 Aug 2005, Junio C Hamano wrote:
>
> Comments: Wouldn't that mean git-*-scripts would not benefit from this
> because git-sh-setup would set GIT_DIR for you even if
> you don't?
As it stands now, yes. But the point being that if people like this, then
I'll just ch
Linus Torvalds <[EMAIL PROTECTED]> writes:
> If you use the GIT_DIR environment variable approach, it assumes that all
> filenames you give it are absolute and acts the way it always did before.
> Comments? Like? Dislike?
Comments: Wouldn't that mean git-*-scripts would not benefit from this
At Mon, 15 Aug 2005 15:43:26 -0700 (PDT),
Linus Torvalds wrote:
>
> On Tue, 16 Aug 2005, Yasushi SHOJI wrote:
> >
> > > Instead of disabling it entirely, how about just having some limit on it?
> >
> > ah, that's a good idea. here is a quick and dirty patch.
>
> This makes it somewhat more expe
At Tue, 16 Aug 2005 15:45:35 -0700 (PDT),
Linus Torvalds wrote:
>
> This is really partly a serious patch, but also just a query whether
> people would want git to work in subdirectories, not just the top-level
> directory.
>
> So you can be in linux/drivers, and if you do a
>
> git-diff
On Tue, Aug 16, 2005 at 02:09:08PM -0700, Junio C Hamano wrote:
> And presumably you have .git/branches/myremotebranch file that
> says something like "master.kernel.org:/pub/scm/git/git.git".
> Or should the last line of relationships file be spelled just
> push:master:ko-master?
Oops, I did inte
This does only "git-diff-cache" and "git-diff-files", but the concept
should work for any command that uses the working tree.
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
---
This is really partly a serious patch, but also just a query whether
people would want git to work in subdirecto
I just tried a cvs->git conversion using the git-cvsimport-script
and cvsps flagged a bunch of tags as **FUNKY**
I've no idea what I did when I tagged those trees, but according
to a google search, cvsps does that when it find patchsets which
are chronologically (and thus by patchset id) earlier t
On Tue, 16 Aug 2005, Marco Costalba wrote:
> Martin Langhoff wrote:
>
> >>From what I understand, you'll want the StGIT infrastructure. If you
> >use git/cogito, there is an underlying assumption that you'll want
> >all the patches merged across, and a simple cg-update will bring in
> >all the pe
Introduces --keep-subjects flag to tell it not to munge the
first line of the commit message. Running "git applymbox" on
the output from "git format-patch -m -k" would preserve the
original commit information better this way.
At the same time, prefix Subject: on the first line of the
commit, to h
Martin Langhoff wrote:
>>From what I understand, you'll want the StGIT infrastructure. If you
>use git/cogito, there is an underlying assumption that you'll want
>all the patches merged across, and a simple cg-update will bring in
>all the pending stuff.
>
My concerns are both metodologicals and
On Tue, 16 Aug 2005, Junio C Hamano wrote:
> Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> > We've got a "git prune-packed", it would be good to have a "git
> > prune-alternate" or something equivalent.
>
> If you have GIT_ALTERNATE_DIRECTORIES environment variable, git
> prune-packed will rem
Linus Torvalds <[EMAIL PROTECTED]> writes:
> We've got a "git prune-packed", it would be good to have a "git
> prune-alternate" or something equivalent.
If you have GIT_ALTERNATE_DIRECTORIES environment variable, git
prune-packed will remove objects from your repository if it is
found in somebody
Junio C Hamano wrote:
>
>I would like to know a bit about "git format-patch" adding extra
>info that you needed to get rid of. It shouldn't be necessary.
>
As example, in the rev d5a63b99835017d2638e55a7e34a35a3c1e80f1f from git
the original subject is:
' Alternate object pool mechanism updat
On 8/16/05, Sven Verdoolaege <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 16, 2005 at 10:35:27PM +1200, Martin Langhoff wrote:
> > +
> > +sub get_headref($$) {
>
> If you want to check whether a ref is valid, then
> it is better to use git-rev-parse...
We are reading/writing directly to .git/refs/hea
On 8/17/05, Marco Costalba <[EMAIL PROTECTED]> wrote:
> What do you think?
>From what I understand, you'll want the StGIT infrastructure. If you
use git/cogito, there is an underlying assumption that you'll want
all the patches merged across, and a simple cg-update will bring in
all the pending s
Hello!
cg-admin-cat ignores the argument for the "-r" option because it uses
optparse incorrectly. For OPTARG to be set, "-r=" should be used
instead of "-r".
Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
diff --git a/cg-admin-cat b/cg-admin-cat
--- a/cg-admin-cat
+++ b/cg-admin-cat
@@ -27,7
Carl Baldwin <[EMAIL PROTECTED]> writes:
> If I may, let me give an example of something I think could serve the
> purpose a little more simply and generically.
>
> Let's say I start with the following:
> % ls .git/refs/heads
> master
> mylocalbranch
> myremotebranch
> ko-master
> % cat .git/branc
Kalle Valo <[EMAIL PROTECTED]> writes:
> If no argument provided to `git branch`, show available branches and
> mark current branch with star.
I like the general direction, but this particular implementation
may be a bit troublesome.
> +if [ -z "$branchname" ]; then
> +current=$(basename $(r
Marco Costalba <[EMAIL PROTECTED]> writes:
> It is just a very thin layer above the two git scripts, the only extra work
> is the cleaning up of some info that git-format-patch-script automatically
> adds,
> so that the new commits look like the originals (i.e. same header and
> description).
Hi,
On Tue, 16 Aug 2005, Carl Baldwin wrote:
> So, just a question. What, exactly, is meant by 'cross-pulling'?
When I say "cross-pulling" I mean that a branch is pulled from a remote
repository, where the named head is called "a", but that reference is
pulled into the local branch whose head
Hi,
On Tue, 16 Aug 2005, Horst von Brand wrote:
> And teach make(1) about checking out files from git... or just create a
> co(1) command for git.
How about "git-checkout-script", optionally with the "-f" flag to ignore
changes since the last checkout/checkin?
Ciao,
Dscho
-
To unsubscribe fro
Hi,
On Tue, 16 Aug 2005, Marco Costalba wrote:
> Suppose a possible scenario involves using a couple of git archives, one
> for releases and stable code, say MAIN, and one for experimental stuff
> or new development, say HEAD.
>
> Suppose there is stuff in HEAD you don't want merged in MAIN,
Linus Torvalds <[EMAIL PROTECTED]> writes:
> Btw, looking at the code, it strikes me that using ":" to separate the
> alternate object directories in the file is rather strange.
Yes, I admit it one was done in a quick and dirty way. Patches
welcome [*1*] ;-)
> Anyway, I don't think "alternates
Hi,
I would like to ask the list about something I'am thinking about,
and I'am not sure it's a good idea.
Suppose a possible scenario involves using a couple of git archives, one
for releases and stable code, say MAIN, and one for experimental stuff
or new development, say HEAD.
Suppose there
Junio C Hamano <[EMAIL PROTECTED]> wrote:
[...]
> - Oh, another itch I did not list in the previous message. Is
> anybody interested in doing an Emacs VC back-end for GIT?
And teach make(1) about checking out files from git... or just create a
co(1) command for git.
--
Dr. Horst H. von Brand
On Tue, 16 Aug 2005, Linus Torvalds wrote:
> Finally, I have to say that that "info" directory is confusing. Namely,
> there's two of them - the "git info" and the "object info" directories are
> totally different directories - maybe logical, but to me it smells like
> "info" is here a code-name f
On Sun, 14 Aug 2005, Junio C Hamano wrote:
> Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> > I think this is great - especially for places like kernel.org, where a lot
> > of repos end up being related to each other, yet independent.
>
> Yes. There is one shortcoming in the current git-clon
My bug. Thanks.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please pull from:
rsync.kernel.org://pub/scm/linux/kernel/git/chrisw/git
This will give you the following trivial fix for the rpm build, where
tools was still using dest not DESTDIR.
thanks,
-chris
--
diff-tree 5eaaed02111510ff00b288a99ec3d203d5d1761f (from
d9ac9df41c8c1c3a2f5b0fb1bcc05
If no argument provided to `git branch`, show available branches and
mark current branch with star.
This is based on patch written by Amos Waterland <[EMAIL PROTECTED]>.
Signed-off-by: Kalle Valo <[EMAIL PROTECTED]>
---
git-branch-script |8 +++-
1 files changed, 7 insertions(+), 1 dele
Amos Waterland <[EMAIL PROTECTED]> writes:
> For people whose workflow involves switching back and forth between a
> lot of branches, it can be really helpful to be able to quickly tell
> which branch you are on and which ones are available. This patch
> introduces a small script that when invoke
On Mon, Aug 15, 2005 at 05:18:43PM -0700, Junio C Hamano wrote:
> If you are referring to what I said about the user having some
> control over both ends hence it should be possible to arrange to
> use the same name on both ends to reduce mental burden, Pasky
> and others convinced me otherwise dur
On Tue, 2005-08-16 at 23:26 +1200, Martin Langhoff wrote:
> I haven't seen this problem myself. There are some recent patches
> Junio merged that handle some oddities better. Give the 'pu' branch a
> go if you can.
I'll look at that in a bit. I already picked up a few of the patches
mentioned on t
On Tue, Aug 16, 2005 at 12:49:33AM +0200, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 15 Aug 2005, Carl Baldwin wrote:
>
> > Somewhere in the thread something was mentioned about maintaining
> > : pairs in the git repository when pushes
> > and pulls are performed. I think the argument was actu
On Tue, 16 Aug 2005, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 16 Aug 2005, Junio C Hamano wrote:
>
> > - Are all the files in Documentation/ reachable from git(7)
> > or otherwise made into a standalone document using asciidoc
> > by the Makefile? I haven't looked into documentation
On Tue, 16 Aug 2005, Junio C Hamano wrote:
> Daniel Barkalow <[EMAIL PROTECTED]> writes:
>
> > It might be worth putting the list of things left to do before 1.0 in the
> > tree (since they clearly covary), and it would be useful to know what
> > you're thinking of as preventing the release at any
Hi,
On Tue, 16 Aug 2005, Junio C Hamano wrote:
> - Are all the files in Documentation/ reachable from git(7)
> or otherwise made into a standalone document using asciidoc
> by the Makefile? I haven't looked into documentation
> generation myself (I use only the text files as they a
Johannes Schindelin wrote:
> Hi,
>
> On Mon, 15 Aug 2005, Junio C Hamano wrote:
>
>>Johannes Schindelin <[EMAIL PROTECTED]> writes:
>>
>>>Maybe we should enhance git-applymbox to detect whitespace corruption in
>>>particular, and output the User-Agent header (or if that does not
>>>exist, the M
On Tue, 2005-08-16 at 14:16 +0200, David Kågedal wrote:
> Alex Bennee <[EMAIL PROTECTED]> writes:
>
> > Before the import script finally dies with:
> >
> > WARNING: revision 1.3.2.1 of file
> > scripts/xmltools/t/data/gzip/DO-NOT-BACKUP on unnamed branch
> > DONE; creating master branch
> > cp: ca
Alex Bennee <[EMAIL PROTECTED]> writes:
> Before the import script finally dies with:
>
> WARNING: revision 1.3.2.1 of file
> scripts/xmltools/t/data/gzip/DO-NOT-BACKUP on unnamed branch
> DONE; creating master branch
> cp: cannot stat `/export/test/cvstogit/.git/refs/heads/origin': No such
> file
On 8/16/05, Junio C Hamano <[EMAIL PROTECTED]> wrote:
> However, the -kk change one is a corrupted patch and does not
> apply. Your MUA ate leading whitespaces, perhaps.
I stupidly did a forward. Rebased to your current pu branch and sent.
>From now on I'll be sending straight from cmdline.
> I
I haven't seen this problem myself. There are some recent patches
Junio merged that handle some oddities better. Give the 'pu' branch a
go if you can.
I take it that the repo is not public. I'd like to try and reproduce
the problem. Can you get it to happen with a public repository?
For debugging
On Tue, Aug 16, 2005 at 10:35:27PM +1200, Martin Langhoff wrote:
> +
> +sub get_headref($$) {
If you want to check whether a ref is valid, then
it is better to use git-rev-parse...
> +my $name= shift;
> +my $git_dir = shift;
> +my $sha;
> +
> +if (open(C,"$git_dir/refs/he
Hi,
We've been having issues with CVS for some time and I thought I'd give
git a spin. To do some like-for-like tests I'm having a go at importing
our cvs repository into git so I can do some benchmarks on things like
branch creation as well as play around with the visualisation tools.
Obviously
[PATCH] Add merge detection to git-cvsimport
Added -m and -M flags for git-cvsimport to detect merge commits in cvs.
While this trusts the commit message, in repositories where merge commits
indicate 'merged from FOOBRANCH' the import works surprisingly well.
Even if some merges from CVS are bogu
Hi,
Is there any guide or advise for deploy git server ? Especially
http/https/ssh server.
How do I set repository permissions correctly?
cauchy
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kern
Hi,
Is there any guide or advise for deploy git server ?
How do I set repository permissions correctly?
cauchy
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi,
On Tue, 16 Aug 2005, Junio C Hamano wrote:
> - Glossary documentation Johannes Schindelin is working on.
Yeah, yeah. Call _me_ lazy :-) I'll try to come up with a discussable item
today.
> - git prune and git fsck-cache; think about their interactions
> with an object database that bor
Daniel Barkalow <[EMAIL PROTECTED]> writes:
> It might be worth putting the list of things left to do before 1.0 in the
> tree (since they clearly covary), and it would be useful to know what
> you're thinking of as preventing the release at any particular stage.
Yeah, yeah. Call me lazy.
Exc
75 matches
Mail list logo
