* Re: [PATCH/resent 0/9] Sparse checkout (first half)
From: Santi Béjar @ 2008-10-01 10:20 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Shawn O. Pearce
In-Reply-To: <1222833849-22129-1-git-send-email-pclouds@gmail.com>
Not in this half but I've seen that you added a --default-sparse flag
to "git clone". I think it is useless as mostly always the one given
in -sparse-checkout should be used.
Thanks
Santi
On Wed, Oct 1, 2008 at 6:04 AM, Nguyễn Thái Ngọc Duy <pclouds@gmail.com> wrote:
> This is the first half of the series, making git ready for sparse
> checkout. The only difference from the last (first half) sent
> series is safeguard bitmask fix in 1/9
>
> Nguyễn Thái Ngọc Duy (9):
> Extend index to save more flags
> Introduce CE_NO_CHECKOUT bit
> ls-files: add options to support sparse checkout
> update-index: refactor mark_valid() in preparation for new options
> update-index: add --checkout/--no-checkout to update CE_NO_CHECKOUT
> bit
> ls-files: Add tests for --sparse and friends
> Prevent diff machinery from examining worktree outside sparse
> checkout
> checkout_entry(): CE_NO_CHECKOUT on checked out entries.
> grep: skip files outside sparse checkout area
>
> .gitignore | 1 +
> Documentation/git-checkout.txt | 34 +++++++++++++++++
> Documentation/git-grep.txt | 4 +-
> Documentation/git-ls-files.txt | 24 +++++++++++-
> Documentation/git-update-index.txt | 13 ++++++
> Makefile | 2 +-
> builtin-grep.c | 7 +++-
> builtin-ls-files.c | 41 ++++++++++++++++++--
> builtin-update-index.c | 40 ++++++++++++-------
> cache.h | 66 +++++++++++++++++++++++++++++++--
> diff-lib.c | 5 +-
> diff.c | 4 +-
> entry.c | 1 +
> read-cache.c | 57 ++++++++++++++++++++++------
> t/t2104-update-index-no-checkout.sh | 36 ++++++++++++++++++
> t/t3004-ls-files-sparse.sh | 40 ++++++++++++++++++++
> t/t3004/cached.expected | 5 ++
> t/t3004/deleted.expected | 1 +
> t/t3004/everything.expected | 10 +++++
> t/t3004/modified.expected | 2 +
> t/t3004/no-checkout.expected | 2 +
> t/t3004/orphaned-no-checkout.expected | 3 +
> t/t3004/orphaned.expected | 1 +
> t/t3004/others.expected | 2 +
> t/t3004/sparse-cached.expected | 3 +
> t/t3004/sparse-everything.expected | 11 +++++
> test-index-version.c | 14 +++++++
> 27 files changed, 385 insertions(+), 44 deletions(-)
> create mode 100755 t/t2104-update-index-no-checkout.sh
> create mode 100755 t/t3004-ls-files-sparse.sh
> create mode 100644 t/t3004/cached.expected
> create mode 100644 t/t3004/deleted.expected
> create mode 100644 t/t3004/everything.expected
> create mode 100644 t/t3004/modified.expected
> create mode 100644 t/t3004/no-checkout.expected
> create mode 100644 t/t3004/orphaned-no-checkout.expected
> create mode 100644 t/t3004/orphaned.expected
> create mode 100644 t/t3004/others.expected
> create mode 100644 t/t3004/sparse-cached.expected
> create mode 100644 t/t3004/sparse-everything.expected
> create mode 100644 test-index-version.c
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: obscure platform autobuilders
From: Mike Ralphson @ 2008-10-01 10:46 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20081001071653.GA21174@sigill.intra.peff.net>
2008/10/1 Jeff King <peff@peff.net>:
> On Mon, Sep 29, 2008 at 08:51:29AM +0100, Mike Ralphson wrote:
>> Feel free to push changes to gitbuild.sh, including getting rid of
>> anything which looks environment-specific.
>
> I actually went a step further and revamped the architecture a bit.
> Check out the "platform" branch in gitbuild.git. My goal was to try to
> include more information in the gitbuild repository about exactly what
> goes into the test setup for each platform.
Very nice!
> I'm currently building, testing, and pushing FreeBSD 6.1 and Solaris 2.8
> with it (you can see the copious tests I am skipping in
> jk/solaris/config).
My googling led me to think that INTERNAL_QSORT would be a good idea
on at least some versions of Solaris... it may depend on the fs
though.
> If you like this approach, please go ahead and add an "mr/aix" profile
> with your setup. See the README for details, and let me know if you have
> questions. The script is a mish-mash of yours, mine, and some extra
> rewrites. I wouldn't be surprised if it needs a tweak or two. :)
How about this - let me know if ok, and I'll push it.
diff --git a/README b/README
index 184de11..e91037f 100644
--- a/README
+++ b/README
@@ -10,7 +10,8 @@ several files:
- 'config', a shell script sourced by the build script to override any
variables. See below for more information.
- - 'branches', a list of branches, one per line, to build and test
+ - 'branches', a list of branches, one per line, to build and test.
+ Lines starting with # are treated as comments
- 'gitconfig'; if this file exists, it will be used as the .git/config
of the built and tested repository. This file should define a remote
@@ -18,7 +19,16 @@ several files:
should be published (i.e., repo.or.cz:/srv/git/git/gitbuild.git).
- 'config.mak'; if this file exists, it will be used as the config.mak
- file for building git
+ file for building git. If it is not present, but there is a
+ config.mak file in your project directory, it is copied here to
+ prevent it being removed by 'git clean'
+
+ - 'catch', a shell script sourced by the build script if an error
+ occurs. It is passed the failing command-line in its arguments
+
+ - 'finally', a shell script sourced by the build script at the end
+ of the process. It is passed the exit code of build.sh as its
+ argument
The convention for platform directory names is "$initials/$platform". A
build should be initiated from the platform directory. E.g., by putting
@@ -42,6 +52,9 @@ the variables are:
- make; the command to invoke make. If not set, defaults to "gmake".
+ - project; the path to the directory to build in. If not set, defaults
+ to ./project relative to the starting directory
+
- path_build; the PATH to use while building git. If not set, the
PATH is left alone.
@@ -52,8 +65,8 @@ Invoking build.sh
=================
Generally build.sh is invoked without any options, which means it should
-build all branches one after the other. However, it can be invoked with
-a branch name to build and test just a single branch.
+build all specified branches one after the other. However, it can be
+invoked with a branch name to build and test just a single branch.
The 'project' directory need not be set up beforehand. If it does not
exist, it will be created as an empty git repository automatically. As
diff --git a/build.sh b/build.sh
index b318af2..0967ff3 100755
--- a/build.sh
+++ b/build.sh
@@ -9,6 +9,7 @@ root=$PWD
initials=`dirname $PWD 2>/dev/null`; initials=`basename $initials 2>/dev/null`
name=`basename $PWD 2>/dev/null`
make=gmake
+project=project
. ./config
name=`echo $name | sed 's/[^A-Za-z0-9.-]/-/g'`
@@ -19,6 +20,8 @@ try() {
0) ;;
*) echo >&2 "build failed: $*"
cat >&2 "$log"
+ test -f $root/catch && . $root/catch $*
+ test -f $root/finally && . $root/finally 1
exit 1
;;
esac
@@ -36,6 +39,7 @@ build_branch() {
rm -f "$log"
try git checkout -f -q $branch
+ test -f config.mak && test ! -f $root/config.mak && try cp config.mak $root/
try git clean -d -f -q -x
test -f $root/config.mak && try cp $root/config.mak config.mak
@@ -59,22 +63,23 @@ build_branch() {
log=$root/log.build
rm -f "$log"
-if ! test -d project; then
- try mkdir project
- try cd project
+if ! test -d $project; then
+ try mkdir $project
+ try cd $project
try git init
else
- try cd project
+ try cd $project
fi
test -f $root/gitconfig && try cp $root/gitconfig .git/config
try git remote update
if test -z "$1"; then
- for i in `cat "$root/branches"`; do
+ for i in `cat "$root/branches" | grep -v '^#'`; do
build_branch $i || exit 1
done
else
build_branch $1
fi
+test -f $root/finally && . $root/finally 0
exit 0
^ permalink raw reply related
* Re: [PATCH/resent 0/9] Sparse checkout (first half)
From: Santi Béjar @ 2008-10-01 11:25 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Shawn O. Pearce
In-Reply-To: <adf1fd3d0810010320v340230f0jb443bafc1ef05d6f@mail.gmail.com>
On Wed, Oct 1, 2008 at 12:20 PM, Santi Béjar <santi@agolina.net> wrote:
> Not in this half but I've seen that you added a --default-sparse flag
> to "git clone". I think it is useless as mostly always the one given
> in -sparse-checkout should be used.
To be more precise, whenever you do "git clone --sparse-checkout" you
will want it to be the default sparse pattern.
Best regards,
Santi
^ permalink raw reply
* Re: [PATCH (GIT-GUI,GITK) 0/8] Encoding support in GUI
From: Johannes Sixt @ 2008-10-01 11:35 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Alexander Gavrilov, git, Shawn O. Pearce
In-Reply-To: <18646.53492.20994.908025@cargo.ozlabs.ibm.com>
Paul Mackerras schrieb:
> Alexander Gavrilov writes:
>> 3) It can be further set on per-file basis by specifying
>> the 'encoding' attribute in gitattributes.
>
> I haven't used .gitattributes before, but I would expect that the
> .gitattributes files would be stored in the repository along with
> everything else. If that's the case, then for gitk at least there is
> the question of which version of a given .gitattributes file one
> should use when viewing the tree for a commit which isn't the
> currently checked-out commit - do you use the version from that tree,
> or the version in the working directory? We seem to be using the
> latter at present, and caching the results. Is there a philosophical
> reason to do that, other than speed?
I understand your concerns that an encoding may be picked from the "wrong"
.gitattributes file. But in practice it doesn't matter much, and picking
the attribute from a past commit's tree would even be counter-productive:
I'm about to add a .gitattributes file that specifies the encoding for
some of my files *today* because I was not clever enough to anticipate the
usefulness of an "encoding" attribute a year ago when those files were
added to the repository. When I browse history, I *do* want that *today's*
encoding is picked.
> (Also it seems that we won't
> notice if the user changes .gitattributes after we've looked at it, or
> if they create one after we've looked for one and not found it.)
This is not a show stopper, IMHO. The user will notice soon enough, and
can restart gitk. Nobody sane will change the encoding attributes every hour.
That said, a menu command to flush the attribute cache would be useful
every now and then.
-- Hannes
^ permalink raw reply
* Re: [PATCH/resent 0/9] Sparse checkout (first half)
From: Nguyen Thai Ngoc Duy @ 2008-10-01 12:09 UTC (permalink / raw)
To: Santi Béjar; +Cc: git, Shawn O. Pearce
In-Reply-To: <adf1fd3d0810010425r145396b0t52cf883576da8bbd@mail.gmail.com>
On 10/1/08, Santi Béjar <santi@agolina.net> wrote:
> On Wed, Oct 1, 2008 at 12:20 PM, Santi Béjar <santi@agolina.net> wrote:
> > Not in this half but I've seen that you added a --default-sparse flag
> > to "git clone". I think it is useless as mostly always the one given
> > in -sparse-checkout should be used.
>
>
> To be more precise, whenever you do "git clone --sparse-checkout" you
> will want it to be the default sparse pattern.
Yes, if only the default pattern gets updated properly when you update
your checkout area. If "git clone --sparse-checkout" makes the default
pattern, then "git checkout --reset-sparse" should reset the default
pattern as well. The hard part is how to update default pattern with
--include-sparse and --exclude-sparse. Also, people can use "git
update-index" to update checkout area, which should not touch default
pattern at all. Maybe just throw a warning when default pattern no
longer matches the checkout area, then let them decide.
--
Duy
^ permalink raw reply
* Re: [PATCH] git grep: Add "-Z/--null" option as in GNU's grep.
From: Johannes Schindelin @ 2008-10-01 13:15 UTC (permalink / raw)
To: Raphael Zimmerer; +Cc: Shawn O. Pearce, git
In-Reply-To: <20080930234157.GA1453@rdrz.de>
Hi,
On Wed, 1 Oct 2008, Raphael Zimmerer wrote:
> On Tue, Sep 30, 2008 at 04:16:19PM -0700, Shawn O. Pearce wrote:
> > Elsewhere in Git we call this "-z", like "git ls-tree -z", "git log
> > -z". Should we match grep or git convention here?
>
> I'd tend to grep's convention, as most options of git-grep mimic those
> of grep. grep uses "-z" for \0 on _input_, so that would be very
> confusing for grep users...
I tend to disagree. Git is _already_ perceived as too heterogenous, and
we should not add to that pile.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git grep: Add "-Z/--null" option as in GNU's grep.
From: Raphael Zimmerer @ 2008-10-01 13:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, git
In-Reply-To: <alpine.DEB.1.00.0810011514530.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On Wed, Oct 01, 2008 at 03:15:34PM +0200, Johannes Schindelin wrote:
> On Wed, 1 Oct 2008, Raphael Zimmerer wrote:
> > On Tue, Sep 30, 2008 at 04:16:19PM -0700, Shawn O. Pearce wrote:
> > > Elsewhere in Git we call this "-z", like "git ls-tree -z", "git log
> > > -z". Should we match grep or git convention here?
> >
> > I'd tend to grep's convention, as most options of git-grep mimic those
> > of grep. grep uses "-z" for \0 on _input_, so that would be very
> > confusing for grep users...
>
> I tend to disagree. Git is _already_ perceived as too heterogenous, and
> we should not add to that pile.
How about discarding "-Z" from my patch, and only leave in "--null"?
That removes ambiguity _and_ is compatible to GNU grep.
- Raphael
^ permalink raw reply
* [TG PATCH] README: Fix spelling and reflect recent depend support
From: Jonas Fonseca @ 2008-10-01 14:07 UTC (permalink / raw)
To: Petr Baudis, Petr Baudis; +Cc: git
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
README | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/README b/README
index 35a9f98..903face 100644
--- a/README
+++ b/README
@@ -22,7 +22,7 @@ version control of patches (reordering of patches is not
version-controlled at all). But there are several disadvantages -
for one, these tools (especially StGIT) do not actually fit well
with plain Git at all: it is basically impossible to take advantage
-of the index efectively when using StGIT. But more importantly,
+of the index effectively when using StGIT. But more importantly,
these tools horribly fail in the face of distributed environment.
TopGit has been designed around three main tenets:
@@ -45,7 +45,7 @@ them.
As mentioned above, the main intended use-case for TopGit is tracking
third-party patches, where each patch is effectively a single topic
-branch. In order to flexibly accomodate even complex scenarios when
+branch. In order to flexibly accommodate even complex scenarios when
you track many patches where many are independent but some depend
on others, TopGit ignores the ancient Quilt heritage of patch series
and instead allows the patches to freely form graphs (DAGs just like
@@ -252,6 +252,7 @@ tg delete
depending on it.
TODO: '-a' to delete all empty branches, depfix, revert
+ TODO: subcommand removing dependencies smoothly
tg depend
~~~~~~~~~
@@ -344,7 +345,7 @@ tg export
in the cleaned up history (corresponding basically exactly
to `tg patch` output for the topic branch).
- The command has two posible outputs now - either a Git branch
+ The command has two possible outputs now - either a Git branch
with the collapsed history, or a quilt series in new directory.
In case of producing collapsed history in new branch,
@@ -449,7 +450,6 @@ tg update
TODO: tg update -a for updating all topic branches
-TODO: tg depend for adding/removing dependencies smoothly
TODO: tg rename
@@ -479,10 +479,10 @@ whatever Cc headers you choose or the post-three-dashes message.
When mailing out your patch, basically only few extra headers
mail headers are inserted and the patch itself is appended.
Thus, as your patches evolve, you can record nuances like whether
-the paricular patch should have To-list/Cc-maintainer or vice
+the particular patch should have To-list/Cc-maintainer or vice
versa and similar nuances, if your project is into that.
-From is prefilled from your current GIT_AUTHOR_IDENT, other headers
-can be prefilled from various optional topgit.* config options.
+From is pre-filled from your current GIT_AUTHOR_IDENT, other headers
+can be pre-filled from various optional topgit.* config options.
.topdeps: Contains the one-per-line list of branches
your patch depends on, pre-seeded with `tg create`. (Continuously
--
tg: (67ae5b2..) jf/readme-update (depends on: master)
^ permalink raw reply related
* Re: [EGIT PATCH 2/8] Move AWTPlotRenderer to its own file.
From: Shawn O. Pearce @ 2008-10-01 14:32 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1222818823-22780-2-git-send-email-robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> This is mostly a convenience issue as it allows the
> use of the JVM hotswap feature while debugging.
>
> Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
> ---
> .../org/spearce/jgit/awtui/AWTPlotRenderer.java | 104 ++++++++++++++++++++
> .../org/spearce/jgit/awtui/CommitGraphPane.java | 92 -----------------
> 2 files changed, 104 insertions(+), 92 deletions(-)
> create mode 100644 org.spearce.jgit/src/org/spearce/jgit/awtui/AWTPlotRenderer.java
>
> diff --git a/org.spearce.jgit/src/org/spearce/jgit/awtui/AWTPlotRenderer.java b/org.spearce.jgit/src/org/spearce/jgit/awtui/AWTPlotRenderer.java
> new file mode 100644
> index 0000000..a9933a4
> --- /dev/null
> +++ b/org.spearce.jgit/src/org/spearce/jgit/awtui/AWTPlotRenderer.java
> @@ -0,0 +1,104 @@
> +/**
> + *
> + */
> +package org.spearce.jgit.awtui;
Missing copyright from the old sources. Please carry over the
existing copyright header.
--
Shawn.
^ permalink raw reply
* Re: [EGIT PATCH 3/8] Dispose of allocated colors on finalize()
From: Shawn O. Pearce @ 2008-10-01 14:37 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1222818823-22780-3-git-send-email-robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> ---
Missing SBO.
> .../egit/ui/internal/history/SWTPlotRenderer.java | 11 +++++++++++
> 1 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/SWTPlotRenderer.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/SWTPlotRenderer.java
> index 23ec255..a58b3bf 100644
> --- a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/SWTPlotRenderer.java
> +++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/SWTPlotRenderer.java
> @@ -45,6 +45,17 @@ SWTPlotRenderer(final Display d) {
> sys_darkblue = d.getSystemColor(SWT.COLOR_DARK_BLUE);
> }
>
> + @Override
> + protected void finalize() throws Throwable {
> + sys_black.dispose();
> + sys_blue.dispose();
> + sys_gray.dispose();
> + sys_darkblue.dispose();
> + sys_yellow.dispose();
> + sys_green.dispose();
> + sys_white.dispose();
> + }
I think this is wrong. Any color that we get from
Display.getSystemColor() must not be disposed of by the application,
its in use by the Display and/or other parts of the application.
>From the Javadocs:
This color should not be free'd because it was allocated by the
system, not the application.
I take that to mean that the color should not be disposed of.
Though reading the Gtk SWT sources it seems that the system color
objects aren't pooled, each call to getSystemColor causes a new
Color instace to be allocated. So it may be harmless on Gtk.
What was the rationale for disposing of these resources? Did you
identify that this is a resource leak somewhere? Because I'd like
to make sure I actually understand the SWT resource model better
so I don't commit mistakes in the future.
--
Shawn.
^ permalink raw reply
* Re: [EGIT PATCH 4/8] Align commit text properly in jgit glog
From: Shawn O. Pearce @ 2008-10-01 14:38 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1222818823-22780-4-git-send-email-robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
> ---
> .../egit/ui/internal/history/SWTPlotRenderer.java | 3 ---
> .../org/spearce/jgit/awtui/AWTPlotRenderer.java | 7 +++----
> 2 files changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/SWTPlotRenderer.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/SWTPlotRenderer.java
> index a58b3bf..7c286a4 100644
> --- a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/SWTPlotRenderer.java
> +++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/SWTPlotRenderer.java
> @@ -51,9 +51,6 @@ protected void finalize() throws Throwable {
> sys_blue.dispose();
> sys_gray.dispose();
> sys_darkblue.dispose();
> - sys_yellow.dispose();
> - sys_green.dispose();
> - sys_white.dispose();
> }
Can't you squash this hunk to the prior commit, assuming the prior
commit is still a valid change?
--
Shawn.
^ permalink raw reply
* Re: [PATCH/resent 0/9] Sparse checkout (first half)
From: Santi Béjar @ 2008-10-01 14:38 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git, Shawn O. Pearce
In-Reply-To: <fcaeb9bf0810010509m4d2045e4qcc2a887c180a787@mail.gmail.com>
On Wed, Oct 1, 2008 at 2:09 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> On 10/1/08, Santi Béjar <santi@agolina.net> wrote:
>> On Wed, Oct 1, 2008 at 12:20 PM, Santi Béjar <santi@agolina.net> wrote:
>> > Not in this half but I've seen that you added a --default-sparse flag
>> > to "git clone". I think it is useless as mostly always the one given
>> > in -sparse-checkout should be used.
>>
>>
>> To be more precise, whenever you do "git clone --sparse-checkout" you
>> will want it to be the default sparse pattern.
>
> Yes, if only the default pattern gets updated properly when you update
> your checkout area.
I don't parse this sentence, but I cannot see the connection between
the default sparse pattern for _clone_ and updating it or the working
area.
> If "git clone --sparse-checkout" makes the default
> pattern, then "git checkout --reset-sparse" should reset the default
> pattern as well.
Makes sense.
> The hard part is how to update default pattern with
> --include-sparse and --exclude-sparse.
Maybe you could let the core.defaultsparse be defined multiple times.
[core]
defaultsparse = Documentation/*
defaultsparse = t/*
defaultsparse = !t/*svn*
equivalent to
[core]
defaultsparse = Documentation/*:t/*:!t/*svn*
but it moves the complexity to the parsing of the config.
> Also, people can use "git
> update-index" to update checkout area, which should not touch default
> pattern at all.
I would prefer having a --not-update-sparse-pattern.
The most common workflow should be the most straightforward. The most
common use-case would be somebody working _only_ in some subdirectory
(say Documentation), then what s/he normally does is:
1) cloning and default sparse chechout:
$ git clone --sparse-checkout=Documentation/* ...
or within an existing wd
$ git checkout --reset-sparse=Documentation/* ...
(maybe just --sparse?)
2) Work normally inside the Documentation directory...
3) Abort a merge with conflicts outside the sparse area:
$ git reset --hard ORIG_HEAD)
<Now there are files outside the default sparse area>
$ git checkout --reset-sparse # with --sparse to set the sparse pattern
Including/excluding more paths in the default sparse checkout is not
something you would do normally, but I think it makes sense to add
them to the default pattern.
Please correct me if you think there are other use-cases, or more
things in my use-case.
> Maybe just throw a warning when default pattern no
> longer matches the checkout area, then let them decide.
Sure, and inform in the "git status" that you are in a sparse checkout.
Best regards,
Santi
^ permalink raw reply
* Re: [PATCH] git grep: Add "-Z/--null" option as in GNU's grep.
From: Shawn O. Pearce @ 2008-10-01 14:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Raphael Zimmerer, git
In-Reply-To: <alpine.DEB.1.00.0810011514530.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Wed, 1 Oct 2008, Raphael Zimmerer wrote:
>
> > On Tue, Sep 30, 2008 at 04:16:19PM -0700, Shawn O. Pearce wrote:
> > > Elsewhere in Git we call this "-z", like "git ls-tree -z", "git log
> > > -z". Should we match grep or git convention here?
> >
> > I'd tend to grep's convention, as most options of git-grep mimic those
> > of grep. grep uses "-z" for \0 on _input_, so that would be very
> > confusing for grep users...
>
> I tend to disagree. Git is _already_ perceived as too heterogenous, and
> we should not add to that pile.
I already have my brain wired that "\0 terminators in Git are -z".
Thus I'd assume "git grep -z .. | xargs -0" would work. Today it
doesn't without this patch, but if the patch was added I'd assume
it would work.
Perhaps I'm too close to git as a contributor and experienced user
to realize any brain damage.
I'd rather stick to "-z" in Git. At least its consistent.
Its not like tools outside of Git are all that consistent. GNU
grep uses --null/-Z. xargs and perl use -0. find uses -print0.
The human at the keyboard already has to navigate this rats nest
between different tools, but within a tool (git) we should be as
consistent as we can.
--
Shawn.
^ permalink raw reply
* Re: interactive rebase not rebasing
From: Stephen Haberman @ 2008-10-01 14:52 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <48E32BD4.1050107@op5.se>
> >> I don't think you can have a single command that does all the
> >> things you want, because the possible differences in input makes it
> >> very nearly impossible to always do "the right thing".
> >
> > Ah, you are too pessimistic. :-)
> >
>
> Perhaps, although I think you're being overly optimistic if you think
> rebase can do all of this intelligently while still retaining clear
> semantics. I'd start with writing a separate tool for it, probably
> based on git sequencer.
I would agree with this, except that --preserve-merges is already in
the codebase and does what we want. I'm not fundamentally changing how
it works (e.g. how it decides what commits to keep/rewrite/etc.), I just
found and patched a bug in it.
> When that works out ok, get it to do what rebase does today and then
> incorporate the new tool as an option to rebase and get ready to
> answer complex questions for the cases where it doesn't do what the
> user wanted it to do.
Yeah, I'm sorry, I did not mean my "pessimistic" comment that
seriously. I understand `git rebase` can never do what everyone wants
in all scenarios.
But given /this/ scenario (hehe), with the implementation's existing
explicit usage of "--left-right --cherry-pick" to drop no-op commits,
but then it's forgetting of this information later, leading to `git
rebase` not performing a rebase at all, I think it is an obvious bug,
and one that can be fixed without changing any of `git rebase`s
existing semantics.
> Merely that you should think hard about it and then make sure it
> doesn't break anything people are already doing today with the current
> toolset.
I've attempted to do that. Now that I sent in the patch, if you could
review it, I would appreciate your feedback. I do need to rework the
test case because I realized including the origin/pull aspects (which
is what caused us to find it) is just noise and the bug can be
reproduced with just local branches.
Thanks,
Stephen
^ permalink raw reply
* Re: [PATCH 1/3] parse-opt: migrate fmt-merge-msg.
From: Shawn O. Pearce @ 2008-10-01 14:56 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git, gitster
In-Reply-To: <1222841106-26148-1-git-send-email-madcoder@debian.org>
Pierre Habouzit <madcoder@debian.org> wrote:
> @@ -347,38 +349,32 @@ int fmt_merge_msg(int merge_summary, struct strbuf *in, struct strbuf *out) {
>
> int cmd_fmt_merge_msg(int argc, const char **argv, const char *prefix)
> {
> + const char *inpath = NULL;
> + struct option options[] = {
> + OPT_BOOLEAN(0, "log", &merge_summary, "populate log with the shortlog"),
> + OPT_BOOLEAN(0, "summary", &merge_summary, "alias for --log"),
> + OPT_STRING('F', "file", &inpath, "file", "file to read from"),
> + OPT_END()
> + argc = parse_options(argc, argv, options, fmt_merge_msg_usage, 0);
> + if (argc > 0)
> + usage_with_options(fmt_merge_msg_usage, options);
> +
> + if (!inpath || strcmp(inpath, "-"))
> + in = stdin;
> + else {
> + fclose(in);
> + in = fopen(argv[2], "r");
> + if (!in)
> + die("cannot open %s", argv[2]);
Really argv[2]? Shouldn't that be inpath?
--
Shawn.
^ permalink raw reply
* Re: [PATCH 3/3] parse-opt: migrate builtin-merge-file.
From: Shawn O. Pearce @ 2008-10-01 15:01 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git, gitster
In-Reply-To: <1222841106-26148-3-git-send-email-madcoder@debian.org>
Pierre Habouzit <madcoder@debian.org> wrote:
> diff --git a/builtin-merge-file.c b/builtin-merge-file.c
> index 45c9853..7736fe8 100644
> --- a/builtin-merge-file.c
> +++ b/builtin-merge-file.c
> @@ -2,21 +2,44 @@
...
> +static int label_cb(const struct option *opt, const char *arg, int unset)
> +{
> + static int label_count = 0;
> + const char **names = (const char **)opt->value;
> +
> + if (label_count >= 3)
> + return error("too many labels on the command like");
Typo on "command line".
--
Shawn.
^ permalink raw reply
* Re: [PATCH] git grep: Add "-Z/--null" option as in GNU's grep.
From: Shawn O. Pearce @ 2008-10-01 15:03 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Raphael Zimmerer, git
In-Reply-To: <20081001061249.GC22363@artemis.corp>
Pierre Habouzit <madcoder@debian.org> wrote:
> On Tue, Sep 30, 2008 at 11:13:10PM +0000, Raphael Zimmerer wrote:
> > + printf("%s%c", name, opt->null_following_name ? 0 : '\n');
>
> I know I'm nitpicking and I don't know what the git custom on this
> really is, but I tend to prefer '\0' when in the context of a char.
> There is no confusion here of course, but I believe it to be a sane
> habit. (In the same vein that it's ugly to use 0 for NULL ;p).
Its a valid nitpick. NUL is '\0' when dealing with chars in Git,
NULL is NULL, and 0 is the integer 0. That line should read '\0'
to conform with the other code already in git.git.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Builtin-commit: show on which branch a commit was added
From: Shawn O. Pearce @ 2008-10-01 15:10 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Jeff King, Wincent Colaiuta, Pieter de Bie, Junio C Hamano,
Git Mailinglist
In-Reply-To: <48E3312E.4090601@op5.se>
Andreas Ericsson <ae@op5.se> wrote:
> Jeff King wrote:
>> On Tue, Sep 30, 2008 at 11:59:25AM +0200, Andreas Ericsson wrote:
>
>>> Another way would be to write
>>> <branch>: Created <hash>: "subject line..."
>>
>> I think I like this even better.
>
> Me too, but I thought it up after I sent out the first patch. The nicest
> part is that the info that's always present will always end up in the
> same place, while my patch moves the branch-name around depending on
> the length of the subject line.
>
> Let's agree here and now that the subject should be last and that "commit "
> should be dropped, at least for the normal cases.
Actually I rather like the patch you submitted yesterday:
normal case
Created abc9056 (i386: Snib the sprock) on i386
detached head
Created DETACHED commit abc9056 (i386: Snib the sprock)
initial commit
Created root-commit abc9056 (i386: Snib the sprock) on i386
The detached HEAD and root-commit cases are clearly denoted at the
very start of the line, where your eyes are likely to start scanning
from first before you say "Doh, its just line noise because Git wants
a pat on the back for doing what I asked". Thus you are likely
to notice something out of the ordinary (commit on detached HEAD)
pretty quick.
The "<branch>: Created <hash>: subject" format described above
has the problem that a lot of errors look like "error: foo: bar"
and the human eye is probably trained to glance over it. IMHO its
formatted too much like an error message line.
>> My only concern is that many programs
>> say "program: some error", so you could potentially have a confusing
>> branch name. But I personally have never used a branch name that would
>> cause such confusion.
>
> A valid concern, certainly. We needn't use colons for the branch-name
> though, but could instead use some other delimiter, like this:
> [<branch>] Created <hash>: "subject line..."
> although I do believe we're close to nitpicking this issue to death
> now. It's not *that* important after all.
Yup, its a bikeshed.
Right now I'm happy with your patch in next. I don't like taking
the paint brush away from folks, but I also don't want to be applying
a ton of commit message reformatting patches over the next week. ;-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH] git grep: Add "-Z/--null" option as in GNU's grep.
From: Raphael Zimmerer @ 2008-10-01 15:11 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, git
In-Reply-To: <20081001145207.GW21310@spearce.org>
On Wed, Oct 01, 2008 at 07:52:07AM -0700, Shawn O. Pearce wrote:
> Its not like tools outside of Git are all that consistent. GNU
> grep uses --null/-Z. xargs and perl use -0. find uses -print0.
> The human at the keyboard already has to navigate this rats nest
> between different tools, but within a tool (git) we should be as
> consistent as we can.
... and git-config uses --null/-z.
I will send an updated patch with --null/-z.
- Raphael
^ permalink raw reply
* Re: [TG PATCH] README: Fix spelling and reflect recent depend support
From: Jonas Fonseca @ 2008-10-01 15:17 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <1222870059-22077-1-git-send-email-fonseca@diku.dk>
On Wed, Oct 1, 2008 at 16:07, Jonas Fonseca <fonseca@diku.dk> wrote:
> Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
>
> ---
I have been trying to get `tg mail` to work and have a few questions.
Would you mind if topgit didn't insert an empty line after the sob
line? Most emails to this list doesn't have it. The patch mail I just
sent had two 'To:' lines: one probably comes from topgit passing
git-send-email the --to option and the other comes from the patch file
(basically .topmsg) containing a 'To:' line. Should `tg mail` be fixed
to filter this somehow? Finally, tg-mail uses bash arrays, however,
perhaps topgit could get away with just passing one --from and one
--to option to git-send-email.
> diff --git a/README b/README
> index 35a9f98..903face 100644
> --- a/README
> +++ b/README
> @@ -252,6 +252,7 @@ tg delete
> depending on it.
>
> TODO: '-a' to delete all empty branches, depfix, revert
> + TODO: subcommand removing dependencies smoothly
>
> tg depend
> ~~~~~~~~~
Gah, this is obviously in the wrong subsection ...
--
Jonas Fonseca
^ permalink raw reply
* Re: [PATCH] Builtin-commit: show on which branch a commit was added
From: Jeff King @ 2008-10-01 15:18 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Wincent Colaiuta, Pieter de Bie, Junio C Hamano, Git Mailinglist
In-Reply-To: <48E3312E.4090601@op5.se>
On Wed, Oct 01, 2008 at 10:13:34AM +0200, Andreas Ericsson wrote:
> Me too, but I thought it up after I sent out the first patch. The nicest
> part is that the info that's always present will always end up in the
> same place, while my patch moves the branch-name around depending on
> the length of the subject line.
>
> Let's agree here and now that the subject should be last and that "commit "
> should be dropped, at least for the normal cases.
Yes, I agree that those are the most important aspects, and the rest of
it is just minor formatting details.
> A valid concern, certainly. We needn't use colons for the branch-name
> though, but could instead use some other delimiter, like this:
> [<branch>] Created <hash>: "subject line..."
> although I do believe we're close to nitpicking this issue to death
> now. It's not *that* important after all.
Heh. Yes, I feel a little silly discussing this so much. But it probably
is _the_ most frequently seen informational message in git. So not only
does it affect new users' perception of git, but I have to see it every
day. ;)
> I don't quite like the fact that you're removing the "detached" thingie.
> I have coworkers that have been bitten by committing on detached head,
> so I'd like to have some mention of it. I'll rework it to take that
> into account. Otherwise, this looks good. Less code is always a good
> thing, imo.
I thought the all-caps "HEAD" instead of the branch name would make it
stand out. But given that it isn't the common case, I don't think it is
the end of the world to spend a little more screen real estate
mentioning it.
I am ready to bikeshed the next patch you produce. ;)
-Peff
^ permalink raw reply
* Re: [PATCH] Builtin-commit: show on which branch a commit was added
From: Andreas Ericsson @ 2008-10-01 15:22 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Jeff King, Wincent Colaiuta, Pieter de Bie, Junio C Hamano,
Git Mailinglist
In-Reply-To: <20081001151011.GA21310@spearce.org>
Shawn O. Pearce wrote:
> Andreas Ericsson <ae@op5.se> wrote:
>> Jeff King wrote:
>>> On Tue, Sep 30, 2008 at 11:59:25AM +0200, Andreas Ericsson wrote:
>>>> Another way would be to write
>>>> <branch>: Created <hash>: "subject line..."
>>> I think I like this even better.
>> Me too, but I thought it up after I sent out the first patch. The nicest
>> part is that the info that's always present will always end up in the
>> same place, while my patch moves the branch-name around depending on
>> the length of the subject line.
>>
>> Let's agree here and now that the subject should be last and that "commit "
>> should be dropped, at least for the normal cases.
>
> Actually I rather like the patch you submitted yesterday:
>
> normal case
> Created abc9056 (i386: Snib the sprock) on i386
>
> detached head
> Created DETACHED commit abc9056 (i386: Snib the sprock)
>
> initial commit
> Created root-commit abc9056 (i386: Snib the sprock) on i386
>
> The detached HEAD and root-commit cases are clearly denoted at the
> very start of the line, where your eyes are likely to start scanning
> from first before you say "Doh, its just line noise because Git wants
> a pat on the back for doing what I asked". Thus you are likely
> to notice something out of the ordinary (commit on detached HEAD)
> pretty quick.
>
> The "<branch>: Created <hash>: subject" format described above
> has the problem that a lot of errors look like "error: foo: bar"
> and the human eye is probably trained to glance over it. IMHO its
> formatted too much like an error message line.
>
>>> My only concern is that many programs
>>> say "program: some error", so you could potentially have a confusing
>>> branch name. But I personally have never used a branch name that would
>>> cause such confusion.
>> A valid concern, certainly. We needn't use colons for the branch-name
>> though, but could instead use some other delimiter, like this:
>> [<branch>] Created <hash>: "subject line..."
>> although I do believe we're close to nitpicking this issue to death
>> now. It's not *that* important after all.
>
> Yup, its a bikeshed.
>
> Right now I'm happy with your patch in next. I don't like taking
> the paint brush away from folks, but I also don't want to be applying
> a ton of commit message reformatting patches over the next week. ;-)
>
Thanks for putting your foot down. Having thought more about it, I
was quite disgusted to realize I spent brain-time on something so
unimportant.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Builtin-commit: show on which branch a commit was added
From: Jeff King @ 2008-10-01 15:25 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Andreas Ericsson, Wincent Colaiuta, Pieter de Bie, Junio C Hamano,
Git Mailinglist
In-Reply-To: <20081001151011.GA21310@spearce.org>
On Wed, Oct 01, 2008 at 08:10:11AM -0700, Shawn O. Pearce wrote:
> Actually I rather like the patch you submitted yesterday:
>
> normal case
> Created abc9056 (i386: Snib the sprock) on i386
>
> detached head
> Created DETACHED commit abc9056 (i386: Snib the sprock)
>
> initial commit
> Created root-commit abc9056 (i386: Snib the sprock) on i386
>
> The detached HEAD and root-commit cases are clearly denoted at the
> very start of the line, where your eyes are likely to start scanning
> from first before you say "Doh, its just line noise because Git wants
> a pat on the back for doing what I asked". Thus you are likely
> to notice something out of the ordinary (commit on detached HEAD)
> pretty quick.
I agree with your assumption that people scan the line from left to
right, and that the most important stuff should come first. So that
format covers _those_ cases, but not the case of "oops, I committed on
a different branch than I intended." So I think it really makes sense
to keep the branch name on the left side, and the commit subject last.
> Right now I'm happy with your patch in next. I don't like taking
> the paint brush away from folks, but I also don't want to be applying
> a ton of commit message reformatting patches over the next week. ;-)
Welcome to maintainership. ;P
-Peff
^ permalink raw reply
* Re: interactive rebase not rebasing
From: Andreas Ericsson @ 2008-10-01 15:26 UTC (permalink / raw)
To: Stephen Haberman; +Cc: git
In-Reply-To: <20081001095225.d28de16a.stephen@exigencecorp.com>
Stephen Haberman wrote:
>
> But given /this/ scenario (hehe), with the implementation's existing
> explicit usage of "--left-right --cherry-pick" to drop no-op commits,
> but then it's forgetting of this information later, leading to `git
> rebase` not performing a rebase at all, I think it is an obvious bug,
> and one that can be fixed without changing any of `git rebase`s
> existing semantics.
>
Agreed.
>> Merely that you should think hard about it and then make sure it
>> doesn't break anything people are already doing today with the current
>> toolset.
>
> I've attempted to do that. Now that I sent in the patch, if you could
> review it, I would appreciate your feedback.
I'm heading home from work now. I'll look it over tonight or tomorrow
morning. Thanks for the confidence :-)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Builtin-commit: show on which branch a commit was added
From: Shawn O. Pearce @ 2008-10-01 15:36 UTC (permalink / raw)
To: Jeff King
Cc: Andreas Ericsson, Wincent Colaiuta, Pieter de Bie, Junio C Hamano,
Git Mailinglist
In-Reply-To: <20081001152546.GB4962@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Wed, Oct 01, 2008 at 08:10:11AM -0700, Shawn O. Pearce wrote:
>
> > Actually I rather like the patch you submitted yesterday:
> >
> > normal case
> > Created abc9056 (i386: Snib the sprock) on i386
> >
> > detached head
> > Created DETACHED commit abc9056 (i386: Snib the sprock)
> >
> > initial commit
> > Created root-commit abc9056 (i386: Snib the sprock) on i386
> >
> > The detached HEAD and root-commit cases are clearly denoted at the
> > very start of the line, where your eyes are likely to start scanning
>
> I agree with your assumption that people scan the line from left to
> right, and that the most important stuff should come first. So that
> format covers _those_ cases, but not the case of "oops, I committed on
> a different branch than I intended." So I think it really makes sense
> to keep the branch name on the left side, and the commit subject last.
I briefly considered a format like this while replying above, but
at prior day-job I used rather long branch names (sometimes with
common prefixes) so it would truncate alot:
normal case
On i386 abc9056 (i386: Snib the sprock)
detached head
On DETACHED HEAD abc9056 (i386: Snib the sprock)
initial commit
On i386
Root commit abc9056 (i386: Snib the sprock)
With the branch name field set at about 15 characters and truncated.
The initial commit case is very infrequent so burning two lines
for it to help make it stand out *and* make the branch name clear
isn't really a problem.
> > Right now I'm happy with your patch in next. I don't like taking
> > the paint brush away from folks, but I also don't want to be applying
> > a ton of commit message reformatting patches over the next week. ;-)
>
> Welcome to maintainership. ;P
*sigh* And I just took up the #@*#@!&!*!@ paintbrush myself.
Dammit. I'm putting it down now. Really. :-)
--
Shawn.
^ 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