* Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'
From: Shawn O. Pearce @ 2007-11-23 20:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: hanwen, git
In-Reply-To: <Pine.LNX.4.64.0711230149430.27959@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Thu, 22 Nov 2007, Han-Wen Nienhuys wrote:
>
> > > Maybe you want to specify if all blobs should be output first, and
> > > then the commits? Or files should be used? But all of these things
> > > seem to be useless to me.
> >
> > No, I want the program to wait for me to tell it what
> > blobs/commits/trees I want. The commit I want to see secondly may depend
> > on the output I read in the first request blob. Right now, for each data
> > dependency I have to start a new git process.
>
> It does not seem like you want a mirror of fast-import, but rather a
> driver. You might be happy to hear that you can do that already. Today.
> However, you probably want to query different programs about certain
> states of the repository. This will not change.
>
> > > > Besides being a nuisance, I actually run git on NFS, and every git
> > > > process has to go to NFS a couple times to retrieve the same
> > > > information. This has a noticeable performance impact.
I have been considering creating a "git-gui daemon" process that
links to libgit.a and can be driven bidirectionally through its
stdin/stdout. Based on git-fast-export, sorta. But I haven't
even started it...
But the idea is sort of what Han-Wen wants. Why should I fork
rev-parse to get a ref value? Or update-ref to change one?
--
Shawn.
^ permalink raw reply
* Re: Git Screencast ?
From: Shawn O. Pearce @ 2007-11-23 20:58 UTC (permalink / raw)
To: Johannes Gilger; +Cc: Michael Donaghy, git
In-Reply-To: <20071123101426.GA15902@dualtron.vpn.rwth-aachen.de>
Johannes Gilger <heipei@hackvalue.de> wrote:
> On 22/11/07 20:47, Michael Donaghy wrote:
> > Yes thank you , although a screen cast would still be ideal , the
> > documentation is very good,
> > also , what do you think of git-gui ? , I think it is the best one
>
> I think you're trying to hide the complexity of git. The problem with
> graphical tools is that they hide complexity from the user, which in
> some cases is only possibly/good if the user has understood the
> underlying principles already.
Actually some users have found that its easier to grok the index
by using git-gui. You can more directly see the state of update
actions, and it is fairly easy to stage/unstage individual hunks
of files through git-gui. Once you get that down then seeking
the same methods through the command line isn't too difficult,
many of the terms in git-gui are the same as the command line term,
to make the transition back and forth easier for the user.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Add config_int() method to the Git perl module
From: Wincent Colaiuta @ 2007-11-23 20:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git, Jeff King, Dan Zwell
In-Reply-To: <7vabp4u40y.fsf@gitster.siamese.dyndns.org>
El 23/11/2007, a las 20:59, Junio C Hamano escribió:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Integer variables can have optional 'k', 'm' or 'g' suffix.
>> config_int() method will return simple decimal number, taking
>> care of those suffixes.
>
> Good. I forgot about --int option to "git config" already.
>
> Maybe in a similar way, we might want to add --color to "git
> config" to return ANSI sequence, so that Git::config_color() can
> work without even loading Term::ANSIColor?
Or failing that, it would be very easy to remove the dependency on
Term::ANSIColor by adding something like this to Git.pm:
+my $COLOR = {
+ "reset" => "\e[0m",
+ "normal" => "",
+ "black" => "\e[30m",
+ "red" => "\e[31m",
+ "green" => "\e[32m",
+ "yellow" => "\e[33m",
+ "blue" => "\e[34m",
+ "magenta" => "\e[35m",
+ "cyan" => "\e[36m",
+ "white" => "\e[37m",
+ "bold" => "\e[1m",
+ "ul" => "\e[4m",
+ "blink" => "\e[5m",
+ "reverse" => "\e[7m",
+ "on_red" => "\e[41m",
+};
+
+sub color {
+ my $desired_color = shift;
+ return $COLOR->{$desired_color} || "";
+}
Cheers,
Wincent
^ permalink raw reply
* Re: [WIP PATCH] Add 'git fast-export', the sister of 'git fast-import'
From: Shawn O. Pearce @ 2007-11-23 20:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <Pine.LNX.4.64.0711231428350.27959@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Fri, 23 Nov 2007, Nguyen Thai Ngoc Duy wrote:
> > I have a suggestion though. git-fast-export and git-fast-import should
> > support bundle.
>
> I think this is not what fast-export and fast-import are about. They use
> an easy to generate, and easy to edit, format.
>
> Bundles are optimised transport mechanisms for sneaker net. They are not
> to be meant to be easy to edit, but as small as possible.
Actually I wonder, what about bundles that are formatted as a
git-fast-import data stream? Then you can have a human readable
bundle format that can be (reasonably) easily turned back into a
packfile and loaded into the local ODB.
Only we'd probably want to express blobs as diffs if we can, to
save disk space, which means we'd need to have git-apply organized
in a way that we can call it from within fast-import. :-)
But I agree with Dscho's basic comment; fast-import should not
be reading a bundle. It doesn't want to. That's what git-bundle
is for.
--
Shawn.
^ permalink raw reply
* Re: cloning submodules with children submodules
From: Paul Martinolich @ 2007-11-23 20:35 UTC (permalink / raw)
To: skimo; +Cc: git
In-Reply-To: <20071123194904.GL2261MdfPADPa@greensroom.kotnet.org>
On Nov 23, 2007, at 1:49 PM, Sven Verdoolaege wrote:
> You didn't commit the change to mod_B to proj_one.
> Furthermore, you didn't push your changes to mod_B to
> the repo you specified for mod_B in .gitmodules.
Thanks for the help.
It works with the changes below.
Paul
I changed the creation of mod_b under mod_B to:
# add mod_b to mod_B and push the changes back to mod_B
cd $GITDIR/proj_one/mod_B
git submodule add $GITDIR/modules/mod_b
git commit -m 'add module mod_b under module mod_B for project proj_one'
git push
cd $GITDIR/proj_one
git add mod_B
git commit -m 'reflect module mod_B update for project proj_one'
git status
and when I cloned it to:
# clone the proj_one project (user user_a)
mkdir -p $GITDIR/user_a
cd $GITDIR/user_a
git clone $GITDIR/proj_one
cd $GITDIR/user_a/proj_one
# get mod_A and mod_B
git submodule init
git submodule update
# now get mod_b in mod_B
cd mod_B
git submodule init
git submodule update
^ permalink raw reply
* [PATCH] Remove git-status from list of scripts as it is builtin
From: Shawn O. Pearce @ 2007-11-23 20:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Now that git-status is builtin on Cygwin this compiles as
git-status.exe. We cannot continue to include git-status
as a Makefile target as it will never be built.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
I apologize if this is a dupe; I haven't had a chance to read
the list traffic to see what has been posted and what hasn't.
I'll be offline for the next few days so I figured I should get
this out there now, just in case anyone else might run into the
same problem I did.
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 313f9a2..a5a40ce 100644
--- a/Makefile
+++ b/Makefile
@@ -233,7 +233,7 @@ SCRIPT_PERL = \
SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)) \
$(patsubst %.perl,%,$(SCRIPT_PERL)) \
- git-status git-instaweb
+ git-instaweb
# ... and all the rest that could be moved out of bindir to gitexecdir
PROGRAMS = \
--
1.5.3.6.1936.gc44a9
^ permalink raw reply related
* Re: [PATCH] Don't add To: recipients to the Cc: header
From: Sergei Organov @ 2007-11-23 20:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ask Bjørn Hansen, git
In-Reply-To: <7vejegu4in.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Sergei Organov <osv@javad.com> writes:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> Sergei Organov <osv@javad.com> writes:
>>>
>>>> Junio C Hamano <gitster@pobox.com> writes:
>>>> [...]
>>>>> Oops, forgot to say "no need to resend". I asked only because I
>>>>> wanted an independent datapoint for Emacs diff mode breakage.
>>>>
>>>> I bet I can damage any patch using any editor ;)
>>>>
>>>> More interesting is what version of Emacs it was?
>>>
>>> To be fair and honest, I do not think there is a simple fix for
>>> this, although it probably is possible to fix it.
>>>
>>> What is causing the "breakage" is the fact that format-patch
>>> output ends with the signature delimiter line "^-- $" that
>>> immediately follows the patch text.
>>
>> Exactly. What causes breakage is the fact that the '-' character (as
>> well as '+', ' ', '!', '#', and '\'), being the first symbol of a line
>> has special meaning in the diff format.
>
> That is correct only if they appear inside a hunk. The number
> of preimage and postimage lines in a hunk is recorded on the
> hunk header line --- tools are given enough information to tell
> a line that begins with a SP (or '+' or '-') outside a patch
> from another such line that is inside the patch.
Yeah, it's one valid interpretation. Here is another one:
"The chunk range for the original should be the sum of all contextual
and deletion (including changed) chunk lines. The chunk range for the
new file should be a sum of all contextual and addition (including
changed) chunk lines. If chunk size information does not correspond
with the number of lines in the hunk, then the diff could be
considered invalid and be rejected."
taken from here: <http://www.answers.com/topic/diff?cat=technology>
The above implies that a tool should be able to determine the "end of
hunk" without using the hunk header information. This is rather hard to
do with current format-patch output, and it's impossible to do if there
are no "unchanged context" lines at all (i.e., format-patch -U0).
> The diff editing mode of Emacs, at least the version that caused
> this issue, however did not make use of that information.
> That's the breakage. Not format-patch output.
IMHO it's rather useless to argue about it without strict definition of
correct format of a patch (do you have one?). However, it's easy to add
an empty line for format-patch and very difficult, if not impossible,
for Emacs to handle this without such a line.
Therefore I repeat my question: are there any objections to add such an
empty line by format-patch?
--
Sergei.
^ permalink raw reply
* Re: [PATCH] Add config_int() method to the Git perl module
From: Junio C Hamano @ 2007-11-23 19:59 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Jeff King, Dan Zwell
In-Reply-To: <200711231904.53551.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Integer variables can have optional 'k', 'm' or 'g' suffix.
> config_int() method will return simple decimal number, taking
> care of those suffixes.
Good. I forgot about --int option to "git config" already.
Maybe in a similar way, we might want to add --color to "git
config" to return ANSI sequence, so that Git::config_color() can
work without even loading Term::ANSIColor?
^ permalink raw reply
* Re: cloning submodules with children submodules
From: Sven Verdoolaege @ 2007-11-23 19:49 UTC (permalink / raw)
To: Paul Martinolich; +Cc: git
In-Reply-To: <BC1DE15A-9225-41D3-A2D7-21A14DF81048@nrlssc.navy.mil>
On Fri, Nov 23, 2007 at 01:17:15PM -0600, Paul Martinolich wrote:
> It appears that git clone or git submodule init does not handle
> submodules under submodules.
I don't see why it wouldn't work.
You seem to think, however, that git submodule update would
call git submodule update/init inside any submodules it clones.
It doesn't.
> The cloning of proj_two works correctly. However, for proj_one, mod_b
> is not under mod_B:
You didn't commit the change to mod_B to proj_one.
Furthermore, you didn't push your changes to mod_B to
the repo you specified for mod_B in .gitmodules.
skimo
^ permalink raw reply
* Re: [PATCH] Don't add To: recipients to the Cc: header
From: Junio C Hamano @ 2007-11-23 19:48 UTC (permalink / raw)
To: Sergei Organov; +Cc: Ask Bjørn Hansen, git
In-Reply-To: <87lk8orgpm.fsf@osv.gnss.ru>
Sergei Organov <osv@javad.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Sergei Organov <osv@javad.com> writes:
>>
>>> Junio C Hamano <gitster@pobox.com> writes:
>>> [...]
>>>> Oops, forgot to say "no need to resend". I asked only because I
>>>> wanted an independent datapoint for Emacs diff mode breakage.
>>>
>>> I bet I can damage any patch using any editor ;)
>>>
>>> More interesting is what version of Emacs it was?
>>
>> To be fair and honest, I do not think there is a simple fix for
>> this, although it probably is possible to fix it.
>>
>> What is causing the "breakage" is the fact that format-patch
>> output ends with the signature delimiter line "^-- $" that
>> immediately follows the patch text.
>
> Exactly. What causes breakage is the fact that the '-' character (as
> well as '+', ' ', '!', '#', and '\'), being the first symbol of a line
> has special meaning in the diff format.
That is correct only if they appear inside a hunk. The number
of preimage and postimage lines in a hunk is recorded on the
hunk header line --- tools are given enough information to tell
a line that begins with a SP (or '+' or '-') outside a patch
from another such line that is inside the patch.
The diff editing mode of Emacs, at least the version that caused
this issue, however did not make use of that information.
That's the breakage. Not format-patch output.
^ permalink raw reply
* cloning submodules with children submodules
From: Paul Martinolich @ 2007-11-23 19:17 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 2097 bytes --]
It appears that git clone or git submodule init does not handle
submodules under submodules.
Given this project tree:
modules/mod_A
modules/mod_B
modules/mod_b
proj_one/mod_A
proj_one/mod_B
proj_one/mod_B/mod_b
proj_two/mod_A
proj_two/mod_B
proj_two/mod_b
The cloning of proj_two works correctly. However, for proj_one, mod_b
is not under mod_B:
cloned proj_one
$ ls -a ./
. .. .git .gitmodules mod_A mod_B project.txt
$ ls -a ./mod_A
. ..
$ ls -a ./mod_B
. ..
$ more .gitmodules
[submodule "mod_A"]
path = mod_A
url = /home/martinol/test/modules/mod_A/.git
[submodule "mod_B"]
path = mod_B
url = /home/martinol/test/modules/mod_B/.git
Submodule 'mod_A' (/home/martinol/test/modules/mod_A/.git) registered
for path 'mod_A'
Submodule 'mod_B' (/home/martinol/test/modules/mod_B/.git) registered
for path 'mod_B'
Initialized empty Git repository in /home/martinol/test/user_a/
proj_one/mod_A/.git/
0 blocks
Submodule path 'mod_A': checked out
'80298817a0789d039e1fb4a73c9635fce8e7cdd2'
Initialized empty Git repository in /home/martinol/test/user_a/
proj_one/mod_B/.git/
0 blocks
Submodule path 'mod_B': checked out
'21b652610f5e9085f799c424d8a7ef685f5ec440'
submodule init/update proj_one
$ ls -a ./
. .. .git .gitmodules mod_A mod_B project.txt
$ ls -a ./mod_A
. .. .git module.txt
$ ls -a ./mod_B
. .. .git module.txt
$ more .gitmodules
[submodule "mod_A"]
path = mod_A
url = /home/martinol/test/modules/mod_A/.git
[submodule "mod_B"]
path = mod_B
url = /home/martinol/test/modules/mod_B/.git
public proj_one
$ cd ~/test/proj_one
$ ls -a ./
. .. .git .gitmodules mod_A mod_B project.txt
$ ls -a ./mod_B
. .. .git .gitmodules mod_b module.txt
$ more .gitmodules
[submodule "mod_A"]
path = mod_A
url = /home/martinol/test/modules/mod_A/.git
[submodule "mod_B"]
path = mod_B
url = /home/martinol/test/modules/mod_B/.git
$ more mod_B/.gitmodules
[submodule "mod_b"]
path = mod_b
url = /home/martinol/test/modules/mod_b/.git
$ git --version
git version 1.5.3.6
I've attached a script that demonstrates this behavior.
Thanks, Paul
[-- Attachment #2: sub-sub-modules.sh --]
[-- Type: application/octet-stream, Size: 2530 bytes --]
#/bin/sh
GITDIR=$HOME/test
mk_modules()
{
mkdir -p $GITDIR/modules/$1
cd $GITDIR/modules/$1
git init
echo "$1" > module.txt
git add module.txt
git commit -m "initialize module $1"
git branch -m master proj_one
}
# setup public modules
mk_modules mod_A
mk_modules mod_b
mk_modules mod_B
# create public proj_one project
mkdir -p $GITDIR/proj_one
cd $GITDIR/proj_one
git init
echo "Project One" > project.txt
git add project.txt
git commit -m 'initialize project proj_one'
git branch -m master proj_one
git submodule add $GITDIR/modules/mod_A
git commit -m 'add module mod_A to project proj_one'
git submodule add $GITDIR/modules/mod_B
git commit -m 'add module aps to project proj_one'
cd $GITDIR/proj_one/mod_B
git submodule add $GITDIR/modules/mod_b
git commit -m 'add module mod_b under module mod_B for project proj_one'
git status
# create public proj_two project
mkdir -p $GITDIR/proj_two
cd $GITDIR/proj_two
git init
echo "Project Two" > project.txt
git add project.txt
git commit -m 'initialize project proj_two'
git branch -m master proj_two
# create proj_two branch on public modules
cd $GITDIR/modules/mod_A
git checkout -b proj_two
cd $GITDIR/modules/mod_B
git checkout -b proj_two
cd $GITDIR/modules/mod_b
git checkout -b proj_two
# add these modules to the proj_two project
cd $GITDIR/proj_two
git submodule add $GITDIR/modules/mod_A
git commit -m 'add module mod_A to project proj_two'
git submodule add $GITDIR/modules/mod_B
git commit -m 'add module mod_B to project proj_two'
git submodule add $GITDIR/modules/mod_b
git commit -m 'add module mod_b to project proj_two'
# clone the proj_two project (user a)
mkdir -p $GITDIR/user_a
cd $GITDIR/user_a
git clone $GITDIR/proj_two
cd $GITDIR/user_a/proj_two
git submodule init
git submodule update
# clone the proj_two project (user b)
mkdir -p $GITDIR/user_b
cd $GITDIR/user_b
git clone $GITDIR/proj_two
cd $GITDIR/user_b/proj_two
git submodule init
git submodule update
# clone the proj_one project (user user_a)
mkdir -p $GITDIR/user_a
cd $GITDIR/user_a
git clone $GITDIR/proj_one
cd $GITDIR/user_a/proj_one
echo ""
echo "cloned proj_one"
echo ""
ls -a ./
ls -a ./mod_A
ls -a ./mod_B
more .gitmodules
git submodule init
git submodule update
echo ""
echo "submodule init/update proj_one"
echo ""
ls -a ./
ls -a ./mod_A
ls -a ./mod_B
more .gitmodules
echo ""
echo "public proj_one"
echo ""
cd $GITDIR/proj_one
ls -a ./
ls -a ./mod_B
more .gitmodules
more mod_B/.gitmodules
[-- Attachment #3: Type: text/plain, Size: 4 bytes --]
^ permalink raw reply
* Re: [PATCH 1/7] Add -q/--quiet switch to git-ls-files
From: Wincent Colaiuta @ 2007-11-23 19:25 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git, gitster, peff
In-Reply-To: <1195845650-85962-2-git-send-email-win@wincent.com>
El 23/11/2007, a las 20:20, Wincent Colaiuta escribió:
> +test_expect_success \
> + 'git ls-files -q --error-unmatch should be quiet with unmatched
> path.' \
> + 'git ls-files -q --error-unmatch foo bar-does-not-match 1> out
> 2> err ||
> + test $(cat out | wc -l) -eq 0 &&
> + test $(cat err | wc -l) -gt 0'
> +
> +test_expect_success \
> + 'git ls-files -q --error-unmatch should be quiet with matched
> paths.' \
> + 'git ls-files -q --error-unmatch foo bar 1> out 2> err ||
> + test $(cat out | wc -l) -eq 0 &&
> + test $(cat err | wc -l) -eq 0'
> +
> test_done
Doh, in that last test it should be:
+ 'git ls-files -q --error-unmatch foo bar 1> out 2> err &&
Instead of:
+ 'git ls-files -q --error-unmatch foo bar 1> out 2> err ||
Cheers,
Wincent
^ permalink raw reply
* [PATCH 5/7] Teach builtin-add to pass path arguments to git-add--interactive
From: Wincent Colaiuta @ 2007-11-23 19:20 UTC (permalink / raw)
To: git; +Cc: gitster, peff, Wincent Colaiuta
In-Reply-To: <1195845650-85962-5-git-send-email-win@wincent.com>
The previous patches in the series taught git-add--interactive to handle
optional path arguments. This patch teaches builtin-add to pass
these arguments through to the script.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
---
Documentation/git-add.txt | 4 +++-
builtin-add.c | 23 +++++++++++++----------
commit.h | 2 +-
3 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 63829d9..0b0ab1d 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -61,7 +61,9 @@ OPTIONS
-i, \--interactive::
Add modified contents in the working tree interactively to
- the index.
+ the index. Optional path arguments may be supplied to limit
+ operation to a subset of the files in the working tree.
+ See ``Interactive mode'' for details.
-u::
Update only files that git already knows about. This is similar
diff --git a/builtin-add.c b/builtin-add.c
index cf815a0..3646a45 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -135,11 +135,17 @@ static void refresh(int verbose, const char **pathspec)
free(seen);
}
-int interactive_add(void)
+int interactive_add(int argc, const char **argv)
{
- const char *argv[2] = { "add--interactive", NULL };
-
- return run_command_v_opt(argv, RUN_GIT_CMD);
+ int status;
+ const char **args = xmalloc(sizeof(const char *) * (argc + 1));
+ args[0] = "add--interactive";
+ memcpy((void *)args + sizeof(const char *), argv, sizeof(const char *) * argc);
+ args[argc + 1] = NULL;
+
+ status = run_command_v_opt(args, RUN_GIT_CMD);
+ free(args);
+ return status;
}
static struct lock_file lock_file;
@@ -163,17 +169,14 @@ static struct option builtin_add_options[] = {
int cmd_add(int argc, const char **argv, const char *prefix)
{
- int i, newfd, orig_argc = argc;
+ int i, newfd = argc;
const char **pathspec;
struct dir_struct dir;
argc = parse_options(argc, argv, builtin_add_options,
builtin_add_usage, 0);
- if (add_interactive) {
- if (add_interactive != 1 || orig_argc != 2)
- die("add --interactive does not take any parameters");
- exit(interactive_add());
- }
+ if (add_interactive)
+ exit(interactive_add(argc, argv));
git_config(git_default_config);
diff --git a/commit.h b/commit.h
index aa67986..d82b8bc 100644
--- a/commit.h
+++ b/commit.h
@@ -113,7 +113,7 @@ extern struct commit_list *get_shallow_commits(struct object_array *heads,
int in_merge_bases(struct commit *, struct commit **, int);
-extern int interactive_add(void);
+extern int interactive_add(int argc, const char **argv);
extern void add_files_to_cache(int verbose, const char *prefix, const char **files);
extern int rerere(void);
--
1.5.3.6.886.g3364
^ permalink raw reply related
* [PATCH 1/7] Add -q/--quiet switch to git-ls-files
From: Wincent Colaiuta @ 2007-11-23 19:20 UTC (permalink / raw)
To: git; +Cc: gitster, peff, Wincent Colaiuta
In-Reply-To: <1195845650-85962-1-git-send-email-win@wincent.com>
When using the --error-unmatch switch to git-ls-files you may only be
interested in the exit status rather than the actual listing that would
normally be printed to the stdout.
To make this kind of workflow easier, the -q/--quiet switch suppresses
all non-error output.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
---
Documentation/git-ls-files.txt | 7 ++++++-
builtin-ls-files.c | 12 +++++++++++-
t/t3020-ls-files-error-unmatch.sh | 12 ++++++++++++
3 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
index 2ec0c0d..33481b6 100644
--- a/Documentation/git-ls-files.txt
+++ b/Documentation/git-ls-files.txt
@@ -9,7 +9,7 @@ git-ls-files - Show information about files in the index and the working tree
SYNOPSIS
--------
[verse]
-'git-ls-files' [-z] [-t] [-v]
+'git-ls-files' [-z] [-t] [-v] [-q]
(--[cached|deleted|others|ignored|stage|unmerged|killed|modified])\*
(-[c|d|o|i|s|u|k|m])\*
[-x <pattern>|--exclude=<pattern>]
@@ -107,6 +107,11 @@ OPTIONS
Similar to `-t`, but use lowercase letters for files
that are marked as 'always matching index'.
+-q|--quiet::
+ Suppress all non-error output. This may be useful in conjunction
+ with --error-unmatch when you are only interested in the exit
+ status.
+
--full-name::
When run from a subdirectory, the command usually
outputs paths relative to the current directory. This
diff --git a/builtin-ls-files.c b/builtin-ls-files.c
index 7f60709..6c710a8 100644
--- a/builtin-ls-files.c
+++ b/builtin-ls-files.c
@@ -20,6 +20,7 @@ static int show_unmerged;
static int show_modified;
static int show_killed;
static int show_valid_bit;
+static int quiet;
static int line_terminator = '\n';
static int prefix_len;
@@ -83,6 +84,8 @@ static void show_dir_entry(const char *tag, struct dir_entry *ent)
if (pathspec && !match(pathspec, ps_matched, ent->name, len))
return;
+ if (quiet)
+ return;
fputs(tag, stdout);
write_name_quoted(ent->name + offset, stdout, line_terminator);
}
@@ -205,6 +208,8 @@ static void show_ce_entry(const char *tag, struct cache_entry *ce)
tag = alttag;
}
+ if (quiet)
+ return;
if (!show_stage) {
fputs(tag, stdout);
} else {
@@ -385,7 +390,8 @@ static void overlay_tree(const char *tree_name, const char *prefix)
}
static const char ls_files_usage[] =
- "git-ls-files [-z] [-t] [-v] (--[cached|deleted|others|stage|unmerged|killed|modified])* "
+ "git-ls-files [-z] [-t] [-v] [-q|--quiet] "
+ "(--[cached|deleted|others|stage|unmerged|killed|modified])* "
"[ --ignored ] [--exclude=<pattern>] [--exclude-from=<file>] "
"[ --exclude-per-directory=<filename> ] [--exclude-standard] "
"[--full-name] [--abbrev] [--] [<file>]*";
@@ -423,6 +429,10 @@ int cmd_ls_files(int argc, const char **argv, const char *prefix)
show_valid_bit = 1;
continue;
}
+ if (!strcmp(arg, "-q") || !strcmp(arg, "--quiet")) {
+ quiet = 1;
+ continue;
+ }
if (!strcmp(arg, "-c") || !strcmp(arg, "--cached")) {
show_cached = 1;
continue;
diff --git a/t/t3020-ls-files-error-unmatch.sh b/t/t3020-ls-files-error-unmatch.sh
index c83f820..5178322 100755
--- a/t/t3020-ls-files-error-unmatch.sh
+++ b/t/t3020-ls-files-error-unmatch.sh
@@ -23,5 +23,17 @@ test_expect_success \
'git ls-files --error-unmatch should succeed eith matched paths.' \
'git ls-files --error-unmatch foo bar'
+test_expect_success \
+ 'git ls-files -q --error-unmatch should be quiet with unmatched path.' \
+ 'git ls-files -q --error-unmatch foo bar-does-not-match 1> out 2> err ||
+ test $(cat out | wc -l) -eq 0 &&
+ test $(cat err | wc -l) -gt 0'
+
+test_expect_success \
+ 'git ls-files -q --error-unmatch should be quiet with matched paths.' \
+ 'git ls-files -q --error-unmatch foo bar 1> out 2> err ||
+ test $(cat out | wc -l) -eq 0 &&
+ test $(cat err | wc -l) -eq 0'
+
test_done
1
--
1.5.3.6.886.g3364
^ permalink raw reply related
* [PATCH 7/7] Teach builtin-add to handle "--patch" option
From: Wincent Colaiuta @ 2007-11-23 19:20 UTC (permalink / raw)
To: git; +Cc: gitster, peff, Wincent Colaiuta
In-Reply-To: <1195845650-85962-7-git-send-email-win@wincent.com>
Now builtin-add can take a "--patch" option; when found, it passes control
over to git-add--interactive, passing the --patch switch and the supplied
pathspecs.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
---
Documentation/git-add.txt | 5 +++++
builtin-add.c | 13 ++++++++-----
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 0b0ab1d..1acf10f 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -65,6 +65,11 @@ OPTIONS
operation to a subset of the files in the working tree.
See ``Interactive mode'' for details.
+-p, \--patch:
+ Similar to Interactive mode but the initial command loop is
+ bypassed and the 'patch' subcommand is invoked using each of
+ the specified filepatterns before exiting.
+
-u::
Update only files that git already knows about. This is similar
to what "git commit -a" does in preparation for making a commit,
diff --git a/builtin-add.c b/builtin-add.c
index 3646a45..c8335f1 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -19,6 +19,7 @@ static const char * const builtin_add_usage[] = {
"git-add [options] [--] <filepattern>...",
NULL
};
+static int patch_interactive = 0, add_interactive = 0;
static int take_worktree_changes;
@@ -138,10 +139,12 @@ static void refresh(int verbose, const char **pathspec)
int interactive_add(int argc, const char **argv)
{
int status;
- const char **args = xmalloc(sizeof(const char *) * (argc + 1));
+ int pre_argc = patch_interactive ? 2 : 1;
+ const char **args = xmalloc(sizeof(const char *) * (argc + pre_argc + 1));
args[0] = "add--interactive";
- memcpy((void *)args + sizeof(const char *), argv, sizeof(const char *) * argc);
- args[argc + 1] = NULL;
+ args[1] = "--patch";
+ memcpy((void *)args + sizeof(const char *) * pre_argc, argv, sizeof(const char *) * argc);
+ args[argc + pre_argc] = NULL;
status = run_command_v_opt(args, RUN_GIT_CMD);
free(args);
@@ -154,13 +157,13 @@ static const char ignore_error[] =
"The following paths are ignored by one of your .gitignore files:\n";
static int verbose = 0, show_only = 0, ignored_too = 0, refresh_only = 0;
-static int add_interactive = 0;
static struct option builtin_add_options[] = {
OPT__DRY_RUN(&show_only),
OPT__VERBOSE(&verbose),
OPT_GROUP(""),
OPT_BOOLEAN('i', "interactive", &add_interactive, "interactive picking"),
+ OPT_BOOLEAN('p', "patch", &patch_interactive, "interactive patching"),
OPT_BOOLEAN('f', NULL, &ignored_too, "allow adding otherwise ignored files"),
OPT_BOOLEAN('u', NULL, &take_worktree_changes, "update tracked files"),
OPT_BOOLEAN( 0 , "refresh", &refresh_only, "don't add, only refresh the index"),
@@ -175,7 +178,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
argc = parse_options(argc, argv, builtin_add_options,
builtin_add_usage, 0);
- if (add_interactive)
+ if (add_interactive || patch_interactive)
exit(interactive_add(argc, argv));
git_config(git_default_config);
--
1.5.3.6.886.g3364
^ permalink raw reply related
* [PATCH 6/7] Add "--patch" option to git-add--interactive
From: Wincent Colaiuta @ 2007-11-23 19:20 UTC (permalink / raw)
To: git; +Cc: gitster, peff, Wincent Colaiuta
In-Reply-To: <1195845650-85962-6-git-send-email-win@wincent.com>
When the "--patch" option is supplied, the patch_update_file function is
called, once for each supplied pathspec argument, and then we exit.
This commit adds an early return mechanism to the patch_update_pathspec
function to prevent spurious line feeds from being echoed when the user
passes in pathspecs which match unchanged files.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
---
git-add--interactive.perl | 35 ++++++++++++++++++++++++++++++++---
1 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 8706528..43a5344 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -1,6 +1,10 @@
#!/usr/bin/perl -w
use strict;
+use Getopt::Long;
+
+# command line options
+my $patch;
sub run_cmd_pipe {
if ($^O eq 'MSWin32') {
@@ -335,7 +339,8 @@ sub add_untracked_cmd {
sub parse_diff {
my ($path) = @_;
- my @diff = run_cmd_pipe(qw(git diff-files -p --), $path);
+ my @diff = run_cmd_pipe(qw(git diff-files -p --), $path)
+ or return undef;
my (@hunk) = { TEXT => [] };
for (@diff) {
@@ -571,6 +576,7 @@ sub patch_update_pathspec {
my ($ix, $num);
my $path = shift;
my ($head, @hunk) = parse_diff($path);
+ return unless $head;
for (@{$head->{TEXT}}) {
print;
}
@@ -781,6 +787,19 @@ sub check_args {
--error-unmatch --with-tree=HEAD --), @ARGV);
}
+sub usage {
+ print <<EOT;
+git-add--interactive [options] [--] [<filepattern>...]
+Options:
+ -p, --patch Execute the "patch" subcommand and exit
+EOT
+ exit(1);
+}
+
+sub process_options {
+ GetOptions("patch!" => \$patch) or usage();
+}
+
sub main_loop {
my @cmd = ([ 'status', \&status_cmd, ],
[ 'update', \&update_cmd, ],
@@ -809,7 +828,17 @@ sub main_loop {
}
}
+process_options();
refresh();
check_args();
-status_cmd();
-main_loop();
+if ($patch) {
+ print "No filepattern specified: what did you want to patch?\n"
+ unless @ARGV;
+ foreach my $pathspec (@ARGV) {
+ patch_update_pathspec($pathspec);
+ }
+}
+else {
+ status_cmd();
+ main_loop();
+}
--
1.5.3.6.886.g3364
^ permalink raw reply related
* [PATCH 4/7] Bail if user supplies an invalid pathspec
From: Wincent Colaiuta @ 2007-11-23 19:20 UTC (permalink / raw)
To: git; +Cc: gitster, peff, Wincent Colaiuta
In-Reply-To: <1195845650-85962-4-git-send-email-win@wincent.com>
Use git-ls-files to detect whether the user has supplied an invalid
pathspec.
Note that the run_cmd_pipe function unfortunately does not transmit the
exit status of the child process, so there is no way to use it in
conjunction with a command like "git-ls-files --error-unmatch".
The alternative is to use Perl's system() function, but that floods the
standard output. So here we make use of the new -q switch to git-ls-files
so that we can both obtain the exit status of the command and not have to
worry about the standard output. Error conditions are still echoed back to
the user because they come through on the standard error.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
---
git-add--interactive.perl | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 5fc48a5..8706528 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -775,6 +775,12 @@ add untracked - add contents of untracked files to the staged set of changes
EOF
}
+sub check_args {
+ return unless @ARGV;
+ exit $? if system(qw(git ls-files -q --exclude-standard
+ --error-unmatch --with-tree=HEAD --), @ARGV);
+}
+
sub main_loop {
my @cmd = ([ 'status', \&status_cmd, ],
[ 'update', \&update_cmd, ],
@@ -804,5 +810,6 @@ sub main_loop {
}
refresh();
+check_args();
status_cmd();
main_loop();
--
1.5.3.6.886.g3364
^ permalink raw reply related
* [PATCH 3/7] Add path-limiting to git-add--interactive
From: Wincent Colaiuta @ 2007-11-23 19:20 UTC (permalink / raw)
To: git; +Cc: gitster, peff, Wincent Colaiuta
In-Reply-To: <1195845650-85962-3-git-send-email-win@wincent.com>
Implement Junio's suggestion that git-add--interactive should reproduce the
path-limiting semantics of non-interactive git-add.
In otherwords, if "git add -i" (unrestricted) shows paths from a set A,
"git add -i paths..." should show paths from a subset of the set A and that
subset should be defined with the existing ls-files pathspec semantics.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
---
git-add--interactive.perl | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 81575e5..5fc48a5 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -37,7 +37,7 @@ sub list_untracked {
chomp $_;
$_;
}
- run_cmd_pipe(qw(git ls-files --others --exclude-standard --), @_);
+ run_cmd_pipe(qw(git ls-files --others --exclude-standard --), @ARGV);
}
my $status_fmt = '%12s %12s %s';
@@ -58,7 +58,7 @@ sub list_modified {
my ($add, $del, $adddel, $file);
for (run_cmd_pipe(qw(git diff-index --cached
- --numstat --summary HEAD))) {
+ --numstat --summary HEAD --), @ARGV)) {
if (($add, $del, $file) =
/^([-\d]+) ([-\d]+) (.*)/) {
my ($change, $bin);
@@ -81,7 +81,7 @@ sub list_modified {
}
}
- for (run_cmd_pipe(qw(git diff-files --numstat --summary))) {
+ for (run_cmd_pipe(qw(git diff-files --numstat --summary --), @ARGV)) {
if (($add, $del, $file) =
/^([-\d]+) ([-\d]+) (.*)/) {
if (!exists $data{$file}) {
--
1.5.3.6.886.g3364
^ permalink raw reply related
* [PATCH v2] git-add--interactive pathspec and patch additions
From: Wincent Colaiuta @ 2007-11-23 19:20 UTC (permalink / raw)
To: git; +Cc: gitster, peff
This is a revised series based on the feedback and suggestions
received to date. The purpose of the series is to implement these
two user-visible changes:
1. "git-add --interactive" now takes optional pathspec parameters
which can be used to limit the scope of an interactive session
2. We now have "git-add --patch" which takes you straight to the
"patch" subcommand using the given pathspecs and then exits
The series implements these changes in seven steps that apply on top of
"master"; these patches are rebased/squashed ones which *replace* the
ones sent the other day:
1. Add -q/--quiet switch to git-ls-files
Needed because run_cmd_pipe() doesn't propagate the child exit status
and system() likes to be chatty on the standard out. Of the possible
workarounds adding this switch seems to be the cleanest and most
portable.
2. Rename patch_update_file function to patch_update_pathspec
Merely cosmetic.
3. Add path-limiting to git-add--interactive
4. Bail if user supplies an invalid pathspec
For consistency with many other Git commands. It also shields us from
errors if the user starts passing funny pathspecs; eg. consider what
happens if the user passes a non-existent file "foo", and that
eventually hits git-diff-files; note how the error message changes
depending on where "foo" appears in the list:
$ git diff-files --numstat --summary --
1 0 git-commit.sh
$ git diff-files --numstat --summary -- .
1 0 git-commit.sh
$ git diff-files --numstat --summary -- . foo
error: Could not access ''
$ git diff-files --numstat --summary -- foo .
error: Could not access 'foo'
$ git diff-files --numstat --summary -- . . foo
1 0 git-commit.sh
5. Teach builtin-add to pass path arguments to git-add--interactive
6. Add "--patch" option to git-add--interactive
7. Teach builtin-add to handle "--patch" option
And that's all. Here's the diff stat:
Documentation/git-add.txt | 9 +++++-
Documentation/git-ls-files.txt | 7 ++++-
builtin-add.c | 28 ++++++++++++--------
builtin-ls-files.c | 12 ++++++++-
commit.h | 2 +-
git-add--interactive.perl | 52 +++++++++++++++++++++++++++++++-----
t/t3020-ls-files-error-unmatch.sh | 12 ++++++++
7 files changed, 99 insertions(+), 23 deletions(-)
^ permalink raw reply
* [PATCH 2/7] Rename patch_update_file function to patch_update_pathspec
From: Wincent Colaiuta @ 2007-11-23 19:20 UTC (permalink / raw)
To: git; +Cc: gitster, peff, Wincent Colaiuta
In-Reply-To: <1195845650-85962-2-git-send-email-win@wincent.com>
The patch_update_file function really works on pathspecs, not files, so
rename it to reflect its actual purpose.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
---
git-add--interactive.perl | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index fb1e92a..81575e5 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -564,10 +564,10 @@ sub patch_update_cmd {
IMMEDIATE => 1,
HEADER => $status_head, },
@mods);
- patch_update_file($it->{VALUE}) if ($it);
+ patch_update_pathspec($it->{VALUE}) if ($it);
}
-sub patch_update_file {
+sub patch_update_pathspec {
my ($ix, $num);
my $path = shift;
my ($head, @hunk) = parse_diff($path);
--
1.5.3.6.886.g3364
^ permalink raw reply related
* Re: Wishlist for a bundle-only transport mode
From: Jakub Narebski @ 2007-11-23 19:09 UTC (permalink / raw)
To: Santi Béjar; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <8aa486160711230734l30a3e907rac5aee11f3518e88@mail.gmail.com>
On Fri, 23 Nov 2007, Santi Béjar wrote:
> On Nov 23, 2007 4:06 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> "Santi Béjar" <sbejar@gmail.com> writes:
>>
>>> OK. So git push will never understand bundles.
>>
>> Why not?
>
> Sorry, I misunderstood you, because pushing to an existing
> bundle loses information, and that is also inconsistent with pushing
> to regular repositories.
Pushing to regular repositories _adds_ information (adds objects
and advances refs). Junio proposed that "git push <bundle>" do the
same, which means getting refs from bundle, and adding objects
to bundle creating new bundle, which contain all the old one has,
and all what was created since then. What information would be lost?
Johannes provided alternate solution which you can use even now,
namely how to create "incremental" bundle, which has all objects
since last bundle was created. But this does not play with the way
push works with ordinary, regular repositories.
P.S. Code speaks louder than words ;-)
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] Add config_int() method to the Git perl module
From: Jakub Narebski @ 2007-11-23 18:04 UTC (permalink / raw)
To: git
Integer variables can have optional 'k', 'm' or 'g' suffix.
config_int() method will return simple decimal number, taking
care of those suffixes.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
For completness (I don't think anything in Perl uses / tries to use
integer configuration variables).
(Commit message could be better. Hmmm...)
perl/Git.pm | 31 +++++++++++++++++++++++++++++++
1 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/perl/Git.pm b/perl/Git.pm
index dca92c8..7468460 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -549,6 +549,37 @@ sub config_bool {
};
}
+=item config_int ( VARIABLE )
+
+Retrieve the integer configuration C<VARIABLE>. The return value
+is simple decimal number. An optional value suffix of 'k', 'm',
+or 'g' in the config file will cause the value to be multiplied
+by 1024, 1048576 (1024^2), or 1073741824 (1024^3) prior to output.
+It would return C<undef> if configuration variable is not defined,
+
+Must be called on a repository instance.
+
+This currently wraps command('config') so it is not so fast.
+
+=cut
+
+sub config_int {
+ my ($self, $var) = @_;
+ $self->repo_path()
+ or throw Error::Simple("not a repository");
+
+ try {
+ return $self->command_oneline('config', '--int', '--get', $var);
+ } catch Git::Error::Command with {
+ my $E = shift;
+ if ($E->value() == 1) {
+ # Key not found.
+ return undef;
+ } else {
+ throw $E;
+ }
+ };
+}
=item ident ( TYPE | IDENTSTR )
--
1.5.3.5
^ permalink raw reply related
* Re: [PATCH] Don't add To: recipients to the Cc: header
From: Sergei Organov @ 2007-11-23 17:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ask Bjørn Hansen, git
In-Reply-To: <7vr6ikk6rf.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Sergei Organov <osv@javad.com> writes:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>> [...]
>>> Oops, forgot to say "no need to resend". I asked only because I
>>> wanted an independent datapoint for Emacs diff mode breakage.
>>
>> I bet I can damage any patch using any editor ;)
>>
>> More interesting is what version of Emacs it was?
>
> To be fair and honest, I do not think there is a simple fix for
> this, although it probably is possible to fix it.
>
> What is causing the "breakage" is the fact that format-patch
> output ends with the signature delimiter line "^-- $" that
> immediately follows the patch text.
Exactly. What causes breakage is the fact that the '-' character (as
well as '+', ' ', '!', '#', and '\'), being the first symbol of a line
has special meaning in the diff format.
Therefore it seems that format-patch should better put one empty line
after the last diff hunk and before the signature. Any objections?
--
Sergei.
^ permalink raw reply
* Re: Wishlist for a bundle-only transport mode
From: Santi Béjar @ 2007-11-23 16:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, Johannes Schindelin, git
In-Reply-To: <7v63ztuevk.fsf@gitster.siamese.dyndns.org>
On Nov 23, 2007 5:05 PM, Junio C Hamano <gitster@pobox.com> wrote:
> "Santi Béjar" <sbejar@gmail.com> writes:
>
> >> > OK. So git push will never understand bundles.
> >>
> >> Why not?
> >
> > Sorry, I misunderstood you, because pushing to an existing
> > bundle loses information, and that is also inconsistent with pushing
> > to regular repositories.
>
> Maybe I am missing something from the discussion, but what
> information loss are you referring to?
>
Because you create an incremental bundle, so all the objects in the
old bundle will
not be in the new bundle. But it can be considered the natural
behavior of bundles.
But anyway, pushing to an existing bundle is not very convenient (at
leas for me) because it forces you to keep the bundles. I think the
most convenient way would be to have remote tracking branching to
record the bases for future bundles.
For now, I will do an script that behaves like the "git bundle push"
that I described and then I'll report the pro/cons that it has.
Thank you all for the discussion, it was very fruitful.
Santi
P.D.: Am I the only one doing a bundle-only transport mode? If not,
can you comment on the different suggestions that have been said.
Thanks a lot.
^ permalink raw reply
* Re: Wishlist for a bundle-only transport mode
From: Junio C Hamano @ 2007-11-23 16:05 UTC (permalink / raw)
To: Santi Béjar; +Cc: Junio C Hamano, Jakub Narebski, Johannes Schindelin, git
In-Reply-To: <8aa486160711230734l30a3e907rac5aee11f3518e88@mail.gmail.com>
"Santi Béjar" <sbejar@gmail.com> writes:
>> > OK. So git push will never understand bundles.
>>
>> Why not?
>
> Sorry, I misunderstood you, because pushing to an existing
> bundle loses information, and that is also inconsistent with pushing
> to regular repositories.
Maybe I am missing something from the discussion, but what
information loss are you referring to?
^ 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