* Re: What's cooking in git.git (Dec 2008, #04; Mon, 29)
From: Jakub Narebski @ 2008-12-30 23:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vocyt1is2.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> with '-' are only in 'pu' while commits prefixed with '+' are
> in 'next'. The ones marked with '.' do not appear in any of the branches,
> but I am still holding onto them.
>
> The topics list the commits in reverse chronological order. The topics
> meant to be merged to the maintenance series have "maint-" in their names.
>
> ----------------------------------------------------------------
> [Actively cooking]
>
> * mk/gitweb-feature (Mon Dec 15 22:16:19 2008 -0800) 1 commit
> - gitweb: unify boolean feature subroutines
Nice thing from what I remember (I assume it is last incantation?).
> * jn/gitweb-blame (Thu Dec 11 01:33:29 2008 +0100) 3 commits
> - gitweb: cache $parent_commit info in git_blame()
> - gitweb: A bit of code cleanup in git_blame()
> - gitweb: Move 'lineno' id from link to row element in git_blame
>
> Jakub seemed to feel they are not yet ready.
This is, I think, ready. It is incremental AJAX-y blame in gitweb
that is not yet ready; this is simple cleanup and performance
improvement.
> * sc/gitweb-category (Fri Dec 12 00:45:12 2008 +0100) 3 commits
> - gitweb: Optional grouping of projects by category
> - gitweb: Split git_project_list_body in two functions
> - gitweb: Modularized git_get_project_description to be more generic
I think this needs a bit more cooking; with one more commit I think
you can have categories within requested sort order, and not always
sorted alphabetically.
> * gb/gitweb-patch (Thu Dec 18 08:13:19 2008 +0100) 4 commits
> - gitweb: link to patch(es) view in commit(diff) and (short)log view
> - gitweb: add patches view
> - gitweb: change call pattern for git_commitdiff
> - gitweb: add patch view
I think it is ready, or almost ready. I'll try to review this series
within a week. Feel free to prod me if I forget.
P.S. BTW. what is the status on using parse_options among git
commands?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Why can't git pull --rebase work if there are modified files?
From: Thomas Rast @ 2008-12-30 23:09 UTC (permalink / raw)
To: skillzero; +Cc: git
In-Reply-To: <2729632a0812301340y735c3946weee55c9856d4e6a9@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2219 bytes --]
skillzero@gmail.com wrote:
> If I have locally modified files and I try to 'git pull --rebase', it
> fails because of the locally modified files. If I don't use the
> --rebase option, it works (but generates a merge commit if I have
> local commits). Why does rebasing require an unmodified checkout? It
> seems like it should only stop if I something in the newly fetched
> changes conflict with my local changes.
First you need to be aware that 'git pull --rebase' is conceptually
the same as 'git fetch && git rebase upstream', where 'upstream' is
the remote branch tracked by your current branch. (The canonical
choice is upstream=origin/foo for a branch foo.) git-fetch is of no
further interest to the discussion, as it does not touch the working
tree in any way.
git-rebase is not concerned with "newly fetched changes". It
*rewinds* your branch to the updated 'upstream' tip, and then
*rebuilds* your commits on top of that. This involves a lot of
resetting and applying patches, which appears to be why it enforces a
clean working tree.
You can use git-stash (see the man page) to temporarily save away your
uncommitted changes, however. Maybe you could even write a patch to
git-rebase that lets it automatically save and restore uncommitted
changes?
> I almost always have modified files in my checkout for things I'm
> working on. I also often have a commit or two that haven't been pushed
> because I'm waiting until I get to a good point before pushing. If I
> do 'git pull', I end up with a merge commit each time. That's why I
> want to use --rebase, but for it to work, I have to git stash, then
> rebase then git stash pop.
You could probably improve your workflow a lot by using topic
branches. See the recently added gitworkflows manpage, also available
at
http://www.kernel.org/pub/software/scm/git-core/docs/gitworkflows.html
or, e.g., Tv's excellent introduction to git called "Version Control
for Du^H^HDevelopers":
http://eagain.net/blog/2008/08/11/ep-talk-videos.html
(Pretty much the second half is about branch workflows, topic branches
are explicitly introduced at ~44:15.)
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: is there an easier way to do this ?
From: Jakub Narebski @ 2008-12-30 23:03 UTC (permalink / raw)
To: Zorba; +Cc: git
In-Reply-To: <gjc52u$ehc$4@ger.gmane.org>
"Zorba" <cr@altmore.co.uk> writes:
> ok, now I'm in this for real, archiving versions of our website project (5k
> files approx)
>
> so here is the workflow:
>
> - copy version 1 files into GIT dir
>
> - open git bash
>
> $ git init
>
> $ git add .
>
> $ git commit -m "version1"
>
> all vanilla ? cool
> next job = store version 2 [...]
Check out contrib/fast-import/import-tars.perl
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: gitweb $export_ok question
From: Jakub Narebski @ 2008-12-30 23:02 UTC (permalink / raw)
To: Thomas Amsler; +Cc: git@vger.kernel.org
In-Reply-To: <m3sko5b84t.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> in the GITWEB_CONFIG file (usually gitweb_config.perl, installed
> in the same place as gitweb.cgi) [...]
I'm sorry, I forgot about GITWEB_CONFIG_SYSTEM which as you
wrote is by default /etc/gitweb.conf (and is also Perl).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* RE: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]
From: Conor Rafferty @ 2008-12-30 22:55 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: git
Whoa there Stevey, I'm a windows user, don't forget
I mighta had a chance at following this 10-12 years ago when last I did
some scripting, but not now
Its very generous of you to go to all this bother and I'm mighty
grateful.
However if this is what its gonna take to get what I want, then Im'
outta here.
Getting a snapshot on the filesystem, in terms of a directory tree (not
a reference to, representation of etc etc. but a real life directory
tree, files and folders that you can actually interact with - build,
edit etc.), of a past version is a basic operation in my book.
Even in clearcase this was a cinch.
Is there anyone who can see anyway to do this simply, without a script,
without creating a branch ?
Personally I suspect "$ git checkout <version> ." is what should be
doing this (I have confidence in saying this because it seems to want to
do this, and does it right at least half the time). But no-one wants to
admit to the remotest possibility that it might be off ....
In any case, a bunch of smart guys like you should be able to knock this
functionality together in hours, if you put your mind to it.
I know you guys have put a lot into this project and for many of you it
defines who you are
- but if you want ppl out there in the user world to take this stuff on,
its gotta work for them
<END>impassioned plea</>
-----Original Message-----
From: Boyd Stephen Smith Jr. [mailto:bss@iguanasuicide.net]
Sent: 30 December 2008 22:17
To: Conor Rafferty
Cc: git@vger.kernel.org
Subject: Re: for newbs = little exercise / tutorial / warmup for windows
and other non-sophisticated new Git users :-) [Scanned]
On Tuesday 2008 December 30 15:49:22 Boyd Stephen Smith Jr. wrote:
> On Tuesday 2008 December 30 15:27:33 you wrote:
> > conorr@KINKLADZE /w/GITPLATFORM/swproj $ git status # On branch
> > master nothing to commit (working directory clean)
> >
> > conorr@KINKLADZE /w/GITPLATFORM/swproj $ git checkout versionA .
> >
> > conorr@KINKLADZE /w/GITPLATFORM/swproj $ ls ABC.txt AC.txt
> >
> > conorr@KINKLADZE /w/GITPLATFORM/swproj $ rm *.*
> >
> > conorr@KINKLADZE /w/GITPLATFORM/swproj $ git checkout versionB .
> >
> > conorr@KINKLADZE /w/GITPLATFORM/swproj $ ls ABC.txt AC.txt BC.txt
>
> Not a bug. git checkout <commit> <paths> does not delete files by
design.
> Try using "git checkout versionB" instead (no paths specified), and it
> will properly remove AC.txt from your working tree as well as warning
> you that "You're Doing It Wrong" (tm).
This may be what you want:
(commands)
mkdir test && cd test && git init &&
echo 'ABC' > ABC.txt && echo 'AC' > AC.txt && echo 'BC' > BC.txt && echo
'C' > C.txt &&
find -name '*C*' -print0 | xargs -r0 -- git add -- && git commit -m '"C"
files.' && git branch versionC master &&
git checkout -b versionA master &&
find -type f -not -wholename '*.git*' -not -name '*A*' -print0 | \
xargs -r0 -- git rm -- &&
git commit -m 'Removed non-"A" files.' &&
git checkout -b versionB &&
find -type f -not -wholename '*.git*' -not -name '*B*' -print0 | \
xargs -r0 -- git rm -- &&
git commit -m 'Removed non-"B" files.' &&
git checkout -b versionD master &&
find -type f -not -wholename '*.git*' -not -name '*D*' -print0 | \
xargs -r0 -- git rm -- && git commit -m 'Removed non-"D" files.'
&&
git checkout master && git branch -v --abbrev=4 && ls -l && git checkout
versionA && ls -l && git checkout versionB && ls -l && git checkout
versionC && ls -l && git checkout versionD && ls -l
(output)
/home/bss/test
Initialized empty Git repository in /home/bss/test/.git/ Created initial
commit 8dbf3a1: All files.
4 files changed, 4 insertions(+), 0 deletions(-) create mode 100644
ABC.txt create mode 100644 AC.txt create mode 100644 BC.txt create
mode 100644 C.txt Switched to a new branch "versionA"
rm 'BC.txt'
rm 'C.txt'
Created commit a06e10c: Removed non-"A" files.
2 files changed, 0 insertions(+), 2 deletions(-) delete mode 100644
BC.txt delete mode 100644 C.txt Switched to a new branch "versionB"
rm 'AC.txt'
Created commit 2029ca2: Removed non-"B" files.
1 files changed, 0 insertions(+), 1 deletions(-) delete mode 100644
AC.txt Switched to a new branch "versionD"
rm 'ABC.txt'
rm 'AC.txt'
rm 'BC.txt'
rm 'C.txt'
Created commit 1793ba0: Removed non-"D" files.
4 files changed, 0 insertions(+), 4 deletions(-) delete mode 100644
ABC.txt delete mode 100644 AC.txt delete mode 100644 BC.txt delete
mode 100644 C.txt Switched to branch "master"
* master 8dbf "C" files.
versionA a06e Removed non-"A" files.
versionB 2029 Removed non-"B" files.
versionC 8dbf "C" files.
versionD 1793 Removed non-"D" files.
total 16
-rw-r--r-- 1 bss users 4 2008-12-30 16:10 ABC.txt
-rw-r--r-- 1 bss users 3 2008-12-30 16:10 AC.txt
-rw-r--r-- 1 bss users 3 2008-12-30 16:10 BC.txt
-rw-r--r-- 1 bss users 2 2008-12-30 16:10 C.txt Switched to branch
"versionA"
total 8
-rw-r--r-- 1 bss users 4 2008-12-30 16:10 ABC.txt
-rw-r--r-- 1 bss users 3 2008-12-30 16:10 AC.txt Switched to branch
"versionB"
total 4
-rw-r--r-- 1 bss users 4 2008-12-30 16:10 ABC.txt Switched to branch
"versionC"
total 16
-rw-r--r-- 1 bss users 4 2008-12-30 16:10 ABC.txt
-rw-r--r-- 1 bss users 3 2008-12-30 16:10 AC.txt
-rw-r--r-- 1 bss users 3 2008-12-30 16:10 BC.txt
-rw-r--r-- 1 bss users 2 2008-12-30 16:10 C.txt Switched to branch
"versionD"
total 0
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
^ permalink raw reply
* Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-)
From: Boyd Stephen Smith Jr. @ 2008-12-30 22:39 UTC (permalink / raw)
To: Zorba; +Cc: git
In-Reply-To: <200812301617.15496.bss@iguanasuicide.net>
[-- Attachment #1: Type: text/plain, Size: 544 bytes --]
On Tuesday 2008 December 30 16:17:11 Boyd Stephen Smith Jr. wrote:
> git checkout -b versionB &&
Should be:
git checkout -b versionB master &&
to match the other section and fix this part of the output:
> Switched to branch "versionB"
> total 4
> -rw-r--r-- 1 bss users 4 2008-12-30 16:10 ABC.txt
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: gitweb $export_ok question
From: Jakub Narebski @ 2008-12-30 22:37 UTC (permalink / raw)
To: Thomas Amsler; +Cc: git@vger.kernel.org
In-Reply-To: <9B3762519053E645820D9CEBD18B3734023A9FBA00@XEDAMAIL2.ex.ad3.ucdavis.edu>
Thomas Amsler <tpamsler@ucdavis.edu> writes:
> Hello,
>
> I am trying to get the gitweb $export_ok to work. According the
> installation instructions:
>
> Alternatively, you can configure gitweb to only list and allow
> viewing of the explicitly exported repositories, via the
> GITWEB_EXPORT_OK build configuration variable (or the $export_ok
> variable in gitweb config file). If it evaluates to true, gitweb
> shows repositories only if this file exists in its object database
> (if directory has the magic file named $export_ok).
>
> ... I set $export_ok = "true" in my /etc/gitweb.conf file.
[...]
$export_ok is not a boolean, is the _name_ of a file, which if it
is present, then repository is exported to gitweb, and if it is not,
it is invisible to gitweb. It means that if for example we have
$export_ok = "gitweb-export-ok";
in the GITWEB_CONFIG file (usually gitweb_config.perl, installed
in the same place as gitweb.cgi), the repo.git is exported only
if it has file gitweb-export-ok in it.
This mechanism is similar to git-daemon and its magic file
"git-daemon-export-ok".
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* RE: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-) [Scanned]
From: Conor Rafferty @ 2008-12-30 22:36 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: git
I don't understand, sorry. I thought I'd already removed all files from
the local tree, in the $ rm *.* move just above the checkout
-----Original Message-----
From: Boyd Stephen Smith Jr. [mailto:bss@iguanasuicide.net]
Sent: 30 December 2008 21:49
To: Conor Rafferty
Cc: git@vger.kernel.org
Subject: Re: for newbs = little exercise / tutorial / warmup for windows
and other non-sophisticated new Git users :-) [Scanned]
On Tuesday 2008 December 30 15:27:33 you wrote:
> conorr@KINKLADZE /w/GITPLATFORM/swproj $ git status # On branch master
> nothing to commit (working directory clean)
>
> conorr@KINKLADZE /w/GITPLATFORM/swproj $ git checkout versionA .
>
> conorr@KINKLADZE /w/GITPLATFORM/swproj $ ls ABC.txt AC.txt
>
> conorr@KINKLADZE /w/GITPLATFORM/swproj $ rm *.*
>
> conorr@KINKLADZE /w/GITPLATFORM/swproj $ git checkout versionB .
>
> conorr@KINKLADZE /w/GITPLATFORM/swproj $ ls ABC.txt AC.txt BC.txt
Not a bug. git checkout <commit> <paths> does not delete files by
design.
Try using "git checkout versionB" instead (no paths specified), and it
will properly remove AC.txt from your working tree as well as warning
you that "You're Doing It Wrong" (tm).
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
^ permalink raw reply
* Re: Extracting a single commit or object
From: Shawn O. Pearce @ 2008-12-30 22:21 UTC (permalink / raw)
To: yitzhakbg; +Cc: git
In-Reply-To: <21223948.post@talk.nabble.com>
yitzhakbg <yitzhakbg@gmail.com> wrote:
>
> How would I extract a single commit from a repository by it's SHA1 (or any
> other treeish)?
> For that matter, how is any one single object extracted? Examples please.
git cat-file $type $sha1
e.g.
git cat-file commit $commitsha1
git cat-file blob $blobsha1
If you need to inspect a tree, ls-tree is probably better:
git ls-tree $commitsha1
git ls-tree $treesha1
--
Shawn.
^ permalink raw reply
* Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-)
From: Boyd Stephen Smith Jr. @ 2008-12-30 22:17 UTC (permalink / raw)
To: Zorba; +Cc: git
In-Reply-To: <200812301549.26538.bss@iguanasuicide.net>
[-- Attachment #1: Type: text/plain, Size: 4075 bytes --]
On Tuesday 2008 December 30 15:49:22 Boyd Stephen Smith Jr. wrote:
> On Tuesday 2008 December 30 15:27:33 you wrote:
> > conorr@KINKLADZE /w/GITPLATFORM/swproj
> > $ git status
> > # On branch master
> > nothing to commit (working directory clean)
> >
> > conorr@KINKLADZE /w/GITPLATFORM/swproj
> > $ git checkout versionA .
> >
> > conorr@KINKLADZE /w/GITPLATFORM/swproj
> > $ ls
> > ABC.txt AC.txt
> >
> > conorr@KINKLADZE /w/GITPLATFORM/swproj
> > $ rm *.*
> >
> > conorr@KINKLADZE /w/GITPLATFORM/swproj
> > $ git checkout versionB .
> >
> > conorr@KINKLADZE /w/GITPLATFORM/swproj
> > $ ls
> > ABC.txt AC.txt BC.txt
>
> Not a bug. git checkout <commit> <paths> does not delete files by design.
> Try using "git checkout versionB" instead (no paths specified), and it will
> properly remove AC.txt from your working tree as well as warning you
> that "You're Doing It Wrong" (tm).
This may be what you want:
(commands)
mkdir test && cd test && git init &&
echo 'ABC' > ABC.txt && echo 'AC' > AC.txt &&
echo 'BC' > BC.txt && echo 'C' > C.txt &&
find -name '*C*' -print0 | xargs -r0 -- git add -- &&
git commit -m '"C" files.' && git branch versionC master &&
git checkout -b versionA master &&
find -type f -not -wholename '*.git*' -not -name '*A*' -print0 | \
xargs -r0 -- git rm -- &&
git commit -m 'Removed non-"A" files.' &&
git checkout -b versionB &&
find -type f -not -wholename '*.git*' -not -name '*B*' -print0 | \
xargs -r0 -- git rm -- &&
git commit -m 'Removed non-"B" files.' &&
git checkout -b versionD master &&
find -type f -not -wholename '*.git*' -not -name '*D*' -print0 | \
xargs -r0 -- git rm -- && git commit -m 'Removed non-"D" files.' &&
git checkout master && git branch -v --abbrev=4 && ls -l &&
git checkout versionA && ls -l &&
git checkout versionB && ls -l &&
git checkout versionC && ls -l &&
git checkout versionD && ls -l
(output)
/home/bss/test
Initialized empty Git repository in /home/bss/test/.git/
Created initial commit 8dbf3a1: All files.
4 files changed, 4 insertions(+), 0 deletions(-)
create mode 100644 ABC.txt
create mode 100644 AC.txt
create mode 100644 BC.txt
create mode 100644 C.txt
Switched to a new branch "versionA"
rm 'BC.txt'
rm 'C.txt'
Created commit a06e10c: Removed non-"A" files.
2 files changed, 0 insertions(+), 2 deletions(-)
delete mode 100644 BC.txt
delete mode 100644 C.txt
Switched to a new branch "versionB"
rm 'AC.txt'
Created commit 2029ca2: Removed non-"B" files.
1 files changed, 0 insertions(+), 1 deletions(-)
delete mode 100644 AC.txt
Switched to a new branch "versionD"
rm 'ABC.txt'
rm 'AC.txt'
rm 'BC.txt'
rm 'C.txt'
Created commit 1793ba0: Removed non-"D" files.
4 files changed, 0 insertions(+), 4 deletions(-)
delete mode 100644 ABC.txt
delete mode 100644 AC.txt
delete mode 100644 BC.txt
delete mode 100644 C.txt
Switched to branch "master"
* master 8dbf "C" files.
versionA a06e Removed non-"A" files.
versionB 2029 Removed non-"B" files.
versionC 8dbf "C" files.
versionD 1793 Removed non-"D" files.
total 16
-rw-r--r-- 1 bss users 4 2008-12-30 16:10 ABC.txt
-rw-r--r-- 1 bss users 3 2008-12-30 16:10 AC.txt
-rw-r--r-- 1 bss users 3 2008-12-30 16:10 BC.txt
-rw-r--r-- 1 bss users 2 2008-12-30 16:10 C.txt
Switched to branch "versionA"
total 8
-rw-r--r-- 1 bss users 4 2008-12-30 16:10 ABC.txt
-rw-r--r-- 1 bss users 3 2008-12-30 16:10 AC.txt
Switched to branch "versionB"
total 4
-rw-r--r-- 1 bss users 4 2008-12-30 16:10 ABC.txt
Switched to branch "versionC"
total 16
-rw-r--r-- 1 bss users 4 2008-12-30 16:10 ABC.txt
-rw-r--r-- 1 bss users 3 2008-12-30 16:10 AC.txt
-rw-r--r-- 1 bss users 3 2008-12-30 16:10 BC.txt
-rw-r--r-- 1 bss users 2 2008-12-30 16:10 C.txt
Switched to branch "versionD"
total 0
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Extracting a single commit or object
From: yitzhakbg @ 2008-12-30 22:15 UTC (permalink / raw)
To: git
How would I extract a single commit from a repository by it's SHA1 (or any
other treeish)?
For that matter, how is any one single object extracted? Examples please.
Thanks,
YBG
--
View this message in context: http://www.nabble.com/Extracting-a-single-commit-or-object-tp21223948p21223948.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-)
From: Jeff Whiteside @ 2008-12-30 22:03 UTC (permalink / raw)
To: Zorba; +Cc: git
In-Reply-To: <gje4ff$ip6$4@ger.gmane.org>
>> good news, use "git checkout versionA", not "git checkout versionA ."
>> (so, use it wihtout the dot), and you should be back in working order.
>
> ** yes but I don't get the files copied out into the tree which is all my
> little heart ever desired
you dont "get the files copied out into the tree"... i have zero idea
what that means wihtout punctuation and context, but i'm pretty sure
that you want to do a "git checkout versionA", not "git checkout
versionA .". if i'm wrong, then maybe try a git clean?
> But you're right - chances of using are slim - but you could say that about
> every version sitting in any given SCM repo.
> Thats why we have SCM, and why we insure our cars etc etc. :-)
i punish myself for saying what i did. shame on me. you're totally right.
^ permalink raw reply
* Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-)
From: Boyd Stephen Smith Jr. @ 2008-12-30 21:49 UTC (permalink / raw)
To: Zorba; +Cc: git
In-Reply-To: <gje3ok$gnc$4@ger.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]
On Tuesday 2008 December 30 15:27:33 you wrote:
> conorr@KINKLADZE /w/GITPLATFORM/swproj
> $ git status
> # On branch master
> nothing to commit (working directory clean)
>
> conorr@KINKLADZE /w/GITPLATFORM/swproj
> $ git checkout versionA .
>
> conorr@KINKLADZE /w/GITPLATFORM/swproj
> $ ls
> ABC.txt AC.txt
>
> conorr@KINKLADZE /w/GITPLATFORM/swproj
> $ rm *.*
>
> conorr@KINKLADZE /w/GITPLATFORM/swproj
> $ git checkout versionB .
>
> conorr@KINKLADZE /w/GITPLATFORM/swproj
> $ ls
> ABC.txt AC.txt BC.txt
Not a bug. git checkout <commit> <paths> does not delete files by design.
Try using "git checkout versionB" instead (no paths specified), and it will
properly remove AC.txt from your working tree as well as warning you
that "You're Doing It Wrong" (tm).
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git-ls-files -l
From: Jakub Narebski @ 2008-12-30 21:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: jidanni, git
In-Reply-To: <alpine.LFD.2.00.0812301226110.3082@localhost.localdomain>
On Tue, 30 Dec 2008, Linus Torvalds wrote:
> On Tue, 30 Dec 2008, Jakub Narebski wrote:
> >
> > I think it would be easy to add '-l' also to git-ls-files. Please
> > remember to provide size only for blobs, as provoding size for trees
> > would make it harder to change to future packv4, where tree objects
> > would be stored deconstructed.
>
> Personally, more than "git ls-files -l", I've occasionally wanted a real
> "git ls" that really looks more like "ls". That includes:
>
> - turning a list of files in a subdirectory into a "directory" entry
> (which is not very natural for "git ls-files" as an index operation,
> since the index is fundamentally flat).
>
> - yes, adding "-l" as an option, but really showing the stat information.
> Right now, you can do "git ls-files --stage", and it will show a kind
> of extended information, but while it shows the mode, it doesn't show
> the owner/timestamp/etc parts of the index, and those are sometimes
> interesting.
Good idea.
I guess we could put shortened sha-1 of object in place of owner and
group info which is not present in index, and perhaps stage number
instead of number of hard links. I wonder a bit about formatting
timestamps, if to follow "ls -l" format there...
> Btw, the "ls-tree -l" format is not nice. Don't use it as a basis
> to pattern "ls -l" (or if you want to just extend ls-tree, whatever).
Well, "ls-tree -l" is just "ls-tree" with size added. You would
probably want to use "git ls-tree -l --abbrev" instead for human
consumption.
--
Jakub Narebski
Poland
^ permalink raw reply
* Why can't git pull --rebase work if there are modified files?
From: skillzero @ 2008-12-30 21:40 UTC (permalink / raw)
To: git
If I have locally modified files and I try to 'git pull --rebase', it
fails because of the locally modified files. If I don't use the
--rebase option, it works (but generates a merge commit if I have
local commits). Why does rebasing require an unmodified checkout? It
seems like it should only stop if I something in the newly fetched
changes conflict with my local changes.
I almost always have modified files in my checkout for things I'm
working on. I also often have a commit or two that haven't been pushed
because I'm waiting until I get to a good point before pushing. If I
do 'git pull', I end up with a merge commit each time. That's why I
want to use --rebase, but for it to work, I have to git stash, then
rebase then git stash pop.
^ permalink raw reply
* Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-)
From: Zorba @ 2008-12-30 21:39 UTC (permalink / raw)
To: git
In-Reply-To: <3ab397d0812301035w3dcd872fkae9509629a0ed7de@mail.gmail.com>
Thnks for reviewing !
"Jeff Whiteside" <jeff.m.whiteside@gmail.com> wrote in message
news:3ab397d0812301035w3dcd872fkae9509629a0ed7de@mail.gmail.com...
>> commit -a detects that files have been deleted, and takes them out of the
>> index !
>> could also have used $ git rm <specific files> and then $ git commit ..
>
> hey! i like your changes! the post is pretty polished now. the only
> thing else i would change (srysry), is the above. "-a detects that
> files have been deleted" -> heh, not true. you don't need -a here;
> it does something else.
** haven't had time to review this but from what you say it looks like I
forgot to take this out
> okay i just recreated your repo and did the same thing. with your
> syntax "git checkout versionA ." i got the same result, and i'm not
> sure why, but i think it was because of the detached head.
** at Yves' (demerphq) request I reproduced and posted the exact sequence of
commands
this was from a reboot, going straight into git bash and running the warmup
with NO git-resets at all
> good news, use "git checkout versionA", not "git checkout versionA ."
> (so, use it wihtout the dot), and you should be back in working order.
** yes but I don't get the files copied out into the tree which is all my
little heart ever desired
> the other (good?) news is that you probably _do_ want to be using git
> reset --hard in your case, because you're trying to build up a history
> from some project, so you do want to erase some faulty commits after
> you bodge something or miss some files.
** yes, now I know that git-reset is only for destruction, not navigation
> the bad news is that my opinion is that you should probably move on
> with your life, because my own past tells me that you'll never
> actually use those old project versions, hahah :p
** LOL, I have to admit I am enjoying this though, even if its driving me
slightly potty - haha
I didn't write these early versions so I just wanna have them around to
rollback to if I end up hacking the thing to bits.
But you're right - chances of using are slim - but you could say that about
every version sitting in any given SCM repo.
Thats why we have SCM, and why we insure our cars etc etc. :-)
^ permalink raw reply
* Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-)
From: Zorba @ 2008-12-30 21:27 UTC (permalink / raw)
To: git
In-Reply-To: <gjdmm6$9oj$4@ger.gmane.org>
** REPRODUCING Possible bug
rebooted PC, opened a new git bash, and started from scratch - see console
output below
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Welcome to Git (version 1.6.0.2-preview20080923)
Run 'git help git' to display the help index.
Run 'git help <command>' to display help for specific commands.
conorr@KINKLADZE /w/GITPLATFORM
$ mkdir swproj
conorr@KINKLADZE /w/GITPLATFORM
$ cd swproj
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ cat > ABC.txt
ABC
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ cat > BC.txt
BC
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ cat > AC.txt
AC
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ cat > C.txt
C
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ ls
ABC.txt AC.txt BC.txt C.txt
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git init
Initialized empty Git repository in w:/GITPLATFORM/swproj/.git/
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git add *a*.txt
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git commit -m "version A"
Created initial commit 2b88490: version A
2 files changed, 2 insertions(+), 0 deletions(-)
create mode 100644 ABC.txt
create mode 100644 AC.txt
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git tag versionA 2b88
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git rm AC.txt
rm 'AC.txt'
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git add BC.txt
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# deleted: AC.txt
# new file: BC.txt
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# C.txt
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git commit -m "version B"
Created commit c1e1cf8: version B
2 files changed, 1 insertions(+), 1 deletions(-)
delete mode 100644 AC.txt
create mode 100644 BC.txt
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git tag versionB c1e1
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git add *c*.txt
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git commit -m "version C"
Created commit 66c62fd: version C
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 C.txt
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git tag versionC 66c6
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ rm *.*
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ ls
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git commit -a -m "version D"
Created commit eee4a13: version D
3 files changed, 0 insertions(+), 3 deletions(-)
delete mode 100644 ABC.txt
delete mode 100644 BC.txt
delete mode 100644 C.txt
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git tag versionD eee4
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git status
# On branch master
nothing to commit (working directory clean)
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git checkout versionA .
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ ls
ABC.txt AC.txt
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ rm *.*
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git checkout versionB .
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ ls
ABC.txt AC.txt BC.txt
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ rm *.*
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git checkout versionC .
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ ls
ABC.txt AC.txt BC.txt C.txt
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ rm *.*
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ git checkout versionD .
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ ls
ABC.txt AC.txt BC.txt C.txt
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ gitk
conorr@KINKLADZE /w/GITPLATFORM/swproj
$ comment: gitk shows that versionA & C are correct, but B & D are wrong
^ permalink raw reply
* Re: [PATCH v3] Add a commit.signoff configuration option to always use --signoff in commit
From: Junio C Hamano @ 2008-12-30 21:04 UTC (permalink / raw)
To: Adeodato Simó; +Cc: git
In-Reply-To: <1230549405-10000-1-git-send-email-dato@net.com.org.es>
Adeodato Simó <dato@net.com.org.es> writes:
> diff --git a/builtin-revert.c b/builtin-revert.c
> index d48313c..395c7a5 100644
> --- a/builtin-revert.c
> +++ b/builtin-revert.c
> @@ -429,6 +429,8 @@ static int revert_or_cherry_pick(int argc, const char **argv)
> args[i++] = "-n";
> if (signoff)
> args[i++] = "-s";
> + else
> + args[i++] = "--no-signoff";
> if (!edit) {
> args[i++] = "-F";
> args[i++] = defmsg;
Introduction of --no-commit to "git commit" is absolutely necessary for
interactive users if we were to introduce commit.signoff, but I am not
sure about this change and similar ones given to the other Porcelain
commands that use "git commit". They actually started making me think
that commmit.signoff might be more trouble than it is worth.
It is plausible that your workflow is to have others push to your 'mob'
branch and integrating good bits from there by cherry-picking, sort of
like using the 'mob' branch as if they are e-mailed patches. In such a
setup, if you are so forgetful to type "-s" for your commit that you would
want commit.signoff configuration, you would likely to be equally
forgetful to type "-s" for your cherry-pick, and would want to have some
configuration affect how this part of the code works.
I however moderately doubt if the complexity and flexibility of having
rebase.signoff, revert.signoff, and cherry-pick.signoff as independent
options is worth it. I am inclined to think that is too many knobs to
tweak, and it is far simpler to understand and easier to explain if the
single configuration, commit.signoff, applied to every Porcelain that
creates commits.
If we were to go that route, instead of passing --no-signoff when they
invoke "git commit", these commands need to take their own --no-signoff
option instead, and when neither --signoff nor --no-signoff is given, they
just should just invoke "git commit" and let it use the config (if set).
^ permalink raw reply
* What's in git.git (Dec 2008, #04; Mon, 29)
From: Junio C Hamano @ 2008-12-30 21:03 UTC (permalink / raw)
To: git
This is the last installment of "What's in" series of the year 2008.
Enjoy a happy new year break, everybody.
* The 'maint' branch has these fixes since v1.6.1.
Adeodato Simó (2):
git-shortlog.txt: improve documentation about .mailmap files
git-send-email.txt: move --format-patch paragraph to a proper location
Devin Doucette (1):
gitweb: Fix export check in git_get_projects_list
Junio C Hamano (1):
Prepare for v1.6.1.1 maintenance release
René Scharfe (7):
daemon: handle freopen() failure
daemon: cleanup: replace loop with if
daemon: cleanup: factor out xstrdup_tolower()
merge-file: handle freopen() failure
pretty: factor out skip_empty_lines()
pretty: factor out format_subject()
pretty: support multiline subjects with format:
Shawn O. Pearce (1):
describe: Avoid unnecessary warning when using --all
jidanni@jidanni.org (1):
Documentation/diff-options.txt: unify options
* The 'master' branch has these since the last announcement
in addition to the above.
Johannes Schindelin (1):
Force t5302 to use a single thread
Junio C Hamano (2):
Document "git-reset --merge"
Start 1.6.2 cycle
Linus Torvalds (1):
Add 'merge' mode to 'git reset'
Nicolas Pitre (2):
autodetect number of CPUs by default when using threads
pack-objects: don't use too many threads with few objects
Teemu Likonen (2):
Fix the building of user-manual.texi and gitman.texi documents
Fix the building of gitman.info document
^ permalink raw reply
* [PATCH v3] builtin-shortlog.c: use string_list_append(), and don't strdup unnecessarily
From: Adeodato Simó @ 2008-12-30 21:01 UTC (permalink / raw)
To: git, gitster; +Cc: Johannes Schindelin, Adeodato Simó
In-Reply-To: <1230668722-26394-1-git-send-email-dato@net.com.org.es>
Make insert_one_record() use string_list_append(), instead of duplicating
its code. Because of this, do not free the "util" member when clearing the
"onelines" string lists: with the new code path it is not initialized to
any value (was being initialized to NULL previously).
Also, avoid unnecessary strdup() calls when inserting names in log->list.
This list always has "strdup_strings" activated, hence strdup'ing namebuf is
unnecessary. This change also removes a latent memory leak in the old code.
NB: The duplicated code mentioned above predated the appearance of
string_list_append().
Signed-off-by: Adeodato Simó <dato@net.com.org.es>
---
Now with the obvious mistake in the log fixed, apologies. (s/cleanup in//)
builtin-shortlog.c | 19 +++----------------
1 files changed, 3 insertions(+), 16 deletions(-)
diff --git a/builtin-shortlog.c b/builtin-shortlog.c
index d03f14f..90e76ae 100644
--- a/builtin-shortlog.c
+++ b/builtin-shortlog.c
@@ -36,7 +36,6 @@ static void insert_one_record(struct shortlog *log,
const char *dot3 = log->common_repo_prefix;
char *buffer, *p;
struct string_list_item *item;
- struct string_list *onelines;
char namebuf[1024];
size_t len;
const char *eol;
@@ -68,12 +67,9 @@ static void insert_one_record(struct shortlog *log,
snprintf(namebuf + len, room, " %.*s", maillen, boemail);
}
- buffer = xstrdup(namebuf);
- item = string_list_insert(buffer, &log->list);
+ item = string_list_insert(namebuf, &log->list);
if (item->util == NULL)
item->util = xcalloc(1, sizeof(struct string_list));
- else
- free(buffer);
/* Skip any leading whitespace, including any blank lines. */
while (*oneline && isspace(*oneline))
@@ -104,16 +100,7 @@ static void insert_one_record(struct shortlog *log,
}
}
- onelines = item->util;
- if (onelines->nr >= onelines->alloc) {
- onelines->alloc = alloc_nr(onelines->nr);
- onelines->items = xrealloc(onelines->items,
- onelines->alloc
- * sizeof(struct string_list_item));
- }
-
- onelines->items[onelines->nr].util = NULL;
- onelines->items[onelines->nr++].string = buffer;
+ string_list_append(buffer, item->util);
}
static void read_from_stdin(struct shortlog *log)
@@ -323,7 +310,7 @@ void shortlog_output(struct shortlog *log)
}
onelines->strdup_strings = 1;
- string_list_clear(onelines, 1);
+ string_list_clear(onelines, 0);
free(onelines);
log->list.items[i].util = NULL;
}
--
1.6.1.307.g07803
^ permalink raw reply related
* What's cooking in git.git (Dec 2008, #04; Mon, 29)
From: Junio C Hamano @ 2008-12-30 20:59 UTC (permalink / raw)
To: git
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'. The ones marked with '.' do not appear in any of the branches,
but I am still holding onto them.
The topics list the commits in reverse chronological order. The topics
meant to be merged to the maintenance series have "maint-" in their names.
----------------------------------------------------------------
[New Topics]
* nd/grep-assume-unchanged (Sat Dec 27 15:21:03 2008 +0700) 2 commits
- grep: grep cache entries if they are "assume unchanged"
- grep: support --no-ext-grep to test builtin grep
* rs/diff-ihc (Sun Dec 28 19:45:32 2008 +0100) 1 commit
+ diff: add option to show context between close hunks
* as/maint-shortlog-cleanup (Wed Dec 24 17:34:44 2008 +0100) 2 commits
- builtin-shortlog.c: do not unnecessarily strdup before insertion
in list
- builtin-shortlog.c: use string_list_append() instead of
duplicating its code
* js/maint-merge-recursive-r-d-conflict (Mon Dec 22 23:10:20 2008 +0100) 1 commit
+ merge-recursive: mark rename/delete conflict as unmerged
* kk/maint-http-push (Tue Dec 23 11:31:15 2008 +0300) 1 commit
+ http-push: support full URI in handle_remote_ls_ctx()
* jc/maint-ls-tree (Thu Dec 25 16:54:23 2008 -0800) 1 commit
+ ls-tree: add --full-tree option
* mh/maint-sendmail-cc-doc (Mon Dec 29 00:37:25 2008 +0100) 1 commit
+ doc/git-send-email: mention sendemail.cc config variable
----------------------------------------------------------------
[Stalled and may need help and prodding to go forward]
* wp/add-patch-find (Thu Nov 27 04:08:03 2008 +0000) 3 commits
. In add --patch, Handle K,k,J,j slightly more gracefully.
. Add / command in add --patch
. git-add -i/-p: Change prompt separater from slash to comma
I am still holding onto this earlier topic to add '/' subcommand to allow
finding a hunk with given text, but I'd rather not merge/rebase it on top
of wp/add-p-goto series myself. Waiting for a reroll.
* kb/am-directory (Fri Aug 29 15:27:50 2008 -0700) 1 commit
. git-am: Pass the --directory option through to git-apply
A reroll of this by Simon Schubert triggered a series to fix a parameter
propagation bug, and another reroll to add "git am --directory=path/"
should be much easier now. I am not likely to use the feature myself, so
it is up to intrested volunteers to carry it forward.
* ds/uintmax-config (Mon Nov 3 09:14:28 2008 -0900) 1 commit
- autoconf: Enable threaded delta search when pthreads are supported
This automatically enables threaded delta search code when autoconf
detects pthreads are usable. I haven't heard neither positive nor
negative comments from minority platforms that might be harmed.
* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
+ blame: show "previous" information in --porcelain/--incremental
format
+ git-blame: refactor code to emit "porcelain format" output
This gives Porcelains (like gitweb) the information on the commit _before_
the one that the final blame is laid on, which should save them one
rev-parse to dig further. The line number in the "previous" information
may need refining, and sanity checking code for reference counting may
need to be resurrected before this can move forward.
----------------------------------------------------------------
[Actively cooking]
* mk/gitweb-feature (Mon Dec 15 22:16:19 2008 -0800) 1 commit
- gitweb: unify boolean feature subroutines
* cb/merge-recursive-fix (Mon Dec 15 02:41:24 2008 -0800) 3 commits
+ Merge branch 'cb/maint-merge-recursive-fix' into cb/merge-
recursive-fix
+ merge-recursive: do not clobber untracked working tree garbage
+ modify/delete conflict resolution overwrites untracked file
* cb/maint-merge-recursive-fix (Sun Dec 14 19:40:09 2008 -0800) 2 commits
+ merge-recursive: do not clobber untracked working tree garbage
+ modify/delete conflict resolution overwrites untracked file
* js/notes (Sat Dec 20 13:06:03 2008 +0100) 4 commits
- Add an expensive test for git-notes
- Speed up git notes lookup
- Add a script to edit/inspect notes
- Introduce commit notes
* wp/add-p-goto (Thu Dec 4 10:22:40 2008 +0000) 2 commits
+ Add 'g' command to go to a hunk
+ Add subroutine to display one-line summary of hunks
* jn/gitweb-blame (Thu Dec 11 01:33:29 2008 +0100) 3 commits
- gitweb: cache $parent_commit info in git_blame()
- gitweb: A bit of code cleanup in git_blame()
- gitweb: Move 'lineno' id from link to row element in git_blame
Jakub seemed to feel they are not yet ready.
* mv/um-pdf (Wed Dec 10 23:44:50 2008 +0100) 1 commit
+ Add support for a pdf version of the user manual
I do not have a new enough combination of dblatex and asciidoc myself but
this may help interested people.
* sc/gitweb-category (Fri Dec 12 00:45:12 2008 +0100) 3 commits
- gitweb: Optional grouping of projects by category
- gitweb: Split git_project_list_body in two functions
- gitweb: Modularized git_get_project_description to be more generic
* gb/gitweb-patch (Thu Dec 18 08:13:19 2008 +0100) 4 commits
- gitweb: link to patch(es) view in commit(diff) and (short)log view
- gitweb: add patches view
- gitweb: change call pattern for git_commitdiff
- gitweb: add patch view
----------------------------------------------------------------
[Graduated to "master"]
* js/rebase-i-p (Mon Dec 15 11:05:31 2008 +0100) 2 commits
+ rebase -i -p: Fix --continue after a merge could not be redone
+ Show a failure of rebase -p if the merge had a conflict
* np/auto-thread (Mon Dec 15 20:44:30 2008 +0100) 3 commits
+ Force t5302 to use a single thread
+ pack-objects: don't use too many threads with few objects
+ autodetect number of CPUs by default when using threads
* lt/reset-merge (Wed Dec 3 18:00:12 2008 -0800) 2 commits
+ Document "git-reset --merge"
+ Add 'merge' mode to 'git reset'
----------------------------------------------------------------
[Will merge to "master" soon]
* cb/mergetool (Fri Dec 12 21:48:41 2008 +0000) 4 commits
+ mergetool: Don't keep temporary merge files unless told to
+ mergetool: Add prompt to continue after failing to merge a file
+ Add -y/--no-prompt option to mergetool
+ Fix some tab/space inconsistencies in git-mergetool.sh
I have been waiting for comments from the original author and other
interested parties, but haven't heard anything yet. This tool is on the
fringe from my point of view anyway, so I'll push them out to 'master'
soon. If there is a breakage that annoys real people, we will hear from
them, and we can take it from there.
----------------------------------------------------------------
[On Hold]
* nd/narrow (Sun Nov 30 17:54:38 2008 +0700) 17 commits
- wt-status: show sparse checkout info
- Introduce default sparse patterns (core.defaultsparse)
- checkout: add new options to support sparse checkout
- clone: support sparse checkout with --sparse-checkout option
- unpack_trees(): add support for sparse checkout
- unpack_trees(): keep track of unmerged entries
- Introduce "sparse patterns"
- Merge branch 'master' into nd/narrow
- t2104: touch portability fix
- grep: skip files outside sparse checkout area
- checkout_entry(): CE_NO_CHECKOUT on checked out entries.
- Prevent diff machinery from examining worktree outside sparse
checkout
- ls-files: Add tests for --sparse and friends
- update-index: add --checkout/--no-checkout to update
CE_NO_CHECKOUT bit
- update-index: refactor mark_valid() in preparation for new options
- ls-files: add options to support sparse checkout
- Introduce CE_NO_CHECKOUT bit
Kicked out of 'next' by popular demand (see recent discussion on the
interaction between the checkout area and commands such as "grep").
* jc/clone-symref-2 (Sat Nov 29 23:38:21 2008 -0800) 7 commits
- clone: test the new HEAD detection logic
- Merge commit 'HEAD@{2}' into HEAD
- upload-pack: send the HEAD information
- clone: find the current branch more explicitly
- connect.c::read_extra_info(): find where HEAD points at
- connect.c::read_extra_info(): prepare to receive more than server
capabilities
- get_remote_heads(): refactor code to read "server capabilities"
An attempt to extend the fetch protocol to make the logic to detect where
HEAD on the origin site points to more robust.
* cc/bisect-replace (Mon Nov 24 22:20:30 2008 +0100) 9 commits
- bisect: add "--no-replace" option to bisect without using replace
refs
- rev-list: make it possible to disable replacing using "--no-
bisect-replace"
- bisect: use "--bisect-replace" options when checking merge bases
- merge-base: add "--bisect-replace" option to use fixed up revs
- commit: add "bisect_replace_all" prototype to "commit.h"
- rev-list: add "--bisect-replace" to list revisions with fixed up
history
- Documentation: add "git bisect replace" documentation
- bisect: add test cases for "git bisect replace"
- bisect: add "git bisect replace" subcommand
I think a mechanism like this should be added to replace grafts, but it
should always be enabled for normal revision traversal operation, while
always disabled for object enumeration and transfer operation (iow, fsck,
fetch and push should use the real ancestry information recorded in the
underlying objects, while rev-list, log, etc. should always use the
replaced objects). I have a suspicion that even cat-file could honor it.
* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
- "git push": tellme-more protocol extension
This seems to have a deadlock during communication between the peers.
Someone needs to pick up this topic and resolve the deadlock before it can
continue.
* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
- diff: enable "too large a rename" warning when -M/-C is explicitly
asked for
This would be the right thing to do for command line use,
but gitk will be hit due to tcl/tk's limitation, so I am holding
this back for now.
* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
- git-am --forge: add Signed-off-by: line for the author
- git-am: clean-up Signed-off-by: lines
- stripspace: add --log-clean option to clean up signed-off-by:
lines
- stripspace: use parse_options()
- Add "git am -s" test
- git-am: refactor code to add signed-off-by line for the committer
^ permalink raw reply
* Re: git-ls-files -l
From: Linus Torvalds @ 2008-12-30 20:32 UTC (permalink / raw)
To: Jakub Narebski; +Cc: jidanni, git
In-Reply-To: <m3wsdiaptg.fsf@localhost.localdomain>
On Tue, 30 Dec 2008, Jakub Narebski wrote:
>
> I think it would be easy to add '-l' also to git-ls-files. Please
> remember to provide size only for blobs, as provoding size for trees
> would make it harder to change to future packv4, where tree objects
> would be stored deconstructed.
Personally, more than "git ls-files -l", I've occasionally wanted a real
"git ls" that really looks more like "ls". That includes:
- turning a list of files in a subdirectory into a "directory" entry
(which is not very natural for "git ls-files" as an index operation,
since the index is fundamentally flat).
- yes, adding "-l" as an option, but really showing the stat information.
Right now, you can do "git ls-files --stage", and it will show a kind
of extended information, but while it shows the mode, it doesn't show
the owner/timestamp/etc parts of the index, and those are sometimes
interesting.
Btw, the "ls-tree -l" format is not nice. Don't use it as a basis
to pattern "ls -l" (or if you want to just extend ls-tree, whatever).
Linus
^ permalink raw reply
* [PATCH v2] builtin-shortlog.c: use string_list_append(), and don't strdup unnecessarily
From: Adeodato Simó @ 2008-12-30 20:25 UTC (permalink / raw)
To: git, gitster; +Cc: Johannes Schindelin, Adeodato Simó
In-Reply-To: <alpine.DEB.1.00.0812301319140.30769@pacific.mpi-cbg.de>
Make cleanup in insert_one_record() use string_list_append(), instead of
duplicating its code. Because of this, do not free the "util" member when
clearing the "onelines" string lists: with the new code path it is not
initialized to any value (was being initialized to NULL previously).
Also, avoid unnecessary strdup() calls when inserting names in log->list.
This list always has "strdup_strings" activated, hence strdup'ing namebuf is
unnecessary. This change also removes a latent memory leak in the old code.
NB: The duplicated code mentioned above predated the appearance of
string_list_append().
Signed-off-by: Adeodato Simó <dato@net.com.org.es>
---
> FWIW I like the patch, but would like it even more if the strdup() removal
> was squashed in (with an explanation in the commit message).
Ok, I myself prefer it the other way, but here it is. :-)
builtin-shortlog.c | 19 +++----------------
1 files changed, 3 insertions(+), 16 deletions(-)
diff --git a/builtin-shortlog.c b/builtin-shortlog.c
index d03f14f..90e76ae 100644
--- a/builtin-shortlog.c
+++ b/builtin-shortlog.c
@@ -36,7 +36,6 @@ static void insert_one_record(struct shortlog *log,
const char *dot3 = log->common_repo_prefix;
char *buffer, *p;
struct string_list_item *item;
- struct string_list *onelines;
char namebuf[1024];
size_t len;
const char *eol;
@@ -68,12 +67,9 @@ static void insert_one_record(struct shortlog *log,
snprintf(namebuf + len, room, " %.*s", maillen, boemail);
}
- buffer = xstrdup(namebuf);
- item = string_list_insert(buffer, &log->list);
+ item = string_list_insert(namebuf, &log->list);
if (item->util == NULL)
item->util = xcalloc(1, sizeof(struct string_list));
- else
- free(buffer);
/* Skip any leading whitespace, including any blank lines. */
while (*oneline && isspace(*oneline))
@@ -104,16 +100,7 @@ static void insert_one_record(struct shortlog *log,
}
}
- onelines = item->util;
- if (onelines->nr >= onelines->alloc) {
- onelines->alloc = alloc_nr(onelines->nr);
- onelines->items = xrealloc(onelines->items,
- onelines->alloc
- * sizeof(struct string_list_item));
- }
-
- onelines->items[onelines->nr].util = NULL;
- onelines->items[onelines->nr++].string = buffer;
+ string_list_append(buffer, item->util);
}
static void read_from_stdin(struct shortlog *log)
@@ -323,7 +310,7 @@ void shortlog_output(struct shortlog *log)
}
onelines->strdup_strings = 1;
- string_list_clear(onelines, 1);
+ string_list_clear(onelines, 0);
free(onelines);
log->list.items[i].util = NULL;
}
--
1.6.1.307.g07803
^ permalink raw reply related
* Re: git clone - failing on cygwin with git:// but not with ssh://
From: Joe Casadonte @ 2008-12-30 20:01 UTC (permalink / raw)
To: git
In-Reply-To: <u7i5hy5ti.fsf@terrapin.northbound-train.com>
On 30 Dec 2008, Joe Casadonte wrote:
> Looking for a little help, please. Is this not a legitimate git
> issue? Can anyone at least help me diagnose the issue? Please?
My apologies to the group -- I wasn't really cognizant of the fact
that its only been 3 days since my first email. That has now been
made abundantly clear to me :)
I've been working on getting git working full-bore since the middle of
last week, of which this issue is just part of it, and I'm quickly
running out of time (Jan 5 I have to ditch this and go back to my
normal tasks). All the days are blurring together.....
Anyhow, thanks for *your* patience with me, despite the lack of
manners on my end. A happy & safe New Years to all!
--
Regards,
joe
Joe Casadonte
jcasadonte@northbound-train.com
------------------------------------------------------------------------------
Llama Fresh Farms => http://www.northbound-train.com
Ramblings of a Gay Man => http://www.northbound-train.com/ramblings
Emacs Stuff => http://www.northbound-train.com/emacs.html
Music CD Trading => http://www.northbound-train.com/cdr.html
------------------------------------------------------------------------------
Live Free, that's the message!
------------------------------------------------------------------------------
^ permalink raw reply
* Re: git clone - failing on cygwin with git:// but not with ssh://
From: Junio C Hamano @ 2008-12-30 19:54 UTC (permalink / raw)
To: Joe Casadonte; +Cc: git
In-Reply-To: <u7i5hy5ti.fsf@terrapin.northbound-train.com>
"Joe Casadonte" <jcasadonte@northbound-train.com> writes:
> Looking for a little help, please. Is this not a legitimate git issue? Can
> anyone at least help me diagnose the issue? Please?
I think "git on Cygwin" is as legitimate as git on anything else, but at
the same time my guess is that it is a combination of the fact that
everybody is busy with other things around the end of year , and that
probably there are not many "git on Cygwin" experts monitoring the list to
begin with.
Sorry, I do not work on Cygwin (nor Windows in general). "fatal: read
error (Socket operation on non-socket)" sounds like it is coming from
pkt-line.c::safe_read() on the downloading side (i.e. git-clone).
Googling for that error message seems to indicate that it seems to a
rather common error message on wide variety of programs running on Cygwin.
C.f.
http://www.google.com/search?&q=%22Socket+operation+on+non-socket%22+site%3Acygwin.com
^ 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