* Re: How to prefix existing svn remotes?
From: Michael J Gruber @ 2009-01-23 13:02 UTC (permalink / raw)
To: Sébastien Mazy; +Cc: git
In-Reply-To: <20090123124231.GA17616@locahost>
Sébastien Mazy venit, vidit, dixit 23.01.2009 13:42:
> Hi Michael,
>
> Thanks for your reply.
>
> On Fri, Jan 23, 2009 at 12:13:18PM +0100, Michael J Gruber wrote:
>> The following works for me:
>>
>> 0) fetch to make sure you're current (optional)
>> 1) edit .git/config and add the prefix (right hand side of the
>> refpsecs), or really rename in any way you want
>
> OK.
>
>> 2) rename the existing remote branches in the same way
>
> I'm not sure how I can do it. 'trunk' is the only remote-tracking svn
> branches under .git/refs/. Here is how it looks:
>
> ls -R .git/refs
> .git/refs: heads remotes tags
> .git/refs/heads: master
> .git/refs/remotes: trunk
>
> Still, a 'branch0' remote exist:
>
> git show-ref
> refs/heads/master
> refs/remotes/branch0
> refs/remotes/trunk
You can do (bash)
for b in trunk branch0
do
git update-ref refs/remotes/yournewprefix/$b refs/remotes/$b
git update-ref -d refs/remotes/$b
done
OTOH, any incarnation of "git -m" (with or without "-r", specifying
refs/remotes/trunk, remotes/trunk or trunk) failed.
Michael
^ permalink raw reply
* Re: bug: transform a binary file into a symlink in one commit => invalid binary patch
From: Michael J Gruber @ 2009-01-23 13:13 UTC (permalink / raw)
To: Pixel; +Cc: git
In-Reply-To: <lyhc3q9pl1.fsf@leia.mandriva.com>
Pixel venit, vidit, dixit 23.01.2009 13:25:
> hi,
>
> i hit a bug (git 1.6.1): when you transform a binary file into a
> symlink in one commit, the binary patch can't be used in "git apply".
> Is it a known issue?
>
>
> reproducer:
>
> ----------
> #!/bin/sh -e
>
> # the bug: if you transform a binary file into a symlink in one commit,
> # the binary patch can't be used in "git apply"
> #
> # nb: if you uncomment the "##" lines, the problem disappears
> # since the first patch will empty the binary file then the non-binary file
> # will be transformed into a symlink
>
> rm -rf t t2
> mkdir t
> dd if=/dev/urandom of=t/a count=10
> cp -r t t2
>
> cd t
> git init
> git add .
> git commit -m initial
>
> ##echo -n > a
> ##git commit -a -m foo
> ln -sf zzz a
> git commit -a -m foo2
> git format-patch :/initial
>
> cd ../t2
> git apply ../t/*.patch
>
> cd ..
> rm -rf t t2
> ----------
You're not even initialising a repo in t2. I assume you want to "cp -a t
t2" after the "initial" commit, don't you? Doing that I get
error: binary patch to 'a' creates incorrect result (expecting
e132db255c0e0e3e9309c3c58a0a9c9eb97dd942, got
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391)
error: a: patch does not apply
error: a: already exists in working directory
which is not that magnificient either. If that's the error you're after
your test script needs to be modified.
Michael
^ permalink raw reply
* Re: [PATCH] git-am: Add --ignore-date option
From: Adeodato Simó @ 2009-01-23 13:17 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Nanako Shiraishi, Junio C Hamano, git list, Christian MICHON
In-Reply-To: <alpine.DEB.1.00.0901231336080.3586@pacific.mpi-cbg.de>
* Johannes Schindelin [Fri, 23 Jan 2009 13:38:34 +0100]:
> FWIW I have that problem in one of my workflows, and I do this:
> grep -v "^Date:" < $MBOX | git am
> Of course, this assumes that none of my commit messages has the string
> "Date:" at the beginning of the line...
In case you're interested:
% formail -I 'Date' -s < $MBOX | git am
is robust against your assumption being wrong. (I realize ^Date: is not
very likely in commit messages, but I thought I'd mention nevertheless.)
Cheers,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
- Are you sure we're good?
- Always.
-- Rory and Lorelai
^ permalink raw reply
* Re: git-svn fails to fetch repository
From: Björn Steinbrink @ 2009-01-23 13:22 UTC (permalink / raw)
To: Petr Baudis; +Cc: Vladimir Pouzanov, git
In-Reply-To: <20090123085235.GA14721@machine.or.cz>
On 2009.01.23 09:52:35 +0100, Petr Baudis wrote:
> On Tue, Jan 13, 2009 at 08:46:55PM +0000, Vladimir Pouzanov wrote:
> > Björn Steinbrink <B.Steinbrink <at> gmx.de> writes:
> > > Is that Linux box using Gentoo? If so, try emerging subversion with -dso
> > > in your build flags.
> >
> > Yeah, that's gentoo. Will try rebuilding svn now.
>
> I have hit the same issue (segfault on Gentoo) and this fixed it for me.
> But do you have any details on why is the segfault caused and how to
> prevent it? USE=dso is the default on Gentoo. :-(
No idea, I just heard about that in #git. IIRC it was Mikachu who came
up with that solution. Unfortunately, he's not around at the moment, and
I don't recall his real name, so not on Cc. :-/
Björn
^ permalink raw reply
* Re: [PATCH] mergetool merge/skip/abort
From: Caleb Cushing @ 2009-01-23 15:16 UTC (permalink / raw)
To: Charles Bailey; +Cc: git
In-Reply-To: <20090122142258.GA2316@hashpling.org>
> You'll never (well, almost never) know that tabs aren't 4 spaces.
no but I think people should be able to view indents at whatever they
want and still have it work, which is why I normally use tabs
exclusively, and set it to 4 space display, but if people wanted to
view at 2, 6, 8 spaces or whatever they could and the indents should
still look correct.
it doesn't really matter to each project there own.
so does my patch satisfy now? what's it take to get it included in the
next version of git?
--
Caleb Cushing
http://xenoterracide.blogspot.com
^ permalink raw reply
* Re: Merging adjacent deleted lines?
From: Jay Soffian @ 2009-01-23 15:51 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Jonathan del Strother, Junio C Hamano, Git Mailing List
In-Reply-To: <200901231132.36543.robin.rosenberg.lists@dewire.com>
On Fri, Jan 23, 2009 at 5:32 AM, Robin Rosenberg
<robin.rosenberg.lists@dewire.com> wrote:
> Where's the ancestor? I'm used to having four panes for doing three-way
> merges, but your screenshot showed only three.
I installed xxdiff to compare w/opendiff, meld, and vimdiff and I see
what you mean with xxdiff.
opendiff/meld/vimdiff don't show the ancestor directly, but they are
still using it in order to show how one version differs from the
ancestor in the left pane, and how the other version differs in the
right pane.
>> Shrug.
>
> You have the option to ignore me....
Doh, I meant only "I don't understand." My apologies.
j.
^ permalink raw reply
* Re: Merging adjacent deleted lines?
From: Jay Soffian @ 2009-01-23 15:59 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Jonathan del Strother, Junio C Hamano, Git Mailing List
In-Reply-To: <76718490901230751uef27274sf7b44e6718f861ae@mail.gmail.com>
On Fri, Jan 23, 2009 at 10:51 AM, Jay Soffian <jaysoffian@gmail.com> wrote:
> opendiff/meld/vimdiff don't show the ancestor directly, but they are
> still using it in order to show how one version differs from the
> ancestor in the left pane, and how the other version differs in the
> right pane.
Hmm, okay. I see that meld/vimdiff are apparently not doing a 3-way
merge. So I guess after all this, I don't have an explanation about
opendiff. It claims to do a 3-way diff and mergetool is passing it the
ancestor as an argument. Sorry for the confusion.
j.
^ permalink raw reply
* Re: CR codes from git commands
From: Brent Goodrick @ 2009-01-23 16:12 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Daniel Barkalow, Brent Goodrick, Mike Ralphson, Junio C Hamano,
git
In-Reply-To: <alpine.DEB.1.00.0901221751320.3586@pacific.mpi-cbg.de>
Johannes Schindelin writes:
> Hi,
>
> On Thu, 22 Jan 2009, Daniel Barkalow wrote:
>
> > In any case, it's all done in progress.c, so it should be easy enough to
> > make changes to if you can come up with something better to do with
> > progress messages and some way to determine when it should be done.
>
> Maybe "git --no-progress <program>" would be a sensible user
> interface?
Thanks. I now see the \r reference inside the "display" file-static
function inside progress.c.
However, I propose to add two options, the first being, IMO, the
minimal one to implement, and the second being "nice-to-have":
- Bare minimum: Add a new --no-cr option (e.g., "git --no-cr
<program>") that would prevent any git code (inside progress.c or
elsewhere) from emitting a CR code from stdout or stderr. This has
the effect of allowing progress messages, but not asking too much
of terminals-that-are-not-really-terminals such as the GNU Emacs
shell mode.
- Nice-to-have: Add a "git --no-progress" message that would never
show progress at all (e.g., perhaps by not installing a signal
handler inside progress.c such that no messages would not be
emitted at all.
Both options are intended to be independent of each other.
And for both options, I would like there to be a config option to
allow the user to enable said behavior globally across all git
operations covered by that config file.
I might be willing to take a swipe at this myself and submit a patch,
provided I receive adequate noobie hand-holding (or hand-slapping) on
patch submission and test case development.
bg
^ permalink raw reply
* Re: [PATCH] Allow cloning an empty repository
From: Miklos Vajna @ 2009-01-23 16:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sverre Rabbelier, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901230419080.3586@pacific.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 424 bytes --]
On Fri, Jan 23, 2009 at 04:20:34AM +0100, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> But then, scripts have no business cloning repositories (fetching, yes.
> But cloning?)
I think portals like repo.or.cz may do it.
Isn't setting errno (or similar variable) in the HTTP code an option?
Then we could see why the transport failed and make a difference between
"network error" and "no refs found".
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: CR codes from git commands
From: Junio C Hamano @ 2009-01-23 16:59 UTC (permalink / raw)
To: Brent Goodrick; +Cc: Johannes Schindelin, Daniel Barkalow, Mike Ralphson, git
In-Reply-To: <18809.60512.654436.59819@hungover.brentg.com>
Brent Goodrick <bgoodr@gmail.com> writes:
> - Bare minimum: Add a new --no-cr option (e.g., "git --no-cr
> ...
> - Nice-to-have: Add a "git --no-progress" message that would never
> ...
> Both options are intended to be independent of each other.
I do not think so. --no-progress should imply --no-cr ;-)
I do not think it makes much sense to pollute your non-terminal with 100
lines of 1%,2%,3%,...100% if it cannot sensibly do carriage-returns. It
may be another knob to tweak, but it's a kind of thing you implement
because you could, not because it makes sense. I would be mildly against
no-cr.
I suspect we may even be able to solve it without adding --no-progress.
Perhaps some commands do not have --quiet to squelch progress and teaching
them --quiet will solve the issue for you?
^ permalink raw reply
* Re: [PATCH 3/3] git commit: pathspec without -i/-o implies -i semantics during a merge
From: Junio C Hamano @ 2009-01-23 17:01 UTC (permalink / raw)
To: Pieter de Bie
Cc: Nanako Shiraishi, Johannes Sixt, Nathan Yergler, Michael J Gruber,
Asheesh Laroia, git
In-Reply-To: <53513726-CE1C-4487-B775-440C6DC93DD8@ai.rug.nl>
Pieter de Bie <pdebie@ai.rug.nl> writes:
> On 23 jan 2009, at 06:21, Junio C Hamano wrote:
>
>> This makes "git commit paths..." form default to "git commit -i paths"
>> semantics only during a merge, restoring the pre-v1.3.0 behaviour.
>> The
>> codepath to create a non-merge commit is not affected and still
>> defaults
>> to the "--only" semantics.
>
> Do you really want to do this? I think this is a pretty large change
> that can bite users if they don't know about this -- for example,
> because
> they forgot that they are in a merge (it happens..).
>
> FWIW, I'd much rather see a useful error message than this change. If
> this change does get in, I think it should be well-documented in the
> man pages as well as in the release notes.
As I said already in an earlier message in this thread, this is only a
weatherballoon series to help facilitate the discussion, and I am not
strongly in favor of this. In fact, if I were, I would have done that
long time ago around v1.3.0, because there was a discussion about doing
this and the concensus back then was that the command changing the default
behaviour between -i and -o was too confusing, even though it may be
dwimming better.
The onus is upon those who argued that "commit paths" should default to
the --include semantics during a merge resolution in this thread to
improve the documentation, if they want this to go forward.
^ permalink raw reply
* Re: How to prefix existing svn remotes?
From: Sébastien Mazy @ 2009-01-23 17:13 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <4979BFE7.8090402@drmicha.warpmail.net>
On Fri, Jan 23, 2009 at 02:02:31PM +0100, Michael J Gruber wrote:
> You can do (bash)
>
> for b in trunk branch0
> do
> git update-ref refs/remotes/yournewprefix/$b refs/remotes/$b
> git update-ref -d refs/remotes/$b
> done
That did the trick. Thank you so much!
By the way, my renamed remote tracking svn branches now show under
.git/refs/ as expected.
--
Sébastien Mazy
^ permalink raw reply
* Re: [PATCH] mergetool: respect autocrlf by using checkout-index
From: Junio C Hamano @ 2009-01-23 17:20 UTC (permalink / raw)
To: Charles Bailey; +Cc: git, Hannu Koivisto, Theodore Tso
In-Reply-To: <1232578668-2203-1-git-send-email-charles@hashpling.org>
Charles Bailey <charles@hashpling.org> writes:
> Previously, git mergetool used cat-file which does not perform git to
> worktree conversion. This changes mergetool to use git checkout-index
> instead which means that the temporary files used for mergetool use the
> correct line endings for the platform.
>
> Signed-off-by: Charles Bailey <charles@hashpling.org>
Sounds like the right thing to do and from a cursory review it looks Ok to
me.
But I do not use mergetool myself, so an Ack from Ted and a Thanks from
whoever reported the breakage would be encouraging ;-).
> +checkout_staged_file () {
> + tmpfile=$(expr "$(git checkout-index --temp --stage="$1" "$2")" : '\([^ ]*\) ')
> +
> + if test $? -eq 0 -a -n "$tmpfile" ; then
> + mv -- "$tmpfile" "$3"
The original redirects into the final destination but this moves. This
will lose the perm bits of the original and obey the perm bits
checkout-index gives you. It will also behave differently when the path
is a symlink. These two differences _may_ well be improvements and/or
bugfixes, but if that is the case please describe them as such.
^ permalink raw reply
* Re: lineups with GIT (or dealing with directory renames)
From: Jakub Narebski @ 2009-01-23 17:25 UTC (permalink / raw)
To: outre; +Cc: git
In-Reply-To: <1232610882661-2196604.post@n2.nabble.com>
outre <spoony.sob@hotmail.com> writes:
[...]
> I tried using "git mv" command and it somewhat solved the problem. After I
> cloned the devel line-up, I used "git rm iWeb.local iWeb.test".
> And now if I edit a file in iWeb.local and do a pull to iWeb.test this file
> gets properly updated while preserving the difference between
> the folder names. But if I add a new file to iWeb.local, and then do a pull
> I get iWeb.local folder added together with the
> new file to the testing line-up.
>
> I was wondering if it is intended behaviour for GIT. And if it is may be
> someone can point me to a better way to setup two line-ups using
> GIT.
I know nothing about line-ups, but the behaviour wrt. wholesame
directory renames is _known_ behavior of git. If one side renames
directory, and other side creates new files in old-name directory,
the old-name directory gets recreated during merging.
I wrote _known_ and not _intendend_ because this can be changed;
there were some patches on git mailing list (I don't know what
happened to them; I think the development stalled) that added
detecting wholesame rename of directories, based on heuristic
content and filename similarity based detection of renames for
individual files.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] mergetool merge/skip/abort
From: Junio C Hamano @ 2009-01-23 17:26 UTC (permalink / raw)
To: Caleb Cushing; +Cc: Charles Bailey, git
In-Reply-To: <81bfc67a0901230716i166bfc4chd9a5c0990b0cd3b6@mail.gmail.com>
Caleb Cushing <xenoterracide@gmail.com> writes:
> so does my patch satisfy now? what's it take to get it included in the
> next version of git?
I do not use mergetool myself so I generally do not pay attention to
patches on this tool, but I would want to pick up ones that people
involved in mergetool discussion can agree to be good patches.
There are a few mergetool updates in flight from various authors. How
does your submission compare with others' in both form/presentation and
clarity of logic (remember, I am not keeping track)?
^ permalink raw reply
* Re: how to force a commit date matching info from a mbox ?
From: Junio C Hamano @ 2009-01-23 17:27 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git list, Christian MICHON
In-Reply-To: <20090123185209.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Junio C Hamano <gitster@pobox.com>:
>
>>> --->8---
>>> Subject: [PATCH] git-am: Add --ignore-date option
>>
>> Good.
>>
>> Leaving "Subject: " in saves me typing, because I do not have to insert it
>> manually when editing the submitted patch in my MUA to chop off everything
>> before the scissors.
>
> I am sorry to ask you a stupid question, but do you mean you want to have
> "Subject: " there, or do you mean you want me to leave that word out?
Sorry for poor use of the language. I want to see "Subject: " on the
line after the scissors. That way, I can remove everything up to the
scissors, and the resulting message body will start with a line that
begins with "Subject: ", which overrides the subject of the e-mail.
^ permalink raw reply
* Re: How to prefix existing svn remotes?
From: Jakub Narebski @ 2009-01-23 17:51 UTC (permalink / raw)
To: git
In-Reply-To: <20090123171355.GA20413@locahost>
Sébastien Mazy wrote:
> By the way, my renamed remote tracking svn branches now show under
> .git/refs/ as expected.
They were inside file .git/packed-refs
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: lineups with GIT
From: Daniel Barkalow @ 2009-01-23 18:01 UTC (permalink / raw)
To: outre; +Cc: git
In-Reply-To: <1232610882661-2196604.post@n2.nabble.com>
On Wed, 21 Jan 2009, outre wrote:
> I am trying to set up two different line-ups for a project (development and
> testing).
>
> The development line-up is the master, and test line-up pulls data from it.
> The code is the same in both.
> But since the line-ups are served from two different domains one folder in
> the development line-up is called
> iWeb.local, and in the test line-up it is called iWeb.test. That is the only
> difference between the two.
>
> I tried using "git mv" command and it somewhat solved the problem. After I
> cloned the devel line-up, I used "git rm iWeb.local iWeb.test".
> And now if I edit a file in iWeb.local and do a pull to iWeb.test this file
> gets properly updated while preserving the difference between
> the folder names. But if I add a new file to iWeb.local, and then do a pull
> I get iWeb.local folder added together with the
> new file to the testing line-up.
>
> I was wondering if it is intended behaviour for GIT. And if it is may be
> someone can point me to a better way to setup two line-ups using
> GIT.
The best thing is probably to have both of them store everything in a
directory "iWeb", and have whatever process is used to make something
start serving things copy the directory into whatever location it needs.
It helps a lot with git if any two versions that are effectively the same
are exactly the same.
One handy trick is to have a script that reads an untracked file to
determine where and how to arrange stuff for installation. Then you can
have different values in the working directories for the two repositories,
and the same (tracked) script in each repository will do the appropriate
different thing for that repository, while leaving the tracked content for
development exactly the same in testing.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] gittutorial: remove misleading note
From: Miklos Vajna @ 2009-01-23 18:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In the tutorial Alice initializes the repository, and Bob clones it. So
Bob can just do a 'git pull', but Alice will need 'git pull <url>
<branch>'.
The note suggested that the branch parameter is not necessary, which is
no longer true these days.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
The problem was reported by DanC on IRC.
Documentation/gittutorial.txt | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt
index 458fafd..c5d5596 100644
--- a/Documentation/gittutorial.txt
+++ b/Documentation/gittutorial.txt
@@ -308,9 +308,7 @@ alice$ git pull /home/bob/myrepo master
This merges the changes from Bob's "master" branch into Alice's
current branch. If Alice has made her own changes in the meantime,
-then she may need to manually fix any conflicts. (Note that the
-"master" argument in the above command is actually unnecessary, as it
-is the default.)
+then she may need to manually fix any conflicts.
The "pull" command thus performs two operations: it fetches changes
from a remote branch, then merges them into the current branch.
--
1.6.1
^ permalink raw reply related
* Re: [PATCH] mergetool: respect autocrlf by using checkout-index
From: Charles Bailey @ 2009-01-23 18:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Hannu Koivisto, Theodore Tso
In-Reply-To: <7v1vuuvt11.fsf@gitster.siamese.dyndns.org>
On Fri, Jan 23, 2009 at 09:20:10AM -0800, Junio C Hamano wrote:
> Charles Bailey <charles@hashpling.org> writes:
>
> > Previously, git mergetool used cat-file which does not perform git to
> > worktree conversion. This changes mergetool to use git checkout-index
> > instead which means that the temporary files used for mergetool use the
> > correct line endings for the platform.
> >
> > Signed-off-by: Charles Bailey <charles@hashpling.org>
>
> Sounds like the right thing to do and from a cursory review it looks Ok to
> me.
>
> But I do not use mergetool myself, so an Ack from Ted and a Thanks from
> whoever reported the breakage would be encouraging ;-).
Yes, please!
I had wondered why I hadn't really noticed about this 'issue' before
as I've used git mergetool on windows with autocrlf set to true quite
a bit. I think that if your mergetool handles LF endings it doesn't
really matter as it's only the temporary files that are affected and
if the mergetool generates LF output files in response to LF input
files then this is resolved to the correct format at the time it is
added to the index in any case.
> > +checkout_staged_file () {
> > + tmpfile=$(expr "$(git checkout-index --temp --stage="$1" "$2")" : '\([^ ]*\) ')
> > +
> > + if test $? -eq 0 -a -n "$tmpfile" ; then
> > + mv -- "$tmpfile" "$3"
>
> The original redirects into the final destination but this moves. This
> will lose the perm bits of the original and obey the perm bits
> checkout-index gives you. It will also behave differently when the path
> is a symlink. These two differences _may_ well be improvements and/or
> bugfixes, but if that is the case please describe them as such.
I hadn't actually thought about the perms thing that much but now that
I do...
This code, and the code that it replaces, only affects the temporary
files that form the basis for the merge. The result/destination file
is as generated by the merge (or rebase).
The redirect version (as is) will not set permissions from the index -
effectively losing information, the new version should (I think - I'm
not an expert in checkout-index) get the 'correct' repository
permissions. I would say that this is, if anything, an improvement.
The ultimate effect really depends on the mergetool and whether the
source file permissions affect the permissions that it sets on the
target file. In the vast majority of cases I would think that it
doesn't have any effect.
Note that symlinks in the repository are not resolved by this code
path so they aren't affected.
--
Charles Bailey
http://ccgi.hashpling.plus.com/blog/
^ permalink raw reply
* Re: [RFC/PATCH v3 2/3] sha1_file: prepare for adding alternates on demand
From: Lars Hjemli @ 2009-01-23 18:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano, René Scharfe
In-Reply-To: <alpine.DEB.1.00.0901230041500.3586@pacific.mpi-cbg.de>
On Fri, Jan 23, 2009 at 00:43, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> On Thu, 22 Jan 2009, Lars Hjemli wrote:
>> + if (!quiet)
>> + error("object directory %s does not exist; "
>> + "check .git/objects/info/alternates.",
>> + ent->base);
>
> FWIW my concern is not at all addressed. A future user of add_alt_odb()
> (and possibly your users in rare cases, too) can trigger the error that
> suggests looking into the alternates. Leaving the human user puzzled.
Is it the phrasing of the error message that concerns you (when
invoked from add_alt_odb())?
If so, would something like this be ok/better?
>> + if (!quiet)
>> + error("Alternate object directory %s does not exist ",
>> + ent->base);
--
larsh
^ permalink raw reply
* Re: [RFC/PATCH v3 3/3] archive.c: add basic support for submodules
From: Lars Hjemli @ 2009-01-23 18:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano, René Scharfe
In-Reply-To: <alpine.DEB.1.00.0901230044300.3586@pacific.mpi-cbg.de>
On Fri, Jan 23, 2009 at 00:44, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> On Thu, 22 Jan 2009, Lars Hjemli wrote:
>
>> The new --submodules option is used to trigger inclusion of checked out
>> submodules in the archive.
>>
>> The implementation currently does not verify that the submodule has been
>> registered as 'interesting' in .git/config, neither does it resolve the
>> currently checked out submodule HEAD but instead uses the commit SHA1
>> recorded in the gitlink entry to identify the submodule root tree.
>
> Please understand that I skipped the rest of the patch.
That's too bad, I hoped on some feedback from you on the part of the
commit message which you didn't quote:
>> The plan is to fix these limitations by extending --submodules to allow
>> certain flags/options:
>> a|c|r include any|checked out|registered submodules
>> H resolve submodule HEAD to decide which tree to include
>> g:<name> only include submodules in group <name>
>>
>> The syntax would then become '--submodules[=[a|c|r][H][g:<name>]]' and
>> group membership could be specified in .git/config and/or .gitmodules.
>> The current behavior would then match '--submodules=c' (which might be a
>> sensible default when only --submodules is specified).
Wouldn't such an option address your concern about the
consistency/semantics of the --submodules operation?
--
larsh
^ permalink raw reply
* Re: RFC: git diff colorization idea
From: Jakub Narebski @ 2009-01-23 18:40 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git@vger.kernel.org List
In-Reply-To: <53497057-1ADE-4300-9F35-B218959606FE@wincent.com>
Wincent Colaiuta <win@wincent.com> writes:
> Lately I've been wishing that Git's diff output were colorized in a
> way that combines the standard line-by-line colorizing with the word-
> by-word colorizing you get with --color-words.
I like this idea, also because Emacs ediff / ediff3 / emerge uses it,
from what I understand under the name of 'refinement'.
>
> Pictures speak louder than words, so here are some to show what I mean:
>
> http://www.flickr.com/photos/wincent-colaiuta/sets/72157612877491482/
>
[...]
There was some discussion in this thread on how to do this, whether
with --refine / --color-chars we shoud ony highlight differences, or
whether for example use reverse (i.e. background green or background
red), or other red / other green, or perhaps bold, or perhaps
underline to highlight regions in line which differ
> - Meld: http://meld.sourceforge.net/meld_file1.png
Not extremly good example, as it uses equivalent of context diff
format (-,+,!) with added, removed and _changed_ lines, and not
unified diff format (only added / removed lines).
> Would people be interested in seeing this feature go in? [...]
+1 from me
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: CR codes from git commands
From: Johannes Schindelin @ 2009-01-23 18:41 UTC (permalink / raw)
To: Brent Goodrick; +Cc: Daniel Barkalow, Mike Ralphson, Junio C Hamano, git
In-Reply-To: <18809.60512.654436.59819@hungover.brentg.com>
Hi,
On Fri, 23 Jan 2009, Brent Goodrick wrote:
> - Bare minimum: Add a new --no-cr option
I do not see any value of this over "--progress | tr '\r' '\n'". (The
--progress option being the natural counterpart to --no-progress,
_forcing_ the display of the progress.)
And I disagree that --no-progress would be hard to implement. Just have a
look at 7d1864c(Introduce is_bare_repository() and core.bare configuration
variable).
Basically, you'll have to
- introduce a global variable to both environment.c and cache.h,
- set it to -1 by default,
- handle a "--progress" and "--no-progress" option in git.c, setting the
global variable git_show_progress to 1 or 0, respectively,
- teach start_progress_delay() to return NULL if git_show_progress == 0,
- modify all users of start_progress*() to respect git_show_progress == 1,
which probably means to look for "isatty" in builtin-pack-objects.c and
builtin-unpack-objects.c
- add documentation to Documentation/git.txt what --progress and
--no-progress do,
- add a simple test script to t/ (maybe t/t0005-progress.sh) that tests
that --progress works -- maybe you find a clever way to test
--no-progress, too, but that would be harder, as the progress is turned
off by default for the scripts anyway...)
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] gittutorial: remove misleading note
From: Junio C Hamano @ 2009-01-23 19:00 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <1232733749-6120-1-git-send-email-vmiklos@frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> In the tutorial Alice initializes the repository, and Bob clones it. So
> Bob can just do a 'git pull', but Alice will need 'git pull <url>
> <branch>'.
>
> The note suggested that the branch parameter is not necessary, which is
> no longer true these days.
So we have a usability regression here. Perhaps we need to fix that
instead?
^ 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