* [PATCH] teaching git-add--interactive to accept a file param
From: Wincent Colaiuta @ 2007-11-21 12:36 UTC (permalink / raw)
To: git; +Cc: gitster
Back in October a thread came up, "Proposed git mv behavioral change",
and I inadvertently suggested a new feature for git-add--interactive;
the ability to supply an optional file path parameter and jump straight
to the "patch" subcommand for that file:
<http://kerneltrap.org/mailarchive/git/2007/10/19/348229>
This small patch series implements that suggestion:
Refactor patch_update_cmd
Teach git-add--interactive to accept a file path to patch
Teach builtin-add to pass a path argument to git-add--interactive
Document optional file parameter to git-add--interactive
It applies against the current master. I've not yet submitted many
patches to Git, so please be gentle!
Documentation/git-add.txt | 5 ++++-
builtin-add.c | 16 ++++++++++------
commit.h | 2 +-
git-add--interactive.perl | 11 +++++++++--
4 files changed, 24 insertions(+), 10 deletions(-)
^ permalink raw reply
* [PATCH 2/4] Teach git-add--interactive to accept a file path to patch
From: Wincent Colaiuta @ 2007-11-21 12:36 UTC (permalink / raw)
To: git; +Cc: gitster, Wincent Colaiuta
In-Reply-To: <1195648601-21736-2-git-send-email-win@wincent.com>
If supplied a single file path parameter the git-add--interactive script
now bypasses the command loop and jumps straight to the patch subcommand
using the passed path. After returning from the subcommand the main
command loop is entered. If a non-resolvable path is supplied the
operation is a no-op and the command loop is entered.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
---
git-add--interactive.perl | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index fb1e92a..8f21c03 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -803,6 +803,11 @@ sub main_loop {
}
}
+die "add --interactive may take only 1 optional parameter" if ($#ARGV > 0);
refresh();
+if ($#ARGV == 0) {
+ patch_update_file($ARGV[0]);
+}
status_cmd();
main_loop();
+
--
1.5.3.5.737.gdee1b
^ permalink raw reply related
* Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'
From: Geert Bosch @ 2007-11-21 12:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0711210336210.27959@racer.site>
On Nov 20, 2007, at 22:40, Johannes Schindelin wrote:
> Oh, and it relies on "int" being castable to void * and vice
> versa. Is anybody aware of a platform where this can lead to
> problems?
Like any 64-bit system? int is 32 bit and void * is 64.
So, casting a pointer to an int drops half the bits.
When you convert it back it will point to a funny place...
-Geert
^ permalink raw reply
* Re: Using Filemerge.app as a git-diff viewer
From: Wincent Colaiuta @ 2007-11-21 12:59 UTC (permalink / raw)
To: Jeff King; +Cc: Toby White, git
In-Reply-To: <20071121112757.GA17231@sigill.intra.peff.net>
El 21/11/2007, a las 12:27, Jeff King escribió:
> On Wed, Nov 21, 2007 at 10:31:46AM +0000, Toby White wrote:
>
>> So I wrote a quick script (below) which does what I need. Of all
>> the available git-diff flags, it only understands "--cached", and
>> up to two commit objects, and no paths, but that's enough for me.
>> Within those constraints, it has the same semantics as git-diff.
>
> Have you looked at the documentation for GIT_EXTERNAL_DIFF (try
> git(7))?
> I think it is a cleaner way of doing what you want (although I think
> you
> will get each file diffed individually, which is perhaps not what you
> want).
>
> Something like:
>
> $ cat >merge.sh <<EOF
> #!/bin/sh
> opendiff "$1" "$2"
> EOF
> $ GIT_EXTERNAL_DIFF=./merge.sh git-diff ...
A few problems with that:
- FileMerge is broken, and crashes if you pass /dev/null as a param
(which happens for new/deleted files)
- you need to escape those $-signs
- the params you're interested in are actually $2 and $5, not $1 and
$2, according to git(7)
- you need to handle the clean tree case (no params are passed)
- and also the 1-param case, "for unmerged paths", whatever that means
- will only work when run from the top of the tree (path parameters
are passed in relative to that)
So here's a less-broken version of your suggestion, but it's still
broken; a relatively complex wrapper is required to do this right:
$ cat >merge.sh <<EOF
#!/bin/sh
[ \$# -eq 7 ] && opendiff "\$2" "\$5"
EOF
chmod +x merge.sh
GIT_EXTERNAL_DIFF=./merge.sh git-diff ...
Cheers,
Wincent
^ permalink raw reply
* Re: Using Filemerge.app as a git-diff viewer
From: Jeff King @ 2007-11-21 13:04 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Toby White, git
In-Reply-To: <1A9343EE-BB45-4CF8-9F17-E6A73C5F0B83@wincent.com>
On Wed, Nov 21, 2007 at 01:59:37PM +0100, Wincent Colaiuta wrote:
> So here's a less-broken version of your suggestion, but it's still broken; a
> relatively complex wrapper is required to do this right:
Thanks. My "something like" should more accurately have been "I really
didn't think about this at all." But I do think a GIT_EXTERNAL_DIFF-type
approach (and if GIT_EXTERNAL_DIFF isn't powerful enough, considering
some alternate interface) is nicer than trying to wrap git-diff.
> $ cat >merge.sh <<EOF
> #!/bin/sh
> [ \$# -eq 7 ] && opendiff "\$2" "\$5"
> EOF
This is probably easier to read using <<'EOF' to quote (but I failed to
do even that in my example).
-Peff
^ permalink raw reply
* Re: Using Filemerge.app as a git-diff viewer
From: Toby White @ 2007-11-21 13:10 UTC (permalink / raw)
To: Jeff King; +Cc: git, Wincent Colaiuta
In-Reply-To: <20071121112757.GA17231@sigill.intra.peff.net>
Jeff King wrote:
> Have you looked at the documentation for GIT_EXTERNAL_DIFF (try git(7))?
> I think it is a cleaner way of doing what you want (although I think you
> will get each file diffed individually, which is perhaps not what you
> want).
>
> Something like:
>
> $ cat >merge.sh <<EOF
> #!/bin/sh
> opendiff "$1" "$2"
> EOF
> $ GIT_EXTERNAL_DIFF=./merge.sh git-diff ...
I hadn't seen that, no, but that's not quite right.
(Wincent pointed out its flaws better than me. Basically,
opendiff is not really diff-like enough.)
And in any case, that launches Filemerge repeatedly
on every file separately, which makes reviewing a large diff
time-consuming and not very helpful.
> write-tree? Yikes. If you want to diff against the working tree, then do
> that. If you want to diff against the index, then you probably want to
> git-checkout-index to a tmpdir, and diff against that.
Am I misunderstanding the documentation? From man git-write-tree
"Conceptually, git-write-tree sync()s the current index contents into a
set of tree files. In order to have that match what is actually in your
directory right now, you need to have done a git-update-index phase
before you did the git-write-tree."
So git-write-tree precisely does give you the index not the working tree,
by my reading.
>> git-archive --format=tar $OLD | (cd $TMPDIR1; tar xf -)
>
> Again, this could be simpler and faster by using git-checkout-index
> (preceded by git-read-tree into a temp index, if you are comparing
> against a tree).
Erm, ok, this is rapidly approaching the limit of my git knowledge,
but while I can see git-read-tree will write a tree-ish into a temp
index,
(so presumably
git-read-tree --index-output=$TMPFILE <commit>
ought to work. Except it doesn't, I get the error message
fatal: unable to write new index file
),
I can't see how to make git-checkout-index read from a temp index.
And I'm assuming I don't want to go stomping all over the current
index just in order to do a diff, which shouldn't change the state
of my repository.
Is there a canonical way to checkout a given commit object into
a fresh directory?
--
Dr. Toby O. H. White
Dept. Earth Sciences,
Downing Street,
Cambridge CB2 3EQ
United Kingdom
Tel: +44 1223 333464
Fax: +44 1223 333450
Web: http://uszla.me.uk
^ permalink raw reply
* What is the whole process of cooking git as a maintainer?
From: Ping Yin @ 2007-11-21 13:11 UTC (permalink / raw)
To: Git Mailing List
I have scanned the manual and found a 'Linux subsystem maintainer'
example. However, that's a little brief and i wonder a more real
example. I think an example of how to cook git as a maintainer is
better.
Junio , could you please share the whole process of cooking among pu,
next and master? Or, can i find this in the mail list archive?
For example:
In which branch the test is performed?
How to rewind pu?
How to merge a subset of changes from pu to next, and from next to master?
--
Ping Yin
^ permalink raw reply
* Re: What is the whole process of cooking git as a maintainer?
From: Ping Yin @ 2007-11-21 13:17 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <46dff0320711210511g7d9febf5k47b082cc13bb905a@mail.gmail.com>
On Nov 21, 2007 9:11 PM, Ping Yin <pkufranky@gmail.com> wrote:
> I have scanned the manual and found a 'Linux subsystem maintainer'
> example. However, that's a little brief and i wonder a more real
> example. I think an example of how to cook git as a maintainer is
> better.
>
> Junio , could you please share the whole process of cooking among pu,
> next and master? Or, can i find this in the mail list archive?
>
> For example:
> In which branch the test is performed?
> How to rewind pu?
> How to merge a subset of changes from pu to next, and from next to master?
>
One more question:
I see so many merges in pu branch, but where these merges go when a
feature is moved to the master branch?
>
> --
> Ping Yin
>
--
Ping Yin
^ permalink raw reply
* Can git for MinGW clone from http
From: Bo Yang @ 2007-11-21 13:22 UTC (permalink / raw)
To: git
Hi
I just installed the Git for MinGW in windows platform and I try to
git clone http://......
But it give a error message saying that there is no curl available.
Could you please tell me that does this version support clone through
http protocol? Thanks in advance!
Regards!
Bo
^ permalink raw reply
* Re: Using Filemerge.app as a git-diff viewer
From: Wincent Colaiuta @ 2007-11-21 13:28 UTC (permalink / raw)
To: Toby White; +Cc: Jeff King, git
In-Reply-To: <47442E57.8010004@cam.ac.uk>
El 21/11/2007, a las 14:10, Toby White escribió:
> (Wincent pointed out its flaws better than me. Basically,
> opendiff is not really diff-like enough.)
>
> And in any case, that launches Filemerge repeatedly
> on every file separately, which makes reviewing a large diff
> time-consuming and not very helpful.
I know it's not much help to you right now, but when I first asked
about a side-by-side diff viewer back in September I explored creating
a wrapper using GIT_EXTERNAL_DIFF and was basically unsatisfied with
the results.
So I decided to write a very simple native Cocoa app (I'm working on
Mac OS X); it was to be a diff viewer and nothing more (not a
repository browser). I was able to spend a few hours on it back in
September but then other things came up so I haven't been able to
finish it, but I do intend to come back to it when time permits. You
can browse the work in progress at:
<http://git.wincent.com/gdiff.git>
Basically consists of a fast Ragel-generated state machine for parsing
git-diff output, patches and email messages, and the beginnings of a
UI. But like I said, not much help to you right now as it can't yet be
used to do anything useful. My goal for it is to provide a nice
experience, above all when reviewing patches on a mailing list (ie.
where your local repository doesn't have the proposed commits in it
yet). In fact, even when run from outside of any Git repo I want it to
at least show the known parts of the files (the context) and provide a
shaded background for the unknown bits.
Cheers,
Wincent
^ permalink raw reply
* Re: Can git for MinGW clone from http
From: Johannes Sixt @ 2007-11-21 13:54 UTC (permalink / raw)
To: Bo Yang; +Cc: git
In-Reply-To: <474430F9.4080902@gmail.com>
Bo Yang schrieb:
> Hi
> I just installed the Git for MinGW in windows platform and I try to
> git clone http://......
> But it give a error message saying that there is no curl available.
> Could you please tell me that does this version support clone through
> http protocol? Thanks in advance!
Lets see:
D:\Src>git clone http://repo.or.cz/r/kdbg.git
Initialized empty Git repository in d:/Src/kdbg/.git/
http transport not supported, rebuild Git with curl support
Which part of "http transport not supported" requires further explanation?
-- Hannes
^ permalink raw reply
* Re: Using Filemerge.app as a git-diff viewer
From: Jakub Narebski @ 2007-11-21 13:58 UTC (permalink / raw)
To: git
In-Reply-To: <1A9343EE-BB45-4CF8-9F17-E6A73C5F0B83@wincent.com>
Wincent Colaiuta wrote:
> - you need to escape those $-signs
[...]
> $ cat >merge.sh <<EOF
Or use
$ cat >merge.sh <<\EOF
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'
From: Johannes Schindelin @ 2007-11-21 14:01 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4743E1D6.4010308@viscovery.net>
Hi,
On Wed, 21 Nov 2007, Johannes Sixt wrote:
> Johannes Schindelin schrieb:
> > Oh, and it relies on "int" being castable to void * and vice versa.
> > Is anybody aware of a platform where this can lead to problems?
>
> Win64?
Is this really a problem? I mean, all I need is that i == (int)(void *)i.
My doubts came from platforms where you can access memory only aligned to
4-byte chunks, and that it _may_ be possible that some of them do not even
store the least significant two bits.
Ciao,
Dscho
P.S.: I'll try to read up on ptrint_t, as suggested by Shawn.
^ permalink raw reply
* Re: What is the whole process of cooking git as a maintainer?
From: Theodore Tso @ 2007-11-21 14:07 UTC (permalink / raw)
To: Ping Yin; +Cc: Git Mailing List
In-Reply-To: <46dff0320711210517y282643a2q62819d3583ec9344@mail.gmail.com>
On Wed, Nov 21, 2007 at 09:17:59PM +0800, Ping Yin wrote:
> On Nov 21, 2007 9:11 PM, Ping Yin <pkufranky@gmail.com> wrote:
> > I have scanned the manual and found a 'Linux subsystem maintainer'
> > example. However, that's a little brief and i wonder a more real
> > example. I think an example of how to cook git as a maintainer is
> > better.
> >
> > Junio , could you please share the whole process of cooking among pu,
> > next and master? Or, can i find this in the mail list archive?
> >
> > For example:
> > In which branch the test is performed?
> > How to rewind pu?
> > How to merge a subset of changes from pu to next, and from next to master?
> >
>
> One more question:
> I see so many merges in pu branch, but where these merges go when a
> feature is moved to the master branch?
There is a discussion of some of these issues in the mail thread
beginning here:
http://kerneltrap.org/mailarchive/git/2007/10/23/350943
The git setup is actually pretty complex, and all of the details of
how to maintain the pu and next branches are pretty complicated ---
and if you don't have a large development community, it may not be
worth the overhead, and it may scare people off as being too complicated.
There are multiple ways to maintain a project in git, and it's usually
better to start simple --- with a development and maintenance branch.
If you need more, you can add more later, but I wouldn't recommend
starting off with a very complex system right off the bat.
- Ted
^ permalink raw reply
* [PATCH] Highlight keyboard shortcuts in git-add--interactive
From: Wincent Colaiuta @ 2007-11-21 14:27 UTC (permalink / raw)
To: git; +Cc: gitster, Wincent Colaiuta
The user interface provided by the command loop in git-add--interactive
gives the impression that subcommands can only be launched by entering
an integer identifier from 1 through 8.
A "hidden" feature is that any string can be entered, and an anchored
regex search is used to find the first matching option.
This patch makes this feature a little more obvious by highlighting the
first character of each subcommand (for example "patch" is displayed as
"[p]atch"). The mechanism for doing this is to add an optional third
element to the array defining each subcommand; if present, it will be
used for display purposes, while the actual name of the subcommand (the
first element) is still used for matching purposes.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
---
And another thought: if the colorization for git-add--interactive goes
ahead, we could drop the square brackets used here in favor of underline
or boldface, if people find that more attractive.
git-add--interactive.perl | 18 +++++++++---------
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 0317ad9..2b1c55a 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -179,7 +179,7 @@ sub list_and_choose {
my $print = $stuff[$i];
if (ref $print) {
if ((ref $print) eq 'ARRAY') {
- $print = $print->[0];
+ $print = $print->[2] || $print->[0];
}
else {
$print = $print->{PRINT};
@@ -774,14 +774,14 @@ EOF
}
sub main_loop {
- my @cmd = ([ 'status', \&status_cmd, ],
- [ 'update', \&update_cmd, ],
- [ 'revert', \&revert_cmd, ],
- [ 'add untracked', \&add_untracked_cmd, ],
- [ 'patch', \&patch_update_cmd, ],
- [ 'diff', \&diff_cmd, ],
- [ 'quit', \&quit_cmd, ],
- [ 'help', \&help_cmd, ],
+ my @cmd = ([ 'status', \&status_cmd, '[s]tatus', ],
+ [ 'update', \&update_cmd, '[u]date', ],
+ [ 'revert', \&revert_cmd, '[r]evert', ],
+ [ 'add untracked', \&add_untracked_cmd, '[a]dd untracked', ],
+ [ 'patch', \&patch_update_cmd, '[p]atch', ],
+ [ 'diff', \&diff_cmd, '[d]iff', ],
+ [ 'quit', \&quit_cmd, '[q]uit', ],
+ [ 'help', \&help_cmd, '[h]elp', ],
);
while (1) {
my ($it) = list_and_choose({ PROMPT => 'What now',
--
1.5.3.6.866.g67e44
^ permalink raw reply related
* Re: [PATCH] Highlight keyboard shortcuts in git-add--interactive
From: Matthieu Moy @ 2007-11-21 14:32 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git, gitster
In-Reply-To: <1195655278-19535-1-git-send-email-win@wincent.com>
Wincent Colaiuta <win@wincent.com> writes:
> + [ 'update', \&update_cmd, '[u]date', ],
^
"p" missing in "update".
--
Matthieu
^ permalink raw reply
* Re: Using Filemerge.app as a git-diff viewer
From: Jeff King @ 2007-11-21 14:36 UTC (permalink / raw)
To: Toby White; +Cc: git, Wincent Colaiuta
In-Reply-To: <47442E57.8010004@cam.ac.uk>
On Wed, Nov 21, 2007 at 01:10:47PM +0000, Toby White wrote:
> And in any case, that launches Filemerge repeatedly
> on every file separately, which makes reviewing a large diff
> time-consuming and not very helpful.
I think that particular complaint of GIT_EXTERNAL_DIFF has come up
before. It probably wouldn't be too hard to support a separate
environment variable to mean "diff these two trees" (or tree/cache, or
cache/working tree, etc) rather than "diff these two files".
> Am I misunderstanding the documentation? From man git-write-tree
>
> "Conceptually, git-write-tree sync()s the current index contents into a
> set of tree files. In order to have that match what is actually in your
> directory right now, you need to have done a git-update-index phase
> before you did the git-write-tree."
>
> So git-write-tree precisely does give you the index not the working tree,
> by my reading.
What you are doing isn't _wrong_, but it is not the most efficient way
of doing it, and it is a little bit awkward, I think.
There are basically three conceptual "spots" for files in git:
- in the object database (i.e., tree objects pointing to blobs)
- in the index (the blobs are actually in the object db)
- in the working tree (i.e., actual files)
git-write-tree moves data from the index into the object database
(git-commit is more or less git-write-tree followed by git-commit-tree).
git-archive (piped to tar) moves data from the object database (because
it takes a tree object name) into the working tree.
So you are basically moving data into the object db, and then out to the
working tree. But there is a command that moves data directly from the
index to the working tree: git-checkout-index.
Now, what you are doing is not terribly inefficient in that sense, since
creating a tree object is usually pretty inexpensive. But it does
involve writing to the object db for a diff, which is conceptually a
read-only operation.
However, git-checkout-index also avoids piping through tar, which is
likely to be faster for a large data set.
> Erm, ok, this is rapidly approaching the limit of my git knowledge,
BTW, I don't mean to nitpick your script, which obviously works for you.
I'm just trying to increase your git knowledge. :)
> but while I can see git-read-tree will write a tree-ish into a temp
> index,
>
> (so presumably
> git-read-tree --index-output=$TMPFILE <commit>
> ought to work. Except it doesn't, I get the error message
> fatal: unable to write new index file
> ),
Are you perhaps running against the rename(2)-ability boundaries
mentioned in the man page? --index-output is relatively new, and I'm not
sure of the reasons surrounding it. I think what you really want to work
with a temp index is to set GIT_INDEX_FILE.
> I can't see how to make git-checkout-index read from a temp index.
It should read from GIT_INDEX_FILE. So the correct incantation for
checking out a tree should be:
GIT_INDEX_FILE=$TMPFILE git-read-tree <commit>
GIT_INDEX_FILE=$TMPFILE git-checkout-index -a --prefix=$TMPDIR/
and of course, for the --cached case, you can just use the existing
index:
git-checkout-index -a --prefix=$TMPDIR/
(btw, I have no idea if creating a temp index is actually faster than
piping through tar. I suspect it is, but haven't tested. So it may be
sane to use checkout-index for the --cached case, which is what I was
originally suggesting, and simply use git-archive for the tree case).
> And I'm assuming I don't want to go stomping all over the current
> index just in order to do a diff, which shouldn't change the state
> of my repository.
Correct.
> Is there a canonical way to checkout a given commit object into
> a fresh directory?
git-archive piped to tar is the canonical porcelain way (again, I was
suggesting checkout-index mainly for the --cached case). The way I
showed above is the "plumbing" way (and is what underlies git-checkout,
for example, though of course a temp index is not needed in that case).
Hope that make sense.
-Peff
^ permalink raw reply
* Re: Can git for MinGW clone from http
From: Johannes Schindelin @ 2007-11-21 14:38 UTC (permalink / raw)
To: Bo Yang; +Cc: git
In-Reply-To: <474430F9.4080902@gmail.com>
Hi,
On Wed, 21 Nov 2007, Bo Yang wrote:
> I just installed the Git for MinGW in windows platform and I try to
> git clone http://......
You might be interested in http://msysgit.googlecode.com/ (just install
the preview).
Hth,
Dscho
^ permalink raw reply
* Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'
From: Johannes Schindelin @ 2007-11-21 14:42 UTC (permalink / raw)
To: Geert Bosch; +Cc: git
In-Reply-To: <2348F06A-F9A2-4A8F-8501-D0B696F34388@adacore.com>
Hi,
On Wed, 21 Nov 2007, Geert Bosch wrote:
> On Nov 20, 2007, at 22:40, Johannes Schindelin wrote:
> > Oh, and it relies on "int" being castable to void * and vice
> > versa. Is anybody aware of a platform where this can lead to
> > problems?
>
> Like any 64-bit system? int is 32 bit and void * is 64. So, casting a
> pointer to an int drops half the bits. When you convert it back it will
> point to a funny place...
Have you even read the patch? Like I pointed out in my reply to Hannes, I
only need the guarantee that
i == (int)(void *)i
for all integers i.
Ciao,
Dscho
^ permalink raw reply
* Re: What is the whole process of cooking git as a maintainer?
From: Johannes Schindelin @ 2007-11-21 14:45 UTC (permalink / raw)
To: Ping Yin; +Cc: Git Mailing List
In-Reply-To: <46dff0320711210511g7d9febf5k47b082cc13bb905a@mail.gmail.com>
Hi,
On Wed, 21 Nov 2007, Ping Yin wrote:
> Junio , could you please share the whole process of cooking among pu,
> next and master? Or, can i find this in the mail list archive?
The easiest way is to read the notes from the maintainer, and then study
the scripts in the 'todo' branch, and guess...
Hth,
Dscho
^ permalink raw reply
* Wishlist for a bundle-only transport mode
From: Santi Béjar @ 2007-11-21 14:54 UTC (permalink / raw)
To: Git Mailing List
Hi *,
I have to work in a bundle-only mode, but there are some problems
with it, namely:
1) git-clone does not accept a bundle file, even if git-fetch does.
I've made a patch to use git-fetch in git-clone for this.
2) The bundles created with "git bundle" does not record the HEAD,
they resolve the symbolic name to a branch name.
3) I can "git fetch" a bundle but I cannot "git push" a bundle, so if I have:
[remote "bundle"]
url = /file/to/bundle
fetch = "+refs/heads/*:refs/remotes/bundle/*"
$ git push bundle
would create a bundle in /file/to/bundle with the same branches as a
normal git push, but considering the remote branches as the local
remotes/bundle/*
Thank you
Santi
^ permalink raw reply
* Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'
From: Andreas Ericsson @ 2007-11-21 15:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, git
In-Reply-To: <Pine.LNX.4.64.0711211209080.27959@racer.site>
Johannes Schindelin wrote:
>
> P.S.: I'll try to read up on ptrint_t, as suggested by Shawn.
I can't find a reference to ptrint_t anywhere on either my system,
and the 10 first hits on Google finds it on typedef lines, most
commonly like this:
typedef unsigned long ptrint_t;
I think ptrdiff_t is more portable. Here's the relevant entry
about ptrdiff_t from /usr/include/obstack.h on my system:
---%<---%<---%<---
/* We need the type of a pointer subtraction. If __PTRDIFF_TYPE__ is
defined, as with GNU C, use that; that way we don't pollute the
namespace with <stddef.h>'s symbols. Otherwise, include <stddef.h>
and use ptrdiff_t. */
#ifdef __PTRDIFF_TYPE__
# define PTR_INT_TYPE __PTRDIFF_TYPE__
#else
# include <stddef.h>
# define PTR_INT_TYPE ptrdiff_t
#endif
---%<---%<---%<---
MySQL seems to have botched that one though. It has this instead:
typedef long my_ptrdiff_t;
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Wishlist for a bundle-only transport mode
From: Jakub Narebski @ 2007-11-21 15:04 UTC (permalink / raw)
To: git
In-Reply-To: <8aa486160711210654p357ccd87i4809e0cda9471303@mail.gmail.com>
Santi Béjar wrote:
> 3) I can "git fetch" a bundle but I cannot "git push" a bundle, so if I have:
>
> [remote "bundle"]
> url = /file/to/bundle
> fetch = "+refs/heads/*:refs/remotes/bundle/*"
>
> $ git push bundle
>
> would create a bundle in /file/to/bundle with the same branches as a
> normal git push, but considering the remote branches as the local
> remotes/bundle/*
And how you would differentiate between path meaning bundle, and
path meaning "local" protocol, i.e. git repository on the same
filesystem? "bundle = /file/to/bundle" perhaps...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: gitweb: kernel versions in the history (feature request, probably)
From: Petr Baudis @ 2007-11-21 15:18 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: J. Bruce Fields, linux-kernel, git
In-Reply-To: <20071121075217.GA1642@ff.dom.local>
On Wed, Nov 21, 2007 at 08:52:17AM +0100, Jarek Poplawski wrote:
> ...
> tags
> 4 days ago v2.6.24-rc3 Linux 2.6.24-rc3
> 2 weeks ago v2.6.24-rc2 Linux 2.6.24-rc2
> 4 weeks ago v2.6.24-rc1 Linux 2.6.24-rc1
> 6 weeks ago v2.6.23 Linux 2.6.23
>
> which drives me crazy, because, without looking at the calendar, and
> calculator, I don't really know which month was 6 weeks ago, and 4
> days ago, either!
I have myself never been sure if the relative times are a good idea or
not. :-) Sometimes I hate them, sometimes they are more convenient...
At any rate, if you click at the tag name, you should get tag page with
full date.
> So, I go to the: http://www.eu.kernel.org/pub/linux/kernel/v2.6/,
> do some scrolling, look at this:
> ChangeLog-2.6.23 09-Oct-2007 20:38 3.8M
>
> and only now I can guess, this napi patch didn't manage to 2.6.23.
> Of course, usually I've to do a few more clicks and reading to make
> sure where it really started.
>
> So, this could suggest this 2007-10-10 (probably stored with time
> too), could be useful here... but it seems, I'm wrong.
Yes, there are three scenarios:
(i) The patch has been _created_ after the release date. It can't be in
the release.
(ii) The patch has been created before the release date, but _committed_
after the release date. It can't be in the release either.
(iii) The patch has been committed before the release date. It _still_
might not be in the release if it comes from a different branch.
Imagine, say, tglx accepting the patch in his branch, then Linus
releasing new kernel version, and only _then_ Linus merging tglx's
branch.
So the time information isn't really too useful if you want to be any
sort of reliable.
> Of course, this problem doesn't look so hard if we forget about
> git internals: I can imagine keeping a simple database, which
> could simply retrieve commit numbers from these ChangeLogs, and
> connecting this with gitweb's commit page as well... For
> performance reasons, doing it only for stable and testing, so with
> -rc 'precision' would be very helpful too.
It isn't too hard if we don't forget about git internals either. It's
just that getting this information might not be cheap. But maybe I'm
wrong and this won't be a problem for sane projects. Someone should post
a patch. ;-)
--
Petr "Pasky" Baudis
We don't know who it was that discovered water, but we're pretty sure
that it wasn't a fish. -- Marshall McLuhan
^ permalink raw reply
* Re: [PATCH 2/4] Teach git-add--interactive to accept a file path to patch
From: Jeff King @ 2007-11-21 15:21 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git, gitster
In-Reply-To: <1195648601-21736-3-git-send-email-win@wincent.com>
On Wed, Nov 21, 2007 at 01:36:39PM +0100, Wincent Colaiuta wrote:
> If supplied a single file path parameter the git-add--interactive script
> now bypasses the command loop and jumps straight to the patch subcommand
> using the passed path. After returning from the subcommand the main
> command loop is entered. If a non-resolvable path is supplied the
> operation is a no-op and the command loop is entered.
Great, the lack of this feature has bugged me in the past. Thank you for
working on it. However...
> diff --git a/git-add--interactive.perl b/git-add--interactive.perl
> index fb1e92a..8f21c03 100755
> --- a/git-add--interactive.perl
> +++ b/git-add--interactive.perl
> @@ -803,6 +803,11 @@ sub main_loop {
> }
> }
>
> +die "add --interactive may take only 1 optional parameter" if ($#ARGV > 0);
> refresh();
> +if ($#ARGV == 0) {
> + patch_update_file($ARGV[0]);
> +}
> status_cmd();
> main_loop();
> +
Why only one file? How about something like this instead:
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index fb1e92a..8036c95 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -804,5 +804,8 @@ sub main_loop {
}
refresh();
+foreach my $file (@ARGV) {
+ patch_update_file($file);
+}
status_cmd();
main_loop();
On top of that, it would be great to be able to do something like
git-add -i *.c
and just get prompted for changed files (right now, you only get
prompted for changed files, but unchanged files seem to print a spurious
newline).
And at any rate, this would require fixing 3/4 to handle the multiple
files from git-add.
What do you think?
-Peff
^ 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