* Re: [PATCH] Teach remote machinery about remotes.default config variable
From: Mark Levedahl @ 2008-01-15 23:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7arhas9.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
>> Nope, git submodule *still* requires origin (e.g., execute git
>> submodule init or update on a detached head).
>>
>
> Now I am even more confused.
>
> The approach I suggested in a few paragraphs above, to which you
> just said "I like this change", is about making "git submodule
> update" to use the url configured in the upper level repository
> when it runs "git fetch". I am looking at around l.238 of
> git-submodule.sh. In the current code, it runs "git-fetch"
> without any parameter, which would allow it default to origin or
> whatever, which may or may not be desirable depending on where
> the 'origin' points at. If you make that particular git-fetch
> explicitly say where the fetch should be done from, wouldn't it
> fix the issue for that codepath? Why does it still require
> origin?
1) If top-level is on a detached head, then the remotes machinery will
find current remote is "origin". This is what would be passed down the
chain.
2) Absent the other changes in the thread, git-submodule-init still
invokes git clone *without* -o in the submodules, and thus still
defines and points to remote "origin".
Mark
^ permalink raw reply
* Re: [PATCH] safecrlf: Add flag to convert_to_git() to disable safecrlf check
From: Dmitry Potapov @ 2008-01-15 23:03 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: gitster, torvalds, git
In-Reply-To: <53A4FB98-25B5-4598-BED8-7D96AF5527F4@zib.de>
On Tue, Jan 15, 2008 at 09:39:00PM +0100, Steffen Prohaska wrote:
>
> On Jan 15, 2008, at 11:26 AM, Dmitry Potapov wrote:
>
> >but it also means that there is no longer
> >any warning when you are running git diff with the work tree,
> >which would be useful, because it is what most users do before
> >adding anything.
>
> My first concern is to avoid data corruption. But we should also
> avoid to unnecessarily bother users with annoying warnings.
I don't think we bother users with unnecessary warnings. If there
is a problem then it is better to report it earlier than later,
and we *really* want that the user took some action, i.e. either
to mark this file as binary using .gitattributes or corrected its
endings. However, reporting the same problem twice during running
one command does not look nice...
> Thus
> I thought that guarding only the code paths that modify data in
> an irreversible way is sufficient and hence I only guarded the
> code path that writes to the repository.
This policy makes sense to me, it is just I would prefer if we
could find a way to warn a user a bit earlier...
> The underlying
> assumption is that git checkout is the only way of destroying the
> original data. Unless you check out you still have the original
> data and can copy them to a safe place.
It is obvious to you but it may be not so obvious to a new user.
Running 'git diff' before check in is a common practice, so if
the warning was reported at that moment then he or she would not
check in.
Anyway, I like your solution for being simple and guarding the
most important pass reliably.
Dmitry
^ permalink raw reply
* Re: Git Cygwin - unable to create any repository - help!
From: Robin Rosenberg @ 2008-01-15 23:02 UTC (permalink / raw)
To: Paul Umbers; +Cc: Alex Riesen, git
In-Reply-To: <a5eb9c330801151212y30cf4f63r9c294ba33da2b8f@mail.gmail.com>
tisdagen den 15 januari 2008 skrev Paul Umbers:
> git ls (see below) returns nothing - it looks like the object doesn't
> exist at all. I've attached a .zip of the entire test directory (one
> text file plus .git). This is after "git init" followed by "git add ."
>
> What do you think?
Git comes with test suite. Try it using make test or
GIT_TEST_OPTS="--debug --verbose" make test
The extra options are there since we expect it to fail.
-- robin
^ permalink raw reply
* Re: Git Cygwin - unable to create any repository - help!
From: Alex Riesen @ 2008-01-15 22:55 UTC (permalink / raw)
To: Paul Umbers; +Cc: git
In-Reply-To: <a5eb9c330801151359q5a474a83le36ae9076ad4e5c1@mail.gmail.com>
Paul Umbers, Tue, Jan 15, 2008 22:59:52 +0100:
> Git version is 1.5.3.8.
That's ok too. The git-add is as verbose regarding errors as today.
Next would be to try to recompile git and instrument that file:
> On Jan 15, 2008 2:20 PM, Alex Riesen <raa.lkml@gmail.com> wrote:
> > Hmm... What "git version" returns for you? (the .git/config contains
> > filemode=true, which cygwin breaks every time).
> >
> > Of course, it would be interesting to know if the current git works
> > for you. Or the MinGW port:
> >
> > http://code.google.com/p/msysgit/downloads/list
> >
> > It used to conflict with cygwin, though.
Or try the MinGW port
> > If the current git fails, I'd suggest to instrument write_sha1_file in
> > sha1_file.c and see if it really manages to create temporary file and
> > rename it to sha1 file (that d9/b06fceac52f6c24357e6a7f85c601088381152).
> > I suspect either rename or link failing silently (IOW, it fails to
> > create the new name under objects/d9/ but returns 0(no error) anyway).
That sha1_file.c above
^ permalink raw reply
* Re: Git Cygwin - unable to create any repository - help!
From: Alex Riesen @ 2008-01-15 22:51 UTC (permalink / raw)
To: Paul Umbers; +Cc: git
In-Reply-To: <a5eb9c330801151357w62674db6td23dd2c501e62728@mail.gmail.com>
Paul Umbers, Tue, Jan 15, 2008 22:57:35 +0100:
> Try this ... test.tar (from within cygwin).
>
Ok, nothing suspicios here.
^ permalink raw reply
* [PATCH - v3] gitk: fix "Key bindings" message
From: Michele Ballabio @ 2008-01-15 22:31 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <18316.40891.875291.618507@cargo.ozlabs.ibm.com>
The "Key bindings" message under the "Help" menu was too long
and could not be parsed by the translation engine.
Fix both issues by translating one line at a time.
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
---
On Tuesday 15 January 2008, Paul Mackerras wrote:
> I am wondering whether the help text
> needs to be busted up into individual lines for processing by [mc].
Here it is. With this patch the strings do show up in po/gitk.pot.
gitk | 78 +++++++++++++++++++++++++++++++++---------------------------------
1 files changed, 39 insertions(+), 39 deletions(-)
diff --git a/gitk b/gitk
index 5560e4d..7555968 100755
--- a/gitk
+++ b/gitk
@@ -1307,45 +1307,45 @@ proc keys {} {
}
toplevel $w
wm title $w [mc "Gitk key bindings"]
- message $w.m -text [mc "
-Gitk key bindings:
-
-<$M1T-Q> Quit
-<Home> Move to first commit
-<End> Move to last commit
-<Up>, p, i Move up one commit
-<Down>, n, k Move down one commit
-<Left>, z, j Go back in history list
-<Right>, x, l Go forward in history list
-<PageUp> Move up one page in commit list
-<PageDown> Move down one page in commit list
-<$M1T-Home> Scroll to top of commit list
-<$M1T-End> Scroll to bottom of commit list
-<$M1T-Up> Scroll commit list up one line
-<$M1T-Down> Scroll commit list down one line
-<$M1T-PageUp> Scroll commit list up one page
-<$M1T-PageDown> Scroll commit list down one page
-<Shift-Up> Find backwards (upwards, later commits)
-<Shift-Down> Find forwards (downwards, earlier commits)
-<Delete>, b Scroll diff view up one page
-<Backspace> Scroll diff view up one page
-<Space> Scroll diff view down one page
-u Scroll diff view up 18 lines
-d Scroll diff view down 18 lines
-<$M1T-F> Find
-<$M1T-G> Move to next find hit
-<Return> Move to next find hit
-/ Move to next find hit, or redo find
-? Move to previous find hit
-f Scroll diff view to next file
-<$M1T-S> Search for next hit in diff view
-<$M1T-R> Search for previous hit in diff view
-<$M1T-KP+> Increase font size
-<$M1T-plus> Increase font size
-<$M1T-KP-> Decrease font size
-<$M1T-minus> Decrease font size
-<F5> Update
-"] \
+ message $w.m -text "
+[mc "Gitk key bindings:"]
+
+[mc "<%s-Q> Quit" $M1T]
+[mc "<Home> Move to first commit"]
+[mc "<End> Move to last commit"]
+[mc "<Up>, p, i Move up one commit"]
+[mc "<Down>, n, k Move down one commit"]
+[mc "<Left>, z, j Go back in history list"]
+[mc "<Right>, x, l Go forward in history list"]
+[mc "<PageUp> Move up one page in commit list"]
+[mc "<PageDown> Move down one page in commit list"]
+[mc "<%s-Home> Scroll to top of commit list" $M1T]
+[mc "<%s-End> Scroll to bottom of commit list" $M1T]
+[mc "<%s-Up> Scroll commit list up one line" $M1T]
+[mc "<%s-Down> Scroll commit list down one line" $M1T]
+[mc "<%s-PageUp> Scroll commit list up one page" $M1T]
+[mc "<%s-PageDown> Scroll commit list down one page" $M1T]
+[mc "<Shift-Up> Find backwards (upwards, later commits)"]
+[mc "<Shift-Down> Find forwards (downwards, earlier commits)"]
+[mc "<Delete>, b Scroll diff view up one page"]
+[mc "<Backspace> Scroll diff view up one page"]
+[mc "<Space> Scroll diff view down one page"]
+[mc "u Scroll diff view up 18 lines"]
+[mc "d Scroll diff view down 18 lines"]
+[mc "<%s-F> Find" $M1T]
+[mc "<%s-G> Move to next find hit" $M1T]
+[mc "<Return> Move to next find hit"]
+[mc "/ Move to next find hit, or redo find"]
+[mc "? Move to previous find hit"]
+[mc "f Scroll diff view to next file"]
+[mc "<%s-S> Search for next hit in diff view" $M1T]
+[mc "<%s-R> Search for previous hit in diff view" $M1T]
+[mc "<%s-KP+> Increase font size" $M1T]
+[mc "<%s-plus> Increase font size" $M1T]
+[mc "<%s-KP-> Decrease font size" $M1T]
+[mc "<%s-minus> Decrease font size" $M1T]
+[mc "<F5> Update"]
+" \
-justify left -bg white -border 2 -relief groove
pack $w.m -side top -fill both -padx 2 -pady 2
button $w.ok -text [mc "Close"] -command "destroy $w" -default active
--
1.5.3.5
^ permalink raw reply related
* Re: Git Cygwin - unable to create any repository - help!
From: Paul Umbers @ 2008-01-15 21:59 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20080115212022.GC3213@steel.home>
Git version is 1.5.3.8.
On Jan 15, 2008 2:20 PM, Alex Riesen <raa.lkml@gmail.com> wrote:
> Paul Umbers, Tue, Jan 15, 2008 21:12:45 +0100:
> > >
> > > Does the object exists at all? Try
> > >
> > > ls -l .git/d9/b06fceac52f6c24357e6a7f85c601088381152
> > >
> > > Is it possible to get a hold of this repo (just the .git directly
> > > after "git add .")? It would be interesting to see the nature of the
> > > corruption.
> > >
> > git ls (see below) returns nothing - it looks like the object doesn't
> > exist at all. I've attached a .zip of the entire test directory (one
>
> zip is a bit lying: it does not keep the attributes of the files the
> way cygwin programs see them. For instance, it not known whether the
> hooks (.git/hooks) where executable at the time.
>
> > text file plus .git). This is after "git init" followed by "git add ."
> >
> > What do you think?
>
> I think it has failed already at "git add". From looking at the code
> it is hard for the current git-add (builtin-add.c) to fail silently.
>
> Hmm... What "git version" returns for you? (the .git/config contains
> filemode=true, which cygwin breaks every time).
>
> Of course, it would be interesting to know if the current git works
> for you. Or the MinGW port:
>
> http://code.google.com/p/msysgit/downloads/list
>
> It used to conflict with cygwin, though.
>
> If the current git fails, I'd suggest to instrument write_sha1_file in
> sha1_file.c and see if it really manages to create temporary file and
> rename it to sha1 file (that d9/b06fceac52f6c24357e6a7f85c601088381152).
> I suspect either rename or link failing silently (IOW, it fails to
> create the new name under objects/d9/ but returns 0(no error) anyway).
>
>
--
Computer Science is no more about computers than astronomy is about telescopes.
--- Edsger W. Dijkstra
Paul Umbers MSc MBCS MIAP
paul.umbers@gmail.com
^ permalink raw reply
* Re: Git Cygwin - unable to create any repository - help!
From: Paul Umbers @ 2008-01-15 21:57 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20080115212022.GC3213@steel.home>
[-- Attachment #1: Type: text/plain, Size: 1895 bytes --]
Try this ... test.tar (from within cygwin).
On Jan 15, 2008 2:20 PM, Alex Riesen <raa.lkml@gmail.com> wrote:
> Paul Umbers, Tue, Jan 15, 2008 21:12:45 +0100:
> > >
> > > Does the object exists at all? Try
> > >
> > > ls -l .git/d9/b06fceac52f6c24357e6a7f85c601088381152
> > >
> > > Is it possible to get a hold of this repo (just the .git directly
> > > after "git add .")? It would be interesting to see the nature of the
> > > corruption.
> > >
> > git ls (see below) returns nothing - it looks like the object doesn't
> > exist at all. I've attached a .zip of the entire test directory (one
>
> zip is a bit lying: it does not keep the attributes of the files the
> way cygwin programs see them. For instance, it not known whether the
> hooks (.git/hooks) where executable at the time.
>
> > text file plus .git). This is after "git init" followed by "git add ."
> >
> > What do you think?
>
> I think it has failed already at "git add". From looking at the code
> it is hard for the current git-add (builtin-add.c) to fail silently.
>
> Hmm... What "git version" returns for you? (the .git/config contains
> filemode=true, which cygwin breaks every time).
>
> Of course, it would be interesting to know if the current git works
> for you. Or the MinGW port:
>
> http://code.google.com/p/msysgit/downloads/list
>
> It used to conflict with cygwin, though.
>
> If the current git fails, I'd suggest to instrument write_sha1_file in
> sha1_file.c and see if it really manages to create temporary file and
> rename it to sha1 file (that d9/b06fceac52f6c24357e6a7f85c601088381152).
> I suspect either rename or link failing silently (IOW, it fails to
> create the new name under objects/d9/ but returns 0(no error) anyway).
>
>
--
Computer Science is no more about computers than astronomy is about telescopes.
--- Edsger W. Dijkstra
Paul Umbers MSc MBCS MIAP
paul.umbers@gmail.com
[-- Attachment #2: test.tar --]
[-- Type: application/x-tar, Size: 30720 bytes --]
^ permalink raw reply
* Re: [PATCH] safecrlf: Add flag to convert_to_git() to disable safecrlf check
From: Steffen Prohaska @ 2008-01-15 21:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Dmitry Potapov, Linus Torvalds, Git Mailing List
In-Reply-To: <F825ADAF-036C-46FE-8E3D-540B9AA092A8@zib.de>
On Jan 15, 2008, at 9:52 PM, Steffen Prohaska wrote:
>> Of course, "git add" on the path will warn or fail with your
>> patch, but we may somehow want to be warned about the breakage
>> before "git add" on that path triggers it. Perhaps we can have
>> a separate "check-work-tree" command that iterates over locally
>> modified work tree files and runs convert_to_git() with checking
>> enabled.
>
> We could certainly have such a command, yet the question remains
> when to call it. Do you have in mind calling it when we enter
> the work tree, such that all files in the work tree will always
> be verified? Running the check once during start up should be
> sufficient and we could switch it off for the remainder of the
> execution.
>
> We would certainly print all paths with an irreversible conversion
> and only die() afterwards if requested by core.safecrlf=true.
> All information would be printed at once in an ordered way. This
> could be more user friendly than the current approach.
>
> I'll work on this.
What is the right way to iterate over the changed files?
Should I copy and adapt the following from wt-status.c?
static void wt_status_print_changed(struct wt_status *s)
{
struct rev_info rev;
init_revisions(&rev, "");
setup_revisions(0, NULL, &rev, NULL);
rev.diffopt.output_format |= DIFF_FORMAT_CALLBACK;
rev.diffopt.format_callback = wt_status_print_changed_cb;
rev.diffopt.format_callback_data = s;
wt_read_cache(s);
run_diff_files(&rev, 0);
}
Steffen
^ permalink raw reply
* [ANNOUNCE] Push Me Pull You 0.2 - Tech Preview Release
From: Mark Williamson @ 2008-01-15 21:31 UTC (permalink / raw)
To: git
Hi all,
I'd like to announce a new release of the Push Me Pull You (pmpu) tool; a GUI
for distributed revision control systems.
PMPU supports plain hg, hg forest repositories, bzr, git and darcs as
underlying repositories. It aims to provide a powerful graphical interface
to the underlying functionality, based around the workflow of incoming and
outgoing changesets.
PMPU is implemented in Python and PyQt4 and is tested on Linux, though it
should work on other Unix platforms. I eventually hope to support Windows
hosts also. For hg, bzr and git, plugins are supplied to improve integration
with the command line interface of the underlying system.
My DVCS of choice is Mercurial but I aim to properly support the other
backends and have this be an SCM-agnostic system. I would appreciate expert
feedback about my implementation of all the backends including Mercurial,
including advice if I'm doing things wrong and suggestions of further
enhancements.
Please treat this as experimental software, released as a technical preview.
The error handling is not very good and my understanding of the underlying
SCMs is still somewhat incomplete. I regard it as fairly safe and solid and
it hasn't eaten my data during all my use and testing but please be cautious
nonetheless. I don't want to make it sound like it's going to destroy the
world ;-) but I'm very aware that most users of revision control have
critical data to manage.
The website is here: http://www.cl.cam.ac.uk/~maw48/pmpu/ and contains links
to a downloadable tarball and the Mercurial repository.
Please feel free to send me e-mail with feedback or questions, no matter how
insignificant. There's no user documentation, so don't hesitate to ask me
questions about how things work. Private e-mail is fine if you prefer.
Cheers,
Mark
--
Push Me Pull You - Distributed SCM tool (http://www.cl.cam.ac.uk/pmpu/)
^ permalink raw reply
* Re: First time compiling source
From: Alex Riesen @ 2008-01-15 21:23 UTC (permalink / raw)
To: Chris Ortman; +Cc: git
In-Reply-To: <c0f2d4110801151234i2292ad2aw48e38f4f4fcb5ee7@mail.gmail.com>
Chris Ortman, Tue, Jan 15, 2008 21:34:12 +0100:
> Up until today I've always run git off whatever debs come with ubuntu.
> But if I'm going to try to do some work I figured I should be
> compiling from source.
>
> To compile I did
> git co -b current v1.5.3.8
> make
> make install
>
> then to check
> which git
> /home/chrisortman/bin/git
> as expected
>
> however git --version still reports 1.5.2.5
>
> What did I miss?
The git in /usr/bin is stuck in hashed paths of your shell?
For instance, bash remembers all the programs it managed to exec.
^ permalink raw reply
* Re: Git Cygwin - unable to create any repository - help!
From: Alex Riesen @ 2008-01-15 21:20 UTC (permalink / raw)
To: Paul Umbers; +Cc: git
In-Reply-To: <a5eb9c330801151212y30cf4f63r9c294ba33da2b8f@mail.gmail.com>
Paul Umbers, Tue, Jan 15, 2008 21:12:45 +0100:
> >
> > Does the object exists at all? Try
> >
> > ls -l .git/d9/b06fceac52f6c24357e6a7f85c601088381152
> >
> > Is it possible to get a hold of this repo (just the .git directly
> > after "git add .")? It would be interesting to see the nature of the
> > corruption.
> >
> git ls (see below) returns nothing - it looks like the object doesn't
> exist at all. I've attached a .zip of the entire test directory (one
zip is a bit lying: it does not keep the attributes of the files the
way cygwin programs see them. For instance, it not known whether the
hooks (.git/hooks) where executable at the time.
> text file plus .git). This is after "git init" followed by "git add ."
>
> What do you think?
I think it has failed already at "git add". From looking at the code
it is hard for the current git-add (builtin-add.c) to fail silently.
Hmm... What "git version" returns for you? (the .git/config contains
filemode=true, which cygwin breaks every time).
Of course, it would be interesting to know if the current git works
for you. Or the MinGW port:
http://code.google.com/p/msysgit/downloads/list
It used to conflict with cygwin, though.
If the current git fails, I'd suggest to instrument write_sha1_file in
sha1_file.c and see if it really manages to create temporary file and
rename it to sha1 file (that d9/b06fceac52f6c24357e6a7f85c601088381152).
I suspect either rename or link failing silently (IOW, it fails to
create the new name under objects/d9/ but returns 0(no error) anyway).
^ permalink raw reply
* Re: [PATCH] treat any file with NUL as binary
From: Steffen Prohaska @ 2008-01-15 21:03 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Junio C Hamano, git
In-Reply-To: <1200407309-10992-1-git-send-email-dpotapov@gmail.com>
On Jan 15, 2008, at 3:28 PM, Dmitry Potapov wrote:
> There are two heuristics in Git to detect whether a file is binary
> or text. One in xdiff-interface.c relied on existing NUL byte at
> the beginning. However, convert.c used a different heuristic, which
> relied that the number of non-printable symbols is less than 1%.
>
> Due to difference in approaches whether a file is binary or not,
> it was possible that a file that diff treats as binary will not be
> treated as text by CRLF conversation. This is very confusing for
> a user who seeing that 'git diff' shows file as binary expects it
> to be added as binary.
>
> This patch makes is_binary to consider any file that contains at
> least one NUL character as binary.
Shouldn't the commit message explicitly mention that the solution
is to make the check in convert.c stricter than the check in
xdiff-interface.c? I think a comment in xdiff-interface.c
would also be a good thing to remember future developers about
this.
> ---
>
> Junio,
>
> I believe that the current behavior where 'git diff' shows me a file
> as binary and then adds it as text with crlf conversation is a bug.
>
> Though, it is not very likely to happen, it still possible cases where
> a binary file contains large amount of text. For instance, a tar file
> of text files can be such a file. Probably, word processor that store
> text in binary format may also generate a file with more 99% printable
> characters. So, such files will be considered as text by current
> convert
> heuristic. Still such files are considered by diff due present of a
> NUL
> character. This is very confusing for a user to see 'git diff' saying
> that a file is binary and then having it converted as text. Because I
> don't think that any real text file (especially one that requires CRLF
> conversation) may contain NUL character, I believe this change should
> improve binary heuristic and avoid user confusion.
I think this is a good idea. When reading the code for the first
time it took me some time to accept that we really have different
ways for detecting a binary file and to understand how these
detections are related.
I also agree with Dimitry that convert.c should be stricter than
xdiff-interface.c, because everything else could be confusing. ...
> So, please, consider it for inclusion as a bug fix.
... H\x05ence, this should be considered a bug fix.
The patch looks good to me.
Steffen
^ permalink raw reply
* Re: First time compiling source
From: Chris Ortman @ 2008-01-15 21:01 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20080115205603.GA12055@coredump.intra.peff.net>
That was it, thanks.
On Jan 15, 2008 2:56 PM, Jeff King <peff@peff.net> wrote:
> On Tue, Jan 15, 2008 at 02:34:12PM -0600, Chris Ortman wrote:
>
> > then to check
> > which git
> > /home/chrisortman/bin/git
> > as expected
> >
> > however git --version still reports 1.5.2.5
> >
> > What did I miss?
>
> Is bash caching the location of git? Try 'type git' in that shell, or
> try running 'git --version' from a new shell.
>
> -Peff
>
^ permalink raw reply
* Re: First time compiling source
From: Jeff King @ 2008-01-15 20:56 UTC (permalink / raw)
To: Chris Ortman; +Cc: git
In-Reply-To: <c0f2d4110801151234i2292ad2aw48e38f4f4fcb5ee7@mail.gmail.com>
On Tue, Jan 15, 2008 at 02:34:12PM -0600, Chris Ortman wrote:
> then to check
> which git
> /home/chrisortman/bin/git
> as expected
>
> however git --version still reports 1.5.2.5
>
> What did I miss?
Is bash caching the location of git? Try 'type git' in that shell, or
try running 'git --version' from a new shell.
-Peff
^ permalink raw reply
* Re: [PATCH] safecrlf: Add flag to convert_to_git() to disable safecrlf check
From: Steffen Prohaska @ 2008-01-15 20:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: dpotapov, torvalds, git
In-Reply-To: <7vk5mchsct.fsf@gitster.siamese.dyndns.org>
On Jan 15, 2008, at 12:58 AM, Junio C Hamano wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
>> We want to verify if an autocrlf conversion is reversible only if
>> the converted data is actually written to the repository. Only
>> in this case the file would be modified during the next checkout.
>> But convert_to_git() is used for some other purposes.
>> This commit adds a flag to convert_to_git() that controls if the
>> safecrlf check is enabled...
>
> At first this felt dirty to me as convert_to_git() is not
> limited to crlf, but about external vs canonical representation.
> The variable name being "checksafe" however makes it much more
> palatable. It is clear that it is talking about irreversible
> conversion.
>
> When running diff with a work tree file and the index (or a
> named tree), we read the work tree file and run convert_to_git()
> on it before comparing it with what we have in the object store
> (either index or a named tree). When running apply without
> touching the index, we also use convert_to_git() on the work
> tree file. The patch file is supposed to record the data in
> canonical format, I think.
>
> Of course, "git add" on the path will warn or fail with your
> patch, but we may somehow want to be warned about the breakage
> before "git add" on that path triggers it. Perhaps we can have
> a separate "check-work-tree" command that iterates over locally
> modified work tree files and runs convert_to_git() with checking
> enabled.
We could certainly have such a command, yet the question remains
when to call it. Do you have in mind calling it when we enter
the work tree, such that all files in the work tree will always
be verified? Running the check once during start up should be
sufficient and we could switch it off for the remainder of the
execution.
We would certainly print all paths with an irreversible conversion
and only die() afterwards if requested by core.safecrlf=true.
All information would be printed at once in an ordered way. This
could be more user friendly than the current approach.
I'll work on this.
Steffen
^ permalink raw reply
* Re: git-commit fatal: Out of memory? mmap failed: Bad file descriptor
From: Brandon Casey @ 2008-01-15 20:39 UTC (permalink / raw)
To: Kristian Høgsberg
Cc: Linus Torvalds, Git Mailing List, drafnel, Junio C Hamano,
Alex Riesen
In-Reply-To: <1200427202.5821.7.camel@gaara.boston.redhat.com>
Kristian Høgsberg wrote:
> To my defense, the lockfile API is used a little inconsitently in git.
> Many places in git does a close(fd) and the call commit_locked_index(),
> which will close the fd again.
I bet they did that so that the return status of close() could be checked
since commit_lock_file() doesn't currently check it.
-brandon
^ permalink raw reply
* Re: [PATCH] safecrlf: Add flag to convert_to_git() to disable safecrlf check
From: Steffen Prohaska @ 2008-01-15 20:39 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: gitster, torvalds, git
In-Reply-To: <20080115102626.GE2963@dpotapov.dyndns.org>
On Jan 15, 2008, at 11:26 AM, Dmitry Potapov wrote:
> On Tue, Jan 15, 2008 at 12:20:40AM +0100, Steffen Prohaska wrote:
>>
>> I looked briefly at the various places where convert_to_git() is
>> called. I think that only the one code path through index_fd()
>> actually writes data to the repsitory. Maybe someone else with
>> a better understanding of git's internals should confirm this.
>
> Your patch is certainly better than my quick hack for git-add,
> and perhaps you are right that the check should be done only
> when data are written, but it also means that there is no longer
> any warning when you are running git diff with the work tree,
> which would be useful, because it is what most users do before
> adding anything.
My first concern is to avoid data corruption. But we should also
avoid to unnecessarily bother users with annoying warnings. Thus
I thought that guarding only the code paths that modify data in
an irreversible way is sufficient and hence I only guarded the
code path that writes to the repository. The underlying
assumption is that git checkout is the only way of destroying the
original data. Unless you check out you still have the original
data and can copy them to a safe place.
However, there might be other ways by which git will modify the
files in the work tree. And even commands that never touch the
local file system could be dangerous. For example a user could
run git diff to create a patch, which is sent to someone else and
applied there. The change is committed in the remote repository,
published, and pulled back to the local repository and eventually
this might result in the corruption we originally tried to avoid.
So perhaps we should guard _every_ code path that calls
convert_to_git() in an irreversible way; and only avoid printing
the same warning twice for a single run of git add. This is
exactly what your "quick hack" does.
More in my reply to Junios mail ...
> However, my real concern is that it seems we have two different
> heuristics for binary -- one that is used inside of convert.c
> and the other one is buffer_is_binary() in xdiff-interface.c.
>
> So, I am running 'git diff' for some test file, and it says:
>
> diff --git a/foo b/foo
> index e965047..c102bdc 100644
> Binary files a/foo and b/foo differ
>
> okay, now I want to add this *binary* file, so I run 'git add':
>
> warning: Stripped CRLF from foo.
>
> I imagine a user saying: "What the hell! Why did this stupid Git
> strip CRLF from my _binary_ file?"
>
> And the current version of Git, which does not print CRLF warning,
> seems to be dangerous, because when 'git diff' told me that it is
> ca _binary_ file, I expect that Git will put it as *binary*. So,
> from the user's point of view, it looks like a bug.
>
> So, I suppose that at least we should make is_binary heuristic in
> convert.c more strict than those that is used by diff. Namely, if
> there is at least one NUL byte in the buffer, it should be treated
> as binary.
I think we should do this.
Perhaps we should also place a hint for future developers in
xdiff-interface.c, like the patch below.
Steffen
diff --git a/xdiff-interface.c b/xdiff-interface.c
index 4b8e5cc..baa3664 100644
--- a/xdiff-interface.c
+++ b/xdiff-interface.c
@@ -160,6 +160,10 @@ int read_mmfile(mmfile_t *ptr, const char
*filename)
return 0;
}
+/* If you ever modify buffer_is_binary() you should check that
is_binary()
+ in convert.c always uses a stricter heuristic. That is all files
that are
+ classified as binary here should also be classified as binary in
convert.c.
+ */
#define FIRST_FEW_BYTES 8000
int buffer_is_binary(const char *ptr, unsigned long size)
{
^ permalink raw reply related
* [PATCH] ls-remote: add -t and -h options.
From: Miklos Vajna @ 2008-01-15 20:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
These options are listed in the manpage (aliases for --tags/--heads) but they
were not handled.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
Alternatively, if it's too late to introduce new options, I think we should
remove these options from the manpage, but I prefer the current fix.
builtin-ls-remote.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin-ls-remote.c b/builtin-ls-remote.c
index c2caeea..6dd31d1 100644
--- a/builtin-ls-remote.c
+++ b/builtin-ls-remote.c
@@ -54,11 +54,11 @@ int cmd_ls_remote(int argc, const char **argv, const char *prefix)
uploadpack = arg + 7;
continue;
}
- if (!strcmp("--tags", arg)) {
+ if (!strcmp("--tags", arg) || !strcmp("-t", arg)) {
flags |= REF_TAGS;
continue;
}
- if (!strcmp("--heads", arg)) {
+ if (!strcmp("--heads", arg) || !strcmp("-h", arg)) {
flags |= REF_HEADS;
continue;
}
--
1.5.4.rc3.4.g16335-dirty
^ permalink raw reply related
* First time compiling source
From: Chris Ortman @ 2008-01-15 20:34 UTC (permalink / raw)
To: git
Up until today I've always run git off whatever debs come with ubuntu.
But if I'm going to try to do some work I figured I should be
compiling from source.
To compile I did
git co -b current v1.5.3.8
make
make install
then to check
which git
/home/chrisortman/bin/git
as expected
however git --version still reports 1.5.2.5
What did I miss?
Thanks
^ permalink raw reply
* Re: [FEATURE REQUEST] git-svn format-patch
From: Chris Ortman @ 2008-01-15 20:30 UTC (permalink / raw)
To: Jean-Luc Herren; +Cc: git
In-Reply-To: <478D1442.2090301@gmx.ch>
You are correct about Tortoise in that it is too strict.
I looked through their code and they have written their own patch
program which keys off these Index: lines
http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk/src/TortoiseMerge/Patch.cpp
I think it could go either way as to if git-svn creates a different
format patch or tsvn accepts multiple formats, but I anticipated
git-svn would be easier to extend so I started here.
^ permalink raw reply
* Re: git-commit fatal: Out of memory? mmap failed: Bad file descriptor
From: Brandon Casey @ 2008-01-15 20:27 UTC (permalink / raw)
To: Kristian Høgsberg
Cc: Linus Torvalds, Git Mailing List, drafnel, Junio C Hamano,
Alex Riesen
In-Reply-To: <1200427202.5821.7.camel@gaara.boston.redhat.com>
Kristian Høgsberg wrote:
> There's four close(fd) calls in prepare_index() and they're all
> incorrect. The open fd's are cleaned up in rollback_index_files() and
> shouldn't be closed manually. The patch below gets rid of the extra
> close() calls and should fix the problem.
It does. Thanks.
-brandon
^ permalink raw reply
* Re: git-commit fatal: Out of memory? mmap failed: Bad file descriptor
From: Linus Torvalds @ 2008-01-15 20:20 UTC (permalink / raw)
To: Brandon Casey
Cc: Git Mailing List, drafnel, Junio C Hamano, Alex Riesen,
Kristian H?gsberg
In-Reply-To: <alpine.LFD.1.00.0801151207150.2806@woody.linux-foundation.org>
On Tue, 15 Jan 2008, Linus Torvalds wrote:
>
> Your patch seems "ObviouslyCorrect(tm)".
And Kristian's more extensive patch that finds a few more cases looks
better yet. Does that fix it for you?
Linus
^ permalink raw reply
* Re: [FEATURE REQUEST] git-svn format-patch
From: Jan Hudec @ 2008-01-15 20:15 UTC (permalink / raw)
To: Chris Ortman; +Cc: Johannes Schindelin, git
In-Reply-To: <c0f2d4110801151104j4c34dekc7d06dcfc89bfbe6@mail.gmail.com>
On Tue, Jan 15, 2008 at 13:04:23 -0600, Chris Ortman wrote:
> Myself and many others have excellent luck with the cygwin version.
> But the reasoning behind wanting this isn't so much for the developer
> that is creating the patch as it is for the person receiving it. Most
> of the projects I work on use tortoise to apply the patches and don't
> typically have patch.exe
Note, that tortoise might actually use the version numbers, so bonus points
for actually finding them (where applicable -- if the patch is not based on
subversion revision, you can't get them).
> If something like this was to be accepted and become part of standard
> git is there a requirement that it be written in perl or is some other
> scripting language fine?
Git currently uses C, shell, perl and tcl/tk. There would probably be some
resistance to adding more dependencies, but that would not apply to the
contrib directory (so useful things written in something else are likely to
end up there).
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
^ permalink raw reply
* Re: [FEATURE REQUEST] git-svn format-patch
From: Jean-Luc Herren @ 2008-01-15 20:14 UTC (permalink / raw)
To: git
In-Reply-To: <c0f2d4110801150559x155ffabaj6bea52715522a070@mail.gmail.com>
Chris Ortman wrote:
> Something that would really benefit the folks who use git to manage a
> subversion repository (such as myself) would be a special format-patch
> command for git-svn that creates a tortoise svn compatible diff file.
Isn't it that TortoiseSVN is simply being too strict about the
diff format it accepts? Since even GNU patch reads and applies
them fine (I didn't test it thoroughly though), I would assume git
diffs follow some sort of standard (couldn't find it though) for
the unified diff format, or at least was designed to not break
patch. So in the long term, I think this is rather or at least
also something to be addressed in TortoiseSVN.
jlh
^ 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