* Re: [PATCH] git-svn: respect Subversion's [auth] section configuration values
From: Eric Wong @ 2007-10-07 21:43 UTC (permalink / raw)
To: Eygene Ryabinkin; +Cc: Sam Vilain, git
In-Reply-To: <20071007101437.GB3943@void.codelabs.ru>
Eygene Ryabinkin <rea-git@codelabs.ru> wrote:
> Eric, Sam, good day.
> Sun, Oct 07, 2007 at 02:24:43PM +1300, Sam Vilain wrote:
> > Eygene Ryabinkin wrote:
> > > Parameters 'store-passwords' and 'store-auth-creds' from Subversion's
> > > configuration (~/.subversion/config) were not respected. This was
> > > fixed: the default values for these parameters are set to 'yes' to
> > > follow Subversion behaviour.
> > >
> >
> > I saw this in the svn api before. It really is a strange API, requiring
> > the user to get things like this right.
>
> Yes, the need to parse the configuration and set some flags is
> rather strange. Looks like nobody cared to stuff the code like
> I had added to the configuration file parsing routines.
I think I started to look at it a while back and forgot about it :)
> > You can use no warnings 'once';
>
> Great, thanks for the pointer! Eric, do you want me to produce
> another patch or you'll correct mine?
Go ahead and produce another patch. I haven't had much time to
work on git lately.
--
Eric Wong
^ permalink raw reply
* Re: Trying to use git-filter-branch to compress history by removing large, obsolete binary files
From: Frank Lichtenheld @ 2007-10-07 21:38 UTC (permalink / raw)
To: Elijah Newren; +Cc: git
In-Reply-To: <51419b2c0710071423y1b194f22gb6ccaa57303029d1@mail.gmail.com>
On Sun, Oct 07, 2007 at 03:23:59PM -0600, Elijah Newren wrote:
> The following set of instructions will duplicate my problem with a
> smaller repo; why is the local git repository bigger after running
> git-filter-branch rather than smaller as I'd expect? I'm probably
> missing something obvious, but I have no idea what it is.
The usual suspect would be the reflog.
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: Status of kha/experimental
From: Karl Hasselström @ 2007-10-07 21:33 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Yann Dirson, David Kågedal, Git Mailing List
In-Reply-To: <b0943d9e0710071418o6a664981i9d31db980c04bc50@mail.gmail.com>
On 2007-10-07 22:18:44 +0100, Catalin Marinas wrote:
> How stable is the kha/experimental branch? Since there are more and
> more bugs added to the tracking system, I'll have to start looking
> at them before a 0.14 release. Is it worth merging the
> kha/experimental now or we better wait for after 0.14?
The idea is that experimental contains changes that need testing, but
may not yet be ready for your master. (They are generally safe,
though; I run StGit from my experimental branch at work, for example.)
When I decide that they are ready, I move them to safe. If there are
any patches you feel should be in safe rather than experimental, just
ask. Or you could just take them directly from experimental without
asking, of course. :-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [PATCH] git-gui: offer a list of recent repositories on startup
From: Steffen Prohaska @ 2007-10-07 21:28 UTC (permalink / raw)
To: spearce; +Cc: git, msysgit, Steffen Prohaska
If git-gui is started outside a work tree the repository
chooser will offer a list of recently opend repositories.
Clicking on an entry directly opens the repository.
The list of recently opened repositories is stored in the
config as gui.recentrepos. If the list grows beyond 10
entries it will be truncated.
Note, only repositories that are opened through the
repository chooser will get added to the recent list.
Repositories opened from the shell will not yet be added.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
git-gui/lib/choose_repository.tcl | 47 +++++++++++++++++++++++++++++++++++++
1 files changed, 47 insertions(+), 0 deletions(-)
The commit is also available on branch
steffen/git-gui-openrecent in 4msysgit.
Shawn,
I'd suggest to reduce the number of clicks needed to open or
clone an existing directory that is not in the list of
recent repositories. First choosing from the radiobuttons
and then clicking next is one click to much. There are no
options to combine. Choosing from the list should
immediately trigger the action.
We could either put 'Create/Clone/Open New Repository' into
the Repository menu and only present the recent repository
list. Or we could offer push buttons for the other actions.
Steffen
diff --git a/git-gui/lib/choose_repository.tcl b/git-gui/lib/choose_repository.tcl
index 16bf67c..bfc8780 100644
--- a/git-gui/lib/choose_repository.tcl
+++ b/git-gui/lib/choose_repository.tcl
@@ -116,9 +116,26 @@ constructor pick {} {
-text [mc "Open Existing Repository"] \
-variable @action \
-value open
+ label $w_body.space
+ label $w_body.recentlabel \
+ -anchor w \
+ -text "Select Recent Repository:"
+ listbox $w_body.recentlist \
+ -relief flat \
+ -width 50 \
+ -height 10 \
+ -exportselection false \
+ -selectmode select
+ foreach p [_get_recentrepos] {
+ $w_body.recentlist insert end $p
+ }
+ bind $w_body.recentlist <<ListboxSelect>> [cb _open_recent]
pack $w_body.new -anchor w -fill x
pack $w_body.clone -anchor w -fill x
pack $w_body.open -anchor w -fill x
+ pack $w_body.space -anchor w -fill x
+ pack $w_body.recentlabel -anchor w -fill x
+ pack $w_body.recentlist -anchor w -fill x
pack $w_body -fill x -padx 10 -pady 10
frame $w.buttons
@@ -171,6 +188,34 @@ method _invoke_next {} {
}
}
+proc _get_recentrepos {} {
+ set recent [list]
+ foreach p [get_config gui.recentrepos] {
+ if {[file isdirectory [file join $p .git]]} {
+ lappend recent $p
+ }
+ }
+ return [lsort $recent]
+}
+
+proc _append_recentrepos {path} {
+ set recent [get_config gui.recentrepos]
+ if {[lsearch $recent $path] < 0} {
+ lappend recent $path
+ }
+ if {[llength $recent] > 10} {
+ set recent [lrange $recent 1 end]
+ }
+ regsub -all "\[{}\]" $recent {"} recent
+ git config --global gui.recentrepos $recent
+}
+
+method _open_recent {} {
+ set id [$w_body.recentlist curselection]
+ set local_path [$w_body.recentlist get $id]
+ _do_open2 $this
+}
+
method _next {} {
destroy $w_body
_do_$action $this
@@ -893,6 +938,8 @@ method _do_open2 {} {
return
}
+ _append_recentrepos $local_path
+
set ::_gitdir .git
set ::_prefix {}
set done 1
--
1.5.3.mingw.1.110.gef4c8
^ permalink raw reply related
* Trying to use git-filter-branch to compress history by removing large, obsolete binary files
From: Elijah Newren @ 2007-10-07 21:23 UTC (permalink / raw)
To: git
Hi,
I'm using git-cvsimport to import some CVS repos, which unfortunately
included dozens of large regression test output files in their ancient
history...some of which measure hundreds of megabytes in size. I'd
like to prune them out of the git history (I don't have access to
prune them out of the CVS history), but I'm running into problems.
The following set of instructions will duplicate my problem with a
smaller repo; why is the local git repository bigger after running
git-filter-branch rather than smaller as I'd expect? I'm probably
missing something obvious, but I have no idea what it is.
The steps:
# Make a small repo
mkdir test
cd test
git init
echo hi > there
git add there
git commit -m 'Small repo'
# Add a random 10M binary file
dd if=/dev/urandom of=testme.txt count=10 bs=1M
git add testme.txt
git commit -m 'Add big binary file'
# Remove the 10M binary file
git rm testme.txt
git commit -m 'Remove big binary file'
# Compress the repo, see how big the repo is
git gc --aggressive --prune
du -ks . # 10548K
du -ks .git # 10532K
# Try to rewrite history to remove the binary file
git-filter-branch --tree-filter 'rm -f testme.txt' HEAD
git reset --hard
# Try to recompress and clean up, then check the new size
git gc --aggressive --prune
du -ks . # 10580K !?!?!?
du -ks .git # 10564K
Thanks,
Elijah
^ permalink raw reply
* Status of kha/experimental
From: Catalin Marinas @ 2007-10-07 21:18 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Yann Dirson, David Kågedal, Git Mailing List
Hi Karl,
How stable is the kha/experimental branch? Since there are more and
more bugs added to the tracking system, I'll have to start looking at
them before a 0.14 release. Is it worth merging the kha/experimental
now or we better wait for after 0.14?
Thanks.
--
Catalin
^ permalink raw reply
* Re: [PATCH] Support tags in uncommit - use git_id instead of rev_parse
From: Catalin Marinas @ 2007-10-07 21:06 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1191447892.31052.5.camel@dv>
On 03/10/2007, Pavel Roskin <proski@gnu.org> wrote:
> On Wed, 2007-10-03 at 21:35 +0100, Catalin Marinas wrote:
>
> > Without this patch, the 'stg uncommit -t patch' fails with 'Unknown
> > revision: patch'. With the patch applied, it still fails but with
> > 'Commit ... does not have exactly one parent'. I don't say that the
> > first one is good but I don't think the latter is clearer. The 'stg
> > uncommit --help' states that the '--to' option takes a commit argument
> > but if one passes a patch name the error message gets pretty
> > confusing.
>
> Actually, 'Commit ... does not have exactly one parent' means that stg
> misinterpreted the patch name as some non-existing hash and started
> iterating back until it hit the first merge.
>
> Perhaps stgit should make sure that the hash is valid before walking the
> commit tree. If it's not, stgit could provide a better message.
OK, I applied your patch but I'll have to look into the error message
to make it more meaningful. Thanks.
--
Catalin
^ permalink raw reply
* Re: [StGIT PATCH] Better diagnostic for wrong branch configuration.
From: Catalin Marinas @ 2007-10-07 21:04 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <20071005204452.30902.60246.stgit@gandelf.nowhere.earth>
On 05/10/2007, Yann Dirson <ydirson@altern.org> wrote:
> If the branch.*.merge parameter does not name a valid remote head,
> stgit would not rebase after a fetch, and would write instead
> 'Rebasing to "None" ... done'.
Applied, thanks. I'll try it tomorrow with my StGIT over SVN
configuration as well (it works OK with the latter patches).
--
Catalin
^ permalink raw reply
* [PATCH] makefile: Add a cscope target
From: Kristof Provost @ 2007-10-07 20:45 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: git, Alex Riesen
In-Reply-To: <20071006142442.GA4635@luggage>
The current makefile supports ctags but not cscope. Some people prefer
cscope (I do), so this patch adds a cscope target.
Signed-off-by: Kristof Provost <Kristof@provost-engineering.be>
---
This version of the patch includes the fix for the missing [ Frank spotted,
and adds 'cscope*' to the .gitignore list as Alex suggested.
While I did that I noticed that 'tags' and 'TAGS' were also missing.
It's also in the (hopefully) right format. Thank to Johannes Schindelin
for pointing out my mistakes.
.gitignore | 3 +++
Makefile | 8 ++++++--
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/.gitignore b/.gitignore
index e0b91be..62afef2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -171,3 +171,6 @@ config.status
config.mak.autogen
config.mak.append
configure
+tags
+TAGS
+cscope*
diff --git a/Makefile b/Makefile
index 8db4dbe..e2790c8 100644
--- a/Makefile
+++ b/Makefile
@@ -947,6 +947,10 @@ tags:
$(RM) tags
$(FIND) . -name '*.[hcS]' -print | xargs ctags -a
+cscope:
+ $(RM) cscope*
+ $(FIND) . -name '*.[hcS]' -print | xargs cscope -b
+
### Detect prefix changes
TRACK_CFLAGS = $(subst ','\'',$(ALL_CFLAGS)):\
$(bindir_SQ):$(gitexecdir_SQ):$(template_dir_SQ):$(prefix_SQ)
@@ -1093,7 +1097,7 @@ clean:
$(LIB_FILE) $(XDIFF_LIB)
$(RM) $(ALL_PROGRAMS) $(BUILT_INS) git$X
$(RM) $(TEST_PROGRAMS)
- $(RM) *.spec *.pyc *.pyo */*.pyc */*.pyo common-cmds.h TAGS tags
+ $(RM) *.spec *.pyc *.pyo */*.pyc */*.pyo common-cmds.h TAGS tags cscope*
$(RM) -r autom4te.cache
$(RM) configure config.log config.mak.autogen config.mak.append config.status config.cache
$(RM) -r $(GIT_TARNAME) .doc-tmp-dir
@@ -1111,7 +1115,7 @@ endif
$(RM) GIT-VERSION-FILE GIT-CFLAGS GIT-GUI-VARS
.PHONY: all install clean strip
-.PHONY: .FORCE-GIT-VERSION-FILE TAGS tags .FORCE-GIT-CFLAGS
+.PHONY: .FORCE-GIT-VERSION-FILE TAGS tags cscope .FORCE-GIT-CFLAGS
### Check documentation
#
--
1.5.3.4.207.g1aae
^ permalink raw reply related
* Re: How to pick a commit from another git tree?
From: Alex Riesen @ 2007-10-07 20:10 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: git
In-Reply-To: <000101c80907$d461a810$04ac10ac@Jocke>
Joakim Tjernlund, Sun, Oct 07, 2007 19:31:00 +0200:
> This is probably a somewhat stupid question but I havn't had a need until now so here goes:
> There is a commit in David Millers tree:
> http://git.kernel.org/?p=linux/kernel/git/davem/bak-net-2.6.24.git;a=commit;h=bbb4c0c35a4c2aed5e025b668c8dfc99c5b74cff
> that hasn't made it into 2.6.23, but will go into 2.6.24.
> I need this fix on top of 2.6.23(once it is released).
$ git fetch git://git.kernel.org/pub/scm/linux/kernel/git/davem/bak-net-2.6.24.git
$ git cherry-pick bbb4c0c35a4c2aed5e025b668c8dfc99c5b74cff
> Now I wonder how to best add this fix to my tree. Once this fix hits linus tree and I pull
> linus tree, I don't wan't a conflict as I already have this fix in my tree.
Depending on the state the Davids tree ends up when it is merge into
Linus' tree you may or may not get a conflict. It is not in your hands
either way.
> Should I just pull Davids tree? Or should I cherry-pick this one commit?
> Or something else?
I would just cherry-pick it, and revert it (or hard-reset my tree to
Linus' tree) if it conflicts later.
^ permalink raw reply
* Re: [PATCH 1/4] git-gui i18n: Add more words to glossary.
From: Christian Stimming @ 2007-10-07 20:42 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, git
In-Reply-To: <20071007180559.GA2137@spearce.org>
Am Sonntag, 7. Oktober 2007 20:05 schrieb Shawn O. Pearce:
> Christian Stimming <stimming@tuhh.de> wrote:
> > Signed-off-by: Christian Stimming <stimming@tuhh.de>
> >
> > ---
> > po/glossary/git-gui-glossary.pot | 12 ++++++++++--
> > po/glossary/git-gui-glossary.txt | 2 ++
> > 2 files changed, 12 insertions(+), 2 deletions(-)
>
> What version is this series applied to? It rejects against my
> currently published master on repo.or.cz.
It rejects? The patch were intended against master on git-gui.git on
repo.or.cz; the base for the patches was
1952aa1d5735ccbedd832620e43db3e03fc77088
I might have messed up some line wrappings... if that is the case, I can of
course resend and try harder to send them correctly.
Christian
^ permalink raw reply
* Re: Many gits are offline this week
From: Randal L. Schwartz @ 2007-10-07 19:37 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Paolo Ciarrocchi, git
In-Reply-To: <20071007170153.GX2137@spearce.org>
>>>>> "Shawn" == Shawn O Pearce <spearce@spearce.org> writes:
Shawn> What, no mention of git-gui as a porcelain? It has more users
Shawn> than qgit according to the survey. Maybe rephrase the porcelains
Shawn> on slide 15 as:
Shawn> Other porcelain exists:
Shawn> - StGit ("stacked git"), guilt
Shawn> - tig (curses-based viewer)
Shawn> - qgit, git-gui
git-gui should have been mentioned with "the git distro". Fixed.
Shawn> On slide 26 you say "gitk mytopic origin" shows the changes back to
Shawn> the common ancestor. That's what "gitk mytopic...origin" would do.
Shawn> Note the three dots instead of the space. The space will cause
Shawn> gitk to show all history back to the beginning of time.
Darned inconsistency! Sometimes, it's a space. Sometimes it's two dots.
Sometimes, it's three dots. I know, there's reasons for that, but it's still
hard for the newbie.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: Many gits are offline this week
From: Daniel Barkalow @ 2007-10-07 19:04 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Randal L. Schwartz, Paolo Ciarrocchi, git
In-Reply-To: <20071007170153.GX2137@spearce.org>
On Sun, 7 Oct 2007, Shawn O. Pearce wrote:
> "Randal L. Schwartz" <merlyn@stonehenge.com> wrote:
> > >>>>> "Paolo" == Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> writes:
> >
> > Paolo> is there any material (slides, docs) you can share before the talks?
> >
> > I've had the slides reviewed by Smarter People Than Me on #git already, so
> > hopefully most of it is accurate. :) They're temporarily at
> >
> > http://www.stonehenge.com/pic/Git-2.0.3-to-be.pdf
> >
> > I still hope to have a few hours to go in and add a few sadly missing
> > graphics, particularly on the rebase vs merge section.
>
> What, no mention of git-gui as a porcelain? It has more users
> than qgit according to the survey. Maybe rephrase the porcelains
> on slide 15 as:
>
> Other porcelain exists:
> - StGit ("stacked git"), guilt
> - tig (curses-based viewer)
> - qgit, git-gui
For that matter, gitweb is essentially a limited porcelain. And this
points out that all VCSes have alternative porcelains, but git is unusual
in having convenient plumbing to support and encourage this.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Missing tags from git-clone, but not git-clone -l ?
From: Gerald (Jerry) Carter @ 2007-10-07 18:58 UTC (permalink / raw)
To: git
In-Reply-To: <4709242F.7070004@samba.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Gerald (Jerry) Carter wrote:
> I'm really a but stumped on this one. I've got a set of tags
> (created by git-svnimport):
>
> $ git tag -l release-4*
> release-4-0-0tp1
> release-4-0-0tp2
> release-4-0-0tp3
> release-4-0-0tp4
>
> but when I "git-clone samba-svnimport tags-test"", one tag
> is missing.
>
> $ git tag -l release-4*
> release-4-0-0tp2
> release-4-0-0tp3
> release-4-0-0tp4
>
> Running git-clone -l works as expected (i.e. the tp1 tag appears
> in the clone).
Sorry. I did get confused. And I now understand what happened.
git-clone works correctly. What I did was "git-remote add svn
/.../path" followed by a "git-fetch svn". Looks like that
one tag was not directly reachable in the history. Running
"git-fetch -t svn" gave me the missing tags.
Sorry for the noise.
cheers, jerry
=====================================================================
Samba ------- http://www.samba.org
Centeris ----------- http://www.centeris.com
"What man is a man who does not make the world better?" --Balian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHCSxvIR7qMdg1EfYRAldVAJ4ns/X3JDrBnTft6JDEL5e8Tv80agCgvb59
/odKKLNtH2E1zB83pHg3Qdc=
=KkBD
-----END PGP SIGNATURE-----
^ permalink raw reply
* Missing tags from git-clone, but not git-clone -l ?
From: Gerald (Jerry) Carter @ 2007-10-07 18:23 UTC (permalink / raw)
To: git
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
I'm really a but stumped on this one. I've got a set of tags
(created by git-svnimport):
$ git tag -l release-4*
release-4-0-0tp1
release-4-0-0tp2
release-4-0-0tp3
release-4-0-0tp4
but when I "git-clone samba-svnimport tags-test"", one tag
is missing.
$ git tag -l release-4*
release-4-0-0tp2
release-4-0-0tp3
release-4-0-0tp4
Running git-clone -l works as expected (i.e. the tp1 tag appears
in the clone).
Here's some more info about the tag in the original svnimport
repo:
$ ls -l .git/refs/tags/
total 0
$ grep release-4 .git/packed-refs
2fbd67786af06b8f5184048d997b660cbd80cbc4 refs/tags/release-4-0-0tp1
a786f423d6dee793418e8c6591f9b962c0fa96bc refs/tags/release-4-0-0tp2
1fea21bffc836a28e3e86e930d3d9fca85590ae6 refs/tags/release-4-0-0tp3
c58417a9934d3c1f04becb542a9fb6334a07f19d refs/tags/release-4-0-0tp4
$ for h in `grep release-4 .git/packed-refs | awk '{print $1}'`; \
do git-cat-file -t $h; done
tag
tag
tag
tag
Any suggestions on how to debug this? Am I just misunderstanding
something about tags?
cheers, jerry
=====================================================================
Samba ------- http://www.samba.org
Centeris ----------- http://www.centeris.com
"What man is a man who does not make the world better?" --Balian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHCSQvIR7qMdg1EfYRAhOIAKDpefcPqyVhPfxTazJhtd/QrmzM8QCgyyQc
e0Br/1PngGmQlGNkME+tY7c=
=+PIn
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] Make strbuf_cmp inline, constify its arguments and optimize it a bit
From: Johannes Schindelin @ 2007-10-07 18:25 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: Pierre Habouzit, Alex Riesen, git, Junio C Hamano
In-Reply-To: <20071007191821.c872cc51.tihirvon@gmail.com>
Hi,
On Sun, 7 Oct 2007, Timo Hirvonen wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > On Sun, 7 Oct 2007, Pierre Habouzit wrote:
> >
> > > On Sun, Oct 07, 2007 at 02:24:25PM +0000, Timo Hirvonen wrote:
> > >
> > > > strbuf->buf is always non-NULL and NUL-terminated so you could just do
> > > >
> > > > static inline int strbuf_cmp(const struct strbuf *a, const struct strbuf *b)
> > > > {
> > > > int len = a->len < b->len ? a->len : b->len;
> > > > return memcmp(a->buf, b->buf, len + 1);
> > > > }
> > >
> > > doesn't work, because a buffer can have (in some very specific cases)
> > > an embeded NUL.
> >
> > But it should work. The function memcmp() could not care less if there is
> > a NUL or not, it just compares until it finds a difference.
>
> Almost. If a is "hello\0world" and b is "hello" then it would compare 6
> characters from both and think the strings are equal.
Good point.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/4] git-gui i18n: Add more words to glossary.
From: Shawn O. Pearce @ 2007-10-07 18:05 UTC (permalink / raw)
To: Christian Stimming; +Cc: Johannes Schindelin, git
In-Reply-To: <200710052239.02492.stimming@tuhh.de>
Christian Stimming <stimming@tuhh.de> wrote:
> Signed-off-by: Christian Stimming <stimming@tuhh.de>
>
> ---
> po/glossary/git-gui-glossary.pot | 12 ++++++++++--
> po/glossary/git-gui-glossary.txt | 2 ++
> 2 files changed, 12 insertions(+), 2 deletions(-)
What version is this series applied to? It rejects against my
currently published master on repo.or.cz.
--
Shawn.
^ permalink raw reply
* Re: How to pick a commit from another git tree?
From: Pierre Habouzit @ 2007-10-07 17:50 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: git
In-Reply-To: <000101c80907$d461a810$04ac10ac@Jocke>
[-- Attachment #1: Type: text/plain, Size: 1395 bytes --]
On Sun, Oct 07, 2007 at 05:31:00PM +0000, Joakim Tjernlund wrote:
> Hi
>
> This is probably a somewhat stupid question but I havn't had a need until now so here goes:
> There is a commit in David Millers tree:
> http://git.kernel.org/?p=linux/kernel/git/davem/bak-net-2.6.24.git;a=commit;h=bbb4c0c35a4c2aed5e025b668c8dfc99c5b74cff
> that hasn't made it into 2.6.23, but will go into 2.6.24.
> I need this fix on top of 2.6.23(once it is released).
> Now I wonder how to best add this fix to my tree. Once this fix hits linus tree and I pull
> linus tree, I don't wan't a conflict as I already have this fix in my tree.
>
> Should I just pull Davids tree? Or should I cherry-pick this one commit?
> Or something else?
The easiest way is to fetch his tree (git remote add ...; git fetch)
and then yes, cherry-pick the commit(s) you need.
If you need more than one commit, you can use:
git rebase --onto <your tip> fromCommit toCommit
and it will move ]fromCommit..toCommit] onto <your tip>
It's likely that the fetch will be quite cheap as I suppose that David
Millers tree as very few objects different from linus tree (compared to
the linux2.6 git repository size I mean).
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* How to pick a commit from another git tree?
From: Joakim Tjernlund @ 2007-10-07 17:31 UTC (permalink / raw)
To: git
Hi
This is probably a somewhat stupid question but I havn't had a need until now so here goes:
There is a commit in David Millers tree:
http://git.kernel.org/?p=linux/kernel/git/davem/bak-net-2.6.24.git;a=commit;h=bbb4c0c35a4c2aed5e025b668c8dfc99c5b74cff
that hasn't made it into 2.6.23, but will go into 2.6.24.
I need this fix on top of 2.6.23(once it is released).
Now I wonder how to best add this fix to my tree. Once this fix hits linus tree and I pull
linus tree, I don't wan't a conflict as I already have this fix in my tree.
Should I just pull Davids tree? Or should I cherry-pick this one commit?
Or something else?
Jocke
^ permalink raw reply
* Re: [PATCH] git-gui: try to locate git in same directory as git-gui (on Windows)
From: Shawn O. Pearce @ 2007-10-07 17:10 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <11916634041243-git-send-email-prohaska@zib.de>
Steffen Prohaska <prohaska@zib.de> wrote:
> This commit adds another guess where git might be located.
> After searching PATH the last fallback is the directory
> in which git-gui is installed. This is a good guess for
> a sane installation.
Thanks.
--
Shawn.
^ permalink raw reply
* Re: Many gits are offline this week
From: Shawn O. Pearce @ 2007-10-07 17:01 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Paolo Ciarrocchi, git
In-Reply-To: <86tzp54sez.fsf@blue.stonehenge.com>
"Randal L. Schwartz" <merlyn@stonehenge.com> wrote:
> >>>>> "Paolo" == Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> writes:
>
> Paolo> is there any material (slides, docs) you can share before the talks?
>
> I've had the slides reviewed by Smarter People Than Me on #git already, so
> hopefully most of it is accurate. :) They're temporarily at
>
> http://www.stonehenge.com/pic/Git-2.0.3-to-be.pdf
>
> I still hope to have a few hours to go in and add a few sadly missing
> graphics, particularly on the rebase vs merge section.
What, no mention of git-gui as a porcelain? It has more users
than qgit according to the survey. Maybe rephrase the porcelains
on slide 15 as:
Other porcelain exists:
- StGit ("stacked git"), guilt
- tig (curses-based viewer)
- qgit, git-gui
On slide 26 you say "gitk mytopic origin" shows the changes back to
the common ancestor. That's what "gitk mytopic...origin" would do.
Note the three dots instead of the space. The space will cause
gitk to show all history back to the beginning of time.
On slide 27 you say that you can rebase your changes on upstream
using "git-rebase origin/master master". That's a lot more
typing than is required, most people will want to rebase their
current branch onto the upstream and thus will use "git-rebase
origin/master". Personally I think combining git-checkout's branch
switch feature into git-rebase is stupid. It really makes things
confusing. But its supported. :-(
--
Shawn.
^ permalink raw reply
* Re: [ALTERNATE PATCH] Add a simple option parser.
From: Pierre Habouzit @ 2007-10-07 17:01 UTC (permalink / raw)
To: Kristian Høgsberg, git, Junio C Hamano
In-Reply-To: <20071005142507.GL19879@artemis.corp>
[-- Attachment #1: Type: text/plain, Size: 339 bytes --]
FWIW this patch has some issues with long options parsing, I have a
fix, but am trying to migrate more builtins to this parser to see how
well it behaves.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Make strbuf_cmp inline, constify its arguments and optimize it a bit
From: Pierre Habouzit @ 2007-10-07 16:54 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Timo Hirvonen, Alex Riesen, git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0710071710190.4174@racer.site>
[-- Attachment #1: Type: text/plain, Size: 1082 bytes --]
On Sun, Oct 07, 2007 at 04:11:29PM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 7 Oct 2007, Pierre Habouzit wrote:
>
> > On Sun, Oct 07, 2007 at 02:24:25PM +0000, Timo Hirvonen wrote:
> >
> > > strbuf->buf is always non-NULL and NUL-terminated so you could just do
> > >
> > > static inline int strbuf_cmp(const struct strbuf *a, const struct strbuf *b)
> > > {
> > > int len = a->len < b->len ? a->len : b->len;
> > > return memcmp(a->buf, b->buf, len + 1);
> > > }
> >
> > doesn't work, because a buffer can have (in some very specific cases)
> > an embeded NUL.
>
> But it should work. The function memcmp() could not care less if there is
> a NUL or not, it just compares until it finds a difference.
not if your one of your strbuf has as prefix, the other followed by
'\0', then anything else (including nothing ;p).
Your test would yield equality.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] Have a filter_start/filter_end API.
From: Pierre Habouzit @ 2007-10-07 16:52 UTC (permalink / raw)
To: Alex Riesen; +Cc: Linus Torvalds, Junio C Hamano, git
In-Reply-To: <20071007160707.GA3270@steel.home>
[-- Attachment #1: Type: text/plain, Size: 3367 bytes --]
On Sun, Oct 07, 2007 at 04:07:07PM +0000, Alex Riesen wrote:
> Pierre Habouzit, Sun, Oct 07, 2007 16:53:55 +0200:
> > On Sat, Oct 06, 2007 at 09:06:21AM +0000, Alex Riesen wrote:
> > > If you continue to insist the code is generic enough to justify its
> > > residence in strbuf.c, continue reading.
> > >
> > > First off, what was wrong with dumb
> > >
> > > void strbuf_make_room(struct strbuf *, size_t newsize);
> > >
> > > again?
> >
> > If newsize is >= sb->alloc then the area is reallocated, the pointer
> > may move, and the "src" pointer would then be invalidated.
>
> So what? You already _have_ to know it points inside the strbuf, so
> you can't expect it to be valid after any serious strbuf operation.
Then you can't write a filter, because you need to reallocate the
buffer before even starting to read the input buffer sometimes. If you
reallocate the strbuf, and that your original buffer was in there, you
lose.
> > The idea is to have a unified API to deal with both the cases where
> > the filtering is known not to work in place by the caller, or for the
> > cases where it could if enough space is allocated but that a realloc is
> > needed.
>
> this just makes it convoluted and opaque (as in "not transparent")
I'm totally open to better alternatives. We could probably easily get
rid of strbuf_end_filter, as whichever way to deal with the issue I try
to solve in a better way, in the end, it will always be just a "free".
So, maybe there is a way to rename strbuf_start_filter so that it's
more straightforward. The way to use the API is:
@ char *to_free = NULL;
@ if ((src is inside dst && need_realloc) || operation is not in-place)
@ to_free = strbuf_detach(dst, NULL);
@ strbuf_make_room(dst, needed_size);
// do whatever you want with src and dst
free(to_free);
strbuf_start_filter tries to implement the block marked with `@'. Of
course:
* need_realloc == (needed_size >= dst->alloc)
* src is inside dst means:
src > dst->buf && src < dst->buf + dst->alloc
Though, those are both things that I find ugly to "know" in convert.c.
How things are allocated in strbufs is one of the few things we don't
want to assume anywhere outside of the strbuf module.
> > > It is for the first "if", for example. free() wont free the buf in sb.
> > > Oh, right, one can check if returned pointer !NULL. Which just adds
> > > more code to handle your API.
> >
> > I don't get that part. free(NULL) is totally ok.
>
> Not that. One have to store the result of start_filter and check it
Why check it ? You don't have to check. You have to keep it until
you're done with "src". Whichever the result was. The return of
strbuf_start_filter intends to stash a pointer to be freed for the cases
where "src" points into the destination buffer.
> > Note that I did not created this semantics, it was how convert.c
> > worked already, in a even more convoluted way before.
>
> And why shouldn't these semantics kept to convert.c?
I missed where having this live in convert.c rather than in strbuf.c
makes it less ugly or better in any sense.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] setup/rev-parse: allow HEAD to be spelled 'head'
From: Johannes Schindelin @ 2007-10-07 16:49 UTC (permalink / raw)
To: Sam Vilain; +Cc: Alex Riesen, git
In-Reply-To: <47080AC4.3040902@catalyst.net.nz>
Hi,
On Sun, 7 Oct 2007, Sam Vilain wrote:
> Alex Riesen wrote:
> > Sam Vilain, Fri, Oct 05, 2007 05:09:10 +0200:
> >> If the repository got mangled by FAT capitalization rules, then a ref
> >> such as "HEAD" will become "head" once it is back on a non-FAT FS.
> >> Check for this condition in resolve_refs and in the setup code.
> >>
> >> Suggested-by: Francois Marier <francois@debian.org>
> >> Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
> >> ---
> >> This should probably help people putting their git repos on
> >> FAT USB sticks.
> >
> > Can the people just mount FAT partitions with shortname=mixed?
>
> Of course, that is probably a solution to the problem, whereas my patch
> is a workaround.
>
> Now, I realise that this might open a can of worms ... would we also
> want to go looking for files called "pack-ab~1.pac" ?
Hell, no.
> Almost certainly not - but this solves the most immediate problem
> experienced by people putting their git repositories onto FAT
> filesystems mounted with the default options, which will say "FATAL: not
> a git repository" otherwise.
You certainly mean the issue of capitalization; yes, that is my
experience, too. Somehow, "HEAD" is the culprit.
Ciao,
Dscho
P.S.: seems you have quite cute coworkers.
^ 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