* Re: First round of UGFWIINI results
From: Johannes Schindelin @ 2009-03-03 17:49 UTC (permalink / raw)
To: Jeff King; +Cc: Reece Dunn, git
In-Reply-To: <20090303173417.GA1243@coredump.intra.peff.net>
Hi,
On Tue, 3 Mar 2009, Jeff King wrote:
> On Tue, Mar 03, 2009 at 06:27:27PM +0100, Johannes Schindelin wrote:
>
> > I am interested in reading Reece's short stories, though.
>
> I can only hope that they're git-themed (Linus fan-fiction?).
No, that is an intended purpose of Git. To worship Linus.
Thus, it would not qualify.
Ciao,
Dscho
^ permalink raw reply
* More on "fast foward"
From: John Dlugosz @ 2009-03-03 17:45 UTC (permalink / raw)
To: git
After I merged the release fixes back into the development branch, I was
surprised that push complained that it was not fast-forward. I thought
someone must have added something since I looked, but no, my repository
matches exactly. My new dev branch label is the immediate descendant of
the old one. My new node has another ancestor as well, but so what?
The same changes, not recorded as a merge, would work without complaint.
The glossary states, "A fast-forward is a special type of merge where
you have a revision and you are "merging" another branch's changes that
happen to be a descendant of what you have. In such these cases, you do
not make a new merge commit but instead just update to his revision.
This will happen frequently on a tracking branch of a remote
repository." Why did that not work this time?
I'm especially worried about this because it means that topic branches
merged back to the development core when ready would not be a fast
forward, and the "ordinary users" should not force pushes.
What am I missing?
--John
(please excuse the footer; it's not my idea)
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the material from any computer.
^ permalink raw reply
* Re: [PATCH] doc: clarify how -S works
From: John Tapsell @ 2009-03-03 17:39 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Peter Valdemar Mørch (Lists), git
In-Reply-To: <20090303171138.GA454@coredump.intra.peff.net>
2009/3/3 Jeff King <peff@peff.net>:
> On Tue, Mar 03, 2009 at 08:42:12AM -0800, Junio C Hamano wrote:
>
>> In retrospect, because --pickaxe was designed primarily for Porcelain use,
>> it was a mistake for it to have taken a short-and-sweet -S synonym.
>
> Hmm. I actually like the pickaxe behavior and find it useful for
> searching. IOW, I consider it a porcelain feature, just perhaps not the
> one that some people are expecting.
>
>> > -S<string>::
>> > - Look for differences that contain the change in <string>.
>> > + Look for differences that introduce or remove an instance of
>> > + <string>. Note that this is different than the string simply
>> > + appearing in diff output; see the 'pickaxe' entry in
>> > + linkgit:gitdiffcore[7] for more details.
>>
>> Look for differences that change the number of occurrences of <string>?
>
> Yes, that is technically correct. I was trying to find a wording that
> was a little less "this is literally what it does" and more "this is
> what you might find it useful for".
Is there any way to have an option to also match any line containing
the string? That might be the best way to document it, as well as
being very useful:
-s<string>
Look for any additions, removals or changes in any line containing <string>
-S<string>
Look only for any additions or removals of the <string> in any line
John
^ permalink raw reply
* Re: First round of UGFWIINI results
From: Johannes Schindelin @ 2009-03-03 17:36 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Junio C Hamano, Reece Dunn, git
In-Reply-To: <fabb9a1e0903030826p7caa17e3m45789026d51a2f8e@mail.gmail.com>
Hi,
On Tue, 3 Mar 2009, Sverre Rabbelier wrote:
> Heya,
>
> On Tue, Mar 3, 2009 at 17:04, Junio C Hamano <gitster@pobox.com> wrote:
> > Are you also in the contest, with your blog as one of the contenders?
>
> I remember Dscho saying anything mentioned in the announcement does
> not count, but upon later inspection of the original post I cannot
> find it...?
I thought so, too, but from the git log it does not seem like it. Of
course, I sneakily rewrote history from time to time (so it should be
in git log -g, but that computer is at home) ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: First round of UGFWIINI results
From: Jeff King @ 2009-03-03 17:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Reece Dunn, git
In-Reply-To: <alpine.DEB.1.00.0903031826060.6399@intel-tinevez-2-302>
On Tue, Mar 03, 2009 at 06:27:27PM +0100, Johannes Schindelin wrote:
> I am interested in reading Reece's short stories, though.
I can only hope that they're git-themed (Linus fan-fiction?).
-Peff
^ permalink raw reply
* Re: First round of UGFWIINI results
From: Reece Dunn @ 2009-03-03 17:31 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, git
In-Reply-To: <alpine.DEB.1.00.0903031826060.6399@intel-tinevez-2-302>
2009/3/3 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> On Tue, 3 Mar 2009, Jeff King wrote:
>
>> On Tue, Mar 03, 2009 at 04:59:27PM +0100, Johannes Schindelin wrote:
>>
>> > > Does using Git to track edits when proofreading a html/text document
>> > > (short story, novel, ...) count?
>> >
>> > I'll count it, but I want (read-only) access to the repository as a proof
>> > that you actually use Git that way ;-)
>>
>> Is it really that unusual? I've been keeping academic papers in git for
>> years (and CVS before that -- blech), and I'm sure I'm not alone.
>
> Count me in.
>
> I am interested in reading Reece's short stories, though.
I am not writing them (at the moment :)). I am just using git to
proofread stories by other people.
- Reece
^ permalink raw reply
* Re: First round of UGFWIINI results
From: Johannes Schindelin @ 2009-03-03 17:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Reece Dunn, git
In-Reply-To: <7vljrmd24n.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 872 bytes --]
Hi,
On Tue, 3 Mar 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Tue, 3 Mar 2009, Reece Dunn wrote:
> >
> >> 2009/2/17 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> >> > 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
> >>
> >> Does using Git to track edits when proofreading a html/text document
> >> (short story, novel, ...) count?
> >
> > I'll count it, but I want (read-only) access to the repository as a
> > proof that you actually use Git that way ;-)
>
> Are you also in the contest, with your blog as one of the contenders?
As I am the jury, I decided to pretend that I have some decency left by
not putting my own Git crim^Wuses into the contest...
;-)
Ciao,
Dscho
^ permalink raw reply
* Re: First round of UGFWIINI results
From: Johannes Schindelin @ 2009-03-03 17:27 UTC (permalink / raw)
To: Jeff King; +Cc: Reece Dunn, git
In-Reply-To: <20090303161543.GC32079@coredump.intra.peff.net>
Hi,
On Tue, 3 Mar 2009, Jeff King wrote:
> On Tue, Mar 03, 2009 at 04:59:27PM +0100, Johannes Schindelin wrote:
>
> > > Does using Git to track edits when proofreading a html/text document
> > > (short story, novel, ...) count?
> >
> > I'll count it, but I want (read-only) access to the repository as a proof
> > that you actually use Git that way ;-)
>
> Is it really that unusual? I've been keeping academic papers in git for
> years (and CVS before that -- blech), and I'm sure I'm not alone.
Count me in.
I am interested in reading Reece's short stories, though.
> Of course I'm writing in LaTeX, which is arguably a programming
> language. ;)
>
> BTW, --color-words is indispensable when dealing with things that aren't
> line-oriented.
Guess three times why I wrote --color-words...
You guessed it. Academic papers written in LaTeX.
Ciao,
Dscho
^ permalink raw reply
* Re: parallel dev. with email
From: Marcel M. Cary @ 2009-03-03 17:20 UTC (permalink / raw)
To: stoecher@gmx.at; +Cc: git@vger.kernel.org
In-Reply-To: <20090303153141.246620@gmx.net>
stoecher@gmx.at wrote:
> Hi,
>
> I am new to git and I am wondering what git commands to use for
> this szenario: two developers without the possibility of sharing
> a server communicate their changes via email.
>
> This is how far I have come reading the online docu:
> * Each developer can create the diff-info of his commits with
> git format-patch
> * and the other developer can incorporate these changes with
> git am
>
> After creating the patches with format-patch one could set a tag:
> git tag -f patchesDone
> so next time one wants to create patches, this tag can be used as the starting point:
> git format-patch patchesDone..
I wonder if it would be easier to maintain a separate branch containing
changes which you have both integrated. Suppose you call it "master".
And then do your own work on another branch called "private". Then when
you want to send all your new work, you can just do:
git format-patch master..private
possibly threading the messages, etc.
When your collaborator has acknowledged receipt of the patches, you put
them on your master also, and rebase your "private" branch. If the
patch doesn't apply cleanly for your collaborator, you'd need to apply
your collaborator's resolution to your master instead of your original
patch. Or you could apply whatever work your collaborator has that is
conflicting with your own patch, and resolve the conflict yourself.
I would expect you can periodically verify that your "master" source
code is synchronized by comparing tree hashes, even though the commit
hashes may differ.
I imagine you might find that your patches might sometimes have a
different order than your collaborator's if your emails cross, and their
commit hashes may differ. But I expect that would mostly work out ok.
You could probably verify that your "master" source code is synchronized
by comparing tree hashes from time to time, even though the commit
hashes may differ.
You could even split your work among several "feature branches". But
one piece of information that "git format-patch" does not advertise, but
which "git push" does, is the branch that a patch should be applied to.
So if your protocol is email-only, and you want to share many branches
with your collaborator, you'd have to communicate that explicity in the
email.
> But what if in the meantime one has incorporated the other
> developer's changes with git am? Then these changes will also
> be among the patches created with format-patch. What will
> happen, if these patches are sent to the other developer,
> who does not need his own changes again. Will his own changes
> be silently ignored by git am?
Yes, provided the actual code changes in the duplicate patch are exactly
the same, git am will skip it, even if the committer, timestamps, or
comment are slightly different.
Marcel
^ permalink raw reply
* Re: move files between disparate repos and maintain version history
From: Jeff King @ 2009-03-03 17:18 UTC (permalink / raw)
To: David Copeland; +Cc: git
In-Reply-To: <f95d47890903030858xb398b5fy1aeabb19166e6077@mail.gmail.com>
On Tue, Mar 03, 2009 at 11:58:42AM -0500, David Copeland wrote:
> The first option worked, insomuch the history of diffs is preserved,
> but the dates are all today.
That's odd. It works fine here. Can you confirm that the correct dates
in the "patches" file (i.e., the output of format-patch)? What are you
using to look at the patches? Note that gitk will show you both the
"committer" and the "author" fields. The "author" field should have the
original author and time of the patch, but the "committer" will be you,
today.
> The second option was a little over my head; is the idea there that
> you are setting up a branch that has ONLY the files I care about (with
> all their history), and then I pull from the other repo as if they are
> related? That seems like it might preserve the dates...
Yes, that is exactly what is happening in the second example.
-Peff
^ permalink raw reply
* Re: fatal: git write-tree failed to write a tree
From: Caleb Cushing @ 2009-03-03 17:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0903031103580.6399@intel-tinevez-2-302>
>
> 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.
no... not so simple... git mergetool comes back with (c)reated
(d)eleted files. I want the created one. when I choose that and
commit, no merge is capable of happening. it says (for that file) that
there is nothing to change, in fact if nothing else has changed the
branch will simply say nothing to commit once I've resolved it. all
commits at this point are simply commits.
--
Caleb Cushing
http://xenoterracide.blogspot.com
^ permalink raw reply
* Re: [RFC PATCH] Windows: Assume all file names to be UTF-8 encoded.
From: Dmitry Potapov @ 2009-03-03 17:13 UTC (permalink / raw)
To: Peter Krefting; +Cc: Thomas Rast, git
In-Reply-To: <alpine.DEB.2.00.0903031246420.3702@perkele.intern.softwolves.pp.se>
On Tue, Mar 3, 2009 at 2:48 PM, Peter Krefting <peter@softwolves.pp.se> wrote:
> 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.
No, it does not, if you have wchar_t that is only 16-bit wide, because
characters
outside of the BMP have integer values in Unicode greater than 65535...
Dmitry
^ permalink raw reply
* [PATCH] Documentation/git-archive.txt: Note attributes
From: roylee @ 2009-03-03 16:52 UTC (permalink / raw)
To: git; +Cc: Roy Lee
From: Roy Lee <roylee17@gmail.com>
---
Documentation/git-archive.txt | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt
index 41cbf9c..96f5424 100644
--- a/Documentation/git-archive.txt
+++ b/Documentation/git-archive.txt
@@ -88,6 +88,17 @@ tar.umask::
archiving user's umask will be used instead. See umask(2) for
details.
+ATTRIBUTES
+----------------
+
+export-ignore::
+ Files and directories with the attribute export-ignore won't be added to archive files.
+ See linkgit:gitattributes[5] for details.
+
+export-subst::
+ If the attribute export-subst is set for a file then git will expand several placeholders when adding this file
+ to an archive. See linkgit:gitattributes[5] for details.
+
EXAMPLES
--------
git archive --format=tar --prefix=junk/ HEAD | (cd /var/tmp/ && tar xf -)::
@@ -110,6 +121,11 @@ git archive --format=zip --prefix=git-docs/ HEAD:Documentation/ > git-1.4.0-docs
Put everything in the current head's Documentation/ directory
into 'git-1.4.0-docs.zip', with the prefix 'git-docs/'.
+
+SEE ALSO
+--------
+linkgit:gitattributes[5]
+
Author
------
Written by Franck Bui-Huu and Rene Scharfe.
--
1.6.1.3
^ permalink raw reply related
* Re: [PATCH] doc: clarify how -S works
From: Jeff King @ 2009-03-03 17:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Peter Valdemar Mørch (Lists), git
In-Reply-To: <7v1vted0d7.fsf@gitster.siamese.dyndns.org>
On Tue, Mar 03, 2009 at 08:42:12AM -0800, Junio C Hamano wrote:
> In retrospect, because --pickaxe was designed primarily for Porcelain use,
> it was a mistake for it to have taken a short-and-sweet -S synonym.
Hmm. I actually like the pickaxe behavior and find it useful for
searching. IOW, I consider it a porcelain feature, just perhaps not the
one that some people are expecting.
> > -S<string>::
> > - Look for differences that contain the change in <string>.
> > + Look for differences that introduce or remove an instance of
> > + <string>. Note that this is different than the string simply
> > + appearing in diff output; see the 'pickaxe' entry in
> > + linkgit:gitdiffcore[7] for more details.
>
> Look for differences that change the number of occurrences of <string>?
Yes, that is technically correct. I was trying to find a wording that
was a little less "this is literally what it does" and more "this is
what you might find it useful for".
But I don't care overly much; I just think what was there was quite
misleading. And I've already provided my paint color, so feel free to
apply mine, use what you wrote above, or whatever. Just don't leave it
as-is. ;)
-Peff
^ permalink raw reply
* Re: [PATCH v2] git-clone: Add option --branch to override initial branch
From: Junio C Hamano @ 2009-03-03 17:07 UTC (permalink / raw)
To: Tor Arne Vestbø; +Cc: Johannes Schindelin, git
In-Reply-To: <49AD6305.8040909@gmail.com>
Tor Arne Vestbø <torarnv@gmail.com> writes:
> In that case you would either have to ff master all the time
> (requiring a checkout or rebase magic), or do an explicit "git push
> origin 1.6".
or do something like:
$ cat >>.git/config <<\EOF
[remote "there"]
push = HEAD
EOF
just once.
^ permalink raw reply
* Re: [PATCH v2] git-clone: Add option --branch to override initial branch
From: Tor Arne Vestbø @ 2009-03-03 17:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vr61eblde.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Tor Arne Vestbø <torarnv@gmail.com> writes:
>
>> If you would like to contribute to the stable 1.6 branch, do:
>> $ git clone -n git://git.foo.com/project.git
>> $ cd project
>> $ git checkout -t origin/1.6
>> $ git branch -D master
>> Which is not so nice and inviting.
>
> If you are working on 1.6 maintenance track, why discard 'master'?
One example I can think of is if master is moving a lot faster than the
maintenance track, and you are not interested in master.
[box:/tmp/downstream] $ git branch
* 1.6
master
[box:/tmp/downstream] $ git pull --rebase
Current branch 1.6 is up to date.
[box:/tmp/downstream] $ git push
To file:///tmp/upstream
! [rejected] master -> master (non-fast forward)
error: failed to push some refs to 'file:///tmp/upstream'
In that case you would either have to ff master all the time (requiring
a checkout or rebase magic), or do an explicit "git push origin 1.6".
Neither good options when you are trying to teach people that git push
is the way you submit changes.
Tor Arne
^ permalink raw reply
* Re: move files between disparate repos and maintain version history
From: David Copeland @ 2009-03-03 16:58 UTC (permalink / raw)
To: git
In-Reply-To: <20090303041300.GA18136@coredump.intra.peff.net>
The first option worked, insomuch the history of diffs is preserved,
but the dates are all today. The second option was a little over my
head; is the idea there that you are setting up a branch that has ONLY
the files I care about (with all their history), and then I pull from
the other repo as if they are related? That seems like it might
preserve the dates...
Dave
On Mon, Mar 2, 2009 at 11:13 PM, Jeff King <peff@peff.net> wrote:
> On Mon, Mar 02, 2009 at 12:30:58PM -0800, davetron5000 wrote:
>
>> So, is there a way I can move a file between two git repositories,
>> maintaining the change history? I guess it would be something like
>> "apply all patches that this file was involved in, but ONLY apply the
>> ones affecting this file, to the new repo, then delete from the old"?
>
> Yes, that's more or less how you would do it. There are actually two
> separate issues, and each has two possible solutions.
>
> Issue 1 is moving the history to the new repo.
>
> One solution is, as you guessed, to export as patches and import into
> the new repo:
>
> cd /path/to/app
> git format-patch --stdout --root -- <path> >~/patches
> cd /path/to/core
> git am ~/patches
>
> where <path> can be a file, directory, or a list of either or both.
> This should work fine if the history of that path is linear, since a
> list of patches is, by definition, linear. You can see the "shape" of
> the history with:
>
> cd /path/to/app
> gitk -- <path>
>
> The other solution is to actually rewrite a version of git history that
> sees only those paths, then merge it in. That will retain the actual
> shape of the history. You can do this using "git filter-branch":
>
> cd /path/to/app
> # we do our work on a temporary branch
> git branch just-path
> # the actual filter; note you could do more than just grep here
> # if you wanted to munge the pathnames
> git filter-branch --index-filter '
> git ls-files -s | grep path |
> GIT_INDEX_FILE="$GIT_INDEX_FILE.new" git update-index --index-info &&
> mv "$GIT_INDEX_FILE.new" "$GIT_INDEX_FILE"
> ' --prune-empty just-path
>
> # you can inspect just-path at this point with "gitk just-path"
> cd /path/to/core
> # and then pull it into core's history
> git pull /path/to/app just-path
>
> The second issue is what you want to have happen in the "app"
> repository. Presumably you no longer want the moved files there. You
> _could_ filter-branch to pretend as if they were always in "core" and
> never in "app". But that is probably not a good idea because:
>
> 1. You are rewriting history, which will make merging more complex for
> your users.
>
> 2. You may be breaking historical builds which expect the files to be
> there in the past.
>
> So I think you're probably best to just remove them with a new commit
> and have the duplicated history in both.
>
> -Peff
>
> PS I think you might be able to replace the filter-branch invocation
> with a fast-export / fast-import pipeline, but I haven't tried.
>
^ permalink raw reply
* Re: [RFC] Add an option for git-archive to output commit ID in alternative ways
From: roylee17 @ 2009-03-03 16:51 UTC (permalink / raw)
To: git
In-Reply-To: <7vtz6ad31f.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
>
> roylee17 <roylee17@gmail.com> writes:
>
>> 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?
>
> Run "man gitattributes" and look for export-subst?
>
>
Really nice feature, thanks.
--
View this message in context: http://n2.nabble.com/-RFC--Add-an-option-for-git-archive-to-output-commit-ID-in-alternative-ways-tp2414580p2416431.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH v2] git-clone: Add option --branch to override initial branch
From: Junio C Hamano @ 2009-03-03 16:51 UTC (permalink / raw)
To: Tor Arne Vestbø; +Cc: Johannes Schindelin, git
In-Reply-To: <49AD5F0D.8000700@gmail.com>
Tor Arne Vestbø <torarnv@gmail.com> writes:
> If you would like to contribute to the stable 1.6 branch, do:
> $ git clone -n git://git.foo.com/project.git
> $ cd project
> $ git checkout -t origin/1.6
> $ git branch -D master
> Which is not so nice and inviting.
If you are working on 1.6 maintenance track, why discard 'master'? If the
upstream project calls it 1.6, you can call your fork 1.6 and keep that
checked out.
IOW, _you_ are make it not nice.
^ permalink raw reply
* Re: [PATCH v3] send-email: add --confirm option and configuration setting
From: Junio C Hamano @ 2009-03-03 16:48 UTC (permalink / raw)
To: Jay Soffian; +Cc: Bert Wesarg, git, Nanako Shiraishi, Paul Gortmaker
In-Reply-To: <76718490903030822j690cb97blea292d391c0d0112@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> On Tue, Mar 3, 2009 at 6:54 AM, Bert Wesarg <bert.wesarg@googlemail.com> wrote:
>> 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?
>
> There doesn't seem to be any point in having the user confirm before
> sending the message if the message is not actually going to be sent.
> Am I missing something?
I do not think you are missing anything.
IIRC, the --dry-run mode shows more clearly to whom you would be CC'ing
the messages; in other words, the behaviour would be different, but it
gives an uninteractive way to confirm, and not pausing for confirmation is
a good thing.
^ permalink raw reply
* Re: [PATCH v2] git-clone: Add option --branch to override initial branch
From: Tor Arne Vestbø @ 2009-03-03 16:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0903031004570.6399@intel-tinevez-2-302>
Johannes Schindelin wrote:
> Leaving unnecessary initialization and funny indentation aside for a
> moment,
I do appreciate the feedback though. C is not my primary language, and
I'm happy to learn from my mistakes :-)
> Keep in mind: your change (as every change) bears the potential to
> introduce bugs and to complicate the user interface. The change must be
> worth those risks.
I fully understand. Here is my rationale for why it's worth the risk:
Imagine you have a project called Foo, which has active development on
the 'master' branch, and not quite so active development on the more
stable version branch '1.6' (which v1.6.0 and v1.6.1 was tagged from).
Now, you want to put up info on the project web page / wiki on how to
contribute to project Foo. This information is for new contributors --
who may be unfamiliar with git and it's inner workings. You write:
"To get started contributing to project Foo, please clone using:
$ git clone git://git.foo.com/project.git
"
This looks nice and inviting.
You also want to provide instructions for those who would like to
contribute to the more stable branch of project Foo, 1.6:
"If you would like to contribute to the stable 1.6 branch, do:
$ git clone -n git://git.foo.com/project.git
$ cd project
$ git checkout -t origin/1.6
$ git branch -D master
"
Which is not so nice and inviting. At least not compared to:
"If you would like to contribute to the stable 1.6 branch, do:
$ git clone git://git.foo.com/project.git --branch 1.6
"
Remember these are new contributors, unfamiliar with git. Presenting
them with a list of four commands that have to be run to get started
(commands which incidentally also are the first-ones new users mix up),
is not ideal. "What does -n do?", "What does -t do?", "What's a tracking
branch?", "Origin? What's that?", "What does -D do?", "Delete?! Will I
delete the main development line!?", etc.. :)
Also, remember that these commands are not something that can be
scripted or put into an alias, because these users have not cloned
anything yet.
I know Subversions is perhaps not the best ideal, but to contrast:
$ svn import http://svn.foo.bar/project/trunk
$ svn import http://svn.foo.bar/project/branches/1.6
Easy to get to a different branch without having to dive into the full
feature set of the SCM.
So, to conclude, I see this as a usability-feature of git-clone, which
outweighs the possible risk of introducing new bugs. It's not a feature
I will personally use that often, but it's one that I think new users
will appreciate.
Tor Arne
^ permalink raw reply
* Re: [PATCH] doc: clarify how -S works
From: Junio C Hamano @ 2009-03-03 16:42 UTC (permalink / raw)
To: Jeff King; +Cc: Peter Valdemar Mørch (Lists), git
In-Reply-To: <20090303154041.GA31265@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I wonder if "gitdiffcore" is a little scary for new people who just want
> to use "-S", but hopefully point (1) above will get rid of most of the
> confusion, and those who follow the link want to learn all about diff.
As I mentioned in the other message, what --pickaxe achieves is very
different from what people would naturally want from --search, an
option that does not exist.
I do not mind a patch that adds a diffcore transformation that internally
generates a diff and searches the string given by the user in it, and
triggers that with --search option. The transformation should come just
after (or before) the pickaxe in the call sequence inside diffcore_std();
name it diffcore_search() or something.
In retrospect, because --pickaxe was designed primarily for Porcelain use,
it was a mistake for it to have taken a short-and-sweet -S synonym.
> diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
> index 813a7b1..9276fae 100644
> --- a/Documentation/diff-options.txt
> +++ b/Documentation/diff-options.txt
> @@ -176,7 +176,10 @@ override configuration settings.
> number.
>
> -S<string>::
> - Look for differences that contain the change in <string>.
> + Look for differences that introduce or remove an instance of
> + <string>. Note that this is different than the string simply
> + appearing in diff output; see the 'pickaxe' entry in
> + linkgit:gitdiffcore[7] for more details.
Look for differences that change the number of occurrences of <string>?
^ permalink raw reply
* Re: [PATCHv4 0/2] git submodule: normalize paths before adding
From: Junio C Hamano @ 2009-03-03 16:32 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Johannes Sixt, Andrei Thorp
In-Reply-To: <1236092901-28500-1-git-send-email-git@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> This is a rewrite taking into account the advice given by Junio and J6t.
> In particular, the tests are good citizens w.r.t. cd'ing around now, the
> sed expressions work at least on AIX 4.3.3, and iterations of .. are
> tested for and handled correctly.
>
> Sorry I didn't get around to finishing this earlier. Hope this doesn't
> mess up any schedules.
No worries.
Other than obvious documentation fixes, anything sent after -rc0 will not
hit 'master' unless it is a fix, and after -rc1 nothing will hit 'master'
unless it is a regression fix. Even if some future version of your patch
is queued to 'pu' or 'next, it won't affect the schedule for 1.6.2.
Traditionally, those patches that are irrelevant to the upcoming release
during the -rc period have been discussed on the list and then discarded,
with a request to be resubmit after the release. Even though I have been
queuing them to 'pu' or 'next' as an experiment during this cycle, it has
not changed that during the -rc period, any new topic will not disrupt the
upcoming release.
^ permalink raw reply
* Re: [RFC PATCH] Windows: Assume all file names to be UTF-8 encoded.
From: Lars Noschinski @ 2009-03-03 16:29 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.2.00.0903031248040.3702@perkele.intern.softwolves.pp.se>
* Peter Krefting <peter@softwolves.pp.se> [09-03-03 12:54]:
> Lars Noschinski:
> >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.
Because a function in the source code refers to (e.g.) "DC 2E 74 78 74",
not "C3 9C 2E 74 78 74" nor "00DC 0024 0074 0078 0074". And it does so
regardless of the locale.
The file name may look funny depending on your locale, but if you rename
the file to fit your local enconding, it would not work.
^ permalink raw reply
* Re: First round of UGFWIINI results
From: Sverre Rabbelier @ 2009-03-03 16:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Reece Dunn, git
In-Reply-To: <7vljrmd24n.fsf@gitster.siamese.dyndns.org>
Heya,
On Tue, Mar 3, 2009 at 17:04, Junio C Hamano <gitster@pobox.com> wrote:
> Are you also in the contest, with your blog as one of the contenders?
I remember Dscho saying anything mentioned in the announcement does
not count, but upon later inspection of the original post I cannot
find it...?
--
Cheers,
Sverre Rabbelier
^ 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