* 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: [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: 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 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 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: 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] 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: [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: [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: [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 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
* [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: [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
* 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/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-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: 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: 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 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: [RFC PATCH] Documentation: add manpage about workflows
From: Santi Béjar @ 2008-10-01 9:54 UTC (permalink / raw)
To: Thomas Rast; +Cc: Dmitry Potapov, git, Junio C Hamano
In-Reply-To: <200809301805.30753.trast@student.ethz.ch>
On Tue, Sep 30, 2008 at 6:05 PM, Thomas Rast <trast@student.ethz.ch> wrote:
> As a quick status update, mostly to show that I haven't forgotten
> about this topic:
>
> Thanks Santi and Dmitry for your comments. You have raised some very
> good points, and I attempted to fix these issues.
Thanks for you document.
>
> Unfortunately, in some places I got stuck trying to work out good
> explanations for the workings of git.git, and some of the newer
> rearrangements left the lead of "Merging branches" in a dire state.
> I'll see if I can find a good solution myself, but suggestions would
> be welcome in any case. The WIP text is below, and I'll follow up
> with an interdiff to the last version.
>
> - Thomas
>
[...]
>
> SEPARATE CHANGES
> ----------------
>
> As a general rule, you should try to split your changes into small
> logical steps, and commit each of them. They should be consistent,
> working independently of any later commits, pass the test suite, etc.
> This makes the review process much easier, and the history much more
> useful for later inspection and analysis, for example with
> linkgit:git-blame[1] and linkgit:git-bisect[1].
>
> To achieve this, try to split your work into small steps from the very
> beginning. It is always easier to squash a few commits together than
> to split one big commit into several. Don't be afraid of making too
> small or imperfect steps along the way. You can always go back later
> and edit the commits with `git rebase \--interactive` before you
> publish them.
>
I know it is against the recommendation but I think it makes sense to
explain how you can split big patches testing them as is explained in
gitlink:git-stash.
[...]
> Graduation
> ~~~~~~~~~~
>
> As a given feature goes from experimental to stable, it also
> "graduates" between the corresponding branches of the software.
> `git.git` uses the following 'main branches':
>
> * 'master' tracks the commits that should go into the next release;
>
> * 'maint' tracks the commits that should go into the next "maintenance
> release", i.e., update of the last released stable version; and
The "logical" order would be 'maint', 'master', 'next', 'pu', each one
should fast-forward to the next one.
>
> * 'next' is intended as a testing branch for people who like to use
> more experimental stuff.
The key point is not "more experimental stuff", but 'master' material
but not stable enough.
[...]
> Integration branches
> ~~~~~~~~~~~~~~~~~~~~
>
> If you followed the last paragraph, you will now have many small topic
> branches, and occasionally wonder how they interact. Perhaps the
> result of merging them does not even work? But on the other hand, we
> want to avoid merging them anywhere "stable" because such merges
> cannot easily be undone.
>
> The solution, of course, is to make a merge that we can undo: merge
> into a throw-away branch.
>
> .Integration branches
> [caption="Rule: "]
> =====================================
> To test the interaction of several topics, merge them into a
> throw-away branch.
> =====================================
>
> If you make it (very) clear that this branch is going to be deleted
> right after the testing, you can even publish this branch, for example
> to give the testers a chance to work with it, or other developers a
> chance to see if their in-progress work will be compatible. `git.git`
> has such an official integration branch called 'pu'. You must never
> base any work on such a throw-away branch!
Maybe this last sentence should go in the "Rule:".
>
>
> SHARING WORK
> ------------
>
> After the last section, you should know how to manage topics. In
> general, you will not be the only person working on the project, so
> you will have to share your work.
Sharing work is explained in the tutorials, maybe this section should
be about "distributed workflows".
>
> Roughly speaking, there are two important workflows: push/pull and
> format-patch/am.
A more descriptive name could be the "merge workflow" and the "patch workflow".
> The important difference is that push/pull can
> propagate merges, while format-patch cannot.
Like I said in the other mail, the key is that one preserves the
history (including merges) and the other not. This is what makes
possible the push/pull workflow, that all the branches should
fast-forward (and this should be said somewhere)
> Medium to large projects
> will typically employ some mixture of the two:
s/:/./
Although I think it should be deleted. And what about litle projects?
Different roles do uses different workflows:
>
> * "Upstream" in the most general sense 'pushes' changes to the
> repositor(ies) holding the official history of the project.
> Everyone can 'fetch' from there to stay up to date.
s/pushes/publishes/
s/fetch/merge/
>
> * Frequent contributors, subsystem maintainers, etc. may push to a
> public repository to make their changes available to upstream.
s/push/publish/
Or:
* Frequent contributors, subsystem maintainers, etc. may publish to a
public repository to make their changes available to upstream, or to
their downstreams (acting as upstream to them)
>
> * The rest -- typically anyone more than one or two levels away from the
> main maintainer -- send patches by mail.
In the "distributed workflows" this would be:
* "Upstream" merges the branches from subsystem maintainers, applies
the 'patches' from others (including themselves) and publishes to the
main repository. See link:howto/maintain-git.txt to see how it is done
in git.git)
* "Subsystem maintainers" act as "upstream" but publishes to a
different repository/branch.
* Frequent contributors, etc, publish their changes in another repository.
* The rest ...
>
> None of these boundaries are sharp, so find out what works best for
> you.
>
>
> Push/pull
> ~~~~~~~~~
>
> There are three main tools that can be used for this:
Sorry, but I don't see the point explaining how to publish the
branches, or keep them up to date.
>
> If you are a maintainer and would like to merge other people's topic
> branches to the main branches, they will typically send a request to
> do so by mail. Such a request might say
>
> -------------------------------------
> Please pull from
> git://some.server.somewhere/random/repo.git mytopic
> -------------------------------------
>
> In that case, 'git-pull' can do the fetch and merge in one go, as
> follows.
Or:
Then, you can merge them with just:
> .Push/pull: Merging remote topics
> [caption="Recipe: "]
> =====================================
> `git pull <url> <branch>`
> =====================================
>
Use "<url> <branch>" or "git://some.server.somewhere/random/repo.git
mytopic" in the recipies, but not both.
[...]
>
> format-patch/am
> ~~~~~~~~~~~~~~~
s/.*/patch workflow/
>
> If you are a contributor that sends changes upstream in the form of
> emails, you should use topic branches as usual (see above). Then use
> linkgit:git-format-patch[1] to generate the corresponding emails
> (highly recommended over manually formatting them because it makes the
> maintainer's life easier).
>
> .format-patch/am: Publishing branches/topics
> [caption="Recipe: "]
> =====================================
> * `git format-patch -M upstream..topic` to turn them into preformatted
> patch files
> * `git send-email --to=<recipient> <patches>`
> =====================================
>
> See the linkgit:git-format-patch[1] and linkgit:git-send-email[1]
> manpages for further usage notes. Also you should be aware that the
> maintainer may impose further restrictions, such as "Signed-off-by"
> requirements.
The restrictions and the Signed-off-by also applies to the other workflows.
>
> If the maintainer tells you that your patch no longer applies to the
> current upstream, you will have to rebase your topic (you cannot use a
> merge because you cannot format-patch merges):
>
> .format-patch/am: Keeping topics up to date
> [caption="Recipe: "]
> =====================================
> `git pull --rebase <url> <branch>`
> =====================================
>
> You can then fix the conflicts during the rebase. Presumably you have
> not published your topic other than by mail, so rebasing it is not a
> problem.
>
> If you receive such a patch (as maintainer, or perhaps as a reader of
> the mailing list it was sent to), save the mail to a file and use
> 'git-am':
>
> .format-patch/am: Publishing branches/topics
> [caption="Recipe: "]
> =====================================
> `git am < patch`
> =====================================
>
> One feature worth pointing out is the three-way merge, which can help
> if you get conflicts: `git am -3` will use index information contained
> in patches to figure out the merge base. See linkgit:git-am[1] for
> other options.
>
>
> SEE ALSO
> --------
> linkgit:gittutorial[7],
> linkgit:git-push[1],
> linkgit:git-pull[1],
> linkgit:git-merge[1],
> linkgit:git-rebase[1],
> linkgit:git-format-patch[1],
> linkgit:git-send-email[1],
> linkgit:git-am[1]
>
> GIT
> ---
> Part of the linkgit:git[1] suite.
>
>
>
^ permalink raw reply
* Re: [RFC] gitweb wishlist and TODO list (profiling gitweb)
From: Jakub Narebski @ 2008-10-01 9:52 UTC (permalink / raw)
To: Ask Bjørn Hansen; +Cc: git, Petr Baudis
In-Reply-To: <1D35F972-DA47-4445-A667-B03F841CABC6@develooper.com>
On Wed, 1 Oct 2008, Ask Bjørn Hansen wrote:
> On Sep 25, 2008, at 3:30, Jakub Narebski wrote:
>
> > * Optional information about load stats
> >
> > Add an option to display information about how much time it took to
> > generate page, how many git commands were called, and possibly other
> > metric; if page was cached, write when it was generated, and how
> > much time till timeout. This probably would require additional perl
> > modules, and it should be conditional on those modules.
>
> Before spending too much time on this, be sure to have a look a
> Devel::NYTProf.
>
> http://search.cpan.org/~timb/Devel-NYTProf-2.03/lib/Devel/NYTProf.pm
>
> http://blog.timbunce.org/2008/07/15/nytprof-v2-a-major-advance-in-perl-profilers/
Thank you very much for the pointers.
However I'm not sure how much help would that be, as according to J.H.
(kernel.org admin) and Petr Baudis (repo.or.cz admin), gitweb
performance in real life settings is bound by I/O, not by CPU usage.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC] gitweb wishlist and TODO list
From: Ask Bjørn Hansen @ 2008-10-01 8:40 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis
In-Reply-To: <200809251230.11342.jnareb@gmail.com>
On Sep 25, 2008, at 3:30, Jakub Narebski wrote:
> * Optional information about load stats
>
> Add an option to display information about how much time it took to
> generate page, how many git commands were called, and possibly other
> metric; if page was cached, write when it was generated, and how
> much time till timeout. This probably would require additional perl
> modules, and it should be conditional on those modules.
Before spending too much time on this, be sure to have a look a
Devel::NYTProf.
http://search.cpan.org/~timb/Devel-NYTProf-2.03/lib/Devel/NYTProf.pm
http://blog.timbunce.org/2008/07/15/nytprof-v2-a-major-advance-in-perl-profilers/
--
http://develooper.com/ - http://askask.com/
^ permalink raw reply
* Re: [PATCH] Builtin-commit: show on which branch a commit was added
From: Andreas Ericsson @ 2008-10-01 8:13 UTC (permalink / raw)
To: Jeff King
Cc: Wincent Colaiuta, Pieter de Bie, Junio C Hamano, Git Mailinglist
In-Reply-To: <20081001031400.GA24513@coredump.intra.peff.net>
Jeff King wrote:
> On Tue, Sep 30, 2008 at 11:59:25AM +0200, Andreas Ericsson wrote:
>
>> I agree. Obvious solution is to do
>>
>> subj_len = term_width - (strlen(cruft) + strlen(branch_name))
>
> I think the difficulty is that the printing is sometimes done by our
> printf and sometimes by log_tree_commit, and there isn't a convenient
> way to hook into log_tree_commit to postprocess the formatted output.
>
>> where strlen(cruft) is just 8 less if we drop 'commit ' from the
>> cases. See the patch I just sent though. I sort of like that one.
>
> I like it much better than what is on next (and I thought your commit
> message summed up the issue nicely), but...
>
Thanks. Feel free to recycle it :)
>> 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.
> 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.
>> As <hash> will very, very rarely match anything the user would put
>> in his/her commit message themselves. Quoting the subject is probably
>> a nice touch, and it can make sense to put it last as it's the least
>> interesting of the things we print. Ah well. I'll just await commentary
>> on the patch I've already sent before I go ahead and do something like
>> that.
>
> Here is a patch for that format on top of next (the patch between this
> and what is in master is even more simple, since we are mostly removing
> Pieter's helper function).
>
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.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Git config not expanding user home directories
From: Andreas Ericsson @ 2008-10-01 7:52 UTC (permalink / raw)
To: Jeff King; +Cc: Jakub Narebski, Tom Lanyon, Karl Chen, Git Mailinglist
In-Reply-To: <20081001032246.GB24513@coredump.intra.peff.net>
Jeff King wrote:
> On Tue, Sep 30, 2008 at 04:38:46AM -0700, Jakub Narebski wrote:
>
>> There was a patch send to git mailing list adding basic '~' support
>> (I think via $ENV{HOME}), and IIRC even ~user support. I don't know
>> what happened to those patches (check mailing list archive), but
>> most probably it was not accepted because it didn't provide a way
>> for scripts to use this functionality, for example via --path option.
>
> There were several rounds, and I thought it was shaping up, but then
> no more rounds came. I assume that Karl lost interest (or perhaps we
> nitpicked him to death), but I thought at the end of the thread Junio
> laid out a plan for the next revision. I guess nobody cared enough about
> the feature to implement it after that (though I think I found the final
> version acceptable with a minor documentation tweak, I think Junio laid
> out a cleaner approach).
>
> The last patch is here, with one of the replies from Junio giving the
> aforementioned plan:
>
> http://mid.gmane.org/quack.20080829T0229.lthhc94rwyr_-_@roar.cs.berkeley.edu
>
That looks roughly like the way I'd have done it. I'll see if I can find
the time to polish it up a bit.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: interactive rebase not rebasing
From: Andreas Ericsson @ 2008-10-01 7:50 UTC (permalink / raw)
To: Stephen Haberman; +Cc: git
In-Reply-To: <20081001010306.01cc34eb.stephen@exigencecorp.com>
Stephen Haberman wrote:
>>> # A --C------ <-- origin/stable
>>> # \ | \
>>> # B -- D -- E -- F <-- origin/topic2
>>> # \|
>>> # g -- h <-- topic2
>>>
>>> Nothing has changed. g & h haven't moved...I can keep executing this
>>> operation and the commits never make it on top of origin/topic2's F.
>>>
>>> Frustratingly, if I run non-interactive rebase, it works perfectly.
>> I can imagine. Since you don't want to preserve the merges in this
>> case, you shouldn't be using the -p flag.
>
> No, I do want to preserve most merges. This "most" qualification is
> because the merge "g", if rebased, would have been a no-op, so `rebase
> -i -p` correctly kept it out of the TODO file.
>
> Which is cool, except that later on, when rewriting the other TODO
> commits, some of which were children of "g", it did not remember that
> "g" had gone away, so did nothing to take "g" out of the rewritten
> children's parent list.
>
>> In fact, for this particular scenario (assuming "h" is really the only
>> commit on topic2), you probably want to just cherry-pick that commit
>> into origin/topic2:
>>
>> git checkout topic2
>> git reset --hard origin/topic2
>> git cherry-pick ORIG_HEAD
>
> Agreed. This makes a lot of sense for me, who has been hacking around in
> git-rebase--interactive fixing things, but I'd really like the other
> people on my team to just have to run `git rebase -i -p`.
>
>> 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. 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.
Git is stupid very, very much by design. Linus constantly says that
he prefers tools that he can figure out why they did something stupid
over tools that try really hard to get it right, and I agree with him
100%, as do most of the core contributors (insofar as I've understood
it). What you're suggesting is that a git command should try hard to
dwim a lot of complexity about choosing tools away, and that goes
right against the KISS principle which serves git so well. I'm not
saying you shouldn't do it. 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.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ 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