* Re: [PATCH] grep: --full-tree
From: A Large Angry SCM @ 2009-11-25 22:41 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20091125222625.GB2861@coredump.intra.peff.net>
Jeff King wrote:
> On Wed, Nov 25, 2009 at 02:19:35PM -0800, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>>
>>> ... That is, I don't want to have to remember "git grep
>>> --full-tree" or "git grep /" every time
>> But that cuts both ways. If you change the default to full-tree,
>> people will forget to put "." every time when asking to limit to the
>> current directory.
>
> I know. Which is why I am arguing for a configuration option.
>
> Though as a side note, I think if you are going to err, it is probably
> better to err in showing _too much_ data. It is easier for the user to
> notice the situation and re-issue the command with more limits than it
> is for them to notice that some results are missing and re-issue the
> command with fewer limits.
>
>>> If I am the one who sets the configuration variable to something more
>>> sensible for my workflow, who am I hurting?
>> Somebody more clueful in git than you who is called to help you in your
>> repository when you have trouble. Obviously "you" in this sentence is not
>> Jeff King, but I think you get the point.
>
> Clearly, because there _isn't_ anybody more clueful than me in git. ;)
>
> But that is what my meta-rant elsewhere in the thread was about. Sure,
> it hurts when more clueful people are called in (and that includes
> asking for help on the list). But that evil to me is much less than a
> user who is frustrated because they have to specify the same thing to
> git over and over again.
>
>> And re-read what I wrote in its entirety and notice I am not disagreeing
>> with you that the long term goal should be to have the default changed
>> consistently for all command to do the full tree. The important first
>> step is to make sure we are capable of doing both full tree and limit to
>> current directory and "grep" is one example that cannot do both, and be it
>> the --full-tree option or new /rooted-pathspec, we need some change _now_
>> that is backward compatible to pave the way for later changes. We give
>> people convenient way to choose between the two, and _train_ them to
>> express which way they want _without_ having to think. After that is
>> achieved, the default does not matter much and we can safely change the
>> default.
>>
>> Think of it as a way to force existing users _unlearn_ the command
>> specific default we currently have. Because any change of default will
>> hurt them until that is done, we should start training them as early as
>> possible.
>
> I agree with all of this as far as changing the default goes. But the
> point of my earlier messages was that I don't think there _is_ one sane
> default. I really do want it different per-project. And that means a
> configuration option.
Since grep is so useful, both interactively and scripted, outside of
git, this is a pretty convincing argument that git-grep, and all other
git commands with configurable behavior or defaults that change over
time, need a both a scripting form and an interactive form.
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: A Large Angry SCM @ 2009-11-25 22:43 UTC (permalink / raw)
To: gitzilla; +Cc: Junio C Hamano, Jeff King, git
In-Reply-To: <4B0DB04A.6020209@gmail.com>
A Large Angry SCM wrote:
> git-diff aside, I would be much happier with git's interface, and I
> think new/occasional users would be also, if it was consistent across
> all of git commands. And even more so if git's conventions matched most
> other commands on my system of choice.
s/my system of choice/the user's system of choice/
^ permalink raw reply
* Re: OS X and umlauts in file names
From: Andreas Schwab @ 2009-11-25 22:43 UTC (permalink / raw)
To: Thomas Singer; +Cc: Daniel Barkalow, git
In-Reply-To: <4B0CEFCA.5020605@syntevo.com>
Thomas Singer <thomas.singer@syntevo.com> writes:
> I've did following:
>
> toms-mac-mini:git-umlauts tom$ ls
> Überlänge.txt
> toms-mac-mini:git-umlauts tom$ git status
> # On branch master
> #
> # Initial commit
> #
> # Changes to be committed:
> # (use "git rm --cached <file>..." to unstage)
> #
> # new file: "U\314\210berla\314\210nge.txt"
> #
> toms-mac-mini:git-umlauts tom$ git stage "U\314\210berla\314\210nge.txt"
> fatal: pathspec 'U\314\210berla\314\210nge.txt' did not match any files
Try $'U\314\210berla\314\210nge.txt' instead.
"U\314\210berla\314\210nge.txt" is the same as
"U\\314\\210berla\\314\\210nge.txt" to the shell.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* [PATCH] tests: rename duplicate t1009
From: Jeff King @ 2009-11-25 22:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
We should avoid duplicate test numbers, since things like
GIT_SKIP_TESTS consider something like t1009.5 to be
unambiguous.
Signed-off-by: Jeff King <peff@peff.net>
---
This is on top of the nd/sparse topic.
As an aside, that diffstat is really unreadable. I'm not sure how to do
better without dropping the rename information, though.
...ckout.sh => t1011-read-tree-sparse-checkout.sh} | 0
1 files changed, 0 insertions(+), 0 deletions(-)
rename t/{t1009-read-tree-sparse-checkout.sh => t1011-read-tree-sparse-checkout.sh} (100%)
diff --git a/t/t1009-read-tree-sparse-checkout.sh b/t/t1011-read-tree-sparse-checkout.sh
similarity index 100%
rename from t/t1009-read-tree-sparse-checkout.sh
rename to t/t1011-read-tree-sparse-checkout.sh
--
1.6.6.rc0.249.g9b4cf.dirty
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Jeff King @ 2009-11-25 22:53 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: Junio C Hamano, git
In-Reply-To: <4B0DB29D.5010101@gmail.com>
On Wed, Nov 25, 2009 at 05:41:33PM -0500, A Large Angry SCM wrote:
> >I agree with all of this as far as changing the default goes. But the
> >point of my earlier messages was that I don't think there _is_ one sane
> >default. I really do want it different per-project. And that means a
> >configuration option.
>
> Since grep is so useful, both interactively and scripted, outside of
> git, this is a pretty convincing argument that git-grep, and all
> other git commands with configurable behavior or defaults that change
> over time, need a both a scripting form and an interactive form.
It is tempting to have scripts simply set a GIT_VANILLA environment
variable to ignore config options. But I think it is not quite so
simple. As a script, if I am calling "git log", do I want it to respect
the user's colorization config or not? It depends on _how_ I am calling
it. Is the output to be shown to the user, or am I going to process it
myself?
Similarly, why is the script calling "git grep"? If it is because the
script is a convenience wrapper (e.g., let's say to colorize the output
in a particular way), then it probably wants to respect my configured
choice of which files to grep. But if the script is just using "git
grep" to get data to perform some other calculation, then it probably
does care deeply about which set of files to grep.
So I think you have situations where scripts do want to invoke the
porcelain version of a command versus the plumbing. But much harder, you
have ones where they want to respect some options but not others.
-Peff
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Wincent Colaiuta @ 2009-11-25 22:26 UTC (permalink / raw)
To: James Pickens; +Cc: Jeff King, Junio C Hamano, git
In-Reply-To: <885649360911251412n3e566c8fu536b361b993f2ac6@mail.gmail.com>
El 25/11/2009, a las 23:12, James Pickens escribió:
> I like Junio's suggestion to make paths starting with / anchored to
> the
> top.
Oh, I wouldn't like that at all. I think it would be a very ugly UI
wart, because it would basically make Git behave differently than
every other command line tool that accepts paths. If it is to deviate
from the extremely widespread convention that paths starting with /
refer to absolute paths rooted at the root of the filesystem, then the
justification for it would need to be very strong indeed.
Cheers,
Wincent
^ permalink raw reply
* Re: cvsexportcommit dies when applying an (empty) merge commit
From: Nick Woolley @ 2009-11-25 23:00 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <4B0D2BC5.1000002@drmicha.warpmail.net>
Michael J Gruber wrote:
> I think the behavior is correct in the sense that you're telling git
> cvsexportcommit to make a commit to cvs, and it can't, because there is
> no change to commit. A merge can't be represented.
The main problem with this is that by default it aborts the whole process with
an error. I'd prefer a non-fatal warning rather than having to catch the error
and decide if it's ignorable or not, although for now I guess I'll have to, or
make a fork of git-cvsexportcommit.
CVS doesn't has an --allow-empty equivalent I know of, and nor does
git-cvsexportcommit.
Cheers,
N
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: A Large Angry SCM @ 2009-11-25 23:07 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20091125225318.GA10127@coredump.intra.peff.net>
Jeff King wrote:
> On Wed, Nov 25, 2009 at 05:41:33PM -0500, A Large Angry SCM wrote:
>
>>> I agree with all of this as far as changing the default goes. But the
>>> point of my earlier messages was that I don't think there _is_ one sane
>>> default. I really do want it different per-project. And that means a
>>> configuration option.
>> Since grep is so useful, both interactively and scripted, outside of
>> git, this is a pretty convincing argument that git-grep, and all
>> other git commands with configurable behavior or defaults that change
>> over time, need a both a scripting form and an interactive form.
>
> It is tempting to have scripts simply set a GIT_VANILLA environment
> variable to ignore config options. But I think it is not quite so
> simple. As a script, if I am calling "git log", do I want it to respect
> the user's colorization config or not? It depends on _how_ I am calling
> it. Is the output to be shown to the user, or am I going to process it
> myself?
>
> Similarly, why is the script calling "git grep"? If it is because the
> script is a convenience wrapper (e.g., let's say to colorize the output
> in a particular way), then it probably wants to respect my configured
> choice of which files to grep. But if the script is just using "git
> grep" to get data to perform some other calculation, then it probably
> does care deeply about which set of files to grep.
>
> So I think you have situations where scripts do want to invoke the
> porcelain version of a command versus the plumbing. But much harder, you
> have ones where they want to respect some options but not others.
<semi rhetorical>
So, what's the solution?
Have every command command take a list of configuration options to
ignore/respect?
Have every command take an option to ignore/respect _all_ configuration
options?
Have inconsistency between commands, like we have now
Have commands have all kinds of hidden/undocumented default settings?
</semi rhetorical>
^ permalink raw reply
* Re: git-subtree: directory mismatch
From: Johannes Schindelin @ 2009-11-25 23:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Avery Pennarun, Nanako Shiraishi, Marc Fournier, git
In-Reply-To: <7vpr76uzju.fsf@alter.siamese.dyndns.org>
Hi,
On Wed, 25 Nov 2009, Junio C Hamano wrote:
> I do remember some people didn't like -X<option> syntax but I don't
> think there was any solid counterproposal to achieve a similar goal to
> satisfy the need to pass arbitrary parameters to the merge strategy
> backends.
I took exception to the awkward way to specify the option. A strong hint
just how awkward -X<option> is: it is hard to implement using
parse-options.
There is no real reason to do it properly, i.e. with an option
--merge-option <option> or --backend-option <option> or -X <option> (even
if "-X" is not really an expressive name, to be real honest).
BTW the same goes for -S<string>, but unfortunately, we have to keep it
to maintain backwards compatibility.
Ciao,
Dscho
^ permalink raw reply
* Re: git-subtree: directory mismatch
From: Avery Pennarun @ 2009-11-25 23:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Nanako Shiraishi, Marc Fournier, git
In-Reply-To: <alpine.DEB.1.00.0911260013550.4985@pacific.mpi-cbg.de>
On Wed, Nov 25, 2009 at 6:17 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> On Wed, 25 Nov 2009, Junio C Hamano wrote:
>> I do remember some people didn't like -X<option> syntax but I don't
>> think there was any solid counterproposal to achieve a similar goal to
>> satisfy the need to pass arbitrary parameters to the merge strategy
>> backends.
>
> I took exception to the awkward way to specify the option. A strong hint
> just how awkward -X<option> is: it is hard to implement using
> parse-options.
I read the earlier thread and I still don't quite understand this
point. What makes it difficult? X seems just like any other option
that takes a string parameter (which is easily supported by getopt at
least; I haven't played with parse_options but I certainly hope it's
as good as getopt).
The string parameter (say, $x) is translated directly into "--$x" and
passed as exactly one argument of the argv array to the subprogram.
Easy, right? Plus Junio already wrote a patch to do it (which I'm in
the process of forward-porting) and it seems pretty straightforward.
Perhaps I'm missing something.
Thanks,
Avery
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Jeff King @ 2009-11-25 23:22 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: Junio C Hamano, git
In-Reply-To: <4B0DB894.7010800@gmail.com>
On Wed, Nov 25, 2009 at 06:07:00PM -0500, A Large Angry SCM wrote:
> <semi rhetorical>
> So, what's the solution?
>
> Have every command command take a list of configuration options to
> ignore/respect?
>
> Have every command take an option to ignore/respect _all_
> configuration options?
>
> Have inconsistency between commands, like we have now
>
> Have commands have all kinds of hidden/undocumented default settings?
> </semi rhetorical>
I don't know. All of those options suck. ;
Probably we would want something flexible, but with sane defaults. Like
an environment variable to ignore all (or most) config options, but then
the ability to opt into specific ones. Something like:
GIT_PLUMBING=1; export GIT_PLUMBING
git log ;# does not respect any non-plumbing config
git --respect='log.showroot' ;# respect just the one variable
git --respect='color.*' log ;# you get all color
But there are two big obstacles (besides the obvious issue that
introducing this in itself needs a gentle transition plan):
1. We need to annotate every config option with whether it is
potentially problematic. For example, core.filemode should probably
be respected no matter what (but I'm not sure if it is simply true
for core.*).
2. Script writers need to actually use the system, which is somewhat
more verbose and annoying than what they have to do now. But at
least it defaults to safety when they are lazy, and then they can
re-add options. Of course, they are stuck on an upgrade treadmill
of analyzing and approving each new option that appears in git.
-Peff
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Johannes Schindelin @ 2009-11-25 23:31 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, git
In-Reply-To: <fabb9a1e0911251246l4684f357pb5f379b191aaa64a@mail.gmail.com>
Hi,
On Wed, 25 Nov 2009, Sverre Rabbelier wrote:
> On Wed, Nov 25, 2009 at 21:23, Junio C Hamano <gitster@pobox.com> wrote:
> > But then you can alias "gr 'grep --full-tree'" with the same ease and
> > there is no reason to change the default.
>
> I agree, but then again I'm somewhat biased, as I want the current
> behavior :P.
You mean like the many people who wanted to keep the dashed commands, but
unlike who you do speak up _before_ your expectations are broken?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] gitweb.js: Harden setting blamed commit info in incremental blame
From: Jakub Narebski @ 2009-11-25 23:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stephen Boyd, git
In-Reply-To: <7vd436s2r8.fsf@alter.siamese.dyndns.org>
On Wed, środa 25. listopada 2009 22:39, Junio C Hamano napisał:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > It was 'Unspecified error.' shown in xhr watch. Accessing xhr.status
> > causes an error.
>
> As to the topic, it does not seem to break _existing_ features; if that is
> not the case, please let me know.
With the single exception of "Create links leading to 'blame_incremental'
using JavaScript" all commits are about opt-in features: either need to
be enabled in gitweb config ('timed' feature), or you need to handcraft
URL ('blame_incremental' as action parameter).
The commit that makes 'blame' links to use 'blame_incremental' view if
JavaScript is enabled might break 'blame' view for IE8 users.
> Otherwise I'm inclined to merge the entire series to 'master' by 1.6.6-rc1.
>
> 6821dee gitweb.js: fix padLeftStr() and its usage
> 6aa2de5 gitweb.js: Harden setting blamed commit info in incremental blame
> e42a05f gitweb.js: fix null object exception in initials calculation
> 63267de gitweb: Minify gitweb.js if JSMIN is defined
> c4ccf61 gitweb: Create links leading to 'blame_incremental' using JavaScript
> e206d62 gitweb: Colorize 'blame_incremental' view during processing
> 4af819d gitweb: Incremental blame (using JavaScript)
> aa7dd05 gitweb: Add optional "time to generate page" info in footer
> -aef3768 gitweb: Use light/dark for class names also in 'blame' view
>
> and treat it as a new feature with known breakages, to give it wider
> audience. That way you will hopefully get more people who are willing to
> help debug/fix things for you.
Perhaps then it would be better to put commit that creates links to
'blame_incremental' action last, and have it in 'next' and not in master?
Below there is request-pull with reordered series, unless you want me
to resend this series as a set of patches, as reply to this email.
-- >8 --
The following changes since commit b073b7a990deb1cb3425db45642fa18c8b3cb65c:
Benjamin Kramer (1):
Explicitly truncate bswap operand to uint32_t
are available in the git repository at:
git://repo.or.cz/git/jnareb-git.git gitweb/web
7bc7e38 gitweb: Create links leading to 'blame_incremental' using JavaScript
aa1ff3d gitweb.js: Harden setting blamed commit info in incremental blame
da51a3c gitweb.js: fix padLeftStr() and its usage
a253a2c gitweb.js: fix null object exception in initials calculation
fbebd29 gitweb: Minify gitweb.js if JSMIN is defined
8ba6343 gitweb: Colorize 'blame_incremental' view during processing
0e14278 gitweb: Incremental blame (using JavaScript)
c4c6645 gitweb: Add optional "time to generate page" info in foot
Jakub Narebski (6):
gitweb: Add optional "time to generate page" info in footer
gitweb: Incremental blame (using JavaScript)
gitweb: Colorize 'blame_incremental' view during processing
gitweb: Minify gitweb.js if JSMIN is defined
gitweb.js: Harden setting blamed commit info in incremental blame
gitweb: Create links leading to 'blame_incremental' using JavaScript
Stephen Boyd (2):
gitweb.js: fix null object exception in initials calculation
gitweb.js: fix padLeftStr() and its usage
Makefile | 26 ++-
git-instaweb.sh | 7 +
gitweb/README | 5 +
gitweb/gitweb.css | 25 ++
gitweb/gitweb.js | 870 ++++++++++++++++++++++++++++++++++++++++++++++++++++
gitweb/gitweb.perl | 311 ++++++++++++++-----
6 files changed, 1157 insertions(+), 87 deletions(-)
create mode 100644 gitweb/gitweb.js
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Sverre Rabbelier @ 2009-11-25 23:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0911260030130.4985@pacific.mpi-cbg.de>
Heya,
On Thu, Nov 26, 2009 at 00:31, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> You mean like the many people who wanted to keep the dashed commands, but
> unlike who you do speak up _before_ your expectations are broken?
Yes, kinda like that, but with the note that I do think we should not
lock down the UI in favor or not breaking expectations. I mean, if
people want to retain a specific behavior forever, maybe they should
just keep using that version of git forever? Nah, that doens't work of
course, but I do think a balance is needed between the two (improving
the UI and not breaking people's expectations).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Johannes Schindelin @ 2009-11-25 23:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vmy2as319.fsf@alter.siamese.dyndns.org>
Hi,
On Wed, 25 Nov 2009, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > On Wed, Nov 25, 2009 at 12:52:11PM -0800, Junio C Hamano wrote:
> >
> >> So I think the posted patch alone without changing anything else would be
> >> the approach to give the most benefit with the least impact to existing
> >> users, at least for now.
> >
> > Yes, I meant to say in my original message but forgot to: I think
> > --full-tree is an important first step, no matter what happens next. It
> > gives people a way to do what they want without typing the right number
> > of ".."s, and it opens up --no-full-tree if the default changes later.
> >
> > But I do worry about it being a command-line option. You are asking the
> > user to remember to type --full-tree every time.
>
> We could redefine get_pathspec() to treat a pathspec that begins with a
> slash to be anchored at the top,
This would break spectacularly in MSys. And this is just one reason not
to do this "magic".
Clearly, a command line option is the only unambiguous way to do what you
want to do (and not changing the default all of a sudden).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Junio C Hamano @ 2009-11-25 23:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Jeff King, git
In-Reply-To: <alpine.DEB.1.00.0911260032410.4985@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> This would break spectacularly in MSys.
How? If that is the case wouldn't --full-tree break Msys the same way?
^ permalink raw reply
* Re: git-subtree: directory mismatch
From: Björn Steinbrink @ 2009-11-25 23:41 UTC (permalink / raw)
To: Avery Pennarun
Cc: Johannes Schindelin, Junio C Hamano, Nanako Shiraishi,
Marc Fournier, git
In-Reply-To: <32541b130911251520l7a84554bxab9cf59ff9d8fc1@mail.gmail.com>
On 2009.11.25 18:20:45 -0500, Avery Pennarun wrote:
> On Wed, Nov 25, 2009 at 6:17 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > On Wed, 25 Nov 2009, Junio C Hamano wrote:
> >> I do remember some people didn't like -X<option> syntax but I don't
> >> think there was any solid counterproposal to achieve a similar goal to
> >> satisfy the need to pass arbitrary parameters to the merge strategy
> >> backends.
> >
> > I took exception to the awkward way to specify the option. A strong hint
> > just how awkward -X<option> is: it is hard to implement using
> > parse-options.
>
> I read the earlier thread and I still don't quite understand this
> point. What makes it difficult?
I guess it's -Xfoo vs. -X foo (note the space). Same deal with log
-S<string>. "git log -S foo" would look for an empty string (I guess)
being added/removed in some commit in foo's history, while "git log
-Sfoo" looks for "foo" being added/remove in HEAD's history.
Björn
^ permalink raw reply
* Re: Commiting changes onto more than one branch
From: Daniel Barkalow @ 2009-11-25 23:41 UTC (permalink / raw)
To: Mike Jarmy; +Cc: Junio C Hamano, Eugene Sajine, git
In-Reply-To: <6b4a562b0911251143s63f09f7bwe4b67d6871d8a1b2@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2869 bytes --]
On Wed, 25 Nov 2009, Mike Jarmy wrote:
> Junio C Hamano wrote:
> > I take it to mean that even though v[345] have diverged, the area that the
> > particular change you have in mind has to touch haven't changed since they
> > forked.
>
> Correct. Sometimes, there might be unrelated changes to a given file
> or files, in which case conflict resolution will be done manually.
> But generally speaking, bugfixes will tend to go on quite cleanly.
>
> > Instead, you can fork such a topic from the latest common.
> >
> > o--o--o--o--o--o--o--o v4
> > /
> > --o--x--x--x--x--x--x--x v3
> > \
> > Y---Y
> > your change(s)
> >
> > and merging this to v3 and v4 will have the desired effect.
> >
> > o--o--o--o--o--o--o--o---------M v4
> > / /
> > --o--x--x--x--x--x--x--x---M v3 /
> > \ / /
> > Y---Y----------------.-----.
> > your change(s)
> >
> > The merges will incorporate this particular change alone without dragging
> > anything else. When you merge it to v4, none of the unrelated 'x' will be
> > merged into it.
>
> That sounds a whole lot like what I need.
>
> Right now I'm thinking that the right approach is that once we have
> released v3, and started working on v4 heavily, we will probably not
> want to check any commits directly into v3. Bugfixes will have their
> own branch. If there is a whole new project or whatever being done
> on top of v3, it will have its own branch as well.
>
> So once v3 is in beta or whatever and we declare a code freeze, we
> could have a rule that all commits must be merge-commits coming from
> dedicated branches with descriptive, intelligible names. For each
> dedicated branch, some thought will have to be given as to just where
> off of v3 to branch it from (not just carelessly off the latest tip).
> Meanwhile, new development will continue on v4, with lots of commits
> going right into the branch (or into v4 sub-branches with occasional
> merge-commits into v4).
It's worth noting that you don't have to have any general visibility to
the dedicated branch. If you look at Junio's graph, there are only two
branches marked: v3 and v4. The stuff in the bottom line only appears as
the second parent in the merge commits. Git's data model doesn't require a
branch for a commit to be "on" like many other VCSes, so it's perfectly
reasonable for a developer to make a temporary branch, create the fix in
some private repository, merge it to each applicable official branch, and
then discard the temporary branch. (The temporary branch is only needed at
all so that the developer has some way to refer to the fix while merging
it, and the name only matters in that humans will see it in the merge
commit message.)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: git-subtree: directory mismatch
From: Avery Pennarun @ 2009-11-25 23:45 UTC (permalink / raw)
To: Björn Steinbrink
Cc: Johannes Schindelin, Junio C Hamano, Nanako Shiraishi,
Marc Fournier, git
In-Reply-To: <20091125234122.GA31422@atjola.homenet>
2009/11/25 Björn Steinbrink <B.Steinbrink@gmx.de>:
> On 2009.11.25 18:20:45 -0500, Avery Pennarun wrote:
>> I read the earlier thread and I still don't quite understand this
>> point. What makes it difficult?
>
> I guess it's -Xfoo vs. -X foo (note the space). Same deal with log
> -S<string>. "git log -S foo" would look for an empty string (I guess)
> being added/removed in some commit in foo's history, while "git log
> -Sfoo" looks for "foo" being added/remove in HEAD's history.
Oh. Ouch. Isn't it standard for options-that-take-string-parameters
to always *require* that parameter? This seems to be how getopt
works. Basically "-X foo" is the same as "-Xfoo" in that system.
If parse_options doesn't already do this, should I try to add it somehow?
Avery
^ permalink raw reply
* Re: Commiting changes onto more than one branch
From: Andreas Schwab @ 2009-11-25 23:56 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Mike Jarmy, Junio C Hamano, Eugene Sajine, git
In-Reply-To: <alpine.LNX.2.00.0911251752330.14365@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> (The temporary branch is only needed at all so that the developer has
> some way to refer to the fix while merging it, and the name only
> matters in that humans will see it in the merge commit message.)
If you merge by commit-ish the branch name does not even appear in the
commit message.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Johannes Schindelin @ 2009-11-26 0:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vvdgyp3zn.fsf@alter.siamese.dyndns.org>
Hi,
On Wed, 25 Nov 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > This would break spectacularly in MSys.
>
> How? If that is the case wouldn't --full-tree break Msys the same way?
If you want to specify an argument on MSys that starts with a slash, you
have to provide double slashes, otherwise it gets expanded to the Windows
path (prefixing with the absolute path of the MSys root).
But this introduces yet another inconcistency: using double slashes
everywhere else does not work.
Hopefully you see the real reason why it breaks down? The reason is that
you try to re-interpret something in a special way that means something
different. A path starting with a slash simply does not mean "the root of
the project". It means "the root of the file system".
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Junio C Hamano @ 2009-11-26 0:00 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: James Pickens, Jeff King, git
In-Reply-To: <60F92BD7-6FFF-4D9A-B2F0-0858F4E90B59@wincent.com>
Wincent Colaiuta <win@wincent.com> writes:
> Oh, I wouldn't like that at all. I think it would be a very ugly UI
> wart, because it would basically make Git behave differently than
> every other command line tool that accepts paths. If it is to deviate
> from the extremely widespread convention that paths starting with /
> refer to absolute paths rooted at the root of the filesystem, then the
> justification for it would need to be very strong indeed.
There are at least two flaws in that argument.
- git does not accept paths (it lets you specify patterns that match,
e.g. t/ to name ptahs under t/ directory).
- "/pathspec" does follow the widespread convention that a string that
begin with a "/" refer to a path rooted at the root _in the context_;
the definition of root may or may not match the filesystem root.
Think of things like <a href="/$path">Top</a>. Does "/$path" mean at
the root of filesystem? No.
I am not married to the "git grep -e frotz /Documentation" notation, by
the way. I just didn't think of a different notation that is equally
short, sweet and logical. We could do //Documentation if it makes it more
distinct, but I do think it is worse than a single slash.
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Junio C Hamano @ 2009-11-26 0:02 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091125222625.GB2861@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, Nov 25, 2009 at 02:19:35PM -0800, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>>
>> > ... That is, I don't want to have to remember "git grep
>> > --full-tree" or "git grep /" every time
>>
>> But that cuts both ways. If you change the default to full-tree,
>> people will forget to put "." every time when asking to limit to the
>> current directory.
>
> I know. Which is why I am arguing for a configuration option.
Yeah; what is your take on tr/reset-checkout-patch topic, by the way? I
do not particularly like a configuration that changes the behaviour of a
command in a drastic way---it will make helping others much harder, but I
guess it should be Ok?
This may sound like an OffTopic, but because we _are_ discussing
consistency, it matters.
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: Junio C Hamano @ 2009-11-26 0:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Jeff King, git
In-Reply-To: <alpine.DEB.1.00.0911260059040.4985@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> If you want to specify an argument on MSys that starts with a slash, you
> have to provide double slashes, otherwise it gets expanded to the Windows
> path (prefixing with the absolute path of the MSys root).
How well does the command line hack handle things like
$ git archive --output=/var/tmp/foo.tar
I have to wonder.
> Hopefully you see the real reason why it breaks down?
Yes, Windows' braindamage. It doesn't invalidate anything I said so far,
but only proves that emulation can go only so far. I hope msys port can
grok real "path from root" notation on Windows, e.g.
$ git diff --no-index "C:\My Documents/hello.txt" "D:\goodbye.txt"
(or perhaps "//c/my documents/...", but I do not care about the details).
^ permalink raw reply
* Re: [PATCH] grep: --full-tree
From: A Large Angry SCM @ 2009-11-26 0:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Wincent Colaiuta, James Pickens, Jeff King, git
In-Reply-To: <7vd436p339.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> - git does not accept paths (it lets you specify patterns that match,
> e.g. t/ to name ptahs under t/ directory).
Here is where it get interesting!
Our users, new and old alike, are wanting consistency. Consistency
amongst the git commands. Consistency with their platform of choice.
Consistency with what they are familiar with, Consistency with their
expectations.
Declaring that git commands (all?!) do not take paths but patterns does
not help the situation; however technically correct it may be.
> - "/pathspec" does follow the widespread convention that a string that
> begin with a "/" refer to a path rooted at the root _in the context_;
> the definition of root may or may not match the filesystem root.
But the users are almost always dealing with things (objects) that
started as files, act like files and may be files again. Why should they
not expect filesystem semantics.
^ 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