[U-Boot-Users] [PATCH] Add .gitignore files

Grant Likely grant.likely at secretlab.ca
Tue Feb 27 07:42:47 CET 2007


On 2/26/07, Wolfgang Denk <wd at denx.de> wrote:
> In message <528646bc0702261635y51e80d76sd27c4b113eb09820 at mail.gmail.com> you wrote:
> >
> > It forces the assumption that you must 'make clean' before you commit.
>
> Well, I don't have to do that.
>
> Maybe my confusion / ignorance comes from the fact that I tend to use
> cogito rather that raw git commands.

Actually, I think you've hit on something here that I wasn't thinking
about.  By default,cg-commit records all changes in the working set.
git-commit requires you to explicitly mark the files for commit (using
one of git-update-index, git-commit <filelist>, or git-commit -a).  So
while the resulting tree is compatible (praise God!), it does
encourage a different usage model.

With cg-commit, you don't really need cg-status.  When you do a
cg-commit, it brings up an editor window and tells you exactly what it
intends to commit, and even gives you the option to change the commit
list before finishing.  cg-status is redundant for this activity.

With git-commit, it's different.  git-status is used multiple times to
determine what state the index is in.  Calls to git-update-index,
git-add and git-rm are used to manipulate the index before finally
calling git-commit.  hollisb would puke on this UI, but some of us
actually like it.  :)

Not having a nice set of .gitignore files doesn't really impact
cg-commit usage, but it severely impacts those of us using git-commit.
 Every time we do a git-status there are a load of uninteresting .o
files interleaved with a (usually) small number interesting changes.
Plus, if you're like me and make many commits 'on the fly', then it
becomes invasive to do a 'make clean' before the output git-status
becomes parseable by mere mortals.

>
> > There is a strongly established workflow convention use by other
> > git-using projects.  The workflow for committing is this:
> > $ git-status   # to show what has changed/added/removed
> > $ git-update-index   # as needed to update the index
> > $ git-commit    # make it real;
> > It should be noted that 'make clean' is not a required step for the
> > commit workflow.
> >
> > Alternately, the same thing is done with cogito:
> > $ cg-status
> > $ cg-commit
>
> I can do this fine even with uncleanded files. cg-commit will not anny
> files that have not been added with cg-add.
>
> Is this different with above sequence of git commands?

No it's not different.  Your right.  New files must always be
explicitly added.  I was also wrong when I wrote the cogito workflow
above; cg-status is redundant.

> I always assumed that you have to use "git-add"  to  explicitely  add
> new files to the idex. Is this assumption wrong?
>
> If not, what do a few extra files hurt when running a commit?

A few extra files (under 10): wouldn't hurt a bit
The 400 .o files that git-status currently reports: Pretty much
cripples git-status for the purpose of preparing the index for a
commit.

>
> I lost you here. Why do you need the output of git-status  to  commit
> changes?

As discussed above, git-commit needs to be explicitly told which files
to commit.  By default, it commits nothing.  (as opposed to the
cg-commit default, which is to commit everything).

>
> > The next question that must be asked is "why does it matter?"  If
> > u-boot has it's own convention and the commands all work, then what's
> > the problem?  The problem is that it erects an artificial barrier
> > between the developing for u-boot and for other projects, *while
> > adding no significant benefit*.  The last part is important.  If
> > significant benefit can be shown to differing from the conventions
> > used by other project, then I strongly support such a difference.
>
> You are really persuasive.

Thanks!  :-)

> > I second the argument that's already been made the number of people
> > inconvenienced by .gitignore absence is greater than the number
> > inconvenienced by their presence.  :-P
>
> So much ado about this ...
>
> You leave me no sane way out but to give in, but at least I  want  to
> understand why all this is needed. I don't get it yet.

Hehehe, I probably owe you like 10 beers to offset some of the debates
I've instigated lately.  Are you going to be able to make it to OLS
this year?

Cheers,
g.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195




More information about the U-Boot mailing list