* Re: What's cooking in git.git (Mar 2009, #01; Tue, 03)
From: Jeff King @ 2009-03-03 9:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vprgzdlom.fsf@gitster.siamese.dyndns.org>
On Tue, Mar 03, 2009 at 01:01:45AM -0800, Junio C Hamano wrote:
> As an experiment, 'next' and 'pu' stayed open during this release freeze;
> new topics have been accepted. I have to say that the experiment was a
> moderate success, and many topics in 'next' seem to be of fairly high
> quality already, which would mean that we will have a shorter cycle before
> 1.6.3.
I was going to stay quiet on this issue until after 1.6.3 released, but
now you have opened the topic. :)
I think seeing the quality of topics in 'next' is only half of
"success". You have to also consider how much attention was given to the
about-to-be-released version (and its impact on quality). And I think we
won't know about that until we see how quickly we need 1.6.3.1. :)
Personally, I know that I have spent much less time focusing on
'master'. Like everyone else, I have limited git bandwidth, and topics
in 'next' are simply more interesting. I think it's easier to put them
aside for a few weeks if everybody agrees to do so (rather than having
interesting discussion proceeding without you if you choose to focus on
'master').
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Mar 2009, #01; Tue, 03)
From: Jakub Narebski @ 2009-03-03 9:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vprgzdlom.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> ----------------------------------------------------------------
> [Stalled and may need help and prodding to go forward]
>
> * gb/gitweb-base (Sun Feb 15 10:18:36 2009 +0100) 1 commit
> - gitweb: fix wrong base URL when non-root DirectoryIndex
Errrr... isn't this already in 'master' as v1.6.2-rc1-3-g81d3fe9 ?
> * jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
> + blame: show "previous" information in --porcelain/--incremental
> format
> + git-blame: refactor code to emit "porcelain format" output
>
> This gives Porcelains (like gitweb) the information on the commit _before_
> the one that the final blame is laid on, which should save them one
> rev-parse to dig further. The line number in the "previous" information
> may need refining, and sanity checking code for reference counting may
> need to be resurrected before this can move forward.
>
> I thought recent tig discussion may blow new life into it, but is this
> unneeded? If so I'd rather revert it (or discard after 1.6.2).
This would be nice to have for gitweb.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Subject: [PATCH] Push to create
From: Theodore Tso @ 2009-03-03 9:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Shawn O. Pearce, git
In-Reply-To: <7v1vtff1op.fsf@gitster.siamese.dyndns.org>
On Tue, Mar 03, 2009 at 12:30:46AM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > But I think that coincides with what I was trying to say in my original
> > response to the series, which is "this issue is complex, and we need to
> > hear from the people who would really want this exactly what it is they
> > want".
>
> And we haven't heard from them at all, unless you and/or Shawn are
> interested. After all we may not have to worry about this at all ;-)
Junio, I assume you saw Scott James Remnant blog posts, "Git Sucks"?
http://www.netsplit.com/2009/02/17/git-sucks/
http://www.netsplit.com/2009/02/17/git-sucks-2/
http://www.netsplit.com/2009/02/17/git-sucks-3/
http://www.netsplit.com/2009/02/23/revision-control-systems-suck/
My commentary on his complaint is found here:
http://thunk.org/tytso/blog/2009/02/23/reflections-on-a-complaint-from-a-frustrated-git-user/
Some (but not all) of the comments on my blog are also worth reading.
- Ted
^ permalink raw reply
* Re: [PATCH] rebase -i: avoid 'git reset' when possible
From: Johannes Schindelin @ 2009-03-03 9:24 UTC (permalink / raw)
To: Junio C Hamano
Cc: Sverre Rabbelier, Stephen Haberman, Shawn O. Pearce, Thomas Rast,
Git Mailing List, Stephan Beyer, Christian Couder,
Daniel Barkalow
In-Reply-To: <7v1vtfl8xi.fsf@gitster.siamese.dyndns.org>
Hi,
On Mon, 2 Mar 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Or even
> >
> > current=$ONTO
> > fd=3
> > while read command sha1 rest
> > do
> > case "$fd,$command,$current" in
> > 3,pick,"$sha1"*|t,p,"$sha1"*)
> > current=$sha1
> > ;;
> > *)
> > fd=1
> > ;;
> > esac
> > echo "$command $sha1 $rest" >&$fd
> > done < "$TODO" > "$TODO.new" 3>> "$DONE" &&
> > mv "$TODO.new" "$TODO"
> >
> > Hmm?
>
> Certainly.
>
> Even though "3 means we haven't found a non-pick yet" feels slightly
> hacky, the logic is contained in this small loop and I do not see it as a
> problem.
I'll add a one line comment.
> As long as you are sure $ONTO and all sha1 can be compared without
> running them through rev-parse, avoiding rev-parse per iteration is a
> very attractive optimization.
Yes, that is the beauty of abbreviated commit names: they are guaranteed
to be unique, unless other objects were added since, which is not the case
at this point.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC PATCH] Windows: Assume all file names to be UTF-8 encoded.
From: Dmitry Potapov @ 2009-03-03 9:43 UTC (permalink / raw)
To: Peter Krefting; +Cc: git
In-Reply-To: <alpine.DEB.2.00.0903020941120.17877@perkele.intern.softwolves.pp.se>
On Mon, Mar 02, 2009 at 09:47:22AM +0100, Peter Krefting wrote:
> When opening a file through open() or fopen(), the path passed is
> UTF-8 encoded. To handle this on Windows, we need to convert the
> path string to UTF-16 and use the Unicode-based interface.
IMHO, you grossly underestimate what is needed to enable UTF-8 encoding
in Windows. AFAIK, Microsoft C runtime library does not support UTF-8,
so you have to wrap all C functions taking 'char*' as an input parameter.
For example, think about what is going to happen if Git tries to print
a simple error message:
fprintf (stderr, "unable to open %s", path);
> Since there is no real file system abstraction beyond using stdio_
> (AFAIK), I need to hack it by replacing fopen (and open). Probably_
> opendir/readdir as well (might be trickier), and possibly even hack_
> around main() to parse the wchar_t command-line instead of the char copy.
And the command-line is not the only source of file names. Some Git
commands read list of files from stdin usually though the pipe. In
what encoding are they going to be?
Dmitry
^ permalink raw reply
* Re: [RFC PATCH] Windows: Assume all file names to be UTF-8 encoded.
From: Dmitry Potapov @ 2009-03-03 9:47 UTC (permalink / raw)
To: Peter Krefting; +Cc: Thomas Rast, git
In-Reply-To: <alpine.DEB.2.00.0903022135360.20047@perkele.intern.softwolves.pp.se>
On Mon, Mar 02, 2009 at 09:41:57PM +0100, Peter Krefting wrote:
>
> In most cases, I would most definitely agree with you on calling it that,_
> but when it comes to Unicode support, Windows is one of the least broken__
> OSes (with Symbian being my favourite).
The C Standard requires that the type wchar_t is capable of representing
any character in the current locale. If Windows uses UTF-16 as internal
encoding (so, it can work with symbols outside of the BMP), it means you
cannot have 16-bit wchar_t and be compliant with the C standard...
Dmitry
^ permalink raw reply
* [PATCH v2] rebase -i: avoid 'git reset' when possible
From: Johannes Schindelin @ 2009-03-03 9:55 UTC (permalink / raw)
To: Junio C Hamano
Cc: Sverre Rabbelier, Stephen Haberman, Shawn O. Pearce, Thomas Rast,
Git Mailing List, Stephan Beyer, Christian Couder,
Daniel Barkalow
In-Reply-To: <alpine.DEB.1.00.0903031008580.6399@intel-tinevez-2-302>
When picking commits whose parents have not changed, we do not need to
rewrite the commit. We do not need to reset the working directory to
the parent's state, either.
Requested by Sverre Rabbelier.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Actually, I did not think things through. Of _course_ we need
that rev-parse, to determine the parent of the to-be-picked
commit.
Changes since v1: use only one loop instead of counting the number
of skipped commits first, and then actually skipping them.
git-rebase--interactive.sh | 26 ++++++++++++++++++++++++++
t/t3404-rebase-interactive.sh | 11 +++++++++++
2 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 3dc659d..72f7fc7 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -442,6 +442,30 @@ do_rest () {
done
}
+# skip picking commits whose parents are unchanged
+skip_unnecessary_picks () {
+ fd=3
+ while read command sha1 rest
+ do
+ # fd=3 means we skip the command
+ case "$fd,$command,$(git rev-parse --verify --quiet $sha1^)" in
+ 3,pick,"$ONTO"*|t,p,"$ONTO"*)
+ # pick a commit whose parent is current $ONTO -> skip
+ ONTO=$sha1
+ ;;
+ 3,#*|3,,*)
+ # copy comments
+ ;;
+ *)
+ fd=1
+ ;;
+ esac
+ echo "$command${sha1:+ }$sha1${rest:+ }$rest" >&$fd
+ done < "$TODO" > "$TODO.new" 3>> "$DONE" &&
+ mv -f "$TODO".new "$TODO" ||
+ die "Could not skip unnecessary pick commands"
+}
+
# check if no other options are set
is_standalone () {
test $# -eq 2 -a "$2" = '--' &&
@@ -746,6 +770,8 @@ EOF
has_action "$TODO" ||
die_abort "Nothing to do"
+ test -d "$REWRITTEN" || skip_unnecessary_picks
+
git update-ref ORIG_HEAD $HEAD
output git checkout $ONTO && do_rest
;;
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index 603b003..c32ff66 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -459,4 +459,15 @@ test_expect_success 'submodule rebase -i' '
FAKE_LINES="1 squash 2 3" git rebase -i A
'
+test_expect_success 'avoid unnecessary reset' '
+ git checkout master &&
+ test-chmtime =123456789 file3 &&
+ git update-index --refresh &&
+ HEAD=$(git rev-parse HEAD) &&
+ git rebase -i HEAD~4 &&
+ test $HEAD = $(git rev-parse HEAD) &&
+ MTIME=$(test-chmtime -v +0 file3 | sed 's/[^0-9].*$//') &&
+ test 123456789 = $MTIME
+'
+
test_done
--
1.6.2.rc1.456.g3dbe7
^ permalink raw reply related
* Re: fatal: git write-tree failed to write a tree
From: Johannes Schindelin @ 2009-03-03 10:05 UTC (permalink / raw)
To: Caleb Cushing; +Cc: git
In-Reply-To: <81bfc67a0903022147m42e8fe38gb93773084614d30@mail.gmail.com>
Hi,
On Tue, 3 Mar 2009, Caleb Cushing wrote:
> On Sun, Mar 1, 2009 at 4:10 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > A tree cannot contain unmerged files.
>
>
> so... still looking for a solution since it seems I can no longer do a
> merge from this remote. There has to be a way to get the tree back
> into a proper state...
You have a tree with unmerged entries. Why don't you look into the issue
and solve it? A simple "git status" should show you what are the unmerged
entries. A simple look at those files should show you conflict markers.
Resolve the issue, commit, continue.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v3] send-email: add --confirm option and configuration setting
From: Nanako Shiraishi @ 2009-03-03 10:11 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, Paul Gortmaker, Junio C Hamano
In-Reply-To: <1236055938-65407-1-git-send-email-jaysoffian@gmail.com>
Quoting Jay Soffian <jaysoffian@gmail.com>:
> Unfortunately, it is impossible to introduce this patch such that it
> helps new users without potentially annoying some existing users. We
> attempt to mitigate the latter by:
>
> * Allowing the user to set 'git config sendemail.confirm never'
> * Allowing the user to say 'all' after the first prompt to not be
> prompted on remaining emails during the same invocation.
> * Telling the user about the 'sendemail.confirm' setting if it is
> unconfigured whenever we prompt due to Cc before sending.
> * Only prompting if no --suppress related options have been passed, as
> using such an option is likely to indicate an experienced send-email
> user.
>
> There is a slight fib in message informing the user of the
> sendemail.confirm setting and this is intentional. Setting 'auto'
> differs from leaving sendemail.confirm unset in two ways: 1) 'auto'
> obviously squelches the informational message; 2) 'auto' prompts when
> the Cc list has been expanded even in the presence of a --suppress
> related option, where leaving sendemail.confirm unset does not. This is
> intentional to keep the message simple, and to avoid adding another
> sendemail.confirm value ('auto-except-suppress'?).
For what it's worth, I think this much more carefully addresses the issues to migrate existing users by giving adequate help where it matters than the previous patches.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH] clone: run post-checkout hook when checking out
From: Nanako Shiraishi @ 2009-03-03 10:07 UTC (permalink / raw)
To: Jay Soffian; +Cc: Jeff King, layer, git, Junio C Hamano
In-Reply-To: <76718490903022255sab126c7qeab2fc60321a928e@mail.gmail.com>
Quoting Jay Soffian <jaysoffian@gmail.com>:
> On Tue, Mar 3, 2009 at 1:45 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> I do not mind queueing this to 'pu' and let people fight it out. I hate
>> the local side hooks that have no reason to be there, and consider that
>> the existence of the "checkout hook" to be a bug to begin with
>
> I just want to clarify: do you mean to say that none of the local side
> hooks have any reason to be there, or that some of the local hooks do
> not belong, and checkout is one of those?
There are five valid reasons you might want a hook to a git operation.
http://thread.gmane.org/gmane.comp.version-control.git/70781/focus=71069
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: First round of UGFWIINI results
From: Jakub Narebski @ 2009-03-03 10:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0902171745320.6185@intel-tinevez-2-302>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Dear fans of Git,
>
> a while ago I announced the UGFWIINI contest, a glorious battle of ideas
> how to
>
> Use Git For What It Is Not Indended
>
> As most of you probably did not find my blog yet, this may come as a
> surprise to you, but it will not be the only surprise in this email.
Errr... URL (of a blog), please?
Another candidate for UGFWIINI contest: Gitorial. Here is explanation
...this presentation was captured in the Git revision control
system. Every commit has a commit message that explains the 'next
slide' of the presentation. People can then view diffs between
commits to quickly see what changed.
Well, it uses GitHub, not only Git, but...
http://github.com/blog/367-clojure-gitorial
http://larrytheliquid.com/2009/03/02/presenting-clojure-with-a-gitorial
........................................................................
And similar thing: Homoiconic. Here is explanation
Homoiconic is an experiment in publishing code and words about code
on a small scale.
When I write, I will add files to the homoiconic git repository,
organized by date. Code will be included in the posts and also in
the folder with the posts that discuss them, so it's easy to
download what you like. You can even download the entire thing as an
archive if you want.
http://github.com/raganwald/homoiconic
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Subject: [PATCH] Push to create
From: Johannes Schindelin @ 2009-03-03 10:39 UTC (permalink / raw)
To: Theodore Tso; +Cc: Junio C Hamano, Jeff King, Shawn O. Pearce, git
In-Reply-To: <20090303092301.GE32284@mit.edu>
Hi,
On Tue, 3 Mar 2009, Theodore Tso wrote:
> On Tue, Mar 03, 2009 at 12:30:46AM -0800, Junio C Hamano wrote:
> > Jeff King <peff@peff.net> writes:
> >
> > > But I think that coincides with what I was trying to say in my
> > > original response to the series, which is "this issue is complex,
> > > and we need to hear from the people who would really want this
> > > exactly what it is they want".
> >
> > And we haven't heard from them at all, unless you and/or Shawn are
> > interested. After all we may not have to worry about this at all ;-)
>
> Junio, I assume you saw Scott James Remnant blog posts, "Git Sucks"?
>
> http://www.netsplit.com/2009/02/17/git-sucks/
> http://www.netsplit.com/2009/02/17/git-sucks-2/
> http://www.netsplit.com/2009/02/17/git-sucks-3/
> http://www.netsplit.com/2009/02/23/revision-control-systems-suck/
I have to admit that I only skimmed the first two: happily, this guy just
wanted to vent, and chose the correct forum. His personal blog.
Because he would have had to do something completely different if he
wanted to change things. He would have had to:
- write in the public (i.e. this mailing list),
- guard his language much more,
- actually come up with something useful, constructive instead of
repeating several times that Git is hard to use,
- defend that the most important purpose of a revision control system is
the initial publication of a branch, as opposed to controlling
revisions.
It reminds me very much of the question: "Does a universe exist when there
is nobody in it to observe it?"
Only in this case, I would rephrase it to: "Is a usability wart really
serious when the guy does not even bother to report it where it can be
fixed?"
Needless to say, I consider the answer to the latter to be "No. Really,
no."
I mean, it is easy, really, really easy to say that something sucks. It
is so easy that nobody should even pay attention. Certainly so easy that
I should not even have bothered writing this mail.
It is much harder work to come up with solutions, and that is what I am
interested in. So I'll try very hard to ignore everything else.
Ciao,
Dscho
^ permalink raw reply
* Re: What's cooking in git.git (Mar 2009, #01; Tue, 03)
From: Johannes Schindelin @ 2009-03-03 11:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vprgzdlom.fsf@gitster.siamese.dyndns.org>
Hi,
On Tue, 3 Mar 2009, Junio C Hamano wrote:
> * js/clone-depth-local (Fri Feb 27 00:04:06 2009 -0800) 3 commits
> . parse_options(): do not "increment" boolean
> . clone: ignore --depth when cloning locally (implicitly --local)
> . clone: do not ignore --no-local option
>
> Jeff had a good suggestion for this series but it was tripped by
> a misfeature in parse_options().
If the issue is that you cannot discern between implicit --no-local and
--no-local, maybe the solution is to start with option_local = 1.
> * ns/stash-keep (Thu Feb 12 06:25:14 2009 +0900) 1 commit
> - stash: --keep option just saves
>
> Do we want to keep this one?
AFAIAC no.
I'd like a shorter way to say "git stash save --keep-index". But that's
OT.
Ciao,
Dscho
^ permalink raw reply
* [RFC] Add an option for git-archive to output commit ID in alternative ways
From: roylee17 @ 2009-03-03 11:15 UTC (permalink / raw)
To: git
Hi,
Consider the following use case:
Regularly building projects which are untar'ed on-the-fly with git-archive
without intermediate tar balls.
How can I track back which commit IDs were those source code git-archive
from?
I'd like to to add an option for git-archive to output the commit ID in
alternative ways in addition
to only store it inside the tar ball. Any comment?
Regards,
Roy
--
View this message in context: http://n2.nabble.com/-RFC--Add-an-option-for-git-archive-to-output-commit-ID-in-alternative-ways-tp2414580p2414580.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: http: a non-curl_multi interface?
From: Tay Ray Chuan @ 2009-03-03 11:19 UTC (permalink / raw)
To: Daniel Stenberg; +Cc: git
In-Reply-To: <alpine.DEB.1.10.0903021412120.15587@yvahk2.pbagnpgbe.fr>
Hi,
On Mon, Mar 2, 2009 at 9:26 PM, Daniel Stenberg <daniel@haxx.se> wrote:
> What I don't quite grasp (and I must admit I have not followed the critique
> on this matter) is why using the multi interface of libcurl is a problem to
> anyone as all libcurl versions in modern times features it. And if you have
> a libcurl with it working badly, you have a too old libcurl anyway and
> should rather upgrade...
>
> ...
>
> I don't see how that is true. In fact, properly used I would claim that an
> application using the multi interface would in general use less connections
> and do more connection re-use than otherwise. But of course it depends on a
> lot of factors.
Hmm, there aren't any very obvious benefits are there?
In that case, I guess, an re-organization of the http api/curl usage
would be more useful to git.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH v2] rebase -i: avoid 'git reset' when possible
From: Johannes Sixt @ 2009-03-03 11:19 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Sverre Rabbelier, Stephen Haberman,
Shawn O. Pearce, Thomas Rast, Git Mailing List, Stephan Beyer,
Christian Couder, Daniel Barkalow
In-Reply-To: <alpine.DEB.1.00.0903031024420.6399@intel-tinevez-2-302>
Johannes Schindelin schrieb:
> +# skip picking commits whose parents are unchanged
> +skip_unnecessary_picks () {
> + fd=3
> + while read command sha1 rest
> + do
> + # fd=3 means we skip the command
> + case "$fd,$command,$(git rev-parse --verify --quiet $sha1^)" in
> + 3,pick,"$ONTO"*|t,p,"$ONTO"*)
s/t,/3,/
> + # pick a commit whose parent is current $ONTO -> skip
> + ONTO=$sha1
> + ;;
> + 3,#*|3,,*)
> + # copy comments
> + ;;
> + *)
> + fd=1
> + ;;
> + esac
> + echo "$command${sha1:+ }$sha1${rest:+ }$rest" >&$fd
> + done < "$TODO" > "$TODO.new" 3>> "$DONE" &&
> + mv -f "$TODO".new "$TODO" ||
> + die "Could not skip unnecessary pick commands"
> +}
-- Hannes
^ permalink raw reply
* Re: First round of UGFWIINI results
From: Johannes Schindelin @ 2009-03-03 11:20 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3myc2ucfb.fsf@localhost.localdomain>
Hi,
On Tue, 3 Mar 2009, Jakub Narebski wrote:
> Another candidate for UGFWIINI contest: Gitorial. Here is explanation
>
> ...this presentation was captured in the Git revision control
> system. Every commit has a commit message that explains the 'next
> slide' of the presentation. People can then view diffs between
> commits to quickly see what changed.
>
> Well, it uses GitHub, not only Git, but...
>
> http://github.com/blog/367-clojure-gitorial
> http://larrytheliquid.com/2009/03/02/presenting-clojure-with-a-gitorial
>
> ........................................................................
>
> And similar thing: Homoiconic. Here is explanation
>
> Homoiconic is an experiment in publishing code and words about code
> on a small scale.
>
> When I write, I will add files to the homoiconic git repository,
> organized by date. Code will be included in the posts and also in
> the folder with the posts that discuss them, so it's easy to
> download what you like. You can even download the entire thing as an
> archive if you want.
>
> http://github.com/raganwald/homoiconic
Definitely. Both are registered for the next round.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v2] rebase -i: avoid 'git reset' when possible
From: Johannes Schindelin @ 2009-03-03 11:21 UTC (permalink / raw)
To: Johannes Sixt
Cc: Junio C Hamano, Sverre Rabbelier, Stephen Haberman,
Shawn O. Pearce, Thomas Rast, Git Mailing List, Stephan Beyer,
Christian Couder, Daniel Barkalow
In-Reply-To: <49AD1250.4080708@viscovery.net>
Hi,
On Tue, 3 Mar 2009, Johannes Sixt wrote:
> Johannes Schindelin schrieb:
> > +# skip picking commits whose parents are unchanged
> > +skip_unnecessary_picks () {
> > + fd=3
> > + while read command sha1 rest
> > + do
> > + # fd=3 means we skip the command
> > + case "$fd,$command,$(git rev-parse --verify --quiet $sha1^)" in
> > + 3,pick,"$ONTO"*|t,p,"$ONTO"*)
>
> s/t,/3,/
Bah! Of course, I had to insert a typo there!
Thanks!
Dscho
^ permalink raw reply
* [PATCH] git-clone.txt: document that pushing from a shallow clone may work
From: Adeodato Simó @ 2009-03-03 11:33 UTC (permalink / raw)
To: git, gitster; +Cc: Mikael Magnusson, Joey Hess, Adeodato Simó
In-Reply-To: <237967ef0902160200r2320687ai71e62047c3ead9ad@mail.gmail.com>
The documentation used to say that pushing from a shallow clone is not
supported; this is true, though it may work in some simple cases. If a
user notices this fact, such a mismatch between documentation and reality
may leave them assuming the documentation is wrong and that pushing from
a shallow clone is supported.
This commit updates the documentation to say that pushing from a shallow
clone may work in some cases, but that it's not guaranteed to always do.
Signed-off-by: Adeodato Simó <dato@net.com.org.es>
---
Hello,
this is about http://thread.gmane.org/gmane.comp.version-control.git/110100,
which got a single reply from Mikael Magnusson stating:
> AFAIK, it will work in simple cases, but isn't guaranteed to work.
If that's the case, I think it should be documented, for the reasons
explained in the commit message.
Thanks!
Documentation/git-clone.txt | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 95f08b9..1b4f864 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -133,8 +133,10 @@ then the cloned repository will become corrupt.
--depth <depth>::
Create a 'shallow' clone with a history truncated to the
specified number of revisions. A shallow repository has a
- number of limitations (you cannot clone or fetch from
- it, nor push from nor into it), but is adequate if you
+ number of limitations: you cannot clone or fetch from it,
+ nor push into it; pushing from it into a regular repository
+ may work correctly in some cases, but it is not guaranteed to
+ always work. However, a shallow repository is adequate if you
are only interested in the recent history of a large project
with a long history, and would want to send in fixes
as patches.
--
1.6.2.rc2.271.ge939
^ permalink raw reply related
* [TopGit] Multiple concurrent sets of patches
From: Jonas Smedegaard @ 2009-03-03 11:37 UTC (permalink / raw)
To: git
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I have run into a challenge that I suspect is a limitation of current
TopGit. I am hoping you could help enlighten me, as I otherwise feel
that TopGit is not generally usable for my Debian packaging needs:
How to manage patches against multiple source branches using TopGit?
Let's take netatalk as an example. Upstream only quite infrequently
release new upstream tarball releases, so I cherry-pick patches from
upstream VCS. Recently a security-related bug was discovered which
needed fixing not only in the current packaging development (git master
branch) but also needed branching off earlier releases of the package
(those included in the "stable" and "oldstable" Debian distro releases)
and applying same fix for them.
The actual patch needed for the various branches was obviously not
identical, as upstream sources were different and my cherry-picked set
of patches had evolved.
It seems to me that TopGit is incapable of handling this. That it can
only handle patchset against a single branch, and if the need arise for
restructuring an additional patchset for e.g. a stable or oldstable
branch, then quilt needs to be used manually anyway.
- Jonas
Debian developer
- --
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkmtFoUACgkQn7DbMsAkQLgvrACdHfy5K0igPa6Yj/LYyhh3Llyn
jvcAnRfla1QyuUrx8+L4IL9XYY2CB+Su
=B1Kc
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [RFC PATCH] Windows: Assume all file names to be UTF-8 encoded.
From: Peter Krefting @ 2009-03-03 11:48 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Thomas Rast, git
In-Reply-To: <37fcd2780903030147q7062ee47w7ce524c28a6aa347@mail.gmail.com>
Dmitry Potapov:
> The C Standard requires that the type wchar_t is capable of representing
> any character in the current locale. If Windows uses UTF-16 as internal
> encoding (so, it can work with symbols outside of the BMP), it means you
> cannot have 16-bit wchar_t and be compliant with the C standard...
No, that's not quite correct. wchar_t is defined to be "an integer type whose
range of values can represent distinct codes for all members of
the largest extended character set specified among the supported locales".
Since Windows defines all local character sets as Unicode-based, having
wchar_t defined as Unicode means that it can represent everything.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [PATCH v3] send-email: add --confirm option and configuration setting
From: Bert Wesarg @ 2009-03-03 11:54 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, Nanako Shiraishi, Junio C Hamano, Paul Gortmaker
In-Reply-To: <1236055938-65407-1-git-send-email-jaysoffian@gmail.com>
On Tue, Mar 3, 2009 at 05:52, Jay Soffian <jaysoffian@gmail.com> wrote:
> diff --git a/git-send-email.perl b/git-send-email.perl
> index adf7ecb..57127aa 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -837,6 +837,37 @@ X-Mailer: git-send-email $gitversion
> unshift (@sendmail_parameters,
> '-f', $raw_from) if(defined $envelope_sender);
>
> + if ($needs_confirm && !$dry_run) {
So, the output is now differnt with and without --dry-run?
Bert
^ permalink raw reply
* Re: [RFC PATCH] Windows: Assume all file names to be UTF-8 encoded.
From: Peter Krefting @ 2009-03-03 11:54 UTC (permalink / raw)
To: Lars Noschinski; +Cc: Thomas Rast, git
In-Reply-To: <20090303075655.GB9875@lars.home.noschinski.de>
Lars Noschinski:
> Using no encoding for filenames was the obvious (and I would argue)
> correct choice. Unix filenames are specified to be a sequence of bytes,
> excluding '/' and '\0'.
I know the Unix way of thinking lends itself to such a design. This is one
of the few cases where I personally think Unix has got it wrong, and Windows
(NT) has got it right. But then again, Unix' design pre-dates the locale
issue by quite some time, so it is not difficult to see where it comes from.
> Changing the filename (on checkout), so that the user sees an Ü regardless
> of his or her locale (instead of an \0xDC, which only resolves to an Ü on
> latin-1) would be an absolutely broken concept here.
Why would it? It is my view as a user on my files that define how file names
are looked upon. If I have three machines, one Linux box using a iso8859-1
locale, an OS X box (where, I would believe, file APIs use UTF-8, someone
please correct me if I'm wrong), and a Windows box (which uses UTF-16 on the
file system layer, but does provide compatibility functions that use char
pointers), and create a file on each of these called "Ü.txt" (which would be
the sequence "DC 2E 74 78 74" on the Linux box, "C3 9C 2E 74 78 74" (or
probably something else since I believe OS X decomposes the string) on the
OS X box and "00DC 002E 0074 0078 0074" on the Windows box, I see these
three file names as equal.
If I would create a Git repo on each of the three machines and put the file
name in it, and then clone that on one of the other machines. *I* would
assume that the file names were converted to fit the host operating system.
> IMHO having encoding specific open functions is begging for problems.
Indeed. That's why I like Windows' wchar_t APIs, and dislike Unix' and
Linux' char APIs that, in some ways, depend on the user locale.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [PATCH] git-clone.txt: document that pushing from a shallow clone may work
From: Johannes Sixt @ 2009-03-03 11:57 UTC (permalink / raw)
To: Adeodato Simó; +Cc: git, gitster, Mikael Magnusson, Joey Hess
In-Reply-To: <1236080017-13987-1-git-send-email-dato@net.com.org.es>
Adeodato Simó schrieb:
> @@ -133,8 +133,10 @@ then the cloned repository will become corrupt.
> --depth <depth>::
> Create a 'shallow' clone with a history truncated to the
> specified number of revisions. A shallow repository has a
> - number of limitations (you cannot clone or fetch from
> - it, nor push from nor into it), but is adequate if you
> + number of limitations: you cannot clone or fetch from it,
> + nor push into it; pushing from it into a regular repository
> + may work correctly in some cases, but it is not guaranteed to
> + always work. However, a shallow repository is adequate if you
Consider a reader who wants to decide whether --depth should or can be
used in a git clone invocation. Is the new wording helpful? If you don't
describe those "some cases" in more detail, then we better keep the
current wording.
-- Hannes
^ permalink raw reply
* Re: [RFC PATCH] Windows: Assume all file names to be UTF-8 encoded.
From: Peter Krefting @ 2009-03-03 11:56 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: git
In-Reply-To: <37fcd2780903030143t7abe33d5sb7d8163c3c9bf505@mail.gmail.com>
Dmitry Potapov:
> IMHO, you grossly underestimate what is needed to enable UTF-8 encoding in
> Windows. AFAIK, Microsoft C runtime library does not support UTF-8, so you
> have to wrap all C functions taking 'char*' as an input parameter.
I have to wrap all file-related functions, at least.
> For example, think about what is going to happen if Git tries to print a
> simple error message: fprintf (stderr, "unable to open %s", path);
Yeah. That's a problem. That might be solvable by setting the thread locale
to something UTF-8 based and have the console window convert to the output
codepage (that is what it does when you use wprintf and friends).
> And the command-line is not the only source of file names. Some Git
> commands read list of files from stdin usually though the pipe. In what
> encoding are they going to be?
Indeed. Pipes are a problem.
--
\\// Peter - http://www.softwolves.pp.se/
^ 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