* Re: pull into dirty working tree
From: Raimund Bauer @ 2007-06-14 8:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Bill Lear, git
In-Reply-To: <7vps3zascu.fsf@assigned-by-dhcp.pobox.com>
On Thu, 2007-06-14 at 00:49 -0700, Junio C Hamano wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
> > It might make it a bit easier for CVS people to get used to the git model:
> > keep your dirty working tree, and do "git pull" to update it, and fix up
> > any conflicts in the working tree. That's how CVS works - it's a bad
> > model, but it's a model that may be worth supporting just to get people
> > more easily into the _good_ model.
>
> If a bad model _is_ supported, what incentive is there for these
> people to move into the good model, I honestly wonder...
Is it a bad model for the normal development process? Probably.
Would it solve the problem of "I want to keep my debug-statements that I
won't ever commit in the merged result"? ... yes
I think that's at least one valid usecase we should probably support.
One I'd also like to use ;-)
--
best regards
Ray
^ permalink raw reply
* Re: Let me ask again: How do we import patches from non-git sources?
From: Matthieu Moy @ 2007-06-14 7:53 UTC (permalink / raw)
To: Marc Singer; +Cc: Jon Loeliger, Git List
In-Reply-To: <1181785754.4102.13.camel@zealous.synapsedev.com>
Marc Singer <elf@synapse.com> writes:
> On Wed, 2007-06-06 at 13:18 -0500, Jon Loeliger wrote:
>> On Wed, 2007-06-06 at 12:58, Matthieu Moy wrote:
>>
>> > Cogito is more or less depreceted now. You should probably use git
>> > itself.
>>
>> Hmm. We should then likely try to encourage kernel.org and denx.de
>> folks to advertise cloning their published repos with git rather
>> than cogito now.
>
> It's also users who are *just* getting their feet wet in the git pool.
Yes, and cogito definitely _used_ to be a very good thing for them.
But today, starting with cogito instead of git is not really easier
for a beginner: OK, the program is a bit simpler to use, but some
commands are missing, so you'll sometimes have to type "git" and
sometimes "cogito" (the cogito tutorial was actually using a few git
commands). Then, the user comes on the mailing list and asks
something, he will be answered in terms of git commands 95% of the
times, ...
For that reasons, the maintainer of cogito said some time ago that he
was probably going to stop working on cogito. Maybe I missed something
in the meantime, but I don't think anyone volunteered to continue with
cogito. So, encourraging people to use cogito is a bit like "hey, try
this, but once you've finished learning it, you'll have to forget it
and migrate" ...
--
Matthieu
^ permalink raw reply
* Re: pull into dirty working tree
From: Junio C Hamano @ 2007-06-14 7:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Bill Lear, git
In-Reply-To: <alpine.LFD.0.98.0706132216300.14121@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> It might make it a bit easier for CVS people to get used to the git model:
> keep your dirty working tree, and do "git pull" to update it, and fix up
> any conflicts in the working tree. That's how CVS works - it's a bad
> model, but it's a model that may be worth supporting just to get people
> more easily into the _good_ model.
If a bad model _is_ supported, what incentive is there for these
people to move into the good model, I honestly wonder...
^ permalink raw reply
* Re: [PATCH] Interpret :/<pattern> as a regular expression
From: Sam Vilain @ 2007-06-14 7:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, git
In-Reply-To: <Pine.LNX.4.64.0706132317240.4059@racer.site>
Johannes Schindelin wrote:
> Actually, that's funny. Yesterday, I repeated my claim that pcre is
> slow on IRC, and Sam Villain on IRC accused me of trolling. But as you can
> see from my postings on this list ($gmane/41682), you can see that _I_ had
> numbers to back up my claim.
>
> So no, I think pcre is just not worth it.
>
A strange thing to conclude from your figures, which show pcre as the
fastest out of several libraries that you tested.
Your figures show exactly what I was saying on IRC - that a DFA
(external grep) vs NFA engine (most regex libraries) is inherently
faster. The paper I linked to, specially selected as I had previously
read a significant amount of the peer review the paper received,
explained this in detail. The one piece of feedback your numbers got
on-list also mentioned this.
However there is a further flaw in your study. All but one of the
performance tests use an external program, which on a given system may
or may not be faster because of pipeline performance characteristics.
You could improve the quality of the result by using the 'pcregrep'
program as a data point. It might also be worth trying a few more
complex patterns. I suggest reading the paper
(http://swtch.com/~rsc/regexp/regexp1.html) for some background before
repeating the experiment.
Apologies for not reviewing your numbers at the time; it sure is hard to
keep on top of this list. But very interesting that they seem to suggest
pcre would be the best choice from a performance perspective, even
though the figures are very preliminary. Perhaps it is worth pursuing
after all.
Sam.
^ permalink raw reply
* Re: What's in git.git (stable)
From: Johannes Sixt @ 2007-06-14 7:12 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0706132322210.4059@racer.site>
Johannes Schindelin wrote:
> Next plans are: make filter-branch a misnomer: actually be able to rewrite
> more than one branch in one go, writing the outcome to the refs/rewritten/
> namespace. IIRC that was Hannes' project, but I'll gladly step in there if
> need be.
Be my guest. Even though I said "my plan" in that post
http://article.gmane.org/gmane.comp.version-control.git/49292
this was meant as a proposal. I'm not working on the topic at the
moment.
-- Hannes
^ permalink raw reply
* Re: Stupid quoting...
From: Alex Riesen @ 2007-06-14 7:06 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86wsy76p4v.fsf@lola.quinscape.zz>
On 6/14/07, David Kastrup <dak@gnu.org> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >> Can you actually name a program that would work with the default
> >> output of git here?
> >
> > echo.
>
> It doesn't, since it does not interpret the \NNN escape sequences that
> git chooses to output.
Have you tried that -z switch yet?
^ permalink raw reply
* Re: [PATCH] git-svn: allow dcommit to retain local merge information
From: Steven Grimm @ 2007-06-14 6:30 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, Joakim Tjernlund, git
In-Reply-To: <20070613092328.GA30318@muzzle>
Eric Wong wrote:
> Joakim/Steven:
> Any further testing and test cases would be appreciated. Be very
> careful with real-world repositories, and run dcommit with the
> '-n' flag before actually committing to verify the diffs are sane.
>
I poked at this some tonight with an eye toward the use case of using
git to merge svn branches. I ran into one inconvenience and one bug.
I'll try playing with the "use lots of git branches to develop on one
svn branch" use case some too, but for now, here are the notes I took,
along with the commands if anyone wants to reproduce what I did.
Hopefully this won't be too annoying to read. The bug is near the bottom.
svn repo with a trunk and a branch, each with changes (no conflicts at
first, keep it simple to start)
$ svnadmin create svnrepo
$ svn co file://`pwd`/svnrepo svnclient
$ cd svnclient
$ mkdir trunk tags branches
$ echo test file number 1 > trunk/testfile1
$ echo test file number 2 > trunk/testfile2
$ svn add *
$ svn commit -m "initial commit"
$ echo trunk change 1 >> trunk/testfile1
$ svn commit -m "trunk change 1"
$ echo trunk change 2 >> trunk/testfile2
$ svn commit -m "trunk change 2"
$ svn cp trunk branches/mybranch
$ svn commit -m "make a branch"
$ echo trunk change 3 >> trunk/testfile1
$ svn commit -m "post-branch change in trunk"
$ echo branch change 1 >> branches/mybranch/testfile2
$ svn commit -m "change in branch"
git-svn clone of this dinky repo
$ cd ..
$ git-svn clone --trunk=trunk --branches=branches --tags=tags
file://`pwd`/svnrepo gitclone
$ cd gitclone
Try to merge trunk change into branch using git
$ git reset --hard mybranch
$ git merge trunk
Conflicts! what's going on?
$ gitk --all
Aha, looks like git-svn guessed wrong about where I made the branch; it
thinks the branch comes from the initial rev. Easy enough to hack
around, but might be nice to be able to do this using git-svn's history
rewriting rather than a grafts file.
$ echo `git-svn find-rev r4` `git-svn find-rev r3 trunk` > .git/info/grafts
$ git reset --hard mybranch
$ git merge trunk
No conflicts now. Let's see what git-svn thinks it should do
$ git-svn dcommit -n
Looks like the right diff
$ git-svn dcommit
Refresh gitk display. Looks good, the new revision is a merge with the
right parents. Let's check it out in svn land
$ cd ../svnclient
$ svn up
$ cat branches/mybranch/testfile1
Yep, the trunk change is there, nice! Now for a couple more revs with a
conflict.
$ echo post-merge trunk change >> trunk/testfile1
$ svn commit -m "trunk change after merge"
$ echo post-merge conflicting change >> trunk/testfile2
$ svn commit -m "trunk change with conflict"
$ cd ../gitclone
$ git-svn fetch
$ git merge -m "change with conflict" trunk
Conflict, as expected
$ vi testfile2
$ git add testfile2
$ git commit
$ git-svn dcommit
Transaction is out of date: Out of date: '/trunk/testfile1' in
transaction '9-1' at /Users/koreth/git/git-svn line 398
Hmm, this merge was in mybranch, not in trunk
$ git log --first-parent
Yes, the most recent commit with a git-svn-id line has a mybranch URL.
So why is it complaining about a trunk file being out of date?
My experimentation pretty much ended there (I tried a few things to
clear the error up, but none of them helped.)
This machine is an OS X laptop. Subversion is 1.4.3 (r23084) from
MacPorts. I used the git-svn from the "pu" branch since it had this
patch and all the recent fixes.
Let me know if you need more details. Hope this is helpful.
-Steve
^ permalink raw reply
* Re: That improved git-gui blame viewer..
From: Marco Costalba @ 2007-06-14 6:24 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <f4ptq3$71v$1@sea.gmane.org>
On 6/14/07, Jakub Narebski <jnareb@gmail.com> wrote:
>
> On the other hand side, blaming multiple files in parallel has sense I think
> only for graphical viewer, not for command line command.
>
Yes, I agree. The only useful thing for command line is if you use it
togheter with some cache mechanism to allow following runs faster.
git-blame --cache-full-history (?)
Marco
^ permalink raw reply
* Re: Stupid quoting...
From: David Kastrup @ 2007-06-14 6:12 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0706140145450.4059@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> [somehow I got the impression your mail did not make it to the list]
>
> On Wed, 13 Jun 2007, David Kastrup wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>> > On Wed, 13 Jun 2007, David Kastrup wrote:
>> >
>> >> what is the point in quoting file names and their characters in
>> >> git-diff's output? And what is the recommended way of undoing the
>> >> damage?
>> >
>> > The recommended way is not using spaces to begin with.
>>
>> Who is talking about spaces?
>
> That is the common reason for quoting. I mean, really, how many files do
> you have which contain newlines or backslashes or tabs? Huh?
I am talking about non-ASCII characters.
>
>> > I mean, does "David" contain spaces?
>>
>> "Günter" contains non-ASCII characters.
>
> And "Guenther" (sorry, have problems with my mailer, so I simulate
> it in plain ASCII" does not need quotes, _even_ if containing
> non-ASCII characters.
>
> So what exactly was your point again?
You _are_ aware that git writes out \303\274 (8 characters: 2
backslashes and 6 digits) instead of ü in a file name? And I am
talking about a pure utf-8 locale.
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
My point was that these octal escape sequences are utterly pointless.
>> > People seem not to see the problem, and fail to blame Microsoft for
>> > all the damage they have done, introducing that stupid, stupid concept
>> > of filenames containing spaces, and _enforcing_ it.
>>
>> The concept of UNIX file names is _any_ byte sequence not
>> containing "/" or an ASCII NUL. Microsoft actually prohibits quite
>> a few more characters. Filenames with spaces first came into
>> serious use under MacOS, the first graphical user interface where
>> no shell and metacharacters interfered with the choice of file
>> names.
>>
>> Blaming Microsoft here is completely ridiculous.
>
> It is completely unridiculous. Before Microsoft -- in its infinite
> wisdom -- decided to create folders like "Program Files", and
> "Documents and Settings", and made it the _default_ (of all things)
> to save its ridiculous Word documents as "New Document", _nobody_ on
> this planet even _thought_ about including stupid whitespace in a
> filename.
>
> You can tell that this is true by looking at now-ancient Unix
> scripts.
You are making a spectacle of yourself. Do you even read what you are
replying to? When spaces became commonplace in _MacOS_, _MacOS_ was
by no means Unix-based. Microsoft only followed the trend (with a
delay of several years, by the way) when imitating the MacOS GUI.
>> >> I have something like
>> >>
>> >> git-diff -M -C --name-status -r master^ master | {
>> >> while read -r flag name
>> >> do
>> >> case "$name" in *\\[0-3][0-7][0-7]*)
>> >> name=$(echo -e $(echo "$name"|sed 's/\\\([0-3][0-7][0-7]\)/\\0\1/g;s/\\\([^0]\)/\\\\\1/g'))
>> >> esac
>> >> [...]
>> >>
>> >> in order to get through the worst with utf-8 file names, and it is a
>> >> complete nuisance (double quotemarks are treated later).
>> >
>> > Please understand that the quotes are not there for you, but for
>> > processing by other programs.
>> >
>> > However, I _suspect_ that you want to do something like
>> >
>> > name="$(echo $name)"
>> >
>> > because "echo" is exactly one of the programs this quoting was invented
>> > for.
>>
>> Only that it does not work with echo. echo requires \0NNN for
>> octal escapes, not \NNN, and then only when "echo -e" is used.
>
> Um. How does that apply here? Git only does quoting so that programs
> like echo get it right, when passed the name? No funny \0NNN or \NNN
> or whatever?
git puts out funny \NNN quotes. That's what I am complaining about.
>> You are really haphazard in distributing your blame.
>>
>> Can you actually name a program that would work with the default
>> output of git here?
>
> echo.
It doesn't, since it does not interpret the \NNN escape sequences that
git chooses to output.
--
David Kastrup
^ permalink raw reply
* Re: git-p4import.py robustness changes
From: Shawn O. Pearce @ 2007-06-14 5:35 UTC (permalink / raw)
To: Simon Hausmann; +Cc: Junio C Hamano, git
In-Reply-To: <200706122347.00696.simon@lst.de>
Simon Hausmann <simon@lst.de> wrote:
> I've used git-filter-branch to rewrite the history in fast-export to include
> only changes relevant to git-p4 and at the same time move all files into
> contrib/fast-import. The result is available as separate branch at
>
> git://repo.or.cz/fast-export.git git-p4
>
> and technically merges fine into git.git's contrib/fast-import directory with
> three files (git-p4, git-p4.txt and git-p4.bat for windows convenience).
>
> Please let me know if there's anything missing or if you prefer a different
> format or so. I also realized that I haven't really used the 'Signed-off-by'
> tags in the past but I'd be happy to adopt it for git inclusion if you prefer
> that :)
Yes. The SBO line is your assertion that you own the rights to the
code and can release it under the license you are offering it under.
One of the issues I have with this git-p4 history you have built
is the lack of the SBO line on all 255 commits.
Of course an SBO line doesn't carry that much weight, its just a line
after all, but according to Git's project standards it should be there
if you are agreeing to release it. See Documentation/SubmittingPatches
for details.
My other problem with this history is a commit like b79112 "a
little bit more convenience" (and there are many such commits).
This message is insanely short, doesn't really talk at all about
what a little bit is, how it is more convenient, or who it is more
convenient for.
Think about how that oneline (and the others) would look in Junio's
"What's new in git.git" emails, or in gitweb. There is not enough
detail here to be of any value to the reader. Expanding out to the
full message offers nothing additional either, because that is all
there is in the entire commit message body.
I do appreciate you taking the time to use filter-branch to try to
cleanup this history a bit. I really had originally planned on
pulling your tree through to my fastimport tree and then talking
Junio into merging with me. But after reading through this history I
don't want do that, because of the oneline summaries I just pointed
out above, and because of the missing SBO.
--
Shawn.
^ permalink raw reply
* Re: pull into dirty working tree
From: Linus Torvalds @ 2007-06-14 5:21 UTC (permalink / raw)
To: Bill Lear; +Cc: git
In-Reply-To: <18031.64456.948230.375333@lisa.zopyra.com>
On Wed, 13 Jun 2007, Bill Lear wrote:
>
> We have some CVS users who complain that they cannot do a pull
> into a dirty working tree, as they could under CVS.
Well, a lot of people have told you that the answer is "don't do that",
but I actually somewhat disagree.
I think it might be perfectly fine to allow for a *fast-forward* pull to
do a three-way merge on the working tree, assuming the index is clean in
the paths that got modified.
For a real merge (not just a fast-forward), we really *really* must not do
it, for a very simple reason: we have no sane way to handle conflicts if
we have both a merge from the pull itself _and_ a merge from the working
tree. Don't get me wrong: I'm sure it's possible in theory, I just think
that in practice it's such a total hairball that it's not worth it!
So I think we could actually try to allow "git pull" with a fast-forward
pull and a dirty working tree.
(We obviously _already_ allow a working tree that is dirty in the paths
that don't actually get changed at all! I use that all the time. So this
is strictly limited to the "dirty state actually overlaps with what got
pulled!)
It might make it a bit easier for CVS people to get used to the git model:
keep your dirty working tree, and do "git pull" to update it, and fix up
any conflicts in the working tree. That's how CVS works - it's a bad
model, but it's a model that may be worth supporting just to get people
more easily into the _good_ model.
Linus
^ permalink raw reply
* Re: That improved git-gui blame viewer..
From: Shawn O. Pearce @ 2007-06-14 5:17 UTC (permalink / raw)
To: Josef Weidendorfer
Cc: Johannes Schindelin, Marco Costalba, Junio C Hamano,
Linus Torvalds, Git Mailing List
In-Reply-To: <200706131854.59605.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> I wished git-gui and gitk would be better integrated for
> history/blame browsing;
I'm not sure when/if git-gui and gitk will ever integrate. It
looks like it would be a good bit of work. ;-)
> I also missed a text search functionality
> in the blame view of git-gui.
That's on my list of things to do very-soon-now. I'm hoping to
get it into the next release of git-gui, which should be 0.8.0,
and maybe will happen by early next week.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Edit user manual for grammar
From: Shawn O. Pearce @ 2007-06-14 4:59 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Andy Parkins, git
In-Reply-To: <20070612175421.GA26767@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> wrote:
> On Tue, Jun 12, 2007 at 04:43:19PM +0100, Andy Parkins wrote:
> > - "recovery" becomes "recovering" from Steve Hoelzer's original version
> > of this patch
> > - "if you want" is nicer as "if you wish"
> > - "you may" should be "you can"; "you may" is "you have permission to"
> > rather than "you can"'s "it is possible to"
>
> What we really need is a complete recovery tutorial to stick in here
> someplace. (One day git complains about a corrupt pack file. What do
> you do?) What's been stopping me from doing it, besides time, is no
> idea how to come up with a good example to work with.
dd if=/dev/urandom of=.git/pack/pack-DEAD.pack bs=1 seek=12 count=512
Now run git-log. Its probably toast. The front of the packfile
is usually commits, and the first object is usually the most
recent commit. It starts at byte 12. ;-)
We actually do this in the test suite to verify that verify-pack will
detect the corruption. Recovering from it is a bit more interesting
and difficult.
The more common corruption is to repack away an important object
by accident in a shared object directory arrangement. Or just
havee your OS' "disk corruptor^H^H^H^H^H^H^Hvirus scanner" delete
the thing. E.g. create a few commits, pick one out of git-log
and just rm its file in .git/objects/??. How do you get out of
that mess? ;-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Introduce file with the common default build-time items.
From: Shawn O. Pearce @ 2007-06-14 4:36 UTC (permalink / raw)
To: Eygene Ryabinkin; +Cc: git
In-Reply-To: <20070613054316.GN86872@void.codelabs.ru>
Eygene Ryabinkin <rea-git@codelabs.ru> wrote:
> Words 'wish' and 'tclsh' are scattered across at least three files,
> but they are tied to the same entities. To ease the maintenance
> and remove errors, these configuration items were gathered into the
> separate file named 'common-make-vars.def'.
...
> diff --git a/git-gui/Makefile b/git-gui/Makefile
> index 3de0de1..654641a 100644
> --- a/git-gui/Makefile
> +++ b/git-gui/Makefile
> @@ -6,6 +6,8 @@ all::
> GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
> @$(SHELL_PATH) ./GIT-VERSION-GEN
> -include GIT-VERSION-FILE
> +# Default values
> +-include ../common-make-vars.def
A good idea to try and make these all common, but you cannot do this,
or at least this part of the patch.
The git-gui subdirectory of git.git is actually its own project,
maintained in its own Git repository. It appears inside of
git.git only as a convience for users. So I cannot reference
../common-make-vars.def as not all git-gui repositories have a
git.git repository wrapped around them.
--
Shawn.
^ permalink raw reply
* Re: pull into dirty working tree
From: Daniel Barkalow @ 2007-06-14 4:22 UTC (permalink / raw)
To: Bill Lear; +Cc: git
In-Reply-To: <18031.64456.948230.375333@lisa.zopyra.com>
On Wed, 13 Jun 2007, Bill Lear wrote:
> We have some CVS users who complain that they cannot do a pull
> into a dirty working tree, as they could under CVS. Here is
> their scenario: they make a few changes to their code and want
> to test it out; someone else pushes changes to the central repo
> that they then want to add to their working tree to test also;
> they then want to pull in these changes and test everything, as
> if they had done 'mv stuff stuff-; git pull; mv stuff- stuff'.
>
> They would like an option (perhaps a config option) to do a "dirty
> pull".
>
> The git-merge documentation states:
>
> You may have local modifications in the working tree files. In other
> words, git-diff is allowed to report changes. However, the merge uses
> your working tree as the working area, and in order to prevent the
> merge operation from losing such changes, it makes sure that they do
> not interfere with the merge. Those complex tables in read-tree
> documentation define what it means for a path to "interfere with the
> merge". And if your local modifications interfere with the merge,
> again, it stops before touching anything.
>
> But my colleagues are still wondering: why can't git just do it as
> CVS does?
>
> I know there are workarounds: I myself documented a set of commands
> to "put things on a shelf", but they still are whining.
>
> I need a convincing argument: not a technical one, but one that is
> practical (e.g. where CVS would do harm that git is preventing).
Where CVS would do harm that git is preventing is if they did something
brilliant, forgot how they did it, got other people's changes from the
central repository, and got complicated merge conflicts, and lost their
change trying to resolve them. (Or, for that matter, if the merge
algorithm screwed up the file without reporting conflicts.)
What git refuses to do is overwrite a file you've changed when you haven't
committed it, because something could go wrong, and you'd lose the work.
It would be possible to tell git that you're okay with it accidentally
losing your work, but people tend not to like this idea quite so much when
it's phrased like that.
The git sequence for this situation is:
$ git commit -a
$ git fetch
$ git rebase origin
The operation they want to perform is "rebase", which puts the changes
they made on top of other people's changes instead of where they were
written. It also wants the changes committed, so that it doesn't have to
worry about losing your work, but afterward you can use "git commit
--amend" to add fixes and the rest of your changes, because your work is
the top commit and hasn't been pushed out. Alternatively, "git reset
HEAD^" at the end of the sequence will turn the commit into uncommitted
changes.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Linus Torvalds @ 2007-06-14 3:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0706132334060.4059@racer.site>
On Wed, 13 Jun 2007, Johannes Schindelin wrote:
>
> > * js/filter (Fri Jun 8 23:28:50 2007 +0200) 11 commits
>
> Isn't that convenient?
Heh. I heard a perfect Dana Carvey "Isn't that conveeenient" in my head on
that line (SNL "Church Lady" skits, in case people don't make the
connection).
Was that intentional, or is it just my brain that is fried?
"Isn't that speecial?"
> That's already the second project the two JS'es are working together...
There's clearly something deeper to this notion of two-letter naming that
Junio uses. I used to think it was obviously flawed, but Junio may really
be onto something here..
Linus
^ permalink raw reply
* Re: tags and patches
From: Geoff Russell @ 2007-06-14 2:50 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, git
In-Reply-To: <20070614021939.GA18325@segfault.peff.net>
On 6/14/07, Jeff King <peff@peff.net> wrote:
> On Thu, Jun 14, 2007 at 11:35:35AM +0930, Geoff Russell wrote:
>
> > I'm trying to work out if I want to use git to manage a software
> > distribution problem. I distribute release v1.0 to people then later I
> > want to email them a patch to take them from v1.0 to v1.1. I can
> > probably live without the tags, but am just surprised that patches
> > don't send them.
>
> Patches represent differences in _content_, but they don't show history.
> So while git supports a somewhat extended patch format (supporting
> things like renames and file modes), patches don't know anything about
> branches, parent commits, or tags.
>
> If you are trying to take people from v1.0 to v1.1, the best way depends
> on their setup:
>
> - If they are all running git, then you can have them 'pull' from your
> repository
> - If you don't like that for some reason, you can send them a bundle,
> which is the moral equivalent of pulling (except that you've pushed
> through a non-interactive medium, but the end result in their
> repository is the same)
> - If they aren't running git, then you can use git to prepare the
> patch by tagging your own repository, and then creating either a
> patch series (git-format-patch v1.0..v1.1) or a single big patch
> (git-diff v1.0..v1.1). But either way, what would it mean to have a
> tag in the patch, since they don't have a tagging system at the
> other end?
>
> I'm not really sure what you're trying to accomplish; if you can be more
> concrete, we might be able to offer more concrete solutions (or maybe
> the answer you were looking for was simply, "you want bundles, not
> patches").
Ok (in english we have an expression "the penny has dropped" :)), I understand
my confusion and no longer am surprised that patches don't have tags!
I think that we will ensure everyone is running git (but we will ssh into their
machines and do the appropriate pulls).
Many thanks for your help and patience,
Cheers,
Geoff
>
> -Peff
>
^ permalink raw reply
* Re: tags and patches
From: Johannes Schindelin @ 2007-06-14 2:31 UTC (permalink / raw)
To: Geoff Russell; +Cc: git
In-Reply-To: <93c3eada0706131905i1cd43fd2xcc44ce47dca8ce00@mail.gmail.com>
Hi,
On Thu, 14 Jun 2007, Geoff Russell wrote:
> On 6/14/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > AFAIK patches are not supposed to _contain_ patches.
>
> Is this a typo? I expected patches to contain tags, not other patches.
Actually, two typos. Sorry. "AFAIK" -> "AFAICT", and the rest should
actually have been written as "formatted patches are not supposed to
contain tags."
> > What you want is probably a bundle. You don't want a collection of
> > diffs with comments on them, but you want a collection to reacreate
> > the history the other side has.
>
> I didn't know about bundles but do now. However "git bundle --help"
> tells me "No manual entry for git-bundle" despite git-bundle.html being
> in the Documentation directory.
... which probably means that your man pages, and therefore your Git
installation, is not up-to-date.
> I'm trying to work out if I want to use git to manage a software
> distribution problem. I distribute release v1.0 to people then later I
> want to email them a patch to take them from v1.0 to v1.1. I can
> probably live without the tags, but am just surprised that patches don't
> send them.
Patches are just files of the format that "diff" outputs, and "patch"
accepts. There was never any possibility to change anything but files.
But then, usually people put the version _into_ files. So I suspect you
really don't need tags, if you _have_ to send patches. Because if you
_have_ to send patches, your recipients probably don't use Git, and could
not use those tags anyway.
Ciao,
Dscho
^ permalink raw reply
* Re: tags and patches
From: Jeff King @ 2007-06-14 2:19 UTC (permalink / raw)
To: Geoff Russell; +Cc: Johannes Schindelin, git
In-Reply-To: <93c3eada0706131905i1cd43fd2xcc44ce47dca8ce00@mail.gmail.com>
On Thu, Jun 14, 2007 at 11:35:35AM +0930, Geoff Russell wrote:
> I'm trying to work out if I want to use git to manage a software
> distribution problem. I distribute release v1.0 to people then later I
> want to email them a patch to take them from v1.0 to v1.1. I can
> probably live without the tags, but am just surprised that patches
> don't send them.
Patches represent differences in _content_, but they don't show history.
So while git supports a somewhat extended patch format (supporting
things like renames and file modes), patches don't know anything about
branches, parent commits, or tags.
If you are trying to take people from v1.0 to v1.1, the best way depends
on their setup:
- If they are all running git, then you can have them 'pull' from your
repository
- If you don't like that for some reason, you can send them a bundle,
which is the moral equivalent of pulling (except that you've pushed
through a non-interactive medium, but the end result in their
repository is the same)
- If they aren't running git, then you can use git to prepare the
patch by tagging your own repository, and then creating either a
patch series (git-format-patch v1.0..v1.1) or a single big patch
(git-diff v1.0..v1.1). But either way, what would it mean to have a
tag in the patch, since they don't have a tagging system at the
other end?
I'm not really sure what you're trying to accomplish; if you can be more
concrete, we might be able to offer more concrete solutions (or maybe
the answer you were looking for was simply, "you want bundles, not
patches").
-Peff
^ permalink raw reply
* Re: tags and patches
From: Geoff Russell @ 2007-06-14 2:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0706140201400.4059@racer.site>
On 6/14/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 14 Jun 2007, Geoff Russell wrote:
>
> > On 6/13/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > Hi,
> > >
> > > On Wed, 13 Jun 2007, Geoff Russell wrote:
> > >
> > > > Dear gits,
> > >
> > > ;-)
> > >
> > > > [...]
> > > >
> > > > git tag v1.1
> > > > git format-patch v1.0
> > > > cd /tmp/newmyrepo
> > > > git am ~/myrepo/THEPATCHNAME
> > > >
> > > > Where is tag v1.1 ?
> > >
> > > Tags are not propagated with patches. Sorry.
> >
> > Is this considered to be a bug to be eventually fixed or a feature?
>
> AFAIK patches are not supposed to _contain_ patches.
Is this a typo? I expected patches to contain tags, not other patches.
>
> What you want is probably a bundle. You don't want a collection of diffs
> with comments on them, but you want a collection to reacreate the history
> the other side has.
I didn't know about bundles but do now. However "git bundle --help" tells
me "No manual entry for git-bundle" despite
git-bundle.html being in the Documentation directory.
I'm trying to work out if I want to use git to manage a software distribution
problem. I distribute release v1.0 to people then later I want to email them
a patch to take them from v1.0 to v1.1. I can probably live without
the tags, but
am just surprised that patches don't send them.
Cheers,
Geoff
>
> Ciao,
> Dscho
>
>
^ permalink raw reply
* Re: Let me ask again: How do we import patches from non-git sources?
From: Marc Singer @ 2007-06-14 1:49 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Matthieu Moy, Git List
In-Reply-To: <1181153904.12740.35.camel@ld0161-tx32>
On Wed, 2007-06-06 at 13:18 -0500, Jon Loeliger wrote:
> On Wed, 2007-06-06 at 12:58, Matthieu Moy wrote:
>
> > Cogito is more or less depreceted now. You should probably use git
> > itself.
>
> Hmm. We should then likely try to encourage kernel.org and denx.de
> folks to advertise cloning their published repos with git rather
> than cogito now.
It's also users who are *just* getting their feet wet in the git pool.
^ permalink raw reply
* Re: Let me ask again: How do we import patches from non-git sources?
From: Marc Singer @ 2007-06-14 1:45 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
In-Reply-To: <20070612181313.GB26767@fieldses.org>
On Tue, 2007-06-12 at 14:13 -0400, J. Bruce Fields wrote:
> On Tue, Jun 12, 2007 at 09:27:33AM -0700, Marc Singer wrote:
> > git-am complains that it cannot find an email address, but raw patches
> > seldom have these. So, either we could use another command, or it would
> > be handy if we could supply the email address to git-am (or some other
> > data it needs so that it can split the patch.) I suppose the mistaken
> > assumption is that the patch source in an email instead of already being
> > a nice clean patch.
>
> I think it's intentional. You need some standard format git-am can use
> to split out the patches and find the comments and the authorship
> information (for the Author: field on the commit), so why not just use
> something like mbox?
>
> And it could provide some fallback for the "Author:" information in the
> case where it didn't find that, but we wouldn't want that to be the
> default if it meant risking silently losing authorship information. I
> suppose an "--author" option to git-am might be convenient sometimes.
>
> But personally I always just add those headers by hand (or with a
> script). It's not that hard; I the minimum required is just three
> lines, I think:
>
> From git-owner@vger.kernel.org Tue jun 12 11:43:40 2007
> From: someone <someone@example.com>
> Subject: [PATCH] do something
>
> Do something complicated.
>
> ---
>
> diff a/foo b/foo
> ...
>
> And often I need different authors on different patches anyway, so
> git-am --author wouldn't help.
>
> Of course if you've just got one patch to import, you can git-apply and
> then commit.
Thanks for the response.
I found that a deeper look into git-apply gives me a way to import
foreign patches. I still have to do some index management by hand, but
it is much better than the alternative.
Your suggestion, while clearly effective, seems cumbersome. I suppose
it may be worthwhile including a command that converts a foreign patch
into something that git better understands. That would leave out this
sort of complexity from the git-am program. In fact, I can imaging a
tool that lets the user fill in any pieces that aren't already present.
Honestly, it may just be that I'm still below the knee on the learning
curve for git.
Cheers.
^ permalink raw reply
* Re: Stupid quoting...
From: Johannes Schindelin @ 2007-06-14 1:34 UTC (permalink / raw)
To: Steven Grimm; +Cc: David Kastrup, git
In-Reply-To: <467097B6.3030604@midwinter.com>
Hi,
On Wed, 13 Jun 2007, Steven Grimm wrote:
> Johannes Schindelin wrote:
> > Okay, Steven Grimm. How do you think _I_ can tell that Steven is your name
> > from looking at your _full_ name "Steven Grimm"? Huh?
> >
> > Exactly. I split at the space.
>
> At the risk of drawing the conversation way off topic: What's Mary Ann
> Summers' first name? (Hint: It's not "Mary.")
The first first name _is_ Mary. Maybe it is not the name you shout when
calling her.
But that is irrelevant. The names of Mary Ann Summers are separated by
spaces. Period.
Ciao,
Dscho
^ permalink raw reply
* Re: Stupid quoting...
From: Steven Grimm @ 2007-06-14 1:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: David Kastrup, git
In-Reply-To: <Pine.LNX.4.64.0706140211070.4059@racer.site>
Johannes Schindelin wrote:
> Okay, Steven Grimm. How do you think _I_ can tell that Steven is your name
> from looking at your _full_ name "Steven Grimm"? Huh?
>
> Exactly. I split at the space.
>
>
At the risk of drawing the conversation way off topic: What's Mary Ann
Summers' first name? (Hint: It's not "Mary.")
-Steve
^ permalink raw reply
* Re: Stupid quoting...
From: Johannes Schindelin @ 2007-06-14 1:12 UTC (permalink / raw)
To: Steven Grimm; +Cc: David Kastrup, git
In-Reply-To: <4670948B.7070407@midwinter.com>
Hi,
On Wed, 13 Jun 2007, Steven Grimm wrote:
> Johannes Schindelin wrote:
> > The recommended way is not using spaces to begin with. I mean, does "David"
> > contain spaces? People seem not to see the problem, and fail to blame
> > Microsoft for all the damage they have done, introducing that stupid,
> > stupid concept of filenames containing spaces, and _enforcing_ it.
> >
>
> To be fair, Microsoft did not invent the concept of filenames with spaces.
I didn't say that, did I?
They _forced_ the use onto the world. That's what I was complaining about.
> Even UNIX has, I believe, always allowed them, though you risked running
> into buggy scripts misbehaving if you used them. And really, filenames
> with spaces are only a nuisance in a text-based command line scripting
> environment, and only then because someone early on decided to use space
> rather than some other metacharacter as the only available delimiter
> between command arguments in scripts.
Okay, Steven Grimm. How do you think _I_ can tell that Steven is your name
from looking at your _full_ name "Steven Grimm"? Huh?
Exactly. I split at the space.
Ciao,
Dscho
^ 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