* Re: [PATCH] git-add--interactive: never skip files included in index
From: Jeff King @ 2009-10-11 19:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pauli Virtanen, git
In-Reply-To: <7viqelwyp1.fsf@alter.siamese.dyndns.org>
On Sun, Oct 11, 2009 at 11:52:10AM -0700, Junio C Hamano wrote:
> Thanks.
>
> The change looks innocent enough and I do not expect to see any unexpected
> regressions from it, but it is a bit too late for 1.6.5 cycle, so let's
> queue this fix and aim for 1.6.5.1.
I think this patch is good to apply, as there is no conceivable reason
to even look at excludes when listing modified files.
But this triggered my spider sense; shouldn't --exclude-standard simply
be a no-op for ls-files when we are not listing untracked files? And
bisecting, it seems that it is a very old regression caused by 63d285c
(per-directory-exclude: lazily read .gitignore files, 2007-11-29).
I don't know if it is worth fixing now or not. It does seem a bit
inconsistent to me (since everything else is very clear that .gitignore
is only about untracked files), but nobody seems to have been
complaining for the last two years (and they may have, in fact, been
coding to the new behavior).
-Peff
^ permalink raw reply
* Re: git log --graph
From: Matthieu Moy @ 2009-10-11 19:40 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Dilip M, git
In-Reply-To: <fabb9a1e0910111135v4f3c75a7v6657f5dcfacf13ac@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> Heya,
>
> On Sun, Oct 11, 2009 at 20:27, Dilip M <dilipm79@gmail.com> wrote:
>> I am trying git log --graph. (has commits in two branches...). But
>> always see one line :(
>
> It'll show you the history of one branch at a time online, you won't
> get the demo-ed multiple lines unless the branch you're looking at
> contains merges.
That said, git log --graph --all will show multiple branches.
I personnally like the format of
git log --graph --pretty=oneline --abbrev-commit
with ui.color set to true in ~/.gitconfig.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: git log --graph
From: Jakub Narebski @ 2009-10-11 20:30 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Sverre Rabbelier, Dilip M, git
In-Reply-To: <vpqhbu5zplr.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> I personnally like the format of
>
> $ git log --graph --pretty=oneline --abbrev-commit
>
> with ui.color set to true in ~/.gitconfig.
You can use
$ git log --graph --oneline
nowadays for that. A bit shorter.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH 0/2] user-manual: reorganize the configuration steps
From: Felipe Contreras @ 2009-10-11 20:43 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, J. Bruce Fields, Jonathan Nieder,
Felipe Contreras
This basically introduces the "getting started" section so users get familiar
with the configuration from the get-go, and also, most people prefer to teach
'git config --global' to setup the user name and email. Here are a few
examples:
git tutorial:
http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html
GNOME:
http://live.gnome.org/Git/Developers
SourceForge:
http://sourceforge.net/apps/trac/sourceforge/wiki/Git
github:
http://help.github.com/git-email-settings/
Felipe Contreras (2):
user-manual: add global config section
user-manual: simplify the user configuration
Documentation/user-manual.txt | 35 ++++++++++++++++++++++++++++++-----
1 files changed, 30 insertions(+), 5 deletions(-)
^ permalink raw reply
* [PATCH 2/2] user-manual: simplify the user configuration
From: Felipe Contreras @ 2009-10-11 20:43 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, J. Bruce Fields, Jonathan Nieder,
Felipe Contreras
In-Reply-To: <1255293786-17293-2-git-send-email-felipe.contreras@gmail.com>
This is shorter, avoids the burder to think about the format of the
configuration file, and most guides out there prefer this form.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
Documentation/user-manual.txt | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index ff2563a..bab64f8 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1008,13 +1008,11 @@ Telling git your name
---------------------
Before creating any commits, you should introduce yourself to git. The
-easiest way to do so is to make sure the following lines appear in a
-file named .gitconfig in your home directory:
+easiest way is to use the linkgit:git-config[1] command:
------------------------------------------------
-[user]
- name = Your Name Comes Here
- email = you@yourdomain.example.com
+$ git config --global user.name "Your Name Comes Here"
+$ git config --global user.email you@yourdomain.example.com
------------------------------------------------
(See the "CONFIGURATION FILE" section of linkgit:git-config[1] for
--
1.6.5.4.g31fc3
^ permalink raw reply related
* [PATCH 0/3] Trivial patches
From: Felipe Contreras @ 2009-10-11 20:46 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
These are a bunch of no-brainers. The one for bool types has been discussed and
agreed before.
Felipe Contreras (3):
Fix a bunch of pointer declarations (codestyle)
git config: clarify bool types
user-manual: use 'fast-forward'
Documentation/user-manual.txt | 14 +++++++-------
builtin-config.c | 4 ++--
diff.c | 2 +-
3 files changed, 10 insertions(+), 10 deletions(-)
^ permalink raw reply
* [PATCH 1/2] user-manual: add global config section
From: Felipe Contreras @ 2009-10-11 20:43 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, J. Bruce Fields, Jonathan Nieder,
Felipe Contreras
In-Reply-To: <1255293786-17293-1-git-send-email-felipe.contreras@gmail.com>
So that users get to know how to configure git from the get-to with good
practical example (color.ui = auto) that most people would probably like
anyway.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
Documentation/user-manual.txt | 27 +++++++++++++++++++++++++++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 67ebffa..ff2563a 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -40,6 +40,33 @@ without any explanation.
Finally, see <<todo>> for ways that you can help make this manual more
complete.
+[[getting-started]]
+Getting started
+=============
+
+Git's configuration is distributed among different locations--this manual will
+only to deal with 'global' (for the user) and 'repository' variables, where
+'repository' variables take precedence over 'global' ones.
+
+You would probably want to start setting up something useful:
+------------------------------------------------
+$ git config --global color.ui auto
+------------------------------------------------
+
+This will make prettier the output of certain commands such as `git diff`, but
+that's not important; what is important here is that `color.ui` has been
+stored in the 'global' configuration.
+
+View and manually modify the configuration by opening `~/.gitconfig`:
+------------------------------------------------
+[color]
+ ui = auto
+------------------------------------------------
+
+Other locations are `/etc/gitconfig` (system), and `.git/config` (repository).
+
+More git configurations will be covered in the rest of the manual, if you want
+to learn more look at linkgit:git-config[1] for details.
[[repositories-and-branches]]
Repositories and Branches
--
1.6.5.4.g31fc3
^ permalink raw reply related
* [PATCH 3/3] user-manual: use 'fast-forward'
From: Felipe Contreras @ 2009-10-11 20:46 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
In-Reply-To: <1255293973-17444-3-git-send-email-felipe.contreras@gmail.com>
It's a compound word.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
Documentation/user-manual.txt | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 67ebffa..42d92fd 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1384,7 +1384,7 @@ were merged.
However, if the current branch is a descendant of the other--so every
commit present in the one is already contained in the other--then git
-just performs a "fast forward"; the head of the current branch is moved
+just performs a "fast-forward"; the head of the current branch is moved
forward to point at the head of the merged-in branch, without any new
commits being created.
@@ -1719,7 +1719,7 @@ producing a default commit message documenting the branch and
repository that you pulled from.
(But note that no such commit will be created in the case of a
-<<fast-forwards,fast forward>>; instead, your branch will just be
+<<fast-forwards,fast-forward>>; instead, your branch will just be
updated to point to the latest commit from the upstream branch.)
The `git pull` command can also be given "." as the "remote" repository,
@@ -1943,7 +1943,7 @@ $ git push ssh://yourserver.com/~you/proj.git master
-------------------------------------------------
As with `git fetch`, `git push` will complain if this does not result in a
-<<fast-forwards,fast forward>>; see the following section for details on
+<<fast-forwards,fast-forward>>; see the following section for details on
handling this case.
Note that the target of a "push" is normally a
@@ -1976,7 +1976,7 @@ details.
What to do when a push fails
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-If a push would not result in a <<fast-forwards,fast forward>> of the
+If a push would not result in a <<fast-forwards,fast-forward>> of the
remote branch, then it will fail with an error like:
-------------------------------------------------
@@ -2115,7 +2115,7 @@ $ git checkout release && git pull
Important note! If you have any local changes in these branches, then
this merge will create a commit object in the history (with no local
-changes git will simply do a "Fast forward" merge). Many people dislike
+changes git will simply do a fast-forward merge). Many people dislike
the "noise" that this creates in the Linux history, so you should avoid
doing this capriciously in the "release" branch, as these noisy commits
will become part of the permanent history when you ask Linus to pull
@@ -2729,9 +2729,9 @@ In the previous example, when updating an existing branch, "git fetch"
checks to make sure that the most recent commit on the remote
branch is a descendant of the most recent commit on your copy of the
branch before updating your copy of the branch to point at the new
-commit. Git calls this process a <<fast-forwards,fast forward>>.
+commit. Git calls this process a <<fast-forwards,fast-forward>>.
-A fast forward looks something like this:
+A fast-forward looks something like this:
................................................
o--o--o--o <-- old head of the branch
--
1.6.5.4.g31fc3
^ permalink raw reply related
* [PATCH 2/3] git config: clarify bool types
From: Felipe Contreras @ 2009-10-11 20:46 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
In-Reply-To: <1255293973-17444-2-git-send-email-felipe.contreras@gmail.com>
The value is what it is, the --bool and --bool-or-int options don't
specify the value type, just how it is interpreted. For example: a value
of '1' can be interpreted as 'true'.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
builtin-config.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin-config.c b/builtin-config.c
index a2d656e..29d7b75 100644
--- a/builtin-config.c
+++ b/builtin-config.c
@@ -66,9 +66,9 @@ static struct option builtin_config_options[] = {
OPT_STRING(0, "get-color", &get_color_slot, "slot", "find the color configured: [default]"),
OPT_STRING(0, "get-colorbool", &get_colorbool_slot, "slot", "find the color setting: [stdout-is-tty]"),
OPT_GROUP("Type"),
- OPT_BIT(0, "bool", &types, "value is \"true\" or \"false\"", TYPE_BOOL),
+ OPT_BIT(0, "bool", &types, "value is intepreted as bool (\"true\" or \"false\")", TYPE_BOOL),
OPT_BIT(0, "int", &types, "value is decimal number", TYPE_INT),
- OPT_BIT(0, "bool-or-int", &types, "value is --bool or --int", TYPE_BOOL_OR_INT),
+ OPT_BIT(0, "bool-or-int", &types, "value is interpreted either as bool or int", TYPE_BOOL_OR_INT),
OPT_GROUP("Other"),
OPT_BOOLEAN('z', "null", &end_null, "terminate values with NUL byte"),
OPT_END(),
--
1.6.5.4.g31fc3
^ permalink raw reply related
* [PATCH 1/3] Fix a bunch of pointer declarations (codestyle)
From: Felipe Contreras @ 2009-10-11 20:46 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
In-Reply-To: <1255293973-17444-1-git-send-email-felipe.contreras@gmail.com>
Essentially; s/type* /type */ as per the coding guidelines.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
diff.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/diff.c b/diff.c
index e1be189..b39c1b6 100644
--- a/diff.c
+++ b/diff.c
@@ -999,7 +999,7 @@ static void show_stats(struct diffstat_t *data, struct diff_options *options)
total_files, adds, dels);
}
-static void show_shortstats(struct diffstat_t* data, struct diff_options *options)
+static void show_shortstats(struct diffstat_t *data, struct diff_options *options)
{
int i, adds = 0, dels = 0, total_files = data->nr;
--
1.6.5.4.g31fc3
^ permalink raw reply related
* Re: [PATCH 1/3] Fix a bunch of pointer declarations (codestyle)
From: Thiago Farina @ 2009-10-11 20:53 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <1255293973-17444-2-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> wrote:
"Fix a bunch of pointer declarations".
But in this patch you fixed *only* one pointer declaration:
struct diffstat_t* data -> struct diffstat_t *data
^ permalink raw reply
* Re: [PATCH 1/3] Fix a bunch of pointer declarations (codestyle)
From: Felipe Contreras @ 2009-10-11 20:56 UTC (permalink / raw)
To: Thiago Farina; +Cc: git
In-Reply-To: <a4c8a6d00910111353r20de1fb6u2289999491a9310a@mail.gmail.com>
On Sun, Oct 11, 2009 at 11:53 PM, Thiago Farina <tfransosi@gmail.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> wrote:
> "Fix a bunch of pointer declarations".
>
> But in this patch you fixed *only* one pointer declaration:
> struct diffstat_t* data -> struct diffstat_t *data
Yeah, it's a remainder of a patch I sent some time ago. I don't know
why that didn't got picked up =/
--
Felipe Contreras
^ permalink raw reply
* [ANN] gitsharp version 0.1.3 released
From: Meinrad Recheis @ 2009-10-11 21:10 UTC (permalink / raw)
To: git
Hello git community,
GitSharp intends to bring best native git support to Windows. So far
the command line interface is still alpha but the library
GitSharp.Core is already quite usable.
Status Report:
Porting of the jgit core is done, we are waiting for the jgit people
to commit something ;). Just kidding, we still need to port some code
from the jgit command line interface and we are working on a hand full
of porting bugs in the core. Some important bugs have been squashed
since the last release:
In a heroic debugging effort Nulltoken fixed the index-bug that made
git# incompatible to the original git. Now we are on track again.
Rolenun fixed git.exe which failed when started on windows via the
system %PATH%.
On top of that, there is a new user centric api which resides in
namespace Git. It simplifies interaction with git objects and
commands, hides the technical complexity of the core and should
provide a stable interface for your applications (once it is done).
The api is still work in progress, so please expect that it will be
changed / improved / extended, until everyone is happy with it. You
can see it in action in the repository browser demo at
http://github.com/henon/GitSharp.Demo
Have fun,
--Henon
^ permalink raw reply
* [PATCH] Documentation: add 'git replace' to main git manpage
From: SZEDER Gábor @ 2009-10-11 21:08 UTC (permalink / raw)
To: git; +Cc: SZEDER Gábor
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
command-list.txt | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/command-list.txt b/command-list.txt
index fb03a2e..59b0adc 100644
--- a/command-list.txt
+++ b/command-list.txt
@@ -92,6 +92,7 @@ git-reflog ancillarymanipulators
git-relink ancillarymanipulators
git-remote ancillarymanipulators
git-repack ancillarymanipulators
+git-replace ancillarymanipulators
git-repo-config ancillarymanipulators deprecated
git-request-pull foreignscminterface
git-rerere ancillaryinterrogators
--
1.6.5.85.g16dab
^ permalink raw reply related
* Re: Git 1.6.5-rc git clone unhandled exception using http protocol
From: eduard stefan @ 2009-10-11 21:12 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: Git Mailing List, msysgit
In-Reply-To: <be6fef0d0910101554p53d5532cp17768d2c95e9dbf@mail.gmail.com>
Tay Ray Chuan wrote:
> just to check, running
>
> echo list | git remote-curl http://github.com/loudej/spark.git
>
> and
>
> git clone http://github.com/loudej/spark.git
>
> both gives the same error message:
>
> An unhandled win32 exception occurred in git-remote-curl.exe [5820].
> Just-In-Time debugging this exception failed with the following
> error: No installed debugger has Just-In-Time debugging enabled. In
> Visual Studio, Just-In-Time debugging can be enabled from
> Tools/Options/Debugging/Just-In-Time.
>
> Check the documentation index for 'Just-in-time debugging, errors'
> for more information.
>
> in a dialog?
>
>> Is there any way to obtain more information from this crash?
>> Some debug mode?
>
> I'm assuming you're using the Microsoft Visual Studio development
> tools to compile git from the source. I'm cc'ing this to the msysgit
> mailing list, perhaps someone familiar with them can advise you
> further.
>
Git was compiled with msysGit, the errors are generated inside msysGit shell,
and VS2008 debugger gives this message:
"Unhandled exception at 0x00420354 in git-remote-curl.exe:
0xC0000005: Access violation reading location 0x00000000."
Have a nice day,
Eduard
^ permalink raw reply
* Re: [PATCH 1/2] user-manual: add global config section
From: Jonathan Nieder @ 2009-10-11 22:27 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Junio C Hamano, J. Bruce Fields, Jonathan Nieder
In-Reply-To: <1255293786-17293-2-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras wrote:
> So that users get to know how to configure git from the get-to with good
> practical example (color.ui = auto) that most people would probably like
> anyway.
>
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Good idea. Some comments:
> +Git's configuration is distributed among different locations--this manual will
> +only to deal with 'global' (for the user) and 'repository' variables, where
> +'repository' variables take precedence over 'global' ones.
What are these different locations you speak of? If git’s configuration
is complicated to deal with, maybe that is something that could be
improved.
This is very early in the manual, where every word counts. I am not
very good at wording and do not have any better suggestions, but would
it be possible to more efficiently convey this:
Git reads its per-user configuration from ~/.gitignore.
That file can also be manipulated with the "git config"
command, which can be convenient in scripts or when using
operating systems like Windows where it is not clear where
the home directory is.
For example, if your terminal supports it, you can tell Git
to use color in the output for commands such as "git diff"
with "git config --global color.ui auto".
For more information and a list of possible settings, see
git-config(1).
By the way, this reminds me that I am not sure git-config(1) conveys the
list of configuration items in an ideal way. It can be easy to dismiss
that page as plumbing documentation when seeing it for the first time.
Should we ship a sample .gitconfig with all items included and comments
describing them, or a separate gitconfig(5)? Either would be easy to
generate from config.txt.
Thoughts?
Jonathan
^ permalink raw reply
* Re: [PATCH] git-add--interactive: never skip files included in index
From: Junio C Hamano @ 2009-10-11 22:22 UTC (permalink / raw)
To: Jeff King; +Cc: Pauli Virtanen, git
In-Reply-To: <20091011191440.GA2532@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sun, Oct 11, 2009 at 11:52:10AM -0700, Junio C Hamano wrote:
>
>> Thanks.
>>
>> The change looks innocent enough and I do not expect to see any unexpected
>> regressions from it, but it is a bit too late for 1.6.5 cycle, so let's
>> queue this fix and aim for 1.6.5.1.
>
> I think this patch is good to apply, as there is no conceivable reason
> to even look at excludes when listing modified files.
>
> But this triggered my spider sense; shouldn't --exclude-standard simply
> be a no-op for ls-files when we are not listing untracked files? And
> bisecting, it seems that it is a very old regression caused by 63d285c
> (per-directory-exclude: lazily read .gitignore files, 2007-11-29).
>
> I don't know if it is worth fixing now or not. It does seem a bit
> inconsistent to me (since everything else is very clear that .gitignore
> is only about untracked files), but nobody seems to have been
> complaining for the last two years (and they may have, in fact, been
> coding to the new behavior).
This is one of those moments when I feel very blessed to have competent
and diligent people around me ;-)
I think you are right; that we shouldn't filter the output with gitignore
entries when showing what is _in_ the index.
^ permalink raw reply
* Script to convert git patches to Hg format
From: Mark Lodato @ 2009-10-11 22:56 UTC (permalink / raw)
To: git list
To make it easier to submit patches to a project using Hg, I wrote a
small script to convert the output of `git format-patch' to something
suitable for `hg import'. The latest version is available at:
http://github.com/MarkLodato/patch-converter
While `hg import' *can* read a git patch, it does not interpret the
date, and it includes the diffstat in the commit log. This script
fixes those problems.
The script worked well enough for me, but bugs may exist. If you have
ideas for improvement, patches are welcome :)
--
Mark
^ permalink raw reply
* Re: gitweb - bare repos integration - owner info in description file
From: Johannes Schindelin @ 2009-10-12 0:04 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Eugene Sajine, git
In-Reply-To: <200910102045.13374.jnareb@gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 806 bytes --]
Hi,
On Sat, 10 Oct 2009, Jakub Narebski wrote:
> On Sat, 10 Oct 2009, Eugene Sajine wrote:
>
> > [something, but forgot to say whom he quoted:]
>
> > > %
> > > "To be fair, there are uses for XML. On Halloween, for example."
> > >
> > > - Johannes Schindelin, on git@vger.kernel.org
> > > %
> >
> > yeah, to show kids xml print outs as an answer to "trick or treat!".
> > Can save on candies;)
>
> Err, I think Dscho meant here that XML is so *scary*... Isn't it?
XML can be scary. Somebody on usenet once said something like: "XML is
just a skeleton; if you see a skeleton walking around, wouldn't you
be scared?"
What is really scary, though, is how many people really believe that just
using XML will magically solve all problems of this world. They really
believe that.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] disallow refs containing successive slashes
From: Jonathan Nieder @ 2009-10-12 0:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jens Lehmann, git
In-Reply-To: <7vbpkdwyo2.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> When the users make typoes (e.g. /foo//bar) you can accept the only sane
> correction (e.g. foo/bar) instead of rejecting, since the only thing the
> user can do after getting such a rejection is to correct it to that
> corrected name (e.g. foo/bar) himself and re-issue the command anyway.
> You can push the "hassle" down to the user, or you can fix the tool to
> remove the hassle from the user.
Yes, making check-ref-format stricter without changing its users to
massage their input would be a regression.
The problem Jens described is a git-gui bug. In lib/branch_delete.tcl,
line 57, the list of deletable branches is populated as follows:
foreach h [load_all_heads] {
if {$h ne $current_branch} {
$w_heads insert end $h
}
}
Since slashes coalesce, a user-supplied new branch name is not canonical
and checking "$h eq $current_branch" does not actually check if they are
the same branch. git-gui should be using the branch name as output by
"git check-ref-format --branch" after the branch is created.
But what about other scripts that assume each branch has only one
possible name? Maybe they could be forced to fix up the name early on
by making check-ref-format reject names with "//" in them and providing
a "git check-ref-format --print" to help.
Upside: scripts would complain loudly instead of failing subtly on input
with extra slashes if they forget to use "git check-ref-format --print"
when appropriate. Downside: users, including the 22 callers of
check_ref_format() in git, would have to be checked and probably changed
to avoid regressions.
Never having made that typo, I find it hard to consider such a change
worth the trouble, but it sounds doable.
Regards,
Jonathan
^ permalink raw reply
* Re: [PATCH] git-add--interactive: never skip files included in index
From: Jeff King @ 2009-10-12 1:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pauli Virtanen, git
In-Reply-To: <7vpr8tr2pe.fsf@alter.siamese.dyndns.org>
On Sun, Oct 11, 2009 at 03:22:05PM -0700, Junio C Hamano wrote:
> > I don't know if it is worth fixing now or not. It does seem a bit
> > inconsistent to me (since everything else is very clear that .gitignore
> > is only about untracked files), but nobody seems to have been
> > complaining for the last two years (and they may have, in fact, been
> > coding to the new behavior).
>
> This is one of those moments when I feel very blessed to have competent
> and diligent people around me ;-)
Well, I have to do _something_ to make up for all the brown paper bag
bugs. ;)
> I think you are right; that we shouldn't filter the output with gitignore
> entries when showing what is _in_ the index.
So being the diligent and competent soul that I am, I started to prepare
a patch for this, which is included below. But the plot thickens.
I bisected the change of behavior to 63d285c, as I mentioned. But when I
found the code that needed to be tweaked, it actually git-blames to a
much earlier date in "git show-files", which later became ls-files. See
9ff768e.
So now I am doubly confused. Did this feature exist, and was broken, and
you actually fixed it in 63d285c, creating what looked like a regression
but was actually intentional?
And more importantly, what do you want to do with it now?
---
builtin-ls-files.c | 8 --------
t/t3003-ls-files-exclude.sh | 32 ++++++++++++++++++++++++++++++++
2 files changed, 32 insertions(+), 8 deletions(-)
create mode 100755 t/t3003-ls-files-exclude.sh
diff --git a/builtin-ls-files.c b/builtin-ls-files.c
index 2c95ca6..c5c0407 100644
--- a/builtin-ls-files.c
+++ b/builtin-ls-files.c
@@ -170,10 +170,6 @@ static void show_files(struct dir_struct *dir, const char *prefix)
if (show_cached | show_stage) {
for (i = 0; i < active_nr; i++) {
struct cache_entry *ce = active_cache[i];
- int dtype = ce_to_dtype(ce);
- if (excluded(dir, ce->name, &dtype) !=
- !!(dir->flags & DIR_SHOW_IGNORED))
- continue;
if (show_unmerged && !ce_stage(ce))
continue;
if (ce->ce_flags & CE_UPDATE)
@@ -186,10 +182,6 @@ static void show_files(struct dir_struct *dir, const char *prefix)
struct cache_entry *ce = active_cache[i];
struct stat st;
int err;
- int dtype = ce_to_dtype(ce);
- if (excluded(dir, ce->name, &dtype) !=
- !!(dir->flags & DIR_SHOW_IGNORED))
- continue;
if (ce->ce_flags & CE_UPDATE)
continue;
err = lstat(ce->name, &st);
diff --git a/t/t3003-ls-files-exclude.sh b/t/t3003-ls-files-exclude.sh
new file mode 100755
index 0000000..fc1e379
--- /dev/null
+++ b/t/t3003-ls-files-exclude.sh
@@ -0,0 +1,32 @@
+#!/bin/sh
+
+test_description='ls-files --exclude does not affect index files'
+. ./test-lib.sh
+
+test_expect_success 'create repo with file' '
+ echo content >file &&
+ git add file &&
+ git commit -m file &&
+ echo modification >file
+'
+
+check_output() {
+test_expect_success "ls-files output contains file ($1)" "
+ echo '$2' >expect &&
+ git ls-files --exclude-standard --$1 >output &&
+ test_cmp expect output
+"
+}
+
+check_all_output() {
+ check_output 'cached' 'file'
+ check_output 'modified' 'file'
+}
+
+check_all_output
+test_expect_success 'add file to gitignore' '
+ echo file >.gitignore
+'
+check_all_output
+
+test_done
--
1.6.5.rc3.240.g77692
^ permalink raw reply related
* Re: [PATCH] disallow refs containing successive slashes
From: Nanako Shiraishi @ 2009-10-12 2:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jens Lehmann, git
In-Reply-To: <7vbpkdwyo2.fsf@alter.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com> writes:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>> Yes, one solution could be to fix every application handling branch, tag
>> or repo names to mimic the namechange done in the bowels of git. But i
>> think it is not worth the hassle.
> Besides, by rejecting what we used to accept you are breaking people's
> expectations. So I am moderately negative, unless you can say your "every
> application" is literally _tons_.
Isn't 1.7.0 a good release to break such people's expectations?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH] git-add--interactive: never skip files included in index
From: Junio C Hamano @ 2009-10-12 2:46 UTC (permalink / raw)
To: Jeff King; +Cc: Pauli Virtanen, git
In-Reply-To: <20091012014007.GA7674@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> So now I am doubly confused. Did this feature exist, and was broken, and
> you actually fixed it in 63d285c, creating what looked like a regression
> but was actually intentional?
I do not think it was an intentional change. I _think_ the comment at the
beginning of show_files() tells us quite a bit---we don't do read-dir when
showing the indexed files, and I suspect that we used to rely on the fact
that not doing the read-dir made exclusion mechanism a no-op. After the
lazy .gitignore reading, I suspect that excluded() call started to
initialize the exclude mechanism lazily, and that is how the bug was
introduced, isn't it?
Regarding your patch, the loops deal with paths that are already in the
index, so removing the conditional skip looks like a sane thing to do.
^ permalink raw reply
* [PATCH] Aggressive three-way merge: fix D/F case
From: Junio C Hamano @ 2009-10-12 2:53 UTC (permalink / raw)
To: git
When the ancestor used to have a blob "P", your tree removed it, and the
tree you are merging with also removed it, the agressive three-way cleanly
merges to remove that blob. If the other tree added a new blob "P/Q"
while removing "P", it should also merge cleanly to remove "P" and create
"P/Q" (since neither the ancestor nor your tree could have had it, so it
is a typical "created in one").
The "aggressive" rule is not new anymore. Reword the stale comment.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* This fixes one problem in the 3-way merge with corrected tree/index
entry order the jc/fix-tree-walk topic exposes.
t/t6035-merge-dir-to-symlink.sh | 2 +-
unpack-trees.c | 13 ++++++++-----
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/t/t6035-merge-dir-to-symlink.sh b/t/t6035-merge-dir-to-symlink.sh
index b9a280e..d1b2287 100755
--- a/t/t6035-merge-dir-to-symlink.sh
+++ b/t/t6035-merge-dir-to-symlink.sh
@@ -74,7 +74,7 @@ test_expect_success 'setup a merge where dir a/b-2 changed to symlink' '
git tag test2
'
-test_expect_failure 'merge should not have conflicts (resolve)' '
+test_expect_success 'merge should not have conflicts (resolve)' '
git reset --hard &&
git checkout baseline^0 &&
git merge -s resolve test2 &&
diff --git a/unpack-trees.c b/unpack-trees.c
index c424bab..ec12341 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -767,7 +767,8 @@ int threeway_merge(struct cache_entry **stages, struct unpack_trees_options *o)
remote = NULL;
}
- /* First, if there's a #16 situation, note that to prevent #13
+ /*
+ * First, if there's a #16 situation, note that to prevent #13
* and #14.
*/
if (!same(remote, head)) {
@@ -781,7 +782,8 @@ int threeway_merge(struct cache_entry **stages, struct unpack_trees_options *o)
}
}
- /* We start with cases where the index is allowed to match
+ /*
+ * We start with cases where the index is allowed to match
* something other than the head: #14(ALT) and #2ALT, where it
* is permitted to match the result instead.
*/
@@ -811,12 +813,13 @@ int threeway_merge(struct cache_entry **stages, struct unpack_trees_options *o)
if (!head && !remote && any_anc_missing)
return 0;
- /* Under the new "aggressive" rule, we resolve mostly trivial
+ /*
+ * Under the "aggressive" rule, we resolve mostly trivial
* cases that we historically had git-merge-one-file resolve.
*/
if (o->aggressive) {
- int head_deleted = !head && !df_conflict_head;
- int remote_deleted = !remote && !df_conflict_remote;
+ int head_deleted = !head;
+ int remote_deleted = !remote;
struct cache_entry *ce = NULL;
if (index)
--
1.6.5.59.g7e3f2
^ permalink raw reply related
* Re: git log --graph
From: Dilip M @ 2009-10-12 3:01 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git
In-Reply-To: <fabb9a1e0910111135v4f3c75a7v6657f5dcfacf13ac@mail.gmail.com>
On Mon, Oct 12, 2009 at 12:05 AM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> Heya,
>
> On Sun, Oct 11, 2009 at 20:27, Dilip M <dilipm79@gmail.com> wrote:
>> I am trying git log --graph. (has commits in two branches...). But
>> always see one line :(
>
> It'll show you the history of one branch at a time online, you won't
> get the demo-ed multiple lines unless the branch you're looking at
> contains merges.
Understood. it shows only when I have merged conflicts!
In case, it is a fast forward merge. It doesn't show. Which is good :)
Thanks to all.
-
Dilip
^ 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