* Re: why still no empty directory support in git
From: Johannes Schindelin @ 2008-12-30 12:09 UTC (permalink / raw)
To: Ping Yin; +Cc: Git Mailing List
In-Reply-To: <46dff0320812291942y6aeec941k9394586621e9151b@mail.gmail.com>
Hi,
On Tue, 30 Dec 2008, Ping Yin wrote:
> Yes, i know this topic has been discussed for many times.
We have empty directory support in Git. It works like this: for
directories that you do want to keep, you add an empty .gitignore file.
No problem at all,
Dscho
^ permalink raw reply
* Re: [PATCH] t7500-commit.sh: do not call test_set_editor unnecessarily, it's confusing
From: Johannes Schindelin @ 2008-12-30 12:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Adeodato Simó
In-Reply-To: <7vmyefco11.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 839 bytes --]
Hi,
On Mon, 29 Dec 2008, Junio C Hamano wrote:
> Adeodato Simó <dato@net.com.org.es> writes:
>
> > I was reading this test case, and it took a small bit to figure out
> > the editor was not being used at all. I hope there was no hidden
> > reason for it to be there, and it can go away.
>
> That 'zort' came from 1320857 (builtin-commit: fix --signoff,
> 2007-11-11), and I _think_ it is trying to make sure that presense of
> "-F -" makes the editor not to trigger.
>
> Dscho?
Hmm. Obviously, I failed to document properly why I tested the editor,
but I think it makes sense to assume that -F still triggered an
interactive editor at some stage in the development of builtin commit.
I do not have anything against separating that issue into another test
case, but I am strongly opposed to simply removing it.
Ciao,
Dscho
^ permalink raw reply
* Re: is there an easier way to do this ? [Scanned]
From: Zorba @ 2008-12-30 12:00 UTC (permalink / raw)
To: git
In-Reply-To: <3ab397d0812292132h6ffe7e49o650fbf35588666db@mail.gmail.com>
Hi Jeff,
Thanks for that, and yes, I will be more careful with my postings. There is
already so much traffic on this list, the last thing anyone needs is more
fragmentation.
I'm so chuffed now that I got $ git add -A (don't even need the dot, i read
!) $ git commit !
Thank you !
I was up till 5:30am this morning working on this. Another in a series of
late nights. My partner stuck her head round the door at 4 and at 5 and
looked at me like I've flipped out (gone crazy). I think she's gonna try and
get them to take me away, so I've only got limited time to "get git" :-)
Its exactly what I need for versioning off my project where the file
"portfolio" (i.e. the configuration of the containers) changes every version
(probably the containers change more than content - I know, badly written,
but hey, that's all in the past)
On another note - your name is very resonant of this part of the world
(Northern Ireland) - I'm guessing you're from here or have some roots here ?
"Jeff Whiteside" <jeff.m.whiteside@gmail.com> wrote in message
news:3ab397d0812292132h6ffe7e49o650fbf35588666db@mail.gmail.com...
> you should reply to the original thread, so that you don't create a
> new one. makes it almost impossible to find what you're referencing.
>
> also, don't bother with git-rm. a simple rm is the same thing.
> (committing will notice that this file is gone)
>
> On Mon, Dec 29, 2008 at 8:29 PM, Zorba <cr@altmore.co.uk> wrote:
>> (punches air with fist)
>> yes indeed !
>>
>> sorry, I didn't follow up on the --update flag first time
>>
>> $ git add -A .
>> $ git commit
>>
>> home in a boat!
>>
>> "Jacob Helwig" <jacob.helwig@gmail.com> wrote in message
>> news:8c9a060812292017m600ca246pf8660630d49a7067@mail.gmail.com...
>>> On Mon, Dec 29, 2008 at 20:11, Conor Rafferty
>>> <conor.rafferty@altmore.co.uk> wrote:
>>>> Ah, but what about the files that have been removed from this version ?
>>>> - that's the whole point of doing commit -a, so I don't have to spend
>>>> ages doing diffs to produce a list of files to feed into git-rm
>>>>
>>>> Or have I missed another glarer ?
>>>>
>>>> -----Original Message-----
>>>> From: Jacob Helwig [mailto:jacob.helwig@gmail.com]
>>>> Sent: 30 December 2008 04:01
>>>> To: git@vger.kernel.org
>>>> Cc: Conor Rafferty
>>>> Subject: Re: is there an easier way to do this ? [Scanned]
>>>>
>>>> On Mon, Dec 29, 2008 at 19:51, Zorba <cr@altmore.co.uk> wrote:
>>>>> The manual shows you can SHOW untracked files, but not add them as
>>>>> part of the commit -a jig
>>>>>
>>>>> Seems a bit strange that git-add operates on both exisging and new
>>>>> files when used standalone, but its behaviour changes when
>>>>> encapsulated in commit -a...
>>>>>
>>>>> So, I thought maybe $ git commit -a, then $ git add .
>>>>> but then the files tracked have missed the commit boat they were meant
>>>>
>>>>> to be on, haven't they,
>>>>>
>>>>> hang on -
>>>>> what about
>>>>>
>>>>> $ git add .
>>>>> $ git commit -a
>>>>>
>>>>> I do believe I've cracked it
>>>>> if so, it seems a bit wasteful, 2x adds (one explicti and one embedded
>>>>
>>>>> in -a) ? shame on you linux kernel guys, i'd have expected better :-)
>>>>>
>>>>> "Zorba" <cr@altmore.co.uk> wrote in message
>>>>> news:gjc52u$ehc$4@ger.gmane.org...
>>>>>> 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, so delete version 1 files from GIT dir,
>>>>>> copy in version 2
>>>>>> version2 has different files from 1 - which ones? Out of 5k files
>>>>>> could be 1% = 50 new ones, and same amount removed. Why should I
>>>>>> care, with such a powerful friend as git around, n'est pas?
>>>>>> THIS TIME we are going to be CLEVER and use "-a" flag on commit to
>>>>>> pick up any files that have been REMOVED (or "deleted" in git-speak)
>>>>>>
>>>>>> $ git commit -a -m "version2"
>>>>>>
>>>>>> BUT this does not pick up any new ones that have been added,
>>>>>>
>>>>>> and when we run
>>>>>>
>>>>>> $ git status > ../git_status.txt
>>>>>>
>>>>>> these are referred to as "untracked files"
>>>>>> only problem there are 50 ish
>>>>>> is there not another flag on git commit to treat any untracked file
>>>>>> as a new file ?
>>>>>> (would save me typing or creating a list out of these untracked ones
>>>>>> and feeding them into git add)
>>>>>>
>>>>>> I know, I realise now I should have looked up git-commit in the
>>>>>> manual - in case its not there, pls enlighten me !
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe git" in the
>>>>> body of a message to majordomo@vger.kernel.org More majordomo info at
>>>>> http://vger.kernel.org/majordomo-info.html
>>>>>
>>>>
>>>> If you do an explicit git add, then you don't need the -a on git
>>>> commit,
>>>> since everything you want to commit will already be in the index for
>>>> git
>>>> commit to work with.
>>>>
>>>
>>> See the -A flag for git add (and it's reference to --update). -A will
>>> remove files that have been removed, add untracked, and update ones
>>> that have changed, all in one go.
>>
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
^ permalink raw reply
* Re: many git sites homepages megabytes big
From: Anders Melchiorsen @ 2008-12-30 11:01 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, jidanni, pasky
In-Reply-To: <m31vvqcvzp.fsf@localhost.localdomain>
Jakub Narebski wrote:
> jidanni@jidanni.org writes:
>
>
>> I notice the web interfaces to many git sites are very risky to just
>> click on. E.g., just clicking http://repo.or.cz/ sends megabytes to
>> the users browser. At least the homepage of such sites should be
>> something lighter in weight.
>>
>
> That is a bit of historical artifact. Currently the "index" page for
> gitweb installation is 'projects_list' page with _all_ the projects
> hosted. It is not split into pages, like for example 'log' or 'heads'
> views are; there were some patches for that, but would have to be
> redone as the area changed a bit since. It could have been replaced by
> projects search page...
>
> It is a bit of historical reason.
>
For the specific case of repo.or.cz, I guess that turning on HTTP
compression might help a lot.
Anders.
^ permalink raw reply
* Re: git-ls-files -l
From: Jakub Narebski @ 2008-12-30 11:01 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <87abae6hbn.fsf@jidanni.org>
jidanni@jidanni.org writes:
> Beginners, finding git-ls-files acts like ls,
> are baffled as to why they can't go on to ls -l.
>
> The git-ls-files man page should reveal the secret of how also to see
> file sizes. Perhaps the closest one can get is
> $ git-ls-tree -l --abbrev ...
git-ls-tree has the '-l' option mimicking (somewhat) "ls -l" behaviour
only because it was thought to be useful for gitweb (to have file
sizes in 'tree' view, like cgit has it), although gitweb doesn't use
it yet.
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.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Apply -p<value> on git-diffs that create/delete files
From: Junio C Hamano @ 2008-12-30 9:03 UTC (permalink / raw)
To: Andrew Ruder; +Cc: git
In-Reply-To: <20081230011545.GA81224@bowser.Belkin>
Andrew Ruder <andy@aeruder.net> writes:
> diff --git a/builtin-apply.c b/builtin-apply.c
> index 07244b0..584a910 100644
> --- a/builtin-apply.c
> +++ b/builtin-apply.c
> @@ -656,137 +660,57 @@ static const char *stop_at_slash(const char *line, int llen)
> }
>
> /*
> - * This is to extract the same name that appears on "diff --git"
> - * line. We do not find and return anything if it is a rename
> - * patch, and it is OK because we will find the name elsewhere.
> + * This is to extract the same name that appears on "diff --git" line.
> + * The name that is returned also has the root applied to it and the
> + * p_value applied. We do not find and return anything if it is a
> + * rename patch, and it is OK because we will find the name elsewhere.
> * We need to reliably find name only when it is mode-change only,
> - * creation or deletion of an empty file. In any of these cases,
> - * both sides are the same name under a/ and b/ respectively.
> + * creation or deletion of an empty file. In any of these cases, both
> + * sides are the same name under a/ and b/ respectively.
> */
This is a very good description of what the fix should do.
> +static char *git_header_name(char *line)
> ...
> - /*
> - * Accept a name only if it shows up twice, exactly the same
> - * form.
> - */
> - for (len = 0 ; ; len++) {
> - switch (name[len]) {
> - default:
> - continue;
> - case '\n':
> - return NULL;
> - case '\t': case ' ':
> - second = name+len;
> - for (;;) {
> - char c = *second++;
> - if (c == '\n')
> - return NULL;
> - if (c == '/')
> - break;
> - }
> - if (second[len] == '\n' && !memcmp(name, second, len)) {
> - return xmemdupz(name, len);
> - }
> - }
> - }
You lost the above logic, and instead call find_name() with TERM_SPACE |
TERM_TAB to find the end of the first name and you expect it uniquely will
find it. It unfortunately won't. Consider this patch:
diff --git a/b is file b/b is file
index e69de29..ce01362 100644
--- a/b is file
+++ b/b is file
@@ -0,0 +1 @@
+hello
Your version finds "b" as the first name, skips to "is file b/b is file"
and assume that is the second name, and your new code later mistakenly
declares it as a rename and returns NULL.
> + /* First we see if they match, if they do, we are done. */
> + if (strcmp(first, second)) {
> + const char *first_slash, *second_slash;
> + /* If they don't, we check that we don't have a a/<match> b/<match>, if we
> + * do we return one of those so the error messages go through correctly
> + * later on */
> + first_slash = stop_at_slash(first, strlen(first));
> + second_slash = stop_at_slash(second, strlen(second));
>
> + /* If this fails, it must be a rename, just return NULL */
> + if (!first_slash || !second_slash || strcmp(first_slash, second_slash))
> + goto error2;
> }
It should of course return "b is file"; the complex backgracking you
removed is all about handling this case correctly.
> builtin-apply.c | 203 +++++++++++++++----------------------------------
> t/t4120-apply-popt.sh | 5 +-
> 2 files changed, 64 insertions(+), 144 deletions(-)
I really wished that this reduction of lines resulted in a code with less
bug, though.
^ permalink raw reply
* Re: why still no empty directory support in git
From: Asheesh Laroia @ 2008-12-30 8:58 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <9b18b3110812300043l55a42f6sd995f36bf857543e@mail.gmail.com>
On Tue, 30 Dec 2008, demerphq wrote:
> 2008/12/30 Asheesh Laroia <asheesh@asheesh.org>:
>> I ask about this because I'm using git to track email in Maildir
>> repositories, and in that vein I'm getting bitten by git's removal of
>> empty directories.
>
> Add a .exists to each directory. There is precedent for such an
> approach in other systems.
Delivering mail into a Maildir is a three-step process. Let's say
we are delivering to a Maildir spool stored in ~/Maildir.
(1)
The message is written out to ~/Maildir/tmp/some_filename.
(2)
When the message is complete, it is rename()d to
~/Maildir/new/some_name.
(3)
When a mail user agent reads the Maildir spool, it checks new/ for new
mail. If there is a message there, it renames it to
~/Maildir/cur/some_other_filename and announces to the user, "You've got
mail!"
So, let's say I take your suggestion.
$ touch ~/Maildir/new/.exists
$ git add ~/Maildir/new/.exists && git commit -m "La di da"
Now a spec-compliant Maildir user agent will attempt to deliver this new
"email message" of zero bytes into the mail spool and assign it a message
UID. Doing so will remove it from Maildir/new.
Then I do "git pull" to get the new messages from my mail server's Maildir
repository for my email. This causes git read-tree to eventually be run.
If the new tree has no unprocessed email, git runs rmdir() on
~/Maildir/new/.
Now if I want to write a new email to ~/Maildir/ (such as due to copying
an email from another folder), the Maildir user agent suddenly finds
itself in a strange place: new/ does not exist, violating the definition
of a Maildir. This breaks mail processing for that ~/Maildir/ folder.
This is because git is removing these directories. There is a strict
incompatibility between git rmdir()ing empty directories behind my back
and Maildir systems.
I hope that explains the issue I face, both to Junio and to Yves.
Note that for me, there is no issue with how to handle merging of empty
directories, or what happens if these empty directories become files, or
which empty directories to keep around; if git just never rmdir()s any
directories for me, and otherwise acts identically to now, that would
solve my problem. I can look into preparing an RFC patch that creates a
mode like that.
-- Asheesh.
--
You will be the last person to buy a Chrysler.
^ permalink raw reply
* Re: why still no empty directory support in git
From: demerphq @ 2008-12-30 8:43 UTC (permalink / raw)
To: Asheesh Laroia; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.2.00.0812300113050.22107@vellum.laroia.net>
2008/12/30 Asheesh Laroia <asheesh@asheesh.org>:
> On Tue, 30 Dec 2008, Asheesh Laroia wrote:
>
>> On Tue, 30 Dec 2008, Ping Yin wrote:
>>
>>> 2. unclear logic, for example, whether to remove the directory after the
>>> last file in it is deleted
>>
>> This is the thing I dislike most about git: that it sometimes calls
>> rmdir() for me. At least, one should be able to turn it off in a
>> per-repository basis. I'm going to see how hard a patch that would be to
>> write.
>
> Well, changing this behavior seems to be "as easy as" changing unlink_entry
> in unpack_trees.c to not always rmdir(). The most naive thing I can think of
> is to have unlink_entry in unpack_trees check against the git config. It's
> probably more sensible for unpack_trees to be passed an argument that
> determines if it rmdir()s; that argument could be set via argv at "git
> unpack-tree" time, which could be set out of a configuration value read at
> "git" time.
>
> Would a change of the "more sensible" kind possibly be accepted by the git
> maintainer?
>
> I ask about this because I'm using git to track email in Maildir
> repositories, and in that vein I'm getting bitten by git's removal of empty
> directories.
Add a .exists to each directory. There is precedent for such an
approach in other systems.
cheers,
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: rebase -i: learn to rebase root commit
From: Junio C Hamano @ 2008-12-30 8:22 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <200812292249.45900.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> ... is there any sensible
> use/interpretation of -p --root that I'm missing? Or should it just
> disallow this combination?
If --root is about replaying all the history, wouldn't people want to use
it together with -p to reconstruct the whole history as a substitute for
filter-branch? IOW, I have a suspicion that they most likely should go
together.
I never felt a need to rebase deep down to --root myself anyway, so I am a
bad judge for people's needs on this topic, though.
^ permalink raw reply
* Re: [PATCH] doc/git-send-email: mention sendemail.cc config variable
From: Junio C Hamano @ 2008-12-30 8:00 UTC (permalink / raw)
To: markus.heidelberg; +Cc: Thomas Rast, git
In-Reply-To: <200812291429.01822.markus.heidelberg@web.de>
Markus Heidelberg <markus.heidelberg@web.de> writes:
> It is already in next, I think a following patch should be against next
> now, shouldn't it?
Surely, and thanks.
If you look at the output of
$ git log --first-parent origin/master..origin/next
You will find the tip of mh/maint-sendmail-cc-doc topic branch is at
bd7c6e7 (doc/git-send-email: mention sendemail.cc config variable,
2008-12-29). I'll apply any follow-up patch to the topic on top of that
commit, and then merge the result to 'next' (and 'master'/'maint' when the
result is ready).
In rare cases when there are other topics in 'next' that touch vicinity of
the code you are modifying, a patch made against 'next' may not apply
cleanly to the topic, but I'll wiggle it to apply anyway (that is what the
maintainers do), so it would certainly be nicer if you sent a patch to the
tip of the topic you are updating, but there is no need to worry about
such conflicts too much.
^ permalink raw reply
* Re: why still no empty directory support in git
From: Junio C Hamano @ 2008-12-30 7:45 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Jeff Whiteside, Asheesh Laroia, Git Mailing List
In-Reply-To: <200812300758.41988.robin.rosenberg.lists@dewire.com>
Robin Rosenberg <robin.rosenberg.lists@dewire.com> writes:
> You can have an empty tree, but the index doesn't store them, so they
> would be lost on checkout/commit. Linus sketched a solution, but nobody
> took the bait. Seems doable if anyone really wants it, but I'm certain
> it adds a lot of special cases.
I think the original poster covered that "a lot of special cases" as
"unclear semantics", and there are more. Do you want to have the presense
of empty directory "sticky"? Perhaps it later becomes non-empty at some
point; will the "will always present" attribute kept then? What happens
when such a directory becomes empty later? What should happen when a
branch that has such a directory with "sticky existence" and another
branch with the same directory but without the stickiness are merged?
But I think one bigger reason missing from the list is that many people
loudly talked about "wants", but nobody made convincing argument on
"needs" of such a feature.
^ permalink raw reply
* Re: why still no empty directory support in git
From: Robin Rosenberg @ 2008-12-30 6:58 UTC (permalink / raw)
To: Jeff Whiteside; +Cc: Asheesh Laroia, Git Mailing List
In-Reply-To: <3ab397d0812292128j65e2e1e1xf403a998f4653aac@mail.gmail.com>
tisdag 30 december 2008 06:28:58 skrev Jeff Whiteside:
> funny, i thought it was 1, by design.
Sure, but designs can be changed.
>
> but i forget why a tree object couldn't point to an empty blob.
It can, but that's not the same.
You can have an empty tree, but the index doesn't store them,
so they would be lost on checkout/commit. Linus sketched a solution,
but nobody took the bait. Seems doable if anyone really wants it, but
I'm certain it adds a lot of special cases.
Look for a discussion [RFC PATCH] Re: Empty directories... posted on 2007-07-19.
It's in the middle of a long thread.
-- robin
^ permalink raw reply
* Re: why still no empty directory support in git
From: Asheesh Laroia @ 2008-12-30 6:25 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <alpine.DEB.2.00.0812300008060.31590@vellum.laroia.net>
On Tue, 30 Dec 2008, Asheesh Laroia wrote:
> On Tue, 30 Dec 2008, Ping Yin wrote:
>
>> 2. unclear logic, for example, whether to remove the directory after the
>> last file in it is deleted
>
> This is the thing I dislike most about git: that it sometimes calls rmdir()
> for me. At least, one should be able to turn it off in a per-repository
> basis. I'm going to see how hard a patch that would be to write.
Well, changing this behavior seems to be "as easy as" changing
unlink_entry in unpack_trees.c to not always rmdir(). The most naive thing
I can think of is to have unlink_entry in unpack_trees check against the
git config. It's probably more sensible for unpack_trees to be passed an
argument that determines if it rmdir()s; that argument could be set via
argv at "git unpack-tree" time, which could be set out of a configuration
value read at "git" time.
Would a change of the "more sensible" kind possibly be accepted by the git
maintainer?
I ask about this because I'm using git to track email in Maildir
repositories, and in that vein I'm getting bitten by git's removal of
empty directories.
-- Asheesh.
--
You will gain money by an illegal action.
^ permalink raw reply
* Re: why still no empty directory support in git
From: Liu Yubao @ 2008-12-30 6:09 UTC (permalink / raw)
To: Ping Yin; +Cc: Git Mailing List
In-Reply-To: <46dff0320812291942y6aeec941k9394586621e9151b@mail.gmail.com>
Ping Yin wrote:
> Yes, i know this topic has been discussed for many times. However, i
> am still not clear about the real reason.
>
> So which is the reason?
>
> 1. it's by design, intentional
It's saied somewhere git is a "stupid content tracker", it cares file content
not file name, and empty directories will complicate the merge algorithm
unnecessarily.
> 2. unclear logic, for example, whether to remove the directory after
> the last file in it is deleted
> 3. hard work, no one has picked it yet
> 4. hardly done in current model
>
> Ping Yin
^ permalink raw reply
* Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-)
From: Sitaram Chamarty @ 2008-12-30 5:34 UTC (permalink / raw)
To: git
In-Reply-To: <gjc7qa$jdj$4@ger.gmane.org>
Hi Conor,
On 2008-12-30, Zorba <cr@altmore.co.uk> wrote:
> so when I reset to A, I've still got the ability to get to B or C again
if this is true... (call this case 1)
> Now I appreciate that if I commit a new change from versionA (lets call it
> B1), then HEAD is now at B1, and B, C etc are lost, correct ?
...then this (call this case 2) is not true.
In case 1, *how* do you get back to B and C? However you do
it, the same action will get you to B and C *after* you
created B1 as well.
It might help to think of these things loosely using a
malloc/linked-list analogy. Imagine a singly-linked list,
and a variable in your program called "head" pointing to the
top element. Each element contains a back-pointer to its
parent. You can start from head and walk the list backward,
but you can't walk forward -- there are no forward pointers.
A "git commit" is analogous to:
newblkptr = malloc(...);
... store whatever you want in the new block ...
newblkptr.backptr = head;
head = newblkptr;
i.e., a classic linked list add.
A "git reset --hard HEAD^" essentially pops the topmost
element off the list:
head = head.backptr
A "git checkout -f HEAD^" is like walking a linked list
backward in a loop, and stopping at some intermediate block
to do something -- other the temporary loop-variable,
nothing else (no global variable perhaps) points to this
block, so this is like a detached head.
Of course, nothing prevents you from permanently saving this
temporary loop variable because you suddenly realise *this*
link in the chain is very important for the rest of your
program:
some_global_var = temp_blk_ptr;
This is like "git checkout -b newbranch" does.
> Its pertinent to where I am right now, as I've goofed a commit, and want to
> reset, and commit again but I'm worried about leaveing garbage lying around
> (the commits for version B and C in the example above).
(1) never worry about leaving garbage around; there are many
operations that do that; it's part of the design. Don't
sweat it.
(2) when in doubt, try "gitk --all". That's a good GUI.
I'm normally a CLI freak, but when something needs to be
understood/learnt, a well-designed GUI really helps.
Run "gitk --all" on the side and hit F5 on it after each
operation on the command line -- helped me when I was trying
to figure out what's happening.
PS: although it doesn't mention detached heads,
http://eagain.net/articles/git-for-computer-scientists/
helped me a lot...
^ 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 5:33 UTC (permalink / raw)
To: Zorba; +Cc: git
In-Reply-To: <gjc7qa$jdj$4@ger.gmane.org>
> Thanks for your contrib. I'll pick these up for sure, but right now I'm
> despo to make some progress getting this confounded real-life project
> versioned.
np, i do understand totally.
> I've just made a commit I want to retract.
this is the purpose of git reset --soft/mixed/hard
> I have been using $ git reset --hard <version> as an escalator to ascend /
> descend the versions up and down
you should probably be using git checkout for this
> Surely it doesn't alter the history, as I can commit versionA, versionB,
> versionC, and then reset to A, then reset to C, then reset to B.
i does alter the history. i think this works because git isnt'
deleting the actual blob objects in the git dir until you use the git
prune, or gc or whatever (i never use it anyway). but, you are
altering history, and just happen to be recovering.
> so when I reset to A, I've still got the ability to get to B or C again
with an uneasy conscience ;)
> Now I appreciate that if I commit a new change from versionA (lets call it
> B1), then HEAD is now at B1, and B, C etc are lost, correct ?
yes! but this is not true if you had done a git checkout (there are
measures to recover B and C, provided you haven't done a prune. i
think git reflog has some answers here, but i'm still a newbie).
> Its pertinent to where I am right now, as I've goofed a commit, and want to
> reset, and commit again but I'm worried about leaveing garbage lying around
> (the commits for version B and C in the example above).
you've goofed what commit (a1?, c?, d3?)? where are you now and what
do you want to do now? reset to what version? if you're just worried
about space used by B and C, i think git prune will purge these (look
at man page, don't guess at the syntax).
i half suspect that you want to git branch at some point, but if
yo'ure just recretaing the other code bases' history form other files,
you shouldn't be able to break too much by git reset --hard, or git
prune.
> BTW: sdf=Syntax Definition Formalism?
hahahaha, no, i was just typing/copypasting garbage, because my gmail
woudln't' get out of bold mode and forgot to delete it at the end.
haha.
On Mon, Dec 29, 2008 at 8:24 PM, Zorba <cr@altmore.co.uk> wrote:
> Hi Jeff,
>
> Thanks for your contrib. I'll pick these up for sure, but right now I'm
> despo to make some progress getting this confounded real-life project
> versioned.
>
> But where I'm stuck now touches on your post.
>
> I've just made a commit I want to retract.
>
> I have been using $ git reset --hard <version> as an escalator to ascend /
> descend the versions up and down
> Surely it doesn't alter the history, as I can commit versionA, versionB,
> versionC, and then reset to A, then reset to C, then reset to B.
>
> so when I reset to A, I've still got the ability to get to B or C again
>
> Now I appreciate that if I commit a new change from versionA (lets call it
> B1), then HEAD is now at B1, and B, C etc are lost, correct ?
>
> Its pertinent to where I am right now, as I've goofed a commit, and want to
> reset, and commit again but I'm worried about leaveing garbage lying around
> (the commits for version B and C in the example above).
>
> NB if you read my latest posts you will see why I chose the example I did
> for my "warm-up" as it closely models what I'm trying to do for real.
>
>
> BTW: sdf=Syntax Definition Formalism?
>
> "Jeff Whiteside" <jeff.m.whiteside@gmail.com> wrote in message
> news:3ab397d0812291505v77824e6fvdecebc80f38a5f89@mail.gmail.com...
>
> -"Rollback to each of the versions, starting with version A"
> this is bad. you're saying rollback. to others that have used scms,
> this will mean, "retrieve an older copy", but in git, this is DELETING
> all the versions after the version that you "rollback" to. your blog
> post shouldn't discuss the git-reset --hard command at all, since
> you're rewriting history, which is dangerous. afaik, most scms don't
> allow you to rewrite history. to "rollback" to an older version you
> should use checkout the git-checkout command. maybe the git reset
> -–hard HEAD is okay to include... but it won't be immediately obvious
> to new users why it does what it does... this nomenclature was likely
> not the best choice whenever it was made.
>
>
> gl with your gitting.
>
> whiteside
>
>
>
>
> u're talking sdf
>
>
>
>
> On Sat, Dec 27, 2008 at 5:29 PM, Zorba <cr@altmore.co.uk> wrote:
>>
>> tidied up the formatting, added a few more comments where needed, fixed
>> errors/lack of clarity
>>
>> "Zorba" <cr@altmore.co.uk> wrote in message
>> news:gj68a0$u56$3@ger.gmane.org...
>> > Here is a little exercise / tutorial / warm-up for someone starting out
>> > with Git. If you're anyting like me you may find the tutorials etc. on
>> > git.or.cz a bit daunting. I recommend you try this after reading the
>> > user
>> > manual but before tearing your hair out trying to follow all the
>> > examples
>> > in the user manual. After you've followed this simple workflow, then go
>> > back to the more advanced stuff in the tutorials and user manuals (like
>> > cloning repositories and creating and merging branches).
>> >
>> > I created this exercise to try and model our workflow and what we wanted
>> > to use git for = tracking a project with multiple files where the
>> > filebase
>> > might change frequently from one version to the next.
>> >
>> > http://siliconmouth.wordpress.com/category/nerdy/
>> >
>> > look for December 27, 2008 or "git warmup"
>> >
>> >
>>
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: is there an easier way to do this ? [Scanned]
From: Jeff Whiteside @ 2008-12-30 5:32 UTC (permalink / raw)
To: Zorba; +Cc: git
In-Reply-To: <gjc83i$juc$4@ger.gmane.org>
you should reply to the original thread, so that you don't create a
new one. makes it almost impossible to find what you're referencing.
also, don't bother with git-rm. a simple rm is the same thing.
(committing will notice that this file is gone)
On Mon, Dec 29, 2008 at 8:29 PM, Zorba <cr@altmore.co.uk> wrote:
> (punches air with fist)
> yes indeed !
>
> sorry, I didn't follow up on the --update flag first time
>
> $ git add -A .
> $ git commit
>
> home in a boat!
>
> "Jacob Helwig" <jacob.helwig@gmail.com> wrote in message
> news:8c9a060812292017m600ca246pf8660630d49a7067@mail.gmail.com...
>> On Mon, Dec 29, 2008 at 20:11, Conor Rafferty
>> <conor.rafferty@altmore.co.uk> wrote:
>>> Ah, but what about the files that have been removed from this version ?
>>> - that's the whole point of doing commit -a, so I don't have to spend
>>> ages doing diffs to produce a list of files to feed into git-rm
>>>
>>> Or have I missed another glarer ?
>>>
>>> -----Original Message-----
>>> From: Jacob Helwig [mailto:jacob.helwig@gmail.com]
>>> Sent: 30 December 2008 04:01
>>> To: git@vger.kernel.org
>>> Cc: Conor Rafferty
>>> Subject: Re: is there an easier way to do this ? [Scanned]
>>>
>>> On Mon, Dec 29, 2008 at 19:51, Zorba <cr@altmore.co.uk> wrote:
>>>> The manual shows you can SHOW untracked files, but not add them as
>>>> part of the commit -a jig
>>>>
>>>> Seems a bit strange that git-add operates on both exisging and new
>>>> files when used standalone, but its behaviour changes when
>>>> encapsulated in commit -a...
>>>>
>>>> So, I thought maybe $ git commit -a, then $ git add .
>>>> but then the files tracked have missed the commit boat they were meant
>>>
>>>> to be on, haven't they,
>>>>
>>>> hang on -
>>>> what about
>>>>
>>>> $ git add .
>>>> $ git commit -a
>>>>
>>>> I do believe I've cracked it
>>>> if so, it seems a bit wasteful, 2x adds (one explicti and one embedded
>>>
>>>> in -a) ? shame on you linux kernel guys, i'd have expected better :-)
>>>>
>>>> "Zorba" <cr@altmore.co.uk> wrote in message
>>>> news:gjc52u$ehc$4@ger.gmane.org...
>>>>> 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, so delete version 1 files from GIT dir,
>>>>> copy in version 2
>>>>> version2 has different files from 1 - which ones? Out of 5k files
>>>>> could be 1% = 50 new ones, and same amount removed. Why should I
>>>>> care, with such a powerful friend as git around, n'est pas?
>>>>> THIS TIME we are going to be CLEVER and use "-a" flag on commit to
>>>>> pick up any files that have been REMOVED (or "deleted" in git-speak)
>>>>>
>>>>> $ git commit -a -m "version2"
>>>>>
>>>>> BUT this does not pick up any new ones that have been added,
>>>>>
>>>>> and when we run
>>>>>
>>>>> $ git status > ../git_status.txt
>>>>>
>>>>> these are referred to as "untracked files"
>>>>> only problem there are 50 ish
>>>>> is there not another flag on git commit to treat any untracked file
>>>>> as a new file ?
>>>>> (would save me typing or creating a list out of these untracked ones
>>>>> and feeding them into git add)
>>>>>
>>>>> I know, I realise now I should have looked up git-commit in the
>>>>> manual - in case its not there, pls enlighten me !
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe git" in the
>>>> body of a message to majordomo@vger.kernel.org More majordomo info at
>>>> http://vger.kernel.org/majordomo-info.html
>>>>
>>>
>>> If you do an explicit git add, then you don't need the -a on git commit,
>>> since everything you want to commit will already be in the index for git
>>> commit to work with.
>>>
>>
>> See the -A flag for git add (and it's reference to --update). -A will
>> remove files that have been removed, add untracked, and update ones
>> that have changed, all in one go.
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: why still no empty directory support in git
From: Jeff Whiteside @ 2008-12-30 5:28 UTC (permalink / raw)
To: Asheesh Laroia; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.2.00.0812300008060.31590@vellum.laroia.net>
funny, i thought it was 1, by design.
but i forget why a tree object couldn't point to an empty blob.
^ permalink raw reply
* Re: why still no empty directory support in git
From: Asheesh Laroia @ 2008-12-30 5:10 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <46dff0320812291942y6aeec941k9394586621e9151b@mail.gmail.com>
On Tue, 30 Dec 2008, Ping Yin wrote:
> 2. unclear logic, for example, whether to remove the directory after the
> last file in it is deleted
This is the thing I dislike most about git: that it sometimes calls
rmdir() for me. At least, one should be able to turn it off in a
per-repository basis. I'm going to see how hard a patch that would be to
write.
> 3. hard work, no one has picked it yet
This is what I recall.
-- Asheesh.
--
Writing is turning one's worst moments into money.
-- J.P. Donleavy
^ permalink raw reply
* Re: is there an easier way to do this ? [Scanned]
From: Zorba @ 2008-12-30 4:29 UTC (permalink / raw)
To: git
In-Reply-To: <8c9a060812292017m600ca246pf8660630d49a7067@mail.gmail.com>
(punches air with fist)
yes indeed !
sorry, I didn't follow up on the --update flag first time
$ git add -A .
$ git commit
home in a boat!
"Jacob Helwig" <jacob.helwig@gmail.com> wrote in message
news:8c9a060812292017m600ca246pf8660630d49a7067@mail.gmail.com...
> On Mon, Dec 29, 2008 at 20:11, Conor Rafferty
> <conor.rafferty@altmore.co.uk> wrote:
>> Ah, but what about the files that have been removed from this version ?
>> - that's the whole point of doing commit -a, so I don't have to spend
>> ages doing diffs to produce a list of files to feed into git-rm
>>
>> Or have I missed another glarer ?
>>
>> -----Original Message-----
>> From: Jacob Helwig [mailto:jacob.helwig@gmail.com]
>> Sent: 30 December 2008 04:01
>> To: git@vger.kernel.org
>> Cc: Conor Rafferty
>> Subject: Re: is there an easier way to do this ? [Scanned]
>>
>> On Mon, Dec 29, 2008 at 19:51, Zorba <cr@altmore.co.uk> wrote:
>>> The manual shows you can SHOW untracked files, but not add them as
>>> part of the commit -a jig
>>>
>>> Seems a bit strange that git-add operates on both exisging and new
>>> files when used standalone, but its behaviour changes when
>>> encapsulated in commit -a...
>>>
>>> So, I thought maybe $ git commit -a, then $ git add .
>>> but then the files tracked have missed the commit boat they were meant
>>
>>> to be on, haven't they,
>>>
>>> hang on -
>>> what about
>>>
>>> $ git add .
>>> $ git commit -a
>>>
>>> I do believe I've cracked it
>>> if so, it seems a bit wasteful, 2x adds (one explicti and one embedded
>>
>>> in -a) ? shame on you linux kernel guys, i'd have expected better :-)
>>>
>>> "Zorba" <cr@altmore.co.uk> wrote in message
>>> news:gjc52u$ehc$4@ger.gmane.org...
>>>> 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, so delete version 1 files from GIT dir,
>>>> copy in version 2
>>>> version2 has different files from 1 - which ones? Out of 5k files
>>>> could be 1% = 50 new ones, and same amount removed. Why should I
>>>> care, with such a powerful friend as git around, n'est pas?
>>>> THIS TIME we are going to be CLEVER and use "-a" flag on commit to
>>>> pick up any files that have been REMOVED (or "deleted" in git-speak)
>>>>
>>>> $ git commit -a -m "version2"
>>>>
>>>> BUT this does not pick up any new ones that have been added,
>>>>
>>>> and when we run
>>>>
>>>> $ git status > ../git_status.txt
>>>>
>>>> these are referred to as "untracked files"
>>>> only problem there are 50 ish
>>>> is there not another flag on git commit to treat any untracked file
>>>> as a new file ?
>>>> (would save me typing or creating a list out of these untracked ones
>>>> and feeding them into git add)
>>>>
>>>> I know, I realise now I should have looked up git-commit in the
>>>> manual - in case its not there, pls enlighten me !
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe git" in the
>>> body of a message to majordomo@vger.kernel.org More majordomo info at
>>> http://vger.kernel.org/majordomo-info.html
>>>
>>
>> If you do an explicit git add, then you don't need the -a on git commit,
>> since everything you want to commit will already be in the index for git
>> commit to work with.
>>
>
> See the -A flag for git add (and it's reference to --update). -A will
> remove files that have been removed, add untracked, and update ones
> that have changed, all in one go.
^ permalink raw reply
* Re: is there an easier way to do this ?
From: Jeff Whiteside @ 2008-12-30 4:26 UTC (permalink / raw)
To: Jacob Helwig; +Cc: git, Zorba
In-Reply-To: <8c9a060812292000k18ccd466g628ea4161bac188b@mail.gmail.com>
$ git add .
$ git commit -a
no, you don't need git commit -a, just git commit
so,
$ git add .
$ git commit -m "my msg"
why?
git add . will add everything to the index, including a notation about
removing deleted files (i hope you know what the index is, if not,
google 'index' or 'staging area', this will clear everything up).
git commit will take everything from the index and commit (not the
working tree of files) it to the actual repository.
git commit -a will take every file that is already tracked in git, but
NOT newly added files, and add/update the content in the index, then
commit it.
so, git commit -a is equivalent to
git add -u
git commit
On Mon, Dec 29, 2008 at 8:00 PM, Jacob Helwig <jacob.helwig@gmail.com> wrote:
> On Mon, Dec 29, 2008 at 19:51, Zorba <cr@altmore.co.uk> wrote:
>> The manual shows you can SHOW untracked files, but not add them as part of
>> the commit -a jig
>>
>> Seems a bit strange that git-add operates on both exisging and new files
>> when used standalone, but its behaviour changes when encapsulated in
>> commit -a...
>>
>> So, I thought maybe $ git commit -a, then $ git add .
>> but then the files tracked have missed the commit boat they were meant to be
>> on, haven't they,
>>
>> hang on -
>> what about
>>
>> $ git add .
>> $ git commit -a
>>
>> I do believe I've cracked it
>> if so, it seems a bit wasteful, 2x adds (one explicti and one embedded
>> in -a) ? shame on you linux kernel guys, i'd have expected better :-)
>>
>> "Zorba" <cr@altmore.co.uk> wrote in message
>> news:gjc52u$ehc$4@ger.gmane.org...
>>> 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, so delete version 1 files from GIT dir, copy
>>> in version 2
>>> version2 has different files from 1 - which ones? Out of 5k files could be
>>> 1% = 50 new ones, and same amount removed. Why should I care, with such a
>>> powerful friend as git around, n'est pas?
>>> THIS TIME we are going to be CLEVER and use "-a" flag on commit to pick up
>>> any files that have been REMOVED (or "deleted" in git-speak)
>>>
>>> $ git commit -a -m "version2"
>>>
>>> BUT this does not pick up any new ones that have been added,
>>>
>>> and when we run
>>>
>>> $ git status > ../git_status.txt
>>>
>>> these are referred to as "untracked files"
>>> only problem there are 50 ish
>>> is there not another flag on git commit to treat any untracked file as a
>>> new file ?
>>> (would save me typing or creating a list out of these untracked ones and
>>> feeding them into git add)
>>>
>>> I know, I realise now I should have looked up git-commit in the manual -
>>> in case its not there, pls enlighten me !
>>>
>>>
>>>
>>
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
> If you do an explicit git add, then you don't need the -a on git
> commit, since everything you want to commit will already be in the
> index for git commit to work with.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: for newbs = little exercise / tutorial / warmup for windows and other non-sophisticated new Git users :-)
From: Zorba @ 2008-12-30 4:24 UTC (permalink / raw)
To: git
In-Reply-To: <3ab397d0812291505v77824e6fvdecebc80f38a5f89@mail.gmail.com>
Hi Jeff,
Thanks for your contrib. I'll pick these up for sure, but right now I'm
despo to make some progress getting this confounded real-life project
versioned.
But where I'm stuck now touches on your post.
I've just made a commit I want to retract.
I have been using $ git reset --hard <version> as an escalator to ascend /
descend the versions up and down
Surely it doesn't alter the history, as I can commit versionA, versionB,
versionC, and then reset to A, then reset to C, then reset to B.
so when I reset to A, I've still got the ability to get to B or C again
Now I appreciate that if I commit a new change from versionA (lets call it
B1), then HEAD is now at B1, and B, C etc are lost, correct ?
Its pertinent to where I am right now, as I've goofed a commit, and want to
reset, and commit again but I'm worried about leaveing garbage lying around
(the commits for version B and C in the example above).
NB if you read my latest posts you will see why I chose the example I did
for my "warm-up" as it closely models what I'm trying to do for real.
BTW: sdf=Syntax Definition Formalism?
"Jeff Whiteside" <jeff.m.whiteside@gmail.com> wrote in message
news:3ab397d0812291505v77824e6fvdecebc80f38a5f89@mail.gmail.com...
-"Rollback to each of the versions, starting with version A"
this is bad. you're saying rollback. to others that have used scms,
this will mean, "retrieve an older copy", but in git, this is DELETING
all the versions after the version that you "rollback" to. your blog
post shouldn't discuss the git-reset --hard command at all, since
you're rewriting history, which is dangerous. afaik, most scms don't
allow you to rewrite history. to "rollback" to an older version you
should use checkout the git-checkout command. maybe the git reset
-–hard HEAD is okay to include... but it won't be immediately obvious
to new users why it does what it does... this nomenclature was likely
not the best choice whenever it was made.
gl with your gitting.
whiteside
u're talking sdf
On Sat, Dec 27, 2008 at 5:29 PM, Zorba <cr@altmore.co.uk> wrote:
>
> tidied up the formatting, added a few more comments where needed, fixed
> errors/lack of clarity
>
> "Zorba" <cr@altmore.co.uk> wrote in message
> news:gj68a0$u56$3@ger.gmane.org...
> > Here is a little exercise / tutorial / warm-up for someone starting out
> > with Git. If you're anyting like me you may find the tutorials etc. on
> > git.or.cz a bit daunting. I recommend you try this after reading the
> > user
> > manual but before tearing your hair out trying to follow all the
> > examples
> > in the user manual. After you've followed this simple workflow, then go
> > back to the more advanced stuff in the tutorials and user manuals (like
> > cloning repositories and creating and merging branches).
> >
> > I created this exercise to try and model our workflow and what we wanted
> > to use git for = tracking a project with multiple files where the
> > filebase
> > might change frequently from one version to the next.
> >
> > http://siliconmouth.wordpress.com/category/nerdy/
> >
> > look for December 27, 2008 or "git warmup"
> >
> >
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: is there an easier way to do this ? [Scanned]
From: Jacob Helwig @ 2008-12-30 4:17 UTC (permalink / raw)
To: Git; +Cc: Conor Rafferty
In-Reply-To: <BB5F02FD3789B54E8964D38D6775E718242D1B@ALTMORE-SVR.altmore.local>
On Mon, Dec 29, 2008 at 20:11, Conor Rafferty
<conor.rafferty@altmore.co.uk> wrote:
> Ah, but what about the files that have been removed from this version ?
> - that's the whole point of doing commit -a, so I don't have to spend
> ages doing diffs to produce a list of files to feed into git-rm
>
> Or have I missed another glarer ?
>
> -----Original Message-----
> From: Jacob Helwig [mailto:jacob.helwig@gmail.com]
> Sent: 30 December 2008 04:01
> To: git@vger.kernel.org
> Cc: Conor Rafferty
> Subject: Re: is there an easier way to do this ? [Scanned]
>
> On Mon, Dec 29, 2008 at 19:51, Zorba <cr@altmore.co.uk> wrote:
>> The manual shows you can SHOW untracked files, but not add them as
>> part of the commit -a jig
>>
>> Seems a bit strange that git-add operates on both exisging and new
>> files when used standalone, but its behaviour changes when
>> encapsulated in commit -a...
>>
>> So, I thought maybe $ git commit -a, then $ git add .
>> but then the files tracked have missed the commit boat they were meant
>
>> to be on, haven't they,
>>
>> hang on -
>> what about
>>
>> $ git add .
>> $ git commit -a
>>
>> I do believe I've cracked it
>> if so, it seems a bit wasteful, 2x adds (one explicti and one embedded
>
>> in -a) ? shame on you linux kernel guys, i'd have expected better :-)
>>
>> "Zorba" <cr@altmore.co.uk> wrote in message
>> news:gjc52u$ehc$4@ger.gmane.org...
>>> 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, so delete version 1 files from GIT dir,
>>> copy in version 2
>>> version2 has different files from 1 - which ones? Out of 5k files
>>> could be 1% = 50 new ones, and same amount removed. Why should I
>>> care, with such a powerful friend as git around, n'est pas?
>>> THIS TIME we are going to be CLEVER and use "-a" flag on commit to
>>> pick up any files that have been REMOVED (or "deleted" in git-speak)
>>>
>>> $ git commit -a -m "version2"
>>>
>>> BUT this does not pick up any new ones that have been added,
>>>
>>> and when we run
>>>
>>> $ git status > ../git_status.txt
>>>
>>> these are referred to as "untracked files"
>>> only problem there are 50 ish
>>> is there not another flag on git commit to treat any untracked file
>>> as a new file ?
>>> (would save me typing or creating a list out of these untracked ones
>>> and feeding them into git add)
>>>
>>> I know, I realise now I should have looked up git-commit in the
>>> manual - in case its not there, pls enlighten me !
>>>
>>>
>>>
>>
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in the
>> body of a message to majordomo@vger.kernel.org More majordomo info at
>> http://vger.kernel.org/majordomo-info.html
>>
>
> If you do an explicit git add, then you don't need the -a on git commit,
> since everything you want to commit will already be in the index for git
> commit to work with.
>
See the -A flag for git add (and it's reference to --update). -A will
remove files that have been removed, add untracked, and update ones
that have changed, all in one go.
^ permalink raw reply
* RE: is there an easier way to do this ? [Scanned]
From: Conor Rafferty @ 2008-12-30 4:11 UTC (permalink / raw)
To: Jacob Helwig; +Cc: git
Ah, but what about the files that have been removed from this version ?
- that's the whole point of doing commit -a, so I don't have to spend
ages doing diffs to produce a list of files to feed into git-rm
Or have I missed another glarer ?
-----Original Message-----
From: Jacob Helwig [mailto:jacob.helwig@gmail.com]
Sent: 30 December 2008 04:01
To: git@vger.kernel.org
Cc: Conor Rafferty
Subject: Re: is there an easier way to do this ? [Scanned]
On Mon, Dec 29, 2008 at 19:51, Zorba <cr@altmore.co.uk> wrote:
> The manual shows you can SHOW untracked files, but not add them as
> part of the commit -a jig
>
> Seems a bit strange that git-add operates on both exisging and new
> files when used standalone, but its behaviour changes when
> encapsulated in commit -a...
>
> So, I thought maybe $ git commit -a, then $ git add .
> but then the files tracked have missed the commit boat they were meant
> to be on, haven't they,
>
> hang on -
> what about
>
> $ git add .
> $ git commit -a
>
> I do believe I've cracked it
> if so, it seems a bit wasteful, 2x adds (one explicti and one embedded
> in -a) ? shame on you linux kernel guys, i'd have expected better :-)
>
> "Zorba" <cr@altmore.co.uk> wrote in message
> news:gjc52u$ehc$4@ger.gmane.org...
>> 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, so delete version 1 files from GIT dir,
>> copy in version 2
>> version2 has different files from 1 - which ones? Out of 5k files
>> could be 1% = 50 new ones, and same amount removed. Why should I
>> care, with such a powerful friend as git around, n'est pas?
>> THIS TIME we are going to be CLEVER and use "-a" flag on commit to
>> pick up any files that have been REMOVED (or "deleted" in git-speak)
>>
>> $ git commit -a -m "version2"
>>
>> BUT this does not pick up any new ones that have been added,
>>
>> and when we run
>>
>> $ git status > ../git_status.txt
>>
>> these are referred to as "untracked files"
>> only problem there are 50 ish
>> is there not another flag on git commit to treat any untracked file
>> as a new file ?
>> (would save me typing or creating a list out of these untracked ones
>> and feeding them into git add)
>>
>> I know, I realise now I should have looked up git-commit in the
>> manual - in case its not there, pls enlighten me !
>>
>>
>>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in the
> body of a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
>
If you do an explicit git add, then you don't need the -a on git commit,
since everything you want to commit will already be in the index for git
commit to work with.
^ permalink raw reply
* Re: is there an easier way to do this ?
From: Jacob Helwig @ 2008-12-30 4:00 UTC (permalink / raw)
To: git; +Cc: Zorba
In-Reply-To: <gjc5t2$g02$4@ger.gmane.org>
On Mon, Dec 29, 2008 at 19:51, Zorba <cr@altmore.co.uk> wrote:
> The manual shows you can SHOW untracked files, but not add them as part of
> the commit -a jig
>
> Seems a bit strange that git-add operates on both exisging and new files
> when used standalone, but its behaviour changes when encapsulated in
> commit -a...
>
> So, I thought maybe $ git commit -a, then $ git add .
> but then the files tracked have missed the commit boat they were meant to be
> on, haven't they,
>
> hang on -
> what about
>
> $ git add .
> $ git commit -a
>
> I do believe I've cracked it
> if so, it seems a bit wasteful, 2x adds (one explicti and one embedded
> in -a) ? shame on you linux kernel guys, i'd have expected better :-)
>
> "Zorba" <cr@altmore.co.uk> wrote in message
> news:gjc52u$ehc$4@ger.gmane.org...
>> 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, so delete version 1 files from GIT dir, copy
>> in version 2
>> version2 has different files from 1 - which ones? Out of 5k files could be
>> 1% = 50 new ones, and same amount removed. Why should I care, with such a
>> powerful friend as git around, n'est pas?
>> THIS TIME we are going to be CLEVER and use "-a" flag on commit to pick up
>> any files that have been REMOVED (or "deleted" in git-speak)
>>
>> $ git commit -a -m "version2"
>>
>> BUT this does not pick up any new ones that have been added,
>>
>> and when we run
>>
>> $ git status > ../git_status.txt
>>
>> these are referred to as "untracked files"
>> only problem there are 50 ish
>> is there not another flag on git commit to treat any untracked file as a
>> new file ?
>> (would save me typing or creating a list out of these untracked ones and
>> feeding them into git add)
>>
>> I know, I realise now I should have looked up git-commit in the manual -
>> in case its not there, pls enlighten me !
>>
>>
>>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
If you do an explicit git add, then you don't need the -a on git
commit, since everything you want to commit will already be in the
index for git commit to work with.
^ 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